Search for projects by name
Set of parties responsible for signing and attesting to the availability of data.
There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known.
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.
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.
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.
The Starkware application utilizes a data availability solution that relies on a Committee Service to ensure data persistence. This architecture comprises the following components:
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.
ApeX DAC on Ethereum.
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.
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.
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.
Funds can be lost if a malicious committee signs a data availability attestation for an unavailable transaction batch.
List of addresses authorized to sign data commitments for the DA bridge.
List of addresses authorized to sign data commitments for the DA bridge.
Data Availability Committee (DAC) contract for USDC StarkEx instance, verifying data availability claim from DAC Members (via multisig check).
Data Availability Committee (DAC) contract for USDT StarkEx instance, verifying data availability claim from DAC Members (via multisig check).