eth_simulateV1 RPC supportMeeting Time: Thursday, February 12, 2026 at 14:00 UTC (90 minutes)
The meeting covered updates on the Glamsterdam devnet and Higota headliners, with discussions on client issues, node performance, and ongoing development work including EIP implementations and protocol changes. The team reviewed and approved various technical changes related to JSON RPC, EIPs, and BAL optimizations, while also addressing concerns about gas limits and receipt synchronization. The conversation ended with discussions about the implementation status of ETH 70 and 71 specifications, as well as the presentation of the Lucid Encrypted Mempool proposal and plans for future headliner selections.
The meeting focused on updates and progress for the Glamsterdam devnet and the Higota headliners. Stefan provided an update on the devnet, mentioning that most issues with clients have been resolved, and nodes are performing well from a consensus perspective. He encouraged clients to review Hive tests and shared details on ongoing spam transactions and node configurations. Andrew explained that Erigon is not yet fully ready for the devnet due to team members being on leave and ongoing work on the parallelized EVM code, with a goal to join the devnet within a week.
The team discussed changes to JSON RPC and introduced a max item limit in BAL as a DOS measure, which clients should review. They also considered two proposed changes to EIP 8024, with a consensus to reject the first change due to concerns about code size impact, while the second, simpler encoding change was approved. Dragan, who had previously supported the first change, expressed flexibility in either approach.
The team discussed priorities for DevNet 3, focusing on non-EIP and EIP-related items. For non-EIPs, they emphasized the need for standardized ETH simulate V1 RPC support across clients and BAL optimizations such as parallel execution, state root calculation, and batched state reads. On the EIP front, they agreed to include EIP-8037 (State Creation Gas Cost Increase) and EIP-7954 (Increase Maximum Contract Size) in DevNet 3, while postponing other EIPs like data repricings to DevNet 4 and beyond. The team also noted that the EF testing team requested a lean EIP scope for DevNet 3 due to their busy schedule with the repricing effort.
The team discussed the implementation of ETH 70 and data repricing in DevNet 3, with concerns raised about gas limits and receipt synchronization. They agreed that while ETH 70 could be included in DevNet 3, it should not be merged with DevNet 4 until there is network-wide adoption. The group decided to wait for protocol updates and client releases before increasing the gas limit, with Felix and others noting that the risk of hitting edge cases was overstated and could be managed. They also considered adding ETH 70 to the Glamsterdam rollout as a non-consensus-changing EIP to ensure network-wide support.
The team discussed the inclusion of ETH70 and ETH71 in the Glamsterdam event, with Felix explaining that these protocol changes follow a linear versioning system. Ansgar confirmed that ETH70 would be added to the Glamsterdam meta EIP, and Toni clarified that ETH71 is a separate EIP with its own specifications. The team agreed on the importance of having an EIP for protocol changes to provide context and rationale for the modifications. Ansgar raised a question about the sequencing of devnet releases, particularly regarding the readiness of ETH70 for mainnet 3 integration, which was left open for further confirmation.
The team discussed the implementation status of ETH 70 and block-level access lists across different clients. Felix explained that while ETH 70 is ready for Geth and Besu, Erigon does not need to implement it immediately as it is not affected by the sync issue it addresses. The team agreed that clients that do not support ETH 70 can still participate in DevNet 3, but decided to postpone decisions about ETH 71 implementation until later. They confirmed that BAL optimizations are the top priority, followed by EIPs 8037 and 7954 as candidates for DevNet 3.
The meeting focused on discussions about Ethereum development, specifically around the ETH 70 and ETH 71 specifications, and the presentation of the Lucid Encrypted Mempool proposal by Justin and Anders. The team discussed the technical details of the Lucid proposal, including its cross-layer properties and encryption mechanisms, with questions raised about decryption efficiency and potential attacks. Ansgar outlined the process for deciding on Execution Layer (EL) headliners, asking clients to write up their preferences within two weeks. Lightclient provided an update on changes to the approve functionality and shared a pull request for implementing frame transactions in the execution specs. Felix mentioned plans to refine the TX param opcode family. The team agreed to have a more substantial discussion on headliners in two weeks, with the possibility of an additional call if needed.
gsV!E^.0)gsV!E^.0)gsV!E^.0)YouTube Stream Links:
The team discussed updates on various devnets and the upcoming launch of Valid3, including status reports and technical issues. The group reviewed potential Ethereum London upgrade options, particularly focusing on frame transactions and encrypted mempools, with different clients expressing varying levels of support and concerns about complexity and implementation. After extensive discussion about frame transactions and their potential benefits versus challenges, the team decided to schedule a follow-up breakout call to further evaluate the proposals and make final decisions.
The team discussed updates on several devnets, including Blob-0, BaldNet-2, NFT devnet-10, and Perf-3. Barnabas reported on the current status and issues with these devnets, including client synchronization problems. The team also discussed the upcoming launch of Valid3, scheduled for next Wednesday, which will include increased maximum contract size and optional networking changes. Spencer provided an update on the 8037 tests, mentioning that they are being converted from YAML to Python and should be ready for release by the end of the following day. The team confirmed high confidence in launching Valid3 next week with a reduced scope using fixed values.
Sina provided an update on EraE, the successor file format to Era 1, which properly handles transition and post-merge history. The spec is stable enough for clients to review and implement, with Geth having a merged implementation and other clients working on pull requests. Mercy discussed reviewing state PRs on the JSON RLP system and sought feedback on the proper pathway for implementing future methods, including whether to use an EIP process. The group agreed on the value of standardizing the API, though there was discussion about the scope and utility of certain methods, particularly for transaction pool functionality. Finally, Ansgar updated the group that the original EIP 8105 proposal for Universal Enshrined Encrypted Mempool has been withdrawn, with its champions endorsing the Lucid proposal instead.
The team discussed various positions on potential Ethereum London (EL) headliners, with clients sharing their views on account abstraction, encrypted mempools, and frame transactions. Erigon expressed support for both account abstraction and encrypted mempools, suggesting Lucid could be delayed to align with the roadmap. The Besu team favored Lucid as the EL headliner, arguing it complements FOCIL better than frame transactions. Geth advocated for frame transactions, citing their potential to improve inclusion guarantees, but raised concerns about metadata leakage in encrypted mempools. Nethermind and Reth were not fully convinced by any of the proposals due to complexity concerns, with Nethermind leaning toward not choosing an EL headliner. The discussion highlighted ongoing debates about the benefits and drawbacks of each proposal, with some suggesting further discussion and prototyping before final decisions.
The team discussed potential options for the Ethereum London (EL) upgrade, focusing on whether to choose a headliner or proceed with multiple EIPs. While there was support for both frame transactions and encrypted mempools, concerns were raised about the readiness of encrypted mempools, with some arguing it was proposed too late and lacked sufficient thought. The team debated the definition of metadata leakage related to Lucid and frame transactions. No final decision was reached, but the group agreed to continue discussions offline, with a deadline set for the next call to lock in a decision.
The team discussed the potential selection of frame transactions as a headliner, with several participants expressing concerns about the proposal’s complexity and impact on dev tooling. Daniel from Besu indicated they could not make a commitment today and suggested a breakout call to allow more stakeholders to participate in the discussion. The group debated whether to proceed with an in-depth discussion of frame transactions immediately or schedule a separate breakout session, ultimately deciding to have a 30-minute Q&A session about the proposal. The discussion highlighted key concerns about frame transactions, including their complexity and potential impact on developer experience, while supporters argued for their benefits in addressing post-quantum security and privacy issues.
The team discussed the purpose and design of frame transactions, focusing on their potential to simplify transaction types while supporting post-quantum signatures and account abstraction. Felix and others argued that frame transactions offer a cleaner approach by reducing complexity and enabling future extensibility, though concerns were raised about security and potential new attack vectors due to the increased flexibility in signature verification. The group also debated the merits of composability over the current object-oriented transaction type model and addressed questions about signature size and implementation, with a consensus that precompiles could provide a secure and scalable solution for cryptographic operations.
The meeting focused on discussing frame transactions and the potential inclusion of various proposals in the Ethereum protocol. Key concerns were raised about the size of post-quantum signatures and the need for signature aggregation. The team debated whether frame transactions were necessary and if they should be implemented now or in the future. There was no consensus reached on whether to include frame transactions or the Lucid proposal in the protocol. The group decided to schedule a breakout call in two weeks to further discuss the future of transactions and make a final decision. The Lucid proposal will remain as a backup option for discussion if frame transactions are not ultimately chosen.
$x085fQK)$x085fQK)$x085fQK)YouTube Stream Links: