Silicon 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
Polygon CDK validiums utilize a data availability solution that relies on a Data Availability Committee (DAC) to ensure data integrity and manage off-chain transaction data.
This architecture comprises the following components:
- Operator: A trusted entity that collects transactions, computes hash values for the transaction batch, and then requests and collects signatures from Committee members.
- Data Availability Committee (DAC): A group of nodes responsible for validating batch data against the hash values provided by the operator (sequencer), ensuring the data accurately represents the transactions.
- PolygonCommittee Contract: Contract responsible for managing the data committee members list. Each DAC node independently validates the batch data, ensuring it matches the received hash values. Upon successful validation, DAC members store the hash values locally and generate signatures endorsing the batch’s integrity. The sequencer collects these signatures and submits the transactions batch hash together with the aggregated signature on Ethereum. The PolygonCommittee contract is used during batch sequencing to verify that the signature posted by the sequencer was signed off by the DAC members stored in the contract.
Silicon 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 a data availability message provided as transaction input, made up of a byte array containing the signatures and all the addresses of the committee in ascending order.
The sequencer distributes the data and collects signatures from Committee members offchain. Only the DA message is posted by the sequencer to the L1 chain inbox (the DA bridge).
A separate contract, the PolygonCommittee contract, is used to manage the committee members list and verify the signatures before accepting the DA commitment.
Funds can be lost if a malicious committee signs a data availability attestation for an unavailable transaction batch.
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:
List of addresses authorized to sign data commitments for the DA bridge.
Admin and ForceBatcher of the SiliconValidium contract, can set core system parameters like replacing the sequencer (relayer), activate forced transactions, and set the DA committee members in the SiliconDAC contract.
The RollupManager can upgrade the DA bridge contract implementation.
SiliconThe system consists of the following smart contracts on Ethereum:
Validium committee contract that allows the admin to setup the members of the committee and stores the required amount of signatures threshold.
Upgrade delay: None
Silicon