Ethereum Core Devs Meeting 109 Agenda #289
Comments
|
(example comment):
|
|
Removed EIP-3322 from the agenda because it was agreed on ACD 108 not to include in London. See #266 (comment) |
|
Berlin is out of the door for most testnets right now. Could we aim to move EIPs 2930 and 2929 from |
|
@evertonfraga good point! @holiman @MicahZoltu could you please move EIPs 2718, 2929 and 2930 to Last Call? We should move them to Final in the call after. |
|
@timbeiko Whether it comes before or after the merge, I think a clear candidate for a future "feature" fork is to pull together our outstanding EVM proposals into a coherent whole. I've re-opened an EVM group on the Magician's as a place to start on these and others.
|
This comment has been minimized.
This comment has been minimized.
|
The same thing is also caused by for instance EIP1559, which had an old reference implementation based upon a much older spec in it for a long time. Why does the EIP not have a security process? I agree. 1559 presents a huge security risk due to the major changes in base fees calculations and burning. The later has never been done before for any crypto currency. I found the admission in the EIP alarming that they have no idea what impact fee burning will have. I would have expected at least two seperate audits before 1559 was accepted since there are different security risks associated with those two. 1559 lists four securiry concerns, none of which had formal audits, why? Also it may help to understand the guidelines (not sure there are any) if we can list EIPs that have been audited before in the past and why? I will start the list:
|
EIPs have a security section. It's expected that EIPs are vetted in various discussion forums, and the implementations vetted, tested, audited, just like every single thing that ever touches how clients reach consensus.
Yes. So do you think that behaviour is worse, from a security perspective, than the unbounded state growth which is a clear and present DoS vector against all nodes on the network? And if so, how come you have not raised this in the discussion-forums, or ACD channel or call?
2315 was fuzzed quite a lot. It was also again fuzzed in the first testnet. The idea behind the feature-testnets was to test the features, yolov3 focused on 2930 and 2929, which were new. We didn't focus on the non-features. I think the amount of people who actually sent transactions on yolov3 can be counted on one hand. With fingers to spare.
Does that mean "the geth team should set up more testnets, and the test-team should work harder", or does it mean "we'll take more responsibility for cross-client testing going forward". Sorry if I sound angry, I felt a bit personally attacked here, and I probably should have not responded right now. It's a bit annoying that when we do find issues, it's more or less "ok, thanks, fixed, let's move on", while when something slips through it's a lot of high and mighty outrage about "the process". |
|
A few more comments:
The challenge here is that EIP authors are the only people who can update their EIPs, so there is a limit to what "management" can do.
Those tests are not written yet, and they typically are done later in the upgrade process. We are about to work on them, and I had planned to ask about them on tomorrow's call. |
It's worth noting that there has been unprecedentedly extensive economic review and audits on EIP 1559's economics, including concerns about the consequences of burning (this is of course separate from the question of whether the code correctly implements the economics, but that's not a bigger problem for this EIP than for any other). This all happened throughout 2019 and 2020. So I don't see any good reason to reopen that can of worms. Technical tests of the spec/code should of course be done as with any EIP. |
On this topic, one thing to keep in mind is that with an accelerated merge this is probably not worth it, because the beacon chain already stores historical beacon roots in the beacon state, and so the first post-merge fork that adds a BEACONBLOCKROOT opcode can easily provide similar functionality. |
I am not aware of any formal audits done for 1559 by third party independant agencies and where the funding came from. Can you elaborate more, perhaps provide some links to the formal audit reports and shed some light on the third party auditors and who funded the audits? When I did a google search for Ethereum audits I came up with this for 1057, could not find anything on 1559. https://leastauthority.com/static/publications/LeastAuthority-ProgPow-Algorithm-Final-Audit-Report.pdf Can you provide a likewise audit of 1559? I also found 2.0 has been audited so that makes two audits that I know of, well actually only one for Eth 1.0 Found this on Discord 1559-fee-market Perhaps Micah has a great point. This is where the distrust of miners and the EIP process began and continues to this day with 1559 being implemented without the same dick move requiring an audit, using Micah's elegant words It also seems there was money allocated for a formal audit from the grant @timbeiko was this ever done? . |
|
@holiman I am sorry that you felt personally attacked. The goal of the raising this point was to create a safer ecosystem and not to (indirectly) attack people. You are absolutely right, I should not have raised this issue here and instead asked questions elsewhere like allcoredevs. I also seem to lack a lot of knowledge of what is going on to increase security. Sorry for being so ignorant, and sorry for making you feel bad. I have retracted my post. |
|
@CryptoBlockchainTechnologies if you have concerns w.r.t. 1559, please share them on the EIP's "discussions-to" link. Quick FYI: not all EIPs have technical audits. 1559's biggest change was economic, not technical, and there was a 50 page paper analyzing it: https://timroughgarden.org/papers/eip1559.pdf We also ran extensive client testing to assess its impact, and have built several testnets (and will do more, along with reference tests) to check consensus between clients. |
I was asking questions in response to Vitalik's comment and in fact agreed with Micah and filled in some of the questions myself. Thanks for the update also. I do agree with the OP that the ACD needs to come up with governance rules on when an audit is required and what type of EIP would require this. |
|
Closed in favor of #293 |
|
ACD 109: April 2, 2021
Note, with DST ending, the meeting time may be different in your region. Please double-check the meeting time in the section below. UTC time does not "move".
Meeting Info
Agenda
BASE FEEOpcode #270AUTHandAUTHCALLopcodes #260initcode#271The text was updated successfully, but these errors were encountered: