• Types of Nodes:
  • Full Nodes: The full nodes download the blocks and validate their correctness but do not participate in consensus. They store the blockchain but are not incentivized to participate or remain honest.
  • Validator Nodes: The validator nodes take part in block generation and decide on transaction inclusion and ordering. These nodes are incentivized to participate in consensus and host the blockchain. Essentially, they are also full nodes with stake in the system.
  • Note that Full nodes and Validator nodes are the reverse of the usual. Normally full nodes are validating nodes that retain the entire history.
  • Light Clients: These are clients with resource constraints who have access to only the block header and query transactional data from other full nodes on an as-needed basis. They want to have high confidence that the block is available, and when querying data they want a proof that the data belongs to the block.
• Fraud proofs
  • Fraud Proofs are for the case when the erasure coded chunks are misconstructed by the block producer. They are constructed by other full nodes in the system and propagated to the light nodes.
  • The light nodes verify the fraud proof and get convinced that the received block header is that of an erroneous block.
  • Having a single honest full node as a neighbour is sufficient for an honest light node to be guaranteed that it receives the fraud proof.
• Commitments
  • In simple erasure coded chunks, to proof that the encoding is incorrect, the entire original data block needs to be propagated to the light client. Hence, the fraud proof size is at least linear to the size of the block.
  • In a one dimensional erasure coding based design, once a block producer selects data chunks 𝐷1,...,𝐷𝑛, it encodes the chunks to generate 𝐷1, . . . , 𝐷2𝑛 (with coding rate = 0.5). It then constructs a Merkle tree over the chunks and keeps the root of it in the block header which acts as the commitment. A light client fetching 𝐷𝑖 gets a Merkle membership proof along with the data chunk so that it can quickly verify that a legitimate chunk has been supplied.
• Two alternative designs
  • Coded Merkle Tree
    • Uses systematic erasure codes
    • The process involves extending 𝑘 data chunks to 𝑛 chunks, with the first 𝑘 chunks being the original ones and the rest being parity symbols. Each chunk in the next layer is created from hashes of 𝑞 chunks from the previous layer. The same systematic erasure code is applied to each layer, and this process continues until we have 𝑡 hashes. These hashes serve as the commitment in the block header.
    • When a light node accesses a base layer chunk, it is provided with the chunk and a Merkle membership proof, ensuring the availability of both the base layer and the higher layers.
    • Analysis: potential attacks
      • The erasure coding in one or more layers is wrong.
      • The Merkle tree construction is wrong.
      • In both cases, the fraud proof captures it
  • Kate Commitment
    • The light clients querying a data block will sample some chunk 𝐷[𝑖][𝑗]. The light clients querying a data block will sample some chunk 𝐷[𝑖][𝑗] and it can immediately verify the validity using the Kate Commitment.
    • For full nodes, the system can have two types of full nodes: 1. classical full nodes having entire block, 2. Column full nodes which keep only a single column of the data. For classical ones, it takes the entire matrix 𝐷, extends each column to 2𝑛 points and getting an extended matrix 𝐷′.
    • For the column full nodes, they can fetch and keep only a column of the matrix 𝐷. They would extend each column to check whether they belong to the extended set of commitments.
    • The node can extend both to 2𝑛 points and immediately verify whether the extended openings are valid. If the number of such column full node is 𝑂 (𝑚), and each column full node ensures at least one column is available, then collaboratively the entire data is available within the column full nodes.
    • No fraud proofs are needed in this system.
    • Analysis: potential attacks:
      • Wrong commitment by block producer. Caught by light client w.o.p.
• Attack vectors of any DA layer
  • A super-majority of validators wants to change the ordering of a finalized block (consensus guarantees)
  • A super-majority of validators create the wrong block header (wrong commitment of the data)
  • A super-majority of validators wants to hide at least one chunk. A light node wouldn't be able to detect hiding of data. A full node wouldn't be able to reconstruct the data.