Search

Search for projects by name

ZKFair DAC logoZKFair DAC

  • Type
    Data Availability Committee
  • TVS
    $12.41 M
  • Economic security

  • Duration of storage
    Flexible
  • Used by
  • Risks
  • Select a bridge
    DA Bridge
    $12.41 M

    Risk summary
    ZKFair DAC

    Set of parties responsible for signing and attesting to the availability of data.

    Risk analysis
    Economic security
    None

    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.

    Fraud detection
    None

    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.

    Committee security
    3/5

    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.

    Upgradeability
    No delay

    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.

    Relayer failure
    No mechanism

    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.

    Technology

    Architecture

    polygoncdk 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.
    1. Polygon CDK Validium Documentation
    DA Bridge

    ZKFair DAC on Ethereum.

    Risk analysis
    Committee security
    3/5

    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.

    Upgradeability
    No delay

    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.

    Relayer failure
    No mechanism

    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.

    Technology

    DA Bridge Architecture

    polygoncdk 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.

    Permissions

    The system consists of the following permissions on Ethereum:

    List of addresses authorized to sign data commitments for the DA bridge.

    ZKFairOwner 0x8933…3A88

    A Gnosis Safe with 3 / 4 threshold. Owner of the ZKFairValidium contract, can set core system parameters like replacing the sequencer (relayer), activate forced transactions, update the DA mode and change DAC members by upgrading the ZKFairValidiumDAC contract.

    Those are the participants of the ZKFairOwner.

    DAC Owner 0xa57c…0c70

    The owner of the ZKFairValidiumDAC contract, can update the committee member set at any time.

    Timelock Executor 0x7557…C527

    Controls the ZKFairValidiumDAC and ZKFairValidium contracts through the Timelock. Can upgrade the DA bridge contract implementation and committee members.

    Check all permissions for the scaling project here: ZKFair logoZKFair
    Contracts

    The system consists of the following smart contracts on Ethereum:

    The DA bridge and main contract of ZKFair. Contains sequenced transaction batch hashes and signature verification logic for the signed data hash commitment.

    Can be upgraded by:

    Upgrade delay: 1d delay.

    Validium committee contract that allows the admin to setup the members of the committee and stores the required amount of signatures threshold.

    Can be upgraded by:

    Upgrade delay: 1d delay.

    Timelock 0x5288…9c17

    Contract upgrades have to go through a 1d timelock unless the Emergency State is activated. It is controlled by the TimelockExecutor.

    Check all contracts for the scaling project here: ZKFair logoZKFair