Ethereum Core Devs Meeting 131 Agenda #459
Comments
|
I'd like to throw an item for ethereum/execution-specs on there, just to talk about the project and get some feedback. |
|
A couple of Engine API things to discuss:
|
|
We'd like to propose EIP-3074 for CFI. ducks |
|
As discussed around last ACD, we've slowly pushed the last EOF-related EIP, which introduces function sections and could deprecate dynamic jumps entirely. I'd like to propose it for CFI: #471. |
|
@gcolvin @axic @lightclient added all your suggestions to the agenda 👍 That said, I think there's a "meta" Shanghai discussion to have before diving deep into all these proposals. On the last call (and quickly after on discord), there seemed to be strong consensus about moving forward with the 3 original EOF EIPs (3540, 3670, 3860), and that was main motivation to include them for consideration on the call. There are a lot of EIPs considered for Shanghai, and we realistically can't do everything, so I think we need to think hard about what we prioritize and how we make sure to not pre-commit to too many things when The Merge is still a WIP. This large set of competing EIPs is what prompted the original discussion and I think it's important we get the big picture right before making too many decisions. |
|
As discussed previously on ACD 125 (#401), we want to introduce the statelessness gas cost changes and deactivation of
|
|
Continuing the discussion on pre-sharding calldata cost relief, here is a proposal to bring in "blob-carrying transactions" that contain data inaccessible to EVM execution, in the same format as what we will ultimately use for sharding. Simple version (easier to implement, but leaves more work for later): https://notes.ethereum.org/@vbuterin/blob_transactions_simple More complex version (harder to implement, but leaves a very easy transition for sharding): https://notes.ethereum.org/@vbuterin/blob_transactions If it can be realistically included in Shanghai, this is a potential replacement for EIP 4488. If it cannot, then I still strongly favor EIP 4488 in Shanghai (if not sooner) and then implementing this EIP a few months later. |
|
I'd like to mention the Kintsugi incident report documented here: https://notes.ethereum.org/@ExXcnR0-SJGthjz1dwkA1A/BkkdHWXTY afaik no discussion is needed on the topic during ACD, but it would be good to mention it for posterity. |
This is great! Can the new transaction format be used for verification of ZKR batches? If not, and the proofs need to be on the execution layer, EIP-4488 still has its place. Consider the most active ZKR today, dYdX: ~80% of costs are batch verification costs, and only ~20% is transaction data. Brendan from Polygon Zero estimates 4488 can drop their verification costs from to <250K gas, and Bobbin estimates Polygon Miden's STARK verification to drop from 5M to <1M gas. In the same thread, Liron from StarkWare notes that this will reduce dYdX gas costs to sub-100 gas (~500 gas today; only making transaction data cheaper it'll still be around ~400 gas). Besides that, EIP-4488 is definitely still simpler. All of this to say: I don't think EIP-4488 should be replaced; rather it should be implemented as soon as possible (IMO it's an emergency that justifies own fork between The Merge & Shanghai - and by this time I'd expect rollups to be more mature too), with the blob transactions rolled out later. EIP-4488 may continue to benefit ZK rollups even after there's dedicated space for transaction data. It'd also make sense to have EIP-4488 first, and then directly go to the more complex version that's more easily forward compatible with danksharding (though I don't understand the technical differences between the simpler version). |
@apolynya could you add this first |
|
shall we split the Merge All Core Devs and EIP All Core Devs so they can work in parallel with separate teams and decision makers? (sounds like the former Consensus and Execution split but with Consensus team bringing EL devs who work on the Merge) |
Yes, it can. Basically, you have to use a proof of equivalence to prove that some commitment in the ZKR's particular proof system commits to the same data as the blob KZG (verifying this does NOT require access to the actual blob, only the commitment and one more BLS point as a proof). Then you can do the rest of the ZKR proof as you would normally, knowing that the data the proof is operating over is available. |
|
Regarding the difference between the two data blob-carrying transaction proposals (EL-only vs EL + CL): if we update the engine API to contain these KZG commitments, we hide the data availability solution from the EL. This enables us to:
|
Sorry about that! I vaguely remember the number being ~1M gas, but I couldn't find a source for it, so I removed it (but forgot to remove "from"!) |
|
Closed in favor of #472 |
|
@timbeiko The instantaneous hashrate value of the ethash network is 1.00 PH/s. According to current GPU fees, the equivalent of this hashrate is 20-25 billion dollars. If the difficulty bomb and merge is delayed to January 2023 instead of June 2022, it will be able to pay off the installation cost for hundreds of thousands of people who started mining in the last 6 months. If you give the miners who are the workers of the Ethereum network +6 more months, hundreds of thousands of miners who invest all their savings in gpu mining can invest their money to stake with ETH 2.0. If you enable miners to hold assets that are twice the value of 10 billion dollars worth of ether currently staked in ETH 2.0, miners can turn their 20-25 billion dollars worth of electronic parts investment into cash and participate in the ETH 2.0 staking process. Otherwise, unfortunately, none of the electronic parts and miners that will turn into 20-25 billion dollars gpu garbage in the world will go bankrupt :( Can't we postpone the difficulty bomb to December 2022? Wouldn't it make the team look more unreliable if you postpone it one month by updating this file every month? As of January 1, 2023, the merge process has been completed and everyone in the community can work more comfortably, let's start as a perfect network with all the problems tested. You know that in every rush you do, you will destroy the entire ecosystem and that ethereum will be no different than a shitcoin, right? I am writing you a Turkish proverb. Search for the meaning and you will understand me :) "Hızlı giden atın boku seyrek düşer." |
The Ethereum Whitepaper was published in 2013 and states "Note that in the future, it is likely that Ethereum will switch to a proof-of-stake model for security, reducing the issuance requirement to somewhere between zero and 0.05X per year." The miners have had 9 years to save ETH and join staking. If they haven't done it by now they aren't going to do it... Edit: I should add that anyone that bought hardware in the last 6 months has had plenty of notice. |
Who knew Ethereum other than Vitalik in 2013? Are you kidding me? Are you talking about the roadmap that is delayed every year? ETH mining has been popular and profitable for the last 1 year. At other times he did not even cover the cost of electricity. Why are you treating miners like they are enemies? Or are you one of the gamers who couldn't save money to buy 3090 for the last 1 year :)) If ethereum is so popular today, it's not just because it's been perfectly designed as an infrastructure. Vitalik had 20-30 billion dollars capital but I don't know? If Ethereum is more populer today, it is thanks to the support of the hundreds of thousands of miners behind it. |
|
These agendas aren't the good place to have this discussion. If you'd like to advocate for pushing back the difficulty bomb more, please discuss it on ethereum-magicians.org. FWIW, I think the only viable reason to delay the bomb at this point is if the transition to proof of stake is not ready by the time it goes off. |
Meeting Info
Agenda
The text was updated successfully, but these errors were encountered: