Request For Proposals: Decentralized Sequencer Selection

Aztec
,
1

The next version of Aztec will be launched as a fully decentralized network. Community discussion and feedback plays a vital role in decentralization, and one of our goals is to build Aztec as transparently as possible. For key network decisions we will be following a call for proposal method allowing anyone to submit proposals.

Up first on our roadmap: Decentralized Sequencer Selection

We are calling internal and external engineers, researchers, and projects to submit their ideas for discussion. Below you will find more information about how to get involved.

Sequencer Selection Overview

In order to effectively provide sequencer selection proposals and meaningful feedback, it may be valuable to understand the role of the sequencer within the context of Aztec. Here’s a basic diagram and brief overview of responsibilities - although we understand your proposal may require some alterations to this list, for example if your proposal includes separating execution from ordering.

sequencer selection RFP
sequencer selection RFP2672Ă—1566 284 KB

Requirements & Design Considerations

Proposals must meet the following requirements and design considerations. If your proposal doesn’t meet all requirements, please call out the missing requirements.

Decentralization:

  • Sequencer selection must be sufficiently sybil resistant
  • Sequencer selection should not prioritize the best hardware or largest actors
  • Hardware requirements for sequencers must be similar to those of Ethereum validators

Liveness:

  • Network participants must know in advance who the sequencer is for a given time slot
  • A rollup should be created in every given slot to reduce network latency even in periods of low transaction activity

Censorship Resistance:

  • Ensure the sequencer selection process is censorship resistant
  • Ensure transaction inclusion from a particular sequencer is censorship resistant

Privacy:

  • Should allow sequencers the option of anonymity during selection and block submission

Additionally, please consider standard good protocol design principles such as efficiency, complexity, and feasibility of being built within the next 6-12 months.

Responsibilities of the sequencer(s)

Participate in the sequencer selection protocol and if selected execute the following steps:

  1. Select pending transactions from the mempool
  2. Order transactions into a block
  3. Verify all private transaction proofs and execute all public transactions to check their validity
  4. Compute the ROLLUP_BLOCK_REQUEST_DATA, which includes: private state database updates, public state updates, and KZG blob commitments (EIP-4844)
  5. Compute state updates for messages between L2 & L1 (docs)
  6. Broadcast the ROLLUP_BLOCK_REQUEST_DATA to the prover network via the proof pool for parallelizable computation.
  7. Build a rollup proof from completed proofs in the proof pool
  8. Tag the pending block with an upgrade signal to facilitate forks
  9. Publish completed block with proofs to Ethereum as an ETH transaction

For further information please consult the Aztec documentation. It may be worth noting that these are the current responsibilities, and may need to be adjusted based on the proposed solution.

Other Considerations & potential areas of interest

Submission Format

To ensure consistency and facilitate the review process, kindly adhere to the following submission format:

Title: A concise, descriptive title for your proposal
Summary: A brief summary of your proposal (150-300 words)
Details: Explain the sequencer solution, its components, and its functionality
Comparisons: Explain what makes this solution unique and different from alternative solutions
Feasibility: Explain the ability to implement this solution within the next 6-12 months
Questions: Any outstanding questions

Submissions should be created as a new post on this forum, tagged sequencers and rfp. Once the new post is created, please refer back to this RFP and post a short description + link your proposal.

Potentially helpful references

  1. Single Secret Leader Election - Dan Boneh & others

  2. Leader Election from Randomness Beacons and Other Strategies - a16z

  3. SASSAFRAS - polkadot

  4. Provable Single Secret Leader Election - Mary Maller

  5. Low-overhead secret single-leader election - Justin Drake

  6. Secret non-single leader election - Vitalik

  7. Endgame - Vitalik

  8. Whisk: A practical shuffle-based SSLE protocol for Ethereum - George Kadianakis & others

Grants

Complete proposals may be eligible for a retro-active cash grant and swag.

FAQ

We anticipate that you may have questions regarding the call for proposals. The following frequently asked questions and their corresponding answers should provide some clarification. Otherwise, feel free to contact cooper@aztecprotocol.com, or follow us on Twitter for updates.

Q1. How will a proposal be chosen?

A1. Proposals will be evaluated based on their adherence to the requirements and design considerations, as well as the quality, feasibility, and innovation of the proposed solution. The selection committee, consisting of Aztec Labs employees and possibly external stakeholders, will determine the winning proposal and share the chosen solution publicly.

Q2. Who can submit proposals?

A2. Researchers, developers, and technology enthusiasts with an interest in decentralized sequencer solutions are encouraged to submit their proposals.

Q3. Can I submit more than one proposal?

A3. Yes, you can submit multiple proposals if you have different ideas for sequencer solutions.

Q4. What if my proposal does not fully meet the requirements?

A4. We still encourage you to submit your proposal and participate in the discussion, as your ideas could contribute valuable insights and help shape the final solution.

Questions & clarifications (post publication)

  • Due to the nature of UTXO based privacy, and Aztec’s use of a nullifier tree, each block must be built from the last confirmed block, with a valid zk proof proving the state transition. If this is not the case, the nullifier non membership proofs would not be valid.

DISCLAIMER

The information set out herein is only conceptual and describes Aztec’s future development goals. In particular, the network roadmap is being shared in order to outline some of the plans for Aztec and is provided solely for informational purposes only and does not constitute any binding commitment. Please do not rely on this information for any purpose - the development, release, and timing of any products, features or functionality remains subject to change.

80 Likes
2
61 Likes
3

Why not just use Chainlink’s decentralized sequencer?

63 Likes
4

Fair Sequencing Services: Enabling a Provably Fair DeFi Ecosystem can read more on there design here.

I think this is a much better and safer alternative that trying to kickstart your own set of sequencers.

61 Likes
5

Edit: linking to new post (missed that bit)

52 Likes
6

Is this live? Do you have documentation past the initial spec?

Thanks for the suggestion!

5 Likes
7
5 Likes
8

Use L1 to drive sequencing?

4 Likes
9

Hey @0x-Stoic I think in general, we could use something like “based/L1 sequencing” but it begs a few other questions in Aztec’s context - specifically, who’s responsibility does it become to: execute state transitions, coordinate the proving network, and aggregate transactions into a final zk rollup. It sounds like the suggestion is piggyback on L1 validators/proposers/searchers/builders, and have them do some ~aztec specific~ work? Is that generally correct, or could you provide some comments on how you’d map this proposal to our usecase/context? Due to how much work an Aztec sequencer (or whomever is publishing the rollup) may require, it may not be reasonable to expect L1 node operators would do so. But that’s just my initial reaction! Appreciate the contribution/discussion.

3 Likes
10

Thanks for opening this up! Properly decentralizing sequencer trully matters when it comes to build scalable and secure rollups.

Do you have any due dates for submission?

3 Likes
11

I am by no means an expert on based rollups. In fact, I am still trying to wrap my head around it; but I do see its benefits as detailed by Justin Drake. That said, I agree that L1 node operators will not be able to carry out all the work. These would be done at L2. For state transition execution, does it have to be done by any designated entity? If the sequence is determined by L1, then the state transitions become deterministic and every L2 node will know them. I am not sure I understand the need to coordinate with the proving network. Thought the users generate the proof locally and then submit them to Aztec/L2. So not sure what needs to be proved, unless you mean some entity needs to coordinate the proving of the aggregate proof and push down to L1?

2 Likes
12

I had the same reaction when I saw Justin Drake’s proposal a while ago. Despite risking to sound like an EigenLayer shill (I’m in no way associated with the project, also they have no token) - I have to say that I think that’s exactly where EigenLayer fits in nicely. It allows validators to opt in to take on addittional duties, possibly exposing them to additional slashing conditions in exchange for additional yield. I don’t think just “possibly some MEV in the future” is strong enough of an incentive to take on the amount of work required.

3 Likes
13

Great question! Currently targeting May 23rd for submission, and leaving some time afterwards for discussions + deliberation. However if you’re working on a proposal and believe this deadline cannot be met for any variety of reasons, please reach out - I’d love to chat!

5 Likes
14

I am a fan of Eigenlayer. I think it is great for protocols that are not able to bootstrap a trust network. However, for Aztec and most L2s, I dont think that will be an issue. And I dont buy the pooled security argument that Eigenlayer will afford every protocol Eth L1 level security. The validators have to opt-in, and with Eigenlayer having access to the stakers’ withdrawal credentials, and each EL project having varying levels of slashing vulnerabilities, it will be interesting to see how many actually opt-in. Additionally, for Aztec there is the overlap risk. If there is a high overlap between Aztec Eiglenlayer stakers and other projects’, any one single project’s mass slashing due to unintended vulnerabilities will impact the other projects’ validator set

3 Likes
16

That’s why I’m more of a fan of the LSD variation

3 Likes
17

Awesome, will get back to you on this!

5 Likes
18

From the Aztec team’s perspective, do you anticipate there’d be advantages to doing some parts of the Sequencer Selection protocol’s chain execution side endogenously in Noir? i.e. leveraging what you think would be good uses of Noir’s private state and selective disclosure capability differentiations. (Though as I write this, I feel like this is a phase2/follow on topic, it would still be interesting to know if there is any early thinking about this point)

5 Likes
19

How to select Sequencer, is there a point calculated system?

4 Likes
20

Definitely, @zac-williamson should be submitting a proposal soon that does just this. There are some trade-offs.

  1. The sequencer selection process likely has a role to play in the network upgrade process especially if you follow the ETH model of pure social consensus. This means that if the selection process uses Noir transactions and there was a bug, it could be quite fatal for the network if exploited.
  2. It is harder to bootstrap institutions e.g Fireblocks as they have to integrate the L2 on day 1, vs just an ETH contract.
  3. However running the process on L2 has benefits:
  • Easily add privacy to the sequencer, and payment of any block rewards / fees
  • Fees will be far cheaper than on L1
  • The algorithm can be more computationally expensive, as its wrapped in a zkp.
3 Likes
21

Excellent question. We’re in the process of finalizing the selection criteria, which is planned to be communicated when the submission period concludes and deliberations begin (to not bias submissions). Probably not a point based system, but that is one of the options on the table. Another idea is ranked choice voting from a number of well educated experts across a variety of teams (eng, product, cryptography, commercial, etc). Do you feel strongly about any particular decision making framework? After deliberations, we’ll share the selected proposal(s) that will continue being pursued for further testing/simulations/modeling, with eventually 1 resulting in an implementation.

Perhaps worth noting that as the protocol and community expand, I imagine a more well established process for collective decision-making, integrating with @joshc’s AZIP process: [Proposal] Aztec Improvement Proposal (AZIP) Process.

Thanks for the time & interest! Let us know what other questions you have :smile:

4 Likes