ApeX DAC

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

ApeX DAC on Ethereum.

3.1

Risk analysis

Committee security

3/5

The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridge and it is reliant on the assumption of an honest sequencer, creating significant risks to data integrity and availability.

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.