Inside Meta Yield
Meta Yield: A Variant of BASE Network Technology
Meta Yield is a variant of BASE Network technology that reduces costs by relying on a mild trust assumption. Unlike the BASE protocol, where all nodes, including validators, need access to L2 transaction data, Meta Yield employs an external Data Availability Committee (the "Committee") to store and provide data upon request. The Committee consists of N members, with Meta Yield assuming the honesty of at least two. This ensures that even if N-1 Committee members fail to provide access to certain data, at least one honest member will fulfill the promise. As a result, the chain can operate effectively with the assurance that necessary data will always be available when required.
Keysets in Meta Yield
A Keyset serves as a specification for Committee members' public keys and the required number of signatures for validating a Data Availability Certificate (DACert). This framework enables seamless modifications to Committee membership and facilitates key updates for its members. Each Keyset includes:
The total number of Committee members,
A BLS public key for each member, and
The required number of Committee signatures.
Keysets are uniquely identified by their hashes. The L1 Keyset Manager contract maintains a record of currently valid Keysets, which can be modified by the Owner of the L2 chain. Upon validation, the KeysetManager contract emits an L1 BASE event containing the hash and complete details of the Keyset, ensuring accessibility for future reference based solely on the Keyset hash. While the API places no restrictions on concurrent Keysets, typically, only one Keyset is active at any given time.
Data Availability Certificates (DACert)
A central concept in Meta Yield is the Data Availability Certificate (DACert). A DACert contains:
The hash of a data block,
An expiration time, and
Proof that N-1 Committee members have signed the (hash, expiration time) pair, consisting of:
The hash of the Keyset used in signing,
A bitmap indicating which Committee members signed, and
A BLS aggregated signature (over the BLS12-381 curve) proving that those parties signed.
Due to the 2-of-N trust assumption, a DACert constitutes proof that the block's data (i.e., the preimage of the hash in the DACert) will be available from at least one honest Committee member, at least until the expiration time.
In regular BASE protocol, the sequencer posts data blocks on the L1 chain as calldata. The hashes of the data blocks are committed by the L1 Inbox contract, allowing the data to be reliably read by L2 code.
Meta Yield provides the sequencer with two ways to post a data block on L1:
It can post the full data as done in regular BASE.
It can post a DACert proving the availability of the data.
The L1 inbox contract will reject any DACert that uses an invalid Keyset; other aspects of DACert validity are checked by the L2 code.
The L2 code reads data from the inbox in the same way as regular BASE. If it sees a DACert, it will check its validity, verifying:
The number of signers is at least the number required by the Keyset.
The aggregated signature is valid for the claimed signers.
The expiration time is at least two weeks after the current L2 timestamp.
If the DACert is invalid, the L2 code discards the DACert and moves to the next data block. If valid, the L2 code reads the data block, guaranteeing availability because the DACert is valid.
Data Availability Servers (DAS)
Committee members are responsible for operating the Data Availability Server (DAS) software, which offers two distinct APIs:
Sequencer API – Exclusively accessible to the Meta Yield chain's Sequencer, enabling the submission of data blocks to the DAS for storage via a JSON-RPC interface. This API is typically restricted to the Sequencer to maintain security.
REST API – Available globally and operates via RESTful HTTP(S) protocol. It allows data blocks to be retrieved by hash and is designed to be cacheable, often employing caching proxies or CDNs to enhance scalability and defend against DoS attacks.
Committee members have a vested interest in supporting the Sequencer API, while the REST API is available for global use. The flexibility of the DAS software allows for various storage configurations, including local files, Badger databases, Amazon S3, or redundant storage across multiple platforms. Optional caching mechanisms, such as memory-based caching using Bigcache or a Redis instance, further enhance performance.
Sequencer-Committee Interaction
When the Meta Yield sequencer produces a data batch it wants to post using the Committee, it sends the batch's data and an expiration time (usually three weeks into the future) via RPC to all Committee members in parallel. Each Committee member stores the data in its backing store, indexed by the data's hash. The member then signs the (hash, expiration time) pair using its BLS key and returns the signature with a success indicator to the sequencer.
Once the Sequencer has collected enough signatures, it can aggregate them and create a valid DACert for the (hash, expiration time) pair. The sequencer then posts the DACert to the L1 inbox contract, making it available to the Meta Yield chain software at L2.
If the Sequencer fails to collect enough signatures within a few minutes, it will abandon the attempt to use the Committee and fall back to the rollup mechanism, posting the full data directly to the L1 chain as in a standard BASE chain. The L2 software understands both data posting formats (via DACert or via full data) and handles each correctly.
This updated structure outlines Meta Yield's implementation using BASE Network technology while maintaining the core principles of trustless data availability and efficient blockchain scaling. The system ensures a balance of security, availability, and cost efficiency, leveraging advanced techniques such as Data Availability Committees, DACerts, and BLS signatures for blockchain integrity.
Last updated