You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
zero-knowledge proofs represent programs as circuits, where a prover generates a proof from public and private inputs, and a verifier computes the output if the statement is correct (without any information regarding the private input).
three fundamental characteristics define a zkp:
completeness (if a statement is true, then an honest verifier can be convinced by an honest prover that they possess knowledge about the correct input).
soundness (if a statement is false, then no dishonest prover can unilaterally convince an honest verifier that they have knowledge about the correct input).
zero-knowledge (if the state is true, then the verifier learns nothing more from the prover other than that).
zk proofs use cases:
private transactions: blockchains such as zcash, with privacy-preserving txs.
verifiable computations: decentralized oracle networks, providing smart contracts with access to off-chain data.
highly-scalable and secure l2s: verifiable computations through methods such as zk-rollups, validiums, and volition by they use l1s as a settlement layer.
decentralized identity and authentication: zkps can underpin identity management systems to enable users to validate their identity.
zk-rollups
zk-rollups write transactions to ethereum as calldata, using compression techniques to reduce transaction data. while calldata is not stored as part of the evm's state, it persists on-chain as part of the chain's history logs.
the zk-rollup's state, which includes l2 accounts and balances, is represented as a merkle tree.
users in the zk-rollup sign transactions and submit them to l2 operators for processing and inclusion in the next batch. in some cases, the operator is a centralized entity (the sequencer), that executes transactions, aggregates them into batches, and submits to L1.
the rollup contract won't automatically accept the proposed state commitment until the operator proves the new merkle root resulted from correct updates to the rollup’s state (this comes from validity proofs).
goals:
lower gas fees (by tx baches and submitting minimal on-chain data)
higher throughput (fast tx speeds, reduced confirmation times, up to 100x)
fastter confirmation time (no need to wait for block confirmations on the base layer, finality on l2)
privacy (no info about the tx is leaked, concealing tx amounts and recipients)
proof generation costs can be high (reducing proof generation costs involves using more efficient proof systems or circuit designs or incentivizing provers).
high circuit complexity can affect zk-rollups' scalability and usability
compatibility issues (not fully compatible with existing smart contracts or tools)