Fluence DAC
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.
Architecture
The DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:
- Sequencer Inbox: Main entry point for the Sequencer submitting transaction batches.
- Data Availability Committee (DAC): A group of members responsible for storing and providing data on demand.
- Data Availability Certificate (DACert): A commitment ensuring that data blobs are available without needing full data posting on the L1 chain.
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.
Fluence 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.
DA Bridge Architecture
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.
The system consists of the following permissions on Ethereum:
Address that can upgrade the DA bridge, upgrade authorized batch posters (relayers), and change the Committee members by updating the valid keyset (via UpgradeExecutor).
The contract used to manage the upgrade of the DA bridge and other contracts.
FluenceThe system consists of the following smart contracts on Ethereum:
Fluence