zkDeal engineering · Platform Engineering

zkDeal vs shared-L2 proof stacks

Compare a finite, policy-bound zkDeal room with shared L2 proof bases, then inspect and test the public room-node execution boundary.

Oleg Iakushkin6 min read
L2 comparisonRoom nodeEVMArchitecture

GENERAL-PURPOSE L2 PROOF BASES

How zkdeal compares with shared-L2 proof stacks

Comparison scope

Comparison unit: This table compares proving and validation technology, not individual chains. Vanilla OP appears once as the optimistic benchmark. A proof family does not by itself determine data availability, sequencing, governance or exit rules.

Underlying technologyUsed by L2BEAT-listed systems (examples)Validation, data availability and canonical exitBest fit and relation to zkdeal
zkdeal RISC Zero room STF + Groth16Independent protocol • not yet L2BEAT-listedSelectable room profiles. On the Stage-oriented rail: a validity proof gates every checkpoint, Ethereum calldata binds genesis and transitions, and the selected exit policy turns proved balances into L1 claims.A bounded EVM workflow whose application policy, proof identity, clocks, assets and close are bound at room opening. It can begin in, return to or coordinate with a larger L2 ecosystem.
OP Stack + OPFP vanilla optimisticOP Mainnet • Ink • UnichainInteractive fault proofs; Ethereum data availability; Standard Bridge withdrawal waits seven days on mainnet.Best for continuous public execution and shared-chain composability; liquidity depth is deployment-specific. zkdeal complements it when one finite episode selects proof-gated room settlement and room-scoped L1 accounting.
SP1 Hypercube / Turbo OP Succinct validityMantle • Katana; SP1 also participates in TaikoIn full-validity mode, SP1 proves each accepted OP/EVM state update; Ethereum data availability; proof-backed bridge exit. OP Succinct can also expose an owner-controlled optimistic fallback.A strong fit for a full OP-compatible validity chain. zkdeal applies a smaller room lifecycle around one workflow.
SP1 ZK fault proofs OP Succinct Lite / 1RBase • Morph • Facet • Ethscriptions • CeloZK resolves disputes; the happy path remains optimistic, so canonical exits retain challenge mechanics. Celo also uses external data availability.A strong fit when OP compatibility is primary and ZK accelerates disputes. zkdeal requires validity at every accepted room checkpoint.
RISC Zero zkVM Kailua / multiproofTaiko • BOB • Ronin; zkdeal uses RISC Zero tooGeneral RISC-V execution proofs; a deployment may use full validity or ZK fault proofs; data availability and exit follow the host rollup.The same prover family supports different products: zkdeal proves a certified room journal; these integrations prove a continuing chain.
Linea proverLineaEVM-specific validity proof; Ethereum data availability; persistent rollup bridge.Linea serves public EVM composability. zkdeal adds task-scoped state, constrained calls/storage, L1 escrow and terminal close.
S-twoStarknet • ParadexCairo-focused STARK validity proofs; persistent rollup state and bridge; Ethereum settlement.S-two now appears in Starknet and Paradex. It is a strong fit for Cairo-based ecosystems; zkdeal is EVM-room oriented.
Boojum / ZK Stack; legacy ZKsync Lite stackZKsync Era • Abstract • Sophon • Lens • Cronos zkEVM • zkCandySeparate Matter Labs validity stacks: Boojum for ZK Stack and Era-era chains; legacy custom circuits for ZKsync Lite. Ethereum data for rollups or external data for validiums; exit follows the deployment.A strong fit for launching a ZK Stack chain with shared tooling. zkdeal offers a bounded room with per-workflow policy and close.
OpenVMScrollRISC-V zkVM-based EVM validity proof; Ethereum data availability; persistent rollup bridge.Scroll serves shared EVM execution. zkdeal focuses on a room-chosen, proof-pinned workflow policy, room-scoped liabilities and a deliberate end state.
AirbenderADI ChainRISC-V validity proof; Ethereum data availability; continuing L2 state and bridge.A strong fit for a policy-aligned general chain. zkdeal makes policy and decommissioning specific to each room.
zkProverSilicon • Wirex Pay ChainValidity proof with external committee data availability in these deployments.A strong fit for continuing application chains using committee availability. zkdeal's current Stage-oriented deployment uses Ethereum calldata; blob modes remain options on the broader deployment rail.

Platform advocate view

Add a bounded episode where a continuing chain is too broad

Shared L2s are excellent public execution substrates. zkDeal is interesting precisely because it is not trying to replace them. A room gives one deal, auction, game, or settlement episode its own policy, accounting boundary, checkpoint rhythm, and deliberate close—then hands the canonical result back to Ethereum.

That is a practical complement to an L2 strategy. Keep wallets, liquidity, and broad composability on the shared chain; move the high-value episode whose market rule and failure boundary deserve to be proved as one unit into a room.

  • Test the node and protocol packages together in the sibling layout they expect.
  • Inspect the published capability manifest instead of inferring production features from a container name.
  • Use hosted and standalone-loopback-dev as explicit modes with different responsibilities.

Demo / use it today

Run the public path

This walkthrough tests the public room-node workspace and reads its machine-readable capability contract. It demonstrates the bounded service boundary, not a complete hosted deployment.

Before you start

  • A Bash-compatible shell: Linux, macOS, or WSL on Windows. The copyable commands use POSIX shell syntax.
  • The public repositories still expect their legacy sibling folder names. Clone into the names shown in the terminal, and keep the pinned commits together in one parent directory.
  • Docker Compose; the final JSON projection also runs in a digest-pinned Node container.
  1. Build the boundary as shipped

    The node test service copies the source into the container, installs the pinned workspace dependencies, builds, and runs the test suite without depending on a host toolchain.

  2. Read the capability contract

    The manifest identifies the service routes, hosted validity-only mode, standalone loopback development mode, restart-safety properties, queue contract, and key-custody expectations.

  3. Do not force a broken image build

    The public split checkout does not include the umbrella BUSL license file copied by the node Dockerfile. Use the workspace test path or the published image until the public build context is made self-contained.

Create the sibling checkout

mkdir zkdeal-lab && cd zkdeal-lab

Fetch the required sources

git clone https://github.com/zkdeal/zkdeal-node.git app-node && \
  git clone https://github.com/zkdeal/zkdeal-protocol.git web3-protocol
Expected output shape
Cloning into 'app-node'...
Cloning into 'web3-protocol'...

Pin reviewed commits

git -C app-node checkout c8b4669 && git -C web3-protocol checkout 8a188a5
Expected output shape
HEAD is now at c8b4669
HEAD is now at 8a188a5

Build the room-node workspace

docker compose -f app-node/docker-compose.yml run --rm build
Expected output shape
packages/room-node build: Done

Run the room-node build and test gate

docker compose -f app-node/docker-compose.yml run --rm test
Expected output shape
packages/room-node test: Test Files 3 passed (3)
packages/room-node test: Tests 32 passed (32)

Inspect the declared service boundary

docker run --rm -v "$PWD:/w:ro" \
  node:22-bookworm@sha256:0557ac14e0d45d02ed563067b82856ca5e7aa3437fa28d98d4350ea9c3d9494a \
  node -e "const c=require('/w/app-node/packages/room-node/capabilities/room-node.json'); console.log(c.service,c.entrypoint.capabilities,Object.keys(c.modes))"
Expected output shape
zkdeal-headless-room-node /capabilities [ 'hosted', 'standalone-loopback-dev' ]

What this gives you: You can point an architecture review at a concrete `/capabilities` contract and a reproducible workspace gate instead of relying on a slide-level comparison.

Interactive expected I/O

Test and inspect the bounded room-node boundary

Source-pinned expected output

Select text directly in the player, pause at any point, or copy the complete transcript below.

Copy or read the complete transcript
$ mkdir zkdeal-lab && cd zkdeal-lab
$ git clone https://github.com/zkdeal/zkdeal-node.git app-node && \
>   git clone https://github.com/zkdeal/zkdeal-protocol.git web3-protocol
Cloning into 'app-node'...
Cloning into 'web3-protocol'...
$ git -C app-node checkout c8b4669 && git -C web3-protocol checkout 8a188a5
HEAD is now at c8b4669
HEAD is now at 8a188a5
$ docker compose -f app-node/docker-compose.yml run --rm build
packages/room-node build: Done
$ docker compose -f app-node/docker-compose.yml run --rm test
packages/room-node test: Test Files 3 passed (3)
packages/room-node test: Tests 32 passed (32)
$ docker run --rm -v "$PWD:/w:ro" \
>   node:22-bookworm@sha256:0557ac14e0d45d02ed563067b82856ca5e7aa3437fa28d98d4350ea9c3d9494a \
>   node -e "const c=require('/w/app-node/packages/room-node/capabilities/room-node.json'); console.log(c.service,c.entrypoint.capabilities,Object.keys(c.modes))"
zkdeal-headless-room-node /capabilities [ 'hosted', 'standalone-loopback-dev' ]
Video fallback generated with VHS 0.11.0

Pinned public inputs

Repositories and images used here

Public availability is not one license claim: protocol, examples, and testing are MIT; node, prover, and coordinator are public source under BUSL-1.1.