Hello Hop DAO community,

This is Soheeb with Contrax, and I’m also a casual Hop DAO member (I’ve “hopped” on a few calls before ). Contrax is a new DeFi yield aggregator focused on making access to DeFi yield earning as easy as using a fintech app. We use account abstraction, gas coverage, routing into all strategies with USDC or ETH, and auto-compounding to enhance this experience.

We are currently on Arbitrum and have received the LTIPP grant. We integrated a few Hop vaults before we were even live, and today, almost 3/4 of our $400k in TVL comes from Hop vaults, with the most popular being the Hop hETH vault:

The vault can achieve such a high APY because it is on top of your current vault, which already has LTIPP rewards, with further rewards distributed by us.

Given that we are LTIPP partners and have already done the integration while bringing liquidity to your vaults, we would love to collaborate further. The exact ways to collaborate are open to discussion. At a high level, the goal would be to increase exposure of both protocols to the communities of the other and find ways to work together as we build out the product.

Looking forward to hearing from the community!

1 post - 1 participant

Read full topic

Unecessary selling pressure (214.33 HOP / day), useless incentive (who tf bridges to Nova in MAGIC…?).

7 posts - 4 participants

Read full topic

Fortunately, the snapshot vote to renew the Hop grants committee passed with 99.88% voting in favor therefore the next step is to commence the nomination thread.

The base responsibilities for each committee member will be to:

• Promote the grant program to attract grant applicants (i.e. hosting discord calls or x spaces).
• Share quarterly participation and voting metrics regarding grant applicants.

If you would like to nominate yourself to join the three-person grants committee please share:

• Background on yourself.

• Why are you a great candidate to join the Hop grants committee?

• Describe a successful grants program.

• Please share a short list of RFPs you would like for the grants program to target.

• Past experience with grants programs

• Reach within crypto community

14 posts - 9 participants

Read full topic

Hello, Hop!

Just wanted to introduce myself, I’m Spike, I work for Avantgarde finance. Before becoming blockchain maxi I used to be investment banker believe it or not!

I’ve been around since 2016, saw first DAO formation and witnessed all the fun with Ethereum classic (how is it still alive).

At Avantgarde I’m covering everything related to governance - voting, decision making, we are a large delegate in a number of protocols including Compound and Uniswap.

Big big big thanks to @francom for having a chat with me recently. It was very helpful in terms of getting better understand how community functions and what are the key pain points.

I’ll be joining the call every now and then to better understand where community is moving.

And of course great to meet everyone!

Cheers!

1 post - 1 participant

Read full topic

Hop Protocol & DAO Q1 ‘24

Welcome to our Quarterly report on the progress of Hop Protocol, the leading crypto bridge focused on enhancing blockchain modularity. In this update, we’ll highlight key advancements achieved over the past quarter, from technical upgrades to protocol and DAO growth.

Hop Protocol

In Q1 2024, Hop Protocol’s volume surpassed the $5 billion mark. Hop Protocol currently supports transfers between the following networks; Ethereum mainnet, polygon, gnosis, optimism, arbitrum one, arbitrum nova, base, linea, and polygon zkEVM.

The total volume this quarter was a 63.62% increase from last quarter with a total volume of $478 million vs $292 million Q4 2023. The total volume this quarter was higher than each quarter in 2023.

While Hop V1 has been around since 2021 and has successfully bridged over $5 billion, Hop V2 is around the corner as development inches closer to mainnet. Significant progress has been made with off-chain infrastructure as the front-end, explorer, etc. for V2 is complete after ongoing testing. Additionally, on-chain contract development is progressing well, with a focus on transaction simulations taking place in the testnet.

The bonder network continues to perform and is preparing for changes coming up with V2 and its push to decentralize the bonder role.

Hop supports liquidity pools in Ethereum mainnet, polygon, gnosis, optimism, arbitrum one, arbitrum nova, base, linea, and polygon zkEVM . The TVL of Hop’s liquidity program is roughly $28.4 million with 76.2% TVL being in ETH. USDC.e comes in second place with 6.3% of the TVL and DAI in third with 5.5%. The protocols with greatest liquidity mining TVL are Arbitrum One with 33.6%, Optimism with 26.2%, Base with 19.9%, and Polygon with 12.5%. The upgrade of the USDC bridge to CCTP has launched and this move supports cheaper and more efficient native USDC transactions and the upgrade to Hop V2.

The list below shows each source chain’s most frequented destination chains during Q1 ‘24

Ethereum > Polygon

Polygon > Ethereum and Base

Optimism > Base

Arbitrum One > Ethereum and Base

Base > Ethereum

Linea > Optimism, Arbitrum, and Base

The lifetime transfer count is roughly 3.7 million and 74.10% of transfers have been in ETH. USDC is second with around 13.64% of transfers. The average weekly transfer counts this quarter was 29k transfers.

The current circulating Hop token supply is around 75 million which represents around 7.5% of the total token supply.

The table below demonstrates that the Hop token’s current liquidity is around $682,711 in various exchanges and chains.

Hop DAO

The DAO has approximately 1.47k governance participants and 78 delegates that have been actively participating recently according to karmahq.xyz/dao/delegates/hop.

During this quarter the DAO has had five passing Snapshot votes while Tally has had three passing votes and one failed vote. The failed vote was [HIP-39] Community Multisig Refill (4) which failed due to lack of quorum.

This quarter the DAO passed the following proposals: Treasury Diversification for Ongoing DAO Expenses (HIP44), Treasury Diversification and Protocol Owned Liquidity, Delegate Incentivization Trial (Third Cycle), Community Moderator Role and Team Compensation, and finally, Head of DAO Ops Role and Election.

There are three main proposals that are currently live in the forum: Grants Committee Renewal and Redesign, Protocol Financial Stability Part 1, and Hop Single Sided Liquidity.

Topics for future discussion: Migrating to L2 for Voting and Token Redelegation.

This report solely represents the views and research of the current Head of DAO Operations which could be subject to errors. Nothing in this report includes financial advice.

1 post - 1 participant

Read full topic

Summary

Hop DAO should LP 25,000,000 HOP as single sided liquidity in the HOP/ETH 0.30% Univ3 pool on Ethereum. This will increase HOP liquidity and market depth while providing a natural source of diversification for the DAO.

Motivation

As Hop prepares for the launch of v2 and hopefully the ensuing growth of the protocol, now is the time to improve HOP liquidity and position the DAO for increased demand. Hop has not engaged any market makers or incentivized liquidity for HOP to date. I believe that this is the correct approach, however HOP liquidity is extremely low. This makes it difficult to enter positions and leads to significant price volatility. As of this past week, ~$500k of total buy orders would basically exhaust the entire Univ3 pool. This is a relatively small amount of liquidity and could prove problematic if Hop v2 significantly increases demand. I understand that some might say, “wow token shortage good, price go up big”, but that approach is not sustainable. The current TVL of the HOP pool is approximately $280k. This proposal would increase the TVL by $1.2m which would put HOP in line with similar assets. Much of the TVL will be well above the current spot price of HOP which should limit potential adverse effects. As a community, I believe that having well aligned HOP holders is in our long-term best interest. Increasing HOP liquidity will create avenues for more participants to get on board in a reasonable manner.

Recent efforts to increase HOP liquidity are positive but still leave a ways to go. Single sided liquidity lets us LP meaningful amounts of HOP solely to the “upside” of the price range. As the price of HOP increases, the DAO is gently selling HOP for ETH based on market demand. If the price of HOP decreases once this position is in range, there will be significantly more market depth to absorb selling. From my perspective, the biggest downside of this proposal is that it effectively creates resting sell orders for HOP that will need to be filled for the price to increase in the pool. I have tried to size the proposal appropriately to increase liquidity while not overburdening the market for HOP. The impact of additional HOP appears to be very reasonable. The next section explains the mechanics and practical implications for the position.

Mechanics of Execution

I will caveat this by saying that it is difficult to model Univ3 positions and that this should be generally accurate but may be slightly off – please keep in mind that everything is priced in ETH terms so that is an additional variable that makes precision challenging. If there is a great tool for modeling Univ3 positions, please let me know because this was all done manually.

This proposal would take 25,000,000 HOP held by the DAO and LP in a range from just above the current spot price to tick #6400 which equates to roughly a $6 HOP price. To provide context for the additional liquidity, this will add ~$250k of depth between the current spot price and $0.10 HOP. As the price of HOP increases, the dollar value of the depth increases as well (e.g. there is about 2x as much additional depth between $0.10 and $0.20, etc.). The current liquidity is fairly concentrated near the spot price; this proposal would greatly increase the longer tail of liquidity throughout this range. For the purpose of illustration, if the entire range were to be filled it would yield about $31m in ETH for the DAO. This proposal will not provide any liquidity for people to “dump” on at the current prices and only comes into range if the price of HOP increases. If we determine that the liquidity is having negative impacts on HOP or unintended consequences, we can pull the liquidity at any time (I assume this would require a subsequent vote).

I believe that this proposal is a positive step towards creating a more robust environment for HOP ahead of v2 while also providing a gentle means of diversification for the DAO. Please let me know if you have any comments, suggestions or concerns.

Voting Options

• LP 25,000,000 HOP in specified range
• No action
• Abstain

12 posts - 6 participants

Read full topic

Useful Links

• [RFC] Treasury Diversification & Protocol Owned Liquidity (multichain HOP/ETH LPs)
• [RFC] V2 Open questions (financial perspective)
• [RFC] - Hop Treasury Management Framework

Summary

• This RFC outlines the importance of prioritizing financial stability for HopDAO and introduces the first part of a three-part proposal aimed at effective treasury management.
• The core of the Framework emphasizes the importance of a structured approach to managing the treasury to guarantee resilience and promote sustainable growth. This includes transparent operations, a clear financial plan, and strategies to uphold token stability.
• Prior to the snapshot, active engagement with the community is essential to gather feedback and refine the proposed framework

Intro

After discussing with delegates and reviewing poll results, along with understanding the DAO’s potential from a developer’s perspective, it’s clear that prioritizing Hop Financial Stability is crucial. Managing the treasury involves many aspects, from basic budgeting to dealing with complex issues like protocol-owned liquidity and spreading out investments.

Our plan is straightforward:

First, we’ll identify the main problems and decide what’s most important. We’ll use feedback from the community and look at the DAO’s current financial situation, especially with the upcoming V2 launch. This will help us figure out where to focus our efforts.

Next, we’ll create a simple plan for managing the treasury. We’ll outline basic rules and goals for how to handle our money. This will give us a clear path forward and make sure everyone knows what to do. This is the initial part and it will be covered in this post.

Then, we’ll look at how to manage the liquidity of our token. We’ll talk about why it’s important and come up with ideas to keep our token stable and attractive to investors. This will be the second part of our RFC.

Lastly, we’ll set up a plan for how to actually do all this. We’ll decide who’s in charge, what goals we want to meet, and how we’ll measure our success. This will be like a roadmap for the DAO to follow and it will be the third and the last part of our RFC.

With this plan, we’ll be ready to manage our treasury effectively and make sure Hop stays strong and successful.

Let’s work together to make it happen!

Problem Statement

Improving our financial stability is essential for the DAO’s success, just like it is for any other business. We need to consider all aspects of our finances, but we also need to prioritize what’s most important.

The Hop Protocol makes a lot of money, but not all of it goes into our HopDAO Treasury. We have a great community, and it’s important to listen to them to understand how they see the financial situation and what’s important to them when making investment decisions.

Recently, we did a survey to find out what the community thinks we should focus on. From the feedback we received from delegates, the survey, and my own experience, here are the things that HopDAO needs:

a) Hop requires a systematic and well-thought-out approach to managing its treasury to ensure the DAO’s financial resilience and create a platform for sustainable growth.

b) To achieve this, we need a Treasury Management Framework. This framework should include:

• a transparent operational model with actions, accountable persons, and governance structure,
• a well-defined financial plan that aims to establish a sustainable runway, liquidity targets, supplemented by proactive budgeting, and regular reporting,
• a HOP token liquidity management plan to ensure Protocol’s token stability and attractiveness for current and future investors.

These priorities form the foundation for the Treasury Management Framework that I’m about to introduce.

Updated Hop Treasury Management Framework

We have laid out the basic structure needed for a successful treasury management plan here.

Now, let’s refine and tailor it to fit the priorities of our DAO. As mentioned earlier, the key is to focus on setting clear principles and objectives from the start. Once we have this solid foundation, our governance process will become transparent and flexible enough to adjust to changes in the market and our financial needs over time.

TMF Initial Components

The structure of the content within the Treasury Management Framework is designed to provide a comprehensive approach to treasury management for Hop. It encompasses the following key components:

1. Treasury Management Principles

Following these principles helps us manage our DAO’s finances well. We focus on being open, inclusive, and responsible. These principles help us handle our funds in a decentralized way, aiming for transparency, reducing risks, and aligning with our goals.

• Transparency: We believe in open communication and sharing relevant information about the DAO’s finances. Everyone should have access to know how funds are allocated and investments are made. Transparency builds trust and ensures that everyone is on the same page. We commit to monthly financial reporting, accessible via the Hop Community Forum.
• Simplicity: “Simplicity is the ultimate sophistication”. We believe in simplicity over complexity. Treasury management doesn’t have to be convoluted and confusing. We aim to streamline our processes, making them accessible and easy to understand for everyone involved. By keeping it simple, we reduce risks and avoid unnecessary complications.
• Diversification: We encourage spreading the risk by diversifying our investments. Instead of relying on HOP, we explore various opportunities across stablecoins, ETH, and WBTC, deployed across multiple DeFi protocols and strategies. Diversification keeps us balanced and safeguards against unexpected exploits.
• Accountability and Decentralisation: We recognize the importance of having a dedicated individual or team responsible for driving decisions forward. This ensures that inertia is overcome and progress is made. While we value efficiency, we also advocate for a democratic process where the DAO collectively votes on fundamental guidelines. This strikes a balance between swift action and maintaining oversight to prevent reckless trading practices.
• Risk Management: Our foremost priority is safeguarding our financial resources. We meticulously assess various risk metrics, from market-related risks to strategy-specific vulnerabilities, ensuring our treasury remains robust and sustainable.
• Focus: Our treasury management decisions should align with our DAO’s objectives, focusing on ensuring the long-term sustainability of the DAO and it’s token. By keeping our objectives in sight, we make purposeful and impactful decisions.

2. Treasury Management Objectives

As framed in the problem statement section, the goal of the Treasury Management is to build:

“…a systematic and well-thought-out approach […] to ensure the DAO’s financial resilience and create a platform for sustainable growth.”

I.e., translating this into 5 key objectives that inform our work for the framework:

1. Meeting Operational Needs: One of the primary objectives of the DAO’s treasury management is to ensure that a DAO has sufficient cash and liquidity to meet its financial obligations and fund its day-to-day operations. This involves optimizing cash flows, managing working capital effectively, and maintaining appropriate levels of liquidity to mitigate the risk of cash shortages. The rest of the longer-term oriented capital, e.g., not needed within the next 24-36 months for operational needs, should be used to take advantage of investment opportunities with different risk profiles.
2. Provide a sustainable liquidity for HopDAO token: Liquidity is a foundational element for the success and stability of any token-based project. It ensures that new investors can seamlessly enter the market while providing an exit path for those looking to divest. HopDAO Treasury should be able to identify mid-term liquidity improvement strategies, and propose long-term solutions to enhance protocol liquidity.
3. Data-Driven Decision Making: By leveraging data, we aim to optimize investment choices, risk management strategies, and operational efficiency. This principle ensures that our DeFi strategies are grounded in solid analysis of on-chain and off-chain data, as well as utilising state-of-art statistical concepts, enhancing the effectiveness of our treasury management.
4. Overseeing Risks, related to Treasury: Treasury management aims to identify, assess, and manage various financial risks faced by a DAO. This includes protocol risk, liquidity risk, credit risk, market risk, and operational risk. The objective is to implement strategies and/or hedging techniques to minimize the impact of these risks on the DAO’s financial performance.
5. Regulatory Considerations: We stay updated on DeFi regulations to adapt our strategies and partnerships accordingly. This helps us avoid legal risks and adjust our investments as needed. We stay resilient and flexible amid regulatory changes.

Once the DAO approves these initial components, we can move forward with implementing and executing the framework.

TMF Top Priority Components Overview and Next Steps

Now, we’re at a critical point where we need to discuss the practical execution of our objectives. The proposal will be divided into two main areas: Protocol Liquidity Management and Treasury Management execution. Here’s what you can expect in Part 2 and Part 3:

Part 2 - Protocol Owned Liquidity Management Overview:

1. POL Research: Every decision made by the DAO should be rational and data-driven. I aim to provide the Hop community with an overview of common practices used to manage protocol liquidity. The goal is to assess various protocols and strategies, ranking them based on our specific needs.
2. Protocol Liquidity Management Framework: In this section, I’ll introduce the principles I plan to use to achieve deep liquidity and price stability.

Part 3 - Treasury Management Mandate:

This final part of the RFC will be structured as a mandate, which will be submitted to the snapshot after gathering all necessary feedback from the community and delegates. Here are the topics we will discuss:

1. Treasury Management Operational Model & Governance: This section outlines the central components of the framework, aligning all stakeholders and ensuring clarity in the treasury management process. It details procedures, policies, and tools for efficient cash flow management, risk mitigation, and decision-making within the DAO.
2. Financial Management and Budgeting: Emphasizing cash flow forecasting and liquidity management, this section explores strategies to ensure adequate liquidity for operational needs. It aligns budgeting practices with the DAO’s financial goals.
3. Treasury Asset Allocation: Efficient allocation of treasury funds is vital for maximizing returns while managing risk. This section covers the selection and allocation process for deploying the DAO’s financial resources, including diversification, rebalancing, and investment strategies.
4. Reporting: Transparency is essential for the success of a DAO. This section focuses on reporting tools and mechanisms to ensure full transparency in treasury management, emphasizing timely and accurate reporting for stakeholders.
5. KPIs, Deliverables, and Terms: This section outlines the specific terms, expectations, timeline, and compensation associated with the mandate.

Conclusion

By implementing the Treasury Management Framework, HopDAO can establish a robust and sustainable approach to managing its financial resources. This framework guides every aspect of treasury management, from principles to governance, empowering DAOs to make informed decisions and achieve their financial goals while maintaining transparency and mitigating risks.

I’m thrilled to be part of this journey and excited to contribute to HopDAO’s Treasury success. Your feedback on this proposal is invaluable, and I welcome any thoughts or suggestions you may have. Feel free to reach out to me directly through DMs for a more detailed conversation. Let’s work together to shape the future of HopDAO!

2 posts - 2 participants

Read full topic

Hey Hop DAO,

Since [HIP-46] Renewal of Hop Delegate Incentivization Trial (Third Cycle) passed, it’s time to create a new Delegate Compensation Reporting Thread for this period (October 11, 2023 – March 27, 2024). The last delegate compensation reporting period ended October 10, 2023, therefore anything from then up until March 27,2024 falls within this reporting period.

To make matters easier for delegates who are eligible for incentives, the Head of DAO Operations will verify the voting and communication requirements for each delegate but each delegate is expected to share in this thread their voting and communication ratio, their lowest HOP delegated during the period, and finally their incentive rewards amount for the period based on the calculation. Please use the calculation from the recent snapshot vote to renew the delegate incentivization program. Please share your communication publicly in each proposal’s governance forum thread or create your own voting and communication thread for the Head of DAO Operations to verify. Please include your Ethereum address as well.

Delegates can utilize this Dune Querry 12 5 to find the lowest level of Hop within the time period.

Delegates can also use this graph 9 5 to determine their compensation by using their lowest Hop for the specified period.

Delegates can go ahead and report below in this thread.

Below are the snapshot votes and Tally votes since the last reporting period.

Snapshot Votes Since Last Delegate Reporting Thread

• [Temperature Check] Treasury Diversification & Protocol Owned Liquidity (multichain HOP/ETH LPs)
• [HIP-41] Incentivize Hop AMMs on Supported and Upcoming Chains
• Hop Community Moderator Compensation
• [HIP-43] Proposal to create Head of DAO Operations
• [HIP-44] Treasury Diversification for Ongoing DAO Expenses
• [HIP-45] Head of DAO Operations Election
• [HIP-46] Renewal of Hop Delegate Incentivization Trial (Third Cycle)

Tally Votes Since Last Delegate Reporting Thread (August, September, October)

• [HIP-39] Community Multisig Refill (4) on Feb 5th, 2024 was defeated
• [HIP-40] Treasury Diversification & Protocol Owned Liquidity on Feb 5th 2024 passed
• [HIP-39] Community Multisig Refill (5) on Feb 15th, 2024 passed
• [HIP-44] Treasury Diversification for Ongoing DAO Expenses on Mar 4th 2024 passed

For example;
francom.eth
Voting: 11/11
Communication: 9/9 (HIP 40 & HIP 44 had to be voted on in snapshot and tally but you only have to communicate rationale once for each of these proposals).

lowest Hop during period: x
incentive rewards during this period: x

20 posts - 7 participants

Read full topic

Launch Hop on NEO X (NEO EVM) Mainnet

Point of Contact: Tony Sun

Proposal summary

We propose to Hop community to deploy Hop Bridge protocol to the NEO Ethereum Virtual Machine rollup known as “NEO X” on behalf of the community.

We believe this is the right moment for Hop to deploy on NEO X, for several major reasons:

· NEO X is a new zk-rollup that provides Ethereum Virtual Machine (EVM) equivalence (opcode-level compatibility) for a transparent user experience and existing NEO ecosystem and tooling compatibility. Additionally, speed of fraud proofs allows for near instant native bridging of funds bridge (rather than waiting seven days).

· An Ethereum L2 scalability solution utilizing cryptographic zero-knowledge technology to provide validation and fast finality of off-chain transaction computations.

· A new set of tools and technologies were created and engineered and are contained in this organization, to address the required recreation of all EVM opcodes for transparent deployment and transactions with existing Ethereum smart contracts.

· NEO X is aligned with NEO and its values.

· Hop is already deployed on POS with good success

· Hop gaining market-share through early mover advantage

NEO X main net will launch in May to June. Our aim is to have Hop as one of our early stage bridge partners, as we view Hop as a highly crucial product for users to bridge their assets across various chains.

About NEO X

Neo was founded 2014 and has grown into a first-class smart contract platform. NEO is one of most feature-complete L1 blockchain platforms for building decentralized applications.

Neo X is an EVM-compatible sidechain incorporating Neo’s distinctive dBFT consensus mechanism. Serving as a bridge between Neo N3 and the widely adopted EVM network, we expect Neo X to significantly expand the Neo ecosystem and provide developers with broader pathways for innovation.

In this pre-alpha version of the TestNet, we have aligned the Engine and dBFT interfaces. The main features are as follows:

dBFT consensus engine support has been added to Ethereum nodes. Geth Ethereum node implementation is taken as a basis.

A set of pre-configured stand by validators act as dBFT consensus nodes. All the advantages, features and mechanics of dBFT consensus are precisely preserved.

Ethereum P2P protocol is extended with dBFT-specific consensus messages.

Invasive existing Ethereum block structure modifications are avoided as much as possible to stay compatible with existing Ethereum ecosystem tools. MixHash block field is reused to store NextConsensus information and Nonce field is reused to store dBFT Primary index.

Multisignature scheme used in Neo N3 is adopted to the existing Ethereum block structure, so that it’s possible for Neo X consensus nodes to add M out of N signature to the block and properly verify signature correctness. Extra block field is reused for this purpose.

Secp256k1 signatures are used for block signing.

The multi-node dBFT consensus mechanism, enveloped transactions, and a seamless native bridge connecting Neo X with Neo N3 will be introduced in subsequent versions.

*Please be aware that this pre-alpha version of NeoX is in the active development phase, meaning that ALL data will be cleared in future updates.

Motivation

There’s significant value in Hop being available on an EVM. Deploying early on NEO X helps solidify Hop’s place as a leading DEX and a thought leader.

Additionally, given the community and user uptake Hop has seen on NEO X PoS, it’s only natural to make its deployment on NEO X a priority.

Partner Details

Neo Global Development

This proposal is being made by Tony Sun, an employee of Neo Global Development. Neo Global Development is a legal entity focused on the ecosystem growth and maintenance of the suite of NEO.

Partner Legal

The legal entity that is supporting this proposal is Neo Global Development Ltd, a British Virgin Islands corporation known as “NGD”.

Delegate Sponsor

There is no delegate co-authoring or sponsoring this proposal. Instead, this is a proposal submitted by Tony Sun of NGD to support the growth of NEO as part of the overall NEO community.

Conflict of Interest Declaration

There are no existing financial or contractual relationships between NGD and any of Sushiswap’s legal entities, including Sushiswap, SUSHI tokens, nor investments of Sushiswap…

What potential risks are there for this project’s success? How could they be mitigated?

Deploying on NEO X should pose minimal risks, relative to deploying on alternate blockchains. As an Ethereum Layer Two, it uses Zero Knowledge proofs to inherit NEO’s core safety, while allowing developers to easily deploy existing EVM codebases. The bridge has been disintermediated, and Sushiswap can expect reputable Oracle providers to be available as data providers from Day One. NEO X’s EVM testnet has been running for the past two months. Additionally, the deployment has been audited multiple times, by auditors including Red4Sec. Welcome to NEO

1 post - 1 participant

Read full topic

This RFC is made with the same goals as the original [RFC] Treasury Diversification. Updated parameters are below.

Summary

Sell 25% of Hop DAO’s ARB holdings (209,251 ARB) for USDC. This should raise approximately $440k for Hop DAO at current prices (~$2.10).

Motivation

Hop DAO will need stablecoins to cover ongoing expenses. The current and future ongoing expenses that currently exist are:

• [HIP-37] Authereum Labs Engagement Adjustment
• Hop Community Moderator Compensation

Execution

The onchain execution of the proposal will send a message through the Arbitrum messenger to trigger a transfer of the ARB currently in the Hop Treasury alias address to the Community Multisig. The Community Multisig can then complete the sale in a series of transactions.

Voting Options

• Sell 25% of Hop DAO’s ARB holdings for USDC
• No action
• Abstain

11 posts - 9 participants

Read full topic

The DAO has voted to create a Head of DAO Ops role with 2.5 million HOP tokens voting in favor. The Head of DAO Operations will connect different aspects of the DAO and make sure there is cross-collaboration and communication to propagate personal responsibilities for the DAO’s subgroups. To qualify for this role, one must have been materially active in the DAO for at least 6-months, having attended community calls, posted on the forum, used the hop bridge, and held HOP).

If you would like to take on this role, please share your nomination below with a short excerpt on who you are and why you would make a great Head of DAO Ops.

For the Head of DAO Ops discussion thread

For the Snapshot Vote

6 posts - 4 participants

Read full topic

References

Original Delegate Incentivisation Trial 18

Delegate Amendment 11

Renewal of hop delegate incentivization trial

Simple Summary

Over the past year, Hop DAO trialed delegate compensation to participate in Hop DAO Governance actively. This is a proposal to extend the Hop Delegate Incentivization Program for a period of twelve months.

Motivation

Through the delegate incentivisation trial over the past year, delegates have been incentivised to actively participate in Hop DAO Governance by taking part in discussions on the forum, voting on proposals and ensuring to share their rationale for voting a particular way. This program has created a healthy culture of governance-related engagement in the Hop DAO.

Renewing this Hop Delegate Incentivization trial will ensure that the quality of Hop DAO does not decline.

This Incentivisation Program will retain the delegate talent that the Hop DAO has attracted; its continued existence will allow future delegates to join the Hop DAO and allocate resources to improving the Hop Protocol.

How did the program work?

Delegates are required to vote on proposals and communicate their rationale for voting in their delegate thread on the Hop DAO Forum.

Under the current Delegate Compensation Program, delegates are compensated using a formula where delegate incentives increase with the amount of HOP delegated, but in a decreasing fashion. This means that a small delegate will receive a greater incentive per voting weight than a large delegate, but a larger delegate will receive more.

Delegates utilise this Dune Querry 3 to ascertain their lowest level of Hop for that month and use this visualization graph 1 to ascertain the incentives they are due according to their lowest amount of Hop for that month.

Finally, delegates would self-report under a thread dedicated to reporting delegate eligibility each month. The following information would be required of a delegate.

Vote participation percent = (Number of proposals voted upon ÷ all proposals) * 100

Communication participation percentage = Number of proposals referenced with voting position and reasoning for that position ÷ all proposals ) * 100

Lowest Amount of Hop for the period

Incentives to be paid out.

Previous Changes to the Program

Sequel to the feedback provided in the previous proposal, the following changes were implemented in the previous renewal proposal.
There shall be a new formula used to calculate incentives.
Where:
I = Incentives to be received
h = lowest level of HOP delegated that month
M = Multiplier based on consecutive participation periods

To calculate the multiplier (M), we can use the following formula:

M = 1 + (0.1 * P)

Where:
P = Number of consecutive completed 6-month participation periods (capped at a certain value, e.g., 5)

This multiplier starts at 1 for new delegates and increases by 0.1 for each consecutive completed 6-month participation period, capped at a certain value (e.g., 1.5 after five periods).

The Participation rate would be removed; therefore, new delegates who reach the 90,000 threshold could join as delegates at any time.

The incentive formula would be amended to include a Multiplier based on consecutive participation periods.

The primary import of these changes is that new delegates can join Hop Governance at any time, while old delegates are incentivized to continue participating.

There is no opt-in or opt-out mechanism. Delegates will have to self-report to receive compensation.

Specification

This proposal requests for the Hop Delegate Incentivization Program to be renewed for another twelve months; the program will retain all the guidelines and procedures laid down by the original proposal 18, its subsequent amendment 11 and amendment in previous renewal.

Next Steps.

If this proposal passes, the Hop DAO Delegate Incentivization Program will continue for another twelve months.

25 posts - 10 participants

Read full topic

Related discussion(s)

• [RFC] - Hop Treasury Management Framework - #12 by francom
• [RFC] Treasury Diversification & Protocol Owned Liquidity (multichain HOP/ETH LPs)
• [RFC] Head of DAO Governance and Operations Role

Rationale

We have a V2 launch coming up soon, and we need to ensure that we have all financial aspects covered. The market could be in our favor, but as we discussed before, we should be proactive. Here is my list of open questions for the upcoming V2 launch from both financial, Ops, and Growth perspectives. Feel free to add your questions; the aim is to keep this as a record of things we should consider.

Open questions:

• Protocol-Owned-Liquidity
  • Single-sided vs. bonding vs. PALM vs. Tokemak V2 etc.
• HOP Valuation
  • What would be the parameters of the floor price, etc.? ( For valuation I would suggest a competitors analysis combined with a secondary market sentiment analysis)
• Treasury
  • Circulation, payments, principles, diversification (Will create another Temp Check following this post to gather feedback)
• Risk management
  • Liquidity risk, eg. stablecoin reserves, HOP volatility etc.
  • Market risk
  • Governance risks, eg. Governance attacks
• Growth
  • Do we plan to have grant programs or any other incentives?
• Token Utility
  • How do we ensure we have enough intrinsic value to hold and use HOP?
  • What would be the tokenomics?

Next Steps

1. Define a rough timeline for the V2 launch so we can prepare accordingly
2. POL research: @fourpoops is rocking with his proposal. I would love to double down on it and create a comparison between different options as part of a larger Risk Management initiative (plan to post it this week)
3. I strongly encourage the community to start discussions on Growth and Token Utility
4. Treasury and risk management setup
5. Fast Head of DAO nomination. I think this volume of work shouldn’t be on the devs’ shoulders but rather on one person who can handle these aspects

I have created a working file where I am already preparing the research on all topics covered here. Feel free to comment and participate!

1 post - 1 participant

Read full topic

DAOs can be chaotic due to their unstructured nature but there are DAO service providers who create governance frameworks and push along the day-to-day operations for the benefit of the respective DAOs. Hop DAO has had help from several groups since its inception. GFX Labs was the first to help with DAO operations given their extensive experience in governance and ops. When they exited the DAO, StableLab took on the role of helping the DAO with operations and governance initiatives. Unfortunately, StableLab has decided to refocus their resources elsewhere during this prolonged bear market and have recently exited the DAO.

While it is hard during this extensive bear market to retain talent…. the show must go on. With that in mind, I propose creating a new role titled Head of DAO Operations where an individual is responsible for the day-to-day operations acting as a liaison between the different participants and subgroups of the DAO such as; core developer team, grants committee, ambassadors, delegates, multisig signers and more.

The Head of DAO Operations is not to be construed as a central figure of authority but more like the glue that connects different aspects of the DAO and makes sure there is cross collaboration and communication and helps propagate personal responsibilities for each of the DAOs subgroups. It is imperative for the Head of DAO ops to be fully aligned. Therefore, to qualify for the role one must have been materially active in the DAO for at least 6-months, having attended community calls, posted on the forum, used the hop bridge, held hop).

The Head of DAO Ops will be in charge of community calls, the governance forum (pushing proposals from start to finish with the respective author), and pushing along the grants committee, ambassador program and multisig signers.

Additional responsibilities:
⁃ evaluating and defining compensation for existing and new committees and their members
⁃ Assigning budgets to committees
⁃ Verifying the data posted each month for the delegate compensation thread
⁃ Providing an overview of DAO ops at a regular cadence
⁃ Oversee and manage the transition from old committee members to new committee members when appropriate
⁃ More rapidly iterate on HIP amendments when they are needed
⁃ Help reform the grants committee and handle some of the ops side
⁃ 30 hours a month (1.5xday)
⁃ If a good faith effort to accomplish the tasks set forth as the Head of DAO ops is not made, the DAO will not pay the compensation.

This role should go through a 6-month initial term to make sure DAO operations continue to run smoothly in the short term while preparing for a long-term solution regarding ongoing operations. Since this role requires constant participation and time commitment, I believe compensation for this role should be $3k/month with a 1-year vesting period.

Compensation to be made in HOP token. Vesting starts the day after the election when the role officially begins and the work is to commence. Payment to be made retroactively every 3-months.

22 posts - 11 participants

Read full topic

Authors: Chris Whinfrey, Rxpwnz

This proposal will provide retroactive compensation to Rxpwnz and the rest of the moderator team who have all provided essential support for the past year and a half. It will also establish a Lead Community Moderator role and sets up an ongoing moderator compensation program to continue rewarding these contributors.

Background

Since Hop’s inception over a year ago, the role of Community Moderator has been entirely voluntary. This arrangement served the DAO well and attracted moderators driven by genuine enthusiasm for the protocol rather than financial incentives. However, it is now crucial to establish a structured framework for rewarding, managing, and training these contributors.

The Hop Community Moderators watch the Hop Discord and forum 24/7 to mitigate spam, scammers, technical difficulties, and much more. This includes manually banned approximately 5,000 Discord scammer or spam profiles, fielding an endless stream of questions from the community, and keeping appropriate stakeholders informed to ensure technical issues are resolved quickly. They’ve played an essential role in building Hop into the trusted platform it is today.

Rxpwnz has taken on a leadership role on the moderator team and regularly goes above and beyond basic moderator responsibilities. He regularly delves into technical and operational security topics including assisting with stuck transactions and reporting phishing websites to Metamask, Google and DNS providers leading to their rapid deactivation. He continually contributes ideas to enhance various aspects of Discord operations. This includes integrating Discord bots and streamlining channels to ensure they remain clean and topic-related. During Arbitrum Bridge Week, he even provided users with his own personal funds to help cover gas fees when needed.

Retrospective Rewards for Dedicated Moderators

Our community moderators have been actively contributing for over 18 months, and it’s time to recognize and reward their invaluable efforts in driving Hop’s growth.

Rxpwnz has been consistently engaged in a wide range of responsibilities, which include Discord and Forum moderation, managing Hop Guild, enhancing operational security (OpSec) by identifying and taking down over 150 phishing sites impersonating Hop, contributing to business development discussions regarding potential partnerships, engaging with developers interested in collaborating with Hop, and offering troubleshooting and improvement assistance. We propose a compensation rate of $3,000/month, both for his active contributions and in retrospective recognition starting June 9th, 2022. This compensation will be divided in a 50:50 ratio between $USDC and $HOP, with the latter being linearly vested over a 1-year period.

Our other moderators, while relatively less active, have been instrumental in moderation tasks and effectively conveying information about issues to key stakeholders. To acknowledge their important contributions, we propose one-time bonuses as follows:

Nauzystan: $4,000
Cai: $2,000
Hossein: $1,000
Abruzy: $1,000

Compensation for these bonuses will also be distributed in a 50:50 ratio between $USDC and $HOP, with the latter subject to linear vesting over 1 year.

The amount of $HOP distributed for retroactive payments should be calculated using the time-weighted average price from the launch of Hop DAO to the date of this proposal passing. Partial months should be prorated appropriately.

Establishing a Lead Community Moderator Role

This proposal establishes a Lead Community Moderator role initially filled by Rxpwnz. A new Lead Community Moderator can be appointed via subsequent governance proposal or by election should there be multiple interested individuals.

Compensation system

In addition to the ongoing compensation for the Lead Community Moderator mentioned above, this proposal establishes a discretionary budget to be used by the lead moderator to reward volunteer moderators from the community. Each month, approximately $2,000 worth of $HOP tokens will be made available to the Lead Community Moderator to distribute to the moderator team when appropriate. The lead moderator will conduct monthly assessments, guided by considerations of individual involvement and performance (activity and delivered Key Performance Indicators) to determine compensation. Any amounts distributed and their justification will be reported by the Lead Community Moderator to the Hop community in either written form or on the regular community calls. In months where the lead chooses to distribute only part or none of the budget, the $HOP will remain in the Hop Community Multisig and does not accrue toward future months.

8 posts - 8 participants

Read full topic

I am a UX researcher looking into the tooling that DAOs use for operations and decision making. Specifically, looking into what DAOs love about Discourse (the forum of choice) and what could be improved.

I have created a small discord group here to help me collect information from any volunteers who would be happy to help. Questions will be usually quick and short, and if we do any long form interviews, incentivize them in appreciation of the feedback.

The end goal is to provide better tooling to DAOs, but this can only be achieved by talking to them. If the Hop community is willing to help, join, please feel free to jump in and say hello.

There is only one channel there #general, since we want to keep comms simple.

Thank you and Much Appreciated!

2 posts - 1 participant

Read full topic

I have been researching how DAOs make decisions and I am curious about anonymity. Since this feature is possible on discourse and is easy to enable:

1. Have we considered enabling it here
2. If yes, why, if not, why not?

My thesis is that optional anonymity would allow users to communicate candidly without needing to create a throwaway account, and would love your feedback on this.

1 post - 1 participant

Read full topic

Intro

Firstly, allow us to introduce ourselves for anyone who isn’t already familiar with L2BEAT.

L2BEAT is an independent, public goods company who acts as an impartial watchdog for the Ethereum Layer2 ecosystem. Our mission is to provide comprehensive and unbiased analysis and comparative evaluations of Layer 2 solutions . We are committed to the verification and fact-checking of the claims made by each project, with a special focus on the security aspects. What sets L2BEAT apart is our unwavering commitment to delivering accurate and reliable information.

In addition, L2BEAT has a governance team (@Kaereste and @Sinkas) which actively participates in constructive discussions of specific protocol challenges and issues, fostering the discourse toward increasingly permissionless, open source, and trustless systems. Our participation in various DAOs and public debates reflects this commitment.

For more information on L2BEAT and our participation in Hop’s Governance, please refer to our delegate profile on Tally..

Delegate Communication Thread

To promote transparency and communication as delegates, we’ll be regularly updating the below thread with our actions in the governance of Hop. Our updates will include how we voted for different proposals and our rationale.

Update #1

Voting

[Snapshot] (HIP-37) Authereum Labs Engagement Adjustment - Voted FOR

We voted in favour of adjusting the compensation to be received by Authereum Labs since they were able to provide their services with a smaller team than expected, and, by extension, at a lesser cost.

[Snapshot] (HIP-38) Treasury Diversification - Voted FOR

Even though we believe there should be a more holistic approach to treasury diversification, we understand the risks associated with being overly exposed to a single asset and as such we voted in favour of the proposal.

[Tally] (HIP-38) Treasury Diversification - Voted FOR

We also voted in favour of the proposal during the subsequent on-chain vote.

[Snapshot] (HIP-39) Community Multisig Refill - Voted FOR

The community multisig should always have at least a couple of months’ worth of expenses and as such we voted in favour of the proposal to refill it.

[Tally] (HIP-39) Community Multisig Refill - Voted FOR

We also voted in favour of the proposal during the subsequent on-chain vote.

Discussions

Hop Grants Committee Renewal and Redesign

We participated in the discussion around the renewal and redesign of the Hop Grants Committee and invited the community to our office hours (which happen every Friday at 4pm UTC/11am EST) to discuss it further.

L2BEAT’s Hop Office Hours

To further our communication with our constituents and any interested party in the community, we’ll be hosting recurring Office Hours on Google Meets.

The office hours will be held every Friday at 4pm UTC/ 11am EST

During the Office Hours, you will be able to reach L2BEAT’s governance team, which consists of Kaereste (Krzysztof Urbanski) and Sinkas (Anastassis Oikonomopoulos) and discuss our activity as delegates.

The purpose of the office hours is to gather feedback from the people who have delegated to us, answer any questions in regards to our voting activities and rationale, and collect input on things you’d like us engage in discussions about.

You can add the L2BEAT Governance Calendar in your Google Calendar to find the respective Google Meets links for every call and to easily keep track of the Office Hours, as well as other important calls and events (e.g. voting deadlines) relevant to Uniswap that L2BEAT governance team will be attending or hosting.

2 posts - 1 participant

Read full topic

Agenda

Execution Layer Meeting 193 · Issue #1104 · ethereum/pm · GitHub
Moderator: @timbeiko

Summary

Stream

Additional info

• Notes: by @Christine_dkim

1 post - 1 participant

Read full topic

Discussion topic for EIP-XXXX: Auditable JSON-RPC

Update Log

• 2024-07-25: initial draft with supporting resources Add EIP: Auditable JSON-RPC API Specification by blockjoe · Pull Request #8760 · ethereum/EIPs · GitHub

External Reviews

I will note the bias that anything before 2024-07-25 is seeded from resources from the Author(s). While these should not be taken explicitly as reviews for the proposed specification, they are here to highlight the importance of keeping these API standards changes visible in the EIP process.

This section should list notable reviews the EIP has received from the Ethereum community. These can include specific comments on this forum, timestamped audio/video exchanges, formal audits, or other external resources. This section should be the go-to for readers to understand the community’s current assessment of the EIP. Aim for neutrality, quality & thoroughness over “cherry-picking” the most favorable reviews.

• 2022-12-05: “Unmitigatable exposure to theft of funds, XSS injection, and malware distribution due to the lack of idempotency in core Ethereum Execution JSON-RPC API logic in a compromised provider scenario.”, by Joseph Habel Original Disclosure

• 2024-07-08: “Accelerating the Distribution of a Verifiable Web”, by Jessica Daugherty (Presented by Joseph Habel) EthCC[7] Presentation

Outstanding Issues

• 2024-07-24: These changes belong in the Execution APIs Context

Discussing the Broader Communications Impact

While I understand for the sake of the Ethereum process that the adoption of these changes happen via the Execution APIs repository, and am happy to submit the test cases and updated OpenRPC specification there, I would like to open a broader discussion of what the process need be for signaling the need for these changes not just to the Execution Client developers, but rather all projects claiming to “Support Ethereum Compatibility”.

This specification, while I realize on a technical basis is irrelevant to the work of the core dev team, has engrained a set of developer anti-patterns that need to be addressed at a “cultural level” core to the experience of ecosystem and application developers.

I’m happy to shepard the technical changes through the proper process, but would like to discuss what the avenue here would be for signaling to projects that have inherited these anti-patterns in the goal of “Ethereum Support”. The EIP nomenclature acts as a very effective communication tool when discussing the importance of changes to other development teams outside of the EL client developers, in a way that an unnamable PR to a supporting repository cannot.

When seeking feedback about these changes in private conversations, the means of effectively communicating the importance comes from demonstrating proof of concept injection attacks. I have chosen not to publicly broadcast these to this point, but I would love feedback about if there’s a stronger middle ground here for herding the branching downstream changes that would need to happen in response.

1 post - 1 participant

Read full topic

First time poster on Ethereum magicians, I hope I’m not overstepping here, if so, please let me know…

I’m looking for some early technical feedback on a new oracle solution my team and I are working on, or interested people who potentially want to give it a try.

We were working on a novel oracle solution that leverages ERC-4337 account abstraction to provide real-time on-chain price updates. Unlike traditional pull or push-based oracles, our approach uses an intent system leveraging and extending the already existing infrastructure for erc4337 account abstraction.

Something like this:

The idea we had was to run a slightly modified erc4337 bundler that listens to a new kind of UserOp, or wraps the actual UserOp in a DataRequestOp and injects updated (price/…/?) information before submitting the actual transaction. From a data-consuming contract perspective, it would be usable very much like a push oracle, just like manually triggering an update before read and would basically ensure accurate and up-to-date data being on chain before a contract reads it. On the other end, the bundler (or whoever is providing data) gets compensated for its services through the same mechanism that erc4337 already uses. So, it would create an additional economic incentive to run a bundler.

We got a prototype for a single bundler and the whole process running on sepolia. It’s of course not decentralized and the end vision is a decentralized network of bundlers or something like aggregated signatures of several bundlers and an open protocol to let anyone run a bundler+dataprovider and potentially a reputation dashboard of some sort.

Anyways, that’s the idea in a nutshell. Thoughts, concerns? Any projects that work on a tangential system and want to collaborate? Anyone who needs access to real time US Equities, Commodities or Forex and want to give it a try? Anyone who is currently running Bundlers and would be interested in implementing it - or spearhead an ERC together?

Thanks,
Thomas

1 post - 1 participant

Read full topic

Agenda

Consensus-layer Call 138 · Issue #1100 · ethereum/pm · GitHub
Moderator: @ralexstokes

Summary

Recap by @ralexstokes (from Eth R&D Discord)

• Started the call with an update on pectra-devnet-1 , which launched this week
  • The network is live but participation is low and the chain has forked into 3-4 pieces
  • The initial chain split appears to have been caused by an EIP-7702 transaction, and there’s ongoing work to debug
• Next, we turned to a proposal to restructure the requests types added in Pectra
  • These requests types are data coming from the EL which are required for the CL to process with each block
  • Until now, CL clients prune EL data as otherwise the data would be duplicated within one Ethereum node given the dual CL-EL architecture
  • The proposal here suggests moving the requests data outside the block structure CL clients already prune so we can easily have the requests data handy with minimal code change
  • We discussed the design space addressing this problem on the call as there are a few different ways to satisfy the problem, but there was broad support for @potuz’s solution linked above.
• Then we had a proposal from @matt to change how these requests types are arranged in the Engine API to facilitate ease of implementation of the EL interfacing with the CL
  • There was some back and forth on the details, as a large part of answering this question comes down to finding the best way to share the technical complexity of this feature set between EL and CL implementations.
  • This proposal appears to mirror the implementation of these features on the EL which can simply forward them into the Engine API; in turn, the CL then has some additional work to do to map the unified data into the requisite parts.
  • Given the fact that CL implementations generally have stronger typing of per-fork types, we landed on this PR making sense and intend to move forward with it.
  • CL teams please take a look here to chime in further.
• After discussing these request types, we turned to an update on the SSZ stable container EIPs.
  • @etan-status gave a great summary of the progress here and proposed we include EIP-7688 and EIP-7495 into Pectra devnet-2.
  • I clarified that the purpose of the pectra devnets is to reflect the formally included set of EIPs in Pectra, and so rather than simply including these EIPs in devnet-2, we must first agree to inclusion in Pectra.
  • We discussed formal inclusion on the call with a variety of viewpoints: while the benefits of these changes are sound in isolation, there was strong pushback that Pectra is already quite large and the testing and security processes around the hard fork development are already quite strained given the size of the fork.
  • There was no strong push for inclusion of these SSZ EIPs on the call and especially in light of the instability of the existing Pectra devnet agreed to focus on hardening the existing fork as specified before moving to consider additional features.
• PeerDAS was up after the core Pectra discussions
  • There hasn’t been much movement on the peerdas-devnet front, as the last network was not stable and clients have been in the process of hardening implementations before attempting another devnet.
  • Acknowledging this, I gave an overview of the option to simplify PeerDAS further by dropping the “sampling” phase of the data availability mechanism of PeerDAS so that we can still have something shipped in Pectra without significantly delaying timelines.
    • This solution would still have nodes down segments of the blob data and for a small change in some of the PeerDAS parameters still maintains the same security profile as PeerDAS with sampling.
  • There was interest on further exploring the idea and I’ll write something soon to share more widely beyond the call. Attendees are open to the idea, especially given the broad support for data scaling in Pectra.
• This discussion segued into a general discussion of how to arrange PeerDAS alongside the rest of the Pectra features
  • The current approach has PeerDAS activated at a separate epoch than the Pectra fork epoch; these two parameters could ultimately be the same but allows for a relatively easy way to “disable” PeerDAS from Pectra in the event development timelines didn’t align with the rest of the Pectra EIP set.
  • There were a variety of opinions on the best way to do this so I recommend checking the call for the full color.
  • Ultimately, we decided to focus on getting a more stable network around the other Pectra EIPs (cf. devnet-1 stability) and revisit the best way to merge in the PeerDAS work once that is done.
• We concluded the call with a proposal from @dapplion to enhance the expressivity of the BeaconBlocksByRange networking method — take a look at that PR and please provide any feedback.

Recording

Additional info

Notes by @Christine_dkim: Ethereum All Core Developers Consensus Call #138 Writeup | Galaxy

1 post - 1 participant

Read full topic

Agenda

PeerDAS Breakout Room #4 · Issue #1103 · ethereum/pm · GitHub

Key items

by Jimmy Chen (from Eth R&D Discord):

• Teams are mostly focused on client stability, optimisation and refactoring
• devnet-1 was shutdown last week and devnet-2 hasn’t been scheduled yet as teams are focused on improving stability and refactoring.
• Teams noted the following changes for the next devnet launch
  • MetaDataV3 rpc query with custody subnet count
  • Clients to make sure initial syncing work and nodes can serve data column rpc methods reliably
  • Delay blob spamming to a few epochs after genesis

Notes & chat log

Recording

PeerDAS Breakout Room #4

1 post - 1 participant

Read full topic

This EIP formalizes the currently proposed algorithm to migrate the state from the current MPT to VKT.

Creating this thread to open for discussion!

Note: I’ll edit the post title when an EIP number gets assigned.

1 post - 1 participant

Read full topic

This is the discussion thread for EIP-7747. EIP-7747 is a proposal for cost-efficient, expanded-width modular addition/subtraction/multiplication opcodes for the EVM. The EIP is currently a PR on the EIPs repo.

2 posts - 1 participant

Read full topic

Hello Ethereum Magicians,

In light of recent discussions around EOF and about protecting the EIP process from special interests, as highlighted in the Ethereum Magicians thread, I propose a transformative yet gradual approach to how we conduct discussions, plan, and make decisions within the Ethereum community. This proposal aims to supplement the current Ethereum Magicians platform with an AI-driven mail server that leverages AI to enhance efficiency, inclusivity, and transparency, while keeping every contribution recorded on the Ethereum blockchain.

Vision:

Imagine a platform where a Linux server checks ethereum-magicians.org for new submissions and a list of mailboxes every 5 minutes, parsing all new content through a preset but configurable LLM (Language Learning Model). This AI would filter and summarize all submitted data to decide the agenda points for the next All Core Dev (ACD) meeting. Here’s how it would work:

Key Components:

1. Data Submission:

   • Participants submit their thoughts, ideas, and concerns here on the forum or via email.
   • Each submission could eventually be authenticated via ENS/ETH to prevent spam and ensure only relevant inputs are considered, perhaps even require a minimum gas fee to consider your contribution and prevent spam though I think current AI can sufficiently filter out spam anyway.

2. AI Aggregation and Summarization:

   • The AI aggregates and summarizes all inputs, identifying key issues and creating a dynamic agenda based on prioritized topics.
   • A local text/data blob file is maintained for every unique submitter and every unique discussion. AI can help people informally connect over similar topics of interest to discuss and guide them towards people also occupied with the same ideas or concerns. acdagenda@ethereum.ai (example) for all submissions around the next agenda eip3074@ethereum.ai (for all discussions around that eip) and of course you can generate new ones on the fly and have AI tell you about / announce to others who have similar enough needs for discussion. let email addresses be channels of communication that anyone can submit whatever to, and set an LLM to moderate away the spam and irrelevance (within that channel)

3. Continuous Updates:

   • The proposed agenda is automatically updated with every new email/datablob processed, valuing every voice equally.
   • A default agenda item is included to discuss any frustrations or proposals for updating the aggregator AI.

4. Human Control and Selection:

   • While the AI assists in creating the agenda and providing solutions, humans retain control over selecting and voting on the final agenda items as AI just like humans, makes mistakes. We must still verify ourselves instead of blindly trusting.
   • This ensures that all decisions are made by the community, maintaining the decentralized ethos of Ethereum.

5. Transparency and Traceability:

   • All raw text interactions and conversations during the ACD are recorded and stored on the Ethereum blockchain for full transparency.
   • Users can query the AI to understand decision histories and how specific agenda points were decided.
   • Privacy concerns are minimal as all discussions are technical in nature, focusing solely on improving Ethereum.

6. Technical Focus:

   • All conversations should be technical in nature and focused on improving Ethereum for everyone. This strict context window ensures relevant discussions and effective governance.

7. EIP Defense Mechanism:

   • Each EIP can defend itself by being automatically included in the ACD agenda once per meeting.
   • The AI summarizes the arguments for and against each EIP based on reactions received in advance, ensuring a balanced and comprehensive discussion.

Proof of Concept:

To validate this approach, I will set up a web interface displaying the most recent ACD agenda proposal based on recent activity on the Ethereum Magicians forums. This interface will feature:

• An email address for anyone to freely contribute their thoughts and ideas.
• The AI will assess the relevance of each contribution to the ACD call and adjust the agenda accordingly within minutes.
• Users can ask the AI questions about the current knowledge database and ongoing discussions not yet visible on the agenda.

This initial phase can run on a regular Linux server, storing submissions locally and connecting necessary APIs. Over time, as we build trust and familiarity, we can transition to a fully functional Layer 2 solution, providing the needed scalability and decentralized trust.

Embracing Change for True Decentralization:

For the Ethereum community to truly embrace decentralization, we must be willing to automate our own roles, even those of community moderators. Current moderators should see this as an opportunity to enhance their contributions, not as a threat to their positions. By adopting superhuman moderators, we can ensure that every voice is heard, and every relevant concern is addressed, pushing the boundaries of what we can achieve as a decentralized community.

Call to Action:

I propose we develop this platform as a proof of concept, initially focusing on ACDE agendas and EIP discussions. By open-sourcing the aggregator AI, we can foster truly decentralized communities moderated by AI. The technology is already here; we just need to update our approach to leverage it fully.

Let’s discuss this proposal, provide feedback, and explore how we can make this vision a reality. Together, we can set a new standard for collaborative decision-making and take the next step in decentralizing our processes.

Looking forward to an enlightening discussion!

Snek 𓆙𓂀

3 posts - 2 participants

Read full topic

I’m in the process of searching for possible solutions to a need I think many DAOs/teams/groups have: the ability to provably have a reward/bounty on some action, and have others be able to contribute to it.

Many groups have “task lists” that they can set up with items they want accomplished. Tools like Dework or CharmVerse already exist to have cryptocurrency bounties put on the tasks. However, in both those tools the bounty is not verified/guaranteed. Visitors need to trust the group organizers to properly pay out when the task is complete, and also have to do their independent verification of whether the organizers actually have those funds to pay out (if there’s five tasks posted and each has a reward of 5 ETH, is there really enough in the treasury to pay all them out? Sorting the list of all Dework bounties by largest reward, I’m really skeptical the top listings would actually pay out…). Because systems like that rely on trust of the organizers, it’s hard to have other community members contribute to the bounty.

I think if there were a lightweight way for community members to pool financial incentives, it would take some of the weight off the community organizers to manage. The goal is to have a list of tasks that are given rewards by many people contributing a little (grassroots-style, Kickstarter-style), rather than a single sponsor giving a grant (organizers figuring out rewards from community funds). Being able to do that in a provable way (the funds are put in escrow on-chain in an easily-inspect-able way) would encourage people to apply to do the task, and I think getting community involvement in bounty-funding is helpful because the financial reward intrinsically scales with how popular an item is to be implemented.

There’s still a level of trust placed in the organizing group to do the reviews of task submissions and fairly trigger the payouts, but I think that’s an acceptable level of trust needed, given the current systems require that too. A more advanced setup could include the ability for a global governance group like Kleros Court to allow end-users to appeal if the organizing group turns unresponsive.

Bountysource had a system like this, but seems to have gone stagnant. Any other platform already done this?

My thoughts on how to make a platform to support this functionality:

Individual Lockboxes

Create a smart contract that is a factory that group organizers can trigger to stamp out a new “lockbox/escrow” contract.

The lockbox contract acts as a smart contract wallet that starts with an owner of the address that triggered its creation. It then exists as a separate space that anyone can send funds to (it’s now the “reward wallet” for a single task item). When someone does the task, the organizer transfers ownership to the awardee.

Downsides

The group organizers probably don’t want to create a lockbox for every single task (as that costs gas to stamp out another smart contract), so either the address the lockbox gets created at needs to be deterministic (community members can send funds to an “empty” address to show interest, and if the wallet’s balance is non-empty, the organizers can trigger deploying the smart contract logic to it), or the first community member to donate to the bounty has an increased cost of creating the lockbox too.

People are likely to donate lots of different types of tokens (a single bounty may end up with a mishmash of DAI, USDT, USDC, FRAX, WETH, and ETH), so “sweeping” the wallet may be pretty gas-intensive. It may be beneficial then for the recipient to just keep the funds where they are, and spend from that wallet directly. Though if a single contributor wins several bounties, they’d then have multiple of these lockboxes, with potentially multiple different “dust” values in each to then try to manage.

Merged Pool

Alternatively, rewards could be pooled into one main “pot” and the individual bounties annotated as how much allocation they get of the main pot.

This is pretty similar to a DAO’s treasury and how Proposals can typically claim portions of the treasury. But a DAO would likely want to keep “bounty” funds separate from their main treasury (as a way to show those funds are earmarked/promised to be spent already, and cannot be used for other proposals).

This is now easier on the recipient, who if they receive multiple bounties, their “dust” combines into a single allowance to be able to withdraw. It also minimizes the gas use for repeated actions (there’s just an initial setup cost of creating the pool, and setting up allowances).

Downsides

Having a central pool means it’s a little more complicated for end-users to contribute: they cannot just send funds to the address, they need to also somehow annotate which bounty the contribution is for. That likely means they’d need to use the “Approve” process for ERC20- and ERC721-style tokens and call specific functions on the pool contract to do it properly. But it’s possible for users to make mistakes, and some funds may get blindly transferred to the pool address, making the total holdings of the pool larger than the combined allocations for the individual bounties.

The pool could be coded to deal with that surplus somehow (e.g. it acts as a form of “quadratic funding” extra balance that bounties that already have some value allocated then get an additional part of the “bonus” in the pool?), but would likely add a lot of complication to the process.

Having the funds in a central pool is more of a honeypot to draw in attackers, and one weakness could result in losing the whole pot of funds. That can be mitigated somewhat by not having a single global bounty pool, but each organizing group having their own individual pool for their bounties.

Next steps

Is there any project that’s already doing this sort of escrow setup? If not, what do we think is the best way to structure the base layer (individual smart contract lockboxes, or centralized bounty pools)?

2 posts - 1 participant

Read full topic

Agenda

EIP-7732 breakout room #5 · Issue #1095 · ethereum/pm · GitHub
Moderator: @potuz

Notes

Recording

https://www.youtube.com/watch?v=pFJMqk5zkPQ

1 post - 1 participant

Read full topic

Discussion topic for EIP-7745

An efficient and light client friendly replacement for bloom filters. This EIP proposes a new data structure that adds a moderate amount of consensus data that is optional to store long term, has limited processing and memory requirements and allows searching for log events with 2-3 orders of magnitude less bandwidth than what bloom filters allowed back when they were not rendered useless by over-utilization. It also inherently adapts to changing block utilization and maintains a constantly low average false positive ratio.

3 posts - 2 participants

Read full topic

Hi everyone,

I’d like to start a discussion on my new EIP-7743: Multi-Owner Non-Fungible Tokens (MO-NFT).

Abstract:
This EIP proposes a new standard for non-fungible tokens (NFTs) that supports multiple owners. The MO-NFT standard allows a single NFT to have multiple owners, reflecting the shared and distributable nature of digital assets. This model also incorporates a mechanism for value depreciation as the number of owners increases, maintaining the principle that less ownership translates to more value.

Motivation:
Traditional NFTs enforce a single-ownership model, which does not align with the inherent duplicability of digital assets. MO-NFTs allow for shared ownership, promoting wider distribution and collaboration while maintaining secure access control. This model supports the principle that some valued information is more valuable if fewer people know it, hence less ownership means higher value.

You can view the full proposal and PR here.

I welcome any feedback, suggestions, or discussions on this proposal.

Thank you!

1 post - 1 participant

Read full topic

Currently contract discovery relies on addresses, which are non-deterministic and can be obfuscated through proxies. Indexing by bytecode hash provides a deterministic and tamper-proof way to identify and verify contract code, enhancing security and trust in the Ethereum ecosystem.

Global bytecode identification is a requirement to build efficient at high scale global factories for future software distribution, that may want to rely on extensive re-use of same codebase as own dependencies, such as Ethereum Distribution System that creates a simple, global index that maps already deployed bytecode to it’s location via address.codehash

5 posts - 2 participants

Read full topic

Agenda

Verkle Implementers Call #21 · Issue #1092 · ethereum/pm · GitHub
2024-07-15T15:00:00Z UTC
Moderator: @rudolf

Notes

Notes by @rudolf

Recording

Verkle Implementers Call #21

1 post - 1 participant

Read full topic

Agenda

Execution Layer Meeting 192 · Issue #1098 · ethereum/pm · GitHub

Moderator: @timbeiko

Summary

Recording

Additional info

• Notes: Ethereum All Core Developers Execution Call #192 Writeup | Galaxy by @Christine_dkim
• EOF: Why I am against EOF in Pectra – MariusVanDerWijden by @MariusVanDerWijden
• RIP7212: Brief History and Current Situation of RIP-7212 by @ulerdogan

2 posts - 2 participants

Read full topic

There is currently a gap in the interface between dapps and ERC-4337 wallets; support for network addition via EIP-3085 wallet_addEthereumChain. In order for a 4337 wallet to function with an arbitrary chain, it needs to be provided with an RPC URL that can serve the 4337-specific RPC methods.

I see a few potential paths forward here:

1. Reuse EIP-3085 EthereumChainAddRequest.rpcUrls by leveraging the fact that a dapp can already provide multiple RPC providers with the existing interface
   1. We could specify the ordering of these URLs, i.e. the first one is always the bundler, and subsequent ones are always general-purpose RPCs
   2. We could define a prefix to be added the bundler URL so that the wallet can identify it
2. Standardize around a single RPC URL - the RPC provider passed via 3085 should handle both traditional as well as 4337-specific RPC methods
   • Some bundlers such as Alchemy already work in this way. Others (i.e. Pimlico) expressly do not.
   • Dapps may need to build a JSON RPC reverse proxy depending on their bundler provider.
3. Extend EIP-3085 EthereumChainAddRequest
   1. Add an rpcMetadata mapping of RPC URLs to metadata (maybe a dictionary with e.g. "supports4337": true)
   2. Add a bundlerRpcUrls parameter

I would love to hear from anyone else who is already thinking about this!

2 posts - 2 participants

Read full topic

Discussions for EIP-7742.

1 post - 1 participant

Read full topic

Discussion for Add ERC: Authorize Operator #536

1 post - 1 participant

Read full topic

Readable Typed Signatures for Smart Accounts

Description: A defensive rehashing scheme which prevents signature replays across smart accounts and preserves the readability of the signed contents.

Authors: vectorized (@vectorized), Sihoon Lee (@push0ebp), Francisco Giordano (@frangio), Im Juno (@junomonster), howydev (@howydev), 0xcuriousapple (@0xcuriousapple)

Requires: 191, 712, 1271, 5267

Preliminary Reading

Signature replay vulnerability with ERC-1271

Defensive rehashing implementations in smart accounts

• Safe: safe-smart-account/contracts/handler/CompatibilityFallbackHandler.sol at 5feb0d08f59cfbb44918be1ed5889d9bb634562a · safe-global/safe-smart-account · GitHub

• Coinbase: smart-wallet/src/ERC1271.sol at facf1a5a00a393c859c77a7cff38de1e557c393f · coinbase/smart-wallet · GitHub

Twitter thread on opaqueness in defensive rehashing:
https://twitter.com/howydev/status/1780353754333634738

Twitter thread on a possible phishing vector with readable defensive rehashing, and how it was fixed:
https://twitter.com/push0ebp/status/1786460154277572718

Code

Solady Solidity ERC-1271 implementation, which implements this ERC-7739.

Viem utilities for Solady ERC-1271:

Abstract

This proposal defines a standard to prevent signature replays across multiple smart accounts when they are owned by a single Externally Owned Account (EOA). This is achieved through a defensive rehashing scheme for ERC-1271 verification using specific nested EIP-712 typed structures, which preserves the readability of the signed contents during wallet client signature requests.

Motivation

Smart accounts can verify signatures with via ERC-1271 using the isValidSignature function.

A straightforward implementation as shown below, is vulnerable to signature replay attacks.

/// @dev This implementation is NOT safe.
function isValidSignature(
    bytes32 hash,
    bytes calldata signature
) external override view returns (bytes4) {
    if (ECDSA.recover(hash, signature) == owner) {
        return 0x1626ba7e;
    } else {
        return 0xffffffff;
    }
}

When a multiple smart accounts are owned by a single EOA, the same signature can be replayed across the smart accounts if the hash does not include the smart account address.

Unfortunately, this is the case for many popular applications (e.g. Permit2). As such, many smart account implementations perform some form of defensive rehashing. First, the smart account computes a final hash from minimally: (1) the hash, (2) its own address, (3) the chain ID. Then, the smart account verifies the final hash against the signature. Defensive rehashing can be implemented with EIP-712, but a straightforward implementation will make the signed contents opaque.

This standard provides a defensive rehashing scheme that makes the signed contents visible across all wallet clients that support EIP-712. It is designed for minimal adoption friction. Even if wallet clients or application frontends are not updated, users can still inject client side JavaScript to enable the defensive rehashing.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Overview

Compliant smart account MUST implement the following:

• EIP-712 Typed structured data hashing and signing.
  Provides the relevant typed data hashing logic internally, which is required to construct the final hashes.

• ERC-1271 Standard Signature Validation Method for Contracts.
  Provides the isValidSignature(bytes32 hash, bytes calldata signature) function.

• ERC-5267 Retrieval of EIP-712 domain.
  Provides the eip712Domain() function which is required to compute the final hashes.

This standard defines the behavior of the isValidSignature function for ERC-1271, which comprises of two workflows: (1) the TypedDataSign workflow, (2) the PersonalSign workflow.

TypedDataSign workflow

The TypedDataSign workflow handles the case where the hash is originally computed with EIP-712.

TypedDataSign final hash

The final hash for the TypedDataSign workflow is defined as:

keccak256(\x19\x01 ‖ APP_DOMAIN_SEPARATOR ‖
    hashStruct(TypedDataSign({
        contents: hashStruct(originalStruct),
        name: eip712Domain().name,
        version: eip712Domain().version,
        chainId: eip712Domain().chainId,
        verifyingContract: eip712Domain().verifyingContract,
        salt: eip712Domain().salt,
        extensions: eip712Domain().extensions
    }))
)

where ‖ denotes the concatenation operator for bytes.

In Solidity, this can be written as:

keccak256(
    abi.encodePacked(
        hex"1901",
        // Application specific domain separator. Passed via `signature`.
        bytes32(APP_DOMAIN_SEPARATOR),
        keccak256(
            abi.encode(
                // Computed on-the-fly with `contentsType`, which is passed via `signature`.
                typedDataSignTypehash, 
                // This is the `contents` struct hash, which is passed via `signature`.
                bytes32(hashStruct(originalStruct)),
                // `eip712Domain()` is from ERC-5267. 
                keccak256(bytes(eip712Domain().name)), 
                keccak256(bytes(eip712Domain().version)),
                uint256(eip712Domain().chainId),
                uint256(uint160(eip712Domain().verifyingContract)),
                bytes32(eip712Domain().salt),
                keccak256(abi.encodePacked(eip712Domain().extensions))
            )
        )
    )
)

where typedDataSignTypehash is:

abi.encodePacked(
    "TypedDataSign(",
        contentsTypeName,
        "bytes1 fields,",
        "string name,",
        "string version,",
        "uint256 chainId,",
        "address verifyingContract,",
        "bytes32 salt,",
        "uint256[] extensions",
    ")",
    contentsType
)

If contentsType is "Mail(address from,address to,string message)", then contentsTypeName will be "Mail".

The contentsTypeName function can be computed with:

// `LibString`: https://github.com/Vectorized/solady/blob/main/src/utils/LibString.sol
//
// `slice(string memory subject, uint256 start, uint256 end)` 
// returns a copy of `subject` sliced from `start` to `end` (exclusive).
// `start` and `end` are byte offsets.
//
// `indexOf(string memory subject, string memory search)`
// Returns the byte index of the first location of `search` in `subject`,
// searching from left to right. Returns `2**256 - 1` if `search` is not found.
LibString.slice(t, 0, LibString.indexOf(t, "("));

For safety, smart accounts MUST treat the signature as invalid if any of the following is true:

• contentsTypeName is the empty string (i.e. bytes(contentsTypeName).length == 0).
• contentsTypeName starts with any of the following bytes abcdefghijklmnopqrstuvwxyz(.
• contentsTypeName contains any of the following bytes , )\x00.

TypedDataSign signature

The signature passed into isValidSignature will be changed to:

originalSignature ‖ APP_DOMAIN_SEPARATOR ‖ contents ‖ contentsType ‖ uint16(contentsType.length)

where contents is the bytes32 struct hash of the original struct.

In Solidity, this can be written as:

abi.encodePacked(
    bytes(originalSignature),
    bytes32(APP_DOMAIN_SEPARATOR),
    bytes32(contents),
    bytes(contentsType),
    uint16(contentsType.length)
)

The appended APP_DOMAIN_SEPARATOR and contents struct hash will be used to verify if the hash passed into isValidSignature is indeed correct via:

hash == keccak256(
    abi.encodePacked(
        hex"1901",
        bytes32(APP_DOMAIN_SEPARATOR),
        bytes32(contents)
    )
)

PersonalSign workflow

This PersonalSign workflow handles the case where the hash is originally computed with EIP-191.

PersonalSign final hash

The final hash for the PersonalSign workflow is defined as:

keccak256(\x19\x01 ‖ ACCOUNT_DOMAIN_SEPARATOR ‖
    hashStruct(PersonalSign({
        prefixed: keccak256(bytes(\x19Ethereum Signed Message:\n ‖
        base10(bytes(someString).length) ‖ someString))
    }))
)

where ‖ denotes the concatenation operator for bytes.

In Solidity, this can be written as:

keccak256(
    abi.encodePacked(
        hex"1901",
        // Smart account domain separator.
        // Can be computed via `eip712Domain()` from ERC-5267.
        bytes32(ACCOUNT_DOMAIN_SEPARATOR),
        keccak256(
            abi.encode(
                // `PERSONAL_SIGN_TYPEHASH`.
                keccak256("PersonalSign(bytes prefixed)"),
                // `hash` is from `isValidSignature(hash, signature)`
                hash
            )
        )
    )
)

Here, hash is computed in the application contract and passed into isValidSignature.

The smart account does not need to know how hash is computed. For completeness, this is how it can be computed:

abi.encodePacked(
    "\x19Ethereum Signed Message:\n",
    // `LibString`: https://github.com/Vectorized/solady/blob/main/src/utils/LibString.sol
    //
    // `toString` returns the base10 representation of a uint256.
    LibString.toString(someString.length),
    // This is the original message to be signed.
    someString
)

PersonalSign signature

The PersonalSign workflow does not require additional data to be appended to the signature passed into isValidSignature.

supportsNestedTypedDataSign function for detection

To facilitate automatic detection, smart accounts SHOULD implement the following function:

/// @dev For automatic detection that the smart account supports the nested EIP-712 workflow.
/// By default, it returns `bytes32(bytes4(keccak256("supportsNestedTypedDataSign()")))`,
/// denoting support for the default behavior, as implemented in
/// `_erc1271IsValidSignatureViaNestedEIP712`, which is called in `isValidSignature`.
/// Future extensions should return a different non-zero `result` to denote different behavior.
/// This method intentionally returns bytes32 to allow freedom for future extensions.
function supportsNestedTypedDataSign() public view virtual returns (bytes32 result) {
    result = bytes4(0xd620c85a);
}

Workflow detection

The isValidSignature function MUST perform the TypedDataSign workflow if the signature contains the correct data to reconstruct the hash.

This can be checked via:

// If this is true, it means that the `signature` contains 
// the correct `APP_DOMAIN_SEPARATOR` and `contents`.
hash == keccak256(
    abi.encodePacked(
        hex"1901",
        bytes32(APP_DOMAIN_SEPARATOR),
        bytes32(contents)
    )
)

If this expression returns false, then the PersonalSign workflow MUST be attempted.

Conditional skipping of defensive rehashing

Smart accounts MAY skip the defensive rehashing workflows if any of the following is true:

• isValidSignature is called off-chain.
• The hash passed into isValidSignature has already included the address of the smart account.

Rationale

TypedDataSign structure

The typedDataSignTypehash must be constructed on-the-fly on-chain. This is to enforce that the signed contents will be visible in the signature request, by requiring that contents be a user defined type.

The structure is intentionally made flat with the fields of eip712Domain to make implementation feasible. Otherwise, smart accounts must implement on-chain lexographical sorting of strings for the struct type names when constructing typedDataSignTypehash.

supportsNestedTypedDataSign for detection

Without this function, this standard will not change the interface of the smart account, as it defines the behavior of isValidSignature without adding any new functions. As such, ERC-165 cannot be used.

For future extendability, supportsNestedTypedDataSign is defined to return a bytes32 as the first word of its returned data. For bytecode compactness and to leave space for bit packing, only the leftmost 4 bytes are set to the function selector of supportsNestedTypedDataSign.

The supportsNestedTypedDataSign function may be extended to return multiple values (e.g. bytes32 result, bytes memory data), as long as the first word of the returned data is a bytes32 identifier. This will not change the function selector.

Backwards Compatibility

No backwards compatibility issues.

Reference Implementation

The following reference implementation is production ready and optimized. It also includes relevant complementary features required for safety, flexibility, developer experience, and user experience.

It is intentionally not minimalistic. This is to avoid repeating the mistake of ERC-1271, where a reference implementation is wrongly assumed to be safe for production use.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.4;

// https://github.com/Vectorized/solady/blob/main/src/utils/EIP712.sol
import {EIP712} from "../utils/EIP712.sol";
// https://github.com/Vectorized/solady/blob/main/src/utils/SignatureCheckerLib.sol
import {SignatureCheckerLib} from "../utils/SignatureCheckerLib.sol";

/// @notice ERC1271 mixin with nested EIP-712 approach.
/// @author Solady (https://github.com/vectorized/solady/blob/main/src/accounts/ERC1271.sol)
abstract contract ERC1271 is EIP712 {
    /*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/
    /*                         CONSTANTS                          */
    /*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/

    /// @dev `keccak256("PersonalSign(bytes prefixed)")`.
    bytes32 internal constant _PERSONAL_SIGN_TYPEHASH =
        0x983e65e5148e570cd828ead231ee759a8d7958721a768f93bc4483ba005c32de;

    /*´:°•.°+.*•´.*:˚.°*.˚•´.°:°•.°•.*•´.*:˚.°*.˚•´.°:°•.°+.*•´.*:*/
    /*                     ERC1271 OPERATIONS                     */
    /*.•°:°.´+˚.*°.˚:*.´•*.+°.•°:´*.´•*.•°.•°:°.´:•˚°.*°.˚:*.´+°.•*/

    /// @dev Validates the signature with ERC1271 return,
    /// so that this account can also be used as a signer.
    function isValidSignature(bytes32 hash, bytes calldata signature)
        public
        view
        virtual
        returns (bytes4 result)
    {
        bool success = _erc1271IsValidSignature(hash, _erc1271UnwrapSignature(signature));
        /// @solidity memory-safe-assembly
        assembly {
            // `success ? bytes4(keccak256("isValidSignature(bytes32,bytes)")) : 0xffffffff`.
            // We use `0xffffffff` for invalid, in convention with the reference implementation.
            result := shl(224, or(0x1626ba7e, sub(0, iszero(success))))
        }
    }

    /// @dev For automatic detection that the smart account supports the nested EIP-712 workflow.
    /// By default, it returns `bytes32(bytes4(keccak256("supportsNestedTypedDataSign()")))`,
    /// denoting support for the default behavior, as implemented in
    /// `_erc1271IsValidSignatureViaNestedEIP712`, which is called in `isValidSignature`.
    /// Future extensions should return a different non-zero `result` to denote different behavior.
    /// This method intentionally returns bytes32 to allow freedom for future extensions.
    function supportsNestedTypedDataSign() public view virtual returns (bytes32 result) {
        result = bytes4(0xd620c85a);
    }

    /// @dev Returns the ERC1271 signer.
    /// Override to return the signer `isValidSignature` checks against.
    function _erc1271Signer() internal view virtual returns (address);

    /// @dev Returns whether the `msg.sender` is considered safe, such
    /// that we don't need to use the nested EIP-712 workflow.
    /// Override to return true for more callers.
    /// See: https://mirror.xyz/curiousapple.eth/pFqAdW2LiJ-6S4sg_u1z08k4vK6BCJ33LcyXpnNb8yU
    function _erc1271CallerIsSafe() internal view virtual returns (bool) {
        // The canonical `MulticallerWithSigner` at 0x000000000000D9ECebf3C23529de49815Dac1c4c
        // is known to include the account in the hash to be signed.
        return msg.sender == 0x000000000000D9ECebf3C23529de49815Dac1c4c;
    }

    /// @dev Returns whether the `hash` and `signature` are valid.
    /// Override if you need non-ECDSA logic.
    function _erc1271IsValidSignatureNowCalldata(bytes32 hash, bytes calldata signature)
        internal
        view
        virtual
        returns (bool)
    {
        return SignatureCheckerLib.isValidSignatureNowCalldata(_erc1271Signer(), hash, signature);
    }

    /// @dev Unwraps and returns the signature.
    function _erc1271UnwrapSignature(bytes calldata signature)
        internal
        view
        virtual
        returns (bytes calldata result)
    {
        result = signature;
        /// @solidity memory-safe-assembly
        assembly {
            // Unwraps the ERC6492 wrapper if it exists.
            // See: https://eips.ethereum.org/EIPS/eip-6492
            if eq(
                calldataload(add(result.offset, sub(result.length, 0x20))),
                mul(0x6492, div(not(mload(0x60)), 0xffff)) // `0x6492...6492`.
            ) {
                let o := add(result.offset, calldataload(add(result.offset, 0x40)))
                result.length := calldataload(o)
                result.offset := add(o, 0x20)
            }
        }
    }

    /// @dev Returns whether the `signature` is valid for the `hash.
    function _erc1271IsValidSignature(bytes32 hash, bytes calldata signature)
        internal
        view
        virtual
        returns (bool)
    {
        return _erc1271IsValidSignatureViaSafeCaller(hash, signature)
            || _erc1271IsValidSignatureViaNestedEIP712(hash, signature)
            || _erc1271IsValidSignatureViaRPC(hash, signature);
    }

    /// @dev Performs the signature validation without nested EIP-712 if the caller is
    /// a safe caller. A safe caller must include the address of this account in the hash.
    function _erc1271IsValidSignatureViaSafeCaller(bytes32 hash, bytes calldata signature)
        internal
        view
        virtual
        returns (bool result)
    {
        if (_erc1271CallerIsSafe()) result = _erc1271IsValidSignatureNowCalldata(hash, signature);
    }

    /// @dev ERC1271 signature validation (Nested EIP-712 workflow).
    ///
    /// This uses ECDSA recovery by default (see: `_erc1271IsValidSignatureNowCalldata`).
    /// It also uses a nested EIP-712 approach to prevent signature replays when a single EOA
    /// owns multiple smart contract accounts,
    /// while still enabling wallet UIs (e.g. Metamask) to show the EIP-712 values.
    ///
    /// Crafted for phishing resistance, efficiency, flexibility.
    /// __________________________________________________________________________________________
    ///
    /// Glossary:
    ///
    /// - `APP_DOMAIN_SEPARATOR`: The domain separator of the `hash` passed in by the application.
    ///   Provided by the front end. Intended to be the domain separator of the contract
    ///   that will call `isValidSignature` on this account.
    ///
    /// - `ACCOUNT_DOMAIN_SEPARATOR`: The domain separator of this account.
    ///   See: `EIP712._domainSeparator()`.
    /// __________________________________________________________________________________________
    ///
    /// For the `TypedDataSign` workflow, the final hash will be:
    /// ```
    ///     keccak256(\x19\x01 ‖ APP_DOMAIN_SEPARATOR ‖
    ///         hashStruct(TypedDataSign({
    ///             contents: hashStruct(originalStruct),
    ///             name: keccak256(bytes(eip712Domain().name)),
    ///             version: keccak256(bytes(eip712Domain().version)),
    ///             chainId: eip712Domain().chainId,
    ///             verifyingContract: eip712Domain().verifyingContract,
    ///             salt: eip712Domain().salt,
    ///             extensions: keccak256(abi.encodePacked(eip712Domain().extensions))
    ///         }))
    ///     )
    /// ```
    /// where `‖` denotes the concatenation operator for bytes.
    /// The order of the fields is important: `contents` comes before `name`.
    ///
    /// The signature will be `r ‖ s ‖ v ‖
    ///     APP_DOMAIN_SEPARATOR ‖ contents ‖ contentsType ‖ uint16(contentsType.length)`,
    /// where `contents` is the bytes32 struct hash of the original struct.
    ///
    /// The `APP_DOMAIN_SEPARATOR` and `contents` will be used to verify if `hash` is indeed correct.
    /// __________________________________________________________________________________________
    ///
    /// For the `PersonalSign` workflow, the final hash will be:
    /// ```
    ///     keccak256(\x19\x01 ‖ ACCOUNT_DOMAIN_SEPARATOR ‖
    ///         hashStruct(PersonalSign({
    ///             prefixed: keccak256(bytes(\x19Ethereum Signed Message:\n ‖
    ///                 base10(bytes(someString).length) ‖ someString))
    ///         }))
    ///     )
    /// ```
    /// where `‖` denotes the concatenation operator for bytes.
    ///
    /// The `PersonalSign` type hash will be `keccak256("PersonalSign(bytes prefixed)")`.
    /// The signature will be `r ‖ s ‖ v`.
    /// __________________________________________________________________________________________
    ///
    /// For demo and typescript code, see:
    /// - https://github.com/junomonster/nested-eip-712
    /// - https://github.com/frangio/eip712-wrapper-for-eip1271
    ///
    /// Their nomenclature may differ from ours, although the high-level idea is similar.
    ///
    /// Of course, if you have control over the codebase of the wallet client(s) too,
    /// you can choose a more minimalistic signature scheme like
    /// `keccak256(abi.encode(address(this), hash))` instead of all these acrobatics.
    /// All these are just for widespread out-of-the-box compatibility with other wallet clients.
    /// We want to create bazaars, not walled castles.
    /// And we'll use push the Turing Completeness of the EVM to the limits to do so.
    function _erc1271IsValidSignatureViaNestedEIP712(bytes32 hash, bytes calldata signature)
        internal
        view
        virtual
        returns (bool result)
    {
        bytes32 t = _typedDataSignFields();
        /// @solidity memory-safe-assembly
        assembly {
            let m := mload(0x40) // Cache the free memory pointer.
            // `c` is `contentsType.length`, which is stored in the last 2 bytes of the signature.
            let c := shr(240, calldataload(add(signature.offset, sub(signature.length, 2))))
            for {} 1 {} {
                let l := add(0x42, c) // Total length of appended data (32 + 32 + c + 2).
                let o := add(signature.offset, sub(signature.length, l)) // Offset of appended data.
                mstore(0x00, 0x1901) // Store the "\x19\x01" prefix.
                calldatacopy(0x20, o, 0x40) // Copy the `APP_DOMAIN_SEPARATOR` and `contents` struct hash.
                // Use the `PersonalSign` workflow if the reconstructed hash doesn't match,
                // or if the appended data is invalid, i.e.
                // `appendedData.length > signature.length || contentsType.length == 0`.
                if or(xor(keccak256(0x1e, 0x42), hash), or(lt(signature.length, l), iszero(c))) {
                    t := 0 // Set `t` to 0, denoting that we need to `hash = _hashTypedData(hash)`.
                    mstore(t, _PERSONAL_SIGN_TYPEHASH)
                    mstore(0x20, hash) // Store the `prefixed`.
                    hash := keccak256(t, 0x40) // Compute the `PersonalSign` struct hash.
                    break
                }
                // Else, use the `TypedDataSign` workflow.
                // `TypedDataSign({ContentsName} contents,bytes1 fields,...){ContentsType}`.
                mstore(m, "TypedDataSign(") // Store the start of `TypedDataSign`'s type encoding.
                let p := add(m, 0x0e) // Advance 14 bytes to skip "TypedDataSign(".
                calldatacopy(p, add(o, 0x40), c) // Copy `contentsType` to extract `contentsName`.
                // `d & 1 == 1` means that `contentsName` is invalid.
                let d := shr(byte(0, mload(p)), 0x7fffffe000000000000010000000000) // Starts with `[a-z(]`.
                // Store the end sentinel '(', and advance `p` until we encounter a '(' byte.
                for { mstore(add(p, c), 40) } iszero(eq(byte(0, mload(p)), 40)) { p := add(p, 1) } {
                    d := or(shr(byte(0, mload(p)), 0x120100000001), d) // Has a byte in ", )\x00".
                }
                mstore(p, " contents,bytes1 fields,string n") // Store the rest of the encoding.
                mstore(add(p, 0x20), "ame,string version,uint256 chain")
                mstore(add(p, 0x40), "Id,address verifyingContract,byt")
                mstore(add(p, 0x60), "es32 salt,uint256[] extensions)")
                p := add(p, 0x7f)
                calldatacopy(p, add(o, 0x40), c) // Copy `contentsType`.
                // Fill in the missing fields of the `TypedDataSign`.
                calldatacopy(t, o, 0x40) // Copy the `contents` struct hash to `add(t, 0x20)`.
                mstore(t, keccak256(m, sub(add(p, c), m))) // Store `typedDataSignTypehash`.
                // The "\x19\x01" prefix is already at 0x00.
                // `APP_DOMAIN_SEPARATOR` is already at 0x20.
                mstore(0x40, keccak256(t, 0x120)) // `hashStruct(typedDataSign)`.
                // Compute the final hash, corrupted if `contentsName` is invalid.
                hash := keccak256(0x1e, add(0x42, and(1, d)))
                signature.length := sub(signature.length, l) // Truncate the signature.
                break
            }
            mstore(0x40, m) // Restore the free memory pointer.
        }
        if (t == bytes32(0)) hash = _hashTypedData(hash); // `PersonalSign` workflow.
        result = _erc1271IsValidSignatureNowCalldata(hash, signature);
    }

    /// @dev For use in `_erc1271IsValidSignatureViaNestedEIP712`,
    function _typedDataSignFields() private view returns (bytes32 m) {
        (
            bytes1 fields,
            string memory name,
            string memory version,
            uint256 chainId,
            address verifyingContract,
            bytes32 salt,
            uint256[] memory extensions
        ) = eip712Domain();
        /// @solidity memory-safe-assembly
        assembly {
            m := mload(0x40) // Grab the free memory pointer.
            mstore(0x40, add(m, 0x120)) // Allocate the memory.
            // Skip 2 words for the `typedDataSignTypehash` and `contents` struct hash.
            mstore(add(m, 0x40), shl(248, byte(0, fields)))
            mstore(add(m, 0x60), keccak256(add(name, 0x20), mload(name)))
            mstore(add(m, 0x80), keccak256(add(version, 0x20), mload(version)))
            mstore(add(m, 0xa0), chainId)
            mstore(add(m, 0xc0), shr(96, shl(96, verifyingContract)))
            mstore(add(m, 0xe0), salt)
            mstore(add(m, 0x100), keccak256(add(extensions, 0x20), shl(5, mload(extensions))))
        }
    }

    /// @dev Performs the signature validation without nested EIP-712 to allow for easy sign ins.
    /// This function must always return false or revert if called on-chain.
    function _erc1271IsValidSignatureViaRPC(bytes32 hash, bytes calldata signature)
        internal
        view
        virtual
        returns (bool result)
    {
        // Non-zero gasprice is a heuristic to check if a call is on-chain,
        // but we can't fully depend on it because it can be manipulated.
        // See: https://x.com/NoahCitron/status/1580359718341484544
        if (tx.gasprice == uint256(0)) {
            /// @solidity memory-safe-assembly
            assembly {
                mstore(gasprice(), gasprice())
                // See: https://gist.github.com/Vectorized/3c9b63524d57492b265454f62d895f71
                let b := 0x000000000000378eDCD5B5B0A24f5342d8C10485 // Basefee contract,
                pop(staticcall(0xffff, b, codesize(), gasprice(), gasprice(), 0x20))
                // If `gasprice < basefee`, the call cannot be on-chain, and we can skip the gas burn.
                if iszero(mload(gasprice())) {
                    let m := mload(0x40) // Cache the free memory pointer.
                    mstore(gasprice(), 0x1626ba7e) // `isValidSignature(bytes32,bytes)`.
                    mstore(0x20, b) // Recycle `b` to denote if we need to burn gas.
                    mstore(0x40, 0x40)
                    let gasToBurn := or(add(0xffff, gaslimit()), gaslimit())
                    // Burns gas computationally efficiently. Also, requires that `gas > gasToBurn`.
                    if or(eq(hash, b), lt(gas(), gasToBurn)) { invalid() }
                    // Make a call to this with `b`, efficiently burning the gas provided.
                    // No valid transaction can consume more than the gaslimit.
                    // See: https://ethereum.github.io/yellowpaper/paper.pdf
                    // Most RPCs perform calls with a gas budget greater than the gaslimit.
                    pop(staticcall(gasToBurn, address(), 0x1c, 0x64, gasprice(), gasprice()))
                    mstore(0x40, m) // Restore the free memory pointer.
                }
            }
            result = _erc1271IsValidSignatureNowCalldata(hash, signature);
        }
    }
}

Security Considerations

Rejecting invalid contentsTypeName

Current major implementations of eth_signTypedData do not sanitize the names of custom types.

A phishing website can craft a contentsTypeName with control characters to break out of the PersonalSign type encoding, resulting in the wallet client asking the user to sign an opaque hash.

Requiring on-chain sanitization of contentsTypeName will block this phishing attack vector.

Copyright

Copyright and related rights waived via CC0.

1 post - 1 participant

Read full topic

A recent discussion (June 2024) in the RollCall Telegram Group has yet again shown that a lack of standards around the processing status of an L2 transaction is confusing not only for users and developers (block explorers, wallets, smart contracts, chain analytics) but also for client teams themselves trying to understand what different statuses mean and what trust assumptions have been made for each status. Besides confusion, there are real security risks, especially for L2 bridges based on the processing status of an L2 transaction (finalized on the L2 but not on the L1 vs finalized on the L2 and the L1).

This topic of discussion also arose in the OASIS Ethereum Open Projects L2 Standards WG when discussing the L2 Transaction Fee API specification. The WG decided to make L2 Transaction Statuses their next work item.

To start the discussion, the WG decided to propose a simple set of statuses both as a string and as a hex value, their definitions and trust assumptions. The minimal set of transaction statuses proposed is as follows:

• L2 Pending: An L2 transaction submitted to an L2, and waiting to be processed by a sequencer. Trust Assumption: No inclusion guarantee on the L2
• L2 Replaced: An L2 transaction that was “Pending” was replaced by another L2 transaction. Trust Assumption: Same as L2 Pending
• L2 Dropped: An L2 transaction that was removed from the L2 processing queue. Trust Assumption: NA
• L2 Confirmed: An L2 transaction processed by a sequencer and assigned an order in a proposed L2 block by the sequencer by applying an L2 client-specific L2 transaction ordering protocol. Trust Assumption: The L2 transaction order guarantee is based on the security guarantee of the ordering protocol. Inclusion in finalized L2 and L1 blocks is not guaranteed.
• L2 Included, L1 Pending: An L2 transaction included in an L2 block but not yet submitted to the L1. Trust Assumption: The L2 inclusion guarantee is dependent on the submission guarantee of the L2 block to the L1 and L1 Finalization.
• L2 Included, L1 Included: An L2 transaction included in an L2 block submitted to the L1. Trust Assumption: The L2 inclusion guarantee is dependent on L1 finalization.
• L2 Finalized, L1 Finalized: An L2 transaction included in a L2 block that has been included in a finalized L1 transaction. Trust Assumption: The L2 transaction finalization guarantee is equivalent to an L1 transaction finalization guarantee in a finalized L1 block.

11 posts - 7 participants

Read full topic

Discussion topic for EIP-7738

This is the discussion on a draft EIP for an onchain script registry.

Abstract

This EIP provides a means to create a standard registry for locating executable scripts associated with contracts.

Motivation

ERC-5169 (scriptURI) provides a client script lookup method for contracts. This requires the contract to have implemented the ERC-5169 interface at the time of construction (or allow an upgrade path).

This proposal outlines a contract that can supply prototype and certified scripts. The contract would be a singleton instance multichain that would be deployed at identical addresses on supported chains.

Overview

The registry contract will supply a set of URI links for a given contract address. These URI links point to script programs that can be fetched by a wallet, viewer or mini-dapp.

The pointers can be set using a setter in the registry contract.

The scripts provided could be authenticated in various ways:

1. The target contract which the setter specifies implements the Ownable interface. Once the script is fetched, the signature can be verified to match the Owner(). In the case of TokenScript this can be checked by a dapp or wallet using the TokenScript SDK, the TokenScript online verification service, or by extracting the signature from the XML, taking a keccak256 of the script and ecrecover the signing key address.
2. If the contract does not implement Ownable, further steps can be taken:
   a. The hosting app/wallet can acertain the deployment key using 3rd party API or block explorer. The implementing wallet, dapp or viewer would then check the signature matches this deployment key.
   b. Signing keys could be pre-authenticated by a hosting app, using an embedded keychain.
   c. A governance token could allow a script council to authenticate requests to set and validate keys.

If these criteria are not met:

• For mainnet implementations the implementing wallet should be cautious about using the script - it would be at the app and/or user’s discretion.
• For testnets, it is acceptable to allow the script to function, at the discretion of the wallet provider.

Specification

The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY” and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

The contract MUST implement the IDecentralisedRegistry interface.
The contract MUST emit the ScriptUpdate event when the script is updated.
The contract SHOULD order the scriptURI returned so that the owner script is returned first (in the case of simple implementations the wallet will pick the first scriptURI returned).

interface IDecentralisedRegistry {
    /// @dev This event emits when the scriptURI is updated, 
    /// so wallets implementing this interface can update a cached script
    event ScriptUpdate(address indexed contractAddress, string[] newScriptURI);

    /// @notice Get the scriptURI for the contract
    /// @return The scriptURI
    function scriptURI(address contractAddress) external view returns (string[] memory);

    /// @notice Update the scriptURI 
    /// emits event ScriptUpdate(address indexed contractAddress, scriptURI memory newScriptURI);
    function setScriptURI(address contractAddress, string[] memory scriptURIList) external;
}

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Rationale

This method allows contracts written without the ERC-5169 interface to associate scripts with themselves, and avoids the need for a centralised online server, with subsequent need for security and the requires an organisation to become a gatekeeper for the database.

Reference Implementation

import "@openzeppelin/contracts/access/Ownable.sol";

contract DecentralisedRegistry is IDecentralisedRegistry {
    struct ScriptEntry {
        mapping(address => string[]) scriptURIs;
        address[] addrList;
    }

    mapping(address => ScriptEntry) private _scriptURIs;

    function setScriptURI(
        address contractAddress,
        string[] memory scriptURIList
    ) public {
        require (scriptURIList.length > 0, "> 0 entries required in scriptURIList");
        bool isOwnerOrExistingEntry = Ownable(contractAddress).owner() == msg.sender 
            || _scriptURIs[contractAddress].scriptURIs[msg.sender].length > 0;
        _scriptURIs[contractAddress].scriptURIs[msg.sender] = scriptURIList;
        if (!isOwnerOrExistingEntry) {
            _scriptURIs[contractAddress].addrList.push(msg.sender);
        }
        
        emit ScriptUpdate(contractAddress, msg.sender, scriptURIList);
    }

    // Return the list of scriptURI for this contract.
    // Order the return list so `Owner()` assigned scripts are first in the list
    function scriptURI(
        address contractAddress
    ) public view returns (string[] memory) {
        //build scriptURI return list, owner first
        address contractOwner = Ownable(contractAddress).owner();
        address[] memory addrList = _scriptURIs[contractAddress].addrList;
        uint256 i;

        //now calculate list length
        uint256 listLen = _scriptURIs[contractAddress].scriptURIs[contractOwner].length;
        for (i = 0; i < addrList.length; i++) {
            listLen += _scriptURIs[contractAddress].scriptURIs[addrList[i]].length;
        }

        string[] memory ownerScripts = new string[](listLen);
        uint256 scriptIndex = 0;

        // Add owner strings
        for (i = 0; i < _scriptURIs[contractAddress].scriptURIs[contractOwner].length; i++) {
            ownerScripts[scriptIndex++] = _scriptURIs[contractAddress].scriptURIs[contractOwner][i];
        }

        // remainder
        for (i = 0; i < addrList.length; i++) {
            for (uint256 j = 0; j < _scriptURIs[contractAddress].scriptURIs[addrList[i]].length; j++) {
                string memory thisScriptURI = _scriptURIs[contractAddress].scriptURIs[addrList[i]][j];
                if (bytes(thisScriptURI).length > 0) {
                    ownerScripts[scriptIndex++] = thisScriptURI;
                }
            }
        }

        //fill remainder of any removed strings
        for (i = scriptIndex; i < listLen; i++) {
            ownerScripts[scriptIndex++] = "";
        }

        return ownerScripts;
    }
}

2 posts - 2 participants

Read full topic

Currently, there is no clear, common language to specify vulnerabilities in crypto. Ethical hackers often refer to vulnerabilities using a combination of “Protocol Name + Exploit,” which can be very confusing, especially when multiple attacks occur on the same protocol.

To reduce communication costs between protocol developers and ethical hackers and build on the security practices of Web2, we propose the VE (Vulnerability and Exposure) identifier. This EIP allows any organization or individual to maintain its own VE on-chain, standardizing the language used to describe and report vulnerabilities.

1 post - 1 participant

Read full topic

Discussion for Add ERC: Simple Permissions Checks #435

1 post - 1 participant

Read full topic

Agenda

PeerDAS Breakout Room #3 · Issue #1093 · ethereum/pm · GitHub

Moderator: @hwwang

Key items

by @hwwang (from Eth R&D Discord):

• devnet-1 has many forks that would be hard to recover. See the meeting notes for the issues)
• ACTION: relaunch devnet-2 by the end of the week with all the client fixes.
• Please review “Decouple network subnets from das-core” PR (a potential devnet-3 update): EIP-7594: Decouple network subnets from das-core by ppopth · Pull Request #3832 · ethereum/consensus-specs · GitHub
• Teams want to include Specify the max blobs per block with each payload by ralexstokes · Pull Request #3800 · ethereum/consensus-specs · GitHub into Pectra so that PeerDAS can be a pure network update (not hard fork).

Notes & chat log

Recording

PeerDAS Breakout Room #3

1 post - 1 participant

Read full topic

Agenda

Consensus-layer Call 137 · Issue #1096 · ethereum/pm · GitHub

Moderator: @ralexstokes

Summary

ACDC #137 recap by @ralexstokes (from Eth R&D Discord)
Shorter call today!

We began with Pectra:

• CL clients are generally ready for pectra-devnet-1
• CL clients working well with static test vectors
• Given a few EL clients are ready, we should launch pectra-devnet-1 as soon as possible, aiming for sometime next week

Then, turned to PeerDAS:

• peerdas-devnet-1 launched but surfaced a number of client bugs which are being resolved
• Expect a peerdas-devnet-2 soon as client teams continue to iterate on scaling blob bandwidth
• I gave an update on the work to uncouple the blob max and target values between the consensus and execution layers
  • After reviewing the syncing semantics, it appears the check for the blob maximum on the EL is redundant and we can safely drop that check and have it done solely at the CL
  • We also want the same uncoupling treatment for the blob target so this value will be driven by the CL but needs to be included in the EL block header for the security of client sync
  • Expect updates to this PR on the CL and an EIP for the 4844 changes soon™!

Wrapped the call with an update on some work to expand the fork choice testing

• Presentation from TXRX research here: FC compliance test suite on ACDC - Google Slides
• This work introduces tooling to expand the scope of the fork choice test suite for static coverage in clients
• Uses a constraint-driven programming language to generate interesting test cases which extend the static test corpus CL clients use for conformance testing
• CTA: CL teams please take a look and incorporate into your client for enhanced coverage

See you next time!

Recording

Transcript

[To be added]

Additional info

Notes by @Christine_dkim: Ethereum All Core Developers Consensus Call #137 Writeup | Galaxy

1 post - 1 participant

Read full topic

This proposal relies on the structure of verkle trees to implement state expiry. A counter is maintained at the extension node level, and only extention-and-suffix nodes (colloquially referred to as “leaves”) are deleted.

Proposal at: Add EIP: Leaf-level state expiry in verkle trees by gballet · Pull Request #8724 · ethereum/EIPs · GitHub

2 posts - 2 participants

Read full topic

After EIP-6780, the SELFDESTRUCT instruction was neutered, so that contracts could no longer be deleted. Contract deletions can still occur, however, via EIP-158. While EIP-7702 this can not happen, this latter EIP introduces the possibility for an empty EoA to have state. This is causing some issues when interfacing with verkle, for which state deletion is not possible.

EIP-158 was meant as a temporary measure to combat the “Shanghai attacks”. Now that this is attack has been mitigated by other means, it can be deactivated.

Note: The deactivation should happen in Prague, for alternative methods to EIP-7612 to be valid. If EIP-7612 is accepted, then nothing opposes its inclusion in Osaka instead.

PR URL: Add EIP: Deactivate EIP-158 by gballet · Pull Request #8712 · ethereum/EIPs · GitHub

2 posts - 2 participants

Read full topic

Agenda

ePBS Breakout room #4 · Issue #1083 · ethereum/pm · GitHub
2024-07-05T14:00:00Z UTC

Moderator: @potuz

Notes

ePBS breakout #4 notes - HackMD

Recording

https://www.youtube.com/watch?v=WC9XsungamU

Additional info

1 post - 1 participant

Read full topic

Agenda

Verkle Implementers Call #20 · Issue #1089 · ethereum/pm · GitHub
2024-07-01T13:00:00Z UTC

Moderator: @rudolf

Notes

Notes by @rudolf from X

1. Team updates

Starting things off as usual with quick updates from the client teams:

@jasoriatanishq for @nethermindeth: continuing testing the verkle sync implementation. Last week implemented the healing part. Anyone can now join the testnet using verkle sync.

@gballet & @ignaciohagopian for @go_ethereum: did a lot of work on the spec. Started implementation of EIP-4762. Still need to re-run the testing framework after it’s complete. Have also spent some time doing a new analysis of Verkle gas cost / code chunking using more recent mainnet transactions. Will be able to share this analysis soon.

@kt2am1990 for @HyperledgerBesu: working on the flat DB refactor for Verkle. Also looking at how we can optimize to reduce the size of the db. Also some performance optimizations around preloading the trie node during block processing, so at the end of the block when have to compute the state root everything is already in memory.

@techbro_ccoli for the testing team: we now have a successful test framework, and our first release is out. These are the simplest form of the transition tests (mid fork) where the test block starts on the fork transition block. For next steps: filling the “genesis test” (starting at the verkle fork) as opposed to during transition.

2. EIP-7709 and EIP-2935 updates

There’s been a bit of pushback on how Verkle handles blockhash, and suggestion that we should copy the behavior of 4788. Going forward, EIP-2935 will behave the same way as 4788.

@gballet has opened a PR: https://github.com/ethereum/EIPs/pull/8698….

3. Testnet

For next testnet: we had a quick discussion on whether it should include deactivating EIP-158. There was no opposition to this on the call. Will also likely be some discussion around this topic of deactivating EIP-158 on this week’s ACD.

4. The transition & preimage distribution

Gary from Besu team joined to share recent ideas and questions around the transition (migrating state from Merkle to Verkle) and preimage distribution.

Guillaume and Gary discussed that during the actual transition (which could take a month or more), clients will not be able to snap sync to latest. Only full sync will be possible. For a client syncing from scratch: they would do a snap sync up to the last Merkle Patricia Tree block, and then do a full sync from there. This seems like a reasonable approach since it would only take 2 hours or so to do a full sync in this case.

On the topic of preimage distribution and including the preimage keys in the execution witness: @kt2am1990 mentioned that if we can have the address/slot we are touching in each transaction, it might enable some parallelization when we want to import the block. Guillaume will be adding this in next round of spec updates. So we’ll know which are being touched in the tx. One potential downside though is that it will make the witness much larger. Guillaume to make the spec update and then continue discussion on this topic.

5. Cost of extcodehash/extcodesize in EOF

Last up, there was some discussion around a few things where EOF differs from legacy code and potentially adds cost: extcodehash, extcodesize, delegatecall. For each of these 3: in addition to reading the code hash you also need to check this is an EOF format. So the question is can we put it directly in the header to avoid this?

@shemnon suggested this is a great use case for a flag. If the EOF flag is set, then extcodesize and extcodehash will go down the separate EOF path to signal its EOF code versus an empty account. Importantly this flag would avoid the need to read an extra chunk which would incur extra cost. If the flag is there, then don’t need to read the chunk.

That’s it for this week’s call…
Check out http://verkle.info or head over to the Eth R&D Discord (verkle-trie-migration channel) to stay up-to-date !

Recording

https://www.youtube.com/watch?v=L873Z5K6XZQ

1 post - 1 participant

Read full topic

0. TL;DR

We introduced and detailed the additional features of FM-AMM, as presented in [CF23]. We modeled the game between CEX-DEX arbitrageurs for arbitrage profit on FM-AMM and then solved it by finding the pure strategy Nash equilibrium. Lastly, we calculated the asymptotic LVR of FM-AMM in theoretical settings and compared its performance against the Uniswap V2-style fixed-rate fee CPMM through numerical simulations. Our observations indicated that the performance is heavily influenced by price volatility, transaction costs, and the size of the liquidity pool, with FM-AMM showing a reduced loss to arbitrageurs under specific conditions.

1. Introduction

Since LVR was introduced in [MMRZ22] and [MMR23], it has quickly become the standard for measuring the performance of AMMs. Numerous attempts have been made to reduce LVR through dynamic fee policies, and this research continues actively. However, batch trade execution has not received much attention, except in [CF23] and [GGMR22]. In [CF23], the authors proposed a function-maximizing automated market maker (FM-AMM), asserting it effectively eliminates LVR, and provided numerical simulations comparing its performance with various Uniswap V3 pools. They later claimed that CoW-AMM (their implementation of FM-AMM) performed well in live settings too, which led to debate on Twitter regarding the legitimacy of their measurement methods. Although the debate focused more on whether markout is a useful metric for measuring performance, the existence of retail order flow and fluctuating transaction costs are also obstacles to precisely comparing their performance. In this article, we analyze the performance of FM-AMM and compare it to CPMM under fixed transaction costs and in the absence of retail order flow conditions like those in [N22] and [E24].

In detail, we slightly modified their design and found a Nash equilibrium in a game where arbitrageurs strategically submit orders to the (slightly modified) FM-AMM to maximize their returns. The game is similar to the liquidity provision game introduced in [MC24], which is a special form of the generalized Tullock contest. The resulting equilibrium has many favorable properties: the solution always uniquely exists, and it is symmetric. Moreover, LVR decays inversely proportionally to the number of participants. This model assumes that the number of arbitrageurs, N, is pre-determined and transaction cost, c, is zero. We proceed to a model where the number of participants is determined endogenously according to c. In this setting, FM-AMM is not always superior; the result now depends on jump size, frequency, and cost. We provide numerical simulation results and suggest that FM-AMM fits well with rollup-based solutions.

2. FM-AMM

In this section we fill the omitted details of FM-AMM introduced in [CF23] to handle the more general case. The underlying AMM curve introduced in [CF23] is:

where x_\text{in} is the amount of token X the trader is willing to sell, and y_\text{in} is the amount of token Y that she will receive. However, this is the simplest case where only a single side of order is submitted in batch. Authors of original paper handled the case such that both side of orders exist in the same batch by assuming users only specify the amount of token X to buy or sell. Unfortunately, this is hard to implement in fully on-chain manner since whether the trader has enough capital to buy specified amount of token X is not guaranteed before the batch is settled (Selling is not problematic; we can pull the token from trader and keep it by settlement). We generalize the formula to handle broader range of cases. Let X, Y be reserves of pool, T be total supply of LP tokens before batch settlement, x_\text{in}, y_\text{in} be aggregate amount of each token that traders are willing to sell, and x_\text{mint}, y_\text{mint} be aggregate amount of each token provided from LPs. The fundamental equation we will start with is:

Here, the p is the clearing price, and \alpha, \beta are the net swap amount for swapping and minting, respectively. In short, among the submitted orders, we swap only part of them, \alpha and \beta, then exchange the rest via p2p without changing the spot price. The fact that

are all parallel gives us following matrix equation:

Note that the determinant of matrix in LHS is always strictly positive so above equation is not singular. \alpha, \beta are:

The clearing price, p_c, is:

x_\text{out}, y_\text{out} are:

It is straight forward to find x_2, y_2, the reserves after minting LP tokens, and t, the newly issued LP token amount, so we would skip on them here.

Above construction charges no fee. To keep price same even after charging fee, we will take 1/(1 + \gamma) portion of input and \gamma portion of output as fee. So the effective fee rate will be \frac{2 \gamma}{1+ \gamma}, which is approximately 2 \gamma. Considering arbitrageurs it may better to take fee fully on input, though.

3. Model

In this section, we describe the model upon which our analysis is based. We model a normal form game involving strategic arbitrageurs. This means that each player is unaware of the bids of others, and all bids are submitted simultaneously. Additionally, each player’s bid is never censored. Although this assumption does not perfectly reflect the current state of blockchains, ongoing cryptographic developments and improved market designs, such as inclusion lists, will help bridge the gap between theory and reality. This formulation is almost the same as that of [CM24]; the only difference is that players now “take” mispriced liquidity instead of providing it to the AMM.

3.1. Automated Market Maker

For the AMM, we will use the FM-AMM introduced in Section 2. Note that the AMM itself is not a player; we assume that the LPs of the AMM are passive investors who will not take any action in the short term.

3.2. Arbitrageurs

We assume that all players are homogeneous. They are risk-neutral and can execute trades of any size and in any direction on CEX without any slippage. Their sole goal is to maximize profit.

3.3. Strategic Game of Liquidity Taking

First, we solve the game with N players where N is given exogenously, without considering transaction costs. Then, we introduce a strictly positive transaction cost c and derive N from the equilibrium condition. We will restrict our interest to conditions with positive trading fees, which guarantees the uniqueness of the equilibrium. Players observe the pool reserves X, Y, and the external true price P. Then, they submit bids (x_i, y_i), which are the amounts of tokens to sell to the pool. The clearing price will be:

The utility function is the arbitrage profit after charging the swap fee (and transaction cost, if applicable). The utility of player i, U_i, is:

Now, we are ready to find the equilibrium.

4. Equilibrium Analysis

4.1. N is Determined Exogenously, and Transaction Cost c is Zero

We first introduce the following lemma:

The proof is straightforward. Assume (x_i, y_i) and (x'_i, y'_i) result in the same clearing price. Then x_i \leq x'_i if and only if y_i \leq y'_i. Combining these and subtracting the utility of one from the other yields the desired result.

Meanwhile, the first order condition and the profitability condition give us that the best response is, when P_{-i} is defined as P_{-i} = \frac{Y + 2\sum^N_{j \neq i} y_j }{X + 2\sum^N_{j \neq i} x_j}, submitting x_i or y_i such that the following holds:

Otherwise, it is better not to submit any order (i.e., bid). One can think of \frac{1+\gamma}{1-\gamma}P_{-i} and \frac{1-\gamma}{1+ \gamma}P_{-i} as the threshold prices such that arbitrage becomes profitable. Note that this holds for every i, so P_{-i} = P_{-j} for every i and j, which tells us the equilibrium is symmetric and always exists.

From now on, we only consider the external price to be sufficiently higher than the pool’s spot price, Y/X. The opposite case can be solved in a similar manner. It is clear that x_\text{eq} = 0 for the case we are dealing with. Then, (3) is equivalent to:

Solving (4) yields that

From now on, we will proceed with radical approximations due to its complexity. Although we do not provide any rigorous proof for the validity of such approximations, we will see it works well in the simulations later. Let P_0 = \frac{Y}{X} and \varepsilon = \frac{1-\gamma}{1+\gamma} \cdot \frac{P}{P_0} - 1, that is, the price difference between the threshold price and the external price. Approximating y_\text{eq} with \varepsilon through a Taylor series gives us a simpler form:

Using (7), one can compute the profit of individual arbitrageurs and the total loss of the AMM against arbitrageurs:

Thus, assuming the transaction cost is 0, for any N, every N arbitrageur will submit identical bids and they will share the profit equally, while each individual arbitrageur’s profit will decay by O(N^{-2}). Moreover, as N goes to infinity the clearing price P_c converges to threshold price, and therefore the stationary distribution of price discrepancy will be as same as that of fixed fee rate CPMM in [MMR23].

4.2. Transaction Cost is Not Free, and the Number of Arbitrageurs is Determined Endogenously

Now we extend the model in 4.1 to a more realistic one by adopting a nonzero transaction cost c. The utility function remains the same as in (2), except we have an additional term -c. Since this term disappears when we take the derivative, the best response remains the same as long as it is profitable. Thus, the solution is not much different from (7), except N is replaced with N^{*}, where N^{*} is the largest integer that satisfies L\sqrt{P_0}\cdot\left(\frac{1+\gamma}{2(N^{*}+1)^2}\right)\cdot\varepsilon^2 \geq c. Then, the LVR will be:

4.3. Comparison with CPMM

The derivation of the LVR for CPMM has already been studied extensively, so we will simply present the result:

where \gamma is the fee rate taken from the input and \varepsilon is again the price difference between the external price and the threshold price, in this case, \frac{P_0}{1-\gamma}. In short, the LVR of CPMM grows faster than that of FM-AMM as \varepsilon (the price difference) and L\sqrt{P_0} (the initial pool size) grow. From this, we can predict that the performance of FM-AMM will be better in larger pools compared to CPMM.

FM-AMM performance is affected by the transaction cost c, while CPMM is not affected as long as the arbitrageur’s profit is greater than c. This implies that FM-AMM suits well with rollup settings that have longer block times (resulting in higher volatility between blocks) and low transaction costs.

5. Simulations

Due to the nonzero transaction cost, finding an analytic solution for instantaneous LVR or the stationary distribution of price discrepancy is no longer straightforward. Therefore, we proceed with numerical simulations. You can check the code used here. This code is largely copy-pasted with minor tweaks from this source. Swap fees are fixed at 0.3% across all simulations (i.e., \gamma_\text{FMAMM} = 0.0015, \gamma_\text{CPMM} = 0.003).

5.1. Distribution of LVR

In this section, we observe the distribution of LVR under several cases without iterating over many parameters. Note that the variance is always greater in FM-AMM; this is because the price is not corrected perfectly under the nonzero transaction cost condition.

The conditions of the first case are L1 (12-second block time), $10 transaction cost, with 5% daily volatility and $100M pool size.

The second is L1, $10 transaction cost, with 10% volatility and $100M pool size.

As predicted, FM-AMM outperforms CPMM as volatility increases.

Next one is L1 with congestion; transaction cost went up to $30.

This fits to our prediction well, too. As tx cost increases FM-AMM loses more than CPMM.

The last result is L1 with congestion, but with smaller liquidity ($10M).

This result is a bit contradictory to our initial guess: usually, smaller liquidity conditions are more favorable to CPMM, as LVR per pool value of FM-AMM increases as the pool value gets smaller. To clarify this, we will run simulations over various parameters and compare the performances.

5.2. Performance Comparisons

Below are the numerical simulations of LVR for CPMM and FM-AMM under various parameters. Swap fees are set at 0.3% for both of them. Blue regions indicate where CPMM performs better, while grey regions indicate where FM-AMM performs better. Note that the results in the low volatility and high-cost regions are not as reliable due to the very few trades occurring in these conditions.

First is the cases for L1:

Following are the special cases for based rollup (tx cost = $0.05, block time = 12 sec) and typical L2s (tx cost = 0.01, block time = 2 sec), respectively:

5.3. Discussion

It is clear that FM-AMM performs better under certain conditions, including L2s and L1 with low transaction costs, and this partially explains why the results in [CF23] was rather mixed and defer by each pair. Due to its nature of forcing competition over price between arbitrageurs, it performs well even in high volatility conditions. Notably, this is achieved without raising the swap fee, which typically results in losing retail order flow. Thus, FM-AMM can lose less to arbitrageurs while not sacrificing retail order flow.

6. Conclusion

As the authors of [CF23] claimed, FM-AMM indeed achieves superior performance under certain conditions, even without raising swap fees. It suits L2s particularly well. However, our analysis is based on several non-realistic assumptions, especially the (short-term) censorship resistance assumption and simultaneous bid submission. Future research will focus on more relaxed conditions to provide a more comprehensive evaluation.

7. References

[MMRZ22] J. Milionis, C. C. Moallemi, T. Roughgarden, and A. L. Zhang. Automated Market Making and Loss-Versus-Rebalancing, arXiv preprint arXiv:2208.06046, 2022.
[MMR23] J. Milionis, C. C. Moallemi, and T. Roughgarden. Automated Market Making and Arbitrage Profits in the Presence of Fees, arXiv preprint arXiv:2305.14604, 2023.
[GGMR22] G. Ramseyer, M. Goyal, A. Goel, and D. Mazières. Augmenting Batch Exchanges with Constant Function Market Makers, arXiv preprint arXiv:2210.04929, 2022.
[CF23] A. Canidio and A. Fritsch. Arbitrageurs’ profits, LVR, and sandwich attacks: batch trading as an AMM design response, arXiv preprint arXiv:2307.02074, 2023.
[CM24] D. Crapis and J. Ma. The Cost of Permissionless Liquidity Provision in Automated Market Makers, arXiv preprint arXiv:2402.18256, 2024.
[N22] A. Nezlobin. Ethereum Block Times, MEV, and LP returns, Medium article Ethereum Block Times, MEV, and LP returns, 2022
[E24] A. Elsts. CEX/DEX arbitrage, transaction fees, block times, and LP profits, Ethresearch Forum article CEX/DEX arbitrage, transaction fees, block times, and LP profits, 2024

1 post - 1 participant

Read full topic

APS-burn in the context of a Decentralized L2

Overview

We propose a design for Attester-Proposer-Separation that is tailored for the context of a decentralized L2. This design is intended to operate in the context of an L2 with its own validator set, running some sort of BFT consensus protocol, with single slot finality.

This design is based on the APS-burn design from @barnabe, but with some notable differences. It assumes that there are short block times, preferably one second, and no longer than 2 seconds, and that each block is final within the scope of the canonical L2 chain (prior to being finalized on L1) . This design aims to obtain the benefits of APS in an L2 context, while aiming to mitigate censorship, and mitigate the negative externalities of multi-block MEV. These properties are achieved using a sealed-bid auction, similar in principle to the Sealed execution auction proposal from Anders, but in an L2 context.

To understand the motivation behind this design, as well as its trade-offs, see the “benefits” and “risks” sections below.

DO NOT read this post if:

• You are trying to keep up with the important developments in Ethereum and attempting to determine which posts are important and which aren’t. This post is intended for soliciting early feedback on a design that is specific to decentralized rollups, and is not a finalized proposal.

DO read this post if:

• You are trying to decentralize a rollup, and are considering adopting an PoS consensus protocol, and are interested in exploring ideas within the design space.

Related Reading

• More pictures about proposers and builders - Barnabé Monnot
• Censorship Resistance in On-Chain Auctions - Elijah Fox, Mallesh Pai, Max Resnick
• Sealed execution auction - Anders Elowsson
• On block-space distribution mechanisms - Mike Neuder
• Block vs. Slot Auction PBS - Julian Ma
  

MEV Burn related reading:

• MEV burn—a simple design
• The price is right: Realigning proposer-builder incentives with predictive MEV-burn
• Dr. changestuff or: how i learned to stop worrying and love mev-burn
• In a post MEV-Burn world - Some simulations and stats

Description

We propose a method whereby the right to propose a future block is obtained via an on-chain auction.

For every slot n, the auction for block proposal rights starts at slot n - t and runs for k slots. The auction closes at slot (n - t) + k. During the period between n - t and (n - t) + k, bids are submitted to an on-chain smart contract. Each bid specifies an amount of some defined token that will be burned as part of the block that will be proposed at slot n. The winning bid is the bid that burns the most tokens.

During the auction between slot n - t and (n - t) + k, bids are posted on-chain as sealed commitments. After the auction closes at slot k, there is a buffer period of b blocks in which no new bids are accepted by the smart contract for slot n. After this buffer period, and up to slot n, bidders post their opened commitments, which reveal the amount they are bidding. The block that is proposed to the network at slot n, must be from the same address specified in the highest bid in the auction for slot n, and also burn the amount of tokens specified in the bid.

Each bid is composed of the height of the slot being bidded on, the address that will propose the block, and an amount of MEV that will be burned in the block.

Mitigating multi-block MEV

By incorporating a sealed bid auction, we can mitigate concerns around multi-block MEV. One of the main concerns with various APS designs is that it allows bidders to bid on block proposal rights for a contiguous segment of slots. If a bidder knows that they have the rights to slot n, then they can bid higher than anyone else for slot n+1, because they know that they can employ lucrative multi-block MEV strategies such as censoring price oracle updates or censoring sell orders on a trading pair to drive up the price etc.

In order to mitigate this concern, it is imperative that the bidders have no guarantee of having won the auction for slot n while the auction for slot n+1 is open.

As an illustrative example, consider the following instantiation where bidders bid for the right to propose a block 12 slots in the future (t = 12), and they have 4 slots in which to submit bids (k = 4), followed by a buffer phase in which the on-chain auction will not accept bids (b = 2) followed by the reveal phase.

As you can see from the following visualization, is we assume that all bids for the slot n auction are revealed at slot (n - t) + k + b then the bidder for slot n only finds out that they have won block proposal rights for slot n after the auction for slot n+1 and slot n+2 have already closed.

Censorship

Censorship is a concern with any on-chain auction (ref: Censorship Resistance in On-Chain Auctions). Obviously block builders are highly incentivized to censor any transactions to the on-chain auction that that carry bids that aren’t their own, which means that the only bids that will make it to the on-chain contract are from block builders that already have proposal rights to slots, as these builders will likely only include their own transactions to the auction contract.

The only way to fully mitigate censorship is through some form of inclusion lists, or a design that facilitates multiple concurrent block proposers. We propose that this sort of mechanism is an integral part of this design, but the exact details of the mechanism employed are out of scope for this piece.

However, even without an inclusion list / MCP mechanism, censorship of auction transactions becomes prohibitively expensive quite quickly. This is because every transaction that is censored has associated transaction fees that can be collected by some other block builder, which they can use to increase their bids with. The censoring block builder will therefore incur a competitive disadvantage for every bid they censor. Moreover, the censoring block builder will incur the cost of each bid they censor for every block they propose, resulting in a linear increase in cost over time. In other words, If n blocks are proposed, and k transactions are censored per block, the total cost incurred by the censoring block builder becomes:

CoC=n\times\sum_{i=1}^{k}C_{i}

Collateralization and Penalties

This design requires that bidders are collateralized in order to submit bids, and that this collateral is slashed under certain circumstances:

• If bid commitments are not revealed, this can incur penalties. The reason for this is to prevent bidders from submitting multiple bids and then just revealing them conditionally based on what other bidders reveal (as detailed in this paper - h/t @quintuskilbourn for this). Obviously censorship resistance is important in order to prevent these penalties from being used for griefing attacks.
• If the winner of an auction for slot n, does not propose a block for slot n, they are slashed.
• If the winner of an auction for slot n, equivocates and proposes more than one block for slot n, they are slashed.
• If the proposed block is valid, and is from the auction winner, but does not burn the amount of MEV that was stipulated in the winning bid, the collateral is slashed.

There are two ways to approach collateralization:

1 | Per-Bidder-Collateralization

This requires that a block builders / bidders posts some collateral on-chain, and that this will be subject to slashing conditions. Once the collateral is posted, the bidder can participate in any number of auctions and submit any number of bids. The collateral can be withdrawn at any stage, but is subject to some defined delay period.

2 | Per-Bid-Bonding

Bidders do not need to be collateralized, but each individual bid will require a bond. In the case of the winning bid, the bond is returned when the block for the slot is delivered. In the case of not winning the bid, the bond is returned only if the bid commitment was revealed.

As a side note: per-bid-bonding can also potentially be used to prevent bids being revealed earlier through some side-channel, by allowing anyone to cancel their bid before the auction closes and withdraw their bond if they reveal the pre-image. Once the auction is closed, then only the original bidder can withdraw the bond.

There are subtle trade-offs between the two approaches:

• Per-bid-bonding could potentially be more centralizing, as it favors better capitalized bidders. With a slot n+t auction with a per-bid bond of S, then bidders will need t \times S to participate in every auction.

• On the other hand, this potentially improves censorship resistance to a degree, as the same bidder can bid from different addresses, reducing the scope for targeted censorship of specific rival block builders.

Preventing bids from being revealed early

It’s not entirely clear what the incentives would be for bidders to reveal their bids early, but the effect of revealing bids early will undermine the value of a sealed-bid auction, and will allow for multi-block MEV strategies to be employed. We can imagine a scenario whereby somebody constructs a mechanism employing ZKPs to allow bidders to reveal their bids, in order to understand if their bid is lower than another bid, which would give them the option to bid higher. This could be a useful tool for participants in the auction.

To mitigate against the risks of bidders revealing their bids early, it should be impossible, or very hard, to prove what the bid was. There are a number of ways of accomplishing this:

Using threshold encryption

The validators will use distributed-key-generation (DKG) to create a threshold encryption key, which is part of the headers for every block. The BFT round leader will also be responsible for collecting the keys from validators, posting the encryption key, and also gossipping the decryption key at the right time, so that it can also be included in the block headers. This will allow bidders to encrypt their bids when they are posted on-chain. It will also allow them to decrypt their bids locally to ascertain if they have won the block proposal rights for slot n. At this stage it should be deterministically known to all parties who have won the slot n auction.

Upon receiving a new block for slot n, validators will examine the amount of MEV burned in the block as well as the address of the proposer. They will take these two pieces of data and encrypt them using the threshold encryption key for the auction for slot n. If there is a bid that exactly matches the ciphertext, and that bid is from the proposer that is proposing the block, and is correctly collateralized, and most importantly, if there is no higher bid in the auction, then that block is accepted. This construction can be strengthened by imposing slashing conditions on entities that propose blocks that do not have a winning bid associated with it.

The benefit of this approach is that it precludes any possibility of revealing bids early, assuming an honest majority of validators. However, it does add some extra complexity to the consensus layer, as well as the overhead of establishing clear and reliable public transmission of threshold encryption keys.

Using a Verifiable Delay Function

In order to reveal a commitment, the smart contract must verify an accompanying Verifiable Delay Function (VDF) proof. The VDF ensures that any bid must take at least d seconds to produce a proof for. While there is nothing to stop bidders revealing their bids, it makes it difficult for bidders to prove what they bid, as the proof will take approximately d seconds to produce.

There are multiple VDF schemes that can be employed. Such a scheme was proposed by Nomadic Labs (see Timed Commitments Revisited).

Note that in this scheme, the commit binding is deterministic, so not completely resilient to revealing bids. In the specific scheme, if the bidder shares the values used to generate the commitment (i.e., G, g, e, k, and ct), others can reproduce the commitment \psi, thereby revealing the bid. Further work is needed to understand the complexity involved in doing this in a ZKP, in order to understand whether the complexity is sufficient to discourage revealing of bids. If needed, we would change the scheme to use a key derivation function that is suboptimal for use within zk circuits, resulting in inefficient proof generation, and therefore a similar level of effort required to create the actual VDF proof.

Note that while it is possible to just use VDFs by themselves without the complexity of a commit-reveal scheme, this has the drawback of allowing bidders to produce multiple VDFs concurrently in order to retain the option of conditional bidding.

Risks / Concerns

Reduced Competitiveness in Bidding

Bids are a bet on averages, this can potentially have more centralizing effects than a JIT block auction, because it precludes any opportunistic MEV strategies that capitalize on MEV spikes, which could prevent block builders that exist on these strategies from participating. Also, because it is a bet on averages, the system may favor the most well capitalized block builders.

Also, because we are using a sealed-bid auction, participants are not bidding in response to each other’s bids. This removes the natural competitiveness that drives up prices, and so the overall level of bidding is likely to be somewhat lower.

L2 reorg resistance

This design assumes a BFT consensus protocol with single-slot-finality, wherein reorgs do not occur in the normal case. If reorgs are a concern, one can adapt the above design to include a second buffer phase at the end of the reveal phase but before slot n. This would force any incentivized reorg to be at least as deep as the size of the second buffer phase, making it much more expensive, and so disincentivizing malicious reorgs.

Benefits

The benefit of APS is that there is no longer a requirement for mev-boost relays

The reason is that there is no negotiation between proposers and relayers (in terms of the proposer being the BFT round leader, who proposes blocks to the validator set). In the mev-boost scenario, the relayers are required in order to give some assurance to the builder that the proposer will not unbundle their block and steal the MEV, and also to give assurance to the proposer that the builder will in fact release the block on time, and not cause the proposer to get slashed. This is necessary to maintain PBS (unless ePBS is implemented), without which searcher bots will engage in PGAs which will cause significant and adverse network congestion.

It reduces the centralizing effects of MEV on the validator set

While mev-boost already does this in terms of democratizing access to MEV, there are still some centralizing effects from having MEV flowing to validators. For example, co-locating validator nodes close to relays means that validators can benefit from reduced latency and the higher bids that emerge in the final milliseconds of the slot. This latency advantage has compelling economies of scale for larger staking pools, which drives both economic and geographic centralization.

Strengthens PoS tokenomic design

For L2s that maintain their own gas token, APS simplifies the modeling of token rewards and penalties with regards to the validator set. This is because MEV no longer flows to the validators, which makes the validator risk/reward profile more deterministic and easier to reason about. Validators will just receive rewards as designed by the protocol and nothing more, which makes it easier to design PoS tokenomics. APS-burn also acts as a natural token sink, strengthening the tokenomics by having a deflationary effect on the token itself.

Future Work

As well as soliciting early feedback and peer review, we plan to work on determining how best to model this design so that we can understand the trade-offs in the design choices such as threshold encryption or VDFs, parameterization of the on-chain auction, per-bidder-collateralization or per-bid-bonding, and to understand the extent to which we can confidently predict the behavior of participants.

1 post - 1 participant

Read full topic

Block-building on Ethereum has become quite centralized. 90% of blocks are auctioned off through MEV-Boost. Numerous solutions have been proposed, including anonymous inclusion lists and execution tickets. People are concerned about this, both for essentially ideological reasons, and for reasons of efficiency. Blockchains have an ethos of being open to all people, whether or not that is maximally efficient. There is a tradeoff between efficiency (in the sense of getting each block built in the most efficient way, by the most efficient builders) and “fairness”, or including all transactions, if people’s use of the chain is unaffected by the degree of centralization. If blockchain users are concerned their transactions will eventually be sanctioned and rendered worthless, they may avoid that blockchain, or avoid cryptocurrencies altogether. Thus, seemingly inefficient decentralization may be optimal for the blockchain as a whole, and would be unanimously preferred by all blockbuilders to the present equilibrium.

I am concerned, however, that the efficiency case is overstated. Imagine there is a firm so efficient at MEV extraction that they build all of the blocks on chain. If them doing so would cause people to leave the blockchain altogether, then they are incentivized to not bid on some blocks at all.

In “On block-space distribution mechanisms”, Neuder, Garavmidi, and Roughgarden propose execution-tickets as a mechanism for distributing block-building rights, using a proportional all-pay auction. Bidders buy lottery tickets for the right to build a block. In the example given, they have two buyers, buyer 1 with value 4, and buyer 2 with value 2. Under a perfectly efficient system, buyer one always gets the block, at price 2+epsilon. Under their all-pay system, buyer 1 bids 8/9th and buyer 2 bids 4/9th, with them receiving the block rights 2/3rds and 1/3rd of the time, respectively.

Under the description of the example, however, this necessarily cannot improve efficiency. If excessive centralization would scare away some users from using the chain at all, the winning monopolist is incentivized to give away some of the block. The value of efficiency is already reflected in their valuations. If you assume that their valuation is always higher, then you are assuming that there is no efficiency case whatsoever. You only have an ideological case, which is fine on its own terms — but you should not mix and match arguments which overstate your case. Note too that we are only caring about one side of the ledger, those who want their transactions to be included. Mightn’t it be possible that some people are repulsed by crypto’s shady reputation?

Nor should this necessarily apply in cases of monopolistic competition. To simply not bid is not the only way to redistribute blocks. If it were the case, the main block-builders would indeed be stuck in a prisoner’s dilemma — they could choose not to bid, but they would have to all do it. If, however, the winners hold another auction for the block, with some of the fairness raising characteristics as before, they can decentralize to the extent which is optimal for them.The drawback is that now the builders internalize a smaller portion of the gains. There is a free-rider problem with decentralization. However, as the market becomes more decentralized, doubtless people will be less concerned about censorship.

The efficiency argument for decentralization therefore much smaller than it would appear. There should probably be a split between allocatively efficient auctions for blocks, and allocatively fair but inefficient markets. What is the right split between the two? It is highly unlikely that it is optimal to only sell blocks in one way all the time.

I think that this is an ideal question for a prediction market. The right amount of decentralization is a macro question. You’re not going to be able to A/B test it in a couple days. Your choices are trying to influence people’s choice in the long run, and answer the question: what is the long run amount of decentralization that maximizes the amount of capital put on the chain. Is there any better use of prediction markets than this? I am somewhat agnostic to the exact method of determining the split — and have no opinions whatsoever as to the proper proportion.

This post was first posted on my blog here. Thank you for reading this, please tell me if you disagree.

3 posts - 2 participants

Read full topic

Special thanks to @soispoke for the review

Background

Builder bidding strategies in the MEV-Boost world have been studied extensively over some time. Numerous excellent resources, literature, game-theoretic models, and archives capture the current builder bidding behaviors on how to win block building right for an Ethereum slot. Today, builder bidding war for MEV-Boost is a complex interplay between latencies, relays, and strategy effectiveness. In this post, we argue that builder bidding strategies become simpler in ePBS world and we highlight the key differences in how bidding strategies change under the new ePBS market space rules, strategy limitations, and reduced latency benefits in ePBS.

Market Spaces

Here, we summarize three types of market spaces. The first one is MEV-Boost. The second and third ones are ePBS. MEV-Boost is push + pull based market space, meaning the builders push the bids to the relays, and the proposer pulls the bids from the relays. ePBS contains two types of market spaces: the P2P Bid Gossip Netwok, which is push-based, and the Builder RPC Endpoint, which is pull-based.

• MEV-Boost market space
  • Push + pull-based: The builders push bids to the relay, and the proposer pulls the bids from the relay.
• ePBS market spaces
  • P2P market space
    • Push-based. The builder pushes the bid to the p2p network.
  • Builder RPC market space
    • Pull-based. The proposer pulls the bids from the builder RPC end points.

We define the following market space characteristics given how the consensus spec is written today. Builder-API is still TBD for ePBS.

MEV-Boost Market Space

• Open auction: Builders that subscribe to the relay’s feed can see the every builder’s latest bid.
• Continuous auction: Builders can bid multiple times and cancel previous bids.
• Auction termination: The auction terminates when the proposer calls getHeader and when the relay returns the header to the proposer to sign. The relay may delay the header response for a timing game. This means the relayer has the final control over when the auction terminates.
• Profit sharing: Some relays take the difference between the winning bid and the second-highest bid received from builders. This difference goes to the relay, with a portion potentially refunded to the builder. This transforms the auction dynamic into a second-price auction. However, not all relays adopt this approach, and complete trust in the relay is mandatory.
• We assume the market space doesn’t verify block contents from the builder, hence it is an optimistic market space. The only delay is when the builder sends the block to the relay.

ePBS P2P Market Space

• Open auction: Anyone can subscribe and listen to the P2P network for gossiped builder bids.
• Single bid auction: To prevent DOS attacks on the P2P network, the current spec only allows builders to submit a single bid and above a certain minimum value. Any subsequent bid will be dropped by the nodes. There is no cancellation support over the P2P network.
• Auction termination: The auction terminates when the proposer proposes the block which includes the builder’s bid. The proposer could play a timing game here and has the final control over when the auction terminates.
• Profit sharing: The bid specifies the value, and the proposer gets the full value on the consensus layer as long as the consensus block that includes the bid remains canonical. There’s no profit sharing with 3rd parties.
• The market space is still optimistic and doesn’t need to verify the execution contents at inclusion time. If the execution block later becomes invalid or fails to reveal, the proposer still gets unconditional payment. The only delay here is the builder sending the bid to the P2P network. This delay is argubly longer than using a relay in MEV-Boost market space.

ePBS Builder RPC Market Space

Note: The Builder API is undefined at this moment. This section is based on what we think the ePBS Builder API might look like, but it’s highly subjective to change and open for feedback. Below outlines one version of Builder API which we have been thinking.

• Private auction: Only the proposer can request a bid from the builder. The proposer will sign the getHeader request using the builder’s public key. The builder’s bid remains private until requested by the proposer. Builders can’t sniff other builders’ bids unless the builder API allows this or the builder voluntarily opens their bids to the public.
• Single (maybe multiple?) bid auction: Builders allow proposers to request a bid once, and any subsequent requests will result in an error. Builders may also allow proposers to request bids multiple times without error; this specific detail is undefined, and it’s unclear what the Nash outcome is here. If builders allow multiple requests, then the builder must ensure previous bids are canceled.
• Auction termination: The auction terminates when the proposer requests the header and the proposer receives the header. The builder can play a timing game, but this may backfire and lead to the proposer using another builder’s bid. Builder timing game will not work here, but proposer timing games are still relevant.
• Profit sharing: Same as the P2P market space.
• The market space is still optimistic, and the delay here is the builder returning the bid to the proposer. This delay is shorter than the P2P market space and likely the same as MEV-Boost if the builder is well co-located.

Builder Bidding Profiles under ePBS

In the Strategic Bidding Wars in On-chain Auctions, four profiles of builder behavior are listed in MEV-Boost auction:

• Naive Behavior: Aggressively updates bids based on their valuation as long as the aggregated signal surpasses their profit margin.
• Adaptive Behavior: Monitors the current highest bid and places a bid if able to outbid by a small constant. Defaults to the naive strategy if unable to outbid.
• Last Minute Behavior: Reveals valuation at the final possible moment before auction termination to minimize the reaction window for other players.
• Bluff Behavior: Initially places high bids (bluff) and later reverts to actual valuation, leveraging bid cancellation to compel other players to disclose their valuations.

Given the new market space in ePBS, we will examine which strategies are viable under the auction rules.

P2P Market Space

• Naive, Adaptive, and Bluff Behaviors: These strategies are harder to execute since bids can only be sent once. The builder might use different staked addresses, each sending one bid. However, this requires staking on the consensus layer for each address, assuming payment is handled on the consensus layer. Additionally, bluffing is not possible because bids cannot be canceled.
• Last Minute Behavior: This is the only possible strategy. Builders will reveal their valuation at the final moment before auction termination to minimize the reaction window for other players.

Builder RPC Market Space

• Naive, Adaptive, Bluff, and Last Minute Behavior: For similar reasons to the P2P market space, these strategies are not possible. Additionally, the auction is private, meaning builders cannot see each other’s bids. Most importantly, the auction has shifted from push-based to pull-based, so the builder no longer has control over when to submit bids. The only way for builders to get their bids to the proposer is through the proposer’s request.

We conclude that builders’ bidding strategies are heavily limited under ePBS. For P2P, only last-minute bidding is possible. For Builder RPC, builders can only respond to the proposer as it is a pull-based model.

Market Space Considerations

We add a few more concerns in this section that was emphasized in the MEV-Boost market space but may no longer be relevant in ePBS market space.

Latency and DOS Concerns

Different market spaces impose varying latency constraints. In the P2P market space, builders push bids to the proposers, and the market operates as a large P2P gossip network constrained by anti-DOS measures. With 1 million validators, the worst-case scenario could mean 1 million bids. Due to these concerns, rules like disallowing multiple bids and ensuring bids are above certain values are necessary. The P2P network is inherently slow, so we don’t foresee serious bidders using it to win bids. However, the P2P market space is valuable for maintaining a good baseline for competitive bids that isn’t latency-sensitive. If builders using RPC collude to drive bid prices low, an altruistic builder over P2P can ensure the bid value baseline remains healthy and competitive with minimal effort. The baseline P2P bid value may also be used for burning in future iterations, as it only requires a 1/n honest assumption.

In the builder RPC market space, which is pull-based, latency matters significantly. Instead of two latencies (global and individual) defined in the MEV-Boost market space, there’s only one individual delay to consider: how fast the builder can return the bids to the proposer. Delaying the return of getHeader may result in proposer missing builder’s bid.

Auction Interval Uncertainty

The auction interval uncertainty becomes clearer in ePBS because MEV-Boost middleware and relays no longer control the timing of when the block gets returned to the proposer or released to the network. The proposer either uses the pushed bids from the P2P network or pulls bids from the builders RPC. The proposer has the final say on the auction interval cut-off. From the builder RPC market space perspective, it will keep updating its bids until the proposer requests them.

New: Bluff Behavior under ePBS

In ePBS, proposers or builders may attempt to bluff other builders. This may not be scalable given the nature of the single bid auction over P2P and the fact that every builder is a validator and needs to have a stake on the beacon chain. One bluff strategy is for the proposer of next slot to reveal a high value P2P bid, intentionally stating that this is the bid it will include for the next slot unless others can beat it. This helps set the base price and forces everyone else to beat it. However, the proposer doesn’t have to include its bid.

Although it’s obvious that anyone can see that the bid comes from the proposer and just ignore it, the proposer may use sybil validators to perform the same bluff. However, it’s still unclear how scalable this strategy is, given that one bid equals one validator.

Open questions

The current ePBS market space design and requirements leave some open questions. We will summarize the open questions here for feedback:

• P2P Market Space Conditions:

  • Every builder can only submit one bid, and the subsequent bids get dropped. Are there any advantages to allowing multiple bids here? If yes, then how many?
  • Every builder’s bid needs to be above a certain value to deter DOS attacks. What should the value be?
    • We can look at current or past empirical data here.
  • There’s a tradeoff between the number of bids allowed and the minimal values. If we set the values high, we may allow multiple bids.
  • Is there a strong argument for requiring bid cancellation?

• Builder RPC Market Space’s Builder API Interface:

  • What does the Builder API interface look like?
    • We want to leverage the existing Builder API and aim for minimal changes.
    • When the proposer makes a header request to the builder, what should the request look like? Can we use the current get header request with a signature, or should we modify it?
    • Do we allow multiple getHeader requests, such as continuous polling from the proposer, or do we enforce a common standard?
  • What kind of auction is most ideal?
    • Sealed second-price auction may be most ideal.
    • How to design this over Builder API?

• Comparing MEV-Boost Market Space to ePBS Market Space:

  • Do we lose anything in the ePBS market space that is important to maintain from the MEV-Boost market space?

• Implications of staking pools also bidding:

  • Pools that hold a significant chunk of validators could be in a privileged position for submitting bids and manipulating the market extensively compared to a builder that doesn’t hold as many keys.
    • Is there an advantage to this asymmetry?
    • Will we see staking pools and builders teaming up, and how will this dynamic play out?

6 posts - 4 participants

Read full topic

Enabling standardized on chain executions through Modular Accounts

Introduction

This blogpost is intended to be an extension from a previous work “ Self-sovereign identity and account abstraction for privacy preserving cross chain user operations across roll ups ” with the intent of proposing a system implementation of network features. In the previous work I tried to envision a system combining a three-layered architecture that I will briefly summarize here:

1. An application layer comprises wallets and other service apps to facilitate the generation and management of Verifiable Credentials, set a permission logic for compiling user operation objects through apps.
2. A network layer based on different L2s, which include a Keystore contract and Smart Contract Accounts. This layer is responsible for generating Zero-Knowledge Proofs (ZKPs) and Merkle proofs for Sequencers. The Keystore contract manages encryption keys and user authentication, ensuring the correct key pairing for Verifiable Credentials and Operations. Smart Contract Accounts verify user operations, by validating ZK cryptographic proofs to ensure the integrity of the signatures of the transactions before they are executed.
3. A sequencing layer which interconnects L2s with Ethereum main-net and manages the execution of batches of transactions anchoring Roll-up IDs to sequencing networks batching, validation cross chain atomic transactions via the Keystore roll-up, and the Roll-up contract within Ethereum’s slots.

Today, I am trying to focus on some elements on the 1 and 2 layer, sitting in the conjunction between External Owned Accounts and Contract Accounts trying to envision an implementation pathway for the adoption of standardized on chain execution.

The concept

To facilitate the adoption of blockchain based services globally there is a need for standardizing secure, privacy and regulatory-compliant on chain executions to scale. As we move towards a more decentralized future, ensuring cyber security, data minimization from origination to processing, and improving UX in executing on chain operations is crucial.

This blog post introduces a framework based on the ERC 7579 proposal, which integrates a module to lavage onchain verifiable credentials and zero-knowledge (zk) proofs in the context of modular smart accounts. This framework aims to standardize onchain executions by separating user authentication and transaction authorization while preserving privacy and regulatory requirements throughout the transaction lifecycle.

The core function of the system described involves validating zk proofs generated by VCs to authenticate users and authorize operations. This makes the Validation Module the most appropriate choice, as it is designed to validate user operations before they are executed.

The Validation Module allows for checking the validity and authenticity of zk proofs, ensuring that only legitimate user operations are processed.

For reference, the framework considers a minimal set of ERC for implementation:

• ERC 7579 - Minimal Modular Smart Accounts: to set a module to validate user operations by verifying ZK proofs derived from verifiable credentials (VCs) ensuring that user operations are authenticated and authorized before execution.

• ERC 1271 - Standard Signature Validation Method for Contracts: to standardize how smart contracts validate signatures, defining the function to verify the validity of a signature, crucial for transaction authorization.

• ERC 4337 - Account Abstraction Using Alt Mempool: to abstract account management and operations, enabling more complex and user-friendly interactions allowing smart contract accounts to handle user operations and transaction executions.

• ERC 165 - Standard Interface Detection: to allow contracts to declare support for certain interfaces and enabling smart contracts to query and interact with other contracts that implement specific interfaces.

High-level process flow

The framework leverages the strengths of different proposals to create a robust, secure, and privacy-preserving onchain execution environment.

I list here a high-level overview:

1. Users issue on chain merklized Verifiable Credentials (VCs) through a contract identifier operated by an issuer. These credentials are stored in the user’s identity wallet (EOA)
2. Users generate and validate ZK proofs derived from their VCs through a contract verifier to access service apps and compile User Operation objects.
3. Smart Contract Account entry point perform canonical verification loop according ERC 4337.
4. The validation module verifies the zk proofs against the VCs in the execution loop and upon successful validation, the module calls the isValidSignature function as defined by ERC 1271 to authorize entry point to executeUserOps.
5. Smart contract Account entry point executes onchain operations and distributes the fees to the Bundler address.

Market & Business Considerations

This framework offers significant value for large-scale enterprise services requiring validation logic before authorizing onchain operations. By integrating SSI and zk proofs, enterprises can ensure privacy and regulatory compliance while enhancing security and efficiency. The separation of authentication and authorization further strengthens the system’s robustness.

Here a short list of valuable use cases that would fit nicely with this logic:

1. Trading: A DeFi platform allows users to interact with various financial services such as lending, borrowing, and trading. The platform issues VCs containing user identity and KYC information. Whenever a user wants to execute a financial transaction, they submit a zk proofs on VC and compile user operations objects along as operation request. The Validation Module verifies the zk proof against the stored VC and upon successful verification, the entry point is executing the operations on chain.
2. DAOs: a decentralized voting system allows DAO members to vote for grants allocation privacy preserving and reducing conflict of interest. Voters authenticate themselves using VCs and zk proofs to cast their votes and upon the voting completion the entry point executes grants allocations on chain according to the voting results.
3. Supply chain: a management system tracks the manufacturing and logistics of goods, participants in the supply chain authenticate using VCs and zk proofs to update and access the status of goods up to the distributor and at the moment of the sale the entry point execute onchain rewards, or payment premiums, to the different members.

Conclusion & further thoughts

When we look forward to what kind of functionalities we would like to have as user for the future I believe there has been a big trend in providing standardization through native abstraction, modularity, and functional collaboration between EOAs and SCAs. Considering the future road map of Ethereum in Pectra, EIP 7702 sets the way for a new transaction type which enables account properties of both externally owned accounts (EOAs) and Smart Contract Accounts (SCAs). Furthering looking ahead, there is a way to set “native account abstraction” by RIP 7560 and ERC 7562 which align with ERC 4337 rules at least on validation rules.

A side of this is also important EIP 7212 proposes a precompiled contract to perform signature verifications using the secp256r1 elliptic curve. This curve, also known as P-256, is widely supported in modern devices like Apple’s Secure Enclave, Webauthn, and Android Keychain, and Passkeys. This would allows more efficient and flexible management of accounts by transaction signs in mobile devices. Both EIP 7702 and EIP 7212 are potentially taking place in Pectra.

Network harmonization is a key capability of every growing community, in this context personally I see value in further exploring the use of keystore contracts, session keys and passkeys as additional features to provide security, flexibility and usability to the product experience.

Passkeys can be used to authenticate users providing a smoother UX while combining strong user authentication. Session keys can improve security of communication at application level, meaning when users are interacting with dapps for using market services, and keystore contract could represent an reliable solution for setting a functional framework for operating key sessions.

The shared focus on improving account flexibility and security through different methods highlights the committment of the community’s to address scalability, usability, and security concerns within the Ethereum network. In this setting collaboration between EOAs and SCAs, and additional features as passkeys keystore contracts can live in a modular setting where specific modules enforce optional rules for executions, and different cryptographic tecniques could ensure data minimization for controllers and processors.

3 posts - 2 participants

Read full topic

Diseconomies of Scale: Anti-Correlation Penalties (EIP-7716)

Special thanks to DappLion and Vitalik for their collaborative effort on the overall concept, and Anders and Julian for their valuable feedback on this post!

Ethereum relies on a decentralized set of validators to ensure properties like credible neutrality and censorship resistance. Validators stake a certain amount of ETH to participate in Ethereum’s consensus and secure the network. In return, validators receive rewards directly from the protocol (#issuance) as well as execution layer rewards when proposing a block, which include transaction fees and MEV from the blocks they propose (#mevboost). As of today, thousands, if not tens of thousands, of small-sized entities run validators from their homes despite several disadvantages. These include the risk and responsibility of operating and maintaining a node, the technical burden associated with setup and upkeep, potential downtime, and the lack of a liquid staking token that would otherwise provide flexibility and liquidity.

With the ongoing maturation of Ethereum’s PoS, we’ve encountered various centralizing forces inherent to the current protocol:

• EL Reward Variance: While attestation rewards are distributed fairly evenly, the rewards for proposing a block can vary significantly. This variation arises because MEV is extremely spiky, resulting in a few outlier blocks with proposer profits exceeding 10 ETH. Large operators running many validators have better chances of capturing these “juicy” blocks. Although over many years the earnings of individual validators should average out, the future remains uncertain. Assuming 1 million validators and 2,628,000 slots per year, the probability of being selected as a proposer is ~0.0001%. On average, a validator can expect to propose \frac{1,000,000}{365.25 \times 7200} = 2.628 blocks per year (there are 7200 slots per day). From April 2023 to April 2024, the percentage of blocks with more than 10 ETH was 0.004041%. Statistically, a single validator will eventually propose a block with more than 10 ETH of MEV, but it’s unknown whether this will happen this year or in ten years, and by then, MEV issues might be resolved. While solo stakers literally participate in a lottery, large operators can average their profits and plan for the future with greater certainty.
  Over 1 year, the probability of a random validator getting at least one block with >10 ETH profits is 0.1%:

If you control 1% of all validators (~10k validators), the probability of getting at least one block with more than 10 ETH of MEV climbs to approximately 99.99% over one year.

The following chart shows the cumulative sum of MEV-Boost payments on the y-axis and the cumulative number of MEV-Boost payments on the x-axis. We can see that 90% of all blocks distribute around 44% of the total value, leaving 56% to be distributed to the lucky 10% of proposers.

• Reorgs: “Honest reorgs” occur when the proposer of slot n_{1} orphans the block of the proposer of slot n_{0} because that block hasn’t received at least 40% of the slot’s committee members’ votes. By using proposer boost, these “weak” blocks (those with less than 40% attestations) can be reorged by the next proposer to penalize the previous proposer for poor performance, such as being late and therefore rugging some attesters for their correct head votes. Reorgs can have centralizing forces and the more stake an entity holds, the more strategically it can decide whether to reorg a particular block. Large-scale operators have more safety because they can ensure their own validators never vote to reorg their own blocks. Essentially, all nodes of an entity can coordinate to always vote for the current slot’s block rather than its parent if the current block comes from that entity. This coordination potentially allows large entities to risk broadcasting their block later in the slot while still having a high probability of the block becoming canonical. Analysis has shown that by second 4 of the slot, 40% of all attestations for that slot have been seen. A large operator, who controls many validators and knows that these validators will never vote to reorganize its blocks, can slightly delay block propagation without significantly increasing its risk. The same principle applies when a single entity owns consecutive slots. In theory, this entity could wait until the end of the slot (or even longer) before publishing its block. Then, it could use the next slot to solidify that weak block into the chain by leveraging proposer boost.

• Proposer Timing Games: Proposer timing games (also see [1], [2]) is a term that summarizes a strategy applied by some block proposers in which they delay their proposal to give the builder more time for extracting MEV. This leads to increased profits for the proposer but evidently comes with a negative impact on other proposers and especially attesters. Proposer timing games are risky because late blocks have an increased chance of being reorged. In general, large-size operators face lower risks when playing timing games than small-size entities. This stems from the fact that larger operators are on average more sophisticated and have better connectivity in the P2P network: What might be a late block for an Australian validator (go sassal ) might be just in time for a US-based Coinbase validator. Thus, the lower the latency, the more a validator can risk delaying.

Economies of scale are nothing new and the crypto landscape isn’t immune either. Looking at Wikipedia, it is defined as “the cost advantages that enterprises obtain due to their scale of operation […]”, and the same applies to Ethereum staking:

Large operators like Coinbase, Kraken, or Kiln can leverage economies of scale to make staking even more profitable. This allows them to offer rewards competitive with those of solo stakers, even after taking their cut. To illustrate this, consider a simple example (the exact numbers are not important here):

For more realistic numbers, refer to the latest EthStaker survey published here. By allocating 10x as much in Other Costs for large operators, we account for the increased complexity of setting up multiple validators on one machine. This is realistic enough for the point we’re making here.

We can see the effects of economies of scale: the machine used by Coinbase will generate 1,000 times the profits compared to solo stakers, while the costs are only eight times higher. As a result, the ROI for large-scale operators is significantly better.

Using one hardware device for multiple validators is just one piece of the puzzle. Others include:

• Cloud service provider
• ISPs
• Geographical locations
• Maintenance responsibilities
• Client software
• And many more…

In all these categories, the goal is maximum diversity to minimize the risk of external factors degrading or damaging the network. Despite this goal, economically rational players might prefer a one-stop-shop solution, such as running a Lighthouse + Geth node on a Google/AWS/Hetzner instance located in central Europe, maintained by a dedicated team of specialists. While this setup may perform well in terms of efficiency, Ethereum should not create incentives that further exacerbate centralization.

But who is large-scale and whose not?

The protocol itself does not know which validator is operated by which entity. From the protocol’s perspective, a Coinbase validator looks the same as a solo staker. Therefore, to prevent correlations from emerging, we cannot simply scale rewards and penalties based on the market share of the entity behind a validator. For more on this topic, I recommend Barnabé’s post, “Seeing Like a Protocol”.

Fortunately, economies of scale inherently come with correlations, which is something the protocol can be made aware of. Leveraging economies of scale may linearly scale with correlations, thus we can implement rules to dynamically scale economic incentives and steer the validator set toward diversification.

Penalizing correlated faults isn’t something new to Ethereum. In the current slashing mechanism, a “malicious” validator is initially penalized by a reduction of 1/32 of their effective balance when they are slashed. After being halfway through the withdrawal period, they are subject to an additional penalty (the correlation penalty) that scales with the number of validators (specifically their stake) who were slashed around the same time (+/- 18 days). Therefore, a solo staker accidentally voting for two different head blocks, which is a slashable offense, would lose significantly less than a party with a 20% market share (assuming all 20% collectively fail).

In the end, the goal must be to incentivize validators to diversify their setup. As shown in the following example, we want validators to reduce their correlation with other validators, making the whole network more robust against external influences.

EIP-7716

The goal of “EIP-7716: Anti-Correlation Attestation Penalties” is to get us closer to diseconomies of scale. The more homogeneous an entity’s staking setup, the more it should be penalized while non-correlated setups profit from the proposed changes.

With anti-correlation penalties, the previous “economies of scale vs number of validators” might be more like the following:

Anti-correlation penalties were first described by Vitalik in an ethresearch post. After some initial analyses and a more concrete proposal available, the EIP is now at the point where everyone is invited to look into the inner workings of correlated penalties and leave feedback.

In short, the EIP proposes to multiply the missed (source) vote penalty by a penalty factor that ranges from 0 to 4 but equals 1 on average (notably, this is important to not touch the issuance policy).

How does 7716 work?

The final values for the constants are still to be decided.

The penalty factor p scales the slot penalties to a maximum of MAX_PENALTY_FACTOR, or down. It’s determined the following:

and from the pyspec implementation; h/t dapplion:

penalty_factor = min(
    ((total_balance - participating_balance) * PENALTY_ADJUSTMENT_FACTOR) // 
    (max(self.net_excess_penalties, 0.5) * total_balance + 1),
    MAX_PENALTY_FACTOR
)

The formula calculates the penalty factor as a ratio of the “penalty weight” of non-attesting validators to the net excess penalty scaled by the balance of all validators. A higher penalty adjustment factor increases the sensitivity of the penalty factor. Conversely, a higher net excess penalty leads to a lower penalty factor.

Finally, this is how the penalty_factor variable would be used:

def get_flag_index_deltas(state: BeaconState, flag_index: int) -> Tuple[Sequence[Gwei], Sequence[Gwei]]:
    """
    Return the deltas for a given ``flag_index`` by scanning through the participation flags.
    """
    ...
    for index in get_eligible_validator_indices(state):
        base_reward = get_base_reward(state, index)
        if index in unslashed_participating_indices:
            if not is_in_inactivity_leak(state):
                reward_numerator = base_reward * weight * unslashed_participating_increments
                rewards[index] += Gwei(reward_numerator // (active_increments * WEIGHT_DENOMINATOR))
        elif flag_index != TIMELY_SOURCE_FLAG_INDEX:
            # [New in correlated_penalties]
            slot = committee_slot_of_validator(state, index, previous_epoch)
            penalty_factor = compute_penalty_factor(state, slot) 
            penalties[index] += Gwei(penalty_factor * base_reward * weight // WEIGHT_DENOMINATOR)
    return rewards, penalties

We check if we are dealing with source votes (line 12), derive the slot in which the validator was supposed to vote (line 14), compute the penalty factor (line 15), and multiply it by the base reward (line 16).

Although source votes might be a good starting point, the concept can be equally appied to head and target votes.

The p_{exc} is updated at the end of each slot using:

Which equals to:

net_excess_penalties = max(
        EXCESS_PENALTY_RECOVERY_RATE, 
        net_excess_penalties + penalty_factor
    ) - EXCESS_PENALTY_RECOVERY_RATE

We can observe the following dynamics:

• If the balance of non-attesting validators increases, the penalty factor also increases.
• If the balance of non-attesting validators remains the same, the penalty factor approaches 1.
• If the balance of non-attesting validators decreases, the penalty factor can go below 1 for a while and then approach 1 afterward.

When the non_participating_balance continuously increases for several rounds, the penalty_factor and the net_excess_penalties also increase. This continues until the non_participating_balance stops increasing. Then, the net_excess_penalties and the penalty_factor start decreasing together.

With the net_excess_penalties keeping track of the excess penalties of past epochs, the formula can self-regulate what constitutes a “large” number of misses and what does not.

This mechanism ensures that the sum of penalties doesn’t change with this EIP—only the distribution does.

Some FAQs

1. Wouldn’t that be even worse for solo stakers?

No. Solo stakers, commonly referred to as small-scale operators or individuals running 1-10 validators from home, are expected to behave in a very uncorrelated manner compared to larger operators. Although factors like geographical location and client software can impact correlations, solo stakers are likely to be offline at different times than large-scale operators such as Coinbase or Kraken. As a result, the penalties solo stakers receive are smaller than those in the current system. In contrast, if a large-scale operator’s staking setup has a bug causing all their validators to fail to attest, the correlation is clear and the penalties are higher.

This expectation was first confirmed in an initial analysis on anti-correlation penalties, which showed that solo stakers and Rocketpool operators would have been better off, while large-scale operators would have received higher penalties on average.

2. Wouldn’t that discourage people from using minority clients?

No. In fact, it encourages using minority clients. Using the majority clients leads to higher correlations. For example, if the Lighthouse client has a bug causing attesters to vote for the wrong source, the correlation is high and the penalty increases. Conversely, if all Lodestar attesters fail, it is considered a much smaller collective fault. The correlation penalty is more forgiving to a small minority than to a majority client. So, even if minority clients are expected to have more bugs, correlation penalties can steer validators toward using them.

3. Why would it benefit decentralization?

Anti-correlation penalties effectively differentiate between small and large operators without relying on validators that have consolidated their stake or other out-of-protocol solutions. By introducing economic incentives for diversified behavior, we benefit small players who are already “anti-correlated” while encouraging large players to reduce the impact of external factors such as one-node setups, or cloud providers on their staking operations.

4. Wouldn’t that just lead to big parties investing in increased fault tolerance while even increasing the correlations?

If big parties invest in increased fault tolerance, it’s still beneficial. Enhancing fault tolerance is difficult and expensive. At some point, it becomes cheaper to invest in anti-correlation than in further fault tolerance improvements. While large operators might have to move validators from popular cloud platforms to different environments, solo stakers running their nodes from home can continue as they are. Anything that costs large operators money but is free for solo stakers (=diseconomies of scale) fosters decentralization.

The main argument is, that no matter how big operators react, either going for anti-correlation or, doing the opposite, putting all validators on a single extremely robust node, both cost money and reduce their APY. As fault tolerance has its limits, there is no escape from harsher penalties other than diversifying.

5. This sounds super dangerous, as I could be penalized for 32 ETH just by missing a single source vote.

This is incorrect since the penalty_factor variable is capped at 4 (to be analyzed). Capping ensures that the correlation penalties never get out of hand.

6. Why only focus on source votes and not do the same for head and target votes?

This is a good question and since research on that topic is still at the very beginning this isn’t decided yet. An argument against head and target votes is the fact that they depend on external factors: as shown in previous analysis, head votes are sensitive to proposer timing games. So, if those timing games become more and more the standard, less well-connected validators (oftentimes solo stakers) could potentially be worse off. However, this analysis showed that it would be the opposite and in the long run, small-size stakers would profit from anti-correlation penalties. The same applies to target votes that are harder to get right in the first slot of an epoch compared to every other slot. Nevertheless, in the long run, this should smooth out across validators, allowing us to do anti-correlation penalties for all parts of an attestation, source-, target-, and head votes.

Useful links:

6 posts - 4 participants

Read full topic

The following post is an introduction to some and an update to others on a community effort called Commit-Boost. Much of this has already been discussed in various public domains / presentations / documentation. Thank you to all the countless teams that already have contributed / committed to contributing to this effort including researchers, validators, builders, relays, client teams, consulting firms, teams building commitment protocols, L2s, restaking platforms, shared sequencers, wallets, and countless others. Please reach out if you would like to contribute to this effort for Ethereum.

TL;DR

• Due to the risks developing for Ethereum, core development, and its validator set, a group of teams / individuals are working on developing a public good called Commit-Boost
• Commit-Boost is an open-source public good that is fully compatible with MEV-Boost but acts as a light-weight validator platform to safely make commitments
• Specifically, Commit-Boost is a new Ethereum validator sidecar that is focused on standardizing the last mile of communication between validators and proposer commitment protocols
• Commit-Boost has been designed with safety and modularity at its core, with the goal of not limiting the market downstream including stakeholders, flows, proposer commitments, enforcement mechanisms, etc.
• While we should always be skeptical of out-of-protocol solutions that directly impact infrastructure this close to the Ethereum protocol layer, if we are going to rely on these solutions, we believe they should be developed, sustained, and governed in a way that encompasses many of the views previously voiced by the community. We have tried to embrace this and strive to model Commit-Boost after it

Background

• Proposer commitments have been an important part of Ethereum’s history. Today, we already see the power of commitments where over 90% of validators give up their autonomy and make a wholesale commitment that outsources block building to a sophisticated actor called a block builder
• However, most are starting to agree on a common denominator: in the future, beacon proposers will face a broader set of options of what they may “commit" to–be it inclusions lists or preconfs or other types of commitments such as long-dated blockspace futures–compared to just an external or local payload they see today
• A post from Barnabe captures this well; during block construction, the validator “…creates the specs, or the template, by which the resulting block must be created, and the builders engaged by the proposer are tasked with delivering the block according to its specifications”
• While this all seems great, the challenge is that many teams building commitments are creating new sidecars driving fragmentation and risks for Ethereum
• For Ethereum, there are going to be significant challenges and increased risks during upgrades if there are a handful of sidecars that validators are running
• For validators, these risks potentially take us to a world where proposers will need to make decisions on which teams to “bet on” and which sidecars they will need to run to participate in what those teams are offering
• For homestakers, this is difficult and they likely will be unable to participate in more than one of these commitments
• For sophisticated actors, this increases the attack vector and operational complexity as more and more sidecars are required to be run
• Another side effect of this is validators are somewhat locked into using a specific sidecar due to limited operational capacity and the switching costs of running a different sidecar (i.e., vendor lock-in). The higher the switching costs, the more embedded network effects could become if these sidecars only support certain downstream actors / proposer commitment protocols
• This also could create a dynamic where core out-of-protocol infrastructure supporting Ethereum which should be a public good, starts being used for monetization, distribution, or other purposes
• Due to these dynamics, various teams and individuals across the community are driving the development and testing of open-source / public good software called Commit-Boost. This effort includes researchers, validators, builders, relays, client teams, consulting firms, protocols building commitments, L2s, restaking platforms, and countless others across the community

Commit-Boost Overview

Commit-Boost is a community-driven, open-source project developing an unopinionated validator platform to enable safe interactions with commitments. Some of its features include:

• Unification: Core devs will be able to interact and work with one standard during Ethereum forks / upgrades / when and if things go wrong
• Backward compatibility + more: Commit-Boost is not only backward compatible with MEV-Boost, but will improve the life of validators who only run MEV-Boost through increased reporting, telemetry / other off-the-shelf tools validators can employ
• Opt-in without running more sidecars: Commit-Boost will allow proposers who want to opt into other commitments do so without having to run multiple sidecars
• Robust support: Commit-Boost the software is supported by a not-for-profit entity. This team will be focused on security and robustness through policies and procedures with follow-the-sun type models where there is support 24/7 if / when things go wrong. This team will also be focused on testing and adjustments needed during hard forks and have a team to interact with to help during adoption, improvements, and sustainment
• Not VC-backed public good: This team and effort will not be VC-backed. There is no monetization plan. The entity will not be able to sell itself and will not start any monetizable side businesses

Robustness, Sustainability, and Security

• Commit-Boost is being developed as a fully open-source project with contributions from teams across the Ethereum tech stack including from validators, client teams, relays, builders, consulting firms, researchers, and many others. This effort with input and support from these teams will help develop a robust product integrating many perspectives
• Commit-Boost will go through code reviews and audits once fully developed
• As noted below, there also will be a full-time team that helps maintain and upgrade the software with their core focus on 100% uptime and when there are bugs, robust processes to quickly address and fix
• The software stack is also built with the validator at the core and includes off-the-shelf tools for monitoring as well as reducing and proactively addressing any risks that may arise
• Last, this public good software will have minimal, but critical open governance around future upgrades with input across the Ethereum

Team Supporting / Governance of Commit-Boost Software

• Entity supporting the software: Not-for-profit entity
• Multiple-person team: Multiple devs that focus on transparency, sustainment / development, and research with an initial focus around Commit-Boost the software
• Transparency: Open-source repo and governance calls (see below)
• Sustainment / Development: 24/7 follow-the-sun coverage and highly engaged with client teams around upgrades / early in getting testnet support
• Research: Helping with open-source research across Ethereum
• Governance: This is still a WIP, but at a minimum will run a Commit-Boost, ACD-like calls (first one coming soon) to engage with stakeholders and drive consensus on upgrades / help coordinate around hard forks. A credibly neutral community member will lead these calls / this process that has experience with running governance processes over critical software within the Ethereum community
• Funding: All grants

Where Will the Grants Come From

The team is in the process of applying for grants from across the ecosystem. We are initially applying to a few organizations across the community that are supporting grants across research organizations and firms focused on PBS and staking. If teams are interested in providing a grant, feel free to comment below / reach out.

Technical Roadmap

Commit-Boost is currently in the MVP phase with testing underway in Holesky with multiple validators. This includes the full functionality of a PBS Module implementing MEV-Boost with additional telemetry and metrics collection. We are continuing the development and feature set of Commit-Boost targeting production-ready software and audits kicking off at the end of Q3. More details are in the Commit-Boost repo and we are keen to get feedback / engage with the community around these.

Some near-term high-level highlights from the roadmap include:

• Optimized and functional MEV-Boost module including multiple metrics for reporting and extensions such as configurable timing for get_header / get_payload calls
• Pre-made dashboards on Grafana for all core services
• Improved reliability and integrations for incident response
• R&D / spec signing mechanism to fit as many validator set-ups as possible
• Expanding modularity and optionality (i.e., supporting different types of signatures and modules)

Commit-Boost Design Principles

• Built for validators: Platform that not only can help validators today (i.e., can improve the lives of validators even if they just run an MEV-Boost module) but allows validators to be ready for the market of tomorrow (i.e., preconfs, inclusion lists, etc)
• Neutrality: No opinions, the platform will be proposer commitment agnostic, relay agnostic, transaction flow agnostic, etc. The goal is to build a platform that doesn’t limit the design space downstream while reducing risks of fragmentation for validators and Ethereum
• Unified: Validators run one core sidecar with the ability to opt into many different commitments
• Safety: Open-source code developed with input by the community with community reviews / audits
• Reduce risks: Modularized and transparency are core to reducing risk / overhead for the proposer to manage commitments and their broader operational processes
• Values aligned: Public good with no plans for monetization. We will continuously ask ourselves: would Vitalik run Commit-Boost and can this be designed in a way to increase the decentralization of Ethereum block construction

From the Perspective of the Proposer

More details on what it takes to run Commit-Boost as a node operator can be found here. Please note that this has not been finalized and over the next few weeks we will be making updates (see roadmap / milestones above).

• Run a single sidecar with support for MEV-Boost and other proposer commitments protocols, such as precons / other commitments
• Out-of-the-box support for metrics reporting and dashboards to have clear insight around what is happening in your validator seen through dashboards such as Grafana
• Plug-in system to add custom modules, i.e., receive a notification on Telegram if a relay fails to deliver a block
• Standardized way to provide a signature to opt into a commitment
• Creates constraints / condition sets and pass these constraints downstream

From the Perspective of the Proposer Commitment Protocol / Module Creator

More details on what it takes to build a module / metrics can be found here. Please note that this has not been finalized and over the next few weeks we will finalize moving parts that impact module creators (see roadmap / milestones above).

• A modular platform to develop and distribute proposer commitments protocols
• A single API to interact with validators
• Support for hard-forks and new protocol requirements

Architecture of Commit-Boost

More details can be found in the Commit-Boost documentation. However, below is a schematic of Commit-Boost. This proposed architecture allows proposers to run one sidecar, but still retain the ability to opt into a network of proposer commitment modules. More specifically, with this middleware, the proposer will only need to (in the case of delegation / light weight commitments) run one sidecar and limit their responsibilities to only selecting which module / proposer commitment protocol they would like to subscribe to.

It is important to note that the below depiction contains just a few examples of proposer commitment modules that can run on Commit-Boost. The design space for modules is completely open / not gated by the Commit-Boost software and proposers will be responsible for opting into the commitments they wish to subscribe to (i.e., a proposer is responsible for which modules they will subscribe to).

Terminology

• Proposer: entity, staking pool NoOp, or DVT cluster with the right to propose the next block
• Commitment: a constraint or condition that the proposer choses and agrees to via a signature
• Key Manager: some proposers use key managers or remote signers as part of their proposer / validator duties. Please note, that Commit-Boost is being designed in a way where it does not require validators to run key managers and working on solutions for monolithic set-ups
• Consensus Client: for example, Lighthouse or Teku (see here for more details)
• Commitment Modules: community-built modules allowing proposers to make commitment, including some of the logic of the proposer commitment protocol
• Signer API: The signer API is one of the core components around Commit-Boost. This is used to provide signatures from the proposer to the proposer commitment protocol. This is still in the design but proxy signatures will be used in nearly all cases (there are some outlier cases). For more details on the API please see here. For an example of how to communicate with the Signer API, please see here

Using this as a middleware instead of direct modification to the consensus client or running a sidecar per commitment will allow for each component to be sustained independently and will provide for cross proposer commitment compatibility. This will also allow for a bit of time for the market to play out, but via a public good, standardize the last mile of communication to help address the risks (discussed in the background section above) developing. Once the market does play out, and the community is able to observe some dynamics (the good and the bad), we can and should push for CL changes.

Resources

• Commit-Boost Repo
• Commit-Boost documentation
• List of presentations
• Original post on ETH Research, read more here
• First presentation to the community can be found here
• Second presentation at zuBerlin can be found here
• zuBerlin Devnet notion can be found here
• Mev-Boost Community call here
• Espresso / One Balance Sequencing day here (this will be updated when the link is ready)
• Gattaca MEV Day here (this will be updated when the link is ready)

1 post - 1 participant

Read full topic

Authors: @Kyungmin @bicoCrypto @solmingming Members of @DecipherGlobal SNU Blockchain Research Center

TL;DR

The current concept of TPS (Transactions Per Second) in blockchain is being disclosed in an ambiguous and opaque manner, conflicting with blockchain’s core value of transparency. This article reconsiders the definition of transactions in blockchain, compares theoretical figures with actual measurements, evaluates existing measurement tools, introduces our self-developed tool, and proposes a more accurate and transparent TPS measurement method.

Problem

The biggest change in the transition from Web2 to Web3 is decentralization. This has led to improved system accessibility and increased information transparency. However, there is still opaque information in the blockchain ecosystem, with TPS being a prime example.

In transaction processing systems, especially financial systems, TPS is a crucial performance indicator. However, the TPS information currently provided in blockchain is limited to simple figures, with detailed information about measurement methods and processes remaining opaque.

While blockchain smart contracts are operated transparently through verification and auditing, we still rely on the foundation’s system for the blockchain nodes themselves, lacking verification procedures similar to smart contracts.

TPS in traditional Web2

When discussing blockchain TPS, VISA’s processing capability is often mentioned as a comparison. VISA officially announced a processing capability of 24,000 TPS, but this has been questioned:

In centralized Web2 systems, it’s difficult to verify such issues. However, blockchain (Web3) systems are decentralized and their code is managed as open source, making it possible to verify TPS.

TPS in Web3

In blockchain systems with public nodes and permissionless nodes, anyone can participate in the network, operate nodes, and access the system. Even without connecting to the mainnet or testnet, the source code is publicly available, allowing independent network construction or modification after forking.

Ethereum and most EVM-compatible blockchains publish high TPS figures. For example, Avalanche C-Chain is introduced as capable of achieving 4,500 TPS. However, information on how this figure was measured is not provided.

Time to Define Transaction

In EVM blockchains, the term “Transaction” is used in various contexts:

• SendTransaction: Simply refers to the act of sending a transaction, without guaranteeing the final state or completeness of the transaction.
• PendingTransaction: The state where a transaction is waiting in the node’s memory pool (Mempool).
• QueuedTransaction: Similar to Pending, waiting in the node’s memory pool, but distinguished in the serialization process through Nonce.
• ConfirmedTransaction: The state where a transaction receipt has been issued, indicating the transaction has succeeded or failed.

We believe that TPS should be calculated based on ConfirmedTransactions when measuring. Based on this, we propose the following formula for calculating TPS:
TPS = BlockGasLimit / (TxGasUsed * BlockCreationTime)

Currently, Avalanche C-Chain’s BlockGasLimit is 15,000,000

Even assuming the simplest transaction (TxGasUsed = 21,000) and the shortest block creation time (BlockCreationTime = 1 second), the theoretical maximum TPS is 715. This shows a significant difference from the officially announced 4,500 TPS. (The actual measured value would naturally be even lower)

We speculate that this difference may occur due to:

• The transaction standard used in TPS calculation may not be ConfirmedTransaction
• The Avalanche version that achieved 4,500 TPS may differ from the version currently used in public nodes
• Differences in TPS measurement methods and methodologies

Such opaque information raises questions about the reliability and accuracy of TPS figures.
Monad has published a critical analysis of these limitations of blockchain TPS: WTF is TPS?

TPS Benchmark Tools

There are currently two main blockchain TPS benchmark tools in use:

1. Hyperledger Caliper: Developed by the Hyperledger Foundation
2. ChainHammer: Recommended by Quorum (a private blockchain developed by ConsenSys)
   Note: ChainHammer’s most recent commit was 2 years ago, making it essentially outdated.

Caliper is written in JavaScript and is a highly complete project. However, there are doubts about whether it is optimized for measuring “blockchain” TPS:

1. TPS measurement on a single node:
   
   

The core of blockchain is distributed storage of data through consensus. However, Caliper only conducts TPS measurements on a single node, which can measure the TPS of individual nodes but does not accurately reflect the TPS of the entire blockchain network. (The transaction propagation process is not considered)

1. Limitation of measurement from a single account:
   In EVM, EOA (Externally Owned Account) has a Nonce value, causing transactions to be processed sequentially.
   While 2024 was predicted to be the era of parallel EVM, current parallel processing technology still proceeds in an optimistic manner, requiring re-execution in case of conflicts. (Cases requiring re-execution can hardly be considered true parallel execution.)
   Therefore, execution from a single account versus multiple accounts can have a significant impact on TPS.

AnTPS(An-ti TPS)

To improve these limitations, we have developed our own blockchain benchmark tool, AnTPS, using Golang: Github
Features include:

• Transparently providing measurement environment/results.
• Conducting measurements on at least two or more nodes.
• Supporting measurement cases for both single and multiple accounts.
• Supporting various scenarios during measurement (ERC20/721/1155/NativeToken).
• Supporting not only local environment measurements but also Cloud environments through IaC.

Our goal is to overcome the limitations of existing tools while providing information transparently.
We welcome your opinions and feedback. Thank you.

3 posts - 2 participants

Read full topic

By Lin Oshitani (Nethermind Switchboard, Nethermind Research). Many thanks to Conor for the detailed back-and-forth on crafting this document and to Aikaterini, Elena, Ahmad, Anshu, Swapnil, Tomasz, Jinsuk, Quintus, Ceciliaz, and Brecht for the helpful comments and/or review. This work was partly funded by Taiko. The views expressed are my own and do not necessarily reflect those of the reviewers or Taiko.

TL;DR

As we outlined in our previous post Strawmanning Based Preconfirmations, naive implementations of based preconfirmations introduce many negative externalities that require thoughtful consideration.

In this post, we will expand on the negative externalities of based preconfirmations by examining them through the lens of the L1 PBS pipeline. Then, we propose multi-round MEV-Boost, a modification of MEV-Boost that enables based preconfirmations by running multiple rounds of MEV-Boost auctions within a single slot. This approach inherits the L1 PBS pipeline and mitigates the negative externalities of based preconfirmations as a result.

Motivation

As Justin Drake defines in the original post, based rollups are rollups “where the next L1 proposer may, in collaboration with L1 searchers and builders, permissionlessly include the next rollup block as part of the next L1 block”. Using the MEV supply chain diagram, based rollups can be illustrated below:

Notice that the L2 transactions, represented as the red line, go through the same process as the L1 transactions, represented as the black line. By effectively “piggybacking” the L1 PBS pipeline, based rollups provide two key benefits:

• Benefit 1: Since no additional actors (and thus no additional choke points) are introduced for L2 sequencing, based rollups fully inherit L1 censorship resistance, liveness, and credible neutrality.
• Benefit 2: Since the L1 and L2 transactions are sequenced by the same entity (the builder), based rollups enable not only synchronous L2-L2 composability but also synchronous L1-L2 composability.

Based rollups are great. They solve L2 fragmentation and sequencer decentralization while enabling L1 composability and inheriting L1’s censorship resistance, liveness, and credible neutrality. They are the only rollups that can have these properties simultaneously.

However, they have one large drawback: they also inherit the 12-second L1 block time. To address the slow confirmation time, Justin introduced base preconfirmations. In this approach, L1 proposers can opt into providing preconfirmations for based rollup L2 transactions, as shown below:

Since providing preconfirmations requires technical sophistication, most based preconfirmation designs include a delegation mechanism that allows validators to outsource the preconfirmation duty to a designated preconfer, as illustrated below:

Notice that L2 and L1 transactions no longer share the block-building pipeline. As such, the benefits of based rollups are diminished:

• On benefit 1: We introduced an additional choke point to the system, the preconfer, which can censor L2 transactions or degrade L2 liveness by going down. As a result, the inheritance of L1 censorship resistance and liveness are degraded.
• On benefit 2: We now have two parallel block-building entities: one for L1 (the builder) and another for L2 (the preconfer). Consequently, L1-L2 composability now requires coordination between the builder and the preconfer. This adds complexity and can lead to builder-preconfer integration, where the proposer delegates not only their preconfirmation right but also the whole block-building right to the preconfer ahead of their slot.

In summary, by introducing preconfirmations, we lost the below structure:

As a result, many of the benefits of based rollups are diminished.

So, what if we keep this pipeline but run it multiple times within a slot to achieve fast preconfirmations? This brings us to the main contribution of this document: Multi-round MEV-Boost.

Multi-round MEV-Boost

At a high level, Multi-round MEV-Boost, or MR-MEV-Boost (pronounced “mister-mev-boost”, h/t Conor for the idea on the pronounciation :)) for short, works as follows:

• Split each slot into a fixed number of rounds, e.g., 4 rounds with 3 seconds each.
• Within each round, run a single MEV-Boost auction. As a result of the auction, a single partial block (a.k.a partial payload) will be signed and published, i.e., the partial block will be preconfirmed.
• The full block is created and published at the end of the slot. The full block should contain the partial blocks in the exact order they were preconfirmed without inserting any transactions before or in between.

Refresher: MEV-Boost

Before diving deeper into the proposed protocol, let’s quickly review today’s MEV-Boost PBS pipeline used in L1 Ethereum.

1. Builders send the header, payload, and bid to the relayer.
2. The relayer checks the validity (the bid is correct, the payload does not contain invalid transactions, etc), stores the payload, and then sends the header and bid to the proposer.
3. The proposer selects the header with the highest bid, signs it, and then sends the signed header to the relayer.
4. The relayer propagates the signed header and corresponding payload to the network.

Protocol Description

In this section, we describe the MR-MEV-Boost protocol.

Protocol Flow Overview

To incentivize proposers to provide preconfirmations, we introduce a preconf transaction, where the payment of a preconf tip is conditioned on being preconfirmed. It will include the following information on top of the transaction payload itself:

• tip: The preconfirmation tip paid for being preconfirmed.
• target_slot: The latest slot in which the preconf transaction can be included.
• target_round: The latest round within the target_slot in which the preconf transaction can be included.

The Preconf Transaction section will discuss the encoding and enforcement of these conditions.

Using this new transaction type, MR-MEV-Boost works as follows:

1. Users submit preconf transactions to the builders. The submission can be through any order flow pipeline used in current L1, such as:
   • Public mempool.
   • Private order flow.
   • Order flow auctions on MEVBlocker, MEV-Share, SUAVE, etc.
2. The builders build partial_payloads. The partial payload built by the builders should only include preconf transactions with target_slot and target_round at or after the current block/round. To commit to this, the builder signs the merkle_root (denoted as sig_b ) and becomes subject to builder slashing condition 1, described in the slashing condition section.
3. The relayer checks the validity (e.g., the bid is correct, the partial_payload does not contain invalid transactions, etc.), stores the partial_payload, and then sends the merkle_root and bid to the proposer.
4. Proposer signs (denoted as sig_p) and returns the selected merkle_root together with the current round.
5. The relay publishes the selected partial_payload and the associated round and signatures to the preconf network. Note that the preconf network is different from the existing L1 p2p network. Only entities interested in the preconfirmed state (partial block builders, relays, full-node providers, etc.) must subscribe to the preconf network.
6. End users—or, more precisely, the L2/L1 full nodes to which they are connected—verify that the merkle_root is signed by the proposer and is associated with the current round. Upon confirmation, they accept the partial_payload as preconfirmed and execute it to update to the latest preconfirmed state.
7. 1. to 6. is repeated multiple rounds within the slot. The number of rounds within each slot will be fixed. The final round will run concurrently with the full block MEV-Boost auction at 8.-11.
8. to 11. The MEV-Boost auction is conducted for the full block. An important difference with the usual L1 MEV-Boost auction is that the merkle_proofs are propagated from the builder to the proposer. These proofs prove that the partial_payloads are included in the full block in the order they were preconfirmed without any other transaction being inserted before or between them. By validating these proofs, the proposer can ensure that the proposer slashing condition 2, described in the slashing conditions section, is not violated without needing to trust the relayer (h/t to Brecht for the idea of using Merkle proofs here).

Preconf Transaction

Let’s consider the encoding of the preconf transactions. For L2s, the additional fields can be introduced as custom encodings of the transactions. For L1, they can be implemented through an ERC-4337-style entry point contract that wraps the contract calls with additional information.

To enforce the expiration, the L2 execution layer (or derivation layer) and L1 entry point contract will filter out preconf transactions with expired target_slot. On the other hand, since the L1 is unaware of the concept of rounds, expiration based on target_round will be enforced via builder slashing condition 1, explained in the next section.

Slashing Conditions

To ensure that the full block matches with the preconfed partial blocks, the proposer will be subject to:

• Proposer slashing condition 1: The proposer must not sign two conflicting merkle_roots within the same round.
• Proposer slashing condition 2: The final full_payload should contain all the partial_payloads in the order they are signed and published without any other transaction being inserted before or in between.

Furthermore, to crypto-economically enforce the expiration of preconf transactions, the builder will be subject to:

• Builder slashing condition 1: Each partial_payload must only include preconf transactions with target_slot and target_round at or after the current slot/round.

We impose this condition on the builder rather than the proposer because the proposer does not see the partial payload when signing. An alternative approach would be to make this a proposer slashing condition and require the relayer to ensure the condition is not violated. However, this would necessitate the proposer trusting the relayer to avoid being slashed rather than only relying on the relayer to avoid missing a slot, as is currently done in L1 MEV-Boost.

User Actions

To mitigate the fair exchange problem, wallets or full nodes to which end users are connected should take the actions below:

• User action 1: Stop submitting preconf transactions if preconfirmed partial_payloads are not published in a timely manner. For example, if we have 4 rounds in a slot, then stop submitting preconf transactions if a partial_payload is not published every 3 seconds.
• User action 2: Set target_slot and target_round to a reasonably close block and round (e.g., one or two rounds ahead). By doing so, builders are required to respond in a timely manner to preconfirmation transactions to avoid the preconfirmation transactions being invalidated.

More on how the fair exchange is addressed is described in the analysis section.

L1-L2 Composability

Since the partial payloads can contain both L1 and L2 transactions, builders can ensure L1-L2 composability by including L1-L2 transaction bundles in the partial payloads.

Non-opted-in Slots

When the current L1 slot’s proposer has not opted in as a preconfer, L1 transactions will be proposed by the current proposer, while L2 transactions will be proposed by the next opted-in preconfer in the lookahead (we follow Justin’s original based preconfirmation design here). This results in two simultaneous MEV-Boost auctions: the usual L1 MEV-Boost auction signed by the current L1 proposer and the MR-MEV-Boost auction signed by the next preconfer. As a result, L1-L2 composability and L1 preconfirmation will be lost during these non-opted-in slots. Note that this limitation applies to all off-protocol preconfirmation designs.

Analysis

In this section, we will perform an initial analysis of the proposed protocol and identify its drawbacks.

Have we solved the problems?

Let’s revisit the problems raised in the Strawmanning Based Preconfirmations post and see if and how MR-MEV-Boost addresses them.

Problem 1: Latency race

Latency races are when searchers fight to be the first to access the preconfer, leading to colocation or vertical integration. With MR-MEV-Boost, this issue is largely mitigated by preconfirming batches and conducting auctions within the batch, as it promotes competition based on price rather than speed. It is generally acknowledged that batch auctions help reduce latency wars compared to continuous first-come, first-served ordering, as described in this paper and this post.

Problem 2: Congestion

Congestion issues arise when searchers flood the rollup with probabilistic arbitrage attempts. With MR-MEV-Boost, this issue is mitigated as searchers are incentivized to participate in auctions rather than resort to spam.

Problem 3: Tip pricing

The MEV-Boost auction will handle the tip pricing of the preconfirmation. Furthermore, by introducing batching and auctions within the batch, proposers can price the preconfirmation tips more effectively (hence capturing revenue) than by providing a continuous stream of per-transaction preconfirmations.

Problem 4: Fair exchange

Let’s see how MR-MEV-Boost addresses the fair exchange problem, where the proposer withholds publishing preconfirmations to the user. Note that preconfers are incentivized to withhold preconf promises as much as possible to maximize their opportunity to reorder and insert transactions, thereby increasing their MEV.

There are two cases to consider:

• If the proposer withholds preconfirming partial payload (i.e., stops signing merkle_roots of partial_payloads), users will stop sending preconfirmation requests (user action 1), reducing the proposer’s order flow and, consequently, revenue.
• If the proposer intentionally publishes empty partial payloads, pending preconf transactions will expire after a few rounds (user action 2 and builder slashing condition 1), reducing the proposer’s order flow and, consequently, revenue.

In summary, end users monitor and enforce proposers’ honest behavior by linking the proposers’ revenue to the timely preconfirmation of partial payloads.

A potential alternative would be to introduce a committee to monitor and attest to the timely releases of partial payloads. However, this would require additional trust assumption to an external committee unless we enshrine the protocol into the L1. More on enshrinement in the future direction section.

Problem 5: Liveness

With existing based preconfirmation designs where preconfirmation duties are delegated ahead of the slot, liveness relies on this single external entity for the duration of the preconfer’s slot(s). On the other hand, with MR-MEV-Boost, liveness concerns are reduced as we do not introduce such “lock-in” to a specific entity before the slot. If some builders or relayers are unavailable, others can step in to maintain functionality. Moreover, even if the entire multi-round MEV-Boost pipeline fails, proposers still have the option to construct their own partial blocks and preconfirm them independently.

Problem 6: Early auctions

Early auctions are not introduced as preconfirmations are provided through the MEV-Boost JIT auctions.

Round Interval

How short can each round in MR-MEV-Boost be? If it is too long, it will degrade the user experience; if it is too short, it will impose excessive network and hardware requirements on builders and relays, thus hurting decentralization.

In each round, the relayer has two tasks:

• (A) Run the partial block auction.
• (B) Propagate the partial block.

Task (A) consists of the time it takes the builder to construct the block, the time it takes the relay to validate the block, and two network round-trips: one between the builder and the relay and another between the relay and the proposer. Assuming that block construction, validation, and network round-trips take 500 milliseconds each, we get a ballpark estimate of 2 seconds.

For task (B), considering L1 allocates 4 seconds for block propagation and 8 seconds for consensus, and no consensus is needed for partial blocks, a good upper bound for propagation time is 4 seconds. In practice, it should be much shorter because only block builders, relays, and full-node providers need to receive these partial blocks, and they have better network bandwidth and lower latency than average validators. Let’s assume 1-2 seconds for this analysis.

Combining 2 seconds for (A) and 1-2 seconds for (B) gives us 3-4 seconds per round.

These estimates are highly approximate, and further research and analysis are needed. Additionally, making the interval too short will intensify latency races toward the end of the batch duration, as described here, and should be considered.

Drawbacks

Next, we will outline the drawbacks of this protocol when compared to existing based preconfirmation designs, such as the one described in the original post. An analysis of more general drawbacks of preconfirmations will be reserved for future work.

No Speed-of-light Continuous Preconfirmations

MR-MEV-Boost does not provide speed-of-light preconfirmations with hundreds of milliseconds latency, like Arbitrum’s first-come-first-serve sequencer. Instead, it offers preconfirmations in batches with a few seconds of latency between them, similar to Optimism’s approach.

Solana and Jito provide an interesting case study on continuous versus batched preconfirmations. In Solana’s “continuous block building,” the leader streams (i.e., preconfirms) processed transactions continuously. Combined with Solana’s fixed low fee, continuous block building led to network spamming and latency races, causing validators to waste 58% of their time processing failed arbitrages. Jito addressed this by introducing a 200ms “speed bump” (batches) and a mev-geth style bundle auction for batches, achieving an 80% share with their Jito validator client. This example indicates that that continuous preconfirmations are likely unsustainable due to spam and that batching and some auction for each batch are required. For more details, watch this informative talk by Zano Sherwani, co-founder of Jito, here.

Relay Burden

MR-MEV-Boost introduces additional burdens to the relays without incentives. Instead of managing a single round of MEV-Boost auctions, relayers must handle multiple rounds within a single slot, each within a limited timeframe. If the cost of operating a relayer increases too much, it may lead to further relayer centralization and builder-relay integration, or alternatively, no relayer may opt to support MR-MEV-Boost. Relayer incentives are a long-lasting problem in L1, and MR-MEV-Boost likely worsen this situation.

One way to mitigate the issue is to incorporate optimistic relay schemes to reduce the relayer’s operational costs. With this approach, relayers optimistically assume the honesty of the block-builder and skip the validation work for payloads sent from the builder. If the builder is later found to deviate from honest behavior, their collateral will be used to refund the proposer. Optimistic relaying would be especially helpful as it allows relayers to bypass the need to validate the based rollup transactions when verifying partial blocks.

Another potential solution is for the proposers to share the preconfirmation tip revenue with the relay to compensate for the additional workload.

Blob Efficiency

So far, we have blurred the line between L1 and L2 preconfirmations. This is somewhat intentional, as L2 transactions are included within L1 transactions. However, there are cases where the difference becomes important.

Consider a scenario where the L2 transactions within a round cannot fill an entire blob. If we only support preconfirmations for L2 transactions by preconfirming the L1 transactions that contain them, we face a problem. Proposers would either have to preconfirm partially filled blob transactions at the end of the round or wait for another round to collect enough transactions to fill the blob.

One solution is to allow proposers to commit to a batch of L2 transactions without linking them to a specific L1 transaction. This would let the builder of the final full block aggregate the L2 transactions into one or more L1 blobs at the end of the slot.

Issues with MEV-Boost

MR-MEV-Boost inherits the existing L1 MEV-Boost pipeline, which also means that we inherit many of MEV-Boost’s downsides, such as reliance on a handful of relays and builders. However, based rollups aim to inherit the security of L1, not to exceed it. Therefore, being “as bad as” L1 is the best we can do as a based solution.

Future Direction

MR-MEV-Boost can be generalized as partial-block preconfirmations, where the proposer incrementally builds the block by committing to and publishing partial blocks during their slot.

One future direction would be to enshrine partial-block preconfirmations into the L1 protocol to achieve faster block times. This aligns with Vitalik’s recent post and offers several benefits over off-protocol designs like MR-MEV-Boost:

• Removes “non-opted-in” proposers, enabling L1 preconfirmations and L1-L2 composability for all slots.
• Fully utilizes Ethereum’s validator set, potentially introducing lightweight PTC-like attestations for timely partial payload releases.
• Opens doors to increase the block times without degrading UX, which may help enable single-slot finality.

Related Work

In his latest post, Jon Charbonneau explains in great detail how based rollups/preconfirmations work and the centralization risk of based preconfirmations.

Furthermore, partial-block preconfirmations are closely related to inclusion list research, as both can be viewed under the broader concept of “partial-block building,” where different parts of a block are constructed at different times by different entities. For example, the MEV-Boost++ proposal from Kyodo (EigenLayer) resembles MR-MEV-Boost, as both enable early commitment to partial blocks by imposing additional slashing conditions on the proposer.

Conclusion

We introduce MR-MEV-Boost, a design that enables based preconfirmations by running multiple rounds of MEV-Boost auctions within a single slot. By inheriting the L1 PBS pipeline, MR-MEV-Boost mitigates many of the negative externalities of based preconfirmations while retaining the benefits of based rollups.

At Nethermind Switchboard, we actively research and tackle the open challenges of based preconfirmations. We are also collaborating closely with Taiko to develop a PoC for based preconfirmations compatible with L2 PBS, including MR-MEV-Boost. Stay tuned for more updates!

5 posts - 3 participants

Read full topic

This study is supported by an Ethereum Foundation R&D grant and is a collaborative work with Enrico ( @enricobottazzi ), Masato ( @0xvon ) and Nam ( namnc (Nam Ngo) · GitHub ) from Ethereum Foundation.

Abstract

Executing graph optimization algorithms such as the Minimum Mean Cycle (MMC) while preserving privacy has significant potential for handling sensitive information between users and companies. For example, it enables multilateral netting to solve the Minimum Cost Flow (MCF) problem [4] without disclosing mutual debts, making it highly relevant for processes like netting among multinational corporations. Aly et. al. [2] proposed an algorithm using Multi-Party Computation (MPC) to execute the MMC problem. However, this approach is based on Karp’s algorithm [1], which was found by Chaturvedi et al. [3] to occasionally fail to detect cycles. In this study, we propose a revised protocol that corrects this issue and enhances its efficiency. We implemented our protocol using MP-SPDZ and confirmed that it correctly identifies the MMC, similar to traditional protocols. Our findings indicate that our proposed protocol operates correctly and more efficiently than Aly’s protocol, which reduces the time/round complexity from O(|V|^5) to O(|V|^3) and the space complexity from O(|V|^4) to O(|V|^2). Furthermore, we discuss potential improvements for even more efficient algorithms.

1. Introduction

1-1. Importance of Graph Theory Optimization

Graph theory optimization problems play a crucial role in various domains, from computer science and engineering to economics and finance. These problems involve finding the most efficient way to navigate, connect, or utilize network structures, and solutions to these problems have far-reaching implications for improving systems and processes.

One of the representative problems in graph theory optimization is the Minimum Cost Flow (MCF) problem, which aims to find the least costly way to send a certain amount of flow through a network. The MCF problem is foundational in numerous applications, providing critical insights and optimizations.

In the financial sector, particularly in Netting, the Minimum Cost Flow (MCF) problem is often addressed to optimize the settlement of transactions and reduce systemic risk [4]. Netting involves aggregating multiple financial obligations to streamline transactions, minimize risk, and enhance efficiency. However, one of the critical challenges in this context is maintaining the privacy and confidentiality of sensitive financial data. Traditional methods for solving the MCF problem may require exposing transaction details, leading to significant privacy concerns and potential security risks.

Beyond netting, the MMC problem and its solutions have a wide array of applications across various fields:

• Network Security: Enhancing security measures by optimizing the flow of information and resources while minimizing potential points of vulnerability.
• Supply Chain Management: Streamlining logistics and distribution networks to reduce costs and improve delivery times.
• Urban Planning: Developing efficient transportation systems by optimizing traffic flow and reducing congestion.

The Minimum Mean Cycle (MMC) problem is a crucial component in solving the MCF problem. The MMC problem focuses on identifying cycles in directed graphs with the minimum average weight, which is essential for detecting inefficient paths and optimizing network performance. By incorporating the MMC problem into the solution of the MCF problem, we can achieve more accurate and efficient outcomes.

To address the privacy concerns inherent in solving the MCF problem, we explore the use of Multi-Party Computation (MPC) to securely solve the MMC problem. MPC is a cryptographic approach that allows multiple parties to collaboratively compute a function over their inputs while keeping those inputs private. By applying MPC techniques, we can solve the MMC problem without exposing sensitive data, thus preserving the privacy of financial transactions and other confidential information.

1-2. Previous Work

Aly et al. [2] proposed a method to solve Karp’s MMC algorithm [1] using Multi-Party Computation. However, this approach has some problems and suffers from significant computational complexity and time consumption. Additionally, the Karp’s algorithm [1] was found by Chaturvedi et al . [3] to occasionally fail to detect cycles.

1-3. Our Contribution

in this study, we propose a novel approach that not only addresses these shortcomings but also offers a more efficient and practical solution for securely solving the MMC problem using MPC. Our proposed protocol aims to reduce computational and time complexities, enhance cycle detection accuracy, and ensure robust privacy protection. Our experimental results demonstrate a significant improvement in efficiency, with a reduction in time complexity from O(|V|^5) to O(|V|^3) and space complexity from O(|V|^4) to O(|V|^2).

2. Minimum Mean Cycle Problem

Minimum Mean Cycle Problem and its solution is defined by Karp in 1978 [1].

2-1. Problem Definition

Given a connected graph G(V,E) where V is a set of nodes and E is a set of edges, with defining these parameters:

• c_{i,j} \in C denotes the cost on the edge (i,j).
• d^k(i) denotes the minimum cost from node s to i that contains exactly k edges.

First of all, for any cycle X, the mean cycle is defined by:

Thus, the minimum mean cycle is:

Minimum Mean Cycle (MMC) Problem is the problem to find this \mu ^*.

2-2. Efficient MMC

The MMC problem is known as NP-hard, and Karp introduces an efficient algorithm for solving it. The solution is followed by 2 steps.

The first step, we call it as Walk, is to calculates d^k(i), which denotes minimum cost from node s to i that contains exactly k edges. Walk can be computed via the recurrence:

Initially, d^0(j)=\infty, except for the source node d^0(s)=0

The second step is to calculate the minimum mean cycle by:

See Karp’s paper [1] for a proof of equation (4). Overall algorithmic complexity is O(|V| \cdot |E|), and the first step has a significant impact on the entire algorithm.

3. Aly’s Secure MMC Protocol

Notation

• [a] denotes secret shared or encrypted values of a
• [z] = _{[c]} [x]:[y] denotes the assignment that if [c] is one, [x] is assigned to [z] or [y] otherwise.

3-1. Protocol

Aly et. al. [2] provide algorithmic solutions to MMC problem in a secure multi-party and distributed setting. This protocol is constructed by 2 sub-protocols:

1. walk([C],[b]) \rightarrow [A],[walks]
2. mmc([A],[walks]) \rightarrow [\text{min-cost}], [\text{min-cycle}]

This corresponds to Steps 1 and 2 of Karp’s Algorithm in section 2.

In first sub-protocol, we have two inputs. The cost matrix [C]_{ij} denotes the cost of edge (i,j). It represents [\infty] for non-existing edges. The viable matrix [b]_{ij} denotes 1 if edge (i,j) doesn’t exist, and 0 otherwise.

From these inputs, we outputs two values. One is the 2-dimensional walk cost matrix [A] which [A]_{jk} records d^k(j). The other is 4-dimensional walk path matrix [walks] which [walks]_{ijkl} records the number of times the edge (i,j) is traversed by the shortest walk of length k from s to l. The algorithm is detailed as Protocol 3-1.

Protocol 3-1. Aly’s Walk Protocol

Input: A matrix of shared costs [C]_{ij} for i,j \in \{1,2,...,|V|\}, a binary matrix on viable adges [b]_{ij} for i,j \in \{1,2,...,|V|\}.

Output: A matrix of walk costs [A]_{ik} for i \in \{1,2,...,|V|\} and k \in \{0,1,...,|V|\}, a wak matrix [walks]_{ijkl} for i,j,k,l \in \{1,2,...,|V|\} encoding these walks.

1. [A] \leftarrow [\infty], [A]_{00} \leftarrow [0], [C] \leftarrow [C] + [\infty](1-[b])
2. for k \leftarrow 1 to |V|+1 do
   1. for j \leftarrow 1 to |V| do
      1. for i \leftarrow 1 to |V| do
         1. [c] \leftarrow [A]_{ik-1} + [C]_{ij} < [A]_{jk}
         2. [A]_{jk} \leftarrow _{[c]} [A]_{ik-1} + [C]_{ij} : [A]_{jk}
         3. [walks]_{..kj} \leftarrow _{[c]} [walks]_{..k-1i} : [walks]_{..kj}
         4. [walks]_{ijkj} \leftarrow _{[c]} [walks]_{ijkj} + 1 : [walks]_{ijkj}
      2. end
   2. end
3. end

In second sub-protocol, we have two outputs. [\text{min-cost}] is the minimum mean cost. [\text{min-cycle}] denotes the 2-dimensional cycle matrix which [\text{min-cycle}]_{jk} is 1 if edge (j,k) is included in the cycle achieving \mu ^* and 0 otherwise. Here, \text{min-cycle} is s-j path with |V| edges whose cost is d^{|V|}(j), minus the s-j path with k edges whose cost is d^{k}(j). The details are provided as protocol 3-2. We note that we use the theorem that \frac{a}{b}>\frac{c}{d} \iff ad>bc to make a comparison of \frac{d^V(j) - d^k(j)}{|V| - k} without calculating the inverse.

Protocol 3-2. Aly’s MMC Protocol

Input: A matrix of walk costs [A]_{ik} for i \in \{1,2,...,|V|\} and k \in \{0,2,...,|V|\}, a walk matrix [walks]_{ijkl} for i,j,k,l \in \{1,2,...,|V|\} encoding these walks.

Output: The cost of the minimum mean cycle [\text{min-cost}], a matrix with the minimum mean cycle [\text{min-cycle}]_{ij} for i,j \in \{1,2,...,|V|\}

1. for j \leftarrow 1 to |V| do

   1. [\text{max-cycle}],[\text{max-cost}] \leftarrow \phi
   2. for k \leftarrow |V| to 1 do
      1. [\text{a-num}] \leftarrow [A]_{j(|V|+1)} - [A]_{jk}
      2. [\text{a-den}] \leftarrow |V|-k
      3. [c] \leftarrow [\text{k-num}] \cdot [\text{a-den}] < [\text{a-num}] \cdot [\text{k-den}]
      4. [\text{k-num}] \leftarrow _{[c]} [\text{a-num}] : [\text{k-num}]
      5. [\text{k-den}] \leftarrow _{[c]} [\text{a-den}] : [\text{k-den}]
      6. [\text{max-cycle}] \leftarrow _{[c]} [walks]_{..|V|j} - [walks]_{..kj} : [\text{max-cycle}]
      7. [\text{max-cost}] \leftarrow _{[c]} [A]_{jk} : [\text{max-cost}]
   3. end
   4. [c] \leftarrow [\text{j-num}] \cdot [\text{k-den}] < [\text{k-num}] \cdot [\text{j-den}]
   5. [\text{j-num}] \leftarrow _{[c]} [\text{k-num}] : [\text{j-num}]
   6. [\text{j-den}] \leftarrow _{[c]} [\text{k-den}] : [\text{j-den}]
   7. [\text{min-cycle}] \leftarrow _{[c]} [\text{max-cycle}] : [\text{min-cycle}]
   8. [\text{min-cost}] \leftarrow _{[c]} [\text{max-cost}] : [\text{min-cost}]

2. end

Complexity

This method requires O(|V|^5) time/round complexity, from the conditional assignments to |V| \times |V| elements in [walks] matrix for |V|^3 loops (line i-3~4 of Protocol 1). And this method requires O(|V|^4) space complexity, due to 4-dimensional [walks] matrix.

3-2. Problem in Aly’s Protocol

Aly’s protocol implements Karp algorithm [1] in the secure manner. In karp’s alrogithm, we determine \text{min-cycle} like s-j path with |V| edges whose cost is d^{|V|}(j), minus the s-j path with k edges whose cost is d^{k}(j). However, Chaturvedi and McConnell [3] provides an counterexample which the cycle couldn’t detected with this method. Furthermore, they prove the following lemma.

Lemma 1
Let j be a vertex such that there exists k, where j and k are a minimizing pair. Every cycle on the length |V| edge progression from s to j of cost d^{|V|}(j) is a cycle of minimum mean cost. (See the proof on their paper [3].)

This lemma means that the cycle can be detected by traversing the edge progression from the last edge and marking the vertices visited by the walk until a previous marked vertex is encountered, from s-j path with |V| edges whose cost is d^{|V|}(j).

4. CM-based Secure MMC Protocol

Notation

• [a] denotes secret shared or encrypted values of a
• [z] = _{[c]} [x]:[y] denotes the assignment that if [c] is one, [x] is assigned to [z] or [y] otherwise.

4-1. Protocol

We propose a protocol that converts the minimum mean cycle detection from Aly’s protocol to one with Lemma1. In addition, a few changes have been made to the data structure. We name it “CM-based Securely MMC Protocol”, taking the initials of Chaturvedi and McConnell, who proposed Lemma 1.

CM-based protocol is constructed by 3 sub-protocols:

1. walk([C],[b]) \rightarrow [A],[ep]
2. mmc
   1. mmcn([A],[ep]) \rightarrow [\text{min-cost}],[\text{minimizing-node}]
   2. extract\text{-}cycle([\text{minimizing-node}],[ep]) \rightarrow [\text{min-cycle}]

Here, Aly’s second sub-protocol is divided into CM-based second and third sub-protocols.

In fist sub-protocol, For the most part, it is the same as Protocol 3-1, with one difference: Instead of [walks], we record the edge progression in a 2-dimensional matrix called [ep], which [ep]_{jk} means the edge that passes before one of j in the shortest s-j path with k edges. This change eliminates the need for extra |V|^2 loops to update [walks]_{..kj}. The algorithm is detailed as Protocol 4-1.

Protocol 4-1. CM-based Walk Protocol

Input: A matrix of shared costs [C]_{ij} for i,j \in \{1,2,...,|V|\}, a binary matrix on viable adges [b]_{ij} for i,j \in \{1,2,...,|V|\}.

Output: A matrix of walk costs [A]_{ik} for i \in \{1,2,...,|V|\} and k \in \{0,1,...,|V|\}, a matrix of walk edge progressions [ep]_{ij} for i,j \in \{1,2,...,|V|\}.

1. [A] \leftarrow [\infty], [A]_{00} \leftarrow [0], [C] \leftarrow [C] + [\infty](1-[b])
2. for k \leftarrow 1 to |V|+1 do
   1. for j \leftarrow 1 to |V| do
      1. for i \leftarrow 1 to |V| do
         1. [c] \leftarrow [A]_{ik-1} + [C]_{ij} < [A]_{jk}
         2. [A]_{jk} \leftarrow _{[c]} [A]_{ik-1} + [C]_{ij} : [A]_{jk}
         3. [ep]_{jk} \leftarrow _{[c]} i : [ep]_{jk}
      2. end
   2. end
3. end

In (a) of the 2nd sub-protocol, instead of computing [\text{min-cycle}], we detect the node j that achieves mmc. We call it minimizing node.

The algorithm is detailed as Protocol 4-2-a.

Protocol 4-2-a. CM-based MMCN Protocol

Input: A matrix of walk costs [A]_{ik} for i \in \{1,2,...,|V|\} and k \in \{0,2,...,|V|\}, a matrix of walk progressions [ep]_{ij} for i,j \in \{1,2,...,|V|\}.

Output: The cost of the minimum mean cycle [\text{min-cost}], the node achieving the minimum mean cycle [\text{minimizing-node}].

1. for j \leftarrow 1 to |V| do

   1. [\text{max-cost}] \leftarrow \phi

   2. for k \leftarrow |V| to 1 do

      1. [\text{a-num}] \leftarrow [A]_{j(|V|+1)} - [A]_{jk}
      2. [\text{a-den}] \leftarrow |V|-k
      3. [c] \leftarrow [\text{k-num}] \cdot [\text{a-den}] < [\text{a-num}] \cdot [\text{k-den}]
      4. [\text{k-num}] \leftarrow _{[c]} [\text{a-num}] : [\text{k-num}]
      5. [\text{k-den}] \leftarrow _{[c]} [\text{a-den}] : [\text{k-den}]
      6. [\text{max-cost}] \leftarrow _{[c]} [A]_{jk} : [\text{max-cost}]

   3. end

   4. [c] \leftarrow [\text{j-num}] \cdot [\text{k-den}] < [\text{k-num}] \cdot [\text{j-den}]

   5. [\text{j-num}] \leftarrow _{[c]} [\text{k-num}] : [\text{j-num}]

   6. [\text{j-den}] \leftarrow _{[c]} [\text{k-den}] : [\text{j-den}]

   7. [\text{minimizing-node}] \leftarrow _{[c]} j : [\text{minimizing-node}]

   8. [\text{min-cost}] \leftarrow _{[c]} [\text{max-cost}] : [\text{min-cost}]

2. end

In (b) of the 2nd sub-protocol, from [\text{minimizing-node}], we construct a back pointer which indicates s-j path with |V| edges whose cost is d^{|V|}(j) and extract a cycle from the back pointer. Compared to Protocol 3-2, instead of expanding [\text{min-cycle}] directly from [walks], the additional protocol is required. We follow Lemma 1 and consider any cycle included in the back pointer as a minimum mean cycle. The algorithm is detailed as Protocol 4-2-b.

Protocol 4-2-b. CM-based Extract-Cycle Protocol

Input: A minmizing node [\text{minimizing-node}], a matrix of walk progressions [ep]_{ij} for i,j \in \{1,2,...,|V|\}.

Output: A matrix with the minimum mean cycle [\text{min-cycle}]_{ij} for i,j \in \{1,2,...,|V|\}

1. [\text{backpointers}]_{0} \leftarrow [\text{minimizing-node}], [\text{next-index}] \leftarrow [\text{minimizing-node}]
2. for k \leftarrow |V| to 1 do
   1. [\text{val}] \leftarrow [0]
   2. for j \leftarrow 0 to |V|-1 do
      1. [match] = j == [\text{next-index}]
      2. [\text{val}] = _{[\text{match}]} [ep]_{jk}:[\text{val}]
      3. [\text{match-index-matrix}]_{jk} = [match]
   3. end
   4. [\text{next-index}] = [\text{val}]
   5. [\text{backpointers}].append([\text{val}])
3. end
4. for i \leftarrow 0 to |V|-1 do
   1. [\text{counter}] \leftarrow [0]
   2. for k \leftarrow 0 to |V| do
      1. [\text{counter}] = [\text{counter}] + [\text{match-index-matrix}]_{ik}
   3. [c] = [\text{counter}] >= 2
   4. [\text{cycle-node}] = _{[c]} i : [\text{cycle-node}]
5. end
6. [\text{min-cycle}] \leftarrow [0],[\text{counter}] \leftarrow [0]
7. for k \leftarrow |V| to 1 do
   1. [\text{edge-from}] \leftarrow [\text{backpointers}]_k
   2. [c] = [\text{edge-from}] [\text{cycle-node}]
   3. [\text{counter}] = [\text{counter}] + [c]
   4. [c_0] = [\text{counter}] + 1
   5. for j \leftarrow 0 to |V|-1 do
      1. [c_1] = [\text{match-index-matrix}]_{jn-k}
      2. [c_2] = [c_0]*[c_1]
      3. for i \leftarrow 0 to |V|-1 do
         1. [c_3] = [\text{match-index-matrix}]_{jn-k+1}
         2. [\text{min-cycle}]_{ji} = [\text{min-cycle}]_{ji} + ([c_2] * [c_3])
      4. end
   6. end
8. end

Complexity
This ****method requires O(|V|^3) multiplications or communication rounds, from the conditional assignments of [A],[ep],[\text{min-cycle}] for |V|^3 loops (line i-2~3 of Protocol 4-1 and like iii-3 of Protocol 4-2-b). And this method requires O(|V|^2) space complexity, largely due to 2-dimensional matrixes. A table comparing the Complexity of each protocol is shown in Table 4-1 below.

Table 4-1. Complexity Analysis of Secure MMC Protocols

4-2. Implementation

We have implemented CM-based Securely MMC protocol in naive secret sharing scheme using Python MP-SPDZ. And we confirmed that the minimum mean cycle was found reliably in a number of random edges, including the counterexamples shown by Chaturvedi et al [3].

5. Conclusion

In this study, we have proposed a more efficient protocol for solving the Minimum Mean Cycle (MMC) problem using Multi-Party Computation (MPC). Our CM-based approach not only addresses but also significantly improves upon the issues identified in Aly’s protocol. Specifically, our protocol reduces the time/round complexity from O(|V|^5) to O(|V|^3) and the space complexity from O(|V|^4) to O(|V|^2) compared to Aly’s protocol.

Despite these advancements, the complexity remains super-quadratic in terms of the number of nodes, which can pose practical challenges for very large graphs. To mitigate this limitation, we propose the following strategies:

• By exposing the graph’s topography, we can optimize the edge search to include only the minimum necessary edges, thereby reducing the time/round complexity to O(|V|^2 \cdot |E|). This approach, however, requires a trade-off with some degree of privacy.
• Implementing simpler algorithms that provide approximate or sub-optimal solutions, such as Greedy Algorithms and Distributed Algorithms, can further enhance practicality. These algorithms can significantly reduce computational overhead while delivering sufficiently accurate results for many applications.

In summary, our protocol offers a substantial improvement over existing methods, paving the way for more efficient and practical solutions to the MMC problem in secure computation settings. Future work will focus on refining these strategies to further balance the trade-offs between efficiency, accuracy, and privacy.

Reference

1. Richard M. Karp, “A characterization of the minimum cycle mean in a digraph”, Discrete Mathematics, Volume 23, Issue 3, 1978, Pages 309-311, ISSN 0012-365X, https://doi.org/10.1016/0012-365X(78)90011-0.
2. Aly, A., Van Vyve, M. (2015). Securely Solving Classical Network Flow Problems. In: Lee, J., Kim, J. (eds) Information Security and Cryptology - ICISC 2014. ICISC 2014. Lecture Notes in Computer Science(), vol 8949. Springer, Cham. Securely Solving Classical Network Flow Problems | SpringerLink
3. Mmanu Chaturvedi, Ross M. McConnell, “A note on finding minimum mean cycle”, Information Processing Letters, Volume 127, 2017, Pages 21-22, ISSN 0020-0190, Redirecting.
4. Fleischman, T.; Dini, P. “Mathematical Foundations for Balancing the Payment System in the Trade Credit Market”, J. Risk Financial Manag. 2021, 14, 452. JRFM | Free Full-Text | Mathematical Foundations for Balancing the Payment System in the Trade Credit Market

1 post - 1 participant

Read full topic

Sealed execution auction

By Anders.

While working on the dynamic pricing auction I though of another way to hold the auction that also seems interesting. Posting a rough sketch here, although I am not yet certain of its viability. Thanks to Justin, Barnabé and Terence.

Introduction

In the process of enshrining proposer–builder separation (ePBS), it has been suggested that attesting and execution proposing should be more fully separated. Proposals such as execution tickets (ETs) and execution auctions (EAs) strive to allocate the right to propose execution blocks to entities other than the validators. This also facilitates MEV burn. There have been concerns (1, 2, 3) around insufficient early bidding in the MEV pricing auctions with a base fee floor used in EA. By considering the staking metagame, this issue is potentially resolved, but the resulting attester–builder integration can then by itself be problematic. There is also a general concern that the decided-upon auction design will induce MEV, and no definite specification among several alternatives for the auction design in ET. For this reason, it seems fruitful to explore an auction that facilitates true separation and does not induce MEV. One such mechanism recently proposed is the MEV resistant dynamic pricing auction. In the context of Vickrey auctions of execution rights, Timeboost under consideration by Arbitrum can also be mentioned.

This post proposes a Vickrey slot auction in two rounds to select a forthcoming execution proposer (akin to EA), referred to as a sealed execution auction (SEA). Staked builders make sealed bids for the right to propose an execution block. Bids are observed by attesters and then collated by the beacon proposer. In subsequent steps, builders reveal their bids, attesters observe the revealed bids, and the proposer once again collates them. The right to propose a forthcoming execution block is awarded to the highest bidder, paying according to the second-highest bid, with the payment burned.

Auction

Staked builders

Builders are staked at a level sufficient for the protocol to penalize them if they fail to reveal committed bids. The stake can also serve as a deposit account to pay for winning bids, or this account can be managed separately.

Sealed bids

Figure 1 gives an overview of the auction. In the first round, each builder has the opportunity to make one sealed bid over a public P2P layer. There might be a small fee for making a bid, as a further anti-Sybil measure. Attesters observe the sealed bids that have come in at time T_1. Around two seconds later, at T_2, the beacon proposer collates sealed bids (including any bids it finds after T_1), and broadcasts them in a structure. This structure may be a beacon block if the auction proceeds over two slots (see Timeline). At T_3, attesters observe the structure and make sure that all previously observed bids at T_1 have been included. If the bids were included in a beacon block, they will attest to the block contingent on correct and timely collation. If not included in a beacon block and the proposer equivocates on the structure, the subsequent block must be rejected.

Figure 1. Sealed execution auction. Staked builders submit sealed bids before T_1 and the proposer collates them at T_2. At T_3 attesters ensure that all bids they observed at T_1 are part of the collated structure. Builders unseal the bids after T_3 and attesters observe them at T_4. The proposer then collates bids in a beacon block at T_5 and attesters attests to the block at T_6 contingent on correct collation. The highest unsealed bid wins, paying a fee corresponding to the second highest bid. The fee is burned. Builders that did not unseal their bids are penalized.

Revealed bids

In the second round, after the T_3 deadline, builders unseal their bids. They should not release before T_3, because then the proposer can collude with other builders to release a bid structure with some bids placed after other bids were revealed. However, they do not need to observe the proposer’s structure before release, and can proceed right after the T_3 mark.

Attesters observe unsealed bids at T_4. The proposer collates all unsealed bids it can find, including them in the beacon block at around T_5. It may also include bids that were never unsealed, so that the associated builder can be penalized (this is a strict requirement in the single-slot design, because then the sealed bids have not been included in a previous beacon block). The highest bid is selected as the forthcoming execution proposer, and the second highest bid value is deducted from the winner’s balance and burned. At T_6, attesters attest to the beacon block, contingent on a correct collation by the beacon proposer.

Rationale

Collusion between builders and proposers to reduce the burn as in the MEV burn design is arguably resolved; without stakers actively burning each others’ MEV revenue.

• There is no longer a stable equilibrium to rely on for colluding parties, such as late bidding.
• The proposer no longer has leverage to punish early bidders by electing another builder.
• Chiseling at a cartel is trivial, simply by truthful bidding.
• Every bid fulfills a real purpose, as opposed to early bids in MEV pricing auctions.
• There is no avenue for discouragement attacks, since there is no substantial proposer revenue to remove.

Penalization

Several actions must be penalized. If the proposer omits an observed sealed bid in the first round or an observed revealed bid in the second round, the proposer’s block must be rejected by attesters. If the proposer fails to release the structure of the sealed bids in the first round or the revealed bids in the second round in a timely manner (reaching attesters before T_3 and T_6 respectively), the proposer’s block must also be rejected by attesters. Edit 18-07-24: As mentioned in the previous section and also further discussed in the next, a builder that does not unseal its bid on time will be penalized. This is facilitated in Figure 1 by including the sealed bid in the beacon block.

It is possible that a builder made a mistake and will be unable to pay for its bid, if the bid is higher than its staked amount. This will be penalized by burning some proportion of the stake, for example corresponding to the amount of the actual winning bid, some fixed amount of ETH, or its entire stake. In any case, if its unbacked bid is the highest, the builder will not win the auction. The second highest bid will instead be selected as the execution proposer, paying the third highest bid, etc. If the bid underpinning the fee (normally the second highest bid) lacks funds, the bid below it will be set to underpin the fee.

Builder–proposer collusion and possible remedies

A potential cause for concern is the following scenario: a builder determines that it would not like to unseal its bid (potentially after observing other builders’ unsealed bids). It does not want to subject itself to a penalty, so it colludes with the proposer to have it miss the slot. Is this a cause for concern? This ultimately depends on if the builder benefits more by not revealing its bid than the proposer loses from a missed proposal. This could be the case when bidding for the right to propose the current or next slot, and the expected MEV falls drastically between bid commit and reveal (i.e., a value-in-flight problem). Another potential cause for concern is if the value instead increases drastically. The proposer might then pose an ultimatum to the winning builder: “send me some part of expected profits, or I will fail to propose”. A failed proposal would leave the builder without rights for the slot. An ultimatum game emerges. The other builders might also be inclined to pay the proposer, in order to starve off competition, and the winning builder would then also need to pay the proposer to ensure it proposes.

While the outlined collusion scenarios may be a bit speculative, it can still be interesting to explore possible remedies. A few directions then spring to mind:

1. Penalize beacon proposers for missed beacon blocks

Proposers already lose out on revenue if they miss their block. However, this loss might not be a sufficient deterrent. It would therefore be beneficial to also penalize proposers if they miss their blocks. Otherwise, if the penalty applied to a builder is substantially higher than the loss from missed proposals for the proposer, that builder penalty will be less meaningful. Builders could seek to collude to let the proposer take the fall. In essence, if the value to the builder, its competitors, or the proposer, of having the builder not win the auction, is higher than the loss to the proposer of not proposing, then collusion or an ultimatum game may emerge.

2. Require subsequent beacon proposers to conclude the auction

Is it possible to have the next beacon proposer conclude the auction? This depends to some extent on the Timeline of the auction.

• Single-slot design: In the single-slot design, attesters do not signal if they rejected a block because of an incorrect initial structure, a late structure, or an incorrect or missing beacon block. A way to deal with this is that the next proposer presents the correct outcome of the auction, in its own view, and that the attesters of n+2 either reject or confirm the new block based on the proposed outcome. But this means that these attesters must also have tracked events in the previous slot as they unfolded, and any split views (e.g., from a rather late sealed builder bid) may persist for several blocks in a row.
• Two-slot design: If the auction commences over two slots, there will be an agreed-upon set of committed sealed bids, or the first beacon block will have been rejected. The second step of the auction can then be concluded in a subsequent slot without requiring attesters to have observed the commit-phase. The requirement is to still have attesters make an observation of unsealed bids sometime before the proposer deadline. But that point need not necessarily be taken from the earlier slot. A benefit is that this might starve off split views.

One thing to note is that if a builder finds it worthwhile to pay the first proposer to not propose, in order to avoid revealing a bid without being penalized, it might be willing to pay also a second proposer for not proposing. However, the price will go up, and the number of potential collusion partners scheduled to propose in a row may not be too large. It should also be noted that when auctioning off rights for slot n+i, there is a requirement that the delay until the conclusion of the auction does not surpass i. In other words, it will only be possible to repeat a failed auction around i times. Note that this requirement is also due to the fact that the order in which auctioned off execution rights are provided cannot be altered ex post, since the expected MEV for slots may vary.

3. Skip the beacon proposal reveal

Is it possible to skip the beacon proposal reveal? If all bids are unsealed, the outcome will be evident to every participant. The mechanism can then be designed such that the winning builder safely can propose its block at the assigned slot, even if a proposer has not collated the outcome and presented a winner. The previous option 2 is focused on concluding the auction via a beacon proposal in time before the execution proposal, but the point here is that the auction does not need to be concluded by the proposer as long as the outcome is evident to the builder and can be verified by attesters when the builder proposes its block. The sealed bids must then have been included in a beacon block, as in the two-slot design.

Threshold decryption via a committee of attesters (h/t Barnabé) is one option here. The bids are decrypted by a committee, and the winner made evident to the builders/forthcoming proposer and attesters. There would still be liveness concerns, but collusion would be more difficult. It can be noted that as long as all builders unseal their bids in a timely manner (even without threshold decryption), the winning builder can proceed with the proposal. Always penalizing builders that do not unseal their bids before T_4 could then seem sufficient, but the issue is that split views would emerge in potential designs. In any case, the outcome would also at some point need to be included in a block, to process payment and penalties.

4. Auction of a future slot to reduce value-in-flight

The Vickrey auction is truthful, allowing builders to bid their true value at the commit deadline. Since value-in-flight is the most likely cause for collusion, auctioning off a slot further removed from the present will temper the issue.

Auctioning off multiple slots

Note that to avoid having a failed beacon proposal result in a missing execution proposal, there is also the option to sell the right to two execution proposals in the subsequent slot (with builders bidding their inverse demand curve and paying according to the second and third highest bids).

Timeline

This section presents two hypothetical timelines for the auction, either when only including unsealed bids in the beacon block (single-slot auction) or when including both sealed and unsealed bids in separate beacon blocks (two-slot auction).

Single-slot auction

Example of a slot auction with a tight schedule enacted mostly during a single slot n, auctioning off execution proposal rights for a later slot n+i.

Note that builders can unseal their bids directly after T_3. This should allow attesters of slot n+1 to observe revealed bids at 10s. However, if needed, the entire schedule could be pushed back slightly.

Two-slot auction

Here is an example of a schedule for the two-slot auction:

6 posts - 2 participants

Read full topic

This post was written by @pedroargento but his account seems unable to post it, so he asked me to do it. I’m not too aware of the necessities/constraints of the ether issuance debate - but this seems quite interesting for defi protocols as well. Anyway, here it goes:

Hey everyone,

A friend of mine just watched the “What’s the Issue with Issuance?” talk by Christine Kim, Caspar Schwarz-Schilling, and Ansgar Dietrichs at EthCC. They said that the key points discussed around Ethereum’s issuance reminded them of a proposal I wrote in the past for Cartesi and CTSI.

The significant issues mentioned were the high (and growing) percentage of ether staked, how having too much ether staked isn’t necessarily beneficial for the network, how LST providers might be in a "winner take all ‘’ situation and etc. Both Ansgar and Justin Drake suggested aiming for around 20-25% staked ether (ball park estimates).

It seems to me that the auction mechanism I proposed for the CTSI staking economy could really help to address these issues, by making the staking system much more expressive. The idea also allows participants to pay negative issuance for the right to earn MEV, which not only tackles the problem of excessive ether staking, but might also helps to balance MEV discrepancies.

I’m not an expert in this research area, but based on the feedback from the EthCC talk, it seems like my proposal aligns well with the direction Ethereum is aiming to take. I’m sharing this here on the Ethereum Research forum in hopes that it can contribute to the ongoing conversation and possibly offer a viable solution to the current challenges with Ethereum’s issuance models.

Looking forward to your thoughts and feedback!

Staking Rights Auctions

A popular solution to reward users for staking is to mint new tokens and distribute them among stakers. Besides the obvious incentive to gain extra tokens, the inflation created penalizes those who choose not to participate. The challenge is how to measure the opportunity costs of users and how to choose the appropriate issuance amount to achieve a target participation rate, while avoiding exceedingly high inflation rates.

Some projects have a fixed emission rate while others have a dynamic inflation function, which is higher when the participation is below desired and lower otherwise. There are three key problems with these methods:

• You need strong assumptions about users’ risk preferences to tailor the parameters of the function;

• Users have little information about the mining income they will get as it depends on the number of total staked funds.

• The methods don’t allow for differentiation between players with different risk preferences;

• It is hard to determine a balanced inflation target.

As a countermeasure to these three issues, I’m proposing a staking system based on a novel mechanism called staking rights, detailed in the sections below.

The Mechanism of Staking Rights

Staking rights give node operators the right to participate in staking. Without the rights, operators cannot be selected in the lottery that chooses the node that will generate the next block.

Rights are transitory. At the end of each staking cycle, a set of rights expires and ceases to exist. Conversely, new rights are created and made available for purchase through an auction.

Staking rights always have a final value of 1 token, which is delivered to the account that purchased it at the precise time of their expiry. When users buy a staking right for a price of less than 1 token, the difference between the price paid and the unit value is proportional to their perceived opportunity of the staking right. In that case, the difference is minted and locked in staking together with the price paid, totaling 1 token staked per right sold.

Here is an example. Suppose that the desired staking participation rate is 50% of the circulating supply of 1 thousand tokens. In this case, the system creates and auctions 500 staking rights, each scheduled to pay 1 token at the end of the cycle.

Circulating supply: 1000
Target participation: 500 (50%)
Staking rights issued: 500
Auction price = 0.97

Assume that each staking right is sold for 0.97 in the auction, thereby generating 0.03 new tokens. The staking rights buyer at the end of the staking cycle would be rewarded 1 token obtaining a 3.09\% return (0.03/0.97). The total inflation generated for the network would be 15 tokens (0.03 per right * 500 rights) or 1.5\%.

With this system, the user knows exactly how much return they will get for their staked tokens, independent of how many rights are sold or how many other stakers exist. There are also no assumptions about risk preferences, buyers will state them through bidding. This method also allows for bigger differentiation between users: instead of asking for a binary decision (stake or not to stake), we allow users to signal at what price they would be willing to stake.

The system can offer staking rights with different staking cycle periods: 2 weeks, 1 month, 3 months, etc. This achieves two objectives (1) differentiate between users who are willing to stake long term from short term players and, mainly, (2) decrease volatility in token emission. After all, if all staking cycles end at the same time, all new staking rights will be subjected to the same market conditions that may not represent the average behavior of stakers.

With different staking periods, in each cycle only a small number of staking rights will need to be created to replace the expired ones. This is because in each cycle there is going to be a mix of active staking rights bought at different points in time.

User risk preferences can be stated in the form of a discount rate, the rate used to convert future values (promises of payouts) to the present. The discount rate is the income that makes one indifferent between gaining money in the present or in the future. For example, with a discount rate of 10% a year, one would be indifferent between receiving 100 dollars today or 110 dollars a year from now.

The discount rate of a user can be translated to a staking right value using it to compute the present value of all incentives that can be paid by staking the right.

Staking rights give the owner three sources of incentives, provided that the owner remained active within the network:

• Staking right’s unit value (paid at the end of the cycle)

• Block producer’s tips

• Mine extractable Value

Below is an example of staking rights holder cash flows for a six month locked period.

The price to be paid for the staking can be easily calculate based on the return demanded by the staker

Given:
a staking right in a staking cycle of 12 weeks that pays rewards every 2 weeks
MEV_t the expected mine reward for time t
NF_t the expected network fees for time t
UV the staking right unit value
i the 2-week return expected by the user
The price P will be calculated as:

P= \frac {UV} {(1+i)^6} + \sum_ {t=1}^{6} \frac {MEV_t + NF_t} {(1+i)^t}

The staking rights can be sold through a closed price auction of Nth price, which means that the higher bid wins the token but will pay the price of the highest loser bid. For example, If 500 tokens are sold and the 501st highest bid was 0.98, all 500 tokens will cost 0.98. This type of auction, also known as a Vickrey auction (or Dutch auction), ensures all players bid their true valuation of the staking right, revealing their true risk preferences.

Proof
Its not 100% applicable to this specific auction, but a classical proof from Game Theory can give the intuition why the paid price being the lowest winning bid incentivizes truthfully reporting:

Given user i has a valuation B_i for a staking right. They can bid B_+ >B_i or B_- < B_i and the N-th price of the auction ends up being B_n.

If they bids B_+ there are two possibilities:

1. B_n < B_i

2. B_+ > B_n > B_i

In (1) they would get (B_i - B_n) independent of bidding B_+ or B_i and in (2) they would lose (B_i — B_+) that would be larger than (B_n — B_i). In neither case they have incentive to bid B_+.

If they bids B_- there are two possibilities:

3. B_n < B_-

4. B_- < B_n < B_i

In (3) they would get (B_i — B_n) independent of bidding B_- or B_i and in (4) they would not get the token, making it better to bid Bi and have the chance to win.

In all possible cases there is no incentive to bid B_+ or B_-, making B_i the dominant Nash-Bayesian equilibrium.

This system also allows for deflation, if the value of the auction ends up above 1 unit. This would make sense if people are expecting such a high reward from the fees and MEV that they are willing to burn a certain amount of tokens in order to participate.

Inflation Control Mechanisms

Besides the burning possibility, its possible to add parameters in the auction to help manage inflation. Although its unclear to me at this time how those parameters could be decided by the Ethereum ecosystem, I’m presenting them anyway. Contributions are welcomed as always.

First. Auction reserve prices: In the worst-case scenario, where all rights are sold in the auction with a price close to zero, the inflation will be the number of rights sold, divided by the total supply (50% in our previous example).

A reserve price means that only bids above a certain value will be considered valid. If we choose a reserve price of 0.7, the worst-case scenario in our example would be an inflation of 15%.

With a reserve price, it is possible to choose an acceptable inflation range and guarantee it will be complied with at all times.

Second. The number of issued tokens: The number of tokens directly affects the inflation. If only 100 tokens are issued (out of a total supply of one thousand), the worst-case scenario for inflation would be 10%.

These two variables need to be controlled dynamically in order to make sure the inflation is never higher than a previously determined ceiling. The number of tokens issued will depend not only on the target participation rate but also on the value of bids from the auction. This number will be capped so that the total newly minted tokens are limited to the maximum inflation. The total newly minted tokens can be calculated as the difference between the face value and the highest bid not honored (the Dutch auction price) times the number of tokens issued.

Let CAP be the maximum number of minted ETH desired

Let N_ {max} be the maximum number of staking rights necessary to achieve the target participation rate

Let B(i) be the i-th largest bid from the auction results

Let N be the number of staking rights issued

N will be chosen as the result of the optimization problem:

\begin{aligned} \max_{} \quad & N\\ \textrm{s.t.} \quad & N * (1-B(N+1)) \le CAP\\ \quad & N \le N_ {max} \\ \end{aligned}

More precisely, suppose that we sort all the bids made during the auction in decreasing order and plot them as in the figure below.

Then N staking rights will be issued in order to preserve the maximum number of ETH issued (CAP). Therefore, we can dynamically choose the minimum value B(N+1) such that the inflation is within the predetermined bounds.

The deflation case is depicted in the figure below:

It is important to note that there is no way around the tradeoff between participation rate and inflation, to control the later there is the need to sacrifice the former. The advantage brought by the system of staking rights auction is that we maximize participation, while limiting the inflation and allowing workers to express their economic preferences.

2 posts - 1 participant

Read full topic

Using threshold BLS signatures we design a new blockchain that implements sharding, separating tokens from EVM processors. Bitfinity is linearly scalable and fast.
Bitfinity implements seamless cross-shard communication.

Using sharding techniques we also implement seamless cross-chain settlement and can bridge over Bitcoin to the EVM.

1 post - 1 participant

Read full topic

In a new paper with Christoph Schlegel (@jcschlegel), Benny Sudakov and Danning Sui(@sui414), we look at the distribution of MEV rewards between the validator and searchers. We model the interaction between all players using tools from cooperative game theory. Namely, for any coalition of players, we define a (maximum achievable) value the coalition can derive by creating the best block together. The validator is a special player, that is needed to create any value. In other words, it has a veto power. However, searchers are the ones that find (arbitrage) opportunities which derive a value. Searchers can be substitutes or complements of each other into finding opportunities. The outcome of this interaction is payoff vector, specifying how much each player gets. In the core of the game payoffs are such that any coalition gets paid at least as much as the value they produce themselves.
First, we study a structure of the core, which is always non-empty set of payoff vectors. Then, we focus on the searcher-optimum allocation and show that each searcher obtains its marginal contribution. In a stochastic model, where each opportunity is independently found with the same probability by each searcher, we show that if this probability is mildly high in the number of searchers, validator gets all rewards. In other words, core is just a single payoff vector. While if this probability is low, with a constant probability the validator can get zero payment, as the searchers are complements of each other. We extend some results to the blocks with bounded size.
On the empirical side, we observe that if there is a high competition of searchers, validator rewards are increasing (in absolute terms), which aligns with our theoretical predictions.
For more details check out the paper: [2407.07474] Searcher Competition in Block Building. Any feedback is welcome.

1 post - 1 participant

Read full topic

Motivation

One key problem with the L2 scaling solutions is that assets natively minted on L2s can only be used on the L2 of issuance but it cannot be bridged back to L1 or other L2s, without utilizing external bridges. This creates fragmentation. At the time of writing, there is already half as much natively-minted assets ($12b) on Eth L2s compared to canonical bridged assets ($24b), according to L2Beat.

Shared settlement layers only solve this problem for L2s using the same shared settlement layer. The ecosystem remain fragmented once more shared settlement layer show up.

We propose two-way canonical bridges as a solution, where L2-minted assets can be reverse-canonically bridged to L1. It is simply an ERC-1155-like interface that an L2 settlement contracts adopt, plus additional precompiles added to the L2 execution environment.

Two-way Canonical Bridges

Below is a highlevel description of two-way canonical bridging.

• The L2 settlement contract becomes the ledger of record for all native assets issued on it (that have been reverse-canonically-bridged). The settlement contract (on L1) shall implement the ERC-1155 interface, where the asset id field denotes the L2 asset address.
• To send an L2-native asset to an L1 address, the L2 users simply send the asset to a prespecified system address, which shall results in the L2 settlement contract on L1 issuing ERC-1155 tokens to itself. Next, L2->L1 call mechanisms can be utilized to move the newly-issued asset to any desired destination. This is done within the same L2 transaction.
• To send a reverse-canonically-wrapped asset back to its L2 of origin, a special burnAndDeposit function on the L2 settlement contract can be called.
• Since the L2 settlement contract is an ERC-1155 contract, L1 EOAs and other L2s can simply hold assets or wrap them as normal. This requires the L2 canonical bridge to support wrapping of ERC-1155 assets.
• In normal usage, it is expected that the only holders of the ERC-1155 tokens issued by an L2 settlement contract are other L2 settlement contracts. This means that the state overhead on L1 is small.

Additional consideration:

• The safety of an asset is maintained without additional trust assumptions because the L2 settlement contract acts as the ledger of record for all outstanding assets (those owned by other L1 addresses).
• It is assumed that any assets that is reverse-canonically-bridged to L1 addresses is done at the risk of the user initiating the bridging.
• In practice, end-users can utilize fast liquidity bridges while crosschain liquidity providers utilize the two-way canonical bridges to rebalance.
• This mechanism can extend to L3s on L2s. An asset issued on an L3 can be reverse canonically-bridged to L2 and then reverse canonically-bridged back to L1. We’d need the 1155 ids on the settlement contract to be able to represent the 1155 asset id on L2 alongside with the asset address–this can be done via hashing for example.

Acknowledgements

Thanks to Shumo Chu for review and comments.

7 posts - 5 participants

Read full topic

MEV resistant dynamic pricing auction of execution proposal rights

Execution proposal of marriage between EA and ET through an auction sequenced by RANDAO (she said yes).

By Anders. Special thanks to Barnabé for helping me improve the clarity of this post. Thanks also for valuable feedback to Thomas, Julian, and Francesco.

1. Introduction

1.1 Background

As part of the effort to enshrine proposer–builder separation (ePBS), the role of beacon validators as execution proposers has come under scrutiny. Execution tickets (ET), first introduced as attester–proposer separation, is a mechanism for selecting the execution proposer by random draw from a ticket pool, aiming to detach beacon validators from the selection process. However, the mechanism for selling tickets has not been settled, with several alternatives under consideration. A notable concern is that the sale of execution tickets may induce maximal extractable value (MEV). If the mechanism is administered by the consensus layer and the beacon proposer is given too much influence over the price or over the selection of purchasers, the design risks repeating one of the issues it was intended to resolve, with a new source of MEV becoming a concern. An execution layer vending machine raises similar questions. Therefore, a MEV resistant auction mechanism could be desirable if pursuing ETs.

Execution auctions (EA) is a related mechanism for selecting a future execution proposer, omitting the ticket pool. It relies on a MEV pricing auction, where bidders first make bids that set a floor to the MEV burn, and finally bid through tips in order to be selected by the proposer. Concerns have been raised (1, 2, 3) regarding the viability of MEV pricing auctions due to insufficient bid incentives in the initial phase. It has recently been suggested that this concern is resolved by considering the staking metagame, in which stakers must bid early to deprive other stakers of revenue. However, this resolution implies that EAs will lead to increased staker–builder integration, which might also be a cause for concern. For this reason, it seems fruitful to explore an alternative auction mechanism also when selecting the execution proposer without leveraging a ticket pool.

1.2 Overview of proposal

This post introduces a dynamic pricing auction with MEV resistance to sell execution proposal rights. Builders hold reserves in a debit account and place binding purchase order for a ticket (ET) or an execution proposal slot (similar to EA). The final price adapts dynamically based on the total outstanding as well as currently incoming orders/tickets, with some similarities to, e.g., EIP-1559, and the payment is burned. Orders are delimited at the slot level through attester observations to remove agency from the beacon proposers facilitating the auction, thus inducing less new MEV. This produces a high aggregate MEV burn. In one version of the design, dubbed execution ticket auction (ETA), orders that came in during the same slot are sequenced for proposal by leveraging the RANDAO. In another version only applicable to ETs, orders that came in during the same slot are minted collectively into tickets. Due to the current limitations of the RANDAO, the mechanism is only capable of auctioning off proposal rights at least one epoch in advance.

2. Purchase process

Figure 1 presents the proposed purchase mechanism. Builders send purchase orders (for one ticket/execution slot at a time) over a public P2P layer. They specify a maximum price and hold a debit account within consensus to guarantee that their purchase orders are backed by sufficient funds. This account is funded using a separate transaction (see the discussion).

Beacon attesters observe all orders up to an observation deadline, enacted for example 2 seconds before the slot boundary. The beacon proposer collects all orders (there will be one purchase order per slot on average), including orders they may have found during the last few seconds of their slot. Orders are added as a group to the beacon block and will later be popped from a virtual first-in first-out (FIFO) queue scheduled across blocks. This queue may be just one slot long, depending on implementation.

Attesters reject the block if the beacon proposer fails to include a purchase order that they observed. The mechanism thus far has similarities to MEV pricing auctions (e.g., MEV smoothing, MEV burn, EA), but attesters are tasked with simply observing all purchases, instead of setting a bid floor. Another design that might come to mind is inclusion lists (ILs) in the style of FOCIL, but there is no new active participant in the form of an IL committee.

Figure 1. Schematic overview of the purchase process. Orders in blue, backed by builders’ debit accounts, are observed by attesters (purple arrows). Beacon proposers subsequently add all incoming orders to the beacon block (dark red arrow). A validity check is performed to ensure that orders are fully backed. Orders are finally processed—using either RANDAO to determine the sequence in cases where several orders came in during the associated slot (yellow), or otherwise using collective minting (red). In ETA, orders are directly queued for proposal.

Once a slot’s orders have been added to the beacon block, a validity check is performed on builders that included at least one new order (cyan in Figure 1). If a builder’s outstanding (not yet processed) orders across the queue are not fully backed by its debit account, all the builder’s pending orders are discarded. A penalty may also be applied. Orders are priced directly upon being added or, e.g., at the time of sequencing, as described in Section 4. The determined purchase price is charged from the debit account and burned. The remaining ETH of the purchase order is subsequently virtually released such that it can be used to back new purchase orders. Orders are then sequenced and either queued for proposal (yellow arrow) or added to the ticket pool (red arrow), as described in Section 3.

3. Sequencing process

The purchase orders from the same slot are added unsequenced to the beacon block. The subsequent sequencing of orders from the same slot varies between designs.

3.1 ET – Minting of execution tickets

The natural strategy for ETs is collective minting, wherein all orders from the same slot mint a ticket at the same time, as indicated by the red arrow in Figure 1. The RANDAO used for ETA in the next subsection could also be applied to ETs using the same setup (dashed yellow arrow). However, the only real benefit (which remains marginal) is to facilitate a more even replenishment of the ticket pool.

3.2 ETA – orders sequenced by RANDAO

Purchase orders that came in during the same slot can be sequenced directly by the RANDAO, completely skipping a ticket pool. Perhaps execution ticket auction (ETA) would be a proper moniker. Indeed, with this design, a buyer will have an Estimated Time of Arrival for their order, which suitably cannot be precisely known beforehand if there is more than one order in the slot. Barnabé’s discussion (1, 2) on the topic of ETs and determinism is relevant here.

Orders can only be sequenced after the RANDAO has been updated. Therefore, there is an initial ineligibility window W during which orders cannot lead to an execution proposal. The RANDAO updates every 32 slots, but the proposed mechanism does not guarantee a new order every slot; in fact, the mode will be zero orders in a slot. Consequently, the safe distance between auction and slot proposal will need to be somewhat longer than 32 slots. Sequenced orders can be understood as sitting in a second FIFO queue while waiting to propose. Note that ETA could set the queue to hold as many proposal rights as the ticket pool, if desirable.

4. Dynamic pricing

4.1 Ticket saturation and delta

The exploration of dynamic pricing will refer to processed orders as “tickets”, although in the ETA design these are just sitting in the ordered queue waiting to propose. The protocol strives to ensure that there are \hat{T} outstanding tickets at any time. The price of a new ticket should be determined by the current number of outstanding tickets T as well as the current supply of purchases and purchase orders T_p, measured over some window of length W_T, which in some versions can be only one slot long.

Define the ticket saturation as T_s=T-\hat{T}. If T_s<0, there are too few tickets, and the protocol would in general like to sell more than one ticket per slot. If T_s>0, there are too many, and it would in general like to sell fewer than one. The delta T_{\delta}=T_p-W_T gives purchase orders relative to an expectation of one ticket per slot, which is the rate at which tickets are consumed by execution proposers. If T_{\delta}<0, the protocol is selling fewer than one ticket per slot and would in general like to sell more. If T_{\delta}>0, it sells more than one and would in general like to sell fewer.

If both T_s and T_{\delta} are negative, the protocol should decrease the ticket price to sell more tickets. If both T_s and T_{\delta} are positive, it should increase the price to sell fewer. The less trivial question is how to approach a situation when one of the variables is negative and the other is positive, how to window sales, and how quickly to adjust the price.

4.2 Dynamic pricing mechanism

4.2.1 Overview

The price of tickets adjusts on a relative basis, just like in EIP-1559, gradually shifting by some proportion of the current price each slot. To improve MEV resistance and adapt to the problem at hand, three differences to EIP-1559 however seem useful: (1) the price should depend on orders included in the current slot, not only the preceding; (2) the block should never be “full”, lest the ticket price becomes very high; (3) the mechanism should be “two-dimensional” in the sense that it accounts for both ticket saturation and delta.

This subsection begins by exploring the simplest realization of such a pricing mechanism, which will then gradually be expanded. In the simplest design, W_T=1, and orders can be priced directly when added to the beacon block. If there is one new order (T_{\delta}=0) and the number of outstanding tickets is as desired (T_s=0), the price stays the same. If there are many new orders (a sudden spike in the expected MEV), the pricing mechanism will hike the price substantially. For example, if 100 orders were to come in, the purchase price for them could rise by orders of magnitude; the exact specification would need to be determined based on other auction paramters such as the size of the ticket pool. Builders will of course track incoming orders in real time and update their estimate of the final purchase price. Therefore, even during a sudden rise in expected MEV, there will only be new orders up to the point where the deduced price matches expected MEV.

As another option, W_T can be longer, setting the price W slots after orders have been added to the beacon block. In Figure 1, W=3. An asymmetric window spanning 4 slots up to and including the processing slot is then an option. The most important benefit is MEV resistance during spikes, as will be further discussed in Section 4.3. Other potential benefits include better pricing granularity, a more complete picture when pricing orders, and the marginal simplification in ETA from pricing and sequencing orders at the same. Of course, it can be argued that the picture already is “complete” in the sense that builders can indicate expected MEV already at the current slot, albeit they may not be fully equipped to evaluate incoming orders in real-time. It can also be argued that W>0 and W_T>1 needlessly increase uncertainty and analytical complexity for builders as well as developers. As an example, builders may place an order several slots before a spike, but still need to pay closer to the real expected value of the MEV they are about to receive (priced closer to proposal time).

4.2.2 Equations

A rudimentary example will now be provided. Should this general mechanism be pursued, the exact price controller would have to be determined by reasoning about how quickly the price should adapt to changes in the willingness to buy tickets, sensitivity to ticket saturation, interplay between saturation and delta, sensitivity to MEV induction (see the next subsection), and by running simulations of the purchase process.

Ticket saturation and delta from the previous subsection is first weighed by window length and desired number of outstanding tickets

using the constants c_s=2^3 and c_{\delta}=2^6. The percentage change w to the ticket price applied each slot is

This post uses k=2, ensuring a non-linear price response as T_{\delta} grows. This can be particularly relevant at shorter windows W_T. Setting k=3 is also viable. The constant c_{\delta} can then alternatively be increased to offer better pricing granularity at a lower ticket delta, while still offering some guarantees regarding the maximum number of orders that may come in during one slot. The price p updates from its level at the previous slot p_0 to its level at the present slot p_1 as

4.2.3 Visualizations

Figure 2 illustrates what a pricing schedule according to w would look like for the outlined equations, with \hat{T}=4096 and W_T=32. The yellow band stipulates no price change (w=1), and passes through the intersection of the black lines, which correspond to a neutral ticket delta (x-axis) and saturation (y-axis). There have been suggestions of much higher \hat{T}. This issue relates to a wide range of considerations that are not the focus of this post.

Figure 2. Rudimentary example for W_T=32 of a percentage change in ticket price that varies with delta in ticket sales and the overall saturation of tickets in the pool. Black lines indicate a neutral delta (one ticket sold per slot) and saturation (T=\hat{T}).

Figure 3 instead shows a pricing schedule when W_T=1 using the same equation and settings as previously. If no orders come in during the measured slot, T_{\delta}=-1. Note that the colormap is log-scaled to capture the large increase in w that is instituted if 64 orders were to come in during a single slot. When T_W=32 (Figure 2), a large jump in orders would affect the price for 32 consecutive slots (assuming an asymmetric window), before the purchase takes place, and so w will naturally be lower on a per-slot basis.

Figure 3. Rudimentary example for W_T=1 of a percentage change in ticket price that varies with delta in ticket sales and the overall saturation of tickets in the pool. Black lines indicate a neutral delta (one ticket sold in the slot) and saturation (T=\hat{T}).

The relative change at W_T=1 for different T_{\delta} is shown in Figure 4, at a neutral ticket saturation (T_s=0). The price change instituted with this setting for between 0 to 4 orders is {0.969, 1, 1.031 1.063 1.096}. The same granularity can be preserved at lower quantities of orders while further raising the price at higher quantities, by increasing k.

Figure 4. Rudimentary example for W_T=1, focusing on the relative price change w across T_{\delta} at a neutral saturation. If 60 orders come in during a single slot, the price rises sharply.

Figure 5 instead plots the response at T_{\delta}=-1 across T_s. In other words, it shows how the price would change if no purchase orders are registered.

Figure 5. Rudimentary example for W_T=1, focusing on the relative price change w across T_s when no purchase order comes in.

4.3 Windowing and slot surge pricing

In the outlined pricing mechanism, there is a remaining opportunity for the beacon proposer to derive some MEV at shorter windows T_W. This happens during a sudden spike in interest for purchasing tickets between the point where attesters have observed purchase orders and the slot boundary.

Let n_a be the equilibrium quantity of orders that would have come in during a slot if a spike happened before the attester observation deadline (purple arrows in Figure 1). Builders keep track of incoming orders and calculate the current ticket price, which when compared to the updated expected MEV V_e produces n_a orders. If a spike comes in after the attester deadline, the proposer has exclusivity and could (be paid to) include only a subset of the orders n_p. The surplus MEV for the proposer emerges from providing a lower expected purchase price for each order it lets through. This is a monopoly pricing regime, wherein the proposer sells spots at a price approaching V_e-p_1. It determines n_p to maximize its revenue R(n_p), in accordance with the revenue function:

Here, p_1(n) is based on the price equation provided in the previous subsection. Also note that if many purchase orders come in, V_e might gradually fall (if there is a temporary spike); hence V_e(n).

Quick edit: some additions/adjustments and referring to the previous subsection, which I had forgotten to do.

As mentioned in the previous subsection, longer windows W_T serve to further starve off MEV. The reason is now clear: bids of the present slot will with longer windows be priced based on information coming in also during subsequent slots. This means that the proposer has less leverage during a sudden spike, since builders will need to pay based on bids that are also observed by attesters (at the fair market price). In Figure 2, the price would be set 32 slots after inclusion in the block, influenced by the bids in these slots. Another way to achieve a similar effect without longer windows is to charge according to the price calculated during the next slot. Here it is important to note that bidders of the next slot cannot materially grief bidders of the present slot. They will also have to pay close to the price of bidders in the current slot, since the price cannot fall substantially between slots at short windows, only rise (also note the discussion of max price in Section 4.4). Yet the downside of heightened uncertainty for builders regarding pricing can be important to keep in mind.

If the price surges more quickly from a high quantity of purchased tickets within a single slot, the proposer’s potential revenue could also be reduced. Proposers can then sell fewer spots. Furthermore, by letting the price in the next slot not shift as much, oscillations in bid quantity (and potentially price) can be tempered. One way to achieve this is to let w rise more quickly with an increase in bids, set the price in the current slot as previously

but to not incorporate the full price change when setting the value p^*_0 that will be used as p_0 when pricing the next slot

The constant c_w is then set above 1. During a spike in expected value up to a new baseline V_e, the price would then theoretically stay rather fixed (at a new higher level) for subsequent slots, with the number of orders in each slot gradually decreasing, until it proceeds at the regular pace of one purchase order per slot. Yet note that if V_e rises from a temporary opportunity, there will be a bit more MEV for the proposer to extract still, because a lot of the value can depend on getting in early. This further depends on if the mechanism is ET or ETA and the size of the ticket pool. It is also important to note that a price surge means giving up some bid granularity. The discussion offers some further thoughts on bid granularity and the proposer’s ability to extract MEV.

As a concluding remark, it should always be remembered that a big ticket pool acts to temper fluctuations in the expected value of tickets. The buyer does not necessarily buy the right to sell tickets within the next couple of epochs, but rather within the next couple of hours, days, weeks or months, depending on the setting for \hat{T}—and it turns out that when measured over longer periods, the level of the MEV has been very stable in Ethereum.

4.4 The role of a maximum price

Each buyer assigns a max price to the order. This is the value that needs to be backed by the debit account. If the max price is insufficient at the time of pricing, such that the actual price is higher, the builder does not receive a ticket/slot. Yet builders could make unbacked orders to starve off competitors, which would bring down the purchase price. It seems desirable to not force builders to analyze the balances of every competitor to determine which bids are real and which are “fake”. One simple way to avoid such a situation is to penalize builders for placing orders that turn out to be unbacked at the time of purchase. This can potentially be combined with setting a validity rule requiring some minimum max price, either relative to the prevailing price at bid time, or/and as a fixed overall minimum.

Penalizing builders however exacerbates another potential issue. During an unforeseen spike in expected MEV, there are circumstances where a builder could “liquidate” its competitors’ bids if the current purchase price is close to their stipulated maximum. A builder could enter new bids forcing other builders out, to penalize them and gain cheaper tickets. For this reason, the mechanism could reduce gameability and the risks as well as improve capital efficiency for builders by stipulating an absolute maximum purchase price. A builder that bids the absolute maximum is guaranteed to not get liquidated and will always receive a ticket. This does not mean that the protocol will burn less MEV, merely that in times of extremely high expected MEV, there will temporarily be a higher quantity of bids, wherein each order has a lower chance of actually getting one of the desirable profitable slots.

What should the absolute maximum be set to if this path is pursued? In data provided by Flashbots spanning 2.7 million blocks between the last quarter of 2022 and the third quarter of 2023, the maximum average REV across 64 slots is 19.5 ETH. The peak average is skewed by a few spurious blocks with REV of several 100 ETH that may have been hard to predict beforehand. This average does therefore not represent a realistic expected MEV for builders bidding many slots in advance. Expand the window by a factor of 4 to 256 and the maximum average falls almost by a factor of 4, to 5.25. Setting the absolute maximum to 5 ETH would thus presumably not influence the auction even in times of extreme market conditions, since that price would hardly ever be reached.

5. Discussion

A MEV resistant dynamic pricing auction for selling execution proposal rights has been presented, relevant to the research of both ETs and EAs. It seeks to remove agency from the beacon proposer, thus inducing less MEV. This is achieved by having every order result in a sale, and every order coming in during the same slot having the same expected sales price. The execution ticket auction (ETA) sequences orders directly for proposal by leveraging the RANDAO. Orders that came in during the same slot can otherwise be minted collectively into tickets, with sequencing pursued at a later stage in accordance with the ET proposal.

If pursuing this auction mechanism, the dynamic pricing step would require substantial analysis. One sensitive part is the balance between moderating changes in the supply of orders while still offering sufficient pricing granularity. A high k can be useful here. Another potential avenue is to hold the auction less frequently. The expected timing of orders within the slot would also be interesting to study—orders can be placed early to starve off others, or late to gain better information. One could even theorize that some builders will wait until after the attester deadline, and then pay the proposer a small fee for exclusive post-deadline inclusion (the benefit being to avoid race conditions).

Transactions to fund or withdraw from a builder’s debit account would need to be synchronized with the validity check to avoid race conditions. It may be convenient to expand the role of the debit account if it is desirable to subject builders to slashing or penalties at the execution proposal stage. In other words, the debit account might also function as a stake.

Just as with MEV pricing auctions, attesters accepting or rejecting a block based on some observation deadline is potentially sensitive. However, this particular design should hopefully be less so, since there will only be one order on average per block to observe, and less value (even potentially negative) in bidding later in the block. A potential benefit of an auction administered instead at the execution layer is the “endogenous” component, facilitating a higher burn; the value of a ticket increases if the current ticket holder can extract value from future ticket holders through MEV. However, this direction raises gameability concerns if a single actor can come to monopolize the auction (ILs may here be useful). A MEV resistant mechanism, as here proposed, originating at the consensus layer, therefore seems like a viable direction.

It might seem tempting to replicate some facets of the proposed design for transaction processing: making the protocol more MEV resistant by having attesters observe transactions, the protocol sequence them by RANDAO, and the price adjust in a slot-delimited fashion. However, the requirements for transactions are different than for the purchase orders of execution rights analyzed in this post (e.g., time, quantity). Translating the ideas of this post directly to transaction processing might therefore unfortunately be difficult. Yet the proposed mechanism could perhaps lend some inspiration going forward.

It should be noted that multi-block MEV is a separate topic of concern. The proposed mechanism is resistant to inducing MEV at the purchase stage but does not preclude multi-block MEV. This is a general issue and an underexplored topic at this point in time. Censorship resistance is likewise an important problem not addressed by the auction mechanism. Various strategies, such as ILs (1, 2, 3), have been proposed. Whether the presented auction mechanism can be one part of an overall architecture that also tackles other issues remains to be explored.

1 post - 1 participant

Read full topic

Deep Diving Attestations

I want to provide some quantitative stats on…

• Head-, target-, and source votes,
• The individual node operators’ attestation performance, including the best and worst validators,
• Attestation timing and inclusion delay, and
• The impact of MEV-Boost, CL clients, Proposer Timing Games and Big Blocks with Blobs on attestation accuracy.

Many thanks to Caspar, DappLion, Barnabé and Potuz for their feedback and review!

Data

I use data ranging from slot 9,169,184 to slot 9,392,415, amounting to 6,975 epochs, 31 days of data.
The goal is to provide some initial results from analyzing attestations, as a warm-up for analyzing correlated attestation penalties (EIP-7716).
Some of the data is collected by myself using custom parsing scripts. Other data was provided by EthPandaOps. This includes timing data collected from running nodes of every client in the regions Sydney, Helsinki, and San Francisco, with all nodes being subscribed to all subnets. For classifying CL clients, the blockprint tool was used.

Importantly, my solo staker categorization is done very conservatively to avoid confusing professional entities with solo stakers. In total, my dataset contains 8,488 validators classified as solo stakers.

The code for creating the charts is published in this repo.

Attestations

The Basics

Attestations are at the core of Ethereum. Through attesting to past checkpoints, Ethereum’s validators agree on a state to become irreversible (Casper FFG). Furthermore, validators use attestations to agree upon the tip of the chain, deciding which transactions get confirmed and which don’t (LMD GHOST).
Every validator, backed by its stake, participates in every epoch and is randomly assigned a slot, during which it is expected to broadcast its view of the chain through attesting.

An attestation contains three things:

• A source vote: The block (and all predecessors) to be finalized
• A target vote: The block (and all predecessors) to be justified (=pre-finalized)
• A head vote: The block seen as the head of the chain.

Since the Deneb hardfork that included EIP-7045, attestations for a slot in epoch N can be included up until the end of epoch N+1. However, inclusion doesn’t guarantee a reward:
To be rewarded, a validator must ensure its source vote is included within 5 slots. The target vote has to be included within 32 slots to be rewarded. Head votes must be included in the following slot to be eligible for a reward.

As of today, Ethereum counts ~1.03 million validators. This means we have 1.03 million votes every epoch, ~32,000 every slot. In one day, with 225 epochs, there are approximately 225 million attestations. This data grows quite fast.

If the source vote is invalid, then the target and head vote MUST be invalid too.

A slot can be broken down into 3 phases:

1. Validators attest when they have seen a block for the current slot or at second 4 in the slot - the attestation deadline. A block broadcasted at second 0 in the slot has 4 seconds to be seen by all relevant validators and collect votes. Late blocks risk not receiving enough attestations and being reorged by a subsequent block.
2. Between second 4 and 8 in the slot, attestations are aggregated and broadcasted by selected validators.
3. Eventually, the subsequent block proposer includes them into its block.

For more in-depth explanations check out this post by Georgios and Mike on “Time, slots, and the ordering of events in Ethereum Proof-of-Stake”.

Definitions

Missed vs. Failed:

• A validator can either miss its attestation (missed) or attest to a wrong checkpoint (failed).
• Missed attestations can happen if the node running the validator is out of sync or offline.
• Voting for a wrong checkpoint, e.g. a wrong head, can have various reasons like receiving a block too late, being out of sync or even having a bug, etc.
• Regardless of the reason, a failed vote tells us one important fact about a validator—it is online.

In the following, we’ll also need the term “high-performing validator” which is a validator that hasn’t failed to cast a correct and timely head vote over the complete time frame analyzed.

Attestation Inclusion Delay

In the best case, attestations are included in the block of the next slot, causing a delay of 1. Sometimes, especially when the next proposer is offline or gets reorged, attestations are not included in the next slot. Then, the validator misses out on the rewards from the correct head vote, even though the attestation can still be included in a later block.

The following chart shows the distribution of the inclusion delay over seconds 1-63 and the clients the attesters were using.

• 95.85% of attestations are included in the next slot.
• ~1.2% of attestations are included in the slot after the next.
• When a new epoch begins, old attestations are again picked up and finally included.
  • This is weird (but there’ll be an explanation little down below).
  • Attestations of validators of all clients are affected.

This raises the question, “what are clients doing?”

Examples include slots 9267438 with a delay of 35 (5250 validators), 9267425 with a delay of 52 (1813 validators), or slot 9267427 with a delay of 36 slots (1305 validators).

What if those late attestations were already included earlier and were later just included again (h/t dapplion)? To analyze that, we reproduce the above chart but separate by first inclusion and every following inclusion:

First, it is interesting that almost half of the attestations included with a delay of 2 slots (note: best is 1) have already been included in an earlier slot. This is possible because proposers are free to pick attestations that have already been included in the past 63 slots and include them again. Additionally, a block can contain the same attestations multiple times, aggregated differently.

We can see that the majority of the attestations included in the second hump with a delay of around 35 slots are reincluded attestations.

This raises the question, “why does this occur with a delay of more than 32 slots?”

In percentage terms, we can see the first inclusion share reducing over an increasing delay:

To dig deeper into this reinclusion finding, let’s check the CL clients that built the blocks that included attestations with >32 slots delay:

We can see quite clearly that it’s mainly Prysm proposers who include attestations that have already been included earlier, which is very likely a bug.

The fact that the plot also shows other clients affected might stem from inaccuracies in classifying clients probabilisticly.

The Prysm team was notified.

Edit: The Prysm team was faster in fixing the bug than I was in finishing this post.

Fix: Increase attestation seen cache exp time to two epochs by terencechain · Pull Request #14156 · prysmaticlabs/prysm · GitHub

Missed/Failed Attestations

Missed/Failed Head Votes

Head votes are the most difficult part of an attestation. They need to be cast correctly and timely. Per honest validator spec, validators have 4 seconds to receive and validate a block for the current slot. If no block is received until second 4, validators attest to the block in the previous slot. Timeliness in the context of head votes means 1 slot. Although older head votes can be included, there is no reward for the respective validator.

The legend is ordered in descending order by the sum of missed votes.

On average, we observe around ~500 missed or wrong head votes out of ~32k validators per slot and ~16k, out of ~1m, per epoch. This represents around 1.56%.

The entity labeled as unidentified may consist of multiple independent parties, including solo stakers and entities that haven’t been identified yet, and it has a total market share of 20% of all validators.

Assuming every node operator performs equally, the market share of each entity should reflect its share of missed head votes. However, this is not the case and we see certain node operators being superior compared to others.

The following chart visualizes the delta in the expected number of missed head votes based on market share and the actual number of missed attestations.

While entities such as Kiln, Ether_fi, Lido, Renzo, Figment, and Stakefish perform better than the average, we observe that Rocketpool validators, Kraken validators, and solo stakers miss up to 3% more head votes than their market share.

Focusing on the slot indices in epochs, we distinguish between missing a head vote due to being offline and voting for the wrong head.

The following chart shows the average number of missed/wrong head votes over the slots of an epoch:

From the above chart, we can infer:

• There is a fairly constant number of missed head votes.
  • This is expected as lost-key validators contribute a constant portion to that category.
• The beginning of an epoch, particularly the first slot, has significantly more wrong head votes than the rest.
  • This is expected because the proposer in the first slot has to carry out the epoch transition. It must then broadcast that block to reach all attesters. T
• The average amount of missed/wrong head votes is 3 times larger in the first slot of an epoch than in the epochs 2-32.

Focusing on missed head votes and CL clients, we cannot see anything suspicious in the following chart:

In general, it looks like all CL clients are affected by early-in-epoch misses the same:

Missed/Failed Target Votes

Target votes are already easier to get right. The only exception is the first slot of an epoch that follows the epoch boundary: In such cases, the head vote equals the target vote and validators having their target vote wrong tend to vote for the parent block (=the block in the last slot of the previous epoch) instead.

On average, we observe around 150 missed target votes per slot and 4,800 per epoch. This represents around 0.48% of all validators.

Visualizing the same over the different CL clients, we see all clients affected to extents close to their market share.

Looking at the entities that perform better than others, we again see operators such as Lido, Renzo, Mantle, Coinbase, etc. outperforming the average.

Notably, Lido isn’t a single NO but consists of multiple operators that I combined for simplicity.

On the other hand, Rocketpool validators and solo stakers perform worse and miss up to 3% more target votes than expected.

As seen in previous analysis on reorgs, epoch boundaries can cause troubles for certain validators when it comes to proposing a block.
Blocks are more frequently reorged if they are proposed in the first or second slot of an epoch. Thus, we would expect those blocks to be responsible for the largest split-views among validators, causing some to attest to the current block, and others to the parent block.

Even though expected, we can see that the slot index in an epoch has a major impact on failed target votes:

Target votes are the hardest to get right at the beginning of an epoch. This is visible in the above diagram showing the first slot of an epoch with 18x more wrong target votes than other slots. The thing is, timely and correct target votes bring twice as many rewards than head or source votes.

Although looking problematic, I’d argue this isn’t a big issue. A target vote at the beginning of an epoch is essentially just a head vote, and the relative share of failures in the first slot at 6.4% is still relatively low. Furthermore, it is a known fact that epoch boundaries come with many different cascading effects including missed slots, which also contributes to the above finding.

This phenomenon seems to be agnostic to CL clients.

Missed/Failed Source Votes

Source votes are easy to get correct and even validators that are slightly out of sync have a good chance to vote for the right source checkpoint. This is because the to-be-voted-for checkpoint is at least 6.4 minutes (=1 epoch) in the past. Wrong source votes indicate that the validator is either out of sync or on a completely different chain. Thus, target and head votes must be incorrect if the source vote is wrong.

For source votes one cannot differentiate between missed and failed because wrong source votes never make it onchain and are ignored by proposers/validators.

On average, we observe around 100 missed source votes per slot, 3,200 per epoch.

Similar to head and target votes, we observe an increased number of missed source votes at the beginning of an epoch. This MIGHT be related to the increased reorg probability at the beginning of an epoch but more analysis would be needed to confirm that.
In general, validators usually have ample time (at least 32 slots) to cast their source vote. However, if their head vote is incorrect, it might result in the entire attestation being ignored by an aggregator and, consequently, not being recorded onchain.

Best and Worst Validators

Validators cast a vote in every epoch and quickly checking beaconcha.in, more than 99.9% of validators are active in every epoch.

By summing up correct head votes, we can determine the best and worst-performing validators.

The following chart visualizes the average missed/failed head votes per slot over the validator IDs:

Withdrawn validators are excluded.

We can see that the missed slot rate is slightly increasing with increasing validator IDs, with outliers for the validators with IDs 0-30k, 300k-330k, and 780k-790k.
The best validators are the group with IDs from 50k-60k.

Over four weeks, most validators miss around 20-30 head votes:

The following chart has a logarithmic y-axis to make sure we can also see the last bar on the very right that consists of validators that have never attested in the 4 weeks analyzed.

The peak of performance (best validators)

For the following, I use data ranging from epoch 292,655 to epoch 293,105, not the entire time frame analyzed, due to the sheer amount of data involved.

High-performers are defined as validators who haven’t missed voting for the correct head during a time frame of 3 days, starting from the last slot analyzed and going backward.

The following table shows the largest node operators (sorted in descending order by market share) and the percentage of high-performing validators within 3 days compared to the total number of validators for each entity:

^ The entities in green have more high-performing validators than the average.

The shares visualized using a bar chart look like the following:

We can see that the average high-performer rate is around 0-5% for the shown entities.
The outliers are Everstake, Frax Finance and Rockx.

So, what are those 3 parties doing differently than others?

There are two strategies an entity might apply:

1. Attest early to ensure their vote has enough time to travel through the network and reach the next proposer for inclusion.
2. Attest late to ensure they vote for the correct head of the chain. The longer a validator waits, the easier it is to determine the head of the chain as other validators have already voted -> the risk is that the vote might not reach the next proposer in time.

The latter strategy may be referred to as attester timing games.

But what is better?

I asked my Twitter friends, and the majority voted for ‘seen later,’ indicating validators are playing timing games for increased attestation accuracy.

In truth, both are right.

The following chart shows the distributions of attestation-seen timestamps of high-performing validators vs. the rest (non-high-performing validators):

We can see that the largest share of head votes from high-performers is seen between second 2 and 3 in the slot. We observe another spike right after second 5 in the slot. For all other validators (cf. rest), the majority of head votes arrive between second 4 and 5.

This points towards:

• Most attesters are exceptionally good because they are faster than others.
• Some attesters are exceptionally good because they might wait longer for more accuracy.

> Early attestations by high-performing validators are seen some milliseconds earlier than the rest.
> Late attestations by high-performing validators are seen about 0.5 seconds later than the rest.

It is worth noting that every high-performing validator can be part of both groups, e.g., attesting late to ‘weak’ blocks (cf. epoch boundaries) and early for ‘strong’ blocks.
Validators with great network connectivity can afford to wait slightly longer. Furthermore, at any second in the slot, validators with great connectivity have more information available than other validators.

A simple example is Coinbase: Technically, every Coinbase validator can be made aware of the votes of other Coinbase validators before voting. With a 10% market share, this provides significant additional security when voting on the correct head.

By examining the head votes received/seen timings among the largest entities, we can clearly observe the differences. The best performers—Everstake, Frax Finance, and Rockx—typically attest between 4 and 6 seconds into the slot. While these entities outperform others, the following chart does not necessarily indicate a specific strategy being applied.

And for a deeper dive into this topic check out this simulation by Barnabé that goes into the depth of strategic attesting behavior.

Finally, we get the following timings for the attestations over different CL clients:

We like them for what they are… (worst validators)

Other validators are less performant than others. This becomes obvious by looking at the number of missed attestations over time.

First, let’s consider the validators who are offline. There are various reasons for validators to go offline, and occasionally, random validators might experience brief outages. However, there is a small subset of validators that are very likely to remain permanently offline.

We observed 139 validators, representing 0.014% of all validators, who were permanently offline in the 4 weeks analyzed.
Now, one can argue that being offline for over 4 weeks doesn’t mean the validator is permanently offline. While this is fair, validators who have never cast any vote provide a good upper-bound estimate for the number of permanently offline validators who might have lost their keys.

Within those offline validators, we identify 12 solo stakers, 37 rocketpool validators, and 90 belonging to the category unidentified (=20% market share, including many many actual solo stakers).

Most offline validators have low validator IDs:

We can see spikes around 730k and 870k, but the largest portion comes from OG validators with low IDs, those activated before the Merge. This is both expected and unexpected:

• OG stakers are generally crypto-native individuals who can securely manage private keys.
• OG stakers are generally solo stakers who are less sophisticated.

Based on the above, it seems the latter is more likely to hold true.

Moving the focus to the bad validators that miss more than the mean but not all slots in the analyzed time frame, the bar chart looks like the following:

If low-id validators aren’t offline they perform quite well. Looking at the above graph, the largest share of “bad” validators can be found at the IDs 900k-1m.

Attestations, Big Blocks, and Blobs

Big blocks and blocks with many blocks are expected to receive fewer attestations. This is because certain validators might struggle to download and validate the block fast enough and therefore vote for another block.

With EIP-4844 going live, the block size consists of 3 parts:

• EL Payload (~85 KB)
• Beacon Block (excl. EL payload) / CL Part (~5 KB)
• Blobs (~384 KB)

Previous analysis showed that the average beacon block size excl. blobs is around 90 KiB. One blob has a size of 128 KiB. As a result, on average, we get blocks (incl. blobs) of size nr_blobs * 128 + 90, with the blob being the main contributor to the size of a block.

More blobs mean more data that needs to be transmitted across the globe. Thus, we can expect more failed head votes for blocks with 6 blobs than those with one blob.

This expectation holds when looking at the above boxplot diagram:
→ The median missed head votes doubles going from 0 to 6 blobs.

Let’s get more granular…

The following visualizes the block size incl. blobs in MiB over the failed head votes per slot.

This chart shows only wrong/failed head votes and excludes offline validators.

For the sizes above 0.8 MiB, which are most likely blocks with 6 blobs, we can see more weak blocks than for 0 blob blocks. “Weak” because up to 32k attesters of that slot, up to 99%, voted for a different block.
The only way that block still made it into the canonical chain is the next validator building on top of it instead of reorging that block out.

In the analyzed month, we observe 401 blocks with >31k attesters voting for different blocks that still made it into the canonical chain. 233 of them carried 6 blobs. Assuming most validators attest at the latest at second 4 of a slot, those blocks must have been propagated very late such that validators already attested to a different block before seeing it.
This can be confirmed by plotting the “first seen” time of those weak blocks over the seconds in a slot, comparing it to all other blocks:

The chart shows that most blocks are seen between second 1 and 2 in the slot. For those weak blocks, it’s between second 4 and 5, right after the attestation deadline.

We can confirm this by looking at the attestation timing over the seconds in a slot. We can see that 80% of the attestations are seen 5 seconds into the slot. A block propagated at second 4 in the slot will likely miss out on at least ~40% of all possible attestations, no matter how fast it propagates through the network.

Are blobs the problem?

The following chart shows the first seen time of 1-blob blocks vs 6-blob blocks:

We can see that despite 6-blobs blocks being seen later in the slot, the delta is rather small, not to say negligible. At the time of the block arriving, the blobs should have already been seen.

In the past, the fact that a user was (not) using MEV-Boost impacted different performance metrics. Thus, let’s plot MEV-Boost users vs. local builders for completeness:

Finally, comparing three of the largest relays, we get the following image:

While most relays such as Ultra Sound, BloXroute, Agnostic Gnosis, or Flashbots show a very similar curve, we can see the Titan relay having two peaks instead of just one.
This means that some blocks going through the Titan relay are first seen in the p2p network between 2.5-3 seconds into the slot, which is very late.

Notable, those late blocks of Titan still became canonical, pointing towards proposer timing games.

Attestations and Proposer Timing Games

Next, let’s look at the impact of Proposer Timing Games on attestations.
We refer to Proposer Timing Games (see [1], [2]) if block proposers delay their block proposal to give the builders more time for MEV extraction.
Instead of asking the relay for a block in second 0 in the block, a proposer can delay this, e.g. until second 2 in the slot, and maximize profits. This comes with the risk of not getting enough attestations and being reorged out.

Find some real-time visuals on timing games at timing.pics.

Proposer timing games are expected to negatively impact validators’ attestation performance, although this hasn’t been thoroughly analyzed yet. The concern is that proposer timing games could have cascading effects: attesters might slightly delay their attestations to ensure they vote for the correct head of the chain. Knowing proposers are playing timing games, it might be rational to delay the attestation too. Such strategies can be harmful to the network’s overall health.

For more info on the impact of proposer timing games on attestations, check out Caspar’s post on it.

The following graph shows the average number of missed head votes over the seconds in a slot. The relays’ Data API (bidsReceived endpoint) was used for the in-slot timestamps.

Multiple prior analyses showed that using the bidsReceived timestamps provides a good enough approximation of actual propagation timings. Notably, bidReceived must come earlier than the block’s propagation timing.

The above chart shows that the number of missed head votes increases rapidly with being 1 - 1.2 seconds into the slot. The longer a proposer waits the fewer attestations its block is expected to receive.

We can see that the number of missed head votes per slot increases to an average of >4k (12.5% of the committee) for late blocks published more than 1.7 seconds into the slot.
This sounds bad although the numbers are still relatively low compared to the 32k validators that attest in each slot.

Proposing a block with a bid received timestamp of over 2 seconds causes an average of 5k attestations to be missed. This represents about 15% of the committee.

5 posts - 4 participants

Read full topic

Author: 0xbrainjar

Reviewers: Sydney Sweck & Bruno Mazorra

Summary

Recently, Composable launched its IBC Ethereum mainnet connection. The IBC Protocol is emerging as the gold standard for cross-chain communication, as we have previously explored in our comparison analysis here. IBC’s trust levels parallel that of ZK bridging, which is limited to the Ethereum ecosystem and its layer 2s. Originally, the IBC Protocol was also limited to one ecosystem: the Interchain, which includes Cosmos SDK chains and the Cosmos Hub. However, IBC has now been expanded outside of the Interchain/Cosmos ecosystem for the first time by Composable’s Picasso Network.

IBC Ethereum a significant milestone, marking the first time that trust-minimized bridging is available between Ethereum and other IBC-enabled chains including the Cosmos hub, Cosmos SDK chains, Polkadot and Kusama parachains, Solana, and more ecosystems soon. Moreover, this was a huge technological feat, given that this connection required architecting a light client on Ethereum. While various projects were exploring the concept of Ethereum light clients at the time, there were no light clients fully available on Ethereum when we began development.

Now, Composable is in the process of launching a product that aims to bring more utility to cross-domain Ethereum operations: Multi-chain Agnostic Trust-minimized Intent Settlement, or Mantis. This framework serves as a vertically integrated intent pipeline, complete with expression, execution, and settlement. Ultimately, Mantis strives to establish a decentralized market for cross-domain intent expression through a permissionless solver network and intent-settlement framework. Through Ethereum IBC and now Mantis, Ethereum will be optimally positioned to continue in its role as the leading hub of DeFi; new cross-chain use cases to and from Ethereum will be generated, enabling the flow of new liquidity and users to Ethereum, with all of the complexities abstracted away to improve the user experience.

The present article thus summarizes Mantis from our recently-published Mantis Whitepaper and Litepaper. Moreover, this post details how Mantis can benefit Ethereum and other IBC-enabled ecosystems.

About Mantis

The Industry Need

Mantis is a relevant protocol within the present DeFi space for a number of reasons, as it aims to fulfill a number of challenges currently facing the space:

• Optimizing UX and Execution: There has always been a need in the space to optimize both user experience (UX) and execution. If this is accomplished, capital efficiency and value accrual can be maximized for all participants.
• Combatting Centralization Trends: In the multi-chain bridging space, there has been an increased reliance upon centralized structures. Unfortunately, there has been a lack of decentralized solutions that rival the speed and cost of centralized structures.
• Facilitating Trust-Minimized Interoperability: Many bridging structures in place today require putting trust in third-party intermediaries, making them vulnerable to attack. However, new technologies are being introduced with the launch of trust-minimized bridging structures like the IBC Protocol, which powers the Picasso Network. These developments enable generalized message passing and synchronization of protocols and applications across multiple blockchain ecosystems.
• Delivering Intent-Centricity: Intents are another new area of development in the DeFi space that are positioned to further assist in resolving user experience and execution issues. However, many intents solutions are not cross-chain interoperable, and are not vertically integrated with execution and settlement solutions, rendering them unable to accrue value from pay for orderflow.

With Mantis, Composable addresses these present unmet needs in the DeFi space. Overall, our thesis is that cross-domain interoperability widens the intent solution space. We hypothesize that this increased choice in solutions results in value in the form of better user outcomes.

Architecture

Mantis accomplishes its functionalities via the Mantis protocol and rollup, a cross-domain auction mechanism, as well as their synergies with the Inter-Blockchain Communication (IBC) Protocol and the Picasso Network. Moreover, a commitment mechanism between chains allows conditions in the other parts of the architecture to be carried out cross-domain.

The Mantis Protocol & Rollup

The Mantis protocol facilitates optimal execution of cross-domain intents via a competition of solvers. Users sign intents, which are contained on a private rollup mempool. Solvers are staked agents that can a) observe the transactions on the mempool and b) post solutions in the auctioneer contract. The auctioneer contract scores the solutions in terms of users utility maximization. The winner of the auction is responsible for settling the outcome of the intent to the solution settlement contracts in the final chain expressed by the intent.

The Mantis protocol lives on the Mantis Solana Virtual Machine (SVM) rollup. This rollup serves as a coordination and settlement layer for cross-domain intents, in addition providing a framework for cross-domain block proposals and credible commitments. The rollup further allows for assets to be staked and restaked to provide crypto-economic security along the proof-of-stake model. This includes staking both the native token of Solana (SOL) as well as liquid staked token versions of SOL. These assets are staked into the bridge contract of the rollup, which then sends them to the proper place for staking or restaking.

The Mantis rollup also provides developers with a simplified mechanism for designing cross-domain decentralized applications (cdApps), which are defined by their inclusion of scoring, solvers, solution settlement, and cross-domain integrity proofs. An SDK is provided to further enhance the development and integration process.

Cross-Domain Auctions

Mantis plans to introduce cross-domain combinatorial auctions, with the goal of accomplishing the following:

• Optimized cross-domain MEV extraction*
• Cross-domain intent solution atomic settlement
• Efficient blockspace allocation
• Increased distribution of revenue to validators selling items separately

*We would like to take a moment here to reflect on MEV and our goals surrounding this concept. MEV is an evolving term with a number of interpretations. Initially MEV stood for miner extractable value, representing the maximum profit an agent (miner or validator) in proof-of-work blockchain systems could incur from its monopolistic rights over transaction inclusion. With the advent of proof-of-stake systems, MEV has become more often described as maximal extractible value, as miners are largely obsolete. Maximal extractible value still refers to the value that agents derive from strategically reordering and including transactions, but now these agents are frequently searchers.

A number of negative ramifications have been reported from these MEV extraction mechanisms. Thus, Flashbots introduced MEV-geth to Ethereum, which implemented a centralized combinatorial auction where searchers can express complex preferences in bundles. Then, this auction system was decentralized by MEV-Boost, allowing anyone to propose their block by bidding at auction. With the introduction of proposer-builder separation, validators on Ethereum now derive value from their monopolistic power over their slots.

As one can see, value from rearranging and including/excluding transactions can now be carried out by a number of parties in a number of manners. In addition to the extraction by validators, miners, and searchers, builders can also derive profits and users themselves can derive financial benefits from these mechanisms by using protocols such as Flashbots Protect, MEV blocker and Cow Protocol . Therefore, it becomes difficult to define exactly what value accrual mechanisms can be considered MEV.

Another complicating factor in the definition of MEV is that some of the aforementioned value accrual mechanisms have an inverse relationship. Most importantly, there is tension between the profits made by validators and other sellers from MEV and the overall welfare of the system (i.e. total value accrued to all users of the system, including end users, solvers, searchers, stakers, etc.). When overall profits to sellers are maximized, overall welfare goes down.

Thus, the goal of Mantis is not necessarily to maximize MEV extraction. Rather, the goal is to maximize overall welfare.One way in which we hope to achieve this is via our mechanisms designed to allocate blockspace efficiently to the users valuing it the most, such as our cross-domain auctions.

Initially, these auctions will be just-in-time to allow builders to express atomically. For two domains, this will involve two simultaneous English auctions with a unique combinatorial block take-it-or-leave it offer. Buyers can place send blocks with bids for the independent blocks and combinatorial blocks. The problems with this approach are the risk of double-signing and the high level of trust placed in the relay.

Therefore, Mantis aims to later introduce a future combinatorial blockspace market, where the rights to future blockspace on multiple domains can be bought and sold. The new crypto-economic primitive of restaking (such as that being facilitated by the Picasso Network) enables block proposers to issue credible commitments about future block construction. These are promises to build blocks in accordance with specific conditions laid out by execution ticket holders if certain payment thresholds are met. Tickets exist outside of a domain’s consensus protocol and will be exchanged via a combinatorial batch auction where buyers express combinatorial valuations over the tickets and sellers express reserve prices. Then, tickets can be traded or sold in a secondary market. This aims to decrease the monopoly of block sellers while increasing market efficiency.

The IBC Protocol

The IBC Protocol facilitates communication between different blockchain ecosystems. Compared to other cross-chain communication protocols, the benefits of IBC are that it is trustless, secure, censorship-resistant, permissionless, fast, cost-effective, and natively interoperable. For these reasons, Mantis has opted to use IBC as its mechanism for cross-chain communication.

Composable has expanded the reach of the IBC so that it not only connects the Cosmos Hub and Cosmos SDK chains that it originally linked, but also interoperates with Polkadot and Kusama parachains, Ethereum, and Solana. Creating these novel connections required a significant amount of technical development, given that many blockchains lack different components needed for IBC-compatibility.

In the case of Ethereum, the following components needed to be architected in order to enable IBC-compatibility:

• ZK Circuit: This program is able to output a proof given a set of inputs. This proof can then be easily verified to ensure that each computational step that was run inside the circuit was done so correctly. In Picasso’s solution, the ZK circuit connects SNARK ED-25519 signatures to a prover. ED-25519 is a digital signature algorithm (DSA) that offers small key and signature sizes and fast computation being impervious to many common attacks to other DSAs.
• Tendermint Light Client on Ethereum: We constructed a Tendermint light client on Ethereum, which lives as an Ethereum smart contract and is able to communicate over IBC with the light client on Picasso.
• Ethereum Light Client on the Picasso Chain: We also created a CosmWasm contract in the Wasm client of the Picasso Cosmos SDK chain to complete the Ethereum IBC connection.
• IBC Stack on Ethereum: We created a modified IBC stack for Ethereum that consists of Solidity smart contracts on Ethereum. Through this IBC stack, all BC components can operate on Ethereum, facilitating Ethereum’s interoperability with IBC.
• Hyperspace Relayer: The Composable Foundation’s Hyperspace relayer connects the two light clients involved in Ethereum IBC by transferring IBC packets between them. Hyperspace is the first event-driven, chain-agnostic IBC relayer that is based on ibc-rs (the Rust implementation of IBC). Hyperspace can thus relay packets between any IBC-enabled chains.
• Prover: This entity interacts with the relayer and proves to the verifier that something is true without revealing other information. On Picasso, what is being proved is various transactions sent between Ethereum and IBC. In particular, this prover is a rapid SNARK prover living on the Picasso Cosmos SDK chain.
• Verifier: Verifiers receive a proof from provers and validate this claim. This prover-verifier relationship results in the production of zero-knowledge proofs, as Ethereum explains here.

The Picasso Network & Its Restaking Pool

The Picasso Network aims to deliver ecosystem-agnosticism to DeFi. It executes on this vision via the Picasso Layer 1, a Cosmos SDK blockchain that acts as an IBC hub between Cosmos and non-Cosmos IBC-enabled chains.

Picasso is the first censorship-resistant, natively-secured cross-ecosystem interoperability solution. The Picasso Network further emphasizes trust-minimization by drawing on the trustless IBC protocol. While a multisig is initially being used for upgradability of IBC contracts on Picasso, the end goal is to transition to decentralized governance.

Picasso is a critical component of Mantis as it allows the Mantis framework to be cross-chain capable over IBC. Specifically, Mantis transactions are grouped into IBC bundles for shipment based on domain. These bundles are then sent from the Mantis rollup over Picasso IBC and out to relevant blockchains for settlement.

Moreover, a restaking pool on Picasso coordinates the agents that have a combination of stake in different chains. Commitments formed between these actors draw upon this restaking pool.

Development Roadmap

The development for Mantis will be carried out in the following steps:

1. Enabling cross-domain swaps: integrating with IBC bridges and automated market makers across different chains to facilitate seamless asset swaps

2. Setting up the foundational architecture: establishing a robust framework that includes the initial design of the Mantis architecture and the development of standards for scoring mechanisms and IBC for intent-based mechanisms

3. Implementing cross-domain intent-based mechanisms: developing application programming interfaces (APIs) and software development kits (SDKs) that enable users to create and manage cross-domain intents, along with implementing an open-source solver that solves these intents

4. Enriching the restaking layer: building out the restaking layer of Mantis to have additional functionality (simultaneously to step 3)

5. Creating cross-domain MEV auctions: developing an auction system that efficiently allocates blockspace (simultaneously to step 3)

6. Deploying block proposal commitments: enhancing the infrastructure for block proposals and establishing a credible commitment mechanism across domains, including robust fraud-proof mechanisms to maintain trust and security.

7. Completing public launch and scaling: focusing on officially releasing all functionalities and documentation for Mantis

Benefits to Ethereum

Mantis supports Ethereum’s continued role as a leader in DeFi as the space becomes increasingly cross-chain. Composable has already connected Ethereum to the IBC, and therefore, to our trust-minimized bridge. This connection will drive new usership and liquidity to Ethereum from Solana, Cosmos, Polkadot, and Kusama. It will also enable the development of new use cases for ETH outside of Ethereum and on these other networks. Through such new use cases in new locations, DeFi users who do not currently hold ETH will likely be incentivized to do so, and existing users may be incentivized to hold more ETH. Thus, the Ethereum network is positioned to expand its reach even further into the cross-domain DeFi landscape, helping the ecosystem to maintain its reputation as a leader in the space.

Another benefit Mantis aims to deliver is chain abstraction. Mantis provides a mechanism for Ethereum and other domains to easily be participants in cross-chain DeFi without the blockchain, its layer 2s, or any protocols in the ecosystem needing to make significant modifications. Now that Ethereum is integrated with IBC, its innumerable DeFi protocols and applications can be leveraged from within Mantis. A user simply puts their intent for a transaction into the Mantis user interface, and the rest is handled for them. For example, A user may be looking to swap ETH for USDC. Once they input this intent, Solvers on Mantis compete to come up with the best execution route. For the sake of this example, perhaps the best price for this swap is through an ETH-USDC pool on Uniswap. The solver who has proposed the best settlement route wins the rights to settle the solution, routing the funds through Uniswap for the swap, and then back to the user. Once the transaction is settled as specified, the solver is rewarded. In this manner, all parties benefit: new traffic is routed through Uniswap in this example (or more generally, any other protocol or protocols providing best execution), the user has a streamlined experience with optimized settlement, and the solver is rewarded for their role.

Conclusion

Mantis provides the architecture needed for IBC-enabled chains like Ethereum to easily participate in the cross-domain future. This will help Ethereum continue its role at the forefront of DeFi as the industry continues to embrace multi-domain operations.

References & More About Composable

Composable is dedicated to improving DeFi’s accessibility, quality, transparency, efficiency, and security. Our ultimate vision is for the Composable ecosystem to become an execution hub for chain-agnostic transactions. We are actualizing our mission by working to unite the DeFi space, building an ecosystem and a range of infrastructure to support trustless cross-chain operations.

• Mantis Whitepaper
• Mantis Litepaper
• Mantis app
• Composable website
• Composable X/twitter
• Composable Discord
• Composable Telegram
• Composable GitHub

1 post - 1 participant

Read full topic

Maximum Viable Security: A New Framing for Ethereum Issuance

by @artofkot, @damcnuta, @sonyasunkim, @adcv_

Appreciate feedback from @ppclunghe, @ks_kulk, @lazyleger, Juan Beccuti, @entigdd, @stakesaurus, @hasufl, @lex_node, @_vshapolapov, @brettpalatiello

Table of Contents

• TLDR: Embrace security
• 1. The foundations of the Maximum Viable Security (“MVS”) framework
  • 1.1. Ethereum has a clear goal: build a secure and sovereign distributed system for everyone
  • 1.2. A diverse staking economy is key
    • 1.2.1. Stakers
    • 1.2.2. Validating entities
    • 1.2.3. Entities’ decentralization
  • 1.3. There is no future-proof safe level of Security
  • 1.4. Reframing the discourse: expansion over efficiency
• 2. Analysis of Ethereum Issuance reduction proposal within the MVS framework
  • 2.1. The assumption that Ethereum overpays for security is wrong: less issuance may lead to centralization of the validator set
    • 2.1.1 ETF inflows would exacerbate centralization in the context of a 33% stake cap
    • 2.1.2 Staked ETH concentration with CEXs doesn’t necessarily have to happen with a higher stake cap
    • 2.1.3 MVI effect on the ratio of solo stakers
  • 2.2. LST dominance and cost-modeling are inadequate arguments for issuance reduction
    • 2.2.1. Issuance as a cost is a reductive framing
    • 2.2.2. Stakers getting higher real vs nominal yield is not significant
    • 2.2.3. Reducing LST dominance shouldn’t be a primary objective of Ethereum’s monetary policy
• 3. Putting it all together

TLDR: Embrace security

Given Ethereum’s goal of building a secure and sovereign distributed system, we believe viewing Ethereum’s monetary policy through the lens of Minimum Viable Issuance (MVI) is not appropriate. Instead, we propose Maximum Viable Security (MVS) as a new framework for the community to consider in the Ethereum issuance debate. That is,

From: Minimum Viable Issuance (MVI) – minimize issuance, without compromising security.
→
To: Maximum Viable Security (MVS) – maximize security, without compromising scarcity.

After covering the motivation and foundations behind MVS, we evaluate Ethereum issuance reduction proposals through the MVS lens. We show that issuance reduction can compromise security and neutrality in a direct way, through staked ETH concentration with Centralized Exchanges – and this effect, on balance, far outweighs the advantages of cutting the issuance.

1. The foundations of the Maximum Viable Security (“MVS”) framework

1.1. Ethereum has a clear goal: build a secure and sovereign distributed system for everyone

There are many goals of this project; one key goal is to facilitate transactions between consenting individuals who would otherwise have no means to trust one another.
Source: Ethereum Yellow Paper (link)

The growth of Ethereum’s market capitalization from 0 to $400bn today underscores the market’s confidence in its current and future potential. This value hinges on Ethereum’s ability to validate state changes transparently, securely, and sovereignly.

Security is a crucial part of the value proposition. Without sybil resistance and slashing defense (programmable or social) against 34% double-signing attacks, a settlement layer would not be trusted by participants. A secure validation layer is the most scalable (link) foundation for providing transaction settlement with incorruptible finality.

Sovereignty is equally important – Ethereum should be able to defend against more subtle 51% attacks such as short-range reorgs and censoring (link), and should be able to resist coercion by state actors. If Ethereum loses sovereignty (aka autonomy), it loses its value as a neutral settlement mechanism:

"Decentralization" is the broad distribution of a system's intrinsic/accepted forms of power, protecting users against arbitrary exercises of power from the recognized legitimate 'authorities' within the system's logic (e.g., validators). "Autonomy" is the system's resistance against extrinsic/unaccepted forms of power, protecting users against all exercises of power from authorities outside the system's logic (e.g., government authorities).
Source: lex_node (link)

While 34% attacks are costly and 51% attacks are to some extent bounded by reputation and social slashing, a gradual coercion by state actors on independent validators is more feasible, and can even be unintentional. For instance, the European Securities and Markets Authority (ESMA) recently suggested (link) viewing MEV as a form of market manipulation subject to notification requirements from validators. Such regulations could make it impracticable for node operators to continue to function in Europe. In a worst-case outcome, these regulations could propagate to the rest of the world and impose artificial restrictions on how the consensus algorithm works.

High autonomy is therefore maintained through robust decentralization among validators, which includes:

• Client software diversity: running different types of validator software to avoid concentration risk from bugs.
• Node operator diversity: different, independent entities running validator software to prevent individual node operators reaching higher levels of control.
• Geographic and jurisdictional diversity: different levels of base-level infrastructure — such as connectivity to the internet, power supply, law authorities and jurisdictions — that are capable of influencing node operators.

1.2. A diverse staking economy is key

1.2.1. Stakers

Stakers fall into three main categories:

1. Retail and Institutions: These participants delegate their staking to Centralized Exchanges (CEXs)
2. On-chain Actors: They delegate their staking to Decentralized Staking Middleware (DSM), such as Liquid Staking Tokens (LSTs) or decentralized pools, as well as Liquid Restaking Token protocols (LRTs) and Centralized Staking Providers (CSPs).
3. Solo Stakers: These users choose not to delegate and run validators independently

1.2.2. Validating entities

A hypothetical scenario where most ETF Ether is staked with custodial services, like Coinbase, suggests that this is where most of future inflows will likely originate. Recent Bitcoin ETFs have seen ~$15b of inflows. Proportionally applied to Ethereum, this could mean about 4m ETH. Notably, 8 out of 11 Bitcoin ETFs use Coinbase as their custodian, a pattern that may repeat with ETH.

1.2.3. Entities’ decentralization

Contributions to decentralization and thus censorship resistance and neutrality can be approximated as follows: Solo Stakers > Decentralized Staking Middleware > Liquid Restaking Protocols > Centralized Staking Providers > CEXs.

• Solo Stakers: Contribute the most to decentralization because each adds an additional validator
• DSM: Efficiently distribute delegated stake among many parties, bonded via reputation (Lido) or collateral (Rocket Pool, Lido’s Community Staking Module). Their impact on Ethereum’s decentralization is measurable and significant, with data on operational diversity publicly available and regularly updated (link). The Herfindahl-Hirschmann Index (HHI) can also provide a useful proxy on the effect on validation concentration (link)

• Restaking Infrastructure: While not cost-optimized for native staking, these protocols distribute stake among fewer node operators without aggregating it under one entity
• Centralized Staking Providers: Risk aggregating large amounts of stake, but competition among them can bolster decentralization if many can sustain independent businesses
• CEXs: Benefit the most from the power law distribution of AUM, often driving staked ETH concentration. Coinbase, for instance, is the largest node operator with nearly 15% market share.

1.3. There is no future-proof safe level of Security

Anders Lowsson suggests (link) that Ethereum should reduce its issuance, arguing that “excessive incentives for staking, beyond what is necessary for security, can unfortunately over time turn into perverse subsidies, with many downsides.” However, this raises the question of what constitutes “adequate incentives for staking” and what level of security is truly necessary.

What exactly is "neutrality"? I see that term being used in handwavy fashion, especially when scaling comes up, and it's hard to know what we mean by "preserving credible neutrality" at the moment. Would be nice to get some info there. :)
Source: eawosikaa (link)

Today’s global capital markets are valued in the hundreds of trillions of dollars, while Ethereum represents only a tiny fraction of that. For Ethereum to become a neutral settlement layer for the world, its cost of corruption would need to be in the hundreds of billions, if not trillions, of dollars, to capture the value that could be extracted in a possible attack. For context, large value payment systems (excluding retail payments) cleared quadrillions of dollars in value in 2022 (link). In comparison, over the past 12mos, stablecoin transfer value on Ethereum just about cleared $8tn, or 0.5% (link). This is consistent with the proportion of market capitalization of Ethereum relative to global capital markets (well under 1% as well).

The slightest risk of insufficient security would stagnate Ethereum’s growth – decentralization and the resulting neutrality is Ethereum’s #1 competitive advantage. No risk should be taken to erode that, and instead, we should seek to strengthen it even further. To answer Emmanuel’s question, in our framing, we would use “neutrality” interchangeably with “sovereignty” and “autonomy”: ability to defend against censorship and coercion attacks (link). Such that the cost of “coercion” is always higher than the benefit from manipulating the state.

Anders’ argument assumes that a 34% double-singing attack is so costly and 51% censorship attack is so unlikely today, that the network can afford to focus on strengthening other layers. If Ethereum were already a major part of the world’s capital markets, this argument might hold more weight, as incremental risks would be smaller. However, reducing today the network’s most crucial features—security and sovereignty—would compromise the network’s ability to grow.

Currently, Ethereum’s social layer serves as the final defense (link) against norm violations that threaten its credible neutrality. However, this social layer is structurally fragile. It requires constant vigilance from the community so that enforcement can occur on a daily basis. Yet, as Ethereum grows, massive new inflows might bypass today’s social layer altogether. If a large bank, say, staked $1tn worth of Ether with a CEX, what chance does a community of open source developers have to enforce social norms? The key question, as Emmanuel points out, is: What is the threshold for security that Ethereum needs today and in the future? The MVI proposal, in our view, fails to address this critical question, focusing instead on the other effects of reducing the security budget.

1.4. Reframing the discourse: expansion over efficiency

Ethereum should balance incentives for all stakeholders to ensure the highest level of security. This balance involves weighing long-term sustainability and expansion vs short-term efficiency to create enduring security value.

MVS suggests that instead of asking “how much could we reduce issuance for staking efficiency”, we should be asking “how much network incentivisation do we need to perpetuate decentralization to maintain and expand security”.

Strategically, MVI and MVS represent two different paths for Ethereum’s growth. MVI focuses on minimizing costs, benefiting ETH holders in the short term. MVS, on the other hand, emphasizes building a long-lasting moat around the network, optimizing long-term value creation for all stakeholders, including ETH holders.

Ethereum’s unique appeal lies in its secure, credibly neutral blockspace. Unlike commodity blockspace, which competes on price, secure blockspace competes on features. Similar to the advanced chip industry, where success depends on computational ability rather than price, Ethereum should compete on the magnitude of security it offers. This security creates an enduring competitive advantage, accelerating value creation across the ecosystem.

There is a subtlety in that the market cap of Ethereum is a variable that contributes to security, and so minimizing issuance can be seen as bolstering security. Superficially, there is a reflexive effect, where Ethereum’s security both causes and is driven by its market cap. However, we believe that Ethereum’s security making ETH valuable is the primary causation, and therefore security needs to be prioritized. Below we illustrate diagrammatically the alternative value creation paths for Ethereum contributors deciding between MVS and MVI.

2. Analysis of Ethereum Issuance reduction proposal within the MVS framework

We posit that, under the MVS framework, Ethereum issuance reduction proposals risk creating downstream effects that would compromise Ethereum’s security value. Overall, we believe that ETH’s moneyness stands to increase with greater security and autonomy, to a degree that far outweighs the downsides of issuance or externalities such as capital gains taxes.

2.1. The assumption that Ethereum overpays for security is wrong: less issuance may lead to centralization of the validator set

2.1.1 ETF inflows would exacerbate centralization in the context of a 33% stake cap

Lowering the target stake ratio (link) could lead to a concentration of staked ETH with Centralized Exchanges (CEXs), driving capital away from decentralized alternatives.

Consider a scenario where a 33% cap (equivalent to 40.6 million staked ETH) is implemented, and the curve enacts a sharp drop of yield to zero as stake ratio increases from 30% (36.6 million ETH) to 33% (40.6 million ETH). Suppose Ether ETFs are launched in the US, attracting significant capital inflows. If these ETFs use Coinbase as their custodian (as 8 out of 11 BTC ETF issuers do), this could lead to $15 billion in inflows, adding approximately 4.5 million ETH to Coinbase’s custody. The simulated impact on the validation market might look like this; the 40.1m max staked ETH being slightly lower then 40.6 represents the fact that when yield becomes extremely low there is no marginal staker at all on the market.

1. Market forces and fiduciary duties ensure that CEXs like Coinbase squeeze the maximum amount of profit from staking-as-a-service (for their customers and ETF issuers), and long-term the majority of their holdings are staked.

We model the above impact by assigning a 10m staked ETH inflow to Coinbase. When Coinbase’s stake reaches 7.8 million, total staked ETH will be about 36.6 million, causing rewards to drop sharply. Consequently:

2. Lido stETH and other LST/LRT users, being sophisticated on-chain actors, will seek higher rewards elsewhere. The switching cost of moving capital on-chain is extremely low, so there is no incentive for capital to stay – the capital will leave for higher yields in DeFi.
3. CSPs will exit these protocols since the 5% fee from middleware won’t cover their costs.

We model the above two impacts by assigning a 2 million ETH outflow to LSTs/LRTs and a 1 million ETH outflow to other entities.

4. Meanwhile, CEXs like Coinbase can continue offering staking products because their marginal costs are extremely low, and can even be offset by other business segments. Their customers may remain loyal or lack alternatives due to regulations or unsophisticated nature of the user base. This can happen despite Coinbase having higher fees (25%) compared to better-performing alternatives (5-15%).

In this scenario, Coinbase could control 14.3 million ETH, surpassing the 33% network control threshold independently, while Lido and other DSMs lose market share.

2.1.2 Staked ETH concentration with CEXs doesn’t necessarily have to happen with a higher stake cap

Without the cap, both CEXs and on-chain market segments could coexist without putting pressure on each other due to sufficient demand for staking. LSTs, LRTs and CSPs wouldn’t face the dramatic yield decrease that would occur when Coinbase’s stake reaches 7.8 million ETH. Some might argue that Coinbase would undercut other staking providers by lowering its 25% fee. However, this is uncertain. Coinbase’s customer base seems inelastic, meaning the most profitable strategy might be to maintain or even increase their fees. In addition, even if Coinbase goes after the on-chain market and lowers their fees, the market may not be fully efficient – some people might prefer to stick with LSTs due to their decentralization preference.

In a highly segmented market, margins don’t need to uniformly compress, leaving space for both CEXs/CSPs and LSTs/restaking segments to thrive. LSTs and CEXs serve distinct market segments. For CEXs, the most profitable approach is to charge high fees from retail and institutional clients (e.g., Coinbase’s 25%) without directly competing with LSTs. Targeting stake ratios could stifle the market for on-chain actors but not significantly affect the market for retail and institutional clients.

Thus, in the absence of a stake cap, the coexistence of various staking actors could lead to a more balanced distribution of staked ETH across different market segments.

2.1.3 MVI effect on the ratio of solo stakers

The importance of this effect is overrated

Approximately 30 million ETH is delegated, while only 3 million is solo staked. It is evident that delegation dominates as a modality of staking. The key issue is ETH concentration with CEXs, rather than the interaction between solo stakers and LSTs.

LSTs and CSPs can also contribute to overall network quality

While solo stakers are often seen as the backbone of Ethereum’s network security, the contributions of LSTs and centralized staking providers are undervalued.

There is a lot of nuance to the emergent risks of malicious actors emerging from LSTs such as Lido. There certainly are risks (cf. Mike Neuder’s extensive post on the subject, link). However, there are also many benefits to deterministic stake allocation to professional or larger node operators. It’s possible for solo stakers to have different motivations than an LST whose main objective is to decentralize Ethereum validation (link). Some of the most noteworthy examples of malicious proposers, for example, have come from solo validators, such as those involved in the April 3rd, 2023 MEV Boost exploit (link).

Centralized staking providers and LSTs are quantifiably more performant validators than solo stakers. There is significant existing data (link) today to quantify proposer effectiveness and attester effectiveness, which drive fewer missed slots and attestations, faster block propagation and chain finalization. Overall the network is much more stable and responsive with professional validators than it would otherwise be, but also more decentralized.

Issuance reductions would likely decrease the share of solo stakers

Some argue that solo stakers are less elastic with respect to yield, because they are as a cohort more heterogeneous than other validating entities, and hence have a steeper supply curve.

However, our simplified analysis of Ethereum validator economics shows this argument is flawed. Solo stakers in fact have much higher fixed costs, making them much less adaptable to a low issuance rates compared to larger node operators. Specifically,

For solo stakers:

• Staking APR is lower and closer to the Median staking APR (i.e. 2.4% per Rated, link) than scale node operators due to the unpredictability of proposer rewards, tips and MEV
• The costs of running a single validator include hardware (32 GB RAM, 4 TB SSD) and electricity. Home internet plans are sufficient for solo stakers, so broadband cost is assumed to be 0 (no incremental cost).
• In this set up, 100% of solo staker’s total costs are fixed costs. Assuming hardware depreciation of 5 years, profit margins are >90% to solo stakers
• We exclude the need to reserve 32 ETH in capital as collateral, which brings the capital outlay (though not outright investment) significantly higher

Then consider, on the opposite end of the spectrum, a large centralized node operator with 100,000 validators:

• Staking APR is higher and closer to the Average staking APR (i.e. 3.3% per Rated, link) as stake pooling smoothes the unpredictable components of both CL (proposer rewards) and EL (tips + MEV) rewards
• Costs include hardware but also significant operational costs including technical and marketing staff
• Hardware and internet are fixed costs, electricity is a variable cost and staff costs can be seen as a semi-variable cost
  • Employment footprint can be eventually adjusted should the top line be negatively impacted
• Counting half of the maintenance & growth spend as fixed and the other half as variable, we arrive at fixed costs representing 64% of the large node operators’ total costs (i.e. much less than solo stakers). Profit margins are also lower than those of solo stakers

In the event that MVI reduces staking APR for all stakers (e.g. -200bps), the below scenario analysis helps visualize how different stakers may be impacted differently. High level:

• Solo stakers have very limited, if no, way of adjusting their underlying costs. 100% of the reduced staking rewards will fall through to the bottom line, resulting in a dramatic reduction in profit margin. As a result, the payback period on capex (i.e. hardware) multiplies from 3.9 months to 47.2 months in our example, without considering the need to raise 32 ETH to activate a validator to begin with. This raises the question of whether incremental demand from new solo stakers could be sustained in the post-MVI world
• Meanwhile, large node operators have more levers to pull to protect their profits and capex payback periods
  • As in Scenario 1, node operators can raise their commission
  • As in Scenario 2, node operators can raise their commission and reduce variable costs, notably staff costs
  • With very minor changes to their structure they can come back to prior levels of profit

Illustrative figures can be found here

Due to the presence of a higher proportion of fixed costs, solo stakers (and smaller node operators alike) will show higher sensitivity to changes in staking rewards compared to larger node operators. The corollary is that as MVI reduces staking reward APR, the marginal players may be priced out, leading to a greater centralization of stake. This would exacerbate the already decreasing trend of solo stakers alongside Ethereum’s issuance compression over time.

2.2. LST dominance and cost-modeling are inadequate arguments for issuance reduction

2.2.1. Issuance as a cost is a reductive framing

“Issuance as a cost” concerns the dilution effect on native ETH holders and the potential welfare loss due to externalities like taxes.

The first component focuses on the direct impact of issuance. It redistributes network ownership from unstaked ETH holders to staked ETH holders. High issuance rates force ETH holders to stake to avoid dilution. This increases Ethereum’s security and neutrality but comes with inconvenience and some risk for native ETH holders – which, under MVS, doesn’t qualify as strongly undesirable. Moreover, the cumulative effect could even be seen as beneficial, to the extent that more stake landing with a distributed set of validators justifies investors’ inconvenience.

The second component addresses additional costs for stakers due to taxes. ETH holders who earn staking rewards may face tax obligations, creating additional sell pressure. However, this concern is specific to certain jurisdictions and points in time. Furthermore, the impact of this sell pressure on Ethereum’s overall functionality is questionable. Assuming 3.5% staking rewards, a $400bn ETH market cap, and 30% average taxes paid by all stakers, we get $4.2bn in annual sell pressure. Given Ethereum’s daily trading volume is in billions, absorbing 1% sell pressure over a year seems immaterial. Furthermore, LSTs such as wstETH may even provide an efficient way to postpone the tax payments, since the tax event might be triggered only when wstETH is sold.

Even though ETH market cap is significant in determining attack costs, the relatively minor effect of sell pressure does not provide enough security benefits to justify reducing issuance. The trade-offs include potential staked ETH concentration, loss of sovereignty, and a more substantial decrease in market cap as a result.

2.2.2. Stakers getting higher real vs nominal yield is not significant

This argument, while mathematically beautiful (link), is not significant in magnitude. It does not affect security and neutrality in any way; in fact, it is not at all clear if there is any benefit to Ethereum in fewer stakers getting higher real yield compared to more stakers getting less real yield. In addition, this analysis assumes concave supply curves with respect to nominal yield, while it is possible that at a higher staking ratio we should adjust our analysis to concave supply curves with respect to real yield.

2.2.3. Reducing LST dominance shouldn’t be a primary objective of Ethereum’s monetary policy

This argument is directly related to security and neutrality, and thus can be analyzed under a security-maximizing framework.

In his article (link) Mike Neuder analyzed various directions and magnitudes of possible Lido attacks on Ethereum in the future. While there are several potential attacks, all of them have a corresponding mitigation plan. Dual governance is at the heart of many of those mitigations. DG is a mechanism that allows stETH holders to slow down Lido’s governance and exit from the protocol before any decision is made. This mechanism is in active and final stages of development (link).

Another argument for issuance reduction is that stETH risks substituting ETH as the de-facto money and collateral. While there is certainly a possibility that LSTs wind up replacing a lot of ETH functionality in DeFi, it does not diminish the moneyness of ETH – all LSTs are underscored by ETH, and thus derive their value from ETH. In order to execute any of these transactions, users will still need ETH to pay for gas, at the very least. Furthermore, ETH will continue to be bridged to various L2s either way, so at a baseline ETH velocity will already decline with broader adoption of L2s, without compromising its moneyness.

Finally, there are unintended consequences to targeting individual applications in an opinionated manner in order to manipulate the viability of ETH as collateral or as commodity money. The long-term roadmap of Ethereum should not be hostage to short-term tactical considerations, least of all on the application layer. The growth of LSTs has allowed the growth of user activity on Ethereum and has also increased the velocity and usage of Ether itself.

3. Putting it all together

MVI, as a framework, ultimately suggests to squeeze as much as possible out of staking, so that stakers’ cost and revenue are more or less at the same low rate. The major problem of this approach is that market forces structurally do not reward decentralization, and ultimately drive stake concentration to CEXs, which are entities with the lowest cost validators and the most inelastic customer base. Thus the downside of MVI is undermining the security and neutrality of Ethereum. In our view, the benefits of MVI, such as decreasing the selling pressure from taxes, do not justify taking this risk on balance.

MVS, on the other hand, suggests evaluating monetary policies primarily through the lens of how it affects security and neutrality, the core value propositions of Ethereum. One of the arguments for issuance reduction, namely to tackle LST dominance, indeed falls into MVS focus. However, the security and neutrality concerns of LST dominance are of second order in nature (“if dual governance doesn’t work”, “LST becomes an additional risk layer for all users”, etc). Meanwhile, stake accumulating in CEXs rather than in LSTs, LRTs or even CSPs creates a very real risk of staked ETH concentration with one single entity. As such, we do not see the case where LST dominance risk outweighs the risk of stake concentration with CEXs.

While we presented the MVS framework, and accordingly evaluated the issuance reduction proposal, the natural question stands: what would be the right issuance policy under the MVS approach? This is an incredibly complex and deep question that we would like to explore in future. Some of the directions that we have in mind include:

• How do we quantifiably measure security? Is there a way for a protocol to see its security? Credit to the contributions from the StakeSure (link) paper in this direction.
• Guided by MVS, rather than focusing on value creation through cost reductions, we should instead consider the value creation by improving security and neutrality. There is a heuristic argument that increasing issuance can improve security through making the network more complex via a more diverse validator set. Is there a way to make this precise? How do we make sure that the extra issued ETH strictly improves security and neutrality?
• Is there a case for a marginal improvement analysis: the more diverse the validator set is, the more complex the network becomes, and improvements to security could have increasing marginal contributions. (Similar to how complexity contributes to entropy and layered security, link)

Disclosure: authors are variously affiliated with cyber.fund, Lido DAO, Steakhouse Financial, Progrmd Capital

4 posts - 3 participants

Read full topic

I am very proud to release the very first version of Constantine, a high-performance modular cryptography stack for blockchains and proof systems.
It is currently as of July 2024 the fastest implementation of Ethereum-specific cryptographic primitives:

• BLS signatures
• BN254 precompiles (EIP-196 and EIP-197, repriced in EIP-1108)
• BLS12-381 precompiles (EIP-2537)
• KZG Polynomial commitments (EIP-4844)

Constantine has bindings in C, Go, Nim and Rust.

History

Constantine is written in Nim, the language was chosen by Status for Nimbus for its expressiveness, its type system strength, the ease to wrap C and C++ and syntactic closeness to Python so that ethereum/research and PyEVM could be ported with ease.

In February 2018, after woes with C++ in Nimbus, the first library I built was a fixed precision big integer library for uint256.
Then we (at Status) realized that we would also need elliptic curves for secp256k1 and BN254 (also known as BN256 or alt_bn128).

How hard could it be to implement elliptic curves, with cryptographic hardening, once you know how to write big integers?

Turned out it was too hard, after a week or so another approach was taken for time-to-market and correctness reasons:

• Use libsecp256k1 from Bitcoin
• Port 1-1 bncurves from Zcash for BN254
• Use Apache Milagro for BLS12-381

It was then restarted as a personal side-project in February 2020 after learning a lot from implementing hashing-to-curve and Ethereum BLS signatures and identifying significant performance gap. Note that this predates BLST which was initially released in June 2020.

Since then Constantine has seen regular contributions (sometimes with couple months gap) up to where it is today.

Performance

Ethereum BLS signatures (Consensus Layer)

Benchmarks are done on an AMD Ryzen 7840U, a low-power ultra-mobile 8-core CPU from 2023.

BLST (through nim-blscurve)

Nim-blscurve is the backend of Nimbus-eth2. As Nim compiles to machine code through C (or C++), calling C has zero-overhead from Nim.

Repro.
Install the latest Nim version, Nim v2.0.8.

git clone https://github.com/status-im/nim-blscurve
cd nim-blscurve
git submodule update --init
nimble bench

2 benchmarks will be done with 2 different memory management solutions (different implementations of refcounting)
BLST is as-of v0.3.12 (May 2024) with runtime CPU features detection

Backend: BLST, mode: 64-bit
====================================================================================================================================

Scalar multiplication G1 (255-bit, constant-time)                             10332.180 ops/s        96785 ns/op       318784 cycles
Scalar multiplication G2 (255-bit, constant-time)                              4622.247 ops/s       216345 ns/op       712585 cycles
EC add G1 (constant-time)                                                   1795332.136 ops/s          557 ns/op         1836 cycles
EC add G2 (constant-time)                                                    713775.874 ops/s         1401 ns/op         4617 cycles
------------------------------------------------------------------------------------------------------------------------------------
Pairing (Miller loop + Final Exponentiation)                                   1484.823 ops/s       673481 ns/op      2218271 cycles
------------------------------------------------------------------------------------------------------------------------------------
Hash to G2 (Draft #9) + affine conversion                                      6795.232 ops/s       147162 ns/op       484712 cycles
------------------------------------------------------------------------------------------------------------------------------------
BLS signature                                                                  3490.864 ops/s       286462 ns/op       943532 cycles
BLS verification                                                               1212.302 ops/s       824877 ns/op      2716928 cycles
BLS agg verif of 1 msg by 128 pubkeys                                          1139.886 ops/s       877281 ns/op      2889519 cycles
------------------------------------------------------------------------------------------------------------------------------------
BLS verif of 6 msgs by 6 pubkeys                                                203.231 ops/s      4920498 ns/op     16206824 cycles
Serial batch verify 6 msgs by 6 pubkeys (with blinding)                         359.968 ops/s      2778025 ns/op      9150078 cycles
Parallel batch verify of 6 msgs by 6 pubkeys (with blinding)                    615.452 ops/s      1624822 ns/op      5351722 cycles
------------------------------------------------------------------------------------------------------------------------------------
BLS verif of 60 msgs by 60 pubkeys                                               20.310 ops/s     49236672 ns/op    162172626 cycles
Serial batch verify 60 msgs by 60 pubkeys (with blinding)                        42.709 ops/s     23414406 ns/op     77120772 cycles
Parallel batch verify of 60 msgs by 60 pubkeys (with blinding)                  250.298 ops/s      3995236 ns/op     13159139 cycles
------------------------------------------------------------------------------------------------------------------------------------
BLS verif of 180 msgs by 180 pubkeys                                              6.746 ops/s    148237745 ns/op    488256390 cycles
Serial batch verify 180 msgs by 180 pubkeys (with blinding)                      14.419 ops/s     69354258 ns/op    228434104 cycles
Parallel batch verify of 180 msgs by 180 pubkeys (with blinding)                 99.467 ops/s     10053540 ns/op     33113513 cycles
------------------------------------------------------------------------------------------------------------------------------------

Using nthreads = 16. The number of threads can be changed with TP_NUM_THREADS environment variable.

Constantine

GCC generates poor code everwhere assembly is not used, hence we force Clang as a compiler.

git clone https://github.com/mratsim/constantine
cd constantine
CC=clang nimble bench_eth_bls_signatures

--------------------------------------------------------------------------------------------------------------------------------------------------
Pubkey deserialization (full checks)                                                     BLS12_381 G1          22295.550 ops/s         44852 ns/op        147729 CPU cycles (approx)
Pubkey deserialization (skip checks)                                                     BLS12_381 G1          92515.496 ops/s         10809 ns/op         35602 CPU cycles (approx)
Signature deserialization (full checks)                                                  BLS12_381 G2          16808.418 ops/s         59494 ns/op        195958 CPU cycles (approx)
Signature deserialization (skip checks)                                                  BLS12_381 G2          46453.291 ops/s         21527 ns/op         70906 CPU cycles (approx)
--------------------------------------------------------------------------------------------------------------------------------------------------
BLS signature                                                                            BLS12_381 G2           4005.078 ops/s        249683 ns/op        822392 CPU cycles (approx)
BLS verification                                                                         BLS12_381              1498.960 ops/s        667129 ns/op       2197347 CPU cycles (approx)
--------------------------------------------------------------------------------------------------------------------------------------------------
BLS agg verif of 1 msg by 128 pubkeys                                                    BLS12_381              1423.694 ops/s        702398 ns/op       2313504 CPU cycles (approx)
--------------------------------------------------------------------------------------------------------------------------------------------------
BLS verif of 6 msgs by 6 pubkeys                                                         BLS12_381               249.683 ops/s       4005085 ns/op      13191614 CPU cycles (approx)
BLS serial batch verify of 6 msgs by 6 pubkeys (with blinding)                           BLS12_381               420.912 ops/s       2375795 ns/op       7825187 CPU cycles (approx)
BLS parallel batch verify (16 threads) of 6 msgs by 6 pubkeys (with blinding)            BLS12_381               683.399 ops/s       1463273 ns/op       4819062 CPU cycles (approx)
--------------------------------------------------------------------------------------------------------------------------------------------------
BLS verif of 60 msgs by 60 pubkeys                                                       BLS12_381                24.863 ops/s      40220998 ns/op     132477024 CPU cycles (approx)
BLS serial batch verify of 60 msgs by 60 pubkeys (with blinding)                         BLS12_381                48.878 ops/s      20459201 ns/op      67387049 CPU cycles (approx)
BLS parallel batch verify (16 threads) of 60 msgs by 60 pubkeys (with blinding)          BLS12_381               280.961 ops/s       3559207 ns/op      11722847 CPU cycles (approx)
--------------------------------------------------------------------------------------------------------------------------------------------------
BLS verif of 180 msgs by 180 pubkeys                                                     BLS12_381                 8.334 ops/s     119995222 ns/op     395232558 CPU cycles (approx)
BLS serial batch verify of 180 msgs by 180 pubkeys (with blinding)                       BLS12_381                16.488 ops/s      60650899 ns/op     199767961 CPU cycles (approx)
BLS parallel batch verify (16 threads) of 180 msgs by 180 pubkeys (with blinding)        BLS12_381               112.215 ops/s       8911481 ns/op      29351939 CPU cycles (approx)
--------------------------------------------------------------------------------------------------------------------------------------------------

Analysis

• 15% performance improvement on signatures
• 24% performance improvement on verification

Furthermore, it is in theory possible to achieve a 2x performance improvement for signing if there is a need for it.

KZG Polynomial commitment for EIP-4844 (Consensus Layer)

I will reuse my benchmarks from Dec, 2023: Productionize KZG EIP-4844 by mratsim · Pull Request #304 · mratsim/constantine · GitHub