Inside ALIENX

ALIENX is a variant of Arbitrum Nitro technology that lowers costs by accepting a mild trust assumption.AlienX, a variation of Arbitrum Nitro technology, reduces costs by relying on a slight trust assumption. Unlike the Arbitrum protocol, where all nodes, including validators, need access to L2 transaction data, AlienX employs an external Data Availability Committee ("the Committee") to store and provide data upon request. The Committee consists of N members, with AlienX assuming the honesty of at least two. This ensures that even if N-1 Committee members pledge to provide access to certain data, at least one honest member will fulfill the promise. Thus, the chain can operate effectively with the assurance that necessary data will be available when required.

Keysets

A Keyset serves as a specification for Committee members' public keys and the requisite number of signatures for validating a Data Availability Certificate. This framework enables seamless modifications to Committee membership and facilitates key updates for its members.Each Keyset encompasses:

• The total count of Committee members,

• A BLS public key for each member, and

• The necessary 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 Ethereum 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

A central concept in ALIENX is the Data Availability Certificate (hereafter, a "DACert"). A DACert contains:

• the hash of a data block, and

• 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, and

  • a bitmap saying which Committee members signed, and

  • a BLS aggregated signature (over the BLS12-381 curve) proving that those parties signed.

Because of 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 ordinary (non-AlienX) Nitro, the Arbitrum 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.

ALIENX gives the sequencer two ways to post a data block on L1: it can post the full data as above, or it can post a DACert proving availability of the data. The L1 inbox contract will reject any DACert that uses an invalid Keyset; the other aspects of DACert validity are checked by L2 code.

The L2 code that reads data from the inbox reads a full-data block as in ordinary Nitro. If it sees a DACert instead, it checks the validity of the DACert, with reference to the Keyset specified by the DACert (which is known to be valid because the L1 Inbox verified that). The L2 code verifies that

• The number of signers is at least the number required by the Keyset, and

• The aggregated signature is valid for the claimed signers, and

• 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 on to the next data block. If the DACert is valid, the L2 code reads the data block, which is guaranteed to be available because the DACert is valid.

Data Availability Servers

Committee members are responsible for operating the Data Availability Server (DAS) software, which provides two distinct APIs:

• The Sequencer API is exclusively accessible to the AlienX chain's Sequencer and facilitates the submission of data blocks to the DAS for storage via a JSON-RPC interface. Typically, access to this API is restricted to the Sequencer to maintain security.

• The REST API, on the other hand, is intended for global accessibility and operates through a RESTful HTTP(S) protocol. This API allows data blocks to be retrieved by hash and is designed to be fully cacheable. Deployments often employ 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 intended for wider 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. Additionally, optional caching mechanisms, such as memory-based caching using Bigcache or a Redis instance, further enhance performance and efficiency.

Sequencer-Committee Interaction

When the AlienX sequencer produces a data batch that it wants to post using the Committee, it sends the batch's data, along with an expiration time (normally three weeks in 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. Then the member 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 the signatures and create a valid DACert for the (hash, expiration time) pair. The Sequencer then posts that DACert to the L1 inbox contract, making it available to the AlienX 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 will "fall back to rollup" by posting the full data directly to the L1 chain, as it would do in a non-AlienX chain. The L2 software can understand both data posting formats (via DACert or via full data) and will handle each one correctly.