null
{
"dac": {
"membersCount": 1,
"requiredMembers": 1
},
"description": "Set of parties responsible for signing and attesting to the availability of data.",
"fallback": {
"value": "Ethereum",
"secondLine": "Calldata",
"sentiment": "good",
"description": "The data is posted to Ethereum as calldata.",
"projectId": "ethereum"
},
"risks": {
"committeeSecurity": {
"value": "1/1",
"sentiment": "bad",
"description": "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.",
"orderHint": -0.01
},
"upgradeability": {
"value": "No delay",
"sentiment": "bad",
"description": "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."
},
"relayerFailure": {
"value": "No mechanism",
"sentiment": "bad",
"description": "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."
},
"economicSecurity": {
"value": {
"value": "None",
"sentiment": "bad",
"description": "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."
},
"adjustSecurityRisk": false
},
"fraudDetection": {
"value": "None",
"sentiment": "bad",
"description": "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."
}
},
"technology": {
"description": "\n## Architecture\n\n\nThe DAC uses a data availability solution built on the AnyTrust protocol. It is composed of the following components:\n- **Sequencer Inbox**: Main entry point for the Sequencer submitting transaction batches.\n- **Data Availability Committee (DAC)**: A group of members responsible for storing and providing data on demand.\n- **Data Availability Certificate (DACert)**: A commitment ensuring that data blobs are available without needing full data posting on the L1 chain. \n\n\nCommittee members run servers that support APIs for storing and retrieving data blobs. \nThe Sequencer API allows the rollup Sequencer to submit data blobs for storage, while the REST API enables anyone to fetch data by hash. \nWhen the Sequencer produces a data batch, it sends the batch along with an expiration time to Committee members, who store it and sign it. \nOnce enough signatures are collected, the Sequencer aggregates them into a valid DACert and posts it to the L1 chain inbox. \nIf the Sequencer fails to collect enough signatures, it falls back to posting the full data to the L1 chain. \n\n\nA 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. \nThe proof consists of a hash of the Keyset used in signing, a bitmap indicating which members signed, and a BLS aggregated signature. \nL2 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. \nIf the DACert is valid, it provides a proof that the corresponding data is available from honest committee members.\n\n## DA Bridge Architecture\n\n\nThe DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge.\nThe 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.\nThe sequencer distributes the data and collects signatures from Committee members offchain. Only the DACert is posted by the sequencer to the destination chain inbox (the DA bridge), achieving destination chain transaction ordering finality in a single onchain transaction.\n ",
"risks": [
{
"category": "Funds can be lost if",
"text": "a malicious committee attests to an invalid data availability certificate."
},
{
"category": "Funds can be lost if",
"text": "the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades."
}
],
"references": [
{
"title": "Inside AnyTrust - Arbitrum Docs",
"url": "https://docs.arbitrum.io/how-arbitrum-works/inside-anytrust"
}
]
},
"type": "Data Availability Committee"
}