Immutable X DAC

There are no onchain assets at risk of being slashed in case of a data withholding attack. However, there is indirect economic security derived by the committee members being publicly known, and their reputation is at stake should they behave maliciously.

Fraud detection

None

There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layer.

2.2

Technology

Architecture

starkex architecture The Starkware application utilizes a data availability solution that relies on a Committee Service to ensure data persistence. This architecture comprises the following components:

Availability Gateway: The primary interface provided by the operator for committee members to access new batch information and submit signed availability claims.
Data Availability Committee (DAC): A group of nodes responsible for storing state data associated with each Merkle root and attesting to data availability by signing claims.
Data Batches: Collections of transactions processed in batches that update the state of accounts, resulting in a new Merkle root representing the updated state.

Committee members run services that interact with the Availability Gateway to obtain information about new batches and submit their signed availability claims. Each batch includes a unique batch_id, a reference to a previous batch, and a list of account updates. Committee members combine this information with data from the reference batch to compute the new state and verify the Merkle root.

When the operator produces a new batch, it must be signed by a minimum number of committee members—as defined by the application’s configuration—for it to be accepted onchain. This includes all members designated as mandatory signers. If the operator attempts to submit a batch without the required signatures, it will be rejected, thereby ensuring that data remains available and consistent.

Committee members are expected to maintain a database that stores the data associated with each batch, making use of storage solutions with a replication factor of at least 2.

StarkEx Committee Service - Source Code

DA Bridge

Immutable X DAC on Ethereum.

3.1

Risk analysis

Committee security

5/7

The committee should require an honest minority (33% or less) of members to prevent the DA bridge from accepting an unavailable data commitment. Currently, an honest minority is not able to prevent an unavailable data commitment from being accepted, as this committee requires 43% of members to be honest.

Upgradeability

Immutable

The bridge smart contract is immutable and cannot be updated. The bridge committee security is low and cannot be improved.

Relayer failure

Self propose

Anyone can relay data availability commitments to the DA bridge. In case of current relayer failure, users can collect attestations from committee members and propose new data availability commitments to the DA bridge.

3.2

Technology

DA Bridge Architecture

starkex bridge architecture The DA commitments are posted to the L1 chain, using the Committee Verifier contract as a DA bridge. The DA commitment consists of a data hash of the transaction batch the Committee has signed off on and a concatenation of ec-signatures by signatories. The Committee Verifier contract verifies the signatures and the data hash and if the required threshold of Committee members has signed off on the data, the hash is stored as a registeredFact in the StarkEx contract. In a separate transaction, the operator calls the updateState() function on the StarkEx contract to update the state. Before the state update is accepted, the StarkEx contract verifies the transaction public inputs by calling the isValid() function, which verifies the hash derived from state update inputs matches the hash stored by the Committee Verifier contract.