---
title: "ZK rollupとは？zero-knowledgeとrollups-as-a-service（RaaS）の完全ガイド"
description: "ZK rollupsの仕組み、optimistic rollupsとの比較、そしてrollups-as-a-serviceが実際に何を代行してくれるのかを解説します。"
---

# ZK rollupとは？zero-knowledgeとrollups-as-a-service（RaaS）の完全ガイド

<ImageBlock
  src="https://media.alchemy.com/blog/zk-rollup-complete-raas-guide-hero.png"
  alt="ZK Rollup RaaS完全ガイド"
  width={1920}
  height={900}
  priority
/>

過去10年近く、「ZK rollupの上に構築すべきか」という問いへの正直な答えは「まだ早い」だった。validity proofの生成には数分かかり、実際にコストもかさんだ。通常のEVMバイトコードを証明システムに通す作業は、デプロイ対象というよりリサーチプロジェクトに近かった。

それが急速に変わった。[Ethereum Foundationのzkevm security roadmap](https://blog.ethereum.org/2025/12/18/zkevm-security-foundations)によれば、約1年でEthereumブロックのproving latencyは16分から16秒に短縮され、proving costは45分の1にまで下がった。ZK rollupsはtrustをproofに置き換える。残っている論点は、この技術が機能するかどうかではなく、自前でチェーンを運用することがそれに伴う運用負荷に見合うかどうかだ。

## ZK rollupとは何か

[zero-knowledge rollup](https://www.alchemy.com/blog/zero-knowledge-rollups)は、トランザクションをmain chainの外で実行し、その結果得られたstateが正しいことを示すcryptographic validity proofをbase layerに投稿するスケーリング設計だ。base layerはそれらのトランザクションを再実行しない。proofを検証するだけだ。

数学のテストを提出する場面を思い浮かべるとよい。採点者は各問題を解き直すのではなく、短い証明書を確認する。証明書は小さく、確認は速く、誤った答えから有効な証明書は生成できない。この非対称性がメカニズムのすべてだ。proofの検証コストは、その裏にあるトランザクションを実行するコストよりはるかに小さいため、rollupは同じbase layerのcapacityでずっと多くのthroughputを処理できる。

「zero-knowledge」という名称は誤解を招きやすい。これはproof systemの性質を表すものであり、チェーンのprivacy特性を表すものではない。ZK rollup上のトランザクションは、Ethereumと同様、デフォルトで公開されている。proofはverifierが再実行することなくstate transitionが有効であることを証明するものであり、これはsuccinctnessの性質であって機密性の性質ではない。実際のprivacyには意図的な追加の作業が必要で、通常はencryptionか、その上に構築された専用のprivacy layerが要る。

したがって、ZK rollupはスケーリングとfinalityに関する判断として捉えるべきだ。confidentialityが必要なら、それは別の設計課題として自分で解決する必要がある。

## ZK rollupはどのように機能するか

4つのコンポーネントが役割を分担し、順番に処理を引き継いでいく。

- **sequencer**は、ユーザーからトランザクションを受け取り、順序付けしてbatchにまとめる。ユーザーが速い確認を得られるのはこの仕組みによるもので、base layerに何かが届くよりずっと前の段階で起こる。
- **prover**は、そのbatchを受け取り、通常は[SNARKまたはSTARK](https://www.alchemy.com/overviews/snarks-vs-starks)であるvalidity proofを生成する。これは、それらのトランザクションを直前のstateに対して実行すると新しいstateが得られることを証明するものだ。
- **verifier contract**はbase layer上にある。proofを検証し、それが有効であれば新しいstate rootをcanonicalなものとして受け入れる。
- **data availability layer**は、誰でもrollupのstateを独立して再構築でき、operatorが何かを隠していないことを検証できるだけのトランザクションデータを保存する。

state自体は[Merkle tree](https://www.alchemy.com/docs/what-are-merkle-trees)で管理されており、単一のroot hashがすべてのaccount balanceとcontract slotをコミットする。受理されたbatchごとにこのrootが更新されるため、base layerはrollupの全stateではなく、この小さなコミットメントだけを保持すればよい。

この最後の要素であるdata availabilityが、経済性を最も大きく変えた部分だ。rollupはかつて、batchデータを公開するためにbase layerのcalldataに料金を支払っていたが、これは高コストであり、しかもオンチェーンに永続的に残るものだった。EthereumのDencunアップグレードは2024年3月にblobsを導入した。これは別料金で価格付けされ、まさにこの用途向けにサイズ設計されたデータレーンだ。blobデータは永久に保持されるのではなく、約18日後にpruneされる仕様で、これは意図的なものだ。rollupのデータは無期限に残す必要はなく、誰かがダウンロードしてチェーンのstateを再構築できる程度の期間だけ入手可能であればよい。2025年12月にFusakaとともにリリースされたdata availability sampling機能であるPeerDASにより、より大きなblob countを安全に運用できるようになった。capacityの増加自体は、blobのパラメータのみを変更する小規模な後続forkによってもたらされた。

data availabilityは、かつてのような支配的なコスト項目ではもはやない。今日rollupのコストを見積もるチームにとって、重要なのはproof generationとsequencer operationsのコストであり、古いcalldataの前提に基づいて作られたコストモデルは桁が1つ違ってくる。

## ZK rollupがビルダーにとって重要な理由

feeが下がるのは、1つのbatchを投稿・検証するコストが、その中のすべてのトランザクションに分散されるためだ。throughputが上がる理由も同じで、base layerのcapacityがtransaction executionではなくproof verificationによって制約されるようになるからだ。

withdrawalはchallenge windowなしで決済される。[optimistic rollup](https://www.alchemy.com/overviews/optimistic-rollups)はbatchを、誰かが異議を申し立てない限り有効とみなすため、慣例的に7日間のdispute periodの間withdrawalを保留する。validity proofは検証された時点ですでに正当性を証明しているため、待つべきものが何もない。layer間で価値を移動させる場面では、この違いこそがユーザーが実際に体感する差だ。

verifiabilityはdata availabilityの要件から生まれる。batchデータが公開されるため、誰でもrollupのstateを独立して再構築できる。したがってoperatorは、誤ったstateをコミットすることも、それを検証するために必要なデータを保留することもできない。ただし、これによってcensorship resistanceが得られるわけではない。sequencerはあなたのトランザクションを黙って含めないこともでき、どれだけデータが公開されていても、そもそもsequenceされなかったトランザクションを明らかにすることはできない。この保護はforced-inclusion pathから得られるもので、ユーザーがbase layerのcontractに直接トランザクションを提出すると、rollupはそれを取り込む義務を負う。あるチェーンを評価する際は、このescape hatchが存在し、operatorの協力なしに機能することを確認するべきだ。

これらを総合すると、ZK rollupsは、settlement速度とper-transactionコストが実装の詳細ではなくプロダクトの機能そのものであるアプリケーションにとって、妥当なデフォルトの選択肢となる。payments、exchanges、gamesはその違いをすぐに体感する。低頻度のアプリケーションではおそらく体感されない。

## ZK rollupはどのようにsmart contract統合をサポートするか

任意のsmart contract executionを証明することは、単純なtransferを証明することよりはるかに難しい。これが、初期のZK rollupsがpaymentsとswapsしかサポートしていなかった理由だ。EVMバイトコードを証明するということは、あらゆるopcodeをproof system内のconstraintとして表現することを意味し、EVMはそもそもそれを想定して設計されていない。

[zkEVM](https://www.alchemy.com/overviews/zkevm)がその答えであり、実装によってEthereumとの近さは異なる。あるものはEthereumのexecution layerを直接証明し、compatibilityを最大化する代わりにproving performanceを犠牲にする。別のものはバイトコードやstate treeを調整してprovingを安価にするが、その分、一部のcontractやtoolingは動作前に調整が必要になる。zkEVMを評価する際は、そのcompatibilityラベルではなく、自分たちが実際に依存しているものと照らして確認すべきだ。

これをリサーチ課題たらしめていたperformance gapは、大きく縮まった。Ethereum Foundationによれば、proverは現在、対象ハードウェア上でEthereumブロックの99%を10秒未満で処理できる。これはper-blockのproving計測値であり、上で挙げたend-to-endのlatency値とは異なる指標だ。現在の焦点はspeedからsecurityへと移っている。公開されているroadmapは、2026年末までの目標として128-bit provable securityと300 KiB未満のproof sizeを掲げており、それと並行してrecursion architectureのformal verificationも行われる。

proving speedは、もはやproduction向けzkEVMとの間にある障壁ではない。それよりも、あるチームにsecurity proofsがどこまで進んでいるかを尋ねるべきだ。

## ZK rollupはoptimistic rollupとどう比較されるか

どちらもトランザクションデータをbase layerに投稿し、どちらもそのsecurityを継承する。両者が異なるのは、base layerに何を信じさせるかという点だ。

<EmbeddedTable
  table={{
    columns: [
      { key: "1", width: 190, title: "Dimension", dataType: "object" },
      { key: "2", width: 250, title: "ZK rollups", dataType: "object" },
      { key: "3", width: 280, title: "Optimistic rollups", dataType: "object" },
    ],
    data: [
      {
        "1": { title: "<p>Proof model</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Validity proof with every batch</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>Fraud proof, only if challenged</p>",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        "1": { title: "<p>Withdrawal to L1</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Once the proof is verified</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>After the dispute window, conventionally 7 days</p>",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        "1": { title: "<p>Cost profile</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Proof generation is the main overhead</p>",
          tooltip: "",
          icon: "",
        },
        "3": {
          title: "<p>Cheap to operate, cost sits in the challenge system</p>",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        "1": { title: "<p>EVM compatibility</p>", tooltip: "", icon: "" },
        "2": {
          title: "<p>Varies by zkEVM, strong and improving</p>",
          tooltip: "",
          icon: "",
        },
        "3": { title: "<p>Near-complete, mature</p>", tooltip: "", icon: "" },
        id: 3,
      },
      {
        "1": { title: "<p>Security assumption</p>", tooltip: "", icon: "" },
        "2": { title: "<p>Cryptographic</p>", tooltip: "", icon: "" },
        "3": {
          title: "<p>Economic, requires at least one honest challenger</p>",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
    ],
  }}
/>

Optimistic rollupsは運用コストが安く、EVM compatibilityでも長い先行期間があった。これが、activityで見た最大規模の汎用L2sが今なおoptimisticである理由だ。ZK rollupsはprovingにコストを払う代わりに、より速いsettlementと、economicではなくcryptographicなtrustモデルを得る。

汎用ワークロードにおいて、もはやどちらかが一方的に優れているわけではない。速く、trust-minimizedなsettlementにprovingコストを払う価値があるならZKを選び、生の運用コストと最大限のEVM compatibilityの方が重要ならoptimisticを選ぶとよい。

## rollups-as-a-service（RaaS）とは何か

かつてrollupを立ち上げるということは、sequencer、prover、bridge contract、data availability pathを自前で構築し、その4つすべてを無期限に稼働させ続けることを意味していた。それはfeatureではなく、chain teamそのものだ。

Rollups-as-a-serviceは、そのスタックをproviderが代わりに運用してくれるものに変える。frameworkを選び、パラメータを設定すれば、providerがその下でsequencer、prover、bridge、node infrastructureを運用する。手元に残るのはチェーンそのものであり、fee token、gas policy、transaction ordering rules、そして共有チェーンでは決して自分の代わりに強制してもらえないcompliance logicなどが含まれる。

初期のRaaSのセールストークのうち古びてしまった部分は、これが5分で終わって手放せる作業だという示唆だ。ゼロから構築するよりも圧倒的に速いのは事実であり、on-callの負担も取り除いてくれる。しかし、architectureに関する意思決定は取り除いてくれない。どのbase layerにsettleするか、data availabilityのトレードオフをどうするか、sequencer decentralizationをどう進化させるか、underlying stackへのupgradeをチェーンを壊さずにどう反映させるかは、依然として自分で決める必要がある。

RaaSはoperationsのoutsourcingであって、designのoutsourcingではないと捉えるべきだ。このモデル自体についてより詳しく見るなら、[rollups-as-a-service](https://www.alchemy.com/overviews/rollups-as-a-service-raas)と[RaaS and appchains](https://www.alchemy.com/overviews/what-are-rollups-as-a-service-appchains)で取り上げている。

## 自前のZK rollupを立ち上げる判断が理にかなうのはどんな場合か

専用のrollupは、いくつかの特定の状況においてそのcomplexityに見合う価値を発揮する。

- **予測可能で高いtransaction量。** 継続的に大量のblockspaceに対して料金を払っている状況になれば、専用capacityの方が共有capacityを奪い合うより価格面で有利になり始める。
- **共有チェーンでは満たせないcompliance要件。** allowlistされた参加者、transaction単位のpolicy、法域上の制約などは、自分が管理するチェーン上でのみ強制可能で、他では不可能だ。
- **専用blockspaceに依存するプロダクト体験。** 無関係なmintがネットワークを混雑させたせいで確認時間が悪化してはならないなら、blockspaceを共有することはリスクになる。

volumeが投機的な段階では、これは誤った判断となる。managed providerは運用負荷を吸収してくれるが、それでもbridge security、sequencer liveness、追跡すべきupgrade cadenceを自分で引き受けることになる。このattack surfaceは、見込みのdemandではなく実際のdemandに対して引き受ける価値がある。[rollupsのbusiness model](https://www.alchemy.com/overviews/the-business-model-of-rollups)は、決断する前に読んでおく価値がある。チェーンは自らの運用コストを稼ぎ出さなければならないからだ。

多くのチームにとってより良い選択は、まず標準の[RPC access](https://www.alchemy.com/rpc-api)を通じて確立されたチェーン上でshipし、利用パターンが根拠を示すようになってから再検討することだ。決断を先延ばしにするコストはごくわずかだが、立ち上げるべきでなかったチェーンを畳むコストは大きい。

<CardWithCta
  text="独自のチェーンの立ち上げについて、Rollupsチームにご相談ください"
  ctaLabel="お問い合わせ"
  ctaHref="https://www.alchemy.com/contact-sales-rollups?utm_source=zk_rollup_guide&utm_medium=overview&utm_campaign=rollups"
  theme="light"
/>

## zero-knowledge rollupsに関するFAQ

### ZK rollupとは何か

ZK rollupは、トランザクションをoffchainでbatchとして実行し、結果として得られるstateが正しいことを証明するcryptographic validity proofをbase layerに投稿するLayer 2 scaling solutionだ。base layerはトランザクションを再実行する代わりにproofを検証するため、コストが下がりthroughputが上がる一方で、base layerのsecurityを継承する。

### ZK rollupはどのように機能するか

sequencerがトランザクションをbatch化し、proverがSNARKやSTARKなどのvalidity proofを生成し、base layer上のverifier contractがそのproofを検証してから新しいstate rootを受け入れる。トランザクションデータは公開されるため、誰でも独立してrollupのstateを再構築できる。現在Ethereumのrollupsは、そのデータをcalldataではなくblobsで公開している。

### ZK rollupはprivateなのか

いいえ、デフォルトではprivateではない。「zero-knowledge」はproof systemを表す言葉であり、verifierがstate transitionを再実行することなくそれが有効であることを確認できることを意味する。ZK rollup上のトランザクションは、Ethereumと同様、公開されて誰でも見ることができる。confidentialityが必要なら、その上に意図的に構築される追加のprivacy layerが必要になる。

### ZK rollupはoptimistic rollupとどう違うのか

ZK rollupsはすべてのbatchが有効であることを証明するため、proofが検証され次第withdrawalが決済される。Optimistic rollupsは、challengeされない限りbatchが有効であるとみなすため、慣例的に7日間のdispute windowをwithdrawalが待つことになる。ZK rollupsはcryptographicな保証に依存し、optimistic rollupsはeconomicなincentiveと少なくとも1人の誠実なchallengerの存在に依存する。

### 主要なZK rollupプロジェクトにはどのようなものがあるか

ZKsync Era、Starknet、Scroll、Lineaは、多くのチームが検討対象とする汎用ZK rollupsであり、ScrollとLineaはどちらも近いEVM equivalenceを目指している。Starknetは現在L2BeatのStage 1評価を得ているが、より厳格なルールが適用されるとStage 0への格下げが見込まれている。Scroll、ZKsync Era、Lineaはいずれも現在Stage 0だ。Polygon zkEVMのMainnet Beta sequencerは2026年7月1日にsunsetされ、Polygonは注力先をPolygon PoSとAgglayerに移した。

### smart contractはZK rollup上で動作するのか

動作する。EVM executionを証明するzkEVM実装を通じて可能だ。compatibilityは実装によって異なる。一部のzkEVMは最大限のcompatibilityのためにEthereumのexecution layerを直接証明する一方、他のものはバイトコードやstate structureを変更してprovingを安価にする代わりに、contractやtoolingの調整が必要になる場合がある。一般的な主張ではなく、自分たちが実際に依存しているものに照らしてcompatibilityを確認すべきだ。

### rollups-as-a-service（RaaS）とは何を意味するのか

Rollups-as-a-serviceとは、あなたが設定・所有するrollupのsequencer、prover、bridge、node infrastructureをproviderが運用することを意味する。これにより、チェーンを運用する運用負担は取り除かれる。しかし、base layerの選択、data availabilityのトレードオフ、sequencer decentralization、stack upgradeがどのようにチェーンに反映されるかといったarchitectureの意思決定は取り除かれない。

### ZK rollupのsecurityは何によって成り立っているのか

ZK rollupsはbase layerからsecurityを継承する。資金はbase layerのcontract上に保持され、新しいstate rootは有効なproofがオンチェーンで検証された場合にのみ受け入れられるため、operatorが無効なstateをコミットすることはできない。batchデータを別途公開することで、誰もがそのstateを独立して再構築でき、operatorがデータを保留していることを検知できる。個々のトランザクションに対するcensorshipへの耐性は別の保証であり、base layerへのforced-inclusion pathに依存する。