ACD After Hours: ACDE #234 🌙

The limits of ‘rough consensus’

Good evening,

Tonight, I’m continuing in my train of thought from last week about why DeFi protocols are likely to rely on permissioned settings for security as they scale and mature.

Along these lines, it’s not just DeFi protocols that must increasingly rely on centralized coordination for security, but public blockchain protocols like Bitcoin and Ethereum, as well.

Let’s get into it.

Yours truly,

Christine D. Kim

P.S. As I mentioned earlier this week, I am joining my former manager, long-time mentor, and dear friend Noelle Acheson for a Substack live session about what life is like as an independent content creator.

We’ll be discussing the highs and lows of newsletter writing and our motivations for choosing this line of work. If you’re interested in joining us, here’s the livestream link. The session will begin at 11 am (ET).

---

🗒️ Call Minutes

First, a quick summary of the latest Ethereum developer call, All Core Developers Execution (ACDE) #234.

Bal-Devnet-3

• Yesterday, developers launched Bal-Devnet-3, a multi-client test network, to test the execution-layer (EL) code changes in the Glamsterdam upgrade.

• Ethereum Foundation (EF) Developer Operations Engineer Stefan Starflinger said there are issues in client implementations of Ethereum Improvement Proposal (EIP) 8037, State Creation Gas Cost Increase.

Epbs-Devnet-1

• Developers launched Epbs-Devnet-1 to test the consensus-layer (CL) code changes in the Glamsterdam upgrade a few days ago.

• EF Developer Operations Engineer Barnabas Busa reported several issues that are still under investigation.

Glamsterdam-Devnet-0

• Developers agreed to merge Bals-Devnet-3 and Epbs-Devnet-1 if the issues on these respective testnets can be resolved by next Monday.

• If not, developers discussed launching Bals-Devnet-4 with two additional EIPs that would allow developers to test higher block gas limits and a more complete version of EIP 8037, which would include variable cost per byte of state.

Requests for feedback

• EF Protocol Support Team Lead Nixo Rokish asked for feedback on a new definition for the EIP status known as “scheduled for inclusion” (SFI). SFI normally refers to an EIP being included in a devnet for testing. However, for reasons stated in her pull request (PR), a more nuanced description of this status may be needed.

• Consensys Lead Researcher Mikhail Kalinin asked for feedback on various updates to the Ethereum Engine API.

• Busa requested feedback on his proposal to upgrade the data serialization format on the EL without any consensus changes.

• Chase Wright, a developer at the EF, requested feedback on a new RPC endpoint that returns a node’s pruning policy, along with other information about the historical data the node is storing.

Hegota

• Rokish summarized the decision to consider for inclusion (CFI) EIP 8141, Frame Transactions, for the Hegota upgrade in the prior ACDE call.

• She added that now developers can propose non-headliner EIPs for consideration in the upgrade.

• The EF will give two to four weeks’ notice before closing the deadline for non-headliner EIP proposals.

• EF Researcher Antonio Sanso, who focuses on post-quantum security, expressed his support for enabling native account abstraction in Hegota. Other participants on the call supported Sanso’s sentiments.

• Nethermind Developer Ben Adams shared a proposal to enable account abstraction in Hegota through non-consensus-breaking code changes.

• Erigon Developer Giulio Rebuffo re-surfaced his proposal for “schemed transactions,” a simpler version of EIP 8141 that could be activated ahead of frame transactions.

• Rokish recommended a dedicated breakout call on account abstraction proposals for Hegota to resolve disagreements about the best path forward.

History Expiry

• Developers discussed the minimum amount of history required in Ethereum nodes to stay in sync with the protocol.

---

🌕 That’s all for my summary of ACDE #234. Continue reading for my insights on Ethereum development and governance. To read the rest of the newsletter, make sure you are signed up for a premium subscription:

🌓 Interested in being a featured sponsor of this newsletter? Learn more about sponsorship opportunities available for ACD After Hours:

🌑 I also run a research and advisory firm called Protocol Watch for businesses building on Bitcoin and Ethereum. Learn more about how I can help your business understand and stay ahead of protocol changes:

---

🔎 Insights

Last week, I explained why decentralized finance (DeFi) protocols need permissioned settings to scale safely.

The more value these protocols manage, the more value is at risk in the event of a hack or code bug.

Since no software is ever perfect, and all require continual maintenance to remain secure, mitigating the technical risks associated with DeFi requires relying on social governance and regulation to secure user funds when technology fails.

This week, I want to extend the argument further and elaborate on why public blockchain protocols like Ethereum and Bitcoin may also find themselves in a similar situation, needing stronger social governance and regulation to oversee protocol development and maintenance in the long run.

Institutionalization

On Monday, Jamie Dimon, the Chairman and CEO of the world’s largest bank, JPMorgan, stated in an open letter to its shareholders that “tokenization” is rapidly reshaping global finance. Dimon said:

“In addition, a whole new set of competitors is emerging based on blockchain, which includes stablecoins, smart contracts and other forms of tokenization. Our ongoing success will be based on our ability to wisely invest and move very quickly and nimbly.”