George Spasov

@Perseverance

Joined on Sep 27, 2018

  • Abstract This dpci,emt proposes the Conditions API, an extension to the Ethereum Builder API, allowing Ethereum proposers to specify constraints on blocks built by external builders. This ensures compliance with specific criteria and enhances the block building process for Ethereum’s external block builders. Motivation The current block building process lacks a mechanism for proposers to enforce validity conditions on blocks built by external entities. This document addresses this gap by introducing the Conditions API, enabling proposers to specify and authenticate conditions for block validity, thus enhancing security and compliance. Several groups of use-cases are made possible by this proposal. Inclusion Commitments This extension enables the proposer to commit to an inclusion of transaction in their block in a PBS setting. While the mechanism of commitment and commitment honouring validation is off the scope of this proposal, this extension enables the proposers to communicate their promises with the external block builders. Some use-cases that fall under this category:
     Like 2 Bookmark
  • hackmd-github-sync-badge TLDR GMEV-Boost is an upgrade/drop-in replacement software to MEV-Boost. Its main goal is to enable the connection between multiple L2 pipelines and the L1 pipeline. The design separates the pipelines to a single primary and multiple secondary pipelines. The primary pipeline deals with the L1 block building. The secondary pipelines deal with the production of the L2 sequencing transactions. The primary pipeline is extended with a Conditions API - an extension to the external block building API - implemented within the relays and used by proposers (through GMEV-Boost) and builders. It allows the proposer to specify validity conditions over their block that the relay needs to enforce. Validity conditions are expressed as complete transactions. GMEV-Boost requires access to the validator keystore (or other signing methods - f.e. Web3Signer) in order to enable the relays of the primary pipeline to authenticate the validator when validity conditions are submitted. The secondary pipelines are used to produce the L2 sequencing transactions. GMEV-Boost exposes an authenticated Pipelines API where the individual secondary pipelines submit their individual conditions. GMEV-Boost combines the conditions and submits them to the primary pipeline. Introduction
     Like  Bookmark
  • Vanilla Based Rollup is a conceptual design for a rollup. It suggests "Vanilla Based Sequencing" - a form of decentralised sequencing where the L1 block proposers are eligible to be the L2 sequencer during their L1 slot. The design is geared towards addressing practical problems of the rollups - addressing low initial participation by sequencers, enabling user experience features on par with centralised sequencing designs and suggesting mission-aligned revenue sources for the various actors. Next, the design explores a practical and viable mechanism for participation and orchestration of the duties of the L1 proposers-L2 sequencers. It suggests the convergence of the various block-building pipelines together by extending the existing interfaces and a new software GMEV-Boost. Last, the design suggests the mechanism for participation by L1 proposers in a vanilla based rollup. Introduction Vanilla Based Rollup is a conceptual design for a rollup. As the name suggests its roots come from the based rollup concept. Similarly to the original based rollup concept, vanilla based rollups are sequenced by the L1 proposer set, thus retaining its advantages - liveness, decentralisation, sovereignty, L1 alignment, etc. Vanilla based rollups extend the based rollups through the introduction of "Vanilla Based Sequencing". This is a form of decentralised sequencing aimed at addressing practical problems of original based sequencing and enabling user experience on par with centralised sequencing. The main differentiator between based and vanilla-based sequencing is the mechanism for the selection of an L2 sequencer if the current L1 proposer has not opted to be a sequencer for the rollup. Vanilla Based Rollup concept is also geared toward the support of preconfirmations. Current rollups with centralised sequencing offer a quick preconfirmation of inclusion and execution. This is now the standard that the users should come to expect for their transactions. The design suggests preconfirmations design and implementation mechanism for vanilla based rollups. Furthermore, this paper goes into exploration of how vanilla based rollups can be implemented. It suggests the extension of existing API interfaces and software components in order to implement the vanilla based rollup concept in practice. The two main development suggestions are GMEV-Boost - a drop-in, backwards-compatible replacement for MEV-Boost - and Conditions API - a backwards-compatible extension to the Ethereum External Builder API.
     Like 2 Bookmark
  • hackmd-github-sync-badge TLDR Vanilla Based Sequencing is a design for decentralised sequencing mechanism for rollups led by the L1 proposers. Its main goals are: Offer equal if not better UX compared to centralised sequencing in terms of preconfirmation time, guarantees and cost of transaction Enable the participating actors, including the rollup protocol itself, to generate revenue Enable composability with other rollups without the requirement to trust a single centralised sequencing layer Base its liveness guarantees on the Ethereum L1. Remove the need for trust towards a single party and ensure a sizable and diverse set of sequencers, so that within an acceptable timeframe a censored transaction will reach an honest sequencer that will be willing to sequence this transaction.
     Like 4 Bookmark
  • hackmd-github-sync-badge TLDR The L1 proposers opt-in to be sequencers via a two-step process - register and activate. Sequencers are eligible to be selected as sequencers after some time delay from their activation. Registration requires a signed message by the proposer validator BLS keypair in order to authenticate the request. Furthermore, the registration requires proof that the validator is still active. Registered sequencers advertise an RPC URL to be connected to and an execution layer address to represent them when sequencing. Sequencing transactions are accepted optimistically and rollups are to decide whether to enforce further sequencer eligibility validation for the sequencing or implement a challenge period. If Ethereum L1 exposes direct access from the execution layer to the L1 proposer BLS pubkey, the challenge period can be replaced with validation of the sequencer selection on submission. If an L1 proposer exits the L1 validator set, a forced deactivation can be triggered by any actor. Opt-in Mechanics
     Like  Bookmark
  • hackmd-github-sync-badge TLDR One major component of UX where centralised sequencers excel is the ability to quickly pre-confirm the inclusion and/or execution of a transaction to its sender. It is a naturally important requirement for vanilla based sequencing to strive to reach and surpass the expected UX. This document outlines the design and mechanics to support preconfirmations in Vanilla Based Rollups. It introduces two new transaction types in order to support the two preconfirmation types: Inclusion Preconfirmation - commitment to the inclusion of a transaction in a sequence Execution Preconfirmation - commitment to the inclusion and the resulting end state after the transaction. The constraints are specified as limited lists of the desired resulting storage slots, account balances and code hashes
     Like  Bookmark
  • L1 - refers to the Layer 1 - the main Ethereum blockchain governed and secured by the Ethereum consensus algorithm. It's the base layer of the ecosystem where transactions are validated and blocks are added to the blockchain. L1 Validator - node or entity that participates in the consensus mechanism of the L1. Validators play a crucial role in maintaining the security and integrity of the blockchain by validating and adding new blocks of transactions to the blockchain. L1 Proposer - a node or entity responsible for proposing new blocks of transactions to be added to the blockchain. Proposer Lookahead - a feature of the L1 consensus algorithm allowing the actors within the network to anticipate the upcomming proposers in advance. L2 - refers to Layer 2 network - a network aiming to enhance the scalability, speed, and functionality of the L1 by processing transactions off-chain while still benefiting from the security and decentralization of the Layer 1 network. Rollup - L2 solution bundling multiple transactions into a single transaction, which is then submitted to the L1 for data availability. L2 Sequencing - refers to the process of arranging, ordering transactions or events in a specific order within a block or transactions list and submitting them to the L1 L2 Sequencer - the actor performing the sequencing Based Sequencing - specific form of sequencing driven by the base L1, and the L1 proposer acts as L2 sequencer within their L1 slot. Liveness fault - a misbehaviour by the L2 sequencer characterised with missed enforcement
     Like  Bookmark
  • Secure without UX Sacrifices Current rollups with centralised sequencers offer superior UX compared to both L1 and rollups with decentralised sequencers. Firstly, due to their constant monopoly, they offer a quick preconfirmation of inclusion and execution. This is now the standard that the users expect from their transactions. Secondly, the rollups with currently centralised sequencers fulfil the rollup-centric future promise offering orders of magnitude cheaper transactions compared to L1. A goal for decentralised sequencing design would be to enable a rollup protocol to offer equal if not better UX compared to centralised sequencing in terms of preconfirmation time, guarantees and cost of transaction. Economically Sustainable
     Like 1 Bookmark
  • TLDR “Based Ticketing Rollup” concept is a design proposal for a decentralised rollup. It starts from the concept of a Based rollup and adds Execution Tickets to address its weak points. Rollup slots are defined as N (N>1) number of l1 slots where only one proposer - L2 proposer - can propose rollup sequence. N can be used to modify the sequencing velocity. The rollup protocol uses the L1 to offer two types of tickets - proposal tickets and enforcement tickets. Lottery draw among the proposal ticket holders determines the next X rollup slot proposers. These L2 proposers can propose the rollup transaction list. Tickets revenue flows into the rollup. Lottery draw among the enforcement ticket holders determines the next X rollup slot L2 enforcers. These L2 enforcers communicate and enforce validity rules of the proposed transaction list to the proposers. They can offer various UX services like preconfirmation with post-state commitments. Tickets revenue flows into the rollup. Any ticket holder needs to have a stake in order to be punished for misbehaviour. A natural extension is to tap in the massive Ethereum L1 stake via Eigen-Layer style restaking + opt-in slashing conditions. This will allow (or can be limited to only) L1 validators to buy tickets and perform the rollup protocol roles. Ticket holders of multiple rollups can enable Universal Synchronous Composability (USC).
     Like  Bookmark