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

0xF40E93A4A8865242c3eC705867d5D872110AF62Cspoiler

1 post - 1 participant

Read full topic

Agenda

PeerDAS Breakout Room #8 · Issue #1145 · ethereum/pm · GitHub

1 post - 1 participant

Read full topic

[Continuing the discussion from Chain-specific addresses]

@vid mentioned in the post above that a addressing standard for transaction hashes which includes the chain it’s on would be helpful. I answered above that there is a draft “CAIP” (chain-agnostic IP, using the CASA chain-specification URI format) which might be useful to revive for cross-VM use-cases, or just useful to copy-paste into a simpler EVM-only EIP achieving the same ends. Comment if you’ve been looking for such a thing or would be interested in prototyping/coauthoring an EIP and/or a CAIP on the subject!

1 post - 1 participant

Read full topic

PR:

This proposal introduces a new smart contract mechanism that allows buyers and sellers to freely negotiate and determine transaction prices on the Ethereum network. A new trading mode is added, where goods can be negotiated rather than only priced. This mechanism allows the seller to set an initial price, and the buyer can propose a new price through negotiation with the seller. Ultimately, both parties can reach an agreement and complete the transaction.

1 post - 1 participant

Read full topic

(Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters.)

Use the following paragraphs for a longer description, or to establish category guidelines or rules:

• Why should people use this category? What is it for?

• How exactly is this different than the other categories we already have?

• What should topics in this category generally contain?

• Do we need this category? Can we merge with another category, or subcategory?

1 post - 1 participant

Read full topic

As we build infrastructure that facilitates embedded wallets, sites have a new opportunity to manage keys to manage permissions they receive (like via ERC-7715).

Alternatively, the site may want to defer key backup to the wallet, while still wanting the benefits of being able to sign on their own behalves.

This is one extremely minimal initial approach to granting sites key material that is deterministically generated to them. It probably needs some refinement in its algorithm, but can be treated as a general outline of an approach for consideration even in this initial draft form.

1 post - 1 participant

Read full topic

Agenda
EOF Implementers Call #57 · Issue #1138 · ethereum/pm · GitHub

Video

EOF Implementers Call 57

link

Call Notes

• clients and compilers - no non-test updates

• switch to prague

• mario discussed 7702/EOF testing features in EEST execution-spec-tests/tests/prague/eip7702_set_code_tx/test_set_code_txs.py at eip-7702-devnet-3 · ethereum/execution-spec-tests · GitHub

• Fuzzing - no new updates

• Discussed converting EOF format tests into format tests.

  • Init containers need extra work, either double wrapping or need to declare deployed container format. Issues include appending data
  • For automated testing we will move to assuming the container is deployed, and in cases where that isn’t going to work we need to notate the tests with expected outputs

• New release of legacy tests - invalid tests have been removed, or fixed, or moved to EEST. No new coverage – all new coverage comes in EEST.

• ISCONTRACT

  • Legacy solidity will not easily be able to determine if it’s EOF or Legacy, so the code may fail compiling to EOF. Old contracts will need new versions or alternates for EOF.
  • Most libraries depending on assembly would need to change for EOF anyway (any use of JUMP, CALL*, EXCODE* for example)
  • May be best solved in solidity? conditional compilation or new is_contract primitive? existing solidity PR Detect EVM version? existing solidity pr
  • Example: OpenZeppelin, Solady, Tycho do deep code interactions and have taken up to a year to implement.
  • Need to do outreach to the AA team, as they expressed concern on ACD that this may be problematic. (Piotr to reach out)

• What is Erigon’s status?

  • Unknown status.

• More on nethermind’s status

  • 7702 is in a different branch from EOF. 7702 will land in Nethermind master first.
  • Will target prague in EOF branch
  • Running published EEST fixtures.

• New fixtures will be published this week. Need to fix an EEST bug relating to EXT*CALL opcodes.

github comment

1 post - 1 participant

Read full topic

Discussion topic for EIP-7762 <link to EIP>

Update Log

2024-09-02: initial draft

External Reviews

None as of 2024-09-03

Outstanding Issues

None as of 2024-09-03

2 posts - 2 participants

Read full topic

Summary

Update by @parithosh (from Eth R&D Discord)

pectra-devnet-2:
Network would be left in its current state to allow for debugging Prysm issue still under investigation

pectra-devnet-3:
Reth is working with the latest spec tests Reth would share some ways of testing 7702 with cast Other clients are still working on passing tests Aiming to have ready branches by mid week if possible

EOF:
Waiting on a 3rd client to try some devnets

peerdas-devnets:
Discussed csc changes and current status

1 post - 1 participant

Read full topic

Abstract

This standard extends the ERC-20 standard to include a metadata function interface and a JSON schema for metadata.

Motivation

Memecoins have demonstrated the value of associating tokens with visual metadata. By standardizing a way to include metadata in ERC-20 tokens, developers can create more engaging and interactive tokens, fostering community engagement.

Specification

The keywords “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.

Every compliant contract must implement the IERCX, and ERC20 interfaces.

This standard includes the following interface:

pragma solidity ^0.8.0;
interface IERC20Metadata is IERC20 {
    /// @dev Returns the metadata URI associated with the token.
    ///  The URI may point to a JSON file that conforms to the "ERCX Metadata JSON Schema".
    function metadata() external view returns (string memory);
}

This is the “ERCX Metadata JSON Schema” referenced above.

{
    "title": "Token Metadata",
    "type": "object",
    "properties": {
        "name": {
            "type": "string",
            "description": "Identifies the asset to which this token represents"
        },
        "description": {
            "type": "string",
            "description": "Describes the asset to which this token represents"
        },
        "image": {
            "type": "string",
            "description": "A URI pointing to a resource with mime type image/* representing the asset to which this token represents."
        }
    }
}

Backwards Compatibility

This standard is backward compatible with the ERC-20 as it extends the existing functionality with new interfaces.

Reference Implementation

pragma solidity ^0.8.0;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
interface IERCX is IERC20 {
    function metadata() external view returns (string memory);
}
contract ERCX is ERC20, IERCX {
    string _metadata = "ipfs://QmakTsyRRmvihYwiAstYPYAeHBfaPYz3v9z2mkA1tYLA4w";
    function metadata() external view returns (string memory) {
        return _metadata;
    }
}

Copyright

Copyright and related rights waived via CC0.

1 post - 1 participant

Read full topic

Discussion topic for EIP-7761

Update Log

• 2024-09-02 initial draft Add EIP: ISCONTRACT instruction by pdobacz · Pull Request #8838 · ethereum/EIPs · GitHub

External Reviews

None as of 2024-09-02.

Outstanding Issues

None as of 2024-09-02.

1 post - 1 participant

Read full topic

This is an open proposal invitation for any developer to write this contract and use the ideas in this proposal. Open License, no limits and credit is appreciated.

I. Executive Summary

Purpose of the Proposal

This proposal introduces ERC-1155 as an alternative to ERC-721 for representing liquidity positions in Uniswap v3. The intent is to leverage ERC-1155’s multi-token capabilities to enhance programmability, efficiency, and flexibility in managing liquidity. This shift aims to offer a more dynamic and automated approach to liquidity management, enabling real-time optimization and broader asset management capabilities.

Key Advantages

• Batch operations and gas efficiency: ERC-1155 allows for batch minting, transferring, and burning, significantly reducing gas costs.
• Enhanced programmability and automation: With ERC-1155, liquidity strategies can be more complex and automated, allowing for dynamic adjustments based on real-time market data.
• Improved user experience: By aggregating positions and intents under unified token types, the user interface becomes more intuitive, simplifying the management of multiple positions.
• Dynamic liquidity management: Real-time optimization and adaptive liquidity strategies can be more effectively implemented using ERC-1155.

II. Introduction

Background on Uniswap v3

Uniswap v3 revolutionized decentralized finance (DeFi) by introducing concentrated liquidity, enabling liquidity providers (LPs) to allocate capital within specific price ranges. This approach, represented by ERC-721 NFTs, created unique, non-fungible liquidity positions that maximized capital efficiency.

Limitations of ERC-721 in Current Implementation

While ERC-721 effectively represents unique positions, it introduces certain inefficiencies:

• Gas inefficiencies: Managing multiple positions requires multiple transactions, leading to high gas costs.
• Complexity: The necessity to manage numerous unique NFTs can complicate operations for LPs, especially those employing more sophisticated strategies.
• Limited programmability: ERC-721’s structure limits the implementation of advanced, programmatic DeFi strategies that require dynamic and automated position management.

Introduction to ERC-1155

ERC-1155, a multi-token standard, supports the creation and management of fungible, non-fungible, and semi-fungible tokens within a single smart contract. This capability allows for more efficient batch operations and versatile token management, making it an ideal candidate for representing liquidity positions in a more programmatic and dynamic manner. By adopting ERC-1155, Uniswap v3 could unlock new possibilities in programmable liquidity management and real-time market adjustments.

III. Technical Overview

ERC-721 vs. ERC-1155: A Comparative Analysis

• ERC-721: Designed for unique, non-fungible tokens where each token is distinct. This standard is excellent for representing individual assets but lacks efficiency in batch operations and programmability.
• ERC-1155: Supports multiple token types within a single contract, enabling efficient batch operations and the representation of both fungible and non-fungible tokens. This flexibility is crucial for implementing complex, automated liquidity strategies.

Alignment with Concentrated Liquidity

Uniswap v3’s core innovation is concentrated liquidity, allowing LPs to provide liquidity within specific price ranges, creating personalized, unique positions. ERC-721 was initially chosen because it effectively represents these unique, one-off positions. However, ERC-1155 can maintain the uniqueness of each liquidity position by leveraging its multi-token structure. Each liquidity position within a pool can be represented by a sub-token under a unique pool ID, where the metadata for each sub-token holds the specific parameters of the position, such as price range and liquidity amount. This allows for the distinctiveness of each position to be preserved while offering enhanced programmability and batch operations. This proposal will include detailed examples of how this structure can be implemented, ensuring that each position retains its unique characteristics within the ERC-1155 framework.

Smart Contract Architecture

The proposed ERC-1155 structure for Uniswap v3 would involve:

• Pool-based tokenization: Each liquidity pool is represented by a unique token ID within the ERC-1155 contract.
• Sub-tokenization of positions: Individual liquidity positions within a pool are represented as sub-tokens, each with its metadata, allowing for precise management of attributes like liquidity amount, price range, and accrued fees.
• Integration with existing protocols: The ERC-1155 contracts would be fully compatible with Uniswap v3’s existing architecture, ensuring seamless integration and operation.

Tokenization of Liquidity Positions

• Representation of liquidity positions: ERC-1155 can represent both the liquidity pool and individual positions within that pool, simplifying the management of aggregated liquidity and enabling more complex, programmatic strategies.
• Metadata management: Each position’s unique attributes are stored as metadata within the sub-token, allowing for real-time data integration and instant market response.

IV. Advantages of Using ERC-1155 for Liquidity Pools

1. Gas Efficiency and Batch Operations
   • Reduced gas costs: ERC-1155’s ability to batch mint, transfer, and burn tokens reduces the number of transactions needed to manage multiple liquidity positions, leading to significant gas savings.
   • Streamlined operations: LPs can manage all their positions within a single transaction, simplifying the process and reducing costs.
2. Enhanced Programmability and Automation
   • Complex strategies: ERC-1155 facilitates the implementation of sophisticated DeFi strategies that require programmable intents and automated actions, such as dynamic rebalancing based on market conditions.
   • Condition-based logic: The standard supports condition-based logic, enabling triggers for rebalancing or adjusting positions automatically when specific market conditions are met.
3. Programmatic Liquidity Management
   • Automated Rebalancing and Fee Management: ERC-1155’s programmability is a key advantage, particularly for automating liquidity management functions. For instance, a liquidity position can be set to automatically adjust its price range in response to market shifts by using condition-based logic embedded in the ERC-1155 contract. These triggers could be based on predefined thresholds or real-time market data, enabling dynamic rebalancing without user intervention. Additionally, fee management can be automated to collect and reinvest fees once they reach a certain threshold, further enhancing LPs’ returns. Customizable algorithms could be developed for users who want to tailor these automated strategies to their specific needs.
4. Pool-Based Tokenization and Modular Management
   • Simplified management: Representing entire pools and their positions within a single contract allows for easier tracking and management of aggregated liquidity, improving the efficiency of liquidity provisioning.
   • Modular approach: This setup supports a modular management strategy where different layers of liquidity can be managed independently or collectively, depending on the strategy employed.
5. Hybrid Asset Management
   • Versatile products: ERC-1155’s ability to handle both fungible and non-fungible assets enables the creation of versatile DeFi products, such as liquidity tokens that can also serve as governance tokens or yield-bearing assets.
   • Cross-protocol integration: The standard allows for the creation of cross-protocol liquidity pipelines, where liquidity can be moved or reused across different DeFi protocols efficiently.
6. Fractional Ownership and Shared Positions
   • Collaborative strategies: ERC-1155 supports fractional ownership of liquidity positions, allowing multiple users to share and collaboratively manage a single position. This can lead to innovative financial products, such as liquidity pools structured as index funds.
   • Crowdsourced liquidity: The ability to fractionalize positions enables new forms of crowdsourced liquidity provisioning, where multiple LPs contribute to and benefit from a shared liquidity strategy.
7. Improved User Experience
   • Unified dashboards: Users can view and manage all their positions and intents through aggregated dashboards, simplifying the interface and making it easier to track and optimize their liquidity strategies.
   • Adaptive management: The flexibility of ERC-1155 allows for adaptive liquidity management, where the system can automatically optimize yield based on market conditions and user preferences.
8. Scalability and Future-Proofing
   • Preparation for growth: ERC-1155’s structure is scalable, making it well-suited for future expansions and integrations within the DeFi ecosystem.
   • AI-driven strategies: The standard’s flexibility also supports the development of AI-driven rebalancing and predictive yield allocation strategies, ensuring that the platform remains adaptable to future advancements in financial technology.

V. Potential Challenges and Mitigation Strategies

1. Increased Complexity in Smart Contract Design
   • Challenge: Managing multiple token types and their interactions within a single ERC-1155 contract introduces additional complexity, potentially complicating the development and auditing process.
   • Mitigation: Modular contract designs and comprehensive testing frameworks can help manage this complexity. By breaking down the functionality into smaller, more manageable components, developers can ensure that each part of the system is secure and efficient.
2. Ecosystem Compatibility and Integration
   • Challenge: ERC-1155 is less widely adopted in the DeFi space compared to ERC-721, which may create integration challenges, especially with existing infrastructure.
   • Mitigation: Developing bridges and compatibility layers that allow ERC-1155 tokens to interact seamlessly with ERC-721 infrastructure can mitigate this challenge. This approach ensures that existing users and protocols can transition smoothly to the new standard without losing functionality or access to liquidity.
3. Security Considerations
   • Challenge: More complex smart contracts can introduce new security vulnerabilities, increasing the risk of exploits.
   • Mitigation: Conducting comprehensive security audits, employing formal verification techniques, and engaging third-party auditors can significantly reduce the risk of vulnerabilities. Additionally, implementing strict testing and deployment protocols will ensure that only thoroughly vetted code is used in live environments.
4. User Adoption and Education
   • Challenge: Users familiar with ERC-721 may need education on the benefits and functionalities of ERC-1155, particularly around its more complex features.
   • Mitigation: Creating detailed documentation, tutorials, and user-friendly interfaces will help ease the transition for users. Educational initiatives, including webinars and interactive guides, can also play a crucial role in helping users understand and take full advantage of the new capabilities.
5. Integration with Layer 2 Solutions
   • Challenge: Gas costs are a significant concern in DeFi, and while ERC-1155 offers batch processing to mitigate this, Layer 2 solutions like Optimism or Arbitrum are also being adopted to reduce costs.
   • Mitigation: The proposal will explore how ERC-1155’s batch operations and programmability can be optimized within Layer 2 environments. For example, batch transactions could be executed on Layer 2 to further minimize gas costs, and the programmability of ERC-1155 could be leveraged to manage liquidity across Layer 1 and Layer 2 seamlessly. This integration would enhance scalability and future-proofing by ensuring that Uniswap’s liquidity management system remains efficient and cost-effective as the DeFi ecosystem evolves.

VI. Use Cases and Implementation Scenarios

1. Automated Liquidity Strategies
   • Rebalancing based on market conditions: With ERC-1155, LPs can set up automated strategies that dynamically rebalance their positions based on real-time market data, ensuring optimal liquidity allocation at all times.
   • Automated fee harvesting: ERC-1155 can be used to automate the collection and reinvestment of fees, maximizing returns for LPs without requiring manual intervention.
   • Sentiment-driven adjustments: LPs can implement sentiment-based strategies that adjust liquidity positions based on market psychology, taking advantage of behavioral finance principles.
2. Integrated DeFi Protocols
   • Layered financial products: ERC-1155 enables the creation of layered financial products that integrate liquidity provision with other DeFi activities, such as yield farming, staking, and governance participation.
   • Cross-chain liquidity sharing: The standard facilitates cross-chain liquidity reallocation, allowing LPs to move liquidity seamlessly across different blockchains or DeFi protocols, optimizing for yield or risk.
3. Fractionalized Liquidity Provision
   • Collaborative ownership: Multiple users can jointly own and manage a single liquidity position, enabling the creation of liquidity index funds or baskets that represent diversified positions across multiple pools.
   • Fractionalized liquidity pools: ERC-1155 supports the fractionalization of liquidity positions, allowing users to buy and sell shares in a larger liquidity pool, democratizing access to liquidity provision.
4. Advanced Financial Instruments
   • Derivatives based on liquidity positions: The standard can be used to create derivatives that are based on the performance of specific liquidity positions, offering new opportunities for hedging and speculation within DeFi.
   • Autonomous risk management: ERC-1155 enables the development of self-optimizing liquidity networks that can automatically manage risk across different pools, adjusting allocations based on market conditions and risk preferences.

VII. Implementation Strategy

1. Smart Contract Development
   • Tailored ERC-1155 contracts: Develop ERC-1155 contracts specifically designed to represent liquidity pools and positions, ensuring that they integrate seamlessly with Uniswap v3’s existing architecture.
   • Adaptive learning protocols: Implement adaptive learning protocols within the smart contracts to enable continuous optimization of liquidity management strategies based on historical data and real-time inputs.
2. Migration Path from ERC-721
   • Transition strategies: Design strategies to transition existing ERC-721-based positions to ERC-1155, ensuring that liquidity providers experience minimal disruption during the migration process.
   • Maintaining liquidity: During the migration, it’s crucial to maintain liquidity in the pools to avoid market disruptions. This can be achieved by providing incentives for early adopters and offering tools to automate the migration process.
3. Integration with Front-End Interfaces
   • Dashboard updates: Update user dashboards and management tools to support the new functionalities offered by ERC-1155, ensuring that users have access to all necessary information and controls.
   • Enhanced wallet compatibility: Work with wallet developers to ensure that ERC-1155 tokens are fully supported, allowing users to manage their liquidity positions directly from their wallets.
4. Testing and Security Audits
   • Comprehensive testing: Implement a rigorous testing phase to validate the behavior of the new ERC-1155 contracts under various scenarios, including high-volume transactions and market stress conditions.
   • Third-party audits: Engage reputable third-party auditors to review the codebase, ensuring that the contracts are secure and free from vulnerabilities before deployment.

VIII. Case Studies and Data Analysis

1. Gas Cost Comparison
   • Quantitative analysis: Perform a detailed comparison of gas costs between ERC-721 and ERC-1155 implementations, highlighting the savings achieved through batch operations and more efficient token management.
   • Case study: Analyze real-world scenarios where ERC-1155 provides significant cost savings for high-frequency liquidity providers managing multiple positions.
2. User Engagement and Efficiency
   • Interaction speeds: Measure the improvements in user interaction speeds and transaction throughput with the adoption of ERC-1155, demonstrating how the new standard enhances user experience.
   • Increased activity: Project the potential increase in liquidity provision activities due to the enhanced efficiencies and new capabilities offered by ERC-1155.
3. Scalability Assessments
   • High usage scenarios: Evaluate the scalability of ERC-1155-based systems under high usage conditions, ensuring that the new standard can handle the growing demand in DeFi without performance degradation.
   • Sustainability metrics: Assess the long-term sustainability of ERC-1155 implementations, focusing on performance metrics and the ability to support future expansions.

IX. Community and Ecosystem Impact

1. Enhancing Developer Ecosystem
   • Innovation opportunities: ERC-1155 opens up new possibilities for developers to build innovative DeFi products, particularly in areas like programmable liquidity, automated strategies, and cross-protocol liquidity management.
   • Community contributions: Encourage open-source collaborations and community contributions to further refine and expand the capabilities of ERC-1155 within the DeFi ecosystem.
2. Market Competitiveness
   • Forward-thinking platform: By adopting ERC-1155, Uniswap v3 positions itself as a forward-thinking platform that embraces advanced token standards, attracting sophisticated liquidity providers and developers.
   • Attracting liquidity providers: The enhanced functionalities and efficiencies offered by ERC-1155 are likely to attract more liquidity providers, increasing the overall liquidity and competitiveness of the platform.
3. Governance and Decentralization
   • Nuanced governance mechanisms: ERC-1155 allows for more nuanced governance mechanisms, where governance tokens can be integrated with liquidity positions, enabling more complex and representative decision-making processes.
   • Community-driven decisions: The flexibility of ERC-1155 empowers the community to drive more effective decision-making, particularly in areas like risk management, protocol upgrades, and ecosystem development.

X. Conclusion

Summary of Benefits

ERC-1155 offers significant enhancements to Uniswap v3’s liquidity management, including improved gas efficiency, advanced programmability, and a more streamlined user experience. By adopting ERC-1155, Uniswap v3 can unlock new possibilities in dynamic liquidity management, enabling the platform to remain at the forefront of innovation in DeFi.

Call to Action

Stakeholders are encouraged to consider the adoption of ERC-1155 for liquidity management in Uniswap v3. The next steps involve research, development, and community engagement to explore the full potential of this proposal and ensure its successful implementation.

XI. Future Directions

1. Research and Development Initiatives
   • Ongoing exploration: Continue to explore the capabilities of ERC-1155 in DeFi contexts, particularly in areas like automated liquidity management and cross-chain integration.
   • Prototypes and pilot programs: Develop and test prototypes to validate the effectiveness of ERC-1155 in real-world scenarios, gathering data to inform further development.
2. Collaboration with DeFi Projects
   • Partnerships: Collaborate with other DeFi protocols to integrate ERC-1155-based liquidity positions, sharing knowledge and best practices to drive broader adoption.
   • Cross-platform integration: Explore opportunities for integrating ERC-1155 with other DeFi platforms, creating a more interconnected and efficient DeFi ecosystem.
3. Continuous Improvement and Iteration
   • Feedback-driven enhancements: Regularly update and refine the ERC-1155 implementation based on user feedback and technological advancements, ensuring that the platform remains adaptable and responsive to changes in the DeFi landscape.
   • Vision beyond the horizon: Anticipate and prepare for the next evolution in programmable finance and liquidity management, ensuring that Uniswap v3 remains a leader in the DeFi space.

1 post - 1 participant

Read full topic

Agenda

Execution Layer Meeting 196 · Issue #1143 · ethereum/pm · GitHub moderated by @timbeiko

Stream

1 post - 1 participant

Read full topic

Agenda

Execution Layer Meeting 195 · Issue #1142 · ethereum/pm · GitHub moderated by @timbeiko

Summary

Recording

2 posts - 2 participants

Read full topic

Summary

Update by @parithosh (from Eth R&D Discord)

pectra-devnet-2 :

• A devnet update was shared, network is unhealthy and a summary can be found on interop
• Network would be left in its current state to allow for debugging
• Nethermind update on blockhash json rpc difference, it isn’t consensus critical so they are still checking how to best handle it. Besu is looking into their debug bug

pectra-devnet-3 :

• 7702 spec tests release has been made, clients are testing with it
• Clients still working on passing all tests
• Aiming to have ready branches by mid week if possible
• Devnet launch can happen wednesday/thursday if so

prague-devnet-4 :

• Teams are working on tests

peerdas-devnets :

• Network still facing issues and clients are working on enr standard and bug fixes
• Barnabas requested for better information in logs about peer scoring to help with debugging peering issues

fuzzing :

• Still being setup

1 post - 1 participant

Read full topic

Agenda

PeerDAS Breakout Room #7 · Issue #1139 · ethereum/pm · GitHub

Notes & chat log

Recording

PeerDAS Breakout Room #7

1 post - 1 participant

Read full topic

Agenda

Consensus-layer Call 141 · Issue #1140 · ethereum/pm · GitHub moderated by @ralexstokes

Summary

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

• Started with Pectra
  • devnet-2 around for debugging, but deprecated soon
    • finality bug in Prysm was identified over the weekend and fixed
  • devnet-3 soon™!
    • some clients ready, others ready in next few days
    • may start devnet with all prepared clients next week, others can join as soon as they are ready
  • Next covered some updates to Pectra EIPs
    • One for EIP-7251 correlated slashing computation, merged!
    • Another for handling execution layer requests in the beacon chain (multiple EIPs)
      • a small bookkeeping issue but should be merged in next few days
  • Turned to a discussion around how to best handle the passing of request data from the EL to CL
    • covers several EIPs in Pectra
    • Felix has this PR to present an option with a minimal number of transformation steps by extracting data from the EL as SSZ and then passing directly to the CL
    • good support from CL devs, will decide on next ACDE
  • Then looked at a PR to update EIP-6110 so that deposit requests from the EL are buffered in a way to prevent CL-layer DoS concerns
    • One open question left around interactions with the MaxEB feature; client teams please take a look so we can merge this in ASAP!
  • Wrapped the Pectra section with a temperature check on two PRs to update EIP-7549
    • further refinement of EIP-7549 features to simplify implementation and make it easier to secure both chain data and network traffic
    • general support from participants, and need a bit more work before we can merge
• And then, PeerDAS
  • some early success with a subset of clients on a local devnet on the path to peerdas-devnet-2
  • clients generally under way to launch peerdas-devnet-2
  • Turned to discuss an issue around timing of PeerDAS proof generation and local block building (where we assume some nodes may have fewer resources available)
    • Work towards peerdas-devnet-2 identified a hotspot in proof generation performance
    • Some proposed solutions from asn here: ⁠data-availability-sampling⁠
    • There was a fairly active conversation about all of the considerations here, as we intend to achieve a performant data facility for any node regardless of size/resource supply; so check the call for the full details!
    • But ultimately, settled on a near-term and longer-term solution. Exploration of both solutions would be helped by a spec so expect to see something along these lines soon.
    • Near-term: go w/ “option 3” linked above, which keeps proof generation on the CL with a richer interface b/t EL and CL during local block building
    • Longer-tem: explore more decentralized block + blob building regimes where lower resourced nodes can leverage higher resourced nodes on the network to assist in blob distribution
      • see ⁠data-availability-sampling if you want to engage with the discussion here!
• Wrapped the call with a discussion around the “union” feature in SSZ
  • currently part of the specification, but has never been used in a “production” setting and so relatively under-developed and under-tested
  • there’s demand to remove or mark them as “experimental” to reduce the design space (in a helpful way!) when discussing various EIPs or client implementations
  • will continue the discussion on the PR: Remove SSZ unions by tersec · Pull Request #3906 · ethereum/consensus-specs · GitHub and likely to do something here to make their status clearer in the specs

Recording

Additional info

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

1 post - 1 participant

Read full topic

This topic is for discussing the proposal of ERC-7757, which introduces a standard for AI-driven automatic transactions on the Ethereum blockchain, triggered by predefined or dynamic “instincts” with associated temptation values.

The full proposal can be found here: ERC-7757 Pull Request

Abstract

This ERC proposes a standard for AI-driven automatic transactions on the Ethereum blockchain, triggered by predefined or dynamic “instincts” with associated temptation values. Instincts represent final targets, but mid-way targets are generated along the path, each with its own temptation value, guiding the AI agents toward the final instinct. If the conditions for an instinct or mid-way target are met, the associated transaction is executed automatically. This standard enables the creation of a self-regulating, adaptive blockchain ecosystem where decisions and transactions are made based on calculated rewards and penalties.

Motivation

As AI and blockchain technologies evolve, the need for autonomous systems that can make complex decisions and execute transactions without direct human intervention becomes more apparent. This standard aims to provide a framework for integrating AI-driven instincts into the blockchain, allowing for more sophisticated, adaptive, and autonomous transaction mechanisms that mimic natural decision-making processes.

Discussion

We welcome feedback, suggestions, and any discussion around this proposed standard. Please review the full proposal and share your thoughts!

Link to the ERC-7757 Pull Request.

1 post - 1 participant

Read full topic

Latest ERC PR

Adoption

https://dune.com/vectorized/erc-7760-proxy-counts

Related Work

An independent work has been done in:

See: GitHub - xiaobaiskill/minimal-upgradable-proxy

This proposal is based off earlier work by JT Riley:

This scope of this proposal includes other variants of minimal ERC-1967 proxies that will benefit from standardization.

Source Code

https://github.com/Vectorized/solady/blob/main/src/utils/LibClone.sol

https://github.com/Vectorized/solady/blob/main/src/utils/ERC1967Factory.sol

Etherscan Automatic Verification

[ ] Transparent (20-byte factory address regular variant)
[ ] Transparent (14-byte factory address regular variant)
[ ] Transparent (20-byte factory address I-variant)
[ ] Transparent (14-byte factory address I-variant)
[x] UUPS (regular variant)
[ ] UUPS (I-variant) 
[x] Beacon Proxy (regular variant)
[ ] Beacon Proxy (I-variant)

1 post - 1 participant

Read full topic

1 Introduction

The L2 WG is an open-source initiative with a scope to

• Identify and document the most relevant use cases and business requirements for Layer 2 and other Blockchain Scalability solutions for EVM-compatible public blockchains

• Define a technical standard with identification and differentiation of classes of scalability solutions as required that meet both ecosystem and enterprise requirements, with a particular focus on interoperability between Layer 2 solutions for EVM-compatible public blockchains

• For EVM-compatible public blockchains, identify, document, and devise solution approaches for Layer 2 Blockchain scalability solution-specific challenges such as MEV, block (gas) limits, TVL concentration, etc.

• Identify and document characteristics of Layer 2 Blockchain environments for EVM-compatible public blockchains that will be key in addressing mainstream and enterprise adoption.

The work is an Ethereum Community Project, which is managed by OASIS.

1.1 Overview

Layer 2 (L2) Transaction Fees are a crucial element of financing the operations of L2 platforms apart from rewards given to participants for providing economic security guarantees such as validators in consensus protocols. Yet how these transaction fees are derived, to whom they are paid, how and where they are displayed to any of the participants in L2 platforms varies greatly between L2 platforms.

Given the above, the need for transparency in an open ecosystem to build trust, and the evolving legal and regulatory landscape around fee transparency and what type of fees can be charged, this document sets out to define the different types of L2 transaction fees and then define requirements around transaction fee transparency for L2 platforms.

Note, that fees associated with asset and data bridges between L2 platforms as well as between L2 platforms and centralized exchanges are beyond the scope of this document.

The standard is an Ethereum Open Community Project specification draft (PSD)

Please, review and comment on the RIP once published as a draft!

1 post - 1 participant

Read full topic

6 posts - 3 participants

Read full topic

Agenda
EOF Implementers Call #56 · Issue #1128 · ethereum/pm · GitHub

Video

EOF Implementers Call 56 [August 21, 2024]

link

Call Notes

• Client and fuzzing updates

  • evmone found a bug that fuzzers couldn’t find
  • besu had subcontainer container bugs found via evmon’s tests a few weeks ago
  • Nethermind is re-writing their subcontainer validation to not be recursive
  • Reth and Geth were not present.

• Spec updates

  • community strongly wants a EXTCODESIZE/ISCONTRACT solution, Libs may not be happy with legacy “escape hatch” contracts rather than using EIP-165 introspections
    • If AA is the reason not to proceed, a clear plan needs to be stated as to how the AA transition is expected to play out.
  • Delegate call into legacy call rule
    • This may break proxies. (EOF proxies, proxying to a legacy contract)
    • A detection of EOF vs legacy contract would be useful. EXTCODEHASH would identify EOF
    • No opinion about 7702 proxy detection detection, can go with legacy treatment.

• Testing Readiness

  • With devnet-4 we need to activate on prague alone
    • EEST will migrate to just “Prague” for tests,
    • EEST will sunset “CancunEIP7692” and “Prague7692” forks
    • Will change once 7702 tests are fully merged into tests
    • Suddenly 7702 tests will work with EOF
  • New fixtures release 1.0.8 - Contains Both pragueEIP-7692 and Cancun7692
  • EOF Container Fuzzing
    • EVMONE and Besu
  • EOF Execution fuzzing
    • possibly goevmlab, guido vranken’s fuzzer.

• Testing matrix

  • Devs, please update
  • Any automation interest?
    • Maybe hive/consume?
      • Still needs final consume setup in CI
      • Consume does not run EOF Validation tests (because engine API is the test interface)

github comment

2 posts - 2 participants

Read full topic

Summary

Update by @parithosh (from Eth R&D Discord)

pectra-devnet-2:

• pectra-devnet-2 status as well as a question about if the blockhash opcode was being tested.
• ethPandaOps is going to write up some local consolidation tests with kurtosis, they should be merged in this week and can help test the latest spec release and devnet-2 bug
• Erigon gave an update on potential reasons for missed proposals with teku. We will try a resync and increasing memory limits, the Erigon team will look into improving performance at the tip of the chain
• Prysm team gave us an update on their blob issue, post resync the prysm nodes are now working

Additional info

• Weekly testing calls won’t be streamed/recorded
• cast supports EIP7702: feat(cast): `cast wallet sign-auth` + `cast send --auth` by klkvr · Pull Request #8683 · foundry-rs/foundry · GitHub

1 post - 1 participant

Read full topic

Background

• using PQC in the Blockchain mitigates risk of Quantum Computers’ attacks.
• signature verification should be happened on on-chain code(solidity)
• Clarify its possibility is a problem of realizability.

What I did

• used SPHINCS+ as a post-quantum signature scheme
  • This is selected because NIST selected SPHINCS+ as a final candidate of PQC scheme
    • FIPS 205, Stateless Hash-Based Digital Signature Standard | CSRC

Result

• I couldn’t realize verification on-chain, because it needs massive gas costs over block gas limit. (30,000,000gas)
• So, it is impossible to use SPHINCS+ as a verification method.

Working Code

• Abount SPHINCS+
  • https://sphincs.org/
• GitHub - kasperdi/SPHINCSPLUS-golang: Implementation of the SPHINCS+ signature framework.
• migrated from Golang code to solidity code
  GitHub - blocq-inc/sphincsplus-verify-sol: solidity code for verify sphincs+ signature

1 post - 1 participant

Read full topic

Agenda

EIP-7732 breakout room #8 · Issue #1135 · ethereum/pm · GitHub

Notes

Highlight by @terence:
Moving to slot auctions seems imminent at this point, the question is when. If we want to have slot auctions for the very first client devnet, then the sooner the better

Recording

ePBS (EIP-7732) breakout room #8

1 post - 1 participant

Read full topic

Agenda

PeerDAS Breakout Room #6 · Issue #1136 · ethereum/pm · GitHub

Notes & Chat log

PeerDAS Breakout Room notes - Google Docs

Recording

PeerDAS Breakout Room #6

1 post - 1 participant

Read full topic

Call for contribution to the Fellowship of Ethereum Magicians

---

In the light of recent feedback, I’d like to continue the discussion started in AllCoreDevs, Network Upgrade & EthMagicians Process Improvements - #23 by timbeiko and focus on the forum itself and how we could improve it. Various community members have expressed their interest in enhancing the Fellowship of Ethereum Magicians.

I invite people that want to contribute to the curation / moderation effort to use this topic to propose their ideas and volunteer. As @bumblefudge suggested, we need more moderators to take care of the topics. We can also leverage discourse AI plugin, as detailed here, to bring changes with little human effort. IMO, we should strive to make the forum more efficient and adapt it so that it can generate fine-grained newsletter/RSS-feed type information. This way, users can subscribe to categories they want to keep up to date with, reducing the effort needed to follow Ethereum’s progress.

Let’s discuss and experiment, innovative propositions are super welcome. I’m convinced we can do all those things while remaining true to the values and purpose of the Fellowship. This one just dropped :

So far we’ve already recategorized and improved the forum as discussed in AllCoreDevs, Network Upgrade & EthMagicians Process Improvements - #24 by nicocsgy

This call for contribution could be a good opportunity for assets to be designed for the forum. I think we have a great theme and it’s under used. While keeping in mind that the fellowship is a technical forum so design shouldn’t go too extravagant. We could have a small poll over logos and category icons. I propose a 1 month period for everyone to submit assets then we can have a poll starting from 2024-09-14T22:00:00Z UTC. Here is my proposal for the logo you may recognize some ethresear.ch vibe:

13 posts - 10 participants

Read full topic

(Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters.)

Use the following paragraphs for a longer description, or to establish category guidelines or rules:

• Why should people use this category? What is it for?

• How exactly is this different than the other categories we already have?

• What should topics in this category generally contain?

• Do we need this category? Can we merge with another category, or subcategory?

1 post - 1 participant

Read full topic

(Replace this first paragraph with a brief description of your new category. This guidance will appear in the category selection area, so try to keep it below 200 characters.)

Use the following paragraphs for a longer description, or to establish category guidelines or rules:

• Why should people use this category? What is it for?

• How exactly is this different than the other categories we already have?

• What should topics in this category generally contain?

• Do we need this category? Can we merge with another category, or subcategory?

1 post - 1 participant

Read full topic

by: Davide Rezzoli (@DavideRezzoli) and Barnabé Monnot (@barnabe)

Many thanks to Yoav Weiss (@yoavw) for introducing us to the problem, Dror Tirosh (@drortirosh) for helpful comments on the draft, and the 4337 team for their support. Reviews ≠ endorsements; all errors are the authors’ own.

This work was done for ROP-7.

---

Introduction

In our previous post, we introduced the ERC-4337 model. This model outlines the fee market structure for bundlers and details the cost function related to the on-chain publishing cost and the off-chain (aggregation costs) of a bundle.

We also introduced the concept of the “Bundler Game”. This game will be the primary focus of the second part. Given a set of transactions, a bundler can choose which transactions to include in their bundle. This creates an asymmetry of information between the bundlers and the user, as the user doesn’t know how many transactions will be included in the bundle. This leads to a zero-sum game where the user is at a clear disadvantage.

This research aims to explore methods to improve the UX by ensuring that users do not need to overpay for inclusion in the next bundle. Instead, users should be able to pay a fee based on the actual market demand for inclusion.

Current state of ERC-4337

In today’s market, the P2P mempool is not live on mainnet and it’s being tested on the Sepolia testnet. Companies building on ERC-4337 are currently operating in a private mode, the users connect via an RPC to a private bundler which will than work with a buidler to publish onchain your useroperation. Bundle Bear app, developed by Kofi, provides some intriguing statistics on the current state of ERC-4337.

In the Weekly % Multi-UserOp Bundles metric, we observe the percentage of bundlers creating bundles that include multiple userops. From the beginning of 2024 to June 2024, this percentage has not exceeded 6.6%. This data becomes even more interesting when considering that many bundlers run their own paymasters, entities that sponsor transactions on behalf of users. Notably, the two largest bundlers who also operate as a paymaster, in terms of user operations published, sponsored 97% of the user operations using their services. The paymaster pays for some parts of the useroperation and the rest is paid by the dapps or other entity.

The question that arises is why paymasters, dApps, etc., are paying for the user operations. Will the user pay them back in the future? We can’t be sure what will happen, but my personal guess is that currently, dApps are covering the fees to increase usage and adoption of their apps. Once adoption is high, users will likely have to pay for the transactions themselves. It’s worth mentioning that for the user to pay for a user operation with the current model is not the best option, since a basic ERC-4337 operation costs ~42,000 gas, while a normal transaction costs ~21,000 gas.

Variations on ERC-4337

Overview of ERC-4337

The mempool is still in a testing phase on Sepolia and is not live on the mainnet. Without the mempool, users have limited options for using account abstraction. Users interact with an RPC, which may be offered by a bundler that bundles UserOps, or with an RPC service that doesn’t bundle, similar to services like Alchemy or Infura, which receive and propagate transactions to other bundlers.

Once the mempool is live, the transaction flow will resemble the diagram below, which is similar to the current transaction flow. A mempool enhances censorship resistance for users because, unlike the RPC model, it reduces the chances of a transaction being excluded. However, even with a mempool, there is still a risk that an RPC provider might not forward the transaction, but the mempool model is particularly beneficial for users who prefer to run their own nodes, as it mitigates this risk.

While bundlers have the potential to act as builders, we prefer to keep the roles separate due to the competitive landscape. Bundlers would face significant competition from existing, sophisticated builders, making building less attractive and potentially less profitable. As a result, bundlers are more incentivized to collaborate with established builders rather than building independently and risking losses.

Combining the roles of bundler and builder into a single entity implies significant changes to the current system. Bundlers would need to compete with existing sophisticated builders, or alternatively, current builders will need to horizontally integrate and assume the bundler role as well. The latter scenario, while more plausible, raises concerns about market concentration and the potential negative impact on censorship resistance.

Bundlers and builders as two different entities

With the users connecting directly to an RPC, everything runs in a more private environment, which doesn’t help with market competition. In the near future the mempool will be on the mainnet increasing competition.

Using a mempool, in which userops are public to different bundlers increases competition, in the case of non native account abstraction having a separation between bundler and builder is needed, in the case of native account abstraction the separation might not be needed since the builder can interpret the userops as normal transactions.

For our model we believe that having a separation between the bundler and the builder also offers some advantages, especially in terms of competition and censorship resistance. Imagine a scenario where all the bundlers are offering a cost \textbf{v} for getting included in their bundle. There will be a bundler who wants to attract more users to achieve higher profits, so they will offer a cost \textbf{v’} where \textbf{v’} < \textbf{v} with enough competition among bundlers, \textbf{v'} will get close to \omega, the aggregation cost for the bundle. In this case, the bundlers who can search more efficiently and have better hardware to include more transactions in a bundle will earn higher fees and in return makes the useroperation for the user cheaper.

This could lead to the following outcome: In a competitive environment, bundlers will lower their prices to be selected by users, who will, in turn, seek the lowest price for the inclusion of their user operation in a bundle. This competition will create a system where the bundler who offers the best price will be selected more often than the bundler who is only trying to maximize their profit by creating smaller bundles. Separating the roles of the bundler and builder can also enhance censorship resistance. A bundler can create a bundle of aggregated user operations and send it to different builders. If the bundle includes operations that could be censored, a non-censoring builder can accept it and proceed with construction. However, it’s worth noting that from a user’s perspective, this setup could increase costs, as the introduction of a bundler adds an additional party, leading to higher expenses.

RIP-7560

Native account abstraction isn’t a novel concept; it’s been under research for years. While ERC-4337 is gaining traction, its implementation outside the protocol offers distinct advantages alongside trade-offs. Notably, existing EOAs can’t seamlessly transition to SCWs, and various types of censorship-resistant lists are harder to utilize. As previously mentioned, the gas overhead of a userOp cost escalates significantly compared to a normal transaction. RIP-7560 won’t inherently resolve the ongoing issue concerning off-chain costs, but it substantially reduce transaction expenses. From the initial ~42000 gas, it’s possible to reduce the cost by ~20000 gas.

Layer2s Account Abstraction

Account abstraction can be utilized in Layer 2 (L2) solutions. Some L2s already implement it natively, while others follow the L1 approach and are waiting for a new proposal similar to RIP-7560. In L2, the L1 is used for data availability to inherit security, while most of the computation occurs off-chain on the L2, providing cheaper transactions and scalability.

In scenarios where computation on L2 is significantly cheaper than the cost of calldata for data availability (DA) on the mainchain, the use of signature aggregation proves highly beneficial. For instance, pairing for BLS on the mainnet is facilitated by the 0x08 precompile from the EVM, which costs approximately ~45000k gas. Consequently, using BLS on L1 is more expensive than traditional transactions.

Compression techniques on L2s are already being used, such as 0-byte compression, which reduces the cost from ~188 bytes to ~154 bytes for an ERC20 transfer. With signature aggregation, the compression efficiency can be further enhanced by using a single signature, reducing the size to ~128 bytes.

In Layer 2s, signature aggregation is a crucial innovation that enhances both transaction efficiency and cost-effectiveness. By combining multiple signatures into a single one, the overall data payload is significantly reduced, which lowers the costs associated with data availability on Layer 1. This advancement not only improves scalability but also reduces transaction costs for users, making the system more economical and efficient.

Signature Aggregation economics in Layer2s

When using an L2 service, the user incurs several costs, including a fee for the L2 operator, a cost based on network congestion, and the cost of data availability on L1.

From a previous research on ”Understanding rollup economics from first principles”, we can outline the costs a user faces when using L2 services as follows:

When a user interatcs with a layer 2 he has some costs that we can define as follow:

• User fee = L1 data publication fee + L2 operator fee + L2 congestion fee
• Operator cost = L2 operator cost + L1 data publication cost
• Operator revenue = User fees + MEV
• Operator profit = Operator revenue - Operator cost = L2 congestion fee + MEV

In the case of non-native account abstraction, an additional entity, the bundler, may introduce a fee for creating bundles of userops.

Considering the bundler, the costs and profits are extended as follows:

• User fee = L1 data publication fee + L2 operator fee + L2 congestion fee + Bundler Fee
• Bundler Cost = Quoted(L1 data publication fee + L2 operator fee + L2 congestion fee)
• Bundler Revenue = User fee
• Bundler profit = Bundler Revenue - Bundler cost = Difference between L1 and L2 costs and quoted prices from the bundler + Bundler fee
• Operator Cost = L1 data publication fee + L2 operator fee
• Operator profit = Operator revenue - Operator cost = L2 congestion fee + MEV

The bundler earns its fee from the user for their services, while the remainder of the user’s payment covers the L2 operator’s costs. If the user is unaware of the bundle size, estimating the actual cost of sending userops becomes challenging, potentially leading to the bundler charging higher fees than the one necessary to cover the operator cost.

Incentive Alignment in L2

The interaction between the bundler and L2 helps address this issue, as L2s are incentivized to keep user costs low due to competition. Overcharging users can drive them to switch to other L2s offering fairer prices.

Let’s redefine our model by introducing the operator. The user bids to the bundler for inclusion in the next L2 block by bidding a value V. The user aims to minimize the data publication fee, while the bundler seeks to maximize their fee or gain a surplus from L2 interaction costs and user fees.

The costs associated with creating a bundle and publishing it on-chain can be divided into two parts:

On-chain cost function: A bundler issuing bundle \mathbf{B} when the base fee is r expends a cost:

Aggregated cost function: The bundler has a cost function for aggregating n transactions in a single bundle \mathbf{B} with base fee of r:

with S' < S the reduced size of a transaction and the pre-verification gas use F' > F, which contains the publication and verification of the single on-chain aggregated signature.

If the user can obtain a reliable estimate for n, they can calculate their cost using the estimateGas function, available in most L2 solutions. Having a good estimation can make the user bid accordingly without having to overestimate their bid for inclusion. This function determines the necessary cost to ensure inclusion. Having a good estimate for n and the estimateGas function can avoid the user to pay for a higher preVerificationGas. In the next section, we will explore various mechanisms to ensure a reliable estimation of n.

Layer2s operate an oracle

The oracle’s role is to monitor the mempool and estimate the number of transactions present. The process works as follows: the Layer 2 deploys an oracle to check the mempool and then informs the user about the number of transactions in the mempool. This enables the user to estimate their bid for inclusion in a bundle. The Layer 2 can request the bundler to include at least a specified number of transactions (n) in a bundle, or else the bundle will be rejected. Once the bundler gathers enough transactions to form a bundle, it sends the bundle to the Layer 2, which then forwards it to the mainnet as calldata for data availability.

Layer2s with shared sequencer

An interesting approach is to have multiple Layer 2 (L2) networks running a shared sequencer. This setup can provide a more accurate estimate of the mempool, as the sequencer reaches an agreement through consensus facilitated by the shared sequencer.

In this configuration, different L2 networks operate independently but share a common sequencer. At regular intervals, these networks check the number of user operations (userops) in the shared mempool. The shared sequencer helps synchronize and aggregate data from these networks. Once they reach an agreement, the information is communicated to the user, allowing them to bid based on the number of userops present.

This approach offers several advantages. Firstly, it provides a decentralized method to determine the number of userops in the mempool, enhancing resistance to collusion. Secondly, it eliminates the single point of failure that could occur if only one system were managing the communication between the user and the mempool. Thirdly, the shared sequencer ensures consistency and reduces discrepancies between the different L2 solutions.

By leveraging the shared sequencer, this method ensures a robust and reliable system for estimating and communicating the state of the mempool to users, thus improving the overall efficiency and security of the process.

In the two explained approaches by using an oracle, there is a potential attack vector where an adversary could generate multiple user operations in the mempool, knowing that they will revert if aggregated together. As a result, the oracle sees that there are n transactions and requires a large bundle, but the bundler cannot create the bundle. This issue could stall the network for many blocks.

Layer2s operate their own bundler

In this proposal, the Layer 2 itself assumes the role of the bundler, while another entity handles the aggregation of signatures (this could be current bundler services). The process works as follows: the Layer 2 operates its own bundler, and users send their operations (userops) to the mempool. The Layer 2 selects some of these userops from the mempool and sends them “raw” to the aggregator, compensating the aggregator for aggregating the signatures. Once the aggregator produces the bundle, it sends it to the bundler, which then forwards it to the mainnet as calldata for data availability.

The main idea is that the Layer 2 handles the collection of userops and then outsources the aggregation to another entity. The Layer 2 pays for the aggregation and charges the user a fee for the service.

There are two different options:

1. Flat Fee Model: The bundler (Sequencer) selects some transactions and charges the user a flat fee. This flat fee is calculated similarly to current Layer 2 transactions, predicting the future cost of L1 data publication. Alternatively, the Layer 2 could charge the user a flat fee based on the cost of bundling n aggregated userops, the layer 2 still have to predict how many transactions will be present in the bundle he will contruct to correctly quote the user, this can be made in the same way is now where the . As it is now where the l2 charge the best comeptitive price to the user that it is in the Layer 2’s best interest to keep the prices as competitive as possible for the user.
   

   

2. Requesting Refunds: If the Layer 2 wants to enhance its credibility, it could enable automatic refunds. This would involve a mechanism that checks how many userops are published in a single block and whether the transactions could have been aggregated. If a userop that could have been aggregated wasn’t, and no automatic refund was issued, the user can request a refund. In this scenario, the Layer 2 could stake some assets, and if the refund isn’t provided, the user could enforce the refund, ensuring fairness and accountability.
   

   

Conclusion

In these two different posts, we outline the difficulties users experience when bidding to be included in the next bundle. In the first part, we presented the ERC-4337 model, explaining the costs a bundler incurs when posting a bundle on-chain and the associated off-chain costs. We also outlined the fee markets for bundlers and began discussing the issue of formatting the bundler. Users experience difficulties with bidding due to a lack of knowledge about the number of transactions present in the mempool at the time of bundling.

In the second part, we explained ERC-4337 and RIP-7560. We then discussed why signature aggregation is more likely to occur on Layer 2 solutions rather than directly on Layer 1. We demonstrated how Layer 2 solutions could address the asymmetric knowledge that users experience in different ways. The first one is to use oracles to signal to the user how many transactions are present in the mempool, with this approach the users knows how much they should bid and can force the bundler to make larger bundles. The third approach which is the simplest is that the L2 acts as a bundler and outsources the aggregation to a third party and lets the users pay a fee for it.

2 posts - 2 participants

Read full topic

Thanks to @Julian and @denisa for the corrections, suggestions and discussions!

Multiple Concurrent Proposers (MCP) has recently become a significant topic of discussion within the community, particularly following the introduction of the BRAID protocol and the rise of DAG consensus. Max’s argument in favor of MCP for Ethereum centers on the monopoly created by leader-based consensus mechanisms, where the leader for a given slot is granted substantial monopolistic power. This concentration of power leads to issues such as short censorship for some transactions.

In leader-based consensus, the designated leader for each slot has the exclusive authority to propose blocks, which allows them to exploit their position for profit maximization, such as through transaction reordering or frontrunning. MCP aims to mitigate these issues by decentralizing the block proposal process, reducing the influence any single proposer can exert over the network during a given slot.

Multiple Concurrent Proposers Economic Order

Let n represent the number of validators in the network. A subset of validators maintains a local chain, denoted by k < n. The protocol at some step will need to pick the union of all local blockchains at slot i and an ordering rule must be applied between transactions of each local chain.

Deterministic Block Ordering: A deterministic rule is applied to order the blocks and its transactions. In the context of MEV-SBC ‘24 event, Max proposes two approaches:

1. Sorting by Priority Fee: Blocks are sorted based on the priority fee of transactions. MEV (Maximal Extractable Value) taxes can be applied, where a percentage of the priority fee is extracted and redistributed by the application. This approach is detailed in the proposal “Priority is All You Need”.
2. Execution Flags: Transactions can set an “execution flag” that indicates specific actions, such as interacting with a particular liquidity pool (e.g., trading ETH/USDC in the UNIv5 pool). When the block ordering rule encounters a transaction with such a flag, it pulls all flagged transactions attempting to interact with that pool and executes them as a batch.

Timing Games with Frontrunning Incentive

Let p be a proposer participating in the MCP protocol, who is responsible for proposing a block in their local chain during slot i. We acknowledge that there exists an inherent delay and processing time required to propose this block. Specifically, the protocol permits a maximum allowable delay of \Delta time units before p incurs penalties.

p may strategically opt to delay their block proposal until \Delta - \epsilon (where \epsilon > 0 ) time units. This delay enables p to potentially exploit a frontrunning opportunity by observing and computing a partial order of transactions submitted by other proposers. By strategically placing their block proposal just before the misslot penalty (no block has been proposed and it’s no going to be accepted for slot i), p could include transactions with higher gas fees, a situation that provides a clear incentive for engaging in frontrunning behavior and the main incentive for playing timing games in this post.

Under the current deterministic protocol rules, such a timing strategy is incentivized as it allows proposers to maximize their rewards through manipulation of transaction order. This situation underscores the need for an effective mechanism. However, a more robust solution may involve revisiting the transaction ordering rules to eliminate this concrete incentive for timing games that lead to such exploitative behaviors, thereby ensuring a fairer and more secure protocol.

Partially Ordered Dataset (POD)

One of the main concerns regarding MCP is the absence of a clearly defined method for determining the order of transactions. It remains uncertain how the sequence and the underlying criteria for ordering will be established, as well as how the influence of clients will be exercised—whether through mechanisms such as auctions, latency considerations, or the risk of spam attacks, as highlighted by Phil at SBC '24.

The team of Common Prefix has conducted a thorough analysis of various consensus protocols, including leader-based, inclusion list, and leaderless consensus models, with a focus on their resistance to censorship. As a result of their research, they developed the concept of a Partially Ordered Dataset. In this model, the order of transactions is determined by the timestamps recorded by the clients, which may lead to a lack of strict ordering when two transactions are recorded simultaneously. The implications of relinquishing strict ordering in transaction processing have not been extensively explored in the existing literature, or at least, I am not aware of any comprehensive studies on the matter.

A POD is a finite sequence of pair \{(r, T), …, (r’, T’)\} s.t. r is round (slot) and T a set of transactions.

A round is perfect r_{perf} if no new transactions can appear with recorded round r_{rec} \leq r_{perf}, which means there is no conflict in the ordering before r_{perf}.

A POD protocol exposes the following methods.

• input event write(tx) : Clients call write(tx) to write a transaction tx .
• output event write_return(tx, π) : after write(tx) the protocol outputs write_return(tx, π), where π is a record certificate.
• input event read_perfect(): Clients call read_perfect() to read the transactions in the bulletin.
• output event read_perfect_return(r, D, Π) : after read_perfect() protocol outputs read_perfect_return(r, D, Π), where r is a round, called the past perfect round, L is a set of transactions, D is a POD, and Π is a past-perfect certificate. For each entry (r', T) in D, we say that transactions in T became finalized at round r'.
• input event read_all() : returns all transactions up to the current round without past-perfection guarantees, hence it can return faster than read_perfect().
• output event read_all_return(D, Π)
• identify(π, Π) → P' ⊆ P : Clients call identify(π, Π) → P' ⊆ P to identify the set P' of parties who vouched for the finalization of a transaction, where Π is a POD and π is the certificate returned by write_return(tx, π).

The properties of Liveness and Security are detailed in the original work, and the following will be utilized in subsequent arguments:

Fair punishment: No honest replica gets punished as a result of malicious operation. If identify(π, Π) → P', where π is a record certificate for transaction tx and Π is a past-perfect certificate for a POD D, can only be created if all parties in P' sign tx and D.

The construction of the POD is as follows: The client will send a transaction to all the validators in the network and will have to wait for n - f signatures to confirm his transaction has been received by the network, where f is the amount of allowed byzantine validators. Once the client received the signature he will record the median of all the signatures he has received, as there is going to be some latency and difference between the validators when they received the transaction.

For the reading set of transactions for some round the client will have two options:

• Believe in synchrony on the txs received: Request all the recorded transactions from the validators for some specific round r. Once obtains the n- f signatures of all the transactions computes the median of the set of transactions based on their timestamps.
• Past-perfect guarantees, no-synchrony believer: Assume r_{perf} to be the minimum of the received r values, then we will not have any transaction with lower timestamp. Now takes the union of all the upcoming transactions. Now the client will have to wait some \delta time to ensure through the gossip mechanism there is no lower r_{perf} and no more transaction for the upcoming round.

PODs mitigating MEV in MCP

Adopting Partially Ordered Datasets (PODs) as the primary data structure for MCP introduces a novel approach that hasn’t been extensively studied, particularly regarding its potential to mitigate the types of MEV games previously described.

In PODs, transactions are ordered deterministically based on their timestamps. While this approach necessitates handling cases where multiple transactions share the same timestamp—or evaluating the likelihood of such occurrences—it fundamentally alters the dynamics of the fronturunning incentive of timing games previously described against other proposers block transactions.

Consider a scenario in slot m where a malicious proposer attempts to front-run or sandwich another transaction. Under the previous deterministic ordering, which was based on auctions and priority fees, such attacks were feasible because proposers could manipulate their position in the ordering by outbidding others or exploiting latency. However, with timestamp-based ordering as implemented in PODs, this strategy changes significantly. An open question is still to know which strategies can be applied with PODs or timestamp ordering to extract MEV and if they are worse in wellfare of the network compared with the described game.

In this new setup, being the last proposer in a slot would actually place that proposer in the final position within the transaction order, limiting their ability to engage in front-running or sandwiching assuming honesty in all nodes. Instead, they would only be able to perform back-running, which is generally considered less harmful than front-running or sandwiching. This shift in ordering strategy could effectively reduce the risk of these more dangerous forms of MEV exploitation.

If a malicious validator attempts to manipulate the order of transactions by bribing proposers, slashing should be applied to the validator. By imposing such penalties, the protocol discourages malicious behavior and ensures that the integrity of the transaction ordering process is maintained. One of the future next questions it’s how can we detect a bad behaviour in the transaction record, maybe applying Turkey’s Method it’s a posible option and assume that outliers are malicious records.

However, the situation is more complex than it appears. The shift to a new game for validators, where transaction ordering is influenced by latency, introduces additional challenges. Validators may now engage in latency games, where geographical proximity to other validators or network nodes becomes a crucial factor in gaining an advantage. To mitigate this, it is essential to ensure that validators are well decentralized across different regions.

Decentralizing validators geographically helps reduce the impact of latency-based advantages. Validators clustered in the same location could lead to centralization risks, where a few validators might dominate the network due to their low-latency connections. This centralization could undermine the fairness of transaction ordering and potentially reintroduce the risk of censorship.

Moreover, validators are incentivized to avoid sharing the same location because doing so decreases the uniqueness of the transactions they can access for a possible backrunning and taking such opportunities. The more validators operate from the same region, the fewer unique transactions each can capture, leading to lower profits from transaction fees, as these would have to be split among more validators. This dynamic encourages validators to spread out, fostering a more decentralized and resilient network that is better protected against latency-based games and the centralization of power. However, the current incentive is still weak and future work will reside in how to provide better incentives for non-centralization.

2 posts - 2 participants

Read full topic

Consider a branch node for an MPT.
Suppose the 17’th item in the branch node list is supposed to be NULL, because the branch node is not a “terminator” node. Ethereum documentation says NULL is encoded as the empty string.
Suppose the 17’th item in the list is supposed to be a value because the branch node is a terminator node. Suppose this value happens to be the empty string.
How to distinguish these two cases?
Note this question should be independent of RLP encoding, which only concerns how we encode the list. I’m asking what’s in the list itself, before considering how the list is subsequently encoded.

1 post - 1 participant

Read full topic

Thanks to Conor, Lin and Swapnil from the Switchboard team, Cecilia and Brecht from the Taiko team, Alex Obadia, Justin Drake, Artem Kotelskiy and the Chainbound team for review.

Abstract

Agreeing on time in a decentralized setting can be challenging: wall clocks may drift between machines, agents can lie about their local times, and it is generally hard to distinguish between malicious intent and just unsynchronized clocks or network latencies.

Ethereum can be thought of as a global clock that ticks at a rate of 1 tick per ~12 seconds. This tick rate is soft-enforced by the consensus protocol: blocks and attestations produced too early or too late will not be considered valid. But what should we do in order to achieve a granularity lower than 12 seconds? Do we always require a consensus protocol to keep track of time?

We want to explore these questions in the context of untrusted L2 sequencers, who don’t have any incentive to follow the L2 block schedule that is currently maintained by trusted L2 sequencers, and will likely play various forms of timing games in order to maximize their revenue.

In this article, we introduce mechanisms to enforce the timeliness, safety and non-extractive ordering of sequencers in a decentralized rollup featuring a rotating leader mechanism, without relying on additional consensus, honest majority assumptions or altruism. To do so, we use three key primitives:

1. Client-side ordering preferences,
2. Ethereum as a global 12s-tick clock,
3. Verifiable Delay Functions.

Lastly, we show the case study of MR-MEV-Boost, a modification of MEV-Boost that enables a variation of based preconfirmations, where the same construction explored can be applied to reduce the timing games of the proposer.

Rationale

Rollup sequencers are entities responsible for ordering (and in most cases, executing) L2 transactions and occasionally updating the L2 state root on the L1. Currently, centralized sequencers benefit from the reputational collateral of the teams building them to maintain five properties:

• Responsiveness: responding to user transactions with soft commitments / preconfirmations in a timely manner. We want to highlight that this definition includes the timely broadcast of unsafe heads on the rollup peer-to-peer network.
• Non-equivocation (safety): adhering to preconfirmation promises when submitting the ordered batch on the L1, which is what will ultimately determine the total ordering of transactions.
• Non-extractive ordering: not extracting MEV from users by front-running or sandwiching, or by accepting bribes for front-running privileges.
• Liveness: posting batches to L1 and updating the canonical rollup state regularly.
• Censorship-resistance: ensuring that no valid transactions are deliberately excluded by the sequencer regardless of the sender, content, or any external factors.

In this piece we are concerned with how the first four properties can be maintained in a permissionless, untrusted setting. Note that censorship-resistance is ensured by construction: by introducing multiple organizationally distinct sequencers in different geographies and jurisdictions we have a strong guarantee that any transaction will be accepted eventually.

Consider a decentralized sequencer set S := \{S_1,\dots,S_n\} with a predictable leader rotation mechanism and a sequencing window corresponding to a known amount of L1 slots. For simplicity, let’s assume S_{i} is the current leader and S_{i+1} is the next one. At any point in time, only one sequencer is active and has a lock over the rollup state.

Here are two strategies that sequencer S_i can explore to maximize its expected value:

1. Delaying the inclusion of transactions

Suppose a user sends a transaction to S_i at a certain L2 slot. Then, the sequencer could wait some time before inserting the transaction into a block in order to extract more MEV with sandwich attacks in collaboration with searchers or by directly front-running the user. In particular, since MEV grows superlinearly with time, it’s not in the sequencer’s best interest to commit early to a transaction. The worst case scenario would be the sequencer delaying inclusion until the sequencer rotation ^1.

2. Not publishing unsafe heads in the rollup peer-to-peer network

In this setting the sequencer has low incentives to publish the unsafe heads in the rollup network: since L2 blocks are signed by the sequencer (e.g. in Optimism), they act as a binding commitment which can be used by users to slash it in case of equivocations.

This has a major downstream consequence on the UX of the rollup: both the next sequencer and users need to wait until a batch is included to see the latest transactions. For users it means they won’t know the status of their transactions in a timely manner, while the next sequencers risks building blocks on invalid state.

We will now explore mechanisms to mitigate these behaviours and introduce slashing conditions for sequencers.

Primitive 1: Transaction Deadlines

We introduce a new EIP-2718 transaction type with an additional field:

• deadline - uint256 indicating the last L2 block number for which the transaction is considered valid.

This idea is not entirely new. For instance, the LimeChain team has explored this in their Vanilla Based Sequencing article. However, in our variant the deadline field is signed as part of the transaction payload and it is not expressed in L1 slots.

The reasoning behind it is that the sequencer cannot tamper with either the deadline field or block.number (because it is a monotonically increasing counter), and therefore it is easy to modify the L2 derivation pipeline to attribute a fault in case the sequencer inserts the user transaction in a block where block.number > deadline.

This approach mitigates problem #1. However, it does not in any way solve the responsiveness issue, since sequencers can still delay proposing the block in order to extract more MEV.

Primitive 2: Ethereum as a Global Clock

A simple rotating sequencer design would be one where S_i loses the power to settle batches after the end of its sequencing window W_i, which is dictated by an L1 smart contract. However, the sequencer still needs some time to post the batch with the latest L2 blocks. We therefore introduce an inclusion window that is shifted n \geq 1 slots ahead of W_i, where S_i still has time to land rollup batches on L1 with the last L2 blocks, even if the responsibility of sequencing has shifted to S_{i+1}.

In case of any safety fault, the sequencer should be slashed. If the sequencer has not managed to post all their assigned L2 blocks by the end of its inclusion window, it will forego all associated rewards. Optionally, there could also be penalties for liveness faults. This also helps with the problem of collaboration with the next sequencer, by ensuring that the latest blocks will be known to it within n\cdot12 seconds. Ideally, we’d like to keep n as small as possible with a value of 1.

There are still some potential issues here: getting a transaction included on Ethereum is probabilistic, meaning that you can’t be sure that a transaction you send will actually be included in time. In this context it means that the last batch sent by an honest leader may not be included in the L1 by the end of its inclusion window. This can be helped with two approaches:

• A “based” setup, where the sequencer is also the L1 block proposer and can include any transactions right up to the point they have to propose, or
• Using proposer commitments with a protocol like Bolt. We expand more on this in the ”Further work” section below.

Note that we assume there is a registry smart contract that can be consulted for the currently active sequencer, i.e. it implements some leader election mechanism and takes care of sequencer bonds along with rewards and penalties. It is up to the rollup governance to decide whether the registry can be fully permissionless or if it should use an allowlist. In case of any misbehaviour, governance would be used to temporarily or permanently remove the sequencer from the allowlist.

Primitive 3: Verifiable Delay Functions

Verifiable Delay Functions (VDFs henceforth) are a cryptographic primitive that allows a prover to show a verifier that a certain amount of time was spent running a function, and do it in a way that the verifier can check the result quickly.

For instance, consider a cryptographic hash function h and define the application

where s is a byte array an n is a natural number.

Composing (or chaining) hash functions like SHA-256 cannot be trivially sped up using parallel computations, but the solution lacks efficient verification ^2 as the only way to verify the result is to recompute the composition of functions. This solution appeared as a naïve VDF in Boneh’s paper, and for this reason it is referred to as weak.

Another example of VDF is iterated squaring over a group of hidden order, with which it is possible to construct time-lock puzzles. We’ll explore the usage of the latter in the next sections.

Why VDFs tho?

VDFs are very useful in the context of sequencing because they can act as a proof of elapsed time for the duration of the block (specifically block_time / max_adversary_speedup, see “Security Considerations”). Consider the following algorithm for the block production pipeline:

1. At the beginning of L2 block N, the sequencer starts computing a VDF that takes an L2 block time (or slightly less) to compute for honest players, using the previous block hash as its input.
2. After the end of the L2 slot the sequencer builds a block B_N where the header contains the result of the VDF, denoted V_N. We call this sealing a block. This means the block hash digest contains V_N.

This algorithm has the nice property of creating a chain of VDF computations, in some sense analogous to Solana’s Proof of History from which we inherit the security guarantees. What does this give us in the sequencer context? If we remember that a sequencer has a certain deadline by which it has to post batches set by the L1 slot schedule, we can have the L1 enforce that at least some number of L2 blocks need to be settled. This has two downstream results:

• The sequencer must start producing and sealing blocks as soon as their sequencing window starts. Pairing this with the transaction deadline property results in an upper bound of time for when a transaction can be confirmed. If they don’t follow the block schedule set by the VDF and the L1, they risk not being able to post any batch.
• We mitigate problem #2 by taking away the incentive to withhold data (not considering pure griefing attacks): this is because the sequencer cannot tamper with an existing VDF chain, which would require recomputing all the subsequent VDFs and result in an invalid batch.

In general, for the sake of this post we will consider a generic VDF, provided as a “black box” while keeping the hash chain example in mind which currently has stronger guarantees against ad-hoc hardware such ASICs. See “Security Considerations” below for more insights.

Proving correct VDFs

If a sequencer provides an invalid VDF in an L2 block header it should be slashed, and ideally we’d like to ensure this at settlement time. However, recalculating a long hash chain on the EVM is simply unfeasible due to gas costs.

How to show then that the number of iterations of the VDF is invalid? One way could be to enforce it optimistically (or at settlement, in case of ZK-rollups) by requiring a valid VDF chain output in the derivation pipeline of the rollup. In case of equivocation in an optimistic rollup the sequencer can be challenged using fraud proofs.

Hardware requirements

Since by definition VDFs cannot be sped up using parallelism, it follows that computing a VDF can be done by only using a single core of a CPU, and so it does in our block production algorithm.

This makes it different and way more lightweight compared to most Proof-of-Work consensus algorithms such as Bitcoin’s which requires scanning for a value such that, when hashed with SHA-256, the hash begins with a certain number of zero bits.

It’s also worth to note that modern CPUs are optimized to compute the SHA-256 hash function. Since 2016 Intel, starting with the Goldmount family of chips, is offering SHA Extensions in the Core and Xeon line-ups on selected models which introduces three new instructions specialized in computing different steps of the hash function algorithm more efficiently.

Lastly, single-core performance has stagnated over the years indicating that there is a minor benefit in investing in the latest generation of CPUs, thus lowering down the requirements of the system.

Case Study: MR-MEV-Boost

Multi-Round-MEV-Boost, is a modification of MEV-Boost that enables based preconfirmations by running multiple rounds of MEV-Boost auctions within a single L1 slot. The usage of this primitive is to output after each round a based rollup block built by L2 block builders. As shown in the article, this approach inherits the L1 PBS pipeline and mitigates some of the negative externalities of based preconfirmations as a result.

Like MEV-Boost, this fork relies on the opted-in proposer to be an auctioneer which ends the sealed auction by calling the getHeader (Builder-API) endpoint of the relays. After having signed the sealed bid, the getPayload (Builder-API) is called by the proposer to receive the actual content of the winning bid and to publish the block in the based rollup network.

In the original protocol, the end of the auction usually coincides with the end of the L1 slot (more precisely, near one second after it); delaying it results in a high risk of not being able to broadcast the block in time to gather all the needed attestation and forgo all its associated rewards. As such, a block time is proposed every twelve seconds with consistency, enforced by Ethereum consensus.

In contrast, given it consists of multiple rounds happening during the slot, in MR-MEV-Boost an untrusted proposer is incentivized to end the auction seconds later or earlier ^{3} according to the incoming bids, in order to extract more more MEV. In the worst case, MR-MEV-Boost will reflect L1 block times. Another consequence of this is an inconsistent slot time for the based rollup. This can be seen as a much more serious form of timing games.

In the article, the discussed possible solutions to this problem are the following:

1. Introduce user incentives: if users determine that a proposer is misbehaving, they stop sending transactions to said proposer.
2. Introduce a committee (consensus) to attest to timeliness and maintain slot durations.

We now argue that a trustless solution that strongly limits the proposer without requiring actions from the user does exist, and it leverages the same construction we used for the VDF-powered block production algorithm in the context of decentralized sequencing.

The construction is fairly simple and consists of computing a VDF that lasts x := 12/r seconds, where r is the number of rounds in an L1 slot (the L2 block time). The proposer must calculate this VDF using the previous based rollup block hash as public input and, at the end of the round, sending it along with the body of a modified getPayload call. The output of the VDF is then stored in the rollup block header and if invalid can result in slashing the proposer after a successful fraud proof.

With this approach the amount of time a proposer can delay the end of a round is limited: for instance if the first auction ended one second later then during the last round it won’t be able to provide three seconds of computation for the VDF but two, resulting in an invalid block and consequent slashing ^4. This is because in order to start computing a valid VDF, it requires the previous block hash as its input, implying a sealed block.

Security Considerations

Are VDFs really safe for this purpose?
Suppose an adversary owns hardware which is capable of computing the VDF faster compared to the baseline of honest players without getting noticed (otherwise the number of iterations for the VDF is adjusted by the protocol). Then, the faster the attacker (max_adversary_speedup), the less our construction would constrain the space of its possible actions. In particular, the sequencer would be able to commit a bit later to blocks and be able to re-organize some of them for extracting more value.

However, given we don’t need the “fast proving” property, hash-chains have proven to be robust with Solana’s Proof of History and will continue to be at least in the short-term. Also, our security requirements will not be as strict as something that needs to be enshrined in Ethereum forever.

Some solutions and directions to get stronger safety guarantees can be found in the ”Further work” section below.

Current limitations

Sequencer credibility

As with many new services which leverage (re)staking, the credibility of the sequencer has an upper bound which is the amount it has staked: if a MEV opportunity exceeds that, then a rational untrusted actor would prefer to get slashed and take the MEV reward.

Leader rotation can be a critical moment

As discussed in the batcher and registry smart contract section, the inclusion window is shifted of one slot forward at minimum compared to the sequencing window. This is needed because of the time required to settle the last batch before rotating leader, but leaves an additional slot time of at least 12 seconds in which the sequencer has room to re-organize the last L2 blocks before publishing them on the rollup peer-to-peer network. As a consequence, liveness is harmed temporarily because S_{i+1} might be building blocks on invalid state if it starts to sequence immediately.

Lastly, one additional slot might not be enough to settle a batch according to recent data on slot inclusion rates for blobs. This can be mitigated by leveraging new inclusion preconfirmation protocols, as explained below.

Sequencer last-look

Our construction makes very difficult for a sequencer to reorg a block after it has been committed to, however it doesn’t solve front-running in its entirety. In particular, the sequencer may extract value from users transactions while building the block with associated deadline field. A possible solution along with its limitations is explored in the section below.

Conclusion

In this article, we explored mechanisms to enforce the timeliness, safety, and non-extractive ordering of untrusted L2 sequencers in a decentralized rollup environment.
The primitives discussed ensure that sequencers can act more predictably and fairly, mitigating issues such as transaction delays and data withholding. Moreover, these techniques can reduce trust assumptions for existing single-sequencer rollups, aligning with the concept of rollups functioning as “servers with blockchain scaffolding”. These findings provide a robust framework for the future development of decentralized, secure rollup architectures.

Further work

Trusted Execution Environments (TEEs) to ensure the sequencer is not running an ASIC

A Trusted Execution Environment is a secure area of a CPU, often called enclave, that helps the code and data loaded inside it be protected with respect to confidentiality and integrity.
Its usage in blockchain protocols is an active area of research, with the main concerns being trusting the hardware manufacturer and the various vulnerabilities found in the past of some implementations (here’s the latest).
Depending on the use case these trust assumptions and vulnerabilities might be a deal-breaker. However, in our setting we just need a guarantee that the sequencer is not using specialized hardware for computing the VDF, without caring about possible leakage of confidential data from the enclave or manipulation of the wall clock / monotonic clock.

Adapt existing anti-ASICs Proof-of-Work algorithms

The Monero blockchain, launched in 2014 as a privacy and untraceable-focused alternative to Bitcoin, uses an ASIC-resistant Proof-of-Work algorithm called RandomX. Quoting their README:

RandomX is a proof-of-work (PoW) algorithm that is optimized for general-purpose CPUs. RandomX uses random code execution (hence the name) together with several memory-hard techniques to minimize the efficiency advantage of specialized hardware.

The algorithm however leverages some degree of parallelism; it is an interesting research direction whether it can adapted into a single-core version, leading to a new weak-VDF.
This approach, while orthogonal to using a TEE, can potentially achieve the same result which is having a guarantee that the sequencer is not using sophisticated hardware.

Time-lock puzzles to prevent front-running

As mentioned in the “Current limitations” section, our construction doesn’t limit the problem of sequencer front-running the users. Luckily, this can be solved by requiring users to encrypt sensitive transactions using time-lock puzzles, as we will show in more detail in a separate piece. However, this solution doesn’t come free: encrypted transactions or encrypted mempools can incentive spamming and statistical arbitrage, especially when the protocol fees are not very high.

Inclusion Preconfirmations and Data Availability layers

Batch submissions to an L1 contract could be made more efficient by leveraging some of the new preconfirmations protocol like Bolt by Chainbound or MEV-Commit by Primev to have guaranteed inclusion in the same slot. In particular, sequencing windows should end precisely in the slot before one where the proposer is running the aforementioned protocols in order to leverage inclusion commitments.

Additionally, the batch could be posted into an efficient and lightweight Data Availability layer run by proposers to enforce a deadline of a configurable amount of seconds in the beginning of the slot, otherwise the sequencer would be slashed.

---

Footnotes

1. More precisely, if an operator controls multiple subsequent sequencers it could delay inclusion until the last sequencer rotation.
2. In Solana, the verification of a SHA-256 chain is actually parallelised but requires dividing a block associated to a ~400ms computation into 32 shreds which are forwarded to the rest of the validators as soon as they’re computed. As such, verification is sped up by computing the intermediate steps of the hash chain in parallel.
3. In general, the proposer will end some rounds earlier as a side effect of delaying other rounds. For example, it could force a longer last round to leverage possible L1 <> L2 arbitrage opportunities.
4. There is an edge case where the proposer might not be able to compute all the VDFs even if honest, and it is due to the rotation mechanism: since the public input of the VDF must be the previous rollup block hash, during rotation the next leader will need some time before hearing the block from the rollup network, potentially more than 1s. This could lead the next proposer to be late in computing the VDFs.
   To reduce this risk, the next proposer could rely on various parties to receive this information such as streaming services and/or trusted relays.

1 post - 1 participant

Read full topic

Joint work with @b-wagn, A Documentation of Ethereum’s PeerDAS

The long-term vision of the Ethereum community includes a comprehensive data availability protocol using polynomial commitments and tensor codes. As the next step towards this vision, an intermediate solution called PeerDAS is about to integrated, to bridge the way to the full protocol. With PeerDAS soon becoming an integral part of Ethereum’s consensus layer, understanding its security guarantees is essential.

The linked document aims to describe the cryptography used in PeerDAS in a manner accessible to the cryptographic community, encouraging innovation and improvements, and to explicitly state the security guarantees of PeerDAS. We focus on PeerDAS as described in Ethereum’s consensus specifications [Eth24a, Eth24b].

Our intention is two-fold: first, we aim to provide a description of the cryptography used in PeerDAS that is accessible to the cryptographic community, potentially leading to new ideas and
improvements that can be incorporated in the future. Second, we want to explicitly state the security and efficiency guarantees of PeerDAS. In terms of security, this document justifies the following claim:
Theorem 1 (Main Theorem, Informal): Assuming plausible cryptographic hardness assumptions, PeerDAS is a secure data availability sampling scheme in the algebraic group model, according to the definition in [HASW23].

We hope to receive feedback from the community to make further improvements to this document

1 post - 1 participant

Read full topic

Co-authored by @pememoni and @shakeshack. With special thanks to the rest of the Fairblock team!

Fairomon is a special fairy type pokemon that combines the work of Fairblock and Monomer - a framework that enables builders to create Ethereum rollups with built-in encryption with minimal lift.

Background

Monomer is a rollup framework that enables Cosmos SDK app chains to be deployed as rollups on Ethereum. Internally, Monomer is built on top of the OP stack relying on it for chain derivation and settlement while supporting an ABCI interface for a Cosmos SDK app chain to be deployed on top. Fairblock provides threshold MPC encryption that can be utilized in Monomer rollups through a module built for Cosmos SDK chains.

Fairblock enables blockchain developers to integrate pre-execution encryption. This pre-execution encryption is made possible through their threshold MPC network that delivers identity-based encryption (IBE), and soon custom encryption schemes, to partner chains. Fairblock’s MPC network, called Fairyring, generates threshold encryption and decryption keys for each supported Monomer rollup, while the rollups themselves receive and process encrypted transactions natively.

How it Works

FairyRing uses decentralized key generation to issue a master secret key (MSK) for each epoch (every 100 blocks). From each MSK, a master public key (MPK) can be derived. Once the MPK is derived, it is relayed to a Monomer chain where it will be used to encrypt each requested transaction. In parallel, the MSK is split into equal shares for the amount of FairyRing validators participating in the network. For each request for decryption, FairyRing validators use their share of the MSK to collectively derive the associated private keys.

In threshold IBE, users or developers can program the decryption conditions for transactions. Onchain conditions that could trigger decryption could be a block height, the price of an asset, a smart contract call, verification of a ZK proof, or the end of a governance poll, for example. Identity-based encryption allows for the programmability of decryption and allows for decryption to be triggered by “IDs,” which can be either onchain conditions or on/offchain identifiers or attributes that certain wallets prove ownership of.

What’s Possible with Fairomon

MPC encryption can make a number of previously inaccessible applications possible within rollups, most notably encrypted mempools, censorship-resistant sequencing, and DeFi and gaming apps such as encrypted orders, leaderless NFT auctions, ID-gated content, and highest-hand-wins card games like blackjack.

The transaction flow for an application is as follows:

• User submits an encrypted tx and decryption condition (e.g. target height) to an app
• Chain receives encrypted txs in mempool
• Encrypted txs are sorted by target heights and ordering within a block is committed to inside of the integrated x/pep module
• When target height or decryption condition is reached, the app chain receives decryption key from the Fairyring chain
• Encrypted txs are decrypted and executed inside the BeginBlock method of the x/pep module

See the architecture diagram below for a detailed description of how Fairyring integrates with a Monomer appchain.

Monomer links:

• Github
• Docs

Fairblock links:

• Website

• Github

• Docs

1 post - 1 participant

Read full topic

Please pardon my ignorance. I’ve read several publications related to blockchain being used in healthcare, construction and the like. Many of these publications state that blockchain allows the storage of secured data.

My question is this: If data is “securely” stored on blockchain (I assume encrypted) and the encryption algorithm LATER (after long-term usage) is proven to be “cryptographically broken” (e.g., SHA-1) …

• does this not mean all “secured” data on the blockchain using that algorithm is suddenly public?
• are there steps that can be taken to re-encrypt the data to avoid the massive leak of data?

Kind regards.

7 posts - 4 participants

Read full topic

Does multi-block MEV exist? Analysis of 2 years of MEV Data

by Pascal Stichler (ephema labs)

Many thanks to Toni, Julian, Danning, Chris and Marc for feedback and especially to Barnabé for nudging the research in the first place and continuous feedback.

TL;DR

• We looked at proposer-builder data and MEV-Boost payment data since the merge (September 2022) to identify patterns of multi-block MEV.
• We observe fewer multi-slot sequences of builders than a random Monte Carlo simulation would predict. The longest observed multi-slot sequence is 25 slots.
• Average MEV-Boost payments increase for longer consecutive sequences by the same builder from ~0.05 ETH for single slots to ~0.08 ETH for nine consecutive slots.
• In longer sequences, the payment per slot increases slightly with later slots. This indicates that builders bid higher to get longer sequences or the first slot after a longer sequence.
• There is a weak positive autocorrelation between subsequent MEV-Boost payments. This contradicts the hypothesis that there are generally periods of low and high MEV.
• Comparing builders with periods of low and high base fee volatility shows a low correlation. This indicates that no builder specialization based on base fee volatility has developed yet.

The detailed results can be found in the Jupyter notebook on Github or Google Colab.

Background

Multi-block Maximal Extractable Value (MMEV) occurs when one party controls more than one consecutive block. It was first introduced in 2021 by [1] as k-MEV and further elaborated by [2]. It is commonly assumed that controlling multiple slots in a sequence allows to capture significantly more MEV than controlling them individually. This derives from MEV accruing superlinearly over time. The most discussed multi-block MEV strategies include TWAP oracle manipulation attacks on DEXes and producing forced liquidations by price manipulation.

After the merge, [3] have looked into the first four months of data on multi-block MEV and summarized it as “preliminary and non-conclusive results, indicating [that] builders employ super-linear bidding strategies to secure consecutive block space".

With the recent Attester-Proposer-Separation (APS) and pre-confirmation discussions, multi-block MEV has become more of a pressing issue again as it might be prohibitive for some of the proposed designs (For a more in-depth overview, we’ve created a diagram of recently proposed mechanism designs and also Mike Neuder lately gave a comprehensive overview).

Methodology

In order to get a better understanding of the historical prevalence of multi-block MEV, we decided to look at all slots from the Merge in September ‘22 until May ‘24 (totalling roughly 4.3 million slots) and analyze the corresponding data on validators and builders and on MEV-boost payments (if applicable). The scope was to identify patterns of unusual consecutive slot sequences and accompanying MEV values. The data has been kindly provided by Toni Wahrstätter and contains information per slot on relay, builder pubkey, proposer pubkey and MEV-Boost value as well as a builder pubkey and validator pubkey mapping. In the labeling of validators for our purposes staking pool providers such as Lido or Rocket Pool are treated as one entity.

MEV-Boost payments are used as a proxy for the MEV per block. We acknowledge that this is only a non-perfect approximation. The ascending MEV-Boost first-price auction by its nature of being public essentially functions like a second price + 1 wei auction (thanks to Julian for pointing this out!). Hence, we strictly speaking only get an estimate of the intrinsic value of the second highest bidder. However, as [4] have observed more than 88% of MEV-Boost auctions were competitive and [5] concluded that the average profit margin per top three builder is between 1% and 5.4%, further indicating a competitive market between the top builders. Based on this, despite the limitations we deem it feasible to use the MEV-Boost payments as an approximation for the generated MEV per block.

To establish a baseline of expected multi-slot sequences, a Monte Carlo simulation was conducted. In this simulation, builders were randomly assigned to each slot within the specified time period, based on their observed daily market share during that period. The frequency of consecutive slots, ranging in length from 1 to 25 (the longest observed sequence in the empirical data), was recorded. This procedure was repeated 100 times, and the average was taken. We decided to use daily market shares for the main analysis as in the investigated time period market shares have strongly shifted [4]. For comparison we also ran the analysis on monthly and overall market shares.

Further, base fee volatility data has been included to cross-check effects of low and high-volatility periods. Previous research (e.g. [6] & [7]) has focused on token price volatility effects based on CEX-prices. As we are interested in low- and high-MEV environments, we deem base fee volatility for our use case more fitting, as it is driven by empty or full blocks which are at least partially a result of the prevalence of MEV opportunities.

Empirical Findings

Finding 1: Fewer multi-slot sequences exist than assumed by random distribution

Figure 1: Comparison of statistically expected vs. observed multi-slot sequences (note that slots > 25 have been summarized in slot 25 for brevity)

Firstly, the prevalence of multi-slot sequences with the same builder proposing the block was investigated to determine if they are more common than would be expected by chance.

Comparing the results of the Monte Carlo simulation as a baseline in expected distribution (blue) with the observed distribution (orange), it can be seen that significantly fewer multi-slot sequences occur than expected (Figure 1). The longest observed sequence was 25 slots and the longest sequence with the same validator (Lido) and builder (BeaverBuild) was 11 consecutive slots on March 4th, 2024 (more details with descriptive statistics in the notebook). Running the same simulation on monthly or total market shares in the time period, the observation shifts to having more longer sequences than expected, however we attribute this to the statistical effect of changing market shares. A detailed analysis can be run in the notebook or be provided upon request.

In the next step, to understand this in a more-fine-grained manner, the values are compared for each of the top 10 builders based on market shares. Therefore, for each builder, the difference between expected and observed occurrences of multi-slot sequences are plotted with the size of the bubble indicating the delta in Figure 2. The expected occurrences are based on the results of the Monte Carlo simulation. Red bubbles indicate a positive deviation (more observed slots than expected), while blue indicates a negative deviation. Green dots indicate values in line with the expectation. In Figure 2 it is shown in absolute numbers, in the notebook it can also be seen on a relative scale.

Image 2: Deviations between expected (Monte Carlo simulation) and observed multi-slot frequencies per builder

It can be observed in the relative as well as in the absolute deviation that for the top builders there are more single slot sequences than expected with the exception of ETH-Builder, f1b and Blocknative. For multi-slot sequences with two or more slots, almost all top 10 builders have less than expected. This shows that the trend is not limited to singular entities but derives more from the general market structure.

Finding 2: Payments for multi-slot sequences are higher on average than for single slots

To understand if multi-slot sequences are valuable, we looked into MEV-Boost payments and compared single-slot to multi-slot sequences (Figure 3).

Figure 3: Average MEV-Boost payments per Sequence Length

It can be observed that in accordance with previous work of [3], we observe higher average MEV payouts for longer consecutive sequences (from about 0.05 ETH for single slot sequences to around 0.08 ETH for sequences with nine consecutive slots). Note that the gray numbers in Figure 3 provide the sample size for each slot length. So it can be observed that the longer the sequence, almost linearly the average MEV-boost payment per slot in the sequence rises. At this stage of the research we can only speculate why this is the case. It could be driven by a higher value in longer consecutive sequences, but also by alternative effects. For example, Julian rightfully pointed out it could also be driven by an increasing intrinsic value for the second highest-bidder due to accumulating MEV in private order flow and the intrinsic valuation of the winning bidder remains constant. Or as Danning suggested, it might be driven by certain types of proprietary order flow (e.g. CEX-DEX arbitrage) being more valuable in certain time periods (e.g. volatile periods) leading to more consecutive sequences as well as higher MEV-Boost payments on average. For a more comprehensive answer and a more in-depth understanding, an analysis on the true block value (builder profits plus proposer payments) and potentially on individual tx level is necessary. We leave this open for future research.

This trend also holds when plotting the average payments for each individual builder. The results on this are shown in the notebook.

Finding 3: Per Slot Payments also increase with longer sequences

Supplementary to the absolute average payment, we also looked into the payment per slot position in longer sequences (Figure 4). E.g. how much was on average paid for the third position in a longer sequence.

Figure 4: Average MEV-Boost payments per Sequence Position

Also in the payment per slot analysis a similar trend can be observed, however less prevalent. This suggests that there is slight value in longer sequences, however builders are not willing to bid significantly more for longer consecutive sequences or the first slot after a longer sequence.

This indicates for us that, at least so far, multi-slot strategies are not applied systematically. In this case, we expect builders would need to pay significantly higher values for later slots to ensure to capture the MEV opportunity prepared earlier.

Finding 4: Low auto-correlation between consecutive MEV-Boost payments

Figure 5: Auto-correlation of MEV-Boost Payments

We examined auto-correlation in the MEV boost payments to understand if historical MEV data allows us to forecast future MEV and to see if there are low- and high-MEV periods (Figure 5).

Overall, it can be observed that within the first few slots the correlation strongly decreases until an offset of 2 to 3 slots (we tested for Pearson Correlation Coefficient, Spearman’s Rank Correlation Coefficient and Kendall’s Rank Correlation Coefficient). Based on this we can conclude that not more than one to three slots in advance the MEV value can be moderately predicted based on historical data.

Further interesting observations can be made. As expected, the Spearman and Kendall correlation coefficients are significantly higher than the Pearson correlation coefficient, underlining that the data is not following a normal distribution but being skewed and having large outliers. Additionally, it is interesting to note that for the Pearson correlation coefficient, the complete data set and the top 50% quantile dataset behave similarly, which is not the case for the Spearman and Kendall coefficients. This might be an indicator that the rank ordering for the lower 50% quantile can be more reliably predicted, further underlying that high MEV values are volatile and spiky, hence difficult to predict.

Finding 5: No indication of builder specialization on low- or high base fee volatility environment

Previous research (e.g. [6] & [7]) has found that certain builders specialize in low- or high token price volatility environments, with volatility being measured on CEX-price changes. Further, [5] observe that different builders have different strategies with some focusing on high-value blocks while others on gaining market share in low-MEV blocks.

Complementary, to determine whether low or high base fee volatility impacts (multi-block) MEV, we analyzed changes in base fee data to identify periods of high volatility. The base fee fluctuations are driven by whether the gas usage in the previous block was below or above the gas target, as defined by EIP-1559. To identify high volatility environments, we employed two methods: (i) a more naive approach that calculated price changes per slot, classifying the highest and lowest (negative) 10% of these changes as high volatility periods, with the remaining 80 % of slots being categorized as low volatility. Consequently, high volatility blocks occur following a block with either minimal or significant MEV and/or priority tips. (ii) Secondly, the Garman-Klass volatility [8] was calculated on an epoch basis, with slots in the top 20% of GK values designated as high volatility. This approach allows us to examine longer periods characterized by minimal or significant MEV and/or priority tips.

Initial correlation analysis shows only a low correlation between low and high volatile periods and the respective builders (Cramér’s V for the naive approach 0.0664 and for the Garman-Klass 0.0772). This indicates that there seems to be no builder specialization based on the volatility environment of the base fee. So, it can be observed that in contrast to token price volatility for base price volatility there seems to not have a specialization of builders developed (yet). Further research is needed to elaborate on this first finding.

Limitations

The research presented here is intended as an initial exploratory analysis of the data rather than a comprehensive study. It is important to note several limitations that affect the scope and conclusions of this analysis. Firstly, it is limited by the considered data set being publicly available MEV-Boost payments data. This leaves out roughly 10 % of non-MEV-Boost facilitated blocks and it does not reflect potential private off-chain agreements. Additionally, the data was partially incomplete and in other parts contained duplicate information (see the notebook for details). Further, missed slots have been excluded so far, a more detailed analysis in the future might focus on the particular effects missed slots have on the subsequent MEV. Lastly, as outlined in the methodology section, using MEV-Boost payments is only a proxy for captured MEV and the competitive metric used in [4] is only partially applicable for our use case.

As outlined in section Finding 2 it currently can only be speculated about the causation of the increasing average MEV-Boost payouts. Furthermore, running the analysis on the true block value (proposer payment plus builder profits) might generate further insights and solidify the research findings.

On the frequency analysis, the approach contains somewhat a chicken and egg-problem. The Monte Carlo simulation is run on market shares, while the market shares potentially derive from multi-slot sequences. We see a daily time window as an appropriate balance between precision and the need to filter out isolated effects, although this can be critically challenged.

Conclusions

Analyzing block meta-data since the merge, we observe that multi-slot sequences occur less frequently than statistically expected. Further, we observe that the average payments for longer multi-slot sequences increase with the sequence length. Similarly, the payments per slot position in longer sequences also slightly rise. This might indicate that there is generally value in longer consecutive sequences. However, considering the only slight increase in value and the fewer observed multi-slot sequences than expected we so far see no indication of deliberate multi-slot MEV strategies being deployed. Also on individual builder level we currently don’t observe strong deviations from expected distributions. This may also stem from the fact that in the current PBS mechanism, with MEV-Boost operating as a just-in-time (JIT) block auction, creating multi-block MEV opportunities carries inherent risk. This risk arises as creating these opportunities typically requires an upfront investment, and the opportunity might be captured by a competing builder in the next slot, assuming no off-chain collusion between the proposer and builder. This element of risk is a critical factor that could be eliminated by some of the proposed changes to the mechanism (e.g. some APS designs), making it an essential consideration when defining future mechanisms.

References

[1] Babel K, Daian P, Kelkar M, Juels A. Clockwork finance: Automated analysis of economic security in smart contracts. In 2023 IEEE Symposium on Security and Privacy (SP) 2023 May 21 (pp. 2499-2516). IEEE.

[2] Mackinga T, Nadahalli T, Wattenhofer R. Twap oracle attacks: Easier done than said?. In 2022 IEEE International Conference on Blockchain and Cryptocurrency (ICBC) 2022 May 2 (pp. 1-8). IEEE.

[3] Jensen JR, von Wachter V, Ross O. Multi-block MEV. arXiv preprint arXiv:2303.04430. 2023 Mar 8.

[4] Yang S, Nayak K, Zhang F. Decentralization of Ethereum’s Builder Market. arXiv preprint arXiv:2405.01329. 2024 May 2.

[5] Öz B, Sui D, Thiery T, Matthes F. Who Wins Ethereum Block Building Auctions and Why?. arXiv preprint arXiv:2407.13931. 2024 Jul 18.

[6] Gupta T, Pai MM, Resnick M. The centralizing effects of private order flow on proposer-builder separation. arXiv preprint arXiv:2305.19150. 2023 May 30.

[7] Heimbach L, Pahari V, Schertenleib E. Non-atomic arbitrage in decentralized finance. arXiv preprint arXiv:2401.01622. 2024 Jan 3.

[8] Meilijson I. The Garman-Klass volatility estimator revisited. arXiv preprint arXiv:0807.3492. 2008 Jul 22.

4 posts - 2 participants

Read full topic

Thanks to Francesco D’Amato, Barnabé Monnot, Mike Neuder, and Thomas Thiery for feedback and review. Thanks again to Francesco for coming up with the second proposal.

Whether we want to implement slot auctions into ePBS is an active discussion area, and support for slot auctions was signaled in the seventh ePBS breakout call. Currently, the ecosystem lacks knowledge about the fork choice safety of slot auctions in the current ePBS proposal. This note presents two strawman proposals to start discussing the forkchoice safety of slot auction ePBS.

This note presupposes the reader is familiar with the ePBS proposal (EIP-7732). An essential part of this EIP is that a payload boost is applied to a beacon block if the Payload-timeliness committee (PTC) reaches a quorum. If an execution payload is seen on time by a majority of the PTC, the beacon block that corresponds to the execution payload receives additional fork-choice weight (Reveal Boost). If the PTC observes a timely message from the builder stating that it withholds its payload, the additional fork-choice weight is given to the parent block of the beacon block corresponding with the withhold message (Withholding Boost).

In slot auction ePBS, the beacon proposer does not commit to an execution payload hash, unlike in block auction ePBS. Instead, it commits to a specific builder that can submit an execution payload when it is time to reveal. The first problem is that a builder could submit multiple execution payloads. In this note, we will refer to this as a builder equivocation.

In block auction ePBS, something similar to equivocation is possible. The builder could wait for at least one PTC member to vote PAYLOAD_ABSENT and then release a withhold message and an execution payload to split the PTC’s view such that none of the three vote options (PAYLOAD_ABSENT, PAYLOAD_WITHHELD, PAYLOAD_PRESENT) reaches the quorum of 50% of the votes.

In block auction ePBS, this equivocation does not benefit the builder much. If the PTC does not reach a quorum, no payload boost is applied, and the honest next-slot validator will take the payload as head. If the builder equivocates, the protocol does not need to guarantee Builder Reveal Safety since the builder does not act as the protocol expects. Still, the builder does not have the flexibility to submit a different execution payload since the beacon block commits to the execution payload hash.

It could be that the builder is incentivized to play a timing game and eventually decides that it is best if the block were withheld. The builder could submit a withhold message and see if the PTC will reach a quorum on PAYLOAD_WITHHELD. If the PTC does not seem to do so, and the PTC also has not yet reached a quorum on PAYLOAD_ABSENT, the builder reveals its payload after all. This attack seems difficult to pull off, but it allows the builder to check whether it can renege on its promised payment to the proposer while still landing its payload on-chain if it has to pay (assuming an honest next-slot proposer).

In slot auction ePBS, a builder may be more incentivized to equivocate because it can change the contents of its execution payload. For example, the builder could broadcast a particular execution payload, but a short time later, a significant MEV opportunity appears, and the builder now wants to broadcast a new execution payload.

Preventing equivocations in slot auction ePBS would be desirable because equivocations would cause insecurity in fork choice. Specifically, we want to obtain the following properties with minimal changes.

Desiderata

1. If the builder reveals precisely one timely execution payload, it should retain the same Builder Reveal Safety guarantees as in block auction ePBS
2. If the builder reveals multiple timely and equivocating execution payloads,
   a. no execution payload should go on-chain,
   b. but the Unconditional Payment should be as strong as in block auction ePBS

Should slashing or a penalty be applied to equivocating execution payload messages? This question is relevant to block and slot auction ePBS, although the potential benefits of equivocation are likely to be higher in slot auction ePBS. Since ePBS still allows local block construction, it seems unwise to apply harsh slashing or penalties if there is equivocation because this may disincentivize local block construction. Moreover, since it is not clear that there are significant gains to be made from equivocating execution payloads, and if gains are to be made, slashing or penalties do not qualitatively change this, so slashing or penalties are not immediately necessary.

Proposal 1: Vote for Execution Payload Hash

The first strawman proposal to obtain these properties involves changing the block auction ePBS fork-choice specification as follows.

Proposal 1: Vote for Execution Payload Hash

1. Replace PAYLOAD_PRESENT with execution_payload_hash
2. If no PTC quorum is reached, let the honest next-slot validator use an empty block as its head instead of a full block.

A PTC member would now vote for the execution_payload_hash it has observed instead of simply voting whether a payload is present. Reveal boost is applied if a quorum is reached on execution_payload_hash. Intuitively, this is necessary for slot auctions since the PTC now indicates which execution payload should be used if the block is full and not just that the block is full.

It seems like desideratum 1—the same Builder Reveal Safety as in block auction ePBS—is immediately satisfied since an honest builder does not release equivocating execution payloads. A PTC member’s execution_payload_hash vote functions the same as a PAYLOAD_PRESENT vote.

If the builder equivocates but the PTC still reaches a quorum on execution_payload_hash, then the execution payload will make it on-chain in the same way a payload would have made it on-chain if the builder did not equivocate. I believe this is fine because the builder released an equivocating payload that did not split the view of the PTC (sufficiently). This indicates that this equivocating payload is a minor threat to the fork-choice security. Although this outcome contradicts desideratum 2a, the timely requirement in desideratum 2 should be read as the execution payload intends to split the view of the PTC sufficiently.

If the builder equivocates and the PTC does not reach a quorum, then the next-slot honest proposer should see an empty block as its head. The builder loses some of its Builder Reveal Safety because it could be that the builder reveals only one payload (does not equivocate), yet the PTC does not reach a quorum. However, Builder Reveal Safety is not very strong in block auction ePBS either because a next-slot rational proposer would prefer to build on an empty block than a full block since these are more valuable (the ex-post reorg safety is low if reveal boost is not applied). Changing the default next-slot honest proposer behavior from seeing a full block to an empty block as its head does not change much in Builder Reveal Safety, and the system then satisfies desideratum 2.

What if the next-slot proposer is dishonest? The builder could collude with the next-slot proposer and broadcast messages such that the PTC does not reach a quorum and include an execution payload late. This is similar to the attack in block auction ePBS, where a builder tries to get Withhold Boost to apply but releases an execution payload if it does not succeed. The builder and next-slot proposer collusion allows the builder to play aggressive timing games while ensuring Builder Reveal Safety. These timing games come at the expense of the execution validation time of the attesting committee. It is not immediately apparent what this attack would gain for the builder and next-slot proposer collusion since the builder timing game gain comes almost entirely from the next-slot proposer’s revenues.

The downside of this proposal is the problem of free data availability. The PTC could now reach a quorum on an execution_payload_hash. These PTC votes would end up on-chain, and an adversary could use them to show that a piece of data was available to the PTC. Yet the adversary would not have to pay the base fee needed to provide the data on-chain; it only has to pay the proposer to commit to the adversary as the builder.

Proposal 2: Pretend Payload Absent

The second strawman proposal does not suffer from the free data availability problem and achieves the desiderata as follows.

Proposal 2: Pretend Payload Absent
If the next-slot proposer/attesters observe(s) at least two equivocating payloads, it/they assign(s) no additional fork-choice weight to any empty or full block

The behavior of a PTC member does not change from the block auction ePBS specification. However, suppose a proposer sees that the block producer in the previous slot released equivocating execution payloads. In that case, it ignores the fork-choice weight the PTC may have given to any fork.

If the builder is honest, this does not change its Builder Reveal Safety since the system works exactly as it does in block auction ePBS. Desideratum 1 is thus immediately satisfied.

If the builder equivocates, an honest-but-rational proposer will choose to build on an empty block since it allows the proposer to extract the MEV from two slots of time instead of one. The attesters will not object to this since they observed the equivocating payloads and assigned no additional fork-choice weight to any forks. Therefore, if the next-slot proposer and attesters are honest, desideratum 2 is also satisfied.

The next-slot proposer could collude with the builder. The builder could equivocate, and the next-slot proposer could choose to build on a full block. Similarly to the collusion situation described in the first proposal, though, the gain that a builder gets from this equivocation seems to primarily come from the profits the next-slot proposer could make. It is not clear that the joint utility of the collusion increases by enough to justify the collusion.

A builder and a next-slot proposer could collude to ensure an execution payload does not become canonical. Consider a builder that submits an execution payload, and the PTC reaches a quorum on whether this payload is timely. Later, the builder regrets the contents of its execution payload and aims to remove it from the canonical chain. It could then release an equivocation payload so the next-slot proposer will not build on the undesirable execution payload. This is similar to a builder not revealing its block in block auction ePBS.

In conclusion, these strawman proposals seem to achieve the same fork-choice safety under slot auctions as under block auctions with minimal changes. While the first proposal has a problem with free data availability, the second proposal may be more susceptible to builder games, such as reorging its execution payload. The lack of free data availability and being less susceptible to builder games are advantages of slot auctions in ePBS. Further research on a design that simultaneously solves both problems would be very valuable. If you are interested in working on (slot auctions in) ePBS, please see this page!

6 posts - 3 participants

Read full topic

A two-tier auction market: the right resembles the less sophisticated publicly observable P2P market, and the left resembles the more sophisticated private RPC market.

Thanks to Potuz, Barnabé Monnot, Terence Tsao, and Thomas Thiery for comments and discussion.

The current ePBS proposal, EIP-7732, suggests operating a two-tier market where builders can bid to obtain the execution payload construction rights. Large block builders are expected to use the pull-based direct connection market. This market allows for lower latency and more flexibility for the builder, as the builder only needs to commit to its bid once the proposer asks for it. This market, however, requires the proposer to connect to the builder’s RPC and actively pull bid(s) from it. Smaller builders who lack this connectivity with the validator set can use the push-based P2P market. This market has stricter rules for what bidders can do but does not need the proposer to pull bid(s) from it since bids are pushed to the proposer.

This note explores the role of the P2P market in ePBS. Although there has been some initial exploration on the topic, this note presents a clear counterfactual of a world where the P2P market were not included in EIP-7732. This note also emphasizes multiplexing—the ability of proposers to discover builders—as the most important aspect of the P2P market.

The three arguments in favor of the P2P market that the author has seen in previous work are: 1) it allows anyone to set a floor price for the auction, 2) it can be used for MEV-Burn in future protocol upgrades, and 3) it lowers entry barriers for new entrants or long-tail builders.

The first argument is that allowing anyone to bid via the publicly observable P2P market gives all validators the ability to set a floor price for the auction. Validators can bid based on the block that they could locally build. Builders must then bid at least above the bid of these validators to obtain the execution payload construction rights. It has been argued that this is valuable if a cartel of builders intends to keep bids low. The floor price, however, would not break up a cartel. Although proposers would make slightly more revenue in this case, it is unclear what the value of such a floor price is to the protocol.

The beacon proposer selling the rights may be the ideal party to set a reserve price. As I argue in this post, a proposer may want to put a higher reserve price than its valuation for the execution payload construction rights to attract higher bids from builders. The P2P market allows the proposer to signal its reserve price to the market. In this sense, the P2P market allows the validator and other participants to express their preferences.

The second argument states that the P2P market may facilitate MEV-Burn in future protocol upgrades. MEV-Burn aims to decouple the rewards from selling execution payload construction rights from being a validator. This has numerous benefits; for example, it decreases the value of using a staking service provider (SSP) since MEV-Burn decreases the variance of validator payoffs. MEV-Burn requires that builder bids be legible to the protocol. Most designs achieve this by having a committee that observes the best available bids. If ePBS would only have the direct connection market, the MEV-Burn designs need to be revisited since a proposer selling the execution rights is incentivized to understate the amount that will be burnt. Still, the P2P market is expected to only reflect a small portion of the value of the execution payload construction rights, hence even ePBS with the P2P market may not be satisfactory for an effective MEV-Burn solution.

The last reason for the P2P market is that it would allow builders from which proposers are unlikely to pull bids to still compete in the market. Proposers may be unlikely to pull bids from builders that infrequently participate in the auction because they are very specialized or from new builders unknown to the proposer. This could be because proposers have an outdated whitelist of builders from which to pull bids. Allowing these proposers to participate in the push-based P2P market will result in more builder diversity in block construction, which may benefit the protocol.

This last reason is what we will explore in this post. Specifically, what does the Ethereum ecosystem gain by enshrining the push-based P2P market aside from an out-of-protocol solution that facilitates small builders’ participation in the market?

Shea Ketsdever recently released a post on TEE-Boost, an adaptation of MEV-Boost that uses Trusted Execution Environments. In this post, she highlights the different roles a relay plays. One of the roles is multiplexing, allowing proposers to discover builders who may want to participate in the auction.

The ePBS P2P market aims to achieve multiplexing. In the context of ePBS, multiplexing has at least two facets: trustlessness and value reflection. Trustlessness is important because ePBS removes the trust that proposers and builders must place in a relay to facilitate the fair exchange. Value reflection is essential because a multiplexing tool that poorly reflects the value bidders assign to the auctioned item will not efficiently match an auctioneer with the correct bidder.

The ePBS P2P market scores very well on the trustlessness front. Neither a proposer nor a builder must trust anyone since bids are broadcast via the P2P network, and the winning bid is committed to on-chain. The P2P market, however, scores poorly on the value reflection front. Since the P2P network must be DOS resistant, it cannot handle too many bids, so bidders will likely not be allowed to bid as often as they could in MEV-Boost, meaning they have to be strategic about when they bid. Moreover, early bids will not be able to be canceled, which could lead to strategic builders only winning via the P2P market if the valuation of other builders that operate via the direct connection market has decreased (adverse selection). Finally, the value reflection of the P2P market relative to the RPC market will worsen as the RPC market becomes more sophisticated while the P2P market becomes stale.

How would an out-of-protocol actor facilitate multiplexing if ePBS were deployed? In MEV-Boost, relays facilitate multiplexing because submitting blocks to relays is (largely) permissionless, and relays are well-connected to validators. In ePBS, a relay - from no one referred to as a bid curation relay - would look different. A bid curation relay could open an RPC endpoint that proposers connect to and host an auction where builders submit bids, like in MEV-Boost. Bids, however, do not need to contain transaction data since the bid curation relay would not be responsible for the fair exchange problem that is solved via ePBS. Bids in ePBS are a bid value and the hash of the execution payload. A proposer then pulls the highest bid from the bid curation relay and, if it so desires, commits to the highest bid via the in-protocol ePBS system. A winning builder then sees this in-protocol commitment and publishes the block via ePBS.

It becomes clear that the trust assumptions that proposers and builders must place in a bid curation relay are vastly lower than in MEV-Boost. Essentially, the proposer and builders must trust the bid curation relay to forward the highest-paying bid when the proposer asks for it. The bid curation relay is not trusted with the block contents (builder privacy is preserved) and is not responsible for unconditional payment (data availability and validation are enforced via the protocol).

The ePBS relay scores worse on the trustlessness front than the P2P market since the proposer and builders must trust the relay not to censor its bids. On the other hand, the value reflection of such a bid curation relay could be far better. The relay could offer bid cancellations and high-frequency bidding to builders. Moreover, relays could invest in latency reductions and charge for this, as some do in MEV-boost. If a relay successfully reduces latency, more prominent builders may connect to it. This means the value reflection of relays relative to directly connected builders may remain stable or improve over time.

Shea also highlights another option that has been discussed widely before: next to the P2P market; there could be an on-chain registry of builders. There could be a smart contract that any builder could write its RPC endpoint to. Any validator could then see the available RPC endpoints and pull bids from it during its slot. This alternative scores well on the trustlessness front since no trust is required, and it scores well on the value reflection point since it allows all builders to compete on a similar level. The proposer could pull from this registry every time it is supposed to propose a block.

Why do we care about multiplexing? Multiplexing contributes to the credible neutrality of the network. In the context of ePBS, credible neutrality may mean something like this: the builder with the highest valuation for the execution payload construction rights is allocated these rights. If proposers were to rely solely on directly connected builders, some long-tail builders who happened to have an exceptionally high value for a specific block might be excluded. If proposers rely on bid curation relays, they may not forward the highest-paying bid because they prefer to forward another bid for whatever reason. If proposers rely on an on-chain registry of builders, it may not connect to the newer or smaller builders.

Allowing multiplexing to contribute to credible neutrality is a trade-off between trustlessness and value reflection. If a completely trustless market is so poor at value reflection that it never surfaces a winning bid, it does not contribute much to credible neutrality. If a perfectly value-reflecting market puts a lot of trust in one party, the benefit of credible neutrality is also nonexistent.

To conclude, the P2P market is easy to implement, and its maintenance does not require a hard fork so clients can iterate freely. Although the P2P market only contributes a little to the core functionality of ePBS, there are virtually no downsides to implementing it, and it is a nice feature that may benefit some users and could be beneficial for proposers as it increases their revenues and may be helpful for MEV-Burn in the future. Further work could specify the P2P market rules and how an on-chain registry of builder RPC endpoints could work.

1 post - 1 participant

Read full topic

Storage collisions and vulnerabilities within Ethereum smart contracts can lead to unexpected issues like freezing funds, escalating privileges, and financial asset theft. A storage collision occurs when two different storage structs unintentionally use same storage slot(s), or the slot layout is changed during the upgrade of implementation contract. These collision vulnerabilities have been detected in large numbers (worth millions of dollars) in a recent study within smart contracts deployed on the Ethereum network.

In this topic, we propose a more accurate and complete technique to detect storage vulnerabilities and collisions in Solidity smart contracts. And encourage the Ethereum community to provide feedback on the proposed technique.

Introduction

We are working on a solution based on advanced static analysis techniques that can identify vulnerabilities within the deep storage of Ethereum Solidity smart contracts. We aim to detect storage collisions in proxy contracts deployed on the Ethereum network like ERC-2535 (Diamond/Multi-Facet Proxy), ERC-1822, upgrade proxy pattern, etc., as complex proxy contracts are more likely to experience a storage collision, like during the upgrade of implementation or facet contracts.

N. Ruaro et al. analyzed Ethereum contracts using contract bytecode to detect storage collisions and reported 14,891 vulnerable contracts. Their technique was able to identify storage slot types correctly with an accuracy of 87.3%. Whereas, we aim to build a solution that will use source code to accurately analyze the storage layout and slot types of the contract. Furthermore, we will also analyze dynamic arrays, mapping variables, and complex nested structs in our analysis.

Suppose a collision occurs on the state variables’ base slots, our approach will allow us to identify the impact of the collision on dynamic arrays and mapping variables declared consecutively, and arrays data type or mappings key types are same which is a common practice in large contracts like gaming contracts.

As shown in the below example code, the slot layout was changed during the contract upgrade, and since token_uris and token_version have same key types and data types, both variables will return each other’s data after the upgrade due to collision.

library ImplementationStorage1 {
    struct AddressSlot {
        address owner; // slot n+0
        mapping(uint256 => string) token_uris; // slot n+1
        mapping(uint256 => string) token_versions; // slot n+2
    }

    function getAddressSlot(bytes32 slot) internal pure returns (AddressSlot storage r) {
        assembly {
            r.slot := slot
        }
    }
}

// updated code
library ImplementationStorage2 {
    struct AddressSlot {
        address owner; //slot n+0
        mapping(uint256 => string) token_versions; // slot n+1 (shld be token_uris)
        mapping(uint256 => string) token_uris; // slot n+2 (shld be token_versions)
    }

    function getAddressSlot(bytes32 slot) internal pure returns (AddressSlot storage r) {
        assembly {
            r.slot := slot
        }
    }
}

token_uris accessing token_versions and vice-versa after the upgrade.

       (before upgrade)                        (after upgrade)   
      _________________                      _________________
     |     Proxy       |                     |     Proxy       |
     |_________________|                     |_________________|
     | * IMPLEMENT_SLOT| --> NFTManager1     | * IMPLEMENT_SLOT| --> NFTManager2
     | * ADMIN_SLOT    |                     | * ADMIN_SLOT    |
     |_________________|                     |_________________|
     | + upgradeTo()   |                     | + upgradeTo()   |
     | + changeAdmin() |                     | + changeAdmin() |
     |_________________|                     |_________________|
              |                                       |
              v                                       v
      _________________                       _________________
     |   NFTManager1   |                     |   NFTManager2   |
     |_________________|                     |_________________|
     | - owner         |                     | - owner         |
     | - token_uris    | **** collision **** | - token_versions|
     | - token_versions| **** collision **** | - token_uris    |
     |_________________|                     |_________________|

We plan to build a technology that will automatically detect all storage collisions within a Solidity smart contract.

Methodology

We have structured our development plan into three distinct phases, outlined as follows:

• Automatic State Variable Detector and Slot Layout Calculator

In this phase, we focus on developing an automatic state variable detector and slot layout calculator. This component will facilitate the identification of state variables within smart contracts and determine their corresponding slot layout. By automating this process, we aim to streamline the initial analysis procedures.

Sample output of Slot Calculator

slot 0 - mapping ds.selectorToFacetAndPosition[bytes4] = FacetAddressAndPosition;
slot 1 - mapping ds.facetFunctionSelectors[address] = FacetFunctionSelectors;
slot 2 - address [] ds.facetAddresses;
slot 3 - mapping ds.supportedInterfaces[bytes4] = bool;
slot 4 - address ds.contractOwner;
slot 5 - mapping ds.tempSelectorsNested[uint256] = FacetAddressAndPosition;
slot 6 - FacetAddressAndPosition [] ds.FacetAddressAndPositionArray;
slot 7 - mapping ds.tempMapping[uint256] = uint256;
slot 8 - mapping ds.tempMapping2[address] = uint256;

• Mapping Keys Analyzer and Slot Calculator of Complex Variables

Building upon the foundation established in phase 1, in this phase we will first extend the slot calculator capability to calculate the slots of complex variables and their entries (for all data types) i.e. slots of mapping keys, dynamic array, complex struct, mappings with complex struct as value.

This component will also include the approximation of all keys used in mapping variables for saving data using advanced static analysis techniques. By accurately approximating keys and calculating entries, we seek to enhance the precision and breadth of storage slot calculation methodology, which will help detect storage collision within deep storage data of a smart contract.

• Collision Detector for State Variables and Complex Variables All Entries Slots

The final phase of our methodology focuses on implementing a collision detector for both state variables and complex variable slots. This critical component will identify any potential collisions or conflicts within any type of state variables and their associated variable(s)/value(s) slots. By detecting and addressing collisions, we aim to ensure the integrity and reliability of smart contracts.

We aim to develop a robust and comprehensive methodology for smart contract storage collision detectors, by systematically progressing through above discussed three development phases.

Conclusion

The development of our solution will allow developers to ensure that their contract has no potential storage collisions before deployment. It will also be able to detect storage collisions within deep storage of deployed smart contracts and can help in securing contracts worth millions of dollars.

1 post - 1 participant

Read full topic

Mechan-stein (alt. Franken-ism)

^ choose your own adventure – either way, just trying to portmanteau ‘Frankenstein’ and ‘Mechanism.’

_{^“don’t worry bro, just one more auction, i swear. check it out.” h/t Mallesh for the relevant tweet.}

\cdot
by mike – wednesday; august 21, 2024.
_{^hbd Bo. if you, dear reader, haven’t seen “Inside” or “Inside Outtakes,” watching them is your homework assignment.}
\cdot
Many thanks to Barnabé, Julian, Thomas, Jacob, mteam, Toni, Justin, Vitalik, Max, and Mallesh for discussions around these topics and comments on the draft!
\cdot
The idea for the combined mechanism explored in Part 2 of this post came from a Baranbé-led whiteboarding session and accompanying tweet thread. These ideas are also explored in the this doc, which inspired this talk.
\cdot
tl;dr; We sketch a high-level framing for Ethereum block construction centered around the design goals of encouraging builder competition, limiting the value of validator sophistication, and preserving the neutrality of block space. We then highlight three proposed mechanisms and how they interface with the established desiderata. We conclude by exploring the potential synergies of combining these designs into a single flow, called Mechan-stein.
\cdot
Contents
(1) The building blocks of block-space market design
   Enshrined PBS & MEV-burn via PTC
   Execution Auctions (an Attester-Proposer Separation instantiation)
   FOCIL
(2) Mechan-stein
   Potenital Issues with Mechan-stein
\cdot

Related work

---

[1] The building blocks (pun intended) of block-space market design

Since before the Merge, much has been (and continues to be) written about Ethereum’s transaction supply chain and block-space market design. I still think Vitalik’s Endgame summarizes the best-case outcome most succinctly with,

“Block production is centralized, block validation is trustless and highly decentralized, and censorship is still prevented.”

We can operationalize each of these statements into a design goal for our system:

1. “Block production is centralized.” \rightarrow MEV is a fact of life in financial systems, and some actors will inevitably specialize in its extraction. We can’t expect solo-stakers to run profitable builders, but we can encourage competition and transparency in the MEV markets. When discussing MEV-boost, we usually describe it as aiming to democratize access to MEV for all proposers (which it does extremely well), but one under-discussed element of the existing system is that it encourages builder competition by creating a transparent market for buying block space. There are (and always will be) advantages and economies of scale for being a big builder (e.g., colocation with relays, acquiring exclusive order flow deals, and holding large inventory on various trading venues – for more, see this recent paper from Burak, Danning, Thomas, and Florian), but anyone can send blocks and compete in the auction. Another important element of MEV-boost is that the auction happens Just-In-Time (JIT) for the block proposal, making timing games around the block proposal deadline valuable to the proposer who serves as the auctioneer. Still, the real-time nature of the auction ensures that the builder with the highest value for this specific slot wins the auction (rather than, e.g., the builder with the highest average value for any slot – see Max & Mallesh’s argument for why ahead-of-time auctions are more centralized). This leads to design goal #1: encourage builder competition.^{[1]}
2. “Block validation is trustless and highly decentralized”^{[2]} \rightarrow Ethereum’s primary focus has been preserving the validator set’s decentralization (why this is important in item #3 below). This fundamental tenet instantiates itself in both the engineering/technical design and the economic/incentive design. On the engineering front, the spec is written with the minimum hardware requirements in mind. This constraint ensures that participation in Ethereum’s consensus is feasible given (relatively) modest resources. On the economic level, the goal is to minimize the disparity in financial outcomes between at-home stakers and professional operators. Beyond feasibility, this aims to make at-home staking not too irrational. This double negative is tongue-in-cheek but hopefully conveys the message of trying to ensure there is some economic viability to at-home staking rather than staking through a centralized provider. Another lens for interpreting this is keeping the marginal value of sophistication low. We can’t expect at-home operators to have the exact same rewards as Coinbase and Lido (e.g., because they may have higher network latency), but the centralized staking providers shouldn’t benefit greatly from sophistication. This leads to design goal #2: limit the value of validator sophistication.
3. “Censorship is prevented.” \rightarrow Credible neutrality is what differentiates crypto-economic systems from FinTech. If centralized entities determine which transactions land on chain and which do not, it’s over. To ensure the anti-fragility and neutrality of Ethereum, we must rely on a geographically distributed validators; the validator set is the most decentralized part of the block production pipeline. In my opinion, (i) the main point of having a decentralized validator set is to allow those validators to express different preferences over the transactions that land on chain (“high preference entropy” – h/t Dr. Monnot), and (ii) relying on this decentralization is the only way to preserve neutrality of the chain (c.f., Uncrowdable Inclusion Lists for more discussion on chain neutrality). This leads to design goal #3: preserve the neutrality of Ethereum block space.

Right. To summarize:

1. “Block production is centralized.” \rightarrow design goal #1: encourage builder competition.
2. “Block validation is trustless and highly decentralized” \rightarrow design goal #2: limit the value of validator sophistication.
3. “Censorship is prevented.” \rightarrow design goal #3: preserve the neutrality of Ethereum block space.

Ok. This is all great, but let’s talk specifics. Many proposals aim to accomplish some of the design goals above. I am going to focus on three:

1. Enshrined Proposer-Builder Separation & MEV-burn via Payload-Timeliness Committee (abbr. PTC onwards).
2. Execution Auctions/Attester-Proposer Separation.
3. Fork-Choice Enforced Inclusion Lists (abbr. FOCIL onwards).

This may seem jargon-laden, and I apologize; please check out the links for the canonical article on each topic; for even more legibility, I will present a high-level view of each proposal below.

Enshrined PBS & MEV-burn via PTC

This design enshrines a JIT block auction into the Ethereum consensus layer. The diagram below summarizes the block production pipeline during the slot.

1. The builder bids in the auction by sending (block header, bid value) pairs to the proposer and the committee members.
2. The proposer commits to the highest bid value by signing and publishing the winning bid.
3. The committee enforces that the proposer selected a sufficiently high bid according to their view.
4. The builder publishes the block.
5. The committee enforces the timeliness of the builder’s publication.

Analysis

• PTC allows the protocol (through the enforcement of the committee) to serve as the trusted third-party in the fair-exchange of the sale of the block building rights. MEV-burn (maybe more aptly denoted as “block maximization” because burning isn’t strictly necessary for the bids) asks the attesters to enforce a threshold for the bid selected as the winner by the proposer.
• PTC primarily implements design goal #1: encourage builder competition. PTC enshrines MEV-boost, fully leaning into creating a competitive marketplace for block building. As in MEV-boost, the real-time block auction allows any builder to submit bids and encourages competition during each slot. Additionally, the JIT auction and bid-threshold enforcement of MEV-burn reduces the risk of multi-slot MEV by forcing each auction to take place during the slot. Lastly, PTC and other ePBS designs historically were aimed at removing relays. With bid thresholds from MEV-burn, the bypassability of the protocol becomes less feasible (even if the best builder bypasses, the second best can go through the protocol and ensure their bid wins).
• PTC marginally addresses design goal #2: limit the value of validator sophistication. By creating an explicit market for MEV-aware blocks, PTC ensures that all validators can access a large portion of the MEV available in their slot. MEV-burn also smooths out the variance in the validator rewards. However, one of the major limitations of this auction design is the “value-in-flight” (h/t Barnabé for coining the term) problem of the auction taking place during the slot. Because the value of the sold item changes dramatically throughout a slot, the auctioneer’s role benefits from sophistication. Beyond simple timing games, more exotic strategies around the fork-choice rule (e.g., using extra fork-choice weight to further delay block publication, h/t Toni) are possible, and we are just starting to see these play out.
• PTC does not address design goal #3: Preserve the neutrality of Ethereum block space. Neither PTC nor PBS generally are designed to encourage censorship resistance. The fact that a few builders account for most of Ethereum’s blocks is not surprising, and we should not count on those builders to uphold the credible neutrality of the chain (even if they are right now). While it is true that PTC aims to maintain a decentralized validator set, the fact that the full block is sold counter-acts that effect by still giving discretionary power of the excluded transactions to the builder (e.g., consider the hypothetical where 100% of validators are at-home stakers (maximally decentralized), but they all outsource to the same builder \implies the builder fully determines the transactions that land onchain).

Execution Auctions (an Attester-Proposer Separation Instatiation)

In contrast to the JIT block auction enabled by PTC, this design enshrines an ahead-of-time slot auction into the Ethereum consensus layer. A slot auction still allocates the entire block to the winner of the auction, but they no longer need to commit to the specific contents of the block when bidding (e.g., they are buying future block space) – this allows the auction to take place well in advance of the slot itself. The diagram below summarizes the block production pipeline 32 slots ahead of time (the 32 is just an arbitrary number; you could run the auction any time in advance or even during the slot itself; the key distinction is the fact that the bids don’t contain commitments to the contents of the block).

N.B., the first three steps are nearly identical to the PTC process. The only differences are (a) the auction for the Slot N+32 block production rights takes place during Slot N and (b) the bid object is a single bid value rather than the (block header, bid value) tuples. The actual building and publication of the block happen during Slot N+32, and Execution Auctions are agnostic to that process.

1. The builder bids in the auction by sending bid value to the proposer and the committee members.
2. The proposer commits to the highest bid value by signing and publishing the winning bid.
3. The committee enforces that the proposer selected a sufficiently high bid according to their view.

Analysis

• Execution Auctions allow the protocol (through the enforcement of the committee) to serve as the trusted third party in the fair-exchange of the sale of the block building rights for a future slot.
• Execution Auctions primarily support design goal #2: limit the value of validator sophistication. With the real-time auction of PTC, we described how the value-in-flight problem results in value from the sophistication of the validators who conduct the auction. In Execution Auctions, the auction occurs apriori, making the value of the object sold less volatile. The validator conducting the auction has a much simpler role that doesn’t benefit from timing games in the way they do in the JIT auction, thereby reducing their value from sophistication.
• Execution Auctions do not address design goal #1: encourage builder competition. By running the auction ahead of time, the highest value bidder will always be the builder who is best at producing blocks (h/t Max and Mallesh for formalizing this). The builder may still choose to sell the block production rights on the secondary market, but only at a premium over the amount they can extract.^{[3]}
• Execution Auctions do not address design goal #3: Preserve the neutrality of Ethereum block space. Execution Auctions are not designed to encourage censorship resistance. We fully expect the future block space and builder markets to remain centralized. Another major concern with Execution Auctions is the risk of multi-slot MEV. Because the auction is not real-time, it is possible to acquire multiple consecutive future slots and launch multi-slot MEV strategies without competing in any auction during the slot itself. (We could try to mitigate this by making the look-ahead only a single slot – e.g., Slot N+1 auction during Slot N, but this may open up the same value-in-flight issues around JIT block auctions. More research is needed (and actively being done h/t Julian) here.)

FOCIL

This design allows multiple consensus participants to construct lists of transactions that must be included in a given slot. In contrast to the previous designs, this is not an auction and does not aim to enshrine a MEV marketplace into the protocol. Instead, the focus here is improving the system’s neutrality by allowing multiple parties to co-create a template (in the form of a set of constraints) for the produced block. The diagram below describes the block production process during the slot itself.

1. The IL committee publishes their inclusion lists to the builder (clumping this together with the proposer for this diagram because the builder must follow the block template) and the attesters.
2. The builder publishes a block that includes an aggregate view of the ILs they received and conforms to the constraints therein.
3. The attesters enforce the block validity conditions, which now check that the builder included a sufficient threshold of observed inclusion lists.

Analysis

• FOCIL increases the protocol’s neutrality by allowing multiple validators to express their preferences in the block co-creation.
• FOCIL primarily contributes to design goal #3: preserve the neutrality of Ethereum blockspace. This is the direct goal; more inputs to the block construction seems like a no-brainer (very much in line with the latest thread of concurrent proposer research). Critically, FOCIL intentionally does not give any MEV power to the inclusion list constructors (see Uncrowdability for more) to avoid the economic capture of that role. In particular, FOCIL does not aim to constrain the builder’s ability to extract MEV generally; the builder can still reorder and insert transactions at will in their block production process. Instead, it’s their ability to arbitrarily exclude transactions, which FOCIL reduces.
• FOCIL does not address design goal #1: encourage builder competition. FOCIL is agnostic to the exact block production process beyond enforcing a block template for transactions that cannot be excluded arbitrarily.
• FOCIL does not address design goal #2: limit the value of validator sophistication. FOCIL is agnostic to the exact block production process beyond enforcing a block template for transactions that cannot be excluded arbitrarily.

Right. That was the “vegetable eating” portion of this article. The critical takeaway is each of the above proposals primarily addresses one of the cited design goals, but none address all three simultaneously. This makes it easy to point out flaws in any specific design.
…
You probably see where we are going with this. Let’s not bury the lede. What if we combine them? Each serves a specific role and operates on a different portion of the slot duration; why not play it out?

[2] Mechan-stein

With the groundwork laid, we can ~nearly~ combine the three mechanisms directly. There is one issue, however, which arises from both auctions selling the same object – the proposing rights for Slot N+32. The resulting bids in the first auction (the slot auction sale of Slot N+32 during Slot N) would thus not carry any economic meaning because bidders would be competing for the slot but would then be forced sellers by the time the slot arrived. To resolve this, the second auction (which happens JIT during the slot) could instead be a Top-of-Block auction (e.g., the first 5mm gas consumed in the block). There are many articles exploring the Top-of-Block/Rest-of-Block split (sometimes called block prefix/suffixes) (see, e.g., here, here, here), so we won’t go into the details of the consensus changes required to facilitate this exchange. Taking its feasibility for granted, the double-auction design of Mechan-stein makes more sense.
- Auction 1 during Slot N sells the block proposing rights for Slot N+32 and is conducted by the proposer of Slot N.
- Auction 2 during Slot N+32 sells the Top-of-Block to a (potentially different) builder who specifies the specific set of transactions to be executed first in the block. This auction is conducted just in time by the builder/winner of Auction 1.

With this framing, the winner of Auction 1 effectively bought the option to build (or sell) the Rest-of-Block for Slot N+32 – thus the expected value of the bids in that auction would be the average amount of MEV extractable in the block suffix (aside: this might play nicely with preconfs). The diagram below shows the flow at a high level (leaving off many back-and-forths for legibility).

1. The Slot N proposer auctions off the Slot N+32 proposing rights.
2. The Slot N attesters enforce the bid threshold of the slot auction.
3. [32 slots later] The Slot N+32 IL committee publishes their ILs.
4. The Slot N+32 builder auctions off the Top-of-Block for Slot N+32.
5. The Slot N+32 PTC enforces the bid threshold of the Top-of-Block auction.
6. The Slot N+32 PTC enforces the timeliness of the block publication from the winning builder.
7. The Slot N+32 attesters enforce the IL threshold of the final block.

Yeah, yeah – it’s a lot of steps, but the pitch is pretty compelling.

• Mechan-stein addresses design goal #1: encourage builder competition. The permissionless, JIT Top-of-Block auction helps mitigate the risk of multi-slot MEV in Execution Auctions by forcing the slot auction winner to sell a portion of the block or at least pay a threshold to build the full block themselves.
• Mechan-stein addresses design goal #2: limit the value of validator sophistication. The role of an average validator in block production is now the simple combination of (1) conducting the ahead-of-time slot auction and (2) publishing their inclusion list when part of an IL committee. This greatly reduces the power bestowed on the validator because (1) they are now conducting an auction apriori (thus, latency and timing games play a smaller role) and (2) the inclusion list intentionally does not generate much value for MEV-carrying transactions (because it only guarantees inclusion rather than ordering).
• Mechan-stein addresses design goal #3: preserve the neutrality of Ethereum block space. By allowing many participants to co-create the set of constraints enforced on the builder of each block, high preference entropy is achieved without unduly benefiting the transactions that land in an inclusion list, as block builders can still reorder and insert at their leisure. However, the builder’s ability to exclude is limited, removing some of their monopolist power over the transactions in the block.

The combined mechanism creates a set of checks and balances where the weaknesses of one design in isolation are the strengths of another. Everything is perfect, right?

Potential issues with Mechan-stein

It might not be only rainbows and butterflies. Without being comprehensive (neither in the list of potential issues nor the responses to said issues), let’s run down a few of the most obvious questions with Mechan-stein and some initial counter-points.

• Point #1 – complexity, complexity, complexity. This could (and maybe should) count for multiple points (h/t Mallesh for the relevant tweet). Each of these proposals involves massive changes to the consensus layer of Ethereum with wide-ranging impact (particularly on the fork-choice rule). The devil is truly in the details, and getting something like this spec’ed out and implemented would be an immense research and engineering lift – let’s just say William of Ockham would not be impressed.
  • Counter-point #1 – building the future of finance in a permissionless and hyper-financialized world wasn’t going to be simple (“Rome wasn’t built in a day”). It shouldn’t be shocking that there doesn’t seem to be a silver bullet for building an MEV-aware, decentralized, credibly neutral blockchain. Maybe eating the complexity now can leave the chain in a more stable equilibrium. Also, there may be significant synergies in combining designs (e.g., using the same committee for FOCIL and PTC). You could probably do a subset of Mechan-stein and still get some benefits (e.g., FOCIL + PTC).
• Point #2 – how may the ahead-of-time slot auction distort the MEV market? Mostly just reciting Max and Mallesh’s argument (3rd time referencing that paper in this article lol). By removing the real-time nature of the initial auction, you bias it towards a winner-take-all for the best builder (or the “Best Block Space Future Value Estimator™”). I’d say this is similar in spirit to the Phil Daian view of making the competition as deterministic as possible (e.g., “deterministic vs statistical opportunities”).
  • Counter-point #2 – that is the point of still having the PTC conduct a JIT Top-of-Block auction. I think this feels reasonable. However, there is still a slight edge that the auctioneer (who may be a builder themselves) has in the JIT auction, which is they can benefit from the sophistication and latency investments as they are the auctioneer and a participant. As mentioned above, you could consider skipping the Execution Auctions part of Mechan-stein and just going with FOCIL + PTC (or even leave MEV-boost alone as the primary PBS market and just do FOCIL). (h/t Justin for pointing out that you could try to do Execution Auctions where multiple proposers (more than one auction winner) are selected – another combined mechanism that tries to mitigate the multi-slot MEV risk.)
• Point #3 – there is still power in being the block producer. As pointed out in this comment and its response on the FOCIL post, there is still some discretionary power in being the block builder. Namely, they can choose which ILs they exclude from their aggregate up to some protocol-enforced tolerance. This notion of having an IL “aggregator” is the main difference between FOCIL and a leaderless approach like Braid.
  • Counter-point #3 – this seems like a fundamental feature. Again, I find myself leaning on Phil’s comment and mental model for “how economic power expresses itself in the protocol.” In a distributed system with network latency and geographic decentralization, some parties will have advantages over others. Suppose the protocol doesn’t explicitly imbue some participants with power during some period (e.g., by electing a leader). In that case, that power will still manifest somewhere else, likely in a more implicit (thus more sophisticated) way. This is more of a meta point, and I am happy to be convinced otherwise.

All right, going to cut it here; hope you found it interesting. Lot’s to think on still.

thank for reading -mike

---

footnotes

^{[1]}: It is worth noting that, conditioned on having strong censorship resistance properties, the difference between a monopolist builder and a competitive marketplace of builders isn’t so vital. As discussed with Barnabé and Julian, perhaps a more important property is the “replace-ability” of a monopolist builder if they begin abusing their power. All else being equal, I still prefer the outcome where we have multiple builders, even if just for the memetic reality of having a single block builder looks highly centralized, even if the other consensus participants heavily constrain them. Hence, builder competition still feels like a fair desiderata.︎

^{[2]}: Vitalik pointed out that when he originally wrote this, he was referring more to the act of validating the blocks (e.g., by verifying a ZK proof) rather than explicitly participating in consensus. The name “validator” denotes someone who engages in consensus, which has been a nomenclatural pain point since the launch of the beacon chain. Despite this, I still like the framing of keeping some form of consensus participation decentralized (mainly as a means to better chain neutrality), so I will slightly abuse the naming confusion. xD ︎

^{[3]}: It is worth noting that validators could also choose to only sell their block at a premium in the more general case through the use of the min-bid feature of MEV-boost. See more on min-bid from Julian and Data Always. ︎

7 posts - 5 participants

Read full topic

Linea’s sequencer proves a 30m gassed block of transactions in 5 minutes. Here’s its setup:

• On a 96 cores machine with 384 GB of RAM (hpc6a.48xlarge on AWS)
• In 5 minutes (only including the inner-proof)

So is it possible to reduce the proving time and, at the same time, obtain decentralization guarantees? We have an idea.

Overview

Almost all of the L2 sequencers are closed-source, intellectual property, and thus protected behind centralized setups. To cram that much power into an entity requires a great deal of justification today. To decentralize the flow, on the other hand, one has to accept certain amounts of delay and noise usually found in decentralized compute networks.

zkVMs, recursion, and Risc0’s approach

Any zkVM toolset puts a certain upper bound on the maximum number of cycles(roughly speaking 1 cycle equals 1 operation) it can prove in one go. This is usually done for efficiency reasons. For Risc0, a RISC-V general zkVM, it is 2^24 ~ 16.78m cycles. With recursion, proving infinitely sized programs are made possible. So the solution is to divide a large program into individual sub-programs(called segment in Risc0 jargon) and have them proved one by one and aggregate the proofs into a final proof as if the whole program was proved in one go. For example, consider proving a 1b cycles program. With 16.78M maximum segment size limit, one ends up proving 60 segments. The upper bound for segment size limit is not the end of story however and one can customize it into a well-known range of [2^13 - 2^24]. Each segment limit size needs specific memory requirements shown on Table 1:

Extrapolating Table 1’s values, we get 50m cycles for a program that needs 384gb of memory, in order to be proved in Risc0. Recall that Linea’s prover uses 384gb of memory to generate proofs. This is a naive 1-1 translation, but we can treat it as baseline for further testing. So, with this assumption, should one write Linea’s sequencer logic in Risc0, she would end up with a program that is 50m cycles long. Doubling cycles to ~90m, to account for aggregation won’t hurt here.

Segmentation, parallel proving, and decentralization

Recursion is a powerful idea in zkVM proving. With recursion once can get to prove seemingly large programs very quickly assuming she has a prove-ready network of machines. Table 2 shows a segmented prove session for a 90m cycles program on a pretty weak machine(8+ years old, Intel core i7 5500U(2C 4T), 16gb memory):

As you can see, different segment size limits result in varied proving regimes. In Table 2, two columns are colored in green, 2^18 and 2^19. Consulting Table 1, we would get 2gb and 4gb of required memory to prove them respectively. These columns are sweet spots for any zkVM proving network whose nodes are presumably weak. Focusing on the 2^19 segment size limit, to prove a 90m cycles program, one would need at least 168 nodes in order to prove the program in 4 minutes and 9 seconds. But 168 nodes is a faulty assumption. In reality, if a p2p network is to undertake the proving job, it needs to have redundancy values of 1:4 and above. The redundancy accounts for noise that is a feature of any p2p network. With 1:4 redundant nodes, 1 in every 5 nodes is assumed to be honest and the rest are time wasters. So, a 1:4 redundant p2p network needs at least of 840 nodes to get the job done.
Assuming that the proving network is p2p, one can expect to obtain decentralized guarantees en route.

Conclusion

Here we introduced an imaginary setup to decentralize and improve L2 sequencer proving times. If the claim turns out to be legit, we would expect to improve the overall proving time for any zkVM application area. In addition, the setup provides decentralization guarantees as a side effect. While everything looks nice, we, at Wholesum network would like to put this setup to test and see if it works in action. If successful, a p2p verifiable compute network of 10,000 weak nodes can handle up to 10 Linea like L2s.

A somewhat more expanded version of this post is also available here.

We appreciate your feedback.

2 posts - 1 participant

Read full topic

On Proposer Timing Games and Economies of Scale

Timing games are a known phenomenon ([1], [2] and [3]). The concern is that proposer timing games come with a negative impact on the network.

In the following, I want to show how the success of playing proposer timing games is also a function of economies of scale.

The main finding is:
→ An entity with 30% market share can delay 0.8s longer than a 5% entity.
→ For every 1% increase in validator market share, the delay in block proposals can increase by 0.03 seconds without facing additional reorg risk.

Special thanks to Anders, Mike and Caspar for feedback!

Introduction

A proposer must gather at least 40% of these votes to ensure their block is accepted and not reorged by the following proposer. It’s 40% because that’s the proposer boost threshold. Blocks with less than 40% attestations can be reorged by the next proposer leveraging proposer boost. The challenge for a timing-gamer lies in determining the optimal time to propose (or call getHeader). An economically rational validator would want to wait as long as possible (providing the builder with the longest possible time window) without risking a reorg.

First, let’s revisit the following chart from this analysis:

~80% of all attestations are seen until second 5 in the slot. The 40% threshold is reached somewhere around second 3.8. Thus, assuming zero latency, a block published at second 3.8 should still be able to receive 60% of attestations.

In the following, we refer to this curve as C(t).

Initial Setup

The core idea is to determine how the cumulative votes cast by validators evolve over a slot and how a proposer’s control over a portion of these validators may influence the optimal timing of their block proposal.

Given that C(t) represents the cumulative percentage of votes cast by time t, the proposer controls x\% of validators, and needs to ensure that they can still reach at least 40% by the time they propose, we start with the following condition:

In this equation:

• (1 - C(t)) \times (1 - x): The remaining uncast votes from validators not controlled by the proposer, which could support the proposer’s block.

Note that x \times C(t) would be the portion of votes from the proposer’s validators already included in C(t).

Two assumptions are important to stress:

• Coordination: It is assumed that validators coordinate when attesting, e.g. using a central oracle that provides the commands.
• Honest Validators: All validators who have not yet voted at the time of the block proposal will vote for the proposed block (and not the parent block). See honest validator specs.

Simplifying the Equation

We rearrange the initial equation to find the threshold for C(t), the cumulative percentage of votes that can be cast before the proposer must act:

Expanding and simplifying:

Finally, solving for C(t):

Find the complete derivation here.

Interpretation

This simplified equation C(t) \leq \frac{0.6}{1 - x} means that the proposer can safely propose as long as the cumulative attestations C(t) remain below the threshold defined by \frac{0.6}{1 - x}.

• C(t): The cumulative percentage of votes cast by time t.
• x \%: The percentage of total validators controlled by the proposer.
• 0.4: The 40% threshold needed to secure a majority (1-0.4=0.6).

The equation ensures that the proposer, with their share of validators, can still influence the outcome favorably by proposing before the cumulative attestations exceed this threshold.

A node operator with many validators can risk a few seconds more than a small-size operator, knowing that their own validators will never vote against them.

The following chart shows the effects of economies of scale and answers the question of how long a node operator with x% market share can maximally wait until the point it won’t be able to receive at least 40% of all attestations anymore.

The “seconds in slot” values on the y-axis are attestation_seen timestamps that are not corrected by the time required for block propagation and verification. Since those numbers are just constants impacting the absolute values on the y-axis, this doesn’t matter in making the relative impact of market share on the limits of timing games visible.

We can see that a node operator with 30% of the market share can potentially wait 0.8 seconds longer than a node operator with 5% market share while risking the same.

In Python

Using Python, we can calculate the latest “safe” proposal time for different percentages of validator control. Here’s the key part of the implementation:

import numpy as np
from scipy.interpolate import interp1d

# Provided cumulative attestation data (seconds, % of casted attestations)
data = [
     (0.791, 0.0005390835579514825),
     # (additional data points omitted for brevity)
     (2.228, 0.05444743935309973),
     (2.464, 0.10835579514824797),
     (2.639, 0.16226415094339622),
     (2.777, 0.21617250673854446),
     (2.932, 0.27008086253369273),
     (3.104, 0.323989218328841),
     (3.308, 0.3778975741239892),
     (3.627, 0.43180592991913747),
     (4.069, 0.4857142857142857),
     (4.25, 0.539622641509434),
     (4.407, 0.5935309973045823),
     (4.576, 0.6474393530997304),
     (4.723, 0.7013477088948787),
     (4.898, 0.7552560646900269),
     (5.039, 0.8091644204851752),
     (5.245, 0.8630727762803234),
     (5.521, 0.9169811320754717),
     (6.187, 0.9708894878706199)
]

# Extracting the times and cumulative attestation percentages
times = np.array([point[0] for point in data])
cumulative_attestations = np.array([point[1] for point in data])

# Interpolating the cumulative attestation function
cumulative_attestation_func = interp1d(times, cumulative_attestations, kind='linear', fill_value="extrapolate")

# Function to calculate the latest time a proposer with x% control can safely propose a block
def calculate_latest_proposal_time(x):
    threshold = 0.5 / (1 - x)
    
    for t in np.linspace(times[0], times[-1], 1000):
        if cumulative_attestation_func(t) > threshold:
            return t
    return None

Conclusion

By understanding and calculating the relationship between validator market share and cumulative attestations, proposers can optimize their proposal timing to minimize the likelihood of reorgs while maximizing profits.

Such strategies could be improved by checking which CL client the subsequent validator runs, or, even simpler, the slot index in an epoch. Based on that information one can better estimate the chances of getting reorged (e.g. if it’s Teku, Nimbus, Lodestar, or the last slot in an epoch, then the reorg probability is significantly lower because no honest reorg strategy is implemented).

Pushing proposer timing games to their limits has a negative impact on attesters and can have cascading effects: If validators realize they miss out on profits because they vote for the wrong block too often, they might start delaying their attestation.

Ultimately, pushing timing games to their limits can have a detrimental impact on the network. Furthermore, validator coordination that goes beyond running multiple validators from a single node shouldn’t be tolerated/supported. Now, it is important to follow/contribute to block construction research and find ways to reduce the profitability of timing games or prevent them entirely.

1 post - 1 participant

Read full topic

by KD.Conway

TL;DR

• We propose a decentralized and verifiable cloud service protocol on Ethereum, which can provide computationally intensive service to all web2 or web3 applications, making decentralized ChatGPT, decentralized blockchain explorer reality. By migrating the full stack, including frontend and backend components, to the decentralized cloud, we move toward fully decentralized and verifiable end-to-end Web3 applications.

• The protocol operates under a minority trust assumption, requiring only one honest node to guarantee service quality. Additionally, the correctness of the cloud service is verifiable on Ethereum.

• With near-zero on-chain costs, our decentralized cloud service platform can be even more affordable than traditional centralized options.

Protocol Overview

A service contract exists on Ethereum, functioning similarly to a gRPC protobuf. This contract defines the service, and the functions within it specify the methods that can be invoked.

Each service provider must register and stake on the service contract. For each service, multiple providers will be available to offer the service.

When a user initiates a service request, such as requesting an AI inference from an LLM model:

• The user first utilizes a verifiable Ethereum light client, such as Helios, to retrieve the list of available service providers from the on-chain service contract.

• The user randomly selects several providers from this list.

• The user then sends off-chain transactions to these selected providers in parallel. These off-chain transactions are essentially the same as calling the corresponding service function in the smart contract, but they use a different chain ID. This specific chain ID indicates that the transaction is intended to call a cloud service rather than perform an on-chain transaction on Ethereum.

• The service providers execute the required computations in their local environments according to the program defined in the corresponding function in the service contract. They then return the responses to the user. Each response is signed by the service provider and includes the user’s transaction hash and the results.

• Upon receiving the responses from the selected providers, the user first verifies the signatures and checks the consistency of the results.

  • If the results are consistent, the service is considered to have functioned correctly, and no further action is required.

  • If there is a discrepancy in the results, this indicates the presence of at least one malicious service provider. In this case, the user submits the providers’ responses to the on-chain arbitration contract. This triggers a process where the service providers must defend the accuracy of their results. The on-chain arbitration process is detailed in the following section.

Service Contract

The design of the service contract is akin to the design of gRPC. A new service contract corresponds to a new service in gRPC, and the functions defined in the service contract specify the methods that can be invoked. Due to the constraints of smart contracts, we cannot implement complex computations, such as AI computations, directly within the smart contract. Instead, we define a standard for writing a program, which is then uploaded to decentralized DA services, with the program’s hash stored in the on-chain smart contract.

Following the design principle of “Separate Execution from Proving,” there are two implementations for the service program. One is compiled for native execution, optimized for speed, and can leverage multithreaded CPUs and GPUs to accelerate execution. The other implementation is for proving; the service program is compiled into machine-independent code, allowing us to use zkVM (zero-knowledge virtual machine) or fpVM (fraud-proof virtual machine) to generate proofs. This dual-target approach ensures fast execution, while proving is based on the machine-independent code.

For example, consider matrix multiplication. Native execution utilizes GPU computation (e.g., CUDA) for acceleration. During the proving phase, the service program is compiled into machine-independent instructions, which can be executed in zkVM or fpVM. Both implementations ensure consistent execution results.

When processing user requests, service providers will run the program in the native execution environment and return the results to the users. Only when on-chain arbitration is required will the service providers run the program for proving. This approach allows service providers to handle requests as quickly as possible in most cases.

Additionally, the service program can be configured to read data from trustworthy sources, such as Ethereum or other blockchains, as well as from decentralized, trustworthy data storage providers. This flexibility allows the service program to function as a blockchain explorer, an AI service, or a decentralized search engine.

A demo version of the service contract is shown below.

contract Service {

    // address => web2 domain
    mapping(address => string) serviceProviderHost;

    address[] serviceProviders;

    // function selector => programHash
    mapping(bytes4 => bytes32) programHashs;

    event Request(
        address account,
        bytes4 functionSelector,
        bytes32 programHash,
        bytes input
    );

    function func1(bytes calldata input) public {
        emit Request(msg.sender, this.func1.selector, programHashs[this.func1.selector], input);
    }
}

Note that func1 specifies the method that can be called. When a user wants to call func1, instead of sending an on-chain transaction on Ethereum, the user needs to send an off-chain transaction directly to the service providers. Besides, the user can obtain the list of service provider addresses, along with their corresponding Web2 domains using Ethereum verifiable light client.

Onchain Arbitration

We support multiple proving systems for on-chain arbitration, including zero-knowledge proofs, Trusted Execution Environments (TEE), and fraud-proof systems. For demonstration purposes, we focus on the fraud-proof system, as it offers lower generation costs compared to zero-knowledge proofs and does not require specific hardware. In previous work, we demonstrated the ability to generate fraud proofs for extremely large AI models. For more details, please refer to opML ([2401.17555] opML: Optimistic Machine Learning on Blockchain).

The on-chain arbitration process using the fraud-proof system proceeds as follows:

• If a user receives inconsistent results from the service providers, they submit the providers’ responses to the on-chain arbitration contract, initiating an interactive dispute game with all the involved providers.

• At this point, the service providers must run the proving-version of the service program in their local fraud-proof VMs to generate the fraud proof, which they then submit to the on-chain arbitration contract to defend their results. For more details on the interactive dispute game, refer to the fraud-proof system design.

• Service providers who supplied incorrect results will lose the dispute game, resulting in their staked amount being slashed. The slashed stake will be distributed to the winners of the dispute game, as well as to the user, as compensation.

This on-chain arbitration mechanism ensures that only one honest node is required to guarantee the correctness of the provided service. As a result, the protocol relies on a minority trust assumption and inherits security from Ethereum. Assuming at least one honest node and the safety of Ethereum, the protocol can guarantee the correctness of the service.

It’s important to note that on-chain arbitration only occurs when some service providers produce incorrect results. In typical cases, no on-chain interaction is needed, which allows the service to operate as quickly as current centralized cloud service providers.

Charging Mechanism

There are several possible charging mechanisms:

• Subscription Model: This is similar to the Web2 approach, where the charging mechanism can be conducted off-chain. For example, to use ChatGPT via an API for commercial purposes, you would pay OpenAI a monthly fee to access their services. Multiple service providers can offer the service, allowing for competition and choice.

• On-Chain Payment Mechanism: Paying for each request on-chain can be costly due to transaction fees. Batching and rolling up these requests and payments can significantly reduce on-chain transaction costs. One possible approach is to use payment channels to pay for requests. Alternatively, service providers could generate service proofs and claim fees as follows:

  • A service agreement contract specifies the price for each service request.

  • Users first stake funds into the service agreement contract.

  • Service providers can claim their fees by submitting service proofs to the on-chain service agreement contract. To minimize transaction costs, providers can batch and roll up user requests.

  • The on-chain service proof is a zk-proof, which verifies that the service provider has delivered a certain number of responses to users. The provider can then claim the corresponding service fees according to the agreement contract. This proof ensures the correctness of the user’s request transaction signature, the service provider’s response signature, and the transaction nonce.

• Free Service Model: Another approach is for companies to cover the service fees by the themselves (currently, the web2 companies pay the cloud service fee by themselves), offering free services to users while generating revenue through other means, such as advertising or VIP services.

Advantages

• This decentralized cloud service can be cheaper than centralized cloud services while maintaining similar speed.

  • Cost-Effectiveness: Decentralized servers can be significantly cheaper than centralized cloud servers. For example, io.net has shown that the cost of decentralized GPUs can be as low as one-third of the cost of AWS. For services with lower security requirements, such as using LLMs for personal queries, using just two nodes is often sufficient. Additionally, a random check mechanism can be adopted, querying one node most of the time and occasionally checking another to verify correctness. This setup can be more cost-effective than centralized platform.

  • Scalability and Speed: This platform can outperform centralized systems, especially for computationally intensive tasks. A decentralized cloud service platform operates on an N-to-M model (N users with M servers, where the number of servers can be infinite), whereas centralized platforms use an N-to-1 model (N users with a single super server). This allows a decentralized cloud service platform to scale more effectively. For instance, a centralized AI platform like ChatGPT may slow down during peak times because it can’t scale its computing power quickly enough. In contrast, decentralized platform can dynamically distribute the load across many servers, ensuring faster response times even during heavy usage.

• Trustless and Verifiable: The protocol operates under a minority trust assumption, requiring only one honest node to guarantee service quality. Additionally, the correctness of the cloud service is verifiable on Ethereum.

• Censorship-Resilient: This platform contributes to a more robustly decentralized Web3, enhancing censorship resistance.

Toward Fully Decentralized and Verifiable Web3 Application

With this protocol, we can move toward fully decentralized and verifiable Web3 applications.

Decentralized and Verifiable Blockchain Explorer: Currently, blockchain explorers like Etherscan are hosted by centralized entities, and the results they present are not verifiable. If such an explorer were hacked, it could display malicious and misleading information, such as fake transactions or contracts, potentially leading to phishing scams. By migrating the entire blockchain explorer—including both the frontend and backend services—to our platform, we can ensure full verifiability and robust security for the blockchain explorer.

Decentralized, Verifiable, Faster, and Cheaper AI Platform: This protocol enables the creation of a fully decentralized, verifiable, and cost-effective AI platform. By moving the entire stack, including both frontend and backend services as well as AI computation, to a decentralized cloud, we can build an AI platform that is not only more affordable but also potentially faster than centralized alternatives.

Decentralized Cloud Gaming: Some games require high-end hardware, such as powerful GPUs and CPUs, leading game companies to move their games to cloud services, reducing the hardware requirements for customers. We can similarly bring Web3 games to our platform. Since our platform is verifiable on Ethereum, game reward settlements can be easily managed through smart contracts.

Further Discussion

Updating the State

In the previous discussion, the service program operates under a stateless design, meaning it does not modify its internal state. However, the data source used by the service program is upgradable. For instance, if a service program uses Ethereum as its data source, users can interact with smart contracts on Ethereum to update the state. The service program can then utilize the latest Ethereum state as its data source, enabling the implementation of a decentralized explorer.

If updating the internal state of the service program is required, a state machine replication network must be established among the service providers. In this case, each service program would correspond to a layer 2 or layer 3 blockchain on Ethereum. When users invoke a method that updates the internal state, they would send the transaction to the corresponding layer 2 or layer 3 blockchain. The service providers would then reach a consensus on the execution results of that transaction and update the internal state accordingly. Periodically, the layer 2 blockchain would roll up the transactions and its latest state back to Ethereum.

Verifiable FHE

To ensure user privacy, Fully Homomorphic Encryption (FHE) can be integrated into our protocol. In this case, the FHE computation would be incorporated into the service program. Instead of sending plaintext data to the service providers, users would encrypt their input and send only the ciphertext, thereby preserving their privacy. Additionally, if on-chain arbitration is triggered, the FHE service program would be compiled into machine-independent instructions, and a fraud proof or zk-proof would be generated to make the FHE computation fully verifiable.

Related Work and Comparison

Comparison with Web3URL

Web3URL (https://w3url.w3eth.io/) is an interesting project that transforms Ethereum into an unstoppable decentralized web server. Our protocol can be seen as a significant extension of Web3URL. In Web3URL, service functions must be written within smart contracts, which naturally limits large-scale applications. In contrast, our protocol supports complex service programs, such as AI computations, and provides flexible access to large-scale data, making decentralized ChatGPT and decentralized explorers a reality.

Comparison with ICP

The Internet Computer (ICP: https://internetcomputer.org/) hosts decentralized serverless compute, similar to our goal of creating a decentralized cloud service platform. However, we differ from ICP in several key aspects:

• Ethereum Integration: We are building on Ethereum, allowing us to inherit its security features.

• Higher Security: We achieve a higher level of security compared to ICP. While ICP operates in a Byzantine Fault Tolerance (BFT) network under a majority trust assumption—requiring that most nodes in the subnet are honest—we adopt an approach similar to rollups, with on-chain arbitration ultimately reverting to Ethereum. This allows us to guarantee correctness under a minority trust assumption, where just one honest node can ensure the integrity of our protocol.

• Complex Computation: Following the design principle of “Separate Execution from Proving,” we can handle complex computations natively, such as LLM inference or even fine-tuning. In contrast, service programs in ICP always run within canisters, which significantly limits their applicability for large-scale computations.

If you are interested in this project or have suggestions for improvements, please feel free to reach out to me.

3 posts - 2 participants

Read full topic

By: Jonah Burian and Ben Levy

Tl;dr: We point out that BRAID’s liquidity requirements lead to poor user UX and suggest censorship insurance markets as a potential solution.

Thanks to Max Resnick and Davide Crapis for the feedback.

Intro

“The greatness of America Ethereum lies not in being more enlightened than any other nation blockchain, but rather in her ability to repair her faults.” - Alexis de Tocqueville

Censorship resistance (CR) is one of the core security properties of a blockchain.

Ethereum gifts proposers with one-slot monopolies on transaction inclusion, creating a principal-agent problem and a single point of failure. A censoring party can bribe the current proposer to censor a transaction.

There has been considerable work to mitigate this problem. A key insight is that the weak link problem of a single proposer results in weak CR. Multi-proposer schemes like BRAID and FOCIL can correct this principal-agent problem.

In this piece, we focus on BRAID, a multi-proposer mechanism that has garnered significant recent attention. It aims to increase CR in a capital-efficient way via a conditional tipping mechanism (explained below).

One challenge in this approach, the need for a deterministic ordering rule, is already well understood. In this piece we identify another challenge—liquidity requirements that adversely affect UX—and propose a few potential solutions.

BRAID at a High Level:

BRAID runs k subchains in parallel, each with a unique proposer. Block n of Ethereum is the union of transactions from block n of the k subchains, with a special ordering rule applied to order this unordered set.

Tipping in BRAID

Bidders submit a conditional twin tip (t,T) which depends on the number of proposers who include the transaction. If only a single proposer includes a transaction, they receive T; if multiple proposers include the transaction, they split t.

Tipping Properties

Let ϕ(t,T) be the minimum cost to censor a BRAID transaction. It has been shown that ϕ(t,T)=kT.

The goal of BRAID is that users will most likely never actually have to pay T; instead, they pay t, which can be much lower than T.

This multi-dimensional tip disentangles the cost of inclusion (for the transacting party) from the cost of censoring such that t<<T.

Simply put, a user get’s kT worth of CR while (usually) only paying t.

How Users Will Tip:

• T: From a user’s perspective, they set T=\frac{V}{k} where V is the value the user places in their transaction not being censored.
• t: In current BRAID specs, the ordering of transactions depends on t, with more favorable ordering (i.e., coming first) given to those with the highest t. Therefore, a user will choose their t based on where they want to be in the ordering.

Note that if a user does not care about CR, they can set T=t and send their transaction to just one proposer.

The UX Challenge:

While a user will only pay t for their transaction, they need to have T available to make a credible promise to the protocol that they can pay T. Hence a user needs to have T of additional available liquidity to make a transaction. We saw before that T \propto V: T tends to scale with the value of the transaction. This burdens users with a liquidity requirement.

For example, say a user wants to sell $5M of ETH due to impending interest rate fears and values censorship resistance at $1M. Let’s say there are 4 shards, i.e., k=4. The user needs to have $250k of additional unpledged liquidity available just to exit their position. This hampers the UX of on-chain finance by placing additional and obscure liquidity requirements on participants that scale with the value of their positions.

Fixes:

Proof of Post-State Liquidity

Idea: A user submits a transaction with a proof that they will have enough liquidity to pay T if necessary after their transaction. In the case before, the proof will show that the transaction will give the user $1M of liquidity so they could afford the T= $250k if necessary.

Problem: This assumes that a proposer has a good understanding of the post-state of a transaction. Most financial transactions interact with shared state, and as a result, transaction ordering is needed to know the post-state. This knowledge relies on the final ordering so we can’t include it as an input to the transaction. Even when there is a reasonable lower bound on post-state available liquidity, establishing it would (unrealistically) require bespoke proofs for each transaction type.

Censorship Insurance (CI)

Idea: A third party–the CI provider–can sponsor the escrow of T for the transaction. Users will have to pay an insurance premium of rT to the CI provider, where r represents the rate (mostly) based on the likelihood of censorship. CI providers are thus assessing the rewards of censoring the transaction in real time to ensure it is below kT.

To prevent an attack where a user purchases insurance and then only sends their tx to one proposer whom they are colluding with, the CI should be (one of) the relayer(s) for the tx. This mirrors how gas sponsorship works and indeed CI insurance should likely just be included in a gas sponsorship service.

Effectively a user pays a total of t + rT for their transaction and only needs to have t + rT on hand as opposed to T, which is frequently more than t + rT.

An additional benefit of this scheme is that a marketplace of at least two CI providers will conveniently alert users when their T is too low and there is a high risk of censorship because they’ll refuse to censorship-insure the transaction at a reasonable rate.

Problem: It will be difficult to bootstrap a two-sided marketplace for this from scratch.

CI Market Structure

In practice applications or wallets will likely claim jurisdiction over this issue. One possible solution to the bootstrapping problem, therefore, is for applications and/or wallets to sign wholesale agreements with CI providers à la PFOF.

While the above solution likely works fine, another option is to create a proper on-chain market with e.g. an RFQ for each transaction whose sender wishes to purchase censorship resistance for.

This market, fittingly, would benefit from the CR properties of BRAID.

Conclusion

BRAID is still in its early days as a proposal. The UX issue of liquidity requirements has not been sufficiently explored, though there are promising signs that we can reasonably punt the issue to the application layer. For next steps, we suggest further exploration of the feasibility of CI markets.

Previous work:

• Censorship Resistance in On-Chain Auctions: Elijah, Max, Mallesh
• Concurrent Block Proposers in Ethereum: Mike, Max
• Introducing Multiplicity: Duality blog
• ROP-9: Multiplicity gadgets for censorship-resistance RIG
• BRAID: Implementing Multiple Concurrent Block Proposers: Max
• Fork-Choice enforced Inclusion Lists (FOCIL): A simple committee-based inclusion list proposal: Thomas, Barnabé, Francesco and Julian

4 posts - 3 participants

Read full topic

Work presented here has been carried out by the ProbeLab team and in particular @guillaumemichel @cortze @dennis-tra and Steph.

High Level Description

The ProbeLab team has developed and deployed infrastructure to monitor several critical metrics for Ethereum’s CL discv5 DHT network. In particular, we have adapted the Nebula crawler (GitHub - dennis-tra/nebula: 🌌 A network agnostic DHT crawler, monitor, and measurement tool that exposes timely information about DHT networks.) to be compatible with discv5-based networks and are gathering results that reflect the health of the P2P network at the DHT level.

In this post we’re presenting a summary of what is included in the reports, but for a more complete picture of what’s there, head to: https://probelab.io/ethereum/discv5/2024-29/ for the latest report.

• Reports are produced every Monday for the preceding week.

• The methodology we follow for DHT Crawling, Data Filtering, Node Classification as well as the differences of our tool to alternatives in the space is given in the Methodology section: https://probelab.io/ethereum/discv5/methodology/.

• The crawler used to produce the reports can be found (and can be reused) here: GitHub - dennis-tra/nebula: 🌌 A network agnostic DHT crawler, monitor, and measurement tool that exposes timely information about DHT networks..

Why you should care

The metrics included in the reports:

• give an overview of the network structure, size and client adoption breakdown. This helps in understanding the robustness and diversity of the network,

• provide accurate geographic distribution of nodes in the network per client implementation over time, which can highlight regional trends and potential vulnerabilities or strengths in specific areas,

• make it easy to spot drastic changes in the structure and setup of the network,

• allow for monitoring of new protocol version uptake/adoption, and provide insights on whether there are adoption barriers,

• reveal the infrastructure setup (e.g., data center-hosted vs non-data center-hosted) and cloud provider distribution per client implementation,

• show the breakdown of nodes supporting particular network-layer protocols,

• depict the percentage of reachable vs unreachable node records in the DHT network.

Overview of Results

We’re presenting a small fraction of the results given at https://probelab.io to give an idea of the metrics listed. Please head there for the complete reports from Week 11 (mid-March), 2024.

Client Diversity

Client Diversity Over Time

Agent version adoption over time - Example: Lighthouse

Country distribution of all nodes

Client-specific country distribution - Example: Prysm

Cloud provider distribution of all nodes

Cloud vs non-cloud distribution of nodes over time

Stale Peer Records over time

How to contribute

Overall, we believe this set of results give an accurate view of the structure and health of the discv5 DHT network. We hope you’ll find the reports useful.

If there are important metrics that you believe should be part of these weekly reports, comment below, or get in touch with the team: probelab.network/contact.

1 post - 1 participant

Read full topic

I’m excited to share my ongoing research on a protocol designed to streamline communication and decision-making around subjective matters, particularly within DAOs and R&D processes. This protocol establishes a ranking system that counters common governance issues, fostering a more collaborative and effective environment.

I’m posting this in the meta-innovation category because it has implications both for DAO/Consensus research and for potential collaboration tools within the Ethereum community.

Link to paper in progress: papers/acid/whitepaper.pdf at main · peersky/papers · GitHub

TL’DR

The protocol enables subjective decision-making and quantifies proposer ratings. Participants define a context and engage in rounds of discussion, providing and receiving feedback without revealing identities until the round concludes. This mitigates biases like the Halo effect, and collusion (sybil attack) risks.

Protocol streamlines discussions and enables autonomously assign competent decision makers as well as create pre-arranged agenda for any follow up voting systems (hence addresses Agenda Manipulation, ( casually explained in this youtube video ) problem

Motivation

Communication Complexities Hinder Decision-Making

Effective decision-making is hindered by communication complexities.

• Traditional methods (meetings, chats): don’t scale, leading to information overload and delays.
• More stakeholders exponentially increase communication complexity, leaving less time for effective decisions.
• Individual contributions can get lost, leading to under-appreciation and high turnover.

Traditional Organizations are Sub-optimally Managed

Despite modern networking and project management technologies, the primary, basis of hierarchical communication hasn’t changed much over centuries. Decisions still require large centralization force, which will step in and cut opinions to shape performance capable decision.

• Centralized decision-making prioritizes efficiency over diverse input, fostering internal politics and biased decisions.
• This breeds internal politics, leading to biased decisions that may harm the organization.
• Current methods lack objective ways to measure and reward valuable contributions, limiting organizational potential.
• Does not let organizations reach their full potential

This touches every organization, including Ethereum R&D.

ICOs do not work well for DAOs

Research shows that many DAOs are highly centralized, with low participation rates and vulnerability to governance attacks. The incentive structures in Proof of Stake (PoS) and Proof of Work (PoW) systems can lead to centralization.

Cyber-Physical-Social-Systems

There’s a growing need for DAOs to bridge traditional management with AI agents and automated infrastructure, as highlighted by research in Cyber-Physical-Social Systems (CPSS).

Approach

The protocol aims to incentivize participation without enabling influence compounding. It builds on a real-world game where participants propose and vote on ideas (like music tracks) without revealing identities until the round ends.

Key requirements for the protocol:

• Mission aligned: Participant activity directly impacts organizational goals.
• Highly performant: Organizations using the protocol should outperform traditional structures.
• Centralization resilient: Financial contributions shouldn’t lead to disproportionate influence.
• Multidimensional: Support diverse participant interests.
• Rational: Function even when agents act in their self-interest.

Key features:

• Competence-based participation: Participants earn governance rights through demonstrated competence, not just financial contributions.
• Sybil attack resistance: A tournament ladder structure imposes costs and time requirements, making manipulation difficult.
• Progressive decentralization: Organizations can evolve by adding governance layers, increasing overall governance surface area.

Current State

• Research paper in progress: Seeking feedback and potential co-authors.
• Basic prototype and testing: Exploring use cases beyond music, such as manage-less code writing.
• Website with Telegram group: https://rankify.it

1 post - 1 participant

Read full topic

Introduction

In blockchain and PKI more generally, people are represented by keys. A somewhat strange question to ask might be “why don’t keys represent people?” I will argue this is actually an important question and the crux of major privacy and onboarding challenges. We present a a threshold network design dubbed Mishti Network to derive keys from people rather than arbitrary randomness. This network solves a number of problems in ZK identity, compliance, and onboarding.

What does it mean for a key to be a representation of a person? There are two conditions that should be met:

• A person’s knowledge and/or attributes can always map to the private key
• This person is the sole controller of the key

In other words, it is a collision-resistant map of personal data and attributes to a high-entropy pseudorandom number. Without collision resistance, multiple people could have the same key. Without high entropy, the key is not secure. Keys can be both standard private keys or also a nullifier that’s useful for secure ZK credentials.

Human keys are not solely biometrics. They could be from human-friendly data such as security questions, passwords, or any unique knowledge belonging to an individual rather than arbitrary randomness.

Solution: Oblivious Pseudorandom Function

This solution is based on a threshold verifiable oblivious pseudorandom function (tVOPRF) on private data. An oblivious pseudorandom function (OPRF) takes a private input and computes a pseudorandom function (PRF). PRFs take low-entropy input and create high-entropy output. Adding verifiability via a ZKP makes it into a VOPRF. Verifying individual node contributions is important to decentralizing the network.

Why it is helpful to Ethereum + PKI

Some of the outstanding issues in Ethereum are onboarding and privacy. Onboarding requires not just simplicity but also self-custody, and recovery. Current onboarding solutions such as social logins and passkeys do not have self-custody (as they can be recovered by web2 accounts), while self-custodial solutions can’t have recovery without extra onboarding step like electing gaurdians.

A similar need is for ZK identity applications that need to derive nullifiers from their users’ identities, in a way nobody can trace back to the user. This is a common need in proof-of-personhood solutions to ensure that each person only has one corresponding nullifier without a central database or key that links users to their nullifiers.

Furthermore, the underlying cryptography and network can be repurposed to tackle another pressing challenge: that of satisfying compliance rules with ZK identity. The same underlying elliptic curve multiplication primitive that underlies this design can be used to construct threshold ElGamal decryption over ZK-friendly curves, which can allow ZK proofs to contain encrypted data with flexible access control.

Oblivious Pseudorandom Function

To generate keys from identities, an oblivious pseudorandom function (OPRF) can be constructed with distributed EC scalar multiplication. This allows private user data such as security questions, biometrics, passwords, or social security numbers, etc. to deterministically generate secret keys. The resulting pseudorandom value is computationally impractical to reverse despite it being from low-entropy input. One can thereby create wallet or nullifier from any (or a combination) of these low-entropy “human” factors. In the 2HashDH OPRF [1], a server or network’s secret is used to give randomness to the client’s input. The oblivious property prevents any server or set of nodes from seeing see this input.

2HashDH is the following algorithm between a user with a private input x and a server (or network) with a private key s. For a subgroup G of an elliptic curve there are two hash functions:

hashToCurve: \{0,1\}^* \rightarrow G
hashToScalar: G \rightarrow F_q.

The 2HashDH OPRF proceeds as follows

1. User samples a random mask r and sends M = r * hashToCurve(x)
2. Server multiplies by its secret, returning s * M
3. User computes the output by unmasking the server’s response and hashing it: o = HashToScalar(r^{-1} * s * M)

o is uniformly pseudorandom in F_q, and the server is information-theoretically blinded from the user’s input.

Decentralizing the server

To decentralize the OPRF server, only the step with a server must be decentralized:

2. Server multiplies by its secret, returning s * M

For threshold elliptic curve multiplication, first a linear secret sharing, such as Shamir’s scheme, must be used. The secret key is generated through distributed key generation (DKG) such that each node with index i receives share f(i) for some secret polynomial f known to nobody. There is no node at the 0 index and f(0) is the secret key of the network. The secret key f(0) can be computed by a set Q of t nodes where t is one more than the degree of f.

f(0) = \sum_{i \in Q}{L_{0, Q}(i)*f(i)}

where L_{0,Q}(i) is the Lagrange basis for index i in set Q evaluated at zero.

Instead of reconstructing f(0), the nodes can collaborate to construct f(0) * M

f(0) * M = \sum_{i \in Q}{L_{0, Q}(i)*f(i) * M}

This is sufficient for step

2. Server multiplies by its secret, returning s * M

if the nodes are honest. But if one lies, the result will be wrong and there will be no way of knowing who lied. Thus, each node should prove their individual multiplication using a lightweight zero-knowledge DLEQ proof.

Other interesting use case: Provable encryption with programmable privacy

The same decentralized EC scalar primitive can be used not just for VOPRF but also for ElGamal decryption over ZK-friendly curves. This is helpful when identities must be revealed in certain conditions.

For example, many private DeFi protocols are interested in ensuring that bad actors do not get the benefits of anonymity, while the average user typically does. Governments are not satisfied with solely ZK because they need access to user data, but currently the only alternative is honeypots where all user data is stored to be turned over to authorities if needed.

Another use of revealing provably encrypted identities under certain conditions is undercollateralized lending – what if you want an identity or private key to be revealed if a DeFi loan is defaulted on? In this case, you need to prove the proper data is encrypted correctly, then have a smart contract control decryption rights.

To modify this threshold EC point multiplication to such use cases, little is needed.

Encryption

ElGamal encryption is client-side:

1. Create an ephemeral keypair (a, A = aG)
2. Encode the message as an EC point P
3. Compute Diffie-Hellman shared secret with network public key: aB
4. Compute the ciphertext (A, aB+P)

Decryption

Unlike encryption, decryption requires a server or decentralized network.

1. Server/network multiply ephemeral public key A by its secret key b to get bA = aB
2. Decryptor subtracts this value from aB+P to get P

The server/network’s step can be handled by the same threshold multiplication protocol as before!

Network Setup and Collusion Protection

The team at Holonym has implemented this as as an AVS on Eigenlayer called Mishti Network. High reputation is common among Eigenlayer operators despite the permissionless nature, so it is ideal for threshold networks where collusion is a concern. To further mitigate collusion risk, there is the idea of parallel networks:

The asynchronous and homomorphic nature of the computations means users can permissionlessly add nodes outside of Mishti Network that they trust to not collude with Mishti Network. E.g. instead of splitting a secret between Mishti Network, half of the secret is between the Mishti Network and the other half in a semi-trusted node elected by the user. Since the whole network just does an EC multiplication, exactly what its individual does do, nodes and networks can be treated the same. A 2/2 scheme could be done between a semi-trusted node and Mishti network, simply by

• Adding their public keys to get the joint public key
• Adding their responses to get a joint response to the computation

Note this requires no consent from the network and is not limited to 2/2 schemes; it can be done with any combination of semi-trusted nodes and/or independent networks via threshold schemes.

References

[1] S. Jarecki, A. Kiayias, and H. Krawczyk, “Round-optimal
password-protected secret sharing and T-PAKE in the password only model,” in International Conference on the Theory and Application of Cryptology and Information Security. Springer, 2014 pp. 233–253

Concluding Notes

If you have any ideas on how to improve or elaborate on this network design for either ZK identity, self-custody, or any other relevant use cases, please reply or reach out.

3 posts - 2 participants

Read full topic

On Attestations, Block Propagation, and Timing Games

By now, proposer timing games are no longer a new phenomenon and have been analyzed, here, here and here.

In the following research piece, I want to show the evolution of proposer timing games and analyze their impact on attesters. Through a case study of the node operators of Lido, Coinbase, and Kiln, we dive deep into block proposal timing and its impact on Ethereum’s consensus.

As of August 2024, the block building market is largely outsourced, with ~90% handled by mevboost block builders. In practice, two builders, Titan Builder and Beaverbuild, produce approximately 80% of all blocks that make it on-chain.

Kiln is among the entities pushing timing games the furthest, delaying block proposals to the 3-3.5 second mark within the slot.

In today’s environment with mevboost, block propagation is primarily handled by relays. Although proposers still propagate the block after receiving it from the relay, relays typically have better network connectivity and can therefore do it faster. However, the timing remains under the control of proposers, who can delay their getHeader calls to engage in timing games.

This chart shows the evolution of timing games. We can see that blocks from Kiln validators appear later and later over time.

This comes with an impact on the network: for blocks proposed by Kiln proposers, the missed/wrong head vote rate is significantly higher:

Previous analysis showed that the longer one waits, the higher the expected number of missed head votes (“80% of attestations seen by the second 5 in the slot”). Kiln proposes blocks very late, causing some attesters to miss them and instead vote for the parent block. Given that there are approximately 32,000 validators assigned to each slot, this results in about 10% of them voting for the wrong block.

Let’s examine the attesting behavior of three large node operators and compare how they respond to blocks proposed at different times within a slot. The chart below illustrates the distribution of correct and timely head votes across the seconds within a slot.

For early blocks, we observe that both Lido and Coinbase display a characteristic “U”-shape in their voting patterns that might be caused by different geo locations or client software. In contrast, Kiln shows a single prominent peak that slightly lags behind the first peaks of Coinbase and Lido. However, for late blocks, Kiln attesters also show the “U”-shape pattern.

When blocks are first seen at the 4-second mark in the p2p network during a slot, most Lido attesters attest up to 2 seconds earlier than most of the Kiln or Coinbase attesters. This pattern doesn’t necessarily suggest that Kiln is executing “individual strategies.” Instead, it could be attributed to running different clients or using different geographical locations.

But who affects whom?

In the following chart, we compare a node operator’s performance over different proposers. A bar above y=1, for example, the green bar at Lido, indicates that Lido attesters miss more head votes for blocks from Kiln proposers. At the same time, Lido attesters do better for Lido blocks. The dashed line at 1 indicates the average share in missed head votes over all entities as proposers. A bar below 1 means the specific entity misses fewer head votes in conjunction with the respective proposer compared to the average.

Importantly, it is expected that each node operator does best with its local blocks. This is expected even without a coordination oracle, simply by co-locating nodes.

To quickly summarize what we see:

• Most node operators are rather stable across different proposers.
• Figment performs significantly worse for Kiln proposers. The same applies to Lido, Kraken, and EtherFi attesters.
• Kiln and Binance are the only entities performing better for Kiln blocks (which are, as a reminder, very late).

Kiln attesters generally do well. Earlier analysis showes that Kiln does a more than good job when it comes to running high-performing validators. Refer to this analysis for further details of Kiln’s attestation performance.

Kiln causes stress. Now, we know that Kiln blocks cause stress to other attesters but not necessarily to Kiln’s attesters.

Explaining how. The “how?” is difficult to respond to at this point. A possible explanation might be that Kiln’s validators are heavily co-located, with many validators running on the same machine, or have very dense peering. Another reason might be coordinated behavior across multiple nodes, either through custom peering/private mesh networks or through another additional communication layer connecting their validators. The latter is regarded as more centralizing as it leverages economies of scale even more.

A similar pattern can be observed when examining the (correct & timely) attestation timing of Lido and Coinbase for the blocks proposed by each respective entity (26.07.2024-03.08.2024).

Interestingly, Kiln develops a “U”-shape distribution ranging from 3.8 \Rightarrow 6.1 for their own late blocks, Lido a peak at 4.2s, and Coinbase a plateau starting at second 4 with a small peak at second 6 in the slot.

“Prevent reorgs of my own proposed blocks”

Let’s shift our focus to reorged blocks. One strategy from the perspective of a node operator might be to never vote for reorging out one’s own block. Simply speaking, “never vote for the parent block as the head if the proposer is me”.

Instead of calling it an entity’s own block, I will use local block in the following.

The following chart shows the percentage of attesters voting for the reorged block vs voting for the parent block. The red part displays the % of all attesters from that entity that voted for a reorged block built by that entity.

Kiln shows outlier behavior. While most node operators’ attesters correctly vote for the parent block rather than the local block, Kiln’s attesters appear to disregard this norm. Over 10% of Kiln attesters attempt to keep the local block on-chain by voting for it. If such strategies are adopted, they might justify the losses from incorrect head votes if they prevent the local block from being reorged. However, these tactics are generally frowned upon within the Ethereum community: “don’t play with consensus”.

The chart uses 365 days of data. Thus, if some sophisticated strategy was implemented during the last year, the red portion would be proportionately smaller.

But how do we feel about any additional level of coordination?

Regarding coordinated attesting, we, as community, seem to accept that validators run on the same node vote for the same checkpoints.

We probably don’t want any additional efforts that cross the boundaries of physical machines to improve coordination across validators. It’s something that everyone can build that goes beyond what the specs describe. Such coordination could have different forms:

• Level 1 - Fall-backs & Static Peering: Have a central fall-back/back-up node for multiple physical machines. This can also be a circuit breaker, some particularly fault-tolerant machine acting as a private relayer for information. Setups with improved peering, private mesh networks, or similar might also fall into this category.
• Level 2 - If-else rules: Have hard-coded rules waiting longer in certain slots. Those would be installed on multiple physical machines, allowing them to “coordinate” based on predefined rules.
• Level 3 - Botnet: Have a centralized oracle that communicates with all validators and delivers the checkpoints to vote for and the timestamp when they should be published.

In my opinion, crossing the line into the latter form of coordination (level 2 and 3) is problematic, and node operators should be held accountable. Finally, there may be a gray area for strategies involving static peering and private mesh networks.

Such setups could be used to run (malicious) strategies such as:

• ensuring to never vote for different checkpoints across multiple physical machines.
• ensuring to never vote for reorging out a block from one’s own proposer.
• coordinating based on the consecutive proposer (honest reorg client (y/n)).
• censoring attestations of a certain party.
• not voting for the blocks of a certain party.
• etc.

When discussing coordination, it’s important to distinguish between two types:

1. Coordinated behavior that occurs when validators are run from the same physical machine.
2. Coordinated behavior that arises from running the same modified client software or relying on the same centralized oracle.

A potential solution to counter sophisticated coordinated validator behavior is EIP-7716: Anti-Correlation Penalties", which proposes to scale penalties with the correlation among validators.

Find the code for this analysis here.

More on that topics

6 posts - 3 participants

Read full topic

By Asim Ahmad and Tahir Mahmood on behalf of KRNL.

1. Abstract

The evolution of the Web3 ecosystem confronts pivotal challenges such as network fragmentation, scalability constraints, cross-chain integration complexities, and security vulnerabilities. To address these issues, we introduce the KRNL Protocol—an orchestration and verification engine that seamlessly integrates permissionless and composable functions across multiple blockchain networks within the Ethereum transaction lifecycle. By transforming both on-chain and off-chain functions into execution shards called “kernels,” KRNL offers a distributed runtime environment that optimizes resource utilization, enhances modularity, and accelerates deployment. This approach not only improves the responsiveness of decentralized applications (dApps) but also reduces their time-to-market. Our proposal positions KRNL as part of the fabric of the Web3 framework.

2. Motivation

The Web3 ecosystem faces several significant challenges, including fragmentation, scalability limitations, cross-chain friction, and security concerns.

Fragmentation: The emergence of numerous Layer 1 and Layer 2 solutions has led to the creation of isolated silos. This fragmentation impedes seamless interaction between applications and smart contracts across different environments, undermining the foundational principle of composability in decentralized systems.

Scalability Constraints: Ethereum grapples with network congestion and high gas fees. These scalability issues deter the widespread adoption of dApps and erode user experience.

Cross-Chain Friction: Facilitating interoperability between Ethereum and other blockchains often demands intricate integrations. The absence of standardized cross-chain communication protocols exacerbates development complexities, stifling innovation and efficiency.

Security Vulnerabilities: Ensuring transaction integrity, provenance, and security in a decentralized manner remains a challenge. The proliferation of bridges and interoperability solutions introduces novel attack vectors, heightening security risks.

To address these challenges, we reimagine the execution paradigm by introducing the concept of kernels - community-built, permissionless, monetizable, and composable execution shards across Web3. We also introduce the KRNL protocol, an orchestration and verification engine that enables smart contracts to integrate execution shards, enriching the logic and state of traditional smart contract operations without the creation of custom infrastructure. With this proposal, we aim to become an essential tool for the development of cross-chain applications.

3. TL;DR

Execution Sharding refers to the approach of dividing and distributing the execution of smart contracts across multiple blockchain networks, or “shards”, to enhance scalability and efficiency in blockchain systems. Instead of executing every transaction on a single chain, execution sharding allows transactions and smart contract states to be distributed across multiple chains, each handling a portion of the overall workload.

Execution sharding is critical for Ethereum’s scalability. The KRNL Protocol integrates permissionless and composable kernels (execution shards) across multiple networks, seamlessly into the native Ethereum transaction lifecycle.

KRNL manages resources to provide a secure and optimal execution environment for smart contracts. This enables a distributed runtime environment that determines transaction outcome based on selected kernels, operating across different environments. KRNL’s open framework enhances modularity, optimizes resources, ensures stable operations, and accelerates deployment, ultimately improving responsiveness and reducing time to market for applications.

4. Introducing Kernels

Within the KRNL Protocol framework, kernels represent execution shards. These kernels transform both on-chain and off-chain functions into modular units characterized by the following attributes:

• Statelessness: Kernels maintain no intrinsic state, ensuring flexibility and facilitating seamless migration across environments.
• Lightweight Design: To minimize computational overhead, kernels promote efficient execution.
• Resilience: Engineered to withstand operational failures, ensuring reliable performance.
• Independent Deployability: Allowing for deployment across various environments.

The defining features of kernels include:

• Infrastructure Agnosticism: Kernels are not tethered to specific infrastructures; they possess the agility to migrate across environments as necessitated.
• Enhanced Modularity and Composability: By deconstructing applications into discrete kernels, modularity is enhanced, enabling permissionless sharing across multiple applications.
• Accelerated Deployment: Simplifying the deployment process improves responsiveness and reduces time-to-market for applications.

5. Vision

The Pre-Cloud Paradigm

Before cloud computing, developers bore the burden of constructing, operating, and maintaining all requisite programs and services. This paradigm engendered prohibitive costs, scalability constraints, accessibility challenges, and resource limitations. Cloud computing revolutionized this landscape, introducing managed services where back-end infrastructures are handled by cloud providers.

KRNL’s Transformative Potential

KRNL seeks to catalyze a comparable paradigm shift within the Web3 domain—a permissionless Web3 cloud environment built by the community through contributions of monetizable kernels. This vision aligns with the Function as a Service (FaaS) model, reimagined to suit the decentralized and heterogeneous fabric of blockchain ecosystems.

Functions as a Service (FaaS) in the Web3 Context

FaaS is a category of cloud computing services that provide a platform enabling customers to develop, run and manage applications without the complexity of building and maintaining the infrastructure associated with developing and launching an app. Examples of a traditional FaaS include AWS Lambda, Google Cloud Functions, Microsoft Azure Functions, etc.

The conventional FaaS model does not fit well in distributed and heterogeneous blockchain environments, where each blockchain is a silo and not efficient in the context of the whole Web3 ecosystem. To adapt this concept to Web3, it is essential to ensure decentralized registry, management, and execution of kernels.

6. Core Concepts

The Computing Engine

KRNL enhances an Ethereum Remote Procedure Call (RPC) node with a verification and orchestration-enabled computing engine. This engine abstracts the intricacies associated with integrating smart contract interdependencies.

The computing engine creates an application and technology agnostic framework that offers a runtime environment to user applications in a distributed manner. It sits between a transaction initiated on any chain and its propagation into a block, determining a transaction’s outcome based on the kernels selected. This approach allows for flexible, efficient scaling and optimization of distributed applications.

Proof of Provenance (PoP)

PoP validates that prescribed kernels have run successfully before a transaction is executed, ensuring reliability and security of the KRNL Protocol.

The KRNL Protocol achieves this by utilizing various schemes including a decentralized token authority that issues a signature token, ERC-1271, cryptography and proof systems. The implementation requires the application developer to implement a Software Development Kit (SDK) as well as the token authority. PoP works with existing standards within the Ethereum ecosystem, combining multiple schemes to ensure an anti-fragile system.

Decentralized Registry

An Ethereum based registry for activating and monetizing community built kernels. This registry serves as the definitive repository, maintaining critical information about registered kernels, including their pathways, monetization schemes, and other customizable parameters. Core to the design of KRNL is the concept of a two-sided marketplace where kernels are built and monetized, while being utilized by applications across Web3.

7. Architecture

Use Case Scenario

In a hypothetical scenario, a DeFi protocol on Ethereum would like to allow users to trade RWA assets if they are an approved user on Company 1’s RWA platform (and if not, to reject the transaction from this wallet). Say Company 1 has built an RWA platform on Blockchain 2, with dynamic off-chain metadata corresponding to approved users. Additionally, these users need to have an identity score of X as determined by a on-chain DID smart contract on Blockchain 3. In the past, implementing these solutions across various chains would have required multiple complex integrations and in many cases require direct communication with vendors. However, with KRNL, builders now only need to perform a single, one-time permissionless integration.

There is not currently any application layer that facilitates the conditional logic before state changes are executed, and this is generally built ground-up by builders. Ideally, this would be done in a plug-and-play, permissionless manner that would be reproducible by protocols that want to utilize the RWA platform and identifiers from the DID system.

8. Decentralization and Security Considerations

Upholding Decentralization

KRNL leverages the intrinsic decentralization of existing native blockchains. By integrating with a standard Ethereum RPC node, any Ethereum RPC node can function as a KRNL node without interfering with consensus mechanisms of the underlying network. Node operators are incentivized through the accrual of a proportion of fees generated from kernels, fostering a decentralized and participatory ecosystem.

Mitigating Malicious Activities

To preempt and mitigate potential malicious activities, such as replicating KRNL node code to fabricate counterfeit signatures, KRNL employs multiple cryptographic schemes that ensure security by design. The security architecture is flexible, customizable, and predominantly under the control of the dApp developer. This approach ensures that the KRNL Protocol remains permissionless, resilient, and secure.

Explore more in our KRNL Developer Sandbox

Learn more about KRNL

Supporting Research Papers

Decentralized FaaS over Multi-Clouds with Blockchain based Management for Supporting Emerging Applications

DeFaaS is a novel decentralized Function-as-a-Service (FaaS) system proposed to address the limitations of centralized FaaS solutions. This system leverages blockchain technology and decentralized API management to create a distributed FaaS platform that offers improved scalability, flexibility, security, and reliability. DeFaaS is designed to support various distributed computing scenarios beyond FaaS, including decentralized applications (dApps), volunteer computing, and multi-cloud service mesh. The proposed system aims to mitigate issues associated with centralized FaaS, such as vendor lock-in and single points of failure.

Multi-Service Model for Blockchain Networks

Multi-service networks aim to efficiently supply distinct goods within the same infrastructure by relying on a (typically centralized) authority to manage and coordinate their differential delivery at specific prices. In turn, final customers constantly seek to lower costs whilst maximizing quality and reliability. This paper proposes a decentralized business model for multi-service networks using Ethereum blockchain features – gas, transactions, and smart contracts – to execute multiple services at different prices. By employing Ether, to quantify the quality of service and reliability of distinct private Ethereum networks, their model concurrently processes streams of services at different gas prices while differentially delivering reliability and service quality.

Qualified Digital Certificates within Blockchain Networks

This paper examines decentralized digital identities, which use asymmetric cryptography without centralized oversight, focusing on both on-chain (blockchain) and off-chain (self-sovereign) types. Currently, no single wallet manages both types of decentralized identities. To address this, the paper proposes an orchestration solution for a universal wallet that combines both types and validates it using a real-life use case.

1 post - 1 participant

Read full topic

1. In Ethereum 2.0 PoS, the block proposer of the next block is known a certain time (~12s) before she creates the block. It might create an opportunity for attackers to DoS the next proposer who will therefore not create the new block and lose the reward. This might be systematically repeated again. We know that something similar was of concern for Algorand PoS and its VRF-based leader election that avoided this kind of attack.

2. In PBS, the builder reveals the sealed block bid (commitment), and then later reveals the block contents. If the contents are not revealed, the builder will be penalized. So, the attacker already knowing the network address of victim can DoS her and cause severe penalties for not revealing the block on time. This might be systematically repeated again.

My question or point to discuss is how Ethereum protects against this kind of attack?

1 post - 1 participant

Read full topic

We have a solution to resolve the Layer2 MEV onchain trustlessly.
Here is the arch:

1. Users only send their txHash to the L2 chain with some advance charge (to prevent DOS attack)
2. The chain accepts these txHashes, sort them based on the amount of tips, and then make a Tx-Order-commitment and broadcast it to the other chain nodes. Also, user can subscribe this commitment.
3. When users see the order-commitments, they will send their tx-content to the L2 chain and the DA-layers.
4. Chain accepts the tx-content from users, and also fetch txs from DA-layers , pack them according to the previously promised order. If the tx-content does not match the previously tx-hash, chain will put them behind the txs which made order-commitment.
   All promised txs will be sorted before the unpromised txs.
   NOTICE: In this way, the chain may deduct tx-content and pretend not to receive it. To prevent this situation. We have to:
   i. Decentralise chain node.
   ii. Use DA to complete the txs if one node does not accept the txs.

In this case, we call it MEVless protocol, it means you don’t have to trust any group and institution. You do not have to depend on a privacy node, not through MEVA, to protect your transactions from MEV attack. Because all the attackers(besides miners themselves) cannot see your tx-content when it orders. Once the tx-content is packed and executed, it must be packed by the previously commitment, attackers cannot front-run and sandwich attack you.

We have developed some of it and you can see the running effect:

You can see the txHash order-commitment in the above red box and you can try MEV-attacking these txs when they are completed by tx-contents later, then you will find you cannot insert your tx into their order at all.

8 posts - 4 participants

Read full topic

Proof of Service integrity (PoSI) : Trustless measurement of service integrity

TL;Dr

Proof of Service Integrity (PoSI) is a byzantine fault tolerant verification protocol for offchain activities.

It performs three main tasks in a decentralised fashion - deployment of approved service images, measurements of deployed services, and attestation of the integrity of these services in production.

The problem PoSI solves is that offchain services are growing in volume, size and complexity in modern chain architectures, but they are largely centralised and run in trusted environments while handling millions of dollars of transaction flows. This is incompatible with the goals of crypto systems. Permissionless verification of offchain services using PoSI protocol provides a real-time integrated security view for emerging hybrid crypto protocols that have a mix of on-chain and off-chain activities.

Offchain services that are verified by PoSI protocol are called Integrity Verified services (IVS).

Preface

This post builds on the earlier proposal on integrity proofs (Integrity proofs to improve rollup security) with the following main differences:

1. Focus on measuring integrity of any off-chain service, rather than just rollup services
2. Earlier design was TEE-based, current protocol is primarily BFT-based but uses TEEs as a defense-in-depth mechanism.
3. Changes to the architecture

Prelude

Traditional distributed systems monitoring/observability involves collecting and analyzing data in order to gain insights into the functioning, performance, security and health of software systems and applications. It involves systematically observing and tracking various metrics, events, logs and distributed traces to construct a visual representation of a system’s hardware and software performance and health. While there are multiple types of distributed systems monitoring data, one dimension in particular that is not measured in traditional web2 distributed systems is service integrity.

For this post, let’s define service integrity as the following:

1. The correct (authorised and verified) software version has been deployed
2. No unauthorised changes have been made to the deployed software in production.
3. Anyone can permissionlessly verify proof of #1 and #2 for any given service either through data provided over a user interface or API, or through verification of a zero-knowledge proof.

In internet/online systems (web2), services integrity (particularly #1 and #2) is the responsibility of the organisation or entity that centrally owns and manages the distributed service, aka trusted deployments. As a consequence, #3 is simply not possible.

When we talk about web3 systems, service integrity becomes paramount. Services are deployed in untrusted environments managed by operators that we do not know or have legal contracts with.

The way this problem has been solved in blockchain-based systems (Proof-of-stake in particular) is through a carefully designed set of incentives to encourage external operators to run the distributed software with desired behaviours, coupled with a clever mechanism for the distributed network to reach a consensus such that if an operator that is part of the consensus set is detected to perform any malicious action, they can be financially penalised (through onchain mechanisms or social governance).

This worked reasonably in the early days of evolution of onchain systems where all the logic for onchain protocols were on smart contracts on a single chain, which was invoked from offchain clients. Censorship resistance was largely handled by allowing anyone to run the Json-RPC nodes (which are the user transaction entry points) that communicate with the other distributed network nodes over P2P protocols. This ensured eventual censorship-resistance.

Evolution of crypto protocol architectures

Recent developments in blockchain systems have seen an explosion in the number of layer-1 and layer-2 chains, and the rise of modular architectures with innovations in application protocols, core infrastructure, scaling and interop solutions, developer & user tools. These innovations are aimed at solving problems with scaling throughput, reducing latency, lowering transaction costs, offering greater sovereignty to builders over design choices, solving for both synchronous and async interoperability, unifying liquidity, mev optimisation, and improving user experience in crypto.

These developments have resulted in increased complexity and sophistication of onchain protocols involving a mix of smart-contract logic and offchain logic. Emerging use cases such as cross-chain swaps involve a mix of smart contract and offchain logic on both the source and destination chains.

Let’s look at a few of the hybrid onchain-offchain architectures in popular crypto protocols.

Fig A shows onchain logic on a single chain encoded as smart contracts. The onchain logic is accessed from a regular web or mobile client application through RPC calls.

Fig B shows an example of crypto protocol containing a mix of onchain smart contract logic on a single chain and offchain component attached to it. The offchain component typically either supplies data from an online system (eg price feeds through oracle) or performs compute-heavy operations on behalf of the smart contract (eg co-processor). The offchain component can also be a regular web backend of the dapp, if the app developer chooses to keep a portion of the business logic offchain (which is not uncommon in most modern dapps).

Fig C shows an example of a cross-chain transaction that involves two chains - source and destination chain (e.g., cross-chain swaps or bridging). Here, smart contract logic is present on both the chains, and there are corresponding offchain components.

The main challenge that is being addressed in this post is that a big proportion of the off-chain components that are part of these hybrid onchain-offchain crypto protocols are run in trusted environments. This is incompatible with the main goals of crypto protocols which are trustlessness, censorship resistance and permission-less participation and verifiability.

While the onchain components (aka smart contracts) are secured by consensus, economic incentives and permissionless verification, the same cannot be said about offchain services whose actions cannot be attributed onchain. These services are, in most cases, centralised, owned and run by trusted entities, but play critical role in the overall transaction workflows. They are vulnerable to censorship, tampering and other kinds of attacks. Note that only the on-chain logic of the crypto protocols is secured by the blockchain consensus, not the supporting off-chain infrastructure and services which have varying levels of trust assumptions. In some cases, it is not even possible to detect malicious actions performed by such offchain components (non-attributable faults).

Figure 2 shows a non-exhaustive list of popular categories of offchain services that are an integral part of many crypto protocols.

What are the types of risks to crypto protocols with such centralised offchain services?

Insider Threats: Employees or contractors within the service development team or the cloud platform provider may misuse their privileged access.
Unauthorized Modifications: Malicious actors might attempt to alter the service code logic or configuration without detection, leading to unintended consequences inconsistent with the protocol goals.
Censorship Risks: In case of offchain services, bad actors might attempt to censor certain transactions or user interactions.
Data and Fund Security: There’s a risk of unauthorized access to sensitive data or funds managed by the service. e.g. a dapp backend managing an embedded wallet may view/steal user wallet keys.

We need a decentralised verification protocol

Hence, a critical requirement for the success of these modular hybrid onchain-offchain architectures is the ability to prove offchain service integrity at scale in a decentralised trustless manner, i.e. a Byzantine fault tolerant service integrity verification system.

In this post, we present Proof of Service Integrity (PoSI), a verification protocol that performs three main tasks - deployment of publicly-identifiable code images, measurement of the correctness of code deployed periodically, and attestation of service integrity in the production environment. These correspond respectively to the properties of correctness, integrity and verifiability for the monitored services. Figure 3 shows the key desired properties and relationships between the PoSI nodes that are part of the verification network, and the monitored services.

The PoSI nodes that implement the verification protocol itself satisfy the following properties: 1) Trustless: Service integrity measurements are secure against byzantine attacks by collaborations among the monitoring services and the monitored services. 2) Tamper-proof: The service monitoring service while verifying the tamper-resistance of the monitored services, is itself tamper-resistant 3) Open: The protocol allows anyone to register and provide measurement data , by using cryptographic primitives to ensure that a subset of actors cannot maliciously modify results in their favour.

A formal security model allows us to establish guarantees of accurate service measurements in the presence of malicious actors. The security guarantees of the PoSI protocol are composable with the onchain state commitments on blockchain ledgers to provide a comprehensive view of protocol security which is not possible by just focusing on smart-contract & consensus-based security.

Proof of Service Integrity (PoSI) protocol overview

PoSI enables verifiable service integrity through the following:

Authenticated Deployment: PoSI ensures that only authorized and verified code is deployed to the production environment. This prevents the introduction of malicious or unauthorized code during the deployment process.

Continuous Integrity Monitoring: Once deployed, PoSI nodes continuously monitor the service to detect any unauthorized modifications or tampering. Any discrepancies between the running service and its expected state are immediately detected and reported.

Integrity Attestation: Users or dApps can request integrity proofs for any PoSI-enabled service through a permissionless, public interface. Two types of integrity checks can be done on a given service - measurements-based and proof-based. Measurements-based checks involve deriving service integrity from the onchain measurements for the service. Proof-based checks can be done by requesting a SNARK proof of integrity for the service, which can then be verified either on-chain (SNARK verification) or off-chain (in a web or mobile app).

Services that are verified by PoSI protocol are called Integrity-verified services (IVS).

Architecture workflows

PoSI protocol involves the following three workflows:

1. Service developer workflow
2. Operator workflow
3. Verification workflow

Figure 5 shows an overview of the key actors and actions in the protocol.

The architecture of PoSI involves the following components and actors:

1. Human/Organisational actors:

Service developer: This refers to the developer and owner of the distributed software service. The service developer is the main ‘customer’ for the integrity-verified service, and is the person or entity that is ready to pay a fee to have their service integrity-verified.

Operator: This refers to the provider of the computational infrastructure. The service developer can themselves choose to be the operator by deploying the IVS on a cloud account controlled by them or they can choose to deploy their service on an external operator’s VM through a DePIN service.

2. PoSI Platform:

PoSI platform onchain: This contains the core smart contracts of the protocol.

PoSI Offchain: This comprises core offchain services that are part of the protocol.

3. Applications/ Other chains:

Application: A web or mobile application that verifies the proof for an IVS.

Other chain: Any other chain can verify the zk proofs generated by the PoSI protocol.

Service developer workflow

1. Service developer builds the service and registers the service image in a public repository.
2. Service developer registers the service image along with other service metadata with the PoSI onchain smart contracts. They also deposit rewards amount, along with service level expectations (e.g. frequency of measurements).
3. Service developer can trigger the PoSI smart contract to trigger the service deployment either on their self-hosted VM, their cloud VM or on a DePIN VM.
4. The PoSI protocol pays out the rewards to the operators based on the tasks performed by them, from the service developer’s account.

Operator workflow

1. Operator registers their VM with the PoSI registration service. The operator can choose to perform two kinds of tasks - host service images, or host the PoSI host program that performs measurements on other services. For the former, any regular VM of the configuration required by service developers would be accepted. For the latter, TEE-based VMs will be required.
2. Note that service developer can choose to deploy their service on their own VM, in which case they need to register it like other external operators. For TEE-based VMs, the quote has to be generated by the operator and submitted to the registration service along with in-enclave generated public key.
3. Operator stakes the minimum specified tokens as part of registration. If the service developer hosts the service on their own VM, this step is not required.
4. The PoSI registration service verifies the registered VM and registers it with the PoSI onchain contract. The PoSi registration service itself runs within a TEE enclave.
5. When the service developer triggers deployment of a service, the PoSI host program retrieves the registered service image from public repository and deploys the service on the service developer (or external operator’s VM based on the configuration).
6. If an operator has registered to host the PoSI protocol, the PoSI master deploys the PoSI host program on the operator’s VM. This enables the operator to then perform service measurements on other services.
7. Based on the specification of the service developer, the operator set is established for verifying that service, which runs the consensus mechanism to determine the final service measurements. The votes of all operators in the operator set are aggregated and recorded onchain, along with the measurements.
8. At periodic intervals, measurements of the performance of the verious operators are taken by the PoSI measurement service, and rewards are computed for the operators. Any incorrect measurements attributable to any of the operators in operator set is penalized through slashing of their stake, in a manner defined in the PoSI protocol.

Verification workflow

1. Any web or mobile application can ask the PoSI protocol servers for attestation of any particular service. The PoSI protocol returns the proof to the web/mobile application.
2. Two kinds of proofs can be requested from the PoSI protocol for a service: state proofs and SNARK-proofs. State proofs simple return the onchain state of a service computed from the measurements submitted by operators. SNARK proofs that are returned by the PoSI protocol can be verified either off-chain within the web/mobile application, or submitted to another on-chain smart contract for verification.

An integrated view of the various workflows for the PoSI protocol is shown in figure.

Note: Figure 6 shows only a single host program taking the service measurements (for reducing clutter in diagram), but it can be visualised as a set of nodes that participate and arrive at a consensus before posting the measurements on-chain.

Conclusion

Trustfree measurement of offchain service integrity is an unsolved problem in decentralised networks. Proof of Service Integrity (PoSI) addresses this core requirement by providing a secure, byzantine resistant verification layer for offchain services while allowing open participation for operators and service developers to benefit from the protocol. All components of the protocol can be operated by community-run protocol nodes controlled by the onchain protocol smart contracts. PoSI incorporates a layered security model that includes consensus-based, hardware-based and crypto-economic security. PoSI requires the participating offchain services to have open source code, a publicly verifiable service image, reproducible build process and dockerized deployment.

FAQ

What kind of services can benefit from the PoSI protocol?

Any in-protocol or out-of-protocol offchain service can benefit from PoSI protocol. A non-exhaustive list of offchain services was mentioned earlier in the post, and is reproduced here:

What are the alternative architectures available to secure offchain services?

For offchain services to transition from trusted to trust-minimised / trustless architectures, here is a comparison of the various design approaches.

Credits

The concept and design for PoSI protocol and Integrity-verified services was initially developed as a collaboration between @peshwar9 and @mohsinriaz17 with contribution from several others to refine and enhance it.

1 post - 1 participant

Read full topic

Introduction

This writeup presents an efficient method for distributing N data elements across n nodes using Reed-Solomon (RS) encoding, specifically designed for blockchain sharded storage solutions. We address the challenge of scaling blockchain storage by introducing techniques that achieve O(N log n) decoding complexity, where N is the total amount of data and n is the number of nodes.

A naive approach would be to simply blow up the data from N to bN, where b is the blowup factor. However, this would result in O(N log N) decoding complexity. Our method, by representing data as a table and creating data shards, achieves O(N log n) decoding complexity, which is significantly faster.

It’s crucial to note that we don’t need to apply RS codes to all data together. This is because a node can only go offline as a whole - there can’t be a situation where two nodes lose half of their data each, requiring RS codes to recover the data. A node either loses all its data or provides it entirely.

While our method doesn’t significantly improve the speed of calculating polynomial commitments (which remains O(N log N) for FRI), it greatly optimizes the data encoding-decoding procedure.

Naive approach

Our approach

Notation and Definitions

Before proceeding with the detailed description of our method, let’s define the key terms and symbols used throughout this writeup:

• N: Total amount of data elements
• n: Number of nodes in the network
• k: Minimum number of nodes required to recover the original data
• b: Blowup factor, defined as b = n/k
• m: Number of rows in the data table representation

2-Adicity Fields Case

We consider a 2-adic prime field, specifically the BabyBear field with prime p = 15 * 2^27 + 1.

Let’s consider we have a vector {a_i} of N elements of field F_p. We want to distribute this vector among n servers, such that any k servers can recover the original vector. We use Reed-Solomon codes to achieve this.

We represent the vector {a_i} as a table {a_{ij}} of size m \times k with m rows and k columns.

We define a bivariate polynomial f(x,y) to represent our data:

f(x,y) = \sum\limits_{ij} a_{ij} L_i(x) \lambda_j(y)

where L_i(x) is a Lagrange polynomial of degree m-1 and \lambda_j(y) is a Lagrange polynomial of degree k-1.

After performing FFT over each row of the table, f(x,y) takes the following form:

f(x,y) = \sum\limits_{ij} b_{ij} L_i(x) y^j = \sum\limits_{j} f_j(x) y^j

where f_j(x)=\sum\limits_{i} b_{ij} L_i(x) is a polynomial of degree m-1.

Each node should receive a unique linear combination of the columns of the table. Then we can recover the original vector by solving a system of linear equations. Let’s represent the data shard as f(x,y_0), where y_0 is a fixed value for each shard.

f(x,y) - f(x,y_0) = \sum\limits_{j} (y^j - y_0^j) f_j(x) = (y-y_0) q(x,y)

where q(x,y) is a quotient polynomial.

We make the substitution y=x^m without loss of any inner polynomial structure. This substitution effectively concatenates all columns of the table, one after another, which is convenient for creating a polynomial commitment.

After the substitution, we get the following polynomial equation to check that the shard is a valid part of the original data:

f(x,x^m) - f(x, y_0) = (x^m - y_0) q(x,x^m)

Circle Fields Case

We now consider the M31 field with p = 2^32 - 1. [HLP24] proposed a method called CFFT (Circular Fast Fourier Transform), which is analogous to FFT but works with polynomials defined on a complex circle.

In the circle representation, the polynomial takes the form f(x,y)=\Re(f(z)), where |z|=1.

Due to the circle constraint |z|^2 = x^2 + y^2 = 1, the polynomial can be represented as:

f(x,y) = f_0(x) + y f_1(x)

where f_0(x) and f_1(x) are polynomials of degree N/2-1. Note that we have two polynomials of this degree, providing sufficient degrees of freedom.

Let’s represent the data vector {a_i} as a table {a_{ij}} of size m \times k with m rows and k columns. We perform circle FFT (CFFT) on each row of the table, resulting in m vectors of size n.

f(x,y,u,v) = \sum\limits_{ij} a_{ij} L_i(x,y) \lambda_j(u,v)

It’s important to note that the function f(x,y,u,v) is defined on a torus: x^2+y^2=1, u^2+v^2=1.

Let’s consider f(x,y,u,v) as v-even function. This approach is not useful directly for SNARKs, because then we have even constraint on function values and next row could be dependent on the previous one. However, it’s useful for data distribution.

Then

f(x,y,u,v) = f(x,y,u) = \sum\limits_{ij} a_{ij} L_i(x,y) \Lambda_j(u) ,
where \Lambda_j(u) is even Lagrange basis on the circle.

After applying CFFT over each row, we get:

f(x,y,u) = \sum\limits_{ij} b_{ij} L_i(x,y) u^j = \sum\limits_{j} f_j(x,y) u^j

where f_j(x,y)=\sum\limits_{i} b_{i} L_i(x,y)=f_{j,0}(x) + y f_{j,1}(x) and each polynomial is (m/2-1)-ordered.

Let’s consider f(x,y,u_0) as a data shard, where u_0 is a fixed value for each shard.

f(x,y,u) - f(x,y,u_0) = \sum\limits_{j} (u^j - u_0^j) f_j(x,y) = (u-u_0) q(x,y,u)

where q(x,y,u) is a quotient polynomial.

We make the substitution u=x^{m/2} in f(x,y,u). This substitution does not result in information loss because f_j(x,y)=f_{j,0}(x) + y f_{j,1}(x), where the degrees of f_{j,0}(x) and f_{j,1}(x) are m/2-1. The resulting polynomial f(x,y,x^{m/2}) maintains the structure f_0(x) + y f_1(x) and remains defined on a circle, albeit with each one-dimensional component now of degree N/2-1. This substitution effectively concatenates all columns of the table, similar to the 2-adicity case.

After the substitution, we get the following polynomial equation to check that the shard is a valid part of the original data:

f(x,y,x^{m/2}) - f(x,y,u_0) = (x^{m/2}-u_0)q(x,y,x^{m/2})

Applications

Recovering the source data

Any k shards are enough to recover the original data.

f(x,y,u) = \sum\limits_{j} c_{ij} L_i(x,y) \mu(u),

where \{\mu_i(u)\} is a Lagrange polynomial basis on the evaluation domain H=\{u_i\}, and u_i are fixed values for each shard.

\mu_i(u) = d_i Z_{H}(u)/(u-u_i),
where Z_{H}(u) is a polynomial that is zero at all points of H, d_i is a normalization factor, so

\mu_i(u) = \begin{cases} 1, & u = u_i \\ 0 & u \neq u_i \end{cases}

The source values could be computed as
a_{ij} = f(g^i.x, g^i.y, h^j.x)

Polynomial storing

In some cases, we want to store something directly related to the polynomial commitment of f instead of a_{ij}. This is important for zk applications, like rollups.

Due to the inner structure of coefficient representation, we can represent g(x,y) as f(x,y,x^{m/2}). That means that we can store rollup block data as a set of shards, keeping the source polynomial structure, keeping the source commitment. Then a_{ij} will be some kind of intermediate representation of the committed data.

Algorithm description

def get_shards_and_commitments(data: List[M31], m:int, n:int, k:int, cd:Domain, rd:Domain, xrd:Domain)
    # data is a list of N elements
    # m is the number of rows in the table
    # n is the number of nodes
    # k is the number of nodes required to recover the original data
    # cd is the evaluation domain for the columns
    # rd is the evaluation domain for the rows
    # xrd is evaluation domain for the shards (blown up rows)
    # Returns polynomial commitments and prover data for all the data and shards
    
    # create a table of size m x k, fulfilled row by row
    table = create_table(data, m, k)
    
    # perform cfft on each row of the table
    for row in table:
        row[:] = cfft(row, rd)
    
    # create shards
    shards = [icfft(fit_to_domain_with_zeros(row, rd, xrd), xrd) for row in table]
    
    # convert to col-ordered table
    shards = to_col_ordered(shards)

    # convert table to col_ordered
    table = to_col_ordered(table)

    # compute monomial representation of $f(x,y,x^{m/2})$
    f = concat([cfft(col, cd) for col in table])

    return pcs_monomial_repr(f), [pcs(shard) for shard in shards]

Distributing the data over a cluster of nodes

In practice, the client should deliver the data to n nodes, and the total amount of data is bN. However, for big files, it could be inefficient due to the client’s limited bandwidth.

Instead of this client-centralized approach, b nodes could deliver N \cdot (1-1/k) total data to k-1 nodes. There is no bottleneck at the client side (the client sends just N data to one node), but total network data bandwidth is b N \cdot (2-1/k) \approx 2bN.

There is no valuable computational overhead to compute the shards vectors because with fft or cfft each node can perform a unique coset shift instead of blowup (and the sum of all shifted evaluation domains is the evaluation domain for the blowup).

Conclusion

We have extended our method of data representation to the M31 field, providing a robust framework for efficient data distribution in blockchain storage. By representing data as a table and using FFT/CFFT techniques, we achieve O(N log n) decoding complexity, significantly optimizing the data encoding-decoding procedure. This approach is particularly valuable in blockchain systems where nodes can only fail as a whole, and efficient data recovery is crucial.

While the complexity of polynomial commitment calculations remains O(N log N) for FRI, our method provides substantial benefits in the overall data handling process, making it a promising solution for scalable blockchain storage.

References

HLP24

1 post - 1 participant

Read full topic

Aligning DAO contributions with objectives

In this post, we’re approaching how to align DAO contributions in a setting where a clear goal is already defined.

We will define an Objective Alignment Engine (OAE) as a class of mechanisms that fulfill this objective. We aim to define the contour of such mechanisms so that they optimize resource allocation and provide economic guarantees on the efficacy of incentives.

A more complete description along with more concrete examples is available at [r.ag.oae] Objective Alignment Engine.

Motivation

Suppose a DAO where governance contributors are compensated based on a simple rule, like “the top 10 delegates by total votes delegates are paid $10k / month”. As protocol designers, this sounds suboptimal as we have no guarantees that the treasury is spent on the delegates who produce the most useful contributions to governance (e.g. produce the most complete proposals, or vote most consistently). Also, any such rules-based process inevitably becomes gameable under Goodhart’s law.

We’d prefer that contributions were picked individually and reward contributors based on how aligned these contributions are with the overarching goals of the network (e.g., how much are such contributions participating in growth? or decentralization?).

Importantly, we’d also prefer that there is an objective notion of alignment, enabling a mechanism that relies not only on individual preferences but as much as possible on eliciting information (as suggested in this post on mixing auctions and futarchy).

Background

On-chain protocols often struggle to align contributor incentives with network goals. While blockchains are designed to optimize resource spending for security, producing alignment with agreed-upon goals is typically left to external governance systems. OAE mechanisms bring contributions and incentives within the purview of the protocol designer.

This approach aligns with the “skin in the game” and futarchy-like solutions suggested in Moving beyond coin voting governance. We’ll rely on the notion that there is a jury that is incentivized to produce a good judgment of whether contributions are aligned and scale this with additional mechanisms.

Assumptions: objective definition

A central assumption that we take is that the DAO has a clearly defined objective. While this is theoretically difficult to achieve in a decentralized setting, most protocol values and visions are set initially by the core team and steered by a Foundation.

For example, Ethereum focuses today on Scalability, Security, and Sustainability, whereas Optimism has the Superchain vision.

In the rest of this post, we assume an existing process produces a clear definition of an objective o (hence, the Objective part of the Alignment Engine).

The existence of such an objective enables designing mechanisms that rely only on eliciting information from participants, namely whether a contribution is aligned or not with the objective.

Alignment engine

Jury

Once an objective is defined, we want to set up a jury that can review any contribution and evaluate how aligned it is with the objective. This is the central part of this design.

The main function of the jury is to produce ratings “aligned” / “misaligned” on contributions that are produced on the protocol.

To produce alignment within the jury itself, we rely on mechanisms that incentivize truthful reporting but don’t rely on verifiable outcomes (like, BTC/USD quote). Possible such mechanisms are SchellingCoin or self-resolving prediction markets for unverifiable outcomes (Srinivasan et al, 2023).

To enable incentivization and notably negative rewards, we expect jurors to stake tokens ($ALIGN) and receive token emissions as rewards.

Dispute resolution

Here we assume that most contributions can be unequivocally qualified as “aligned” or “misaligned” (ie there is a clear way to rate most contributions, as long as o is well defined).

But equivocal cases will inevitably appear. When a contestable result is produced, a dispute resolution mechanism needs to be enforced (either an external one like a Kleros court or an Augur-style ALIGN token fork).

Calibration

In general, a juror can be an agent making use of any tools available, including AI and prediction markets, to produce the best evaluations. But this leaves open the question of how to incentivize jurors to get better at their jobs so the jury doesn’t degenerate into a static committee.

If part of the contributions have a ground truth to which their ratings can be compared (e.g. growth contributions that aim at increasing a key metric like TVL for a DeFi protocol or fees for an L2), jurors can be rewarded accordingly. This way, the mechanism can still leverage objective outcomes to improve its accuracy (or be calibrated).

Scaling

Armed with such a jury, DAO contributions can theoretically be evaluated. To handle large numbers of contributions, two scaling options are available:

• Prediction markets: bettors predict jury decisions, creating “Aligned” and “Misaligned” tokens.
• Peer prediction: raters evaluate contributions, with a small percentage reviewed by the jury.

Spam protection through staked curation or auctions ensures only valuable contributions are evaluated.

Rewards distribution

With contribution evaluation in place, the last bit is to distribute contribution rewards to incentivize the most aligned contributions to be produced in the future.

Aligned contributions receive rewards from treasury or token emissions, proportional to their alignment rating. Highly aligned contributions may be automatically implemented in proposal-like scenarios

This produces a positive feedback loop where:

1. Better-aligned contributions receive more rewards
2. This incentivizes more aligned contributions in the future
3. The protocol becomes more resistant to misaligned or captured governance over time.

Attacks

Some potential limitations and related attacks include:

1. Equivocal objective definition. Attackers may exploit ambiguous objectives to reward misaligned contributions. This can be mitigated by updating the objective when the DAO observes that equivocation happens.
2. Jurors collusion and bribing. This can be countered with staking mechanisms, reputation systems, random juror selection, or shielded voting.
3. Peer prediction and prediction markets manipulation. Usual caveats and mitigations apply.

Questions

Such OAE mechanisms rely on the existence of an objective o. We haven’t answered how such an objective can be defined in a general setting. There is an argument that leaving it to regular token-voting just pushes the problem around and the overall mechanism inherits some of the issues of both sub-mechanisms. However, it appears that splitting the problem in two has benefits, as, once an objective is defined, more deterministic outcomes can be achieved through mechanism design.

Also, other kinds of mechanisms can be devised that rely on subjective evaluations. Including subjective evaluations might render objective definition superfluous. But relying on a jury whose jurors input their own preferences leaves the question open of how the jury achieves legitimacy. A solution would be to rely on a measure of juror reputation, as pioneered by Backfeed.

2 posts - 2 participants

Read full topic

This article was prepared by James A. Henderson from =nil; Foundation

tl;dr

Ethereum’s design has moved away from state sharding; however, L2 architectures like zkSharding provide a unified protocol in which L2 dApps are composable yet scalable via state sharding, avoiding the need for state fragmentation emerging across distinct L2s. However, sharded systems are not without challenges. In particular, state sharding amplifies MEV exploitation and censorship problems that exist in non-sharded blockchains.

We propose a shardDAG architecture for state sharded blockchains or multi-chain systems, combining protocol rules, rewards and penalties that constrain transaction exploitation [[1904.05234] Flash Boys 2.0: Frontrunning, Transaction Reordering, and Consensus Instability in Decentralized Exchanges] and external influences like regulatory censorship [https://www.mevwatch.info/, U.S. Treasury Sanctions Notorious Virtual Currency Mixer Tornado Cash | U.S. Department of the Treasury]. Constraints on exploitation and censorship are achieved using a DAG architecture that links shard blocks to each other. The DAG provides an enforceable order in which cross-shard transactions must be processed by each shard, thereby constraining manipulation of transaction processing order.

Motivation

State sharded blockchains inherit magnified MEV exploitation and censorship problems that exist in non-sharded blockchains because transaction completion can require block proposers in many distinct shards, and each block proposer could exploit or censor transactions. Further, more severe transaction exploits are possible via inserting other exploitative transactions in intermediate blocks that occur between starting and finishing transaction processing.

To understand this, the example below demonstrates a simple exploit scenario.

Exploit Example

Figure 1: Two shard chains. Blocks 0 and 1 of shard A each contain cross-shard transactions t and u respectively, whose destinations are shard B. Suppose t can be exploited if in shard B u is processed earlier than t. Then the system is dangerous for t’s user without enforceable ordering rules that ensure t must be processed before u in shard B.

Why Cross-Shard Transaction Data Availability Matters

Punishment for censoring a cross-shard transaction (CST), or processing in an incorrect, exploitative order can only be enforced provided that

i) It can be established that all the required data was available to the shard, and

ii) The shard subsequently failed to process the data correctly.

Therefore, a mechanism is required for establishing verifiable cross-shard (or cross-chain, or cross-rollup) transaction data availability. The broad steps in achieving this are illustrated in Fig. 2. Preventing exploitation requires enforceable rules for ordering the processing of transactions and CSTs; however, enforcing processing order requires that each shard receives the CSTs that it is required to process. To be able to receive CSTs, that CST data must be available. Thus, constraining exploitation rests upon ensuring CST data availability.

Figure 2: Goal: ShardDAG ordering aims to constrain manipulation, exploitation and censorship of transactions and cross-shard transactions. Step 3: These constraints require enforceable protocol rules for ordering the processing of transactions and cross-shard transactions. Step 2: Fairly enforcing ordering rules requires on-chain acknowledgement of receipt of cross-shard transactions. Step 1: Receipt of cross-shard transactions requires cross-shard transaction data availability.

Step 3. A Preview: How DAGs Provide Order

Our solution to the transaction and cross-shard transaction ordering problem involves linking shard chains into a shard directed acyclic graph or shardDAG, and then ordering processing according to the partial order specified within shard block subgraphs.

ShardDAG ordering is previewed in Fig. 3. The distinct shard chains are connected to form a shardDAG, providing an enforceable ordering of cross-shard transactions amongst the shard chains. Unlike in Fig. 1, in Fig. 3’s shardDAG, an exploitative CST in a later block cannot be processed before a CST in an earlier block.

Figure 3: Unlike the distinct shard chains in Fig. 1, the shardDAG (top) depicted here defines a partial ordering of shard blocks that fall under any particular block (here shard B block 2) and the cross-shard transactions that the blocks contain. (Middle) A Hasse diagram can be constructed to visualise a partial ordering of the shard blocks (for clarity lines connecting blocks have not been included). The shardDAG is topologically sorted (bottom) to produce a block containing an ordered set of transactions and CSTs. In general many topological sorts are possible, the block builder selects one, likely based on MEV.

A ShardDAG for Data Availability

To establish cross-shard transaction data availability, the simple set of shard chains in Fig. 1 is extended to become a shardDAG that is crafted to incentivize data sharing. In this system all validators participate in a synchronization chain which aggregates and finalises state updates from shards that are each operated by distinct subsets of the total validator set. Transaction and CST processing is performed within shards only, hence the synchronization chain is not a processing bottleneck. Here the details of the synchronization chain are restricted to its involvement in the shardDAG—the broader function of the synchronization chain in the sharded system is beyond the scope of this post.

To form a shardDAG, shard blocks include links to other shard blocks in the form of:

• a hash to the previous shard block in the same shard, as in a typical blockchain,
• a set of hashes to other shards blocks in other shards,
• a hash to a (valid) synchronization block, equal to or later than the most recent synchronization block already used by prior shard blocks that are included in the subgraph.

The formation of a shardDAG is illustrated in Fig. 4, where for clarity only edges in the subgraph of the white block are shown. The thick arrows are the white block’s hashes to other blocks.

The following is a central concept in the function of the shardDAG.

When a shard A creates a shard block that includes the hash h of another shard block or synchronization block, this inclusion acts as an acknowledgement that shard A has received the block headers and outboxes of cross-shard transactions for h and h’s entire subgraph in the shardDAG.

Figure 4: Illustration of the white block’s subgraph in the shard DAG. The white block’s header contains a list of hashes to other shard blocks (thick white arrows), and well as a single hash to a synchronization block (thick grey arrow). Thin grey edges trace the subgraph of the white block, beyond the blocks explicitly included in its header.

Step 2. Enforcing CST Receipt

Enforcing CST Receipt via Shard Chains

To enforce shards to continually acknowledge receipt of new shard block data, the protocol specifies conditions on block validity. Suppose we have a shard block b_i and b_i’s prior shard block b_{i-1} in the same shard as b_i.

• [PARENT CONDITION]: For b_i to be a valid shard block, the graph difference of b_i’s subgraph minus b_{i-1}’s subgraph must contain shard blocks created by more than F>1 shards, where F is a system parameter controlling the branching of the DAG.

Example:

In Fig. 4, the subgraph of the white shard A block only contains two blocks that are not in the subgraph of the previous shard A block, i.e. the white block itself, and the middle shard B block. If in this example F=1, then the white block is valid; however, if F>1 then the white block is invalid.

Enforcing CST Receipt Via the Synchronization Chain

The parent condition enforces receipt of CSTs, but does not guarantee that each CST reaches its destination so that transactions complete. Without additional rules it is possible (though unlikely) for sets of shards to create shard blocks whose subgraphs do not span all shards and therefore do not acknowledge receipt of CSTs from all shards, as illustrated in Fig. 6.

Figure 6: Despite the parent condition for valid shard blocks, it is possible (though unlikely) for shard subgraphs to not acknowledge receipt of CSTs from some other shards via shard block edges, indicated by the vertical dashed line. However, the synchronization parent condition eventually forces all shards to acknowledge all CSTs via synchronization block edges. Here the synchronization parent condition forces shard 4 to acknowledge receipt of the red CST (via the red edges) and therefore process it, because the dashed blue edge exceeds the limit (here S=2) of consecutive synchronization block hashes. For clarity only the subset of synchronization blocks edges that are relevant to illustrating the above point are shown.

This is unlikely to occur in the shardDAG; however, the synchronization chain is used to ensure that it cannot occur via a further block validity condition:

• [SYNCHRONIZATION PARENT CONDITION]: A valid shard block b cannot have more than S prior blocks from the same shard using the same synchronization block hash.

The value of S should be chosen depending on the ratio of rates of synchronization block to shard block creation. It is expected that synchronization blocks will be produced at a slower rate compared to shard blocks.

A malicious shard can only produce S shard blocks before being forced to acknowledge receipt of new shard blocks via the synchronization chain. In Fig. 5, the red CST shard block will eventually be included in a synchronization block, in a worst case scenario waiting until a shard 1 validator becomes the synchronization block proposer. Thus, eventually all shards will acknowledge receiving the red CST, including the red CST’s destination shard, as indicated by the red arrows. The dashed blue arrow indicates that shard 4 block 3 would be invalid if it used this hash because more than S (here 2) consecutive shard blocks would hash to the same synchronization block.

In this way, economically motivated validators (and especially synchronization block proposers) are motivated to share data so that finality can be reached and economic rewards can be distributed.

Step 1. Enforcing CST Data Availability Via DAG Edges Between Shards

While the parent, and synchronization parent conditions force shards to acknowledge receipt of data, these rules do not force shards to distribute shard block data and establish data availability. Thus, the protocol specifies a rule on shard block finality to align data availability with economic incentives.

• [CHILD CONDITION]: For a shard block b to be finalised within the synchronization chain, within the subgraph of any synchronization block, b must have child shard blocks created by more than F shards.

When a block satisfies the child condition its CSTs have been acknowledged as received by more than F other shards and the shard has therefore distributed its CST data.

The child condition is illustrated in Fig. 5. For a shard block to acquire child shard blocks, other (honest) shards must first receive its subgraph data. Thus, shards are economically incentivised to possess and distribute data in their subgraphs.

Figure 5: Illustration of the child condition for the subgraph of the upper left synchronization block. In this example F=2. The white block in finalised because it has child shard blocks from three shards, indicated by thick white arrows. In contrast, the bottom right shard block is not finalised because it only has one child shard block indicated by the thick grey arrow.

Step 3. An Enforceable DAG Partial Order of Transaction and CST Processing

The shardDAG provides a verifiable, enforceable ordering of transactions and CSTs, which constrains exploits and guarantees (eventual) transaction processing. Transactions and cross-shard transactions must be processed in an order consistent with the partial order of the shard blocks that they are each created in.

Suppose that shard B creates a new shard block b. As illustrated in Fig.3, the the steps involved in ordering the processing of CSTs and transactions are:

1. First b’s hashes (DAG edges) to other shard blocks and a synchronization block are chosen. Hashes are only chosen if corresponding subgraph CST data is available, otherwise correct ordering cannot be known and penalties may ensue.
2. The protocol rules described earlier require that the validator creating and proposing b has all the CST data from b’s subgraph, call these T. The set of pending CSTs P whose destination is shard B, and which have not already been processed in an existing shard B block are extracted from T and any new transactions are added to P.
3. The set of pending transactions and CSTs, P are (partially) ordered according to the shardDAG ordering of the shard blocks that they were created in, retaining the order of multiple CSTs created within a single block. P is topologically sorted to create a totally ordered set of transactions and CSTs.
4. Block size limits may constrain the number of transactions and cross-shard transactions included in a shard block. If this occurs, it is optional to introduce priority of transactions and CSTs as illustrated in Fig. 7, whereby block proposers select transactions and CSTs to include based on priority fees, and MEV. However, this comes at the cost of potentially allowing exploitative transaction insertion. Pending transactions and CSTs must be processed if allowed by block size limits; any unused block space must be too small to contain any unprocessed transaction or CST.
5. New transactions that do not fit into block processing can be included in a shard block’s outbox of CSTs. Such transactions enter the shardDAG for ordering and will therefore be processed in a later block along with other pending transactions and CSTs not included in b.

Validators should only sign a proposed block once they have verified that the block proposer has followed this protocol ordering. If an invalid ordering is used then the block is invalid and/or the signing validators are subjected to penalties. We reiterate that because ordering rules involve only on-chain data, data availability of CSTs and block headers enables any validator or node to verify correctness of ordering.

Figure 7: An extension of Fig.3 when shard B is overloaded and unprocessed transactions and CSTs exceed maximum block size (left). The block builder selects transactions and CSTs to remove from the topological sort for the new block (middle), so that the remaining transactions and CSTs do not exceed block size limits (right). Removed CSTs will be processed in later blocks. This removal of transactions and CSTs is expected to be based on priority fees and MEV. Unprocessed new transactions (b2’) may be included in an outbox as data so that they enter shardDAG ordering for processing in a later block, like b0 and b1 in earlier blocks, but these outboxed transactions are not processed in the current block.

Summary

In state-sharded blockchains, censorship and insertion of exploitative transactions part-way through transaction processing can be constrained by shardDAG transaction and CST ordering. These shardDAG constraints are derived from ordering, which enforces processing of earlier transactions and CSTs before later ones. ShardDAG ordering rests upon economic incentives that motivate validators to suitably participate in the shardDAG to receive block rewards and avoid penalties.

DAGs are a natural tool to be used in ordered systems. The shardDAG broadens the use of DAGs in blockchain, beyond their more common application in consensus mechanisms. The shardDAG has been presented here in a unified state sharded system, but the ideas can be applied to sets of distinct rollups or blockchains.

1 post - 1 participant

Read full topic

Special thanks to @Julian, @barnabe and @manav2401 for the reviews

Background

Inclusion list have been an active topic since the early days. Various designs have emerged over time, each with inevitable trade-offs concerning What can be constrained within a single Ethereum slot?.
This post explores these trade-offs from the perspectives of different actors involved in ILs and defines the dependencies required for each actor to fulfill their role in integrating ILs into the protocol. We will compare and contrast multiple designs, focusing on the limitations related to timing, security, and feasibility.

First, we will outline some definitions.

IL Definitions

Slot Time: In the context of Ethereum, a slot refers to a fixed interval currently set at 12 seconds. During each slot, the proposer/builder proposes a block, attesters vote on the block, and an aggregator aggregates the votes. The proposer of subsequent slot includes aggregated votes in their block, and the cycle repeats. Today out-of-protocol builders have an ~8-second window to prepare for the next slot’s block. All actions are synchronized with these validator duty intervals, and IL should not extend the current slot time.

Inclusion List: An inclusion list (IL) is a list of transactions that a block proposer commits to including in a block. Depends on the conditional vs unconditional constraint, if these transactions are not included in the block, then the block cannot be considered canonical, assuming honest attesters who will vote against the block. The IL consists of the following options and requirements.

1. Satisfactory Requirement:
   • Conditional: The IL does not need to be satisfied if the target block is full.
     • Forward-Looking: If the IL cannot be satisfied in the current target block, does it still apply to subsequent blocks? More in this post
   • Unconditional: The IL needs to be satisfied. This typically means the IL has its own gas limit.
2. Satisfactory Time:
   • Same Slot IL: The IL is satisfied within the same slot, similar to users sending a transactions wanting to be included on chain. With sufficient base fee and tip, we can expect the transaction to be included the slot of. For example, an IL transaction for slot n+1 is satisfied in slot n+1.
   • Next Slot IL: The IL is satisfied in the subsequent slot with one slot delay. For example, an IL transaction for slot n+1 is satisfied in slot n+2.
3. IL constructor: The actor responsible for preparing and broadcasting the IL to the network. This role can be fulfilled by a single entity (like a proposer) or by a committee where the protocol reaches consensus on individual ILs from its members. The consensus of IL may be reached by IL aggregate which represents IL committee’s vote.
4. IL Gas Limit: IL gas limit has an implication on the size of IL which dirrectly affects the network propagation time and node’s verification time.
5. IL Ordering In Block: When the IL becomes part of the block, the transactions may be required to be placed in a specific order. This order could be:
   • Top of the Block: Transactions are placed at the beginning of the block.
   • Anywhere in the Block: Transactions are placed anywhere within the block.
   • Bottom of the Block: Transactions are placed at the end of the block.
6. Liveness Guarantee The IL must be made available to the block builder to avoid stalling the chain’s liveness. The delivery method of the IL to the builder varies based on the trust model. If a single person constructs the IL, stricter requirements may be necessary, such as additional attester validation along with the block.
7. No Free DA An IL that has not been satisfied in execution cannot be part of the consensus, as it would grant free DA. Free DA has to be tightly coupled with consensus and should not be mistaken for free bandwidth or temporary data storage. While nodes can use a small amount of bandwidth or store temporary data with anti-dos measures in place, this should not be conflated with free DA.

Block Builder: The actor tasked with fulfilling the IL and broadcasting the resulting product (ie. a block that fulfills the IL) over the network. In the case of a solo validator, the block proposer serves as the block builder, and the product is the execution payload of the block. For a MEV-boost validator, the block builder handles the fulfillment, which returns the signed header to proposer, and the relay broadcasts the final block to the network. It is often the case that the block proposer cannot verify the satisfactory fulfillment of the IL when signing the header request. Relays have to verify the payload satisfies IL ahead of time or assume optimistic.

IL Transaction Invalidation: Transactions in an IL may become not includable at the time of inclusion due to invalidations, such as an incorrect nonce or insufficient balance. This situation can arise under different conditions. For example, when multiple parties are involved in constructing their version of ILs, the transactions from each party might render each other not includable. Similarly, if one party constructs the IL while another party broadcasts the block at the same moment, there can also be invalidations, leading to mutual exclusion of the IL transactions and block transactions.

Head Block: Often referred to as the parent block, the IL should be constructed on top of the chain’s head from the perspective of the node. The builder, responsible for constructing the block and satisfying the IL, should also build on top of the head block in order to make sure that block and inclusion list are aligned.
Constraint: If an IL is built on head a, then to satisfy the IL, the builder’s block must also be built on top of head a.

IL Timings

IL Preparation Time: This is the time required for a party to prepare the IL, which is constructed on top of the head block. The larger the IL may require longer time to prepare.

IL Propagation Time: This is the time required for the IL to propagate across the network to other nodes. Factors influencing this time include the size of the IL, the number of ILs (committee size), and the network’s gossip rules.

IL Verification Time: This is the time required to verify the IL. The IL must be valid, otherwise builders can get grieved. In some scenarios, attesters must verify the IL before considering the current slot block as the head (. In other cases, the proposer must verify the IL before proposing the next slot block. The point is that some parties must verify the IL beforehand, and it’s crucial to consider who is bearing this cost.

Block Preparation Time: This is the time required to build an execution block. The block can be constructed either by the proposer or the builder. The IL’s satisfactory requirements must be met in the block. This means the block builder must verify the IL, parent block and ensure that the block satisfies IL requirements.

Block Propagation Time: This is the time taken for a block to be transmitted across the network and received by all participants. It’s crucial that the block is received and verified by attesters promptly, as delays can lead to the block not being considered as the head of the chain, increasing the risk of reorg.

Block Verification Time: This is the time taken for a node to verify the block and IL. The focus here is on execution verification time, as consensus verification is typically fast. A block must be verified as execution valid and meet the IL requirements before it can be considered the head of the chain.

Based on the timing definition provided, we can outline the following dependencies:

• The parent head block n must be released before attestation cut off. The difference is between start of the slot. Head release time = T_{HR}
• The head block must be propagated to peers on time. Head propagation time = T_{HP}

• The IL constructor must see and validate the parent head block before creating the IL. Head validator time = T_{HV}
• The IL must be constructed and released using for example a local mem pool. IL construction time = T_{ILC}
• The IL must propagate through the network to reach the builders. IL propagation time = T_{ILP}
• The block builder needs to verify the IL before submitting a bid. IL verification time = T_{ILV}
  • This requirement may change in the context of slot auctions.
• The proposer must see the bids before submitting a block. Bid propagation time = T_{BP}
• The attester must verify the block n+1 before considering it as the head. We can reuse head verification time above.

In short, we could summarize: A single Ethereum slot should not exceed the following durations, ensuring that the end-to-end IL is applied, and the block remains canonical on the chain: SLOT >= T_{HR}+T_{HP}+2 * T_{HV}+T_{ILC}+T_{ILP}+T_{ILV}+T_{BP}

Different versions of IL

Different versions of IL have varying constraint trade-offs. Some examples taken from EIP-7547 and FOCIL.

EIP-7547 in MEV-Boost

• The block builders for slot n constructs a block for slot n after verifying the block for slot n-1.
• The block proposer of slot n constructs an IL for slot n+1 after verifying the block for slot n-1.
• The IL for slot n+1 and the block for slot n may invalidate each other if they are sent by different parties.
• The block proposer/builder of slot n+1 requires the IL and the block for slot n to build a block.
• The block proposer of slot n+1 needs the IL and the block for slot n to build an IL.
• Attesters for slot n+1 need the IL and the block for slot n to attest to the block. The block for slot n+1 must link to a valid IL n+1, or it cannot be canonical.

EIP-7547 in ePBS (EIP-7732)

• The block proposer of slot n selects the builder’s bid of slot n after verifying the execution block for slot n-1.
• The block proposer of slot n constructs an IL for slot n+1 after verifying the execution block for slot n-1.
• Since the bid commits to the transactions, the IL for slot n+1 and the bid for slot n may conflict. This is different in slot auction.
• The builder reveals the execution block at slot n’s 6-seconds mark.
• Subsequent block builders require the execution block at slot n and the IL for slot n+1 to place bids for slot n+1. This is different in slot auction.
• Attesters for slot n+2 verify that the execution block for slot n+1 satisfies the IL and is valid. We gain an extra slot time for validation due to delayed execution property.

FOCIL in MEV-Boost (Ignoring IL Aggregation Step)

• The block builder of slot n constructs a block for slot n after verifying the block for slot n-1.
• The IL committee builds the IL for slot n after verifying the block for slot n-1.
• The IL committee for slot n releases the IL during slot n-1.
• Attesters for slot n lock their view on the ILs.
• The builder of slot n includes the IL transactions into the block for slot n
• At the start of slot n, the proposer requests the builder’s head, signs it, and broadcasts it.
• Attesters for slot n verify that the block satisfies the IL committee’s requirements according to their locked view in slot n-1.

FOCIL in ePBS (Same Slot Version)

• The block proposer of slot n selects the builder’s bid for slot n after verifying the execution block for slot n-1.
• The IL committee for slot n+1 constructs the IL for slot n+1 after the builder reveals the execution block for slot n.
• Builders for slot n+1 verify the IL and make bids for slot n+1.
• The block proposer of slot n+1 selects the builder’s bid for slot n+1.
• Attesters for slot n+2 verify that the execution block for slot n+1 satisfies the IL and is valid, providing close to an extra slot time due to delayed execution.

FOCIL in ePBS (Next Slot Version)

• The block proposer of slot n selects the builder’s bid for slot n after verifying the execution block for slot n-1.
• The IL committee for slot constructs the IL for slot n+2 after the builder reveals the execution block for slot n.
• Builders for slot n+2 verify the IL and make bids for slot n+2.
• The block proposer of slot n+2 selects the builder’s bid for slot `n+2.
• Attesters for slot n+3 verify that the execution block for slot n+2 satisfies the IL and is valid, providing close to an extra slot time due to delayed execution.

IL Contentions

ILs may compete with initiatives as the following:

Shorter Slot Time Contentions with IL: With shorter slot times, ILs may not be constructed and fulfilled on time. A proposer that cannot fulfill an IL results in a liveness fault. One way to address this is to extend the IL satisfactory rule to the next slot or to multiple subsequent slots, but this approach introduces risks of denial-of-service (DoS) attacks and more transaction invalidation concerns. There is a trade-off here.

Higher Gas Limit Contentions with IL: With a higher block gas limit, it takes longer to verify the block, which reduces the time available to construct the IL after verifying the block. Additionally, with a higher IL gas limit, it takes longer to propagate and verify the IL, reducing the time available to fulfill the IL by building the block.

DVT Contentions with IL: Distributed Validator Technology (DVT) requires more exchanges between validators before signing. This process includes beacon chain duties such as attesting, proposing, and submitting ILs. These additional exchanges require time, and there is a need to ensure that the IL, especially in more complex forms, does not make DVT operations impractical.

AVS Contentions with IL: Active Validator Service (AVS) also require more actions from validators. The specific details depend on the AVS implementation, but generally, requiring more time from validators to perform certain tasks can create contention with fulfilling IL obligations.

1 post - 1 participant

Read full topic

• by Hankyung Ko(@HankyungKo) and Chanyang Ju(@wooju), Researcher at Radius . Thanks to Tariz and AJ for reviewing this post.
• Your feedback and opinions are highly valued.

Radius has designed a synchronous atomic execution solution for cross-rollup composability. This development is driven by our commitment to support rollups seeking improved composability and enhanced user experience. We will enable rollups to create their own shared sequencing layer, offering this as a service to make it widely accessible. By doing so, we ensure that atomic execution of bundled transactions is coordinated effectively across participating rollups.

1. Introduction

---

Synchronous atomic execution allows multiple transactions from different rollups to be executed simultaneously and atomically in an all-or-nothing manner, significantly reducing latency compared to sequential execution. A naive approach to executing multiple cross-rollup transactions require each transaction to be finalized sequentially on L1. For n transactions, the total latency would be n times the L1 finalization period. In contrast, synchronous atomic execution enables all transactions to be executed at the same time, significantly reducing latency.

While executing transactions simultaneously can reduce latency, it may raise concerns about security. For example, in a bundled transaction involving minting-and-burning across different rollups, there’s a risk that the burn could fail while the mint succeeds. To address this, we’ve designed our system to verify the atomicity of bundled transactions faster than the time it takes for block finalization. This approach ensures that security is maintained even with simultaneous execution. Our innovation improves composability across multiple rollups, providing a seamless, efficient, and secure user experience with real-time, all-or-nothing execution of cross-rollup transactions without delays.

To implement this convenient and secure solution, Radius introduces a shared sequencer for rollups to guarantee the atomic execution of bundled transactions. Users create bundled transactions that depend on transactions across multiple rollups, and the shared sequencer manages the sequencing of bundled transactions for successful execution.

It’s important to note that this shared sequencer is not a single entity controlled by Radius, but rather a set formed by aggregating existing sequencers from each rollup. A leader is selected from this set through a predefined process (reference) to manage sequencing.

To prevent potential power abuse by the shared sequencer, Radius employs decentralized sequencing techniques, including encrypted mempool (PVDE and SKDE). The shared sequencer has two main functions: determining transaction order and enforcing transaction reverts to maintain bundle atomicity.

This article details on how our architecture addresses the second function, ensuring atomicity. Preventing potential abuse of the first function, transaction ordering, is also crucial. Radius addresses this concern through the encrypted mempool, ensuring that the shared sequencer cannot abuse its power regarding transaction ordering.

1) Requirements of the synchronous atomicity solution

• Convenience: Users can achieve greater benefits by utilizing atomic execution of cross-rollup bundled transactions, without compromising security.
  • Bundle transactions: Users can bundle and execute multiple transactions across different rollups as one.
  • Atomic execution: The bundle transaction is guaranteed to execute simultaneously without failures. If a failure occurs, it is guaranteed to fail simultaneously.
  • Fast execution for bundle while maintaining security: Transactions are guaranteed to be executed faster than sequential execution (where each transaction waits for the previous one to finish). This allows users to strategize their next transactions more quickly. Additionally, atomic execution is cryptographically verified before finalization, ensuring that the security of the transactions is maintained even though they are executed more quickly.
• Security
  • Minimized trust level: Aims to minimize the amount of trust users must place in key network participants like the shared sequencer and executors by:
    • Minimizing the number of parties that need to be trusted.
    • Minimizing the duration for which trust is necessary.
    • Ensuring early detection and verification of any malicious behavior by the shared sequencer and executors before blockchain finalization.

2) Main Idea

We propose an architecture for synchronous atomic execution using the shared sequencer, data availability (DA), and a verification layer.

Why shared sequencer?

• To satisfy the desired properties of convenience and security, it is necessary to handle bundled transactions across multiple rollups. Therefore, we propose a new entity called the shared sequencer, which is responsible for confirming the blocks of multiple rollups.
• The shared sequencer receives a cross-chain bundle and determines the block order for atomic execution.
• The shared sequencer is responsible to ensure the atomic execution of bundled transactions before confirming the block.

New responsibility of the executor

• The executor, in agreement with the shared sequencer, has an added constraint: it must execute the transaction list committed by the shared sequencer.

[Figure 1] The definition of roles and responsibilities of shared sequencer and executors

Conditions for synchronous atomicity

• Synchronous atomicity for bundle transaction is achieved if the following two conditions are independently verified:
  1. All bundled transaction in the block committed by the shared sequencer should be atomic.
  2. The executor executes the same block as committed by the shared sequencer.

3) Our Contributions

• Designed a synchronous atomic execution solution:
  • Security requirements definition: We have defined the security requirements for each entity involved in synchronous atomic execution, ensuring that all components operate securely and reliably.
  • Architecture design: We have designed a robust architecture that ensures security and efficiency. This architecture includes:
    • User’s bundle transaction: We defined the structure and format of bundle transactions that users can create. These bundled transactions enable users to execute multiple transactions across different rollups simultaneously, ensuring atomic execution.
    • The bundler contract: We designed and implemented the bundler contract, which is responsible for handling and processing bundled transactions. This contract is called by the shared sequencer, and performs several critical functions:
      • Acts as a gateway smart contract for users to call the actual contracts they intend to execute.
      • Allows the shared sequencer to enforce transaction reverts to guarantee the atomicity of the bundle transactions.
      • Verifies the legitimacy of transactions initially created by the user.
      • Charges transaction fees to users.
    • Coordination process for the shared sequencer: We developed a coordination process for the shared sequencer, which includes interaction with the full nodes (simulators) of each rollup. This process ensures that the shared sequencer can effectively manage and sequence transaction across multiple rollups, guaranteeing atomic execution.
    • Verification logic: We defined the verification logic to ensure that all transactions within a bundle meet the defined security requirements before finalization.
• Demonstrated the feasibility of the architecture:
  • Implementation: We have implemented the entire architecture, demonstrating its feasibility and effectiveness. Our implementation includes all components of the synchronous atomic execution solution, from the user’s bundle transaction creation to the coordination process for the shared sequencer.
    • The user’s bundled transaction is signed using MetaMask.
    • Implemented on two Polygon CDKs:
      • Each Polygon CDK has an API that responds to the shared sequencer’s simulation requests.
      • Each Polygon CDK has a deployed Bundler contract.
  • Demo: The demo scenario involves transferring tokens from Rollup A to Rollup B. In this scenario, the bundled transaction consists of two operations: burning the wrapped token on Rollup A and mint it on Rollup B. This demonstrates the practical application of our solution. (Check out our Demo here!)

2. Definition

---

[Figure 2] Overview of transaction flow

The proposed architecture is based on the following assumptions.

• Scenario
  • Each Bundle Tx consists of two transactions: a Burn transaction and a Mint transaction of ERC20 contract (rToken), occurring on different chains (inspired by Hyperlane bridge scenario).
• Rollups
  • Each rollup has a simulation API implemented.
  • The Radius’ Bundler contract is deployed on each rollup.
  • The ERC20 rToken contract is also implemented on each rollup.
  • The execute function of the Radius’ Bundler contract is accessible only by whitelisted shared sequencers.
  • The ERC20 contract (rToken) grants burn and mint access rights to the Radius’ Bundler contract.
• Incentives and Penalties (Future work)
  • There are sufficient incentives for correct behavior and penalties for incorrect behavior for the shared sequencer and Executor.

1) Operational Roles and Security Requirements of Entities

In this section, we define the correct behavior and adversarial behavior of each entity in the architecture. The adversarial behaviors defined here will be analyzed in Section 4.

• User: The entity that generates cross-rollup bundled transactions and sends them to the shared sequencer for atomic execution.
  • Adversarial behaviors
    • Creates invalid Bundle Tx:
      • The value of the BURN Tx and the MINT Tx do not match.
      • Insufficient account balance for the tokens intended to be burned.
      • Lacks the ability to pay the gas fee required for executing the transaction on at least one chain.
      • Incorrectly signs the Bundle Tx.
    • Calls the MINT function without the shared sequencer’s assistance:
      • Attempts to execute the MINT Tx without creating a Bundle Tx.
• Shared sequencer: The entity responsible for receiving bundled transactions from users, creating and submitting blocks for multiple rollups, and ensuring the atomic execution of bundled transactions.
  • Adversarial behaviors
    • Calls bundler contract without user’s consent.
    • Fails to verify whether the Bundle Tx is executed atomically across all rollups.
    • Forces the valid Bundle Tx to revert unnecessarily.
    • Sends a different transaction list to the executor than the one committed to the DA after confirming the block.
• Executor: The entity specific to each rollup that executes the transaction list determined by the shared sequencer and uploads the resulting blocks to the Data Availability layer.
  • Adversarial behaviors
    • Does not execute the transaction list as confirmed and provided by the shared sequencer.
• Shared Prover: The entity that generates zero-knowledge proofs to validate the atomic execution of bundled transactions across different chains based on data from the Data Availability layer.

2) Additional Components

• Simulator: The simulator refers to the full node of each rollup that the shared sequencer communicates with to validate the atomicity of bundled transactions before committing the block. This entity could be the same as the executor mentioned above.
• Data Availability Layer (DA): The DA is a layer for storing data committed by the shared sequencer and executor to prove their honesty. The shared prover uses this information to verify the honesty of both entities.
  • Given a reliable DA, if the shared sequencer and executor each commit the minimum necessary information for the verification of synchronous atomicity to the DA, it can be quickly verified based on that information.
• Verification layer: The verification layer is responsible for verifying the proofs generated by the shared prover and assisting with the appropriate actions if verification fails. This layer can either be part of the settlement layer or a dedicated layer focused solely on verification.

3. Synchronous atomic execution architecture

---

[Figure 3] The process of synchronous atomic execution architecture

The architecture of Radius’s synchronous atomic execution ensures that bundled transactions are executed in an all-or-nothing manner within the same cycle, coordinated by the shared sequencer. Initially, the shared sequencer’s coordination is trusted optimistically, allowing each transaction to be executed independently on its respective rollup. Subsequently, the atomicity of these transactions is verified before the rollup blocks are finalized on L1.

It can be divided into three main components: the bundler contract, the coordination process, and the verification process. This section will describe each of these components in detail.

1) Smart Contract for Bundle Transaction (Radius’s Bundler contract)

[Figure 4] Overview of transaction flow

We introduce a new smart contract called Radius’s bundler contract, designed to handle and process the users’ bundled transactions. It acts as a gateway to execute the users’ intended contracts.

For example, as shown in the figure, suppose a user creates a bundled transaction that includes calling the Burn function of the rToken contract on Rollup A and the Mint function of the rToken contract on Rollup B. The shared sequencer receives this bundle and wraps it into a transaction that calls the Radius’s bundler contract. Each rollup then processes the transaction through a series of verification via the Radius contract, ultimately executing the user’s intended contract calls.

Key features of the Bundler contract

• Acts as a gateway smart contract for users to call the actual contracts they intend to execute.
• Allows the shared sequencer to enforce transaction reverts to guarantee the atomicity of the bundle transactions.
• Verifies the legitimacy of transactions initially created by the user.
• Charges transaction fees to users.

How is the Bundler contract implemented?

The Bundler contract includes the following functions:

• execute: Called by the shared sequencer, this function executes the user’s transaction after a series of verifications.
• deposit: Allows users to deposit transaction fees in advance.
• withdraw: Allows users to withdraw their deposited funds.
• addWhitelist: Adds a sequencer to the whitelist.
• removeWhitelist: Removes a specific sequencer from the whitelist

How is the execute function implemented?

The input parameters for the execute function are as follows:

• from: User address
• bundle_tx_list: Information of all transactions within the Bundle Tx
• index: Current transaction’s index within the bundle_tx_list
• bundle_tx_signature: User’s signature for the Bundle Tx
• revert_flag: Flag for enforcing revert
  • The sequencer includes a “revert_flag” in the data, which is set by the sequencer to forcibly revert the user’s transaction. If this value is set to true, the Bundler contract will revert the user’s transaction. This mechanism is designed to ensure the atomicity of the transactions defined in the bundle, preventing the execution of the remaining transactions if even one included in the bundle fails to execute.

1. Access control:
   • Verify that the call is made by a shared sequencer listed in the whitelist.
2. Check revert_flag:
   • If revert_flag == true, forcibly reverts the transaction.
3. Verify user’s transaction:
   • Decode the transaction’s data field.
   • Ensure the user’s deposit is greater than the transaction fee.
   • Verify the user’s bundled transaction signature.
   • Check the Bundle Transaction validity
     • (In this scenario) Verify that the values to be minted and burned are identical.
4. Deduct transaction fee from user’s deposit (Exception handling required for early reverts):
   • Transfer the transaction fee to the shared sequencer from the contract’s deposited assets.
   • Deduct the transaction fee from the user’s deposit.
5. Execute user’s intended contract:
   • Call the contract that the user intended to execute.

2) Coordination process for the shared sequencer

Radius’s shared sequencing technique separates the roles of sequencing and execution. The shared sequencer is responsible for deciding the block that atomically executes the user’s bundle transactions, while the block is built by each rollup’s executor. Therefore, if it can be ensured that the shared sequencer has coordinated the atomic execution of the bundle transactions and the executor has executed the block as determined by the shared sequencer, synchronous atomic execution is achieved.

Coordination involves requesting simulations to the full nodes of each rollup for the respective transaction lists, collecting the simulated results, and, if some transactions within the bundle need to be reverted to maintain atomicity, forcibly reverting the remaining transactions to produce a transaction list that will be executed atomically. In other words, if the simulation results of the two transaction defined in the bundle are not the same (i.e., one is a revert and the other is a success), the transaction that yields a successful result is modified by setting its revert_flag to 1 to forcibly revert it. The transaction list is then updated with the modified transaction.

[Figure 5] Example of a Simulation Process

After finalizing the block, the shared sequencer commits to it. Later, the block information committed by the shared sequencer can be compared with the block executed by the executor to verify that the executor executed the block as agreed. The atomicity of the bundle transactions can be verified by examining the receipt committed by the executor after building the block, which shows the success status of each transaction and ensures that the shared sequencer did not forcibly revert all transactions. These two processes can be verified off-chain using ZKP systems such as RiscZero or SP1. This process is detailed in section 3.3.

3) Verification process for the shared prover

We design a zk prover called “Shared Prover” which allows us to verify that the shared sequencer and executor acted in accordance with the protocol’s intentions. The shared prover generates proof for the atomicity of the bundle transactions and their valid execution result according to the commitment.

We leverage the DA layer to facilitate the sharing of the sequencer’s commitments and execution data across different chains. Utilizing the DA layer for data storage offers enhanced transparency and accessibility. Based on the DA (Data Availability) data, it can be confirmed that the user’s bundle transactions were executed atomically, and the validity of the execution result on different chains can be verified.

The shared sequencer communicates with simulators to finalize the the list of transactions to be performed while ensuring atomicity, and the executor processes this list and then it uploads the resulting data to the DA layer.

Information stored in the DA

• Shared sequencer’s transactions list commitment

  To settle transaction list, shared sequencer commits the following data with signature to the DA:

  • chain ID
  • block height
  • transaction MPT root
  • bundle transaction list

• Executed Block data

  After a block is executed on each chain, the entity who executed the block uploads the results to the DA.

Atomicity proofs (Shared sequencer’s honesty)

The shared prover retrieves the block execution results stored in the DA by the executor. In the atomicity proof, the following aspects are verified using zero-knowledge proofs:

• All-or-Nothing execution

  • The receipt status for the bundle transactions must have the same value.

    \text{assert!} (\text{receipt}(\text{tx}_A).\text{status} = \text{receipt}(\text{tx}_B).\text{status})

• Prevention of arbitrary manipulation of the shared sequencer’s revert flag

  • There is a potential attack where a valid bundled transaction is reverted entirely, collecting fees from the user without executing the transaction. To prevent this, the atomicity proof checks that not all revert flags for the transactions are set to 1.

  • Therefore, revert flags cannot be set to 1 simultaneously.

    \text{assert!}(\text{tx}_A.\text{revert_flag} \times \text{tx}_B.\text{revert_flag} = 0)

Proof of Rollup executor’s honesty

To verify that the executor has honestly executed the block according to the transaction list committed by the shared sequencer, the shared prover also includes the relationship between the values committed by the shared sequencer and the MPT root of the transactions uploaded by the executor.

4. Security analysis

---

• Individual Transaction Validity: The validity of individual transactions (e.g., insufficient user’s balance) is verified by the Bundler Contract, and transactions will fail if they do not pass this check.
• Bundle Transaction Validity: The validity of the bundled transaction (e.g., discrepancy between mint and burn amounts) is also verified by the Bundler Contract, and the bundle will fail if it does not pass this check.
• Atomicity of Successful Bundle Transactions: The shared sequencer is responsible for ensuring the atomicity of successfully executed bundled transactions. The honesty of the shared sequencer is verified by the shared prover and the verification layer.
• Honesty of the Executor: If the shared sequencer has legitimately determined and committed the blocks for each rollup, the honesty of the executor is verified by the shared prover and the verification layer.
• Prevention of Manipulation: Additionally, neither the shared prover nor the rollup executor can manipulate the user’s bundle transaction. The user’s signature prevents such tampering.
• Integrity of Proofs and Verification: The shared prover and the verification layer perform proofs and verification based on authenticated data available in the Data Availability (DA) layer. As a result, they cannot alter the proof content. The worst they can do is to withhold performance.

2 posts - 2 participants

Read full topic

TLDR

• Since July 10, mev-commit 0.4.3 has enabled over 800 execution preconfirmations on Holesky, with increasing network participation.
• Providers issued 807 preconfirmations across 415 blocks. Bidders sent 4.24 ETH worth of bids.
• Average mev-commit block value was 0.0093 ETH compared to 0.0044 ETH for a vanilla block.
• Average total preconfirmation bids per mev-commit block was 0.0049 ETH, slightly higher than the average priority fees in the mev-commit block of 0.0045 ETH.
• Data shows that preconf bids contribute significantly to overall block value, despite limited participation for the nascent network.

Overview

Since July 10, mev-commit 0.4.3 has been facilitating execution preconfirmations on Holesky tesnet. There has been an upwards trend of participation with currently 1 relay, 3 providers, 9 bidders, and 27,000 validators participating. From July 10 to July 29 (Holesky block range 1902173 to 2027932), providers have issued 807 preconfirmations across 415 Holesky blocks. Some examples of preconfirmation blocks:

• 1943039 with 21 preconfs and .016 ETH worth of bids
• 1986732 with 7 preconfs and .04 ETH worth of bids
• 1986963 with 5 preconfs and .022 ETH worth of bids

There are two caveats to these initial results. The first is that network participation is still growing. As more actors onboard or opt in to the network, the flow of preconfs is likely to increase. The second caveat is that Holesky does not have the same competitive use cases for preconfs as mainnet, and does not mirror mainnet Ethereum transacting behavior as closely as desired.

The notebook used for analytics can be found here. The data for these results can be replicated using the mev-commit-sdk-py repository to collect mev-commit events powered by Hypersync indexer. There is also an explorer, which is currently in development.

Bidding Behavior

We observe 815 preconfirmation transactions, indicating a niche but valuable market segment compared to 4 million regular transactions. This significant difference suggests preconfs are currently used by a smaller subset of users who are testing preconfirmations.

A total of 9 bidders participated, sending 4.24 ETH in bids compared to 0.13 ETH in priority fees, with an average preconfirmation bid of 0.005 ETH versus 0.00016 ETH for priority fees on the same transaction, indicating a heavier bidding preference for preconfirmations over priority fees.

Overall, priority fees totaled 544 ETH with the average preconfirmation bid being 0.0049 ETH, slightly higher than the average priority fee of 0.0045 ETH.

Block Value

We hypothesized that preconfs would add an increase in block value, resulting in higher validator rewards per mev-commit block. On average, we observe 1.95 preconfirmation transactions per block compared to 42.3 total transactions. Average mev-commit block value was 0.0093 ETH compared to 0.0044 ETH for a vanilla block.

One limitation in comparing mev-commit blocks to vanilla Holesky blocks is that there are only ~400 mev-commit blocks compared to ~50,000 Holesky blocks. This is primarily due to the nascent mev-commit network participation rates. Additionally the average bid amount at 0.005 ETH seems on the higher side for Holesky blocks and may not accurately reflect mainnet amounts. However accurately pricing preconfirmations is a difficult task and has to be balanced with the presence of mev spikes on mainnet that can greatly skew results. We are actively researching how to price preconfirmations more effectively.

We illustrate the block revenue breakdown over several days in the chart below for mev-commit blocks, showing the breakdown between preconfirmation bids and priority fees:

Preconfirmation bids significantly contributed to increasing block value. On days such as July 11th, 18th, and 24th, preconfirmation bids markedly boosted total block value, highlighting their substantial impact.

The charts below illustrate an outsized impact that preconfirmation bids on block value:

• Preconf Bids per Block: Despite a smaller number of transactions, preconfirmation bids are consistently higher, often reaching up to 0.02 ETH.
• Priority Fees per Block: While more frequent, priority fees are generally lower, seldom exceeding 0.01 ETH.

A notable example is block 1943039, which had the highest number of preconfs with 21 out of 48 transactions. In this block, preconf bid revenue was 0.008 ETH, vastly outpacing the 0.0009 ETH from priority fees.

These observations demonstrate that even a few preconfirmation transactions can substantially enhance block value due to their higher bid amounts.

Limitations

As mentioned earlier, the caveats to our initial findings is that Holesky is a testnet and does not have the same types of competitive opportunities as Mainnet. Users tend to have less urgency on Holesky and this is reflected in smaller block sizes and lower priority fees.

As a result, the preconf bids may not have the same relationship to priority fees on mainnet compared to testnet and may not accurately reflect the user’s true bidding preferences since testnet tokens are being used.

Closing Remarks

This report initially touches on some preconfirmation bidding behavior observed through early mev-commit usage and offers insights into how preconf bids can increase validator rewards. We plan to follow up with a more detailed report on mev-commit protocol details such as the decay mechanism, rewards and slashing, settlement process, and revenue.

We plan to onboard more bidders, providers and validators into the mev-commit ecosystem and conduct more tests in an environment that mimics mainnet more closely. We invite you to participate starting at Welcome to Primev - Documentation

10 posts - 5 participants

Read full topic

Preamble

Since the inception of the Curve AMM smart contracts at the start of 2020 and the creation of the Curve DAO in August 2020 (together “Curve”), Curve has established itself as a cornerstone of DeFi.

Curve has been able to attract top contributors for every area of its work and has grown into a living community with a diverse ecosystem.

Today numerous projects built on the protocol for the benefit of Curve and a wide distribution of CRV tokens results in a highly decentralized ownership. Curve DAO acts until now as a parametric DAO, for funding it has only been used twice, to fund the grants council.

We are aware that this proposal is a cultural shift and are seeking broad support to underpin its legitimacy.

General Information / Background

This proposal requests a grant for software research and development work as well as related tasks for the benefit of Curve as outlined within this proposal. The grant will be for one year, unused funds will be rolled over to the next year.

Until this point in time, Swiss Stake AG as the initial developer of the Curve software repositories has used the CRV allocation received in August 2020 as the primary funding for further development and research work. As the company wants to retain existing and attract new critical talent & stakeholders, the company seeks funding to ensure, respectively establish long term support for Curve. Currently 25+ persons/entities are directly or indirectly engaged by Swiss Stake AG for development and research work related to Curve.

The company does not have other substantial revenue sources and hence is dependent on the community to vote and ensure that Swiss Stake AG can continue contributions to Curve for years to come. It is the paramount goal of Swiss Stake AG to keep researching, building and further contributing to Curve.

Grant Proposal

3.1 Project Description

To directly or indirectly by engaging third parties (“Project Description”):

• develop and promote Curve, respectively the Curve technology and software repositories.
• coordinate with and engage third parties for code quality and integration safety (Audits, Security Research). Based on past experience within the Curve ecosystem, approx. 35% of the overall costs related to the development of new software components for the repositories is being used for such checks while the rest is the actual software development cost.
• develop and promote software development kits (SDKs) and other software tools to interact with smart contracts for Curve
• build and support the growth of the Curve ecosystem
• create educational resources and organize events related to Curve
• create other resources, software, or other material to support the adoption of the Curve technology / Curve ecosystem

3.2 Grant Amount

Based on past experience with similar development and research tasks within the Curve ecosystem, Swiss Stake AG requests 21’000’000 CRV token vested over one year to the company multisig (“Grant Amount”). We request this from the Community Fund, currently holding 47’545’144 CRV and need the support from Curve DAO token holders.

We did consult with some stakeholders and did our best to integrate the feedback we collected over the last few weeks.

Signing rights of the multisig reflect the signing rights within Swiss Stake AG as displayed in the commercial registry with one additional contingency signer defined by Swiss Stake AG.

3.3 Grant Conditions

• Swiss Stake AG shall use the Grant Amount received in good faith exclusively for the Project Description. Any other use without the prior consent by the Curve DAO is prohibited. Unused funds will be rolled over to the next year and spent in line with the Project Description. If any part of the Grant Amount cannot be used in accordance with the Project Description, it shall be returned to the Curve DAO.

• Swiss Stake AG may at its sole discretion decide to stake the CRVs received as part of the Grant Amount in liquid wrappers to generate additional yield. This yield also will be used exclusively for the Project Description.

• Swiss Stake AG shall release any and all intellectual property consisting of mathematical codes, software programs, routines, and other functions that control the functioning and operation of a computer’s hardware that results from the use of the Grant Amount (“Software”) under an open-source license compatible with the Curve software repositories.

• The Grant Amount includes Swiss Value Added Tax (“VAT”) (if applicable). The Grant Amount may be used for the payment of income tax, capital tax, VAT and tax at source or withholding tax, and any other taxes of Swiss Stake AG, if such taxes apply and are related to the Grant Amount or the activities mentioned in the Project Description.

• Swiss Stake AG commits to produce bi-annual reports on the spending of the Grant Amount. It will list expenses in a summarized form and inform about the ongoing initiatives for which the funds are used. The report will be published in written form on the governance forum.

• Swiss Stake AG shall inform the Curve DAO of any event or change in circumstances that could reasonably affect its ability to perform any of the grant conditions.

• Swiss Stake AG does not guarantee any success related to its activities under the Project Description and all liabilities except for gross negligence, intent and fraud should be excluded.

• The grant proposal as well as the subsequent grant shall in all respects be governed by and construed in accordance with substantive laws of Switzerland (to the exclusion of the Vienna Convention on the Contracts of the Sale of Goods). Any dispute arising out of or in connection with the grant proposal as well as the subsequent grant shall exclusively be referred to the courts competent for the city of Zug, Switzerland.

Proposal Voting Process

After feedback and adjustments by the Curve community, Swiss Stake AG will create the on-chain voting proposal with the request for 21’000’000 CRV running for 7 days.

If the quorum of 30% is reached and the majority of the votes is yes, the vote is enacted to vest 21’000’000 CRV over one year to Swiss Stake AG.

Update

What is the grant going to be spent on?

We plan on developing and delivering a series of revolutionary technical features to be added to the Curve project software repositories. This includes:

• Technology which allows automatically scaling supply sinks for crvUSD such as staked crvUSD. This will also be made portable to other (even non-EVM) chains.

• Code to enable more collaterals for crvUSD such as LP tokens of Curve pools. Curve benefits from this enhanced capital efficiency, allowing liquidity to be utilized more effectively.

• Code for two-way lending markets (e.g. markets where one can borrow against collateral which can be borrowed itself).

• Code for multi-market semi-isolated lending.

• Enabling cryptoswap algorithm to be well integrated with crvUSD to allow for much more efficient forex pools. That also needs provision of the technical basis for non-USD variants of crvUSD.

• Enabling DAO cross-chain functionality (starting with boosts for pools deployed on non-Ethereum chains).

• We are planning on improving and transforming the UI/UX interface and experience, all code will be open source.

• Reworking governance site (e.g. dao.curve.fi), all code will be open source.

Optimized use of grants

We understand the importance of developing a sustainable business model that minimizes or ideally eliminates the need for future grant requests. Over the next 12 months, we will be actively working on this and will keep the community informed of our progress.

Furthermore, we are dedicated to use and spend the grant in a responsible and sustainable manner. Swiss Stake AG will stake the CRV received as part of the grant (and which are not immediately needed) with major liquid locker projects (such as e.g. Convex, StakeDAO, Yearn).

We acknowledge that continued funding is not guaranteed, and we remain committed to demonstrating our value alongside other organizations working toward similar goals.

Community Updates & Reporting

Swiss Stake AG will allocate the entire grant strictly according to the purposes outlined here. If any funds remain unspent within the next 12 months, these residual amounts will be rolled over into the next period.

We are committed to providing the community with regular updates on the status and progress of all technical features. Additionally, we will track and report the expenditure of funds across the following categories: 1) Security Audits, 2) Front-End Development, 3) Software Development, 4) Infrastructure, 5) Community & Tech Support, and 6) Research & Analytics. These reports will be made available to the community on a quarterly basis through the governance forum.

Vesting to a smart contract

Over one year, CRV tokens will be vested to a smart contract, from which Swiss Stake AG multisig can withdraw the CRV. In a dispute, Curve DAO can disable withdrawal for the multisig, then either re-enable it or send the CRV token back to the community funds.

Smart contract is located here.

43 posts - 20 participants

Read full topic

Summary

Proposal to adjust pool parameters of dlcBTC/wBTC pool for upcoming CurveLend integration

Motivation

On advice from both the Curve core team and Curve Research, we propose to change the pool parameters of dlcBTC/WBTC in order to be better optimized for integration into CurveLend, notably the increase of ma_exp_time to 2 hours.

ma_exp_time = increase from 866 to 10387 (7200 / log(2))
D_ma_time = 62324 (unchanged)

dlcBTC/WBTC: Curve.fi

For

Adjust dlcBTC/WBTC pool parameters

Against

Do not change dlcBTC/WBTC pool parameters (do nothing)

1 post - 1 participant

Read full topic

Summary:

Kill CRV emissions to the mentioned gauges.

Abstract:

All pools in the kill list are deprecated, either because the pools were redeployed (stUSDT, pufETH, vsdCRV), tokens were migrated (JPEG), or underlying protocol was deprecated (DCHF).

Motivation:

Gauges cleanup.

Specification:

ACTIONS = [
    # JPEG/ETH kill
    ('0x5a8fdC979ba9b6179916404414F7BA4D8B77C8A1', "set_killed", '0xfa49b2a5d9e77f6748bf05801aa22356d514137b', True),
    # DCHF/3CRV kill
    ('0x5a8fdC979ba9b6179916404414F7BA4D8B77C8A1', "set_killed", '0xb0a6f55a758c8f035c067672e89903d76a5abe9b', True),
    # pufETH/wstETH kill
    ('0xB6Ec26A3433D6CD11084c2094F12c4E571806D06', "set_killed", True),
    # stUSDT/crvUSD kill
    ('0xdf103acc4826c169b5e3ff874548cb82123e9f51', "set_killed", True),
    # CRV/asdCRV/vsdCRV kill
    ('0x017dB2B92233018973902858B31269Ed071E1D39', "set_killed", '0x25E822B65a58Ce1A53DbC327d4fA489351FB1Df0', True),
]

1 post - 1 participant

Read full topic

Summary:

Launch a Curve L2 in order to Mint crvUSD rather than Ethereum.
Frax has already launched an app chain Fraxtal, using fraxtal ETH as gas frxETH
Ideally Curve Chain should use crvUSD as gas token (such as xDAI for Gnosis)
Abstract:

Actually crvUSD is only minted on ETH mainet, which could be expensive for users.
Retails are using Llama lend only on Arbitrum.
Ethereum main net is quite expensive and Curve could miss some opportunity of yield.

Motivation:

-1 more fees for Curve Governance (Sequencer fees) + possible staked ETH yield if ETH gas or more utility to crvUSD
2 less fees paid by users on ETH mainet
3 possible launch of ETH LSD from Curve on this chain crvETH
4connections with other L2 if using a native connected chain

Specification:

Use Arbitrum, Optimism or Polygon zkEVM stack (OP and Polygon could have a native bridge to all similar L2 stacks)
Use an advanced bridge in order to move from Curvechain to other L2 (e.g. CCIP Chainlink, Layer Zero, Cosmos IBC)
(zk EVM seems using IBC tech from Cosmos SDK)

For:

More fees, business expansion, sovereign dapp

Against:

Curve is only a smartcontract level but not infrastructure
Poll:
Post a link to your proposal if it’s already been created

Click to view the poll.

5 posts - 2 participants

Read full topic