Bitcoin

Ethereum

<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/58ad63ea73af41518440c30c723f026c.png" /><ul><li><a href="https://app.superex.live/register?invitationCode&#61;MH74R" rel="noopener noreferrer nofollow">Click to register SuperEx</a></li><li><a href="https://superex.me/3YjX5oK" rel="noopener noreferrer nofollow">Click to download the SuperEx APP</a></li><li><a href="https://superex.me/cmc" rel="noopener noreferrer nofollow">Click to enter SuperEx CMC</a></li><li><a href="https://superex.me/academy" rel="noopener noreferrer nofollow">Click to enter SuperEx DAO Academy</a></li></ul>On January 4, 2024, Ethereum developers gathered on Zoom for the All Core Developers Execution (ACDE) Call #178. Hosted by Tim Beiko, the Ethereum Foundation’s Protocol Lead, the ACDE call is a bi-weekly series where developers discuss and coordinate changes to the Ethereum Execution Layer (EL). This week’s meeting was led by an anonymous Geth EL developer known as “Lightclient.” During the conference, developers confirmed the activation dates of the Cancun/Deneb (Dencun) upgrade on three public testnets and discussed the priorities for code changes (EIPs) in the Prague/Electra upgrade following Dencun.<h2 id="header-0">Dencun Update</h2>During the holiday period, there were no specific updates on the Dencun upgrade. Since the last ACDE call on December 21, client teams have been preparing new versions for the Goerli testnet. Due to delays caused by Prysm in the previous upgrade testing, Geth developer Marius van der Wijden requested the Prysm client team to provide updates on their progress for the upcoming Goerli hard fork. Prysm developer Terence Tsao confirmed that the Prysm team would be ready with a new version for the Goerli hard fork next week. However, it’s important to note that this version would be a “pre-release” and not recommended for use on the Ethereum mainnet. Following the Goerli hard fork, the Prysm team plans to release another version with additional changes and updates for users to run on the mainnet, testing on the Sepolia or Holesky testnets.While Tsao expressed satisfaction with the Goerli hard fork activation date set for January 17, he suggested waiting until after the Goerli hard fork to determine the activation dates for Sepolia and Holesky. Tim Beiko proposed the activation times for the three Ethereum public testnets — Goerli, Sepolia, and Holesky. The suggested fork activation times are as follows:<blockquote>Goerli: January 17, 2024 — Epoch 231680 — Timestamp 1705473120Sepolia: January 30, 2024 — Epoch 132608 — Timestamp 1706655072Holesky: February 7, 2024 — Epoch 29696 — Timestamp 1707305664</blockquote>Lightclient asked if other client teams, apart from Prysm, agreed with Beiko’s proposed Goerli hard fork activation time. All client teams participating in the call, including Geth, Lodestar, Lighthouse, Teku, and Besu, confirmed that they found the timing suitable and expected to release versions for Goerli node operators by the end of the next week. The Lighthouse client team noted that, as they were still testing certain network features of their client, the version they release might also be a pre-release, similar to Prysm.<h2 id="header-1">Dencun Timeline Divergence</h2>Next, Lightclient initiated a discussion on the proposed activation times for the Sepolia and Holesky testnets. A Prysm developer named “Potuz” suggested deferring the finalization of the upgrade dates for the last two testnets until confirmation of the mainnet. He stated, “We should try not to commit to dates right now because things might not go well with Goerli, and rolling back from there is a problem. Adding a new version with the right epoch and no changes is easy. Removing a version and fixing a mistake is a problem. That takes much longer than a couple of weeks.”Lightclient emphasized that between the activation of the Goerli hard fork and the proposed activation dates for Sepolia and Holesky, it might not necessarily require three weeks of turnaround time. Lightclient countered, saying that client teams would only need to release new versions one week after the Goerli hard fork, so it might not be necessary to remove the new version unless upgrade issues arise after January 24. Marius van der Wijden expressed that setting dates for Sepolia and Holesky wouldn’t hurt, as if issues arose on Goerli, developers could always change the dates.Barnabas Busa, DevOps engineer at the Ethereum Foundation, mentioned in the Zoom chat that, in his opinion, it was necessary to release new versions for Sepolia and Holesky upgrades only after confirming the normal functioning of the Goerli version. A Lighthouse developer named “Sean” agreed, suggesting setting a “tentative” date for the Sepolia hard fork but waiting until January 30 to assess Goerli’s progress.Potuz proposed adding an additional week of testing time between the Goerli and Sepolia hard fork activations, essentially analyzing for two weeks instead of three. He stated that adding a week of testing time would allow the client release to “soak” for a few days, and then the client teams would only need to cut new versions for the next testnet upgrade within a two-week span. “Two weeks are too close. That’s the issue I want to point out,” Potuz added. If the Goerli client release underwent sufficient analysis and testing, Potuz suggested that there might not be a need for a three-week turnaround between the Sepolia and Holesky hard fork activations.Potuz’s viewpoint sparked controversy. Ansgar Dietrichs from the Ethereum Foundation called the activation of the first public testnet for the upgrade developers’ “deadline,” and he didn’t see the need to extend the testing network upgrade intervals. However, Dietrichs also pointed out that desires to extend the testing network upgrade interval should be discussed more seriously among developers, especially in the context of the Dencun upgrade. Dietrichs stated, “If someone wants a more extended process, we should discuss that when there’s time, not right before the hard fork.”Lightclient agreed with Dietrichs, stating that if discussions had taken place back in October, developers might have been more lenient toward extending the Dencun testing network schedule. Lightclient said, “I think part of the reason is that we wanted to get the upgrade done in the fall of last year, so now we’re really working hard to achieve that goal, and I think our schedule should be more aggressive.”<h2 id="header-2">Adhering to the Aggressive Schedule</h2>Based on the developers’ perspectives shared during the conference call, Parithosh Jayanthi, a DevOps engineer at the Ethereum Foundation, suggested postponing the Sepolia hard fork upgrade by about a week and setting the date for the Sepolia hard fork on January 25th during the ACDE conference call, which follows the Goerli upgrade. Marius van der Wijden opposed relying entirely on ACDE calls to reconsider the activation dates for the testnet upgrades. He stated, “What I really want to avoid is having to have another All Core Devs call to confirm dates.” He added, “I hate having another All Core Devs call just to say, ‘Okay, Sepolia can start now.’ And now we have to wait two weeks before we can actually start implementing Sepolia.”To appease concerns, Guillaume Ballet, a Geth developer, proposed creating two tentative dates for the Sepolia hard fork. Developers could stick to one set of dates if the Goerli hard fork results were positive and use another set if the Goerli hard fork results were negative. However, Lightclient and Dietrichs opposed this idea because, before developers set a new schedule for the Sepolia hard fork, they must first assess the nature of errors and issues on Goerli.Meanwhile, an anonymous developer from the Ethereum Foundation testing team, known as “Danceratopz,” asked if developers would be willing to wait until the evaluation of the blob expiration issue on the Goerli test network before upgrading Sepolia. As background knowledge, blob expiration refers to the removal of blob data from the Ethereum state approximately two weeks later.During the conference call, Sean from Lighthouse and Justin Florentine from the Besu team expressed support for evaluating blob expiration on one of the three testnets before activating Dencun on the mainnet. Florentine emphasized that waiting for blob expiration on the testnet would help second-layer Rollup protocol teams and application developers better prepare for the Dencun upgrade. Although observing blob expiration on Goerli might not be necessary, it could be a reason to extend the testing period between Sepolia and Holesky to ensure that developers and second-layer teams can fully experience the blob lifecycle on Sepolia. However, other developers on the call did not explicitly agree with Sean’s suggestion.Lightclient asked developers during the call if they were willing to adhere to Beiko’s proposed schedule, which involves upgrading Sepolia on January 30th and Holesky one week later on February 7th. As there were no significant disagreements among developers, Lightclient stated that they would continue to follow the original schedule. In the Zoom chat, Potuz mentioned that he hoped to upgrade both Sepolia and Holesky testnets on February 7th, simultaneously, instead of advancing the former by one week. In a Discord message, Lightclient reiterated that the Dencun testnet schedule would remain unchanged for now.<h2 id="header-3">Prague/Electra</h2>Subsequently, developers discussed which EIPs (Ethereum Improvement Proposals) should be prioritized for the next upgrade after Dencun, known as Prague/Electra. Marius van der Wijden suggested focusing on completing the Merkle Tree upgrade for Prague/Electra rather than other EIPs. He highlighted two issues that need attention: first is the preparedness of the Merkle Tree. Developers planned to hold a dedicated ACDE conference call to delve into the implementation details of the Merkle Tree and the readiness for its hard fork upgrade.The second issue mentioned by van der Wijden is the ability to decouple upgrades on the Execution Layer (EL) from the Consensus Layer (CL). He believed that there are some “high-priority, super urgent” EIPs on CL that might need to be implemented faster than the Merkle Tree upgrade on EL. He suggested that the consensus layer teams discuss whether it’s necessary to hard fork for these changes, if they can be done without EL involvement, or if EL participation is required. He thought the Merkle Tree is a top priority and should be pursued while considering these two issues.However, in the Zoom chat, Ansgar Dietrichs, a researcher at the Ethereum Foundation, strongly opposed focusing the Prague/Electra upgrade on the Merkle Tree. He believed that considering the complexity of code changes required for implementing the Merkle Tree, this could likely lead to a delay in the upgrade until 2025. Lukasz Rozmej, a developer of the Nethermind client, also agreed with this viewpoint, stating that redesigning the state is very difficult and time-consuming, suggesting a focus on smaller hard forks while allocating appropriate resources to the Merkle Tree.The opinions of developers varied on whether Prague/Electra should prioritize the Merkle Tree or faster releases of smaller code changes. Ballet emphasized that, in his view, there is no such thing as a “small fork,” and the longer the wait, the harder it is to implement Ethereum state updates. Tomasz K. Stańczak, a developer of the Nethermind client, proposed taking an ambitious approach, leveraging the team’s capabilities to prove their ability to handle the biggest challenges within a year. He suggested that if the Merkle Tree eventually proves increasingly difficult for the team, it could be discussed again and removed from the upgrade. However, Lightclient expressed that it might be challenging for developers to continue discussions on which EIPs to include in Prague/Electra, especially the Merkle Tree, which is an 18 to 24-month project, once a set of EIPs is committed to. Andrew Ashikhmin, a developer of the Erigon client, suggested releasing smaller EIPs in Prague/Electra while concurrently developing the Merkle Tree for future upgrades. Ballet supported Stańczak’s proposal, emphasizing a focus on the Merkle Tree in Prague/Electra and considering its removal from the upgrade if significant issues arise during the implementation.Regarding the decoupling of EL and CL upgrades, Potuz mentioned that Prague/Electra has only one EIP proposal that requires changes only to CL. He believed a pure CL fork is unlikely to happen, at least not in the current and next years. However, Ansgar Dietrichs thought some EIPs are primarily CL-centric upgrades, requiring minimal changes to EL, allowing EL client teams to easily implement them. These EIPs still need coordination between EL and CL for a hard fork. Dietrichs subsequently added that, from the CL perspective, Data Availability Sampling (DAS) is the most crucial code change after EIP 4844. There was some disagreement between Dietrichs and Lightclient on whether DAS requires a hard fork.<h2 id="header-4">Attention to EOF and Other EIPs</h2>A developer using the pseudonym “Rodiazet,” working in the Ethereum Foundation’s Ipsilon team dedicated to Ethereum Virtual Machine (EVM) research, proposed several EIPs in addition to the Merkle Tree. These include EIP 5920 (PAY opcode) and EIP 2537 (precompiled BLS12–381 curve operations). While most developers agree to some extent on prioritizing the Merkle Tree after the Cancun/Deneb meeting, it remains unclear how much emphasis should be placed on the Merkle Tree in Prague/Electra compared to smaller EIPs that could be implemented more quickly and easily in 2024. Lightclient emphasized that developers do not need to make final decisions on the content of Prague/Electra in this week’s call and suggested continuing the discussion on the topic in the upcoming ACDE conference call.Subsequently, developers quickly moved on to discuss EIPs within the Prague/Electra theme that were not yet discussed in the call, including but not limited to the following EIPs:<blockquote>EIP-7002: Execution Layer can trigger exits.EIP-7549: Move committee index off-chain.EIP-3074: AUTH and AUTHCALL opcodes.EIP-6110: Provide on-chain validator deposits.EIP-6913: SETCODE instruction.EIP-7377: Migration transactions.EIP-4444: Binding historical data in the execution client.EIP-6404: SSZ transaction root.EIP-6465: SSZ extraction root.EIP-6466: SSZ receipt root.EIP-7212: Precompiled curve support for secp256r1.</blockquote>For a detailed overview of opinions on the mentioned EIPs, please refer to the full call recording on YouTube.<h2 id="header-5">Formalizing EIP 7587</h2>Finally, Ethereum Foundation researcher Carl Beekhuizen reintroduced the discussion about EIP 7587, which preserves a set of precompiled addresses for use by second-layer protocols. Beekhuizen inquired how developers could best formalize EIP 7587, making it an informational EIP to create specifications for future Ethereum governance processes. Ahmad Bitar, a developer from Nethermind, suggested incorporating the EIP into the EIP 1 document, outlining the guidelines for the EIP process. Lightclient proposed further discussing this topic on the Ethereum Magicians website and revisiting it in the next ACDE conference call as needed.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/3d7741d0d4ae47e2a6852805e473e052.png" />

Focus on the Ethereum Developers Conference：Ethereum Developer Meeting Recap

Table of Contents

SuperEx

Other articles published on Jan 10, 2024

Solana’s Rise Amidst Market Rally and Technical Analysis

Turkey Unveils Final Stages of Crypto Regulations, as CBDC Pilots Enter Second Phase

Will Hacking Disrupt Bitcoin ETF Approval? Here is the Latest Information!

X Confirms US SEC’s Official Account Was Hacked, No Insider Error Detected

XRP Fails to Overcome Bearish Momentum as Price Tumbles

BlockGuard and Pixelette Technologies forge a strategic DeFi partnership

Join our free newsletter for daily crypto updates!