All Core Devs - Testing (ACDT) #36 | May 12 2025 #1528
Comments
|
Discourse Topic ID: 24076
Zoom Meeting: Reusing meeting 84251237513 for series 'all core devs - testing'.
Existing YouTube Stream Links (Reused):
Calendar Event: Reusing existing event for series (Link/ID not found in mapping).
Telegram Notification
|
marioevz
changed the title
|
we should get final comments on this so we can merge it and move ahead w/ blob scaling |
|
I'd like to bring up the topic of history expiry and what our plan is for rollout, releases, docs, testing |
|
EELS+EEST CFI'd EIPs analysis: https://notes.ethereum.org/@marioevz/fusaka-cfid-testing-analysis |
|
if there is time, we should discuss plans for introducing a per-transaction blob limit in fusaka there's some interest in this (as a single transaction with e.g. 48 blobs is quite unwieldly at the networking layer) and it would be good to align on:
|
PeerDAS Update for All Core Dev Testing (ACDT) #36HEADLINE: peerdas-devnet-7 is live and consensus-spec v1.5.0 was released!A. Client UpdatesCL Client Teams
EL Client Teams
B. Devnet / Testing Updates
C. Spec / EIP Discussion
D. Open Discussion
F. Schedule
|
|
Nethermind's support for Fusaka, ordered by inclusion preference/timeline
With remaining time spent on improving scalability (and possible EIPs that address blockers that may arise during investigation; if they require consensus coordination and are not just individual client implementation improvements) Additional EIPs inclusion should be addressed by maintaining an improved cadence on future forks. |
|
@benaadams PAY EIP is missing? 😢 (EIP-5920)
This sentence is somewhat confusing since "Other EIPs" is also a term used in Fusaka's Hardfork Meta: https://eips.ethereum.org/EIPS/eip-7607#other-eips |
Changed to Additional. One issue with historic fork timelines is the are so infrequent that they need to be jammed with EIPs as the next inclusion round is so far in future. Hopefully with principle of adopting a faster fork cadence; EIPs can be included more frequently and the pressure to stuff forks reduced (e.g. Fusaka 6 months after Pectra, and Glamasterdam perhaps 6 months after Fusaka, etc) |
|
I agree (and hope) we should/will get a faster fork schedule 😄 👍 Could you elaborate why Nethermind does "not want" (I'm assuming this is the signal given here) PAY in Fusaka? Especially with EIPs, which I think are "bigger"/more complex, which are on the inclusion list: RIP-7212? |
RIP-7212 has been implemented for a long time for all the ELs and most L2s already support it; so is just making available to L1 (and geth bringing back from one of the rollup-geth variants) Rest are mostly minor changes Appetite for Evm changes was rejected in this fork; and focus was determined to be improving ELs performance rather than specific EIPs |
|
(This comment is not supposed to be read in a frustrated/irritated tone, but I feel that PAY is relatively small-ish change compared to the huge benefits it unlocks for users/smart contract developers, which is also why I am pushing this rather hard lately 😅 ) I have relistened to last ACD, I think the EVM changes you mentioned here are rejected in the context of "removal of dynamic jumps" (for Fusaka). This rejection also seems to be part of the broader context of the "big"/broader EVM updates (like EOF) and specifically thus the removal of dynamic jumps. The two ModExp EIPs are EVM, as is RIP-7212. The PAY EIP is extremely helpful from a smart contract development perspective. I'll copy the current state of the motivation part from this PR (would also like feedback there).
I have also dedicated myself to ensure there are tests in |
|
I'd like to add that there is also the security concern with TSTORE/TLOAD by re-entering the calling contract via a CALL (with call stipend). Via the 2300 gas stipend this is definitely possible (100 base gas cost for CALL, 100 for TSTORE) to edit the transient storage. This gives headaches for just trying to send ether with these possible security problems which can be circumvented by this non-executing opcode. (I should also add this to the motivation of the EIP) If PAY gets rejected for Fusaka then I will propose it for the next one 😄 👍 |
Don't object to PAY as an EIP |
|
Reth team's priority list for Fusaka:
|
|
For EIP-7918, there have been improvements suggested during the discussion phase for both the if-clause and the return statement. I will here detail them. For the if clause, there is a suggestion by Ben to relate the minimum blob base fee to the cost of POINT_EVALUATION_PRECOMPILE_GAS. I think this can further improve the EIP. Here is a summary: https://notes.ethereum.org/@anderselowsson/EIP-7918E The change is very simple, switching out one constant for another and removing the amortization constant. For the return statement, there has been discussion on the design with on suggestions by Ansgar and one suggestion that does not change the current logic but requires accessing blobSchedule.Max. Here is a summary of those ideas: |
|
|
Erigon's ordered list of CFI'd EIPs:
Don't know enough about CL to opine on EIP-7917. |
All Core Devs - Testing (ACDT) #36, May 12 2025
Agenda
move to SFI status forinclude in Fusaka Devnet-0Other comments and resources
The zoom link will be sent to the facilitator via email
Facilitator emails: mario.vega@ethereum.org
🤖 config
The text was updated successfully, but these errors were encountered: