RollCall #3

[CarlBeek]

This is a call to discuss a frameworks to help aid with coordination between the various EVM-like L2s. The idea is to establish optional norms and standards for L2s to be able to extend the EVM and related tooling while limiting conflicts with the L1 EVM and preventing a proliferation of mutually incompatible standards among the L2s.

Meeting Info

• Wed Feb 14, 2024, 14:00-15:30 UTC
• Zoom link shared on RIP coordination in the RollCall channel in the EthR&D Discord which is bridged to the RollCall telegram channel shortly before the call.
• Previous call: RollCall #2 #925
• Recording: https://youtu.be/rwDpX08PiXQ

Agenda

• EIP-4844 readiness
• Ensure everyone is on the correct version of the trusted setup: Use the correct trusted_setup_4096.json consensus-specs#3583
• Breakouts Recap
• brief presentation on shared sequencing & pre-confirmations by @JustinDrake
• RIP-7614 Expose call stack to contracts overview
• New RIP editor: @ulerdogan

Further discussion

Feel free to add comments to this issue with further items of discussion

[timbeiko]

On ACDE today, we discussed L2 4844 readiness as a topic to discuss on the call.

[CarlBeek]

@timbeiko will add 4844 readiness to to the schedule, but specifically what @adietrichs was referring to is a breakout call on 4844 readiness & testing happening next Wednesday entirely focused on 4844.

[terencechain]

Probably worth shouting out: ethereum/consensus-specs#3583
In case anyone copied the wrong trusted setup

[CarlBeek]

Agreed, @terencechain. I will highlight it!

[leonardoalt]

Meeting info seems to have a typo, I assume date is Wed Jan 24?

[adietrichs]

Meeting info seems to have a typo, I assume date is Wed Jan 24?

This might be slightly confusing, but there are two separate calls:

• the next scheduled RollCall announced here, in 3 weeks
• the 4844 breakout call announced here, in 8min.

[leonardoalt]

So today is only the 4844 breakout call? Is the presentation on shared sequencing going to be today or in the next RollCall?

[adietrichs]

So today is only the 4844 breakout call? Is the presentation on shared sequencing going to be today or in the next RollCall?

Today is only 4844! Sorry for the confusion!

[canercidam]

Hi! Can we present our new RIP in this RollCall? https://ethereum-magicians.org/t/rip-expose-call-stack-to-contracts/18535
Thanks!

[CarlBeek]

The recording in case you missed it: https://youtu.be/rwDpX08PiXQ

[abcoathup]

Notes (from Eth R&D Discord)

thegaram33 - EIP-4844 readiness. zkSync reported they’ll roll out the feature on Sepolia this week and they’re soon ready for mainnet. Taiko has also started integration. Arbitrum has submitted the upgrade DAO proposal this week.

• With 4844 comes the blob transaction mempool (aka blobpool), which is completely separate from the mempool for non-blob transactions. In geth’s implementation, if you already have a pending transaction in the txpool, you cannot submit a transaction into the blobpool ("address already reserved"). koloz reported that this causes challenges since they use the same sender account to submit batches (blob transaction) and validity proofs (normal transaction).
• derek mentioned that they have ongoing discussions with RPC providers about beacon chain RPC availability and support for archive blob, used for node syncing.
• Reminder from @CarlBeek to use the correct version of the KZG trusted setup parameters (see link in the agenda).
• Summary and feedback on breakout calls. Main feedback is that they're useful but could be less frequent. The next one will be in 2 weeks (28 Feb) about shared sequencing, led by @JustinDrake.
• @canercidam | OpenZeppelin presented RIP-7614, a new precompile RIP, proposed by OpenZeppelin, Forta, and other contributors. The goal is to expose the call stack to contracts, so that dapps can use libraries and on-chain oracles / detection engines to reject malicious transactions.
• Some concerns raised: Are these mechanisms generally applicable, can they be circumvented? E.g. a freshly created contract could not have been flagged, and if it's created in tx1 and used in tx2 in the same block then we couldn't detect that it's a new contract. Other concerns are about added complexity and zk proving cost.
• New RIP editor: @ulerdogan.