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 DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:
Committee members run servers that support APIs for storing and retrieving data blobs. The Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. When the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. Once enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. If the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. A DACert includes a hash of the data block, an expiration time, and proof that the required threshold of Committee members have signed off on the data. The proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. L2 nodes reading from the sequencer inbox verify the certificate’s validity by checking the number of signers, the aggregated signature, and that the expiration time is at least two weeks ahead of the L2 timestamp. If the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.
Re.al 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.
There is no delay in the upgradeability of the bridge. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridge does not have a Security Council or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
The DA commitments are posted to the L1 through the sequencer inbox, using the inbox as a DA bridge. The DA commitment consists of Data Availability Certificate (DACert), including a hash of the data block, an expiration time, and a proof that the required threshold of Committee members have signed off on the data. The sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the L1 chain inbox (the DA bridge), achieving L2 transaction ordering finality in a single onchain transaction.
Funds can be lost if a malicious committee attests to an invalid data availability certificate.
Funds can be lost if the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades.
Multisig that can upgrade authorized batch posters via the UpgradeExecutor contract.
The contract used to manage the upgrade of the DA bridge and other contracts.
This is a Gnosis Safe with 4 / 8 threshold. Multisig that can upgrade the DA bridge, upgrade authorized batch posters (relayers), and change the Committee members by updating the valid keyset (via UpgradeExecutor).
Those are the participants of the GelatoMultisig.