Commitment

In cryptography, a commitment scheme is a two-phase protocol consisting of a commit phase and a reveal phase. During the commit phase, a party (the committer) generates a commitment—a short, fixed-size value derived from a secret message—and sends it to a receiver. This act "locks in" the secret. The scheme provides two essential security properties: hiding, which ensures the commitment reveals no information about the secret, and binding, which prevents the committer from later revealing a different secret than the one originally committed to.

Commitment schemes are implemented using cryptographic hash functions, such as SHA-256, in a construction known as a hash commitment. To commit to a value v, the committer typically generates a random nonce r and computes the commitment as C = H(r || v), where H is the hash function. The committer sends C to the verifier. Later, to reveal the commitment, they send the pair (r, v). The verifier can then recompute the hash to confirm it matches the original commitment C, verifying both the value and the committer's inability to change it.

In blockchain systems, commitments are a foundational building block. They are used in Merkle trees to commit to sets of transactions in a block header, in zero-knowledge proofs like zk-SNARKs to hide private inputs, and in privacy protocols such as confidential transactions. The concept is also central to verifiable delay functions (VDFs) and certain consensus mechanisms. By providing a way to prove prior knowledge or intent without immediate disclosure, commitments enable trustless interaction, data integrity, and advanced privacy features across decentralized networks.

A cryptographic commitment is a digital protocol that allows one party to commit to a chosen value while keeping it hidden, with the ability to later reveal the value in a way that is verifiably consistent with the initial commitment. This creates a binding and hiding promise, often implemented using a commitment scheme like a hash function. The committer sends a commitment string (e.g., commit = Hash(value, secret_nonce)) to a verifier. Later, to open the commitment, they reveal the original value and secret_nonce, allowing the verifier to recompute the hash and confirm it matches the initial commitment, proving the value was not altered.

The security of a commitment scheme rests on two core properties: hiding and binding. The hiding property ensures the commitment string reveals no information about the committed value before it is opened, protecting privacy. The binding property guarantees that once a commitment is sent, the committer cannot change the underlying value to a different one when they later open it, ensuring integrity. These properties are typically achieved through cryptographic assumptions, such as the collision resistance of hash functions or the hardness of discrete log problems in schemes like Pedersen commitments.

In blockchain systems, commitments are a critical primitive enabling advanced functionality. They are the core mechanism behind Merkle trees, where data blocks are hashed into a single root commitment, allowing for efficient and verifiable proofs of inclusion. zk-SNARKs and other zero-knowledge proofs rely heavily on commitments to hide user inputs while proving statement validity. Confidential transactions use commitments like Pedersen commitments to encrypt transaction amounts on-ledger. Furthermore, data availability sampling in scaling solutions like danksharding involves committing to large data blobs with a small fingerprint, such as a KZG polynomial commitment.

A common practical example is a sealed-bid auction. A bidder computes a commitment to their bid amount using a random nonce and submits only the commitment. This hides their bid from other participants (hiding) while locking them into their offer (binding). Once all commitments are received and the bidding period ends, bidders reveal their bids and nonces. The auctioneer can then verify each revealed bid against its earlier commitment, ensuring no one changed their bid after seeing others' commitments, thereby guaranteeing a fair and transparent outcome.

Beyond basic hash-based commitments, advanced schemes offer additional properties. Vector commitments allow committing to an ordered list of values and later opening a proof for a specific element at position i. Polynomial commitments, such as KZG commitments, enable a prover to commit to a polynomial and later generate succinct proofs that the polynomial evaluates to a specific value at a given point, which is fundamental to modern zk-rollups. Homomorphic commitments allow mathematical operations to be performed on committed values without opening them, enabling private computations, as seen in some confidential asset protocols.

A commitment is a cryptographic proof that cryptographically binds a dataset—such as a block of transactions or a state root—to a compact, verifiable digest. In the modular stack, these commitments act as the connective tissue between layers. For instance, a rollup's execution layer produces a new state root and commits to its transaction data, publishing this commitment (often as a Merkle root or KZG commitment) to a data availability layer like Celestia or EigenDA. This allows any verifier to check that the data exists without downloading it all, a property known as data availability sampling.

The security of the entire system hinges on the cryptographic soundness of these commitments. A fraud proof or validity proof (zk-proof) does not verify the execution from scratch; instead, it verifies that the execution was performed correctly relative to the committed data and starting state. If the data is unavailable (data withholding attack), these fraud proofs cannot be constructed, and the system cannot challenge invalid state transitions. Therefore, the commitment scheme must be binding (the prover cannot claim a different dataset) and often hiding (the digest reveals no information about the underlying data).

Different layers employ specialized commitments optimized for their function. The consensus layer (e.g., a Layer 1 like Ethereum) may commit to the rollup's state root in its own blockchain, finalizing it. Settlement layers use these commitments to verify proofs and resolve disputes. Data availability layers use them to enable light clients to verify data availability. This creates a chain of trust: a zk-rollup's validity proof commits to a state change; that proof is verified on a settlement layer which commits to the proof's validity; and the entire sequence is anchored in a robust consensus layer, with data availability guaranteed separately.