BitcoinとEthereumの周辺技術を（なるべく）シンプルに整理する。

TLDR;

・Bitcoin L2では基本的に取引内容の隠蔽性を重視し、ユーザへの負荷をある程度前提にしたP2P取引（特に支払い）が主流（Lightning Network）

・Ethereum L2では取引の隠蔽性はある程度落としてその代わりにユーザへの負荷を抑えたより柔軟な(例えば流動性プールや自動市場作成モデルなどを使用した)取引の実現が主流(Rollup)

・BitcoinもEthereumも基本的な思想とは少し異なるベクトルを目指すプロトコル・サービスが存在（BitcoinベースのDLCやBitVM, Ethereum L2ソリューションのIntmaxやPlasma等々）

・Ethereum、Bitcoinともに「取引内容の隠蔽性」及び「取引の柔軟性」の両方を兼ね備えた技術はまだまだ議論の余地ある領域だと思われる

はじめに

“A Peer-to-Peer Electronic Cash System”であるBitcoin、“generalized transaction based state machine concepts”を実現するEthereum、それぞれ独自の設計思想を持つ２つのチェーンは、このLayer1(以降L1)の設計思想を元にLayer2(以降L2※)などのオフチェーンで取引内容を行う提案が数多く存在します。これらをなるべく簡潔に体系的にまとめてみようと思います。

※L2とはL1と同等のセキュリティレベルを保ちながらより高速・安価な取引を可能にするために開発された、L1プロトコルの外側の技術です。L1の外側で取引の実行や検証などを行い、L1に必要最小限の記録を行うことでL1のスケーラビリティを向上させる役割を担っています。

なぜこの記事を書こうと思ったか？

BitcoinやEthereumのL2などのオフチェーンソリューションはそれぞれ要素技術が非常に複雑であり、横断的に分析を行うにはそれぞれの技術に深い知識を必要とします。

故にそれらを比較する記事は技術的な差異にフォーカスしがちであり、本質的なそもそもの設計思想やユーザー目線での技術選定という観点では分かりにくいものになっている気がしています。
今回はこれらの技術の詳細を（なるべく）記載せずに、ブロックチェーンユーザ目線でどの技術を選定するのが望ましいかをまとめてみようと思いました。

ターゲットユーザー（前提条件）

今回のターゲットユーザーについて以下３つのキーワードを元に説明します。

・Not your key not your coins
ユーザーは資産を自分の責任で管理を行いたいと思っています。
Non-custodial walletユーザということもできるでしょう。

・Decentralized Public Blockchain
ユーザーはBitcoinかEthereum(もしくはそれぞれのL2)を使用したいと思っています

・Trust-minimized third party
ユーザが十分に（BitcoinやEthereumほど）分散していないOperatorなどを使用する（※）際にはそれらが不正や結託等によりユーザの資産を奪う、もしくは凍結することができないような設計がされているものを使用することを前提とします。
※例えば、分散性を抑えて処理性能を優先するsidechainの使用はこの例に該当します。十分に分散していないsidechainのブロック生成者の不正や結託によりユーザの資金は凍結もしくは奪われるリスクがあるのでsidechainは本分析の対象外となります。
（Sidechainが何か知りたい方は一番下の「Q＆A」章をご参照ください）

フローチャート1（取引の柔軟性、取引内容の隠蔽性）

上記はユーザの要望によってどのチェーンを選択するべきかを表した図です。取引の柔軟性、取引内容の隠蔽性という観点から以下のような分岐を設けています。

・分岐１：Payment?
シンプルな各種トークンの支払い・Transferか、もしくはオプション・先物・デリバティブなどの金融取引、流動性プールや自動市場作成（AMM）モデルなどを使用したより複雑な取引かという分岐です。
・分岐２：P2P(OTC)?
1:1の取引かもしくは、N:Nの取引や特定の相手を指定しない流動性プールや自動市場作成（AMM）モデルなどを使用したより複雑な取引かという分岐です。ユーザ2者間で何かしらの合意を行い合意内容に応じた取引を行う場合は前者にあたります。Uniswapのような分散型取引所（DEX）での取引は後者に該当します。
・分岐３：Footprint OK?
ブロックチェーン上に記録された内容から取引内容が判断できるか否かの分岐です。マイナーや第三者機関から検閲をされたり、フロントランニングなどに使用されたりしうる点を気にするか否かという分岐です。

分岐のゴールが６つ設けられておりますが、上に行くほど取引の柔軟性は高く、右に行くほど取引内容の隠蔽性は高くなります。

以下でそれぞれの分岐ケースについて説明します。

・Simple Payment cases

まずはシンプルなpaymentについて見ていきましょう。PaymentでFootprintを気にしない場合はBitcoin、Ethereumどちらでも取引が可能ですが、Footprintを最小限にする方法としてはBitcoinおよびEthereumの L2上での支払いが有効です。（詳細は以下フローチャート２で触れます）

こちらは支払いの都度L1へ記録する必要がないのでTx Feeも抑えることが可能です。L1へ記録をしない代わりに、ユーザはL2取引履歴は全て自身の責任でローカル環境などに保管する必要があります（なくすと最悪L1 に資産を戻せなくなります）。

ここで保管する情報は通常walletが保管する「鍵」とは異なるものなので、世の中に広まっているNon custodial wallet（例えばTrezor、Ledger、Metamask、Electrum）で汎用的に保持できるようなものではない場合があり、その場合はユーザは特定のL2専用のwalletを保持する必要があります。

・P2P contract cases

Paymentより複雑なP2P（OTC）取引の場合「Footprint OK?」の回答で適したチェーンが異なります。

ユーザーがFootprintを気にする場合はBitcoin上のOff-chain contractに該当します。これは当事者間で合意した契約内容についてチェーンの外側で定義（実装）を行い、最終的な結果（決済）のみをオンチェーンで実行します。契約内容はチェーン上から識別できないので契約当事者以外はその契約内容および契約がされてたことすら気づくことができません。L1へ記録をしない代わりに、ユーザはL2取引履歴は全て自身の責任で保管する必要があります（なくすと最悪L1 に資産を戻せなくなります）。

・Flexible Contract cases

さらに複雑な取引の場合、最も有効なのがEthereum L1上にデプロイされたDeFiやDEXプラットフォームを使用することです。これらはCotnractの実行にL1（Validator）の計算実行を必要とするため、Gas(Fee)はその分高くなります。その回避策としてL2(Roll up)上での汎用的なコントラクトの実装が現在進められています。
上記のL1、L2（roll up）どちらでもFootprint（契約の内容）はチェーン上に記録されます。

また、Footprint（契約の内容）をチェーン上に残さないような取引としては、現時点では実行不可です。ZK-contractやzk-zk rollupなどという名称で現状Ethereum L2上で実装検討がされています。

フローチャート１の結果の分析（取引の柔軟性、取引内容の隠蔽性の観点）

上記はフローチャートの各結論をピックアップした表です。

上に行くほど取引の柔軟性は高くなり、特にN:Nの取引や特定の相手を指定しない流動性プールや自動市場作成（AMM）モデルなどを使用したより複雑な取引にはEthereum上での実行が有効であることが見て取れます。

また右に行くほど取引内容の隠蔽性は高くなります。取引の隠蔽性が高くなるということは取引はチェーンの外側で定義および実行されることとなり、L1に記録するデータやL1のValidatorの計算コストを下げることにも繋がりますが、その反面、取引の定義や実行などをユーザ自身が行う必要があります。
特にBitcoinはこのようなユーザ要件を前提としたP2P paymentを拡張したLightning Networkの開発が盛んです。

以上をまとめると、Ethereumでは取引の隠蔽性はある程度落としてその代わりにユーザへの負荷を抑えたフレキシブルな取引が（左上）中心であるのに対してBitcoinでは基本的に取引内容の隠蔽性を重視し、ユーザへの負荷をある程度前提にしたP2P取引（特に支払い）が中心であると言えます。

フローチャート2（フローチャート１の結果に分岐を追加）

上記のフローチャート１の６つの結論にさらに「Can you keep your node online?」の分岐を追加し、より詳細なフローチャートを作成します。
この質問は、ユーザが取引を行なっていない間もブロックチェーンの状態を常に監視するようなインフラを備えているかを表しており、要件を満たすためには理想的にはチェーンと同期したフルノードを保持する必要があるのでユーザにとっては非常に高いハードルになります。

Ethreumフルノード運用のサービス（例えばAlchemyやPublic nodeなど）やLightning Costodial wallet(LN サービスプロバイダーが主に提供している)などを使用することでユーザが自身の負荷を下げることは可能ですが、これはサービス提供者への信頼が前提になるので今回の場合は対象外になります。

・Simple payment Cases

ユーザはL1で支払いを行う際はオフラインで問題ないです（分岐なし）

・Off-chain payment Cases

Paymentに特化した技術としてBitcoin L2のLightning Networkがあります。Ethereum L2としては（現在はあまり開発の主流ではないかもですが）Plasmaが挙げられます。
どちらも取引の履歴をチェーンに記録せずにユーザーがローカルで保持し、任意のタイミングでローカルで保持しているステートをL1に反映することで資産をL2からL1に移すことが可能です。
ただしLightning NetworkとPlasmaの場合、L1へ資産を移す際にユーザの提出したステートが正しいか検証することはできません。そのため、ユーザは自分自身のステートが他者の不正な提出などによって不正な状態でL1に反映されていないかブロックチェーンを監視し、不正があった場合に対応をする必要があります。これがユーザがノードを常にオンラインにし続ける必要がある理由です。

取引の隠蔽性はある程度落としてその代わりにユーザへの負荷を抑えたフレキシブルな取引が（左上）主流であるEthereumのプロジェクトの中で、Plasmaはその逆ベクトルを進んでいるプロジェクトということもできるかと思います（それゆえに開発の主流ではないかと思われます）

基本的に取引内容の隠蔽性を重視し、ユーザへの負荷をある程度前提にしたP2P取引（特に支払い）が中心であるBitcoinではLightning Networkはその思想をそのまま受け継いだL2技術と言えるでしょう（それゆえに現状Bitcoin L2開発技術の主流になっています）

また常にオンラインであることをユーザに強要しない特有のプロジェクトとしてはIntmaxがあります。Intmaxは支払いに特化したEthereumのL2技術で支払いの時以外にはユーザにオンラインである必要を問いません。この技術では取引を行ったユーザのアカウント情報はL1に定期的に記録されますが、その内訳は記録されません。
これはユーザへの負荷を抑え、かつ取引の隠蔽性を重視した非常にユニークなプロジェクトだと思います。

・On-chain Contract cases

N:Nの取引や特定の相手を指定しない流動性プールや自動市場作成（AMM）モデルなどを使用したより複雑な取引は、ユーザにオンライン要求を強制しないEthereum L1上のDeFiやDEXアプリケーションを使用した実行が主流です。

まだ研究段階でポピュラーなサービスはないですが、将来的にはEthereumのL2ソリューションであるRollup上に構築されたDeFiやDEXアプリケーションを使用して実行が主流になる可能性があります。

Rollupはoperatorと呼ばれるエンティティがユーザの取引の検証、実行、ステートの更新をチェーンの外側で実行し、定期的にそれらを圧縮して（しばしば「Blob」と呼ばれる）L1に記録することでL1でのトランザクションの実行と保管のコストを下げるL2ソリューションです。ユーザは資産をL1のスマートコントラクトにロックし、以降の取引はL1にブロードキャストするのではなくoperatorに渡すことで取引を継続的に実行できます。

Rollup operatorはroll upユーザの資金を奪うことはできず、万が一Operatorが消滅した場合にもユーザは自分自身のL2上のステートをL1上で証明することでOperatorに頼らずに資産をL1に退避することができます。

Roll upは大きくOptimistic rollup、ZK Rollupの２つに分類されます。

Optimistic rollupはL1ではoperatorが提出したBlobの中身（つまりトランザクション）が正しく検証、処理されているかは検証しません。

オペレータが不正をした際にはユーザはその不正を証明することで、ステートを再度正しい状態に更新させることが可能です。同時にオペレータには不正に伴うペナルティが与えられます。

一方ZK rollupはOperatorはBlobと共に、取りまとめたトランザクションを検証、実行した証拠をZKPとしてL1に提出します。L1で定義されたコントラクトでそのZKPが検証されOKだったものが記録されます。

つまり、Rollup operatorが提出したBlobが正しいかをユーザ自身が検証するのか、L1にデプロイされたコントラクトが検証するのかが両者の大きな違いになります。

この違いはチェーンの監視が必要なOptimistic rollupと不要なZK Rollupとして上記のフローチャートの分岐に現れてきます。

なお、Rollup operatorが消滅した場合にはユーザはL1に資産を退避する必要がありますが、ロールアップの最新の状態を回復するのに十分なトランザクション データは、必要に応じてダウンロードできるように公開する必要があります。（これは「Data availability」と言われる要件です）

現状のrollupはトランザクションデータ（のうち必要最小限の情報）をcall dataとしてL1に保存しています。これがRollup上取引の内容がFootprintとして残る理由です。

・P2P Off-chain Contract

P2P Off-chain Contractは契約の内容はユーザー間で合意し、その内容はチェーンに記録せずにユーザーがローカルで保持します。契約者以外はその内容をブロックチェーン上から判別することはできません。

Discreet Log Contracts

代表的なものはBitcoin上で実行されるDiscreet Log Contracts（DLC）です。

DLCは2者間でデリバティブなどの金融取引を可能とする技術です。ユーザ以外に特定のイベント（BitcoinUSD spot価格など）の結果を発表するオラクルが必要ですが、オラクルはユーザの取引の内容だけでなく取引の有無さえを知る必要はありませんし、ユーザの資金を奪うこともできません。ユーザがクライアントをオンラインにする必要は、契約締結時と契約満期時の決済を行うタイミングのみです。CryptoGarageはこの技術開発を行っており、ライブラリはこちらです。

Discreet Log Contracts on Lightning

また、Lightning Network上のダイレクトチャンネルで繋がっている２者は、DLC用のチェネルをセットアップし、契約施行時にfeeを払うことなく取引を継続的に実行可能です。（詳細はこちら）これはLightning Networkと同様、相手が不正なステートでL1にexitしないかブロックチェーンを監視する必要があるのでユーザは常にオンラインでブロックチェーンを監視する必要があります。

BitVM

BitVM はBitcoin上でチューリング完全な契約を実現する提案です。契約の内容はユーザがオフチェーンで定義を行います。

ただし、現状Ethereum L1で実装されている様々な契約をすぐにBitcoin上で実現するような特効薬（a silver bullet solution）ではないことは強調されています。理由としては以下の通りです。

・契約は2-party間に限られる

・２partyには多くの計算量およびインタラクションを要する（1つの契約を実行するにあたりお互いが交換および保持する情報は数百MB〜数GBになる）

より詳細な解説記事はこちらをご覧ください。

フローチャート２考察（取引の柔軟性、取引の隠蔽性、ユーザー負荷観点）

ここまでフローチャートで記載された各取引についてまとめると上記の三次元のグラフになります。

L2でEthereumで現状、最も開発が盛んに勧められているのは取引の隠蔽性より取引の柔軟性に特化したrollup、Bitcoinはプライバシーを重視したP2P paymentであるLightning Networkです。ともにEthereum、BitcoinのL1の設計思想を受け継いでいると言えます。

また、Ethereum上でシンプルな機能に絞りプライバシーを重視したIntmaxやPlasma、Bitcoin上でP2Pの匿名性を保持したままより複雑な取引を行うDLCやBitVMは上記とは異なる点に着目していることがみて取れると思います。

取引の柔軟性と隠蔽性の両方を兼ね備えた取引はZK-contractやzk-zk rollupなどという名称で現状Ethereum L2上で実装検討がされているようですが、このテーマはまた発展途上であり面白い内容であると思います。

BitVMのようなP2P取引をN:Nに拡大して柔軟性と隠蔽性の両方を兼ね備えた取引を実現する場合は、ユーザ間のインタラクション数が課題になると思われます。
またrollupのような信頼を最小限に抑えた取引のコーディネータを使用して柔軟性と隠蔽性の両方を兼ね備えた取引を実現する場合は、コーディネータがいかに取引内容を把握せずにコーディネーションできるか、コーディネーターが消滅した際にいかにユーザが取引を続行もしくは強制終了できるかが課題になるかと思われます。

まとめ

“A Peer-to-Peer Electronic Cash System”であるBitcoin、“generalized transaction based state machine concepts”を実現するEthereum、それぞれ独自の設計思想を持つ２つのチェーンは、その設計思想を受け継いだスケーリングソリューション（Lightning Network on BitcoinやRollup on Ethereum）およびそれとは少し異なる独自の思想を入れた提案が混在していることが分かりました。

また、どちらのチェーンでも現状は「取引内容を秘匿するフレキシブルな契約の実現」は現状ではされていないことも見てとることができました。

現状ブロックチェーン上では様々な提案が日々されています。それらの膨大な情報に振り回されないためにも、例えば今回のような「ユーザ目線」などの簡易な分類軸を元に考えてみることも１つの方法かなと思いました。

Q＆A

ここまでの分析はかなり分析要素を簡略化した内容であるため、読者の皆さんにはいくつか疑問が挙がっているかと思われます。以下に想定されるQ＆Aを記述します。

Q1.LiquidなどのSidechainはどこに分類されますか？

SidechainとはMainchain（例えばBitcoinやEthereumなど）の側鎖として機能するチェーンです。ユーザはMainchainからsidechainへ資産を移動することで、より高速かつ低いコストで取引が可能です。
SidechainはMainchainとは異なるコンセンサスアルゴリズムを備えており、 ブロックの更新権限者をより中央集権化させることにより性能を上げています。
理論上、この更新権限者が不正や結託等によりSidechain上のユーザの資産を奪う、もしくは凍結すること可能なため、本分析では対象外としています。

※ （12/28追記）nunoさんよりご指摘いただいたので修正を加えております、ありがとうございます！
PolygonをLiquidと同じsidechainとして記載していましたが少し誤解を招く恐れもあったため追記しています。
PolygonはPlasmaとして設計されており、Polygonネットワークが万が一停止した場合でもユーザは資産を保持している証拠をEthereum L1に提出して自身の資産を移動させることが可能です。ただし、これはMATICに限った話であり、ERC20トークンなどは不可能です。よって、Polygonも今回の分析対象外とします。

Q2.mixingなどの秘匿技術が出てきていませんが？

本分析ではあくまで取引に伴いネイティブに隠蔽性が実装されているかに着目しています。取引実施の際にその機能特性として取引が秘匿されることと、「秘匿」を主の目的とした取引自体を実施することは第三者からの見え方や検閲などのリスクはそれなりに異なると個人的には思うので今回は「秘匿」自体を目的とした技術は除外しました。

Q3.ValidiumなどのDAに着目した技術の分析がありません

本分析では対象外です。理由は、十分に分散していないOperator、Validatorなどを使用する際にはそれらが不正や結託等によりユーザの資産を凍結することができない（ユーザが自力で資金を取り返すことができる）技術選定を前提としているためです。

Q4.セキュリティの観点がありません

おっしゃる通りです。安全性においては、ベースとなる暗号プリミティブ自体の安全性、ユーザが行う取引の内容や鍵の管理方法、理論をベースに実装されたソフトウェアの品質やその管理体制など、様々な要因が関係するのでこの大きな括りでの安全性の比較は不可能なため割愛しています。

Q5.AccountモデルとUTXOモデルでそもそもプライバシーが違う

おっしゃる通りです。「取引内容とユーザの紐付け」という観点ではアカウントに取引内容や残高が紐付くモデルと、使用されていない資金の断片とそのオーナーが存在するUTXOモデルとでは紐付けのしやすさが異なります。
今回はあくまで「取引内容の証跡」という観点での分析をしているので上記の内容は対象外としております。

Q6.Atomic Swapは？

Atomic Swapは広義の意味でのpaymentと捉えています（当事者間の合意による2つのpaymentの組み合わせ）各paymentの利便性とプライバシーはそれぞれswapする資産が載っている技術（例えばLightning NetworkとBitcoin L1など）のそれに依存します。

Q7.Bitcoin上で様々な契約を実現するCovenantsの話がない

Covenantsは、Bitcoinに新たなオペコードをアクティベートする（つまりソフトフォークする）必要があり、それがいつ実現するのか（はたまたしないのか）はまだまだ未知のため、今回は対象外にしています。

Q8.Bitcoin上で任意のトークンの扱いについての話がない

すいません、端折りました。
Bitcoin上でトークンを扱うプロジェクトはたくさんあります。現在主流なものはRGB、Taproot Assets Protocolなどです。
これらはトークンの種別や量などをUTXOのどこかしらに組み込みますが基本的にその種別や量などの内容は取引当事者しか識別できません。Bitcoin上でアセットを扱う場合でも取引の隠蔽性を重視したP2P取引という思想を（基本的に）そのまま受け継いでいるとも言えます。またLightning Channelを活用しL2でアセット取引を行う構想もあります。
理論的にはBitcoin上の取引は扱うものがネイティブアセットでもBTCでもその他の任意のアセットでも行えると思います。（開発の工数は当然上がるので実現するのは先だと思われますが）

最後に

全然簡潔にまとめられませんでした。苦笑