BitcoinとEthereumのLayer2の違いについて (LN/Rollup/RGB)
どうも、記事としては久しぶりの投稿になります。
極度妄想(しなさい)です。
今日は、BitcoinやEthereumのヘビーユーザーなら誰でも苦しむ手数料を解決すると期待されるLayer２について、まとまった情報を提供したいと思います。
この記事を要約すると次の通りです。
・BitcoinとEthreumではL1の設計思想や目標の違いがL2にもそのまま残っている。Bitcoinはプライバシー重視のP2P取引、Ethereumはスマートコントラクトの利便性最大化。
・Lightning Networkの仕組みは送金用途に限ると、Ethereum L2の送金よりもはるかにスケーラブルではあるが、Ethereum L2にはない問題がありうる
・Lightning Networkのコストとプライバシーは去年L1のアップデートでさらに改良された
・EthereumのLayer2 はEthereum L1の汎用性とセキュリティを引き継いだままスケールすることに成功した
・RGBはBitcoinのLayer2あるいはLayer3として、ほぼP2P取引(相対取引)とアセット発行に限ったスマートコントラクトの実装である。LNと同じく、設計上非常にスケーラブルであることが期待されている。
・RGBは、いわゆるEthereum的な意味でのDeFiを組むものではない。個人的にはP2Pスマートコントラクトとステート型スマートコントラクトは分けて話されるべき。
・BitcoinL2とEthereum L2のシナジーは難しく、今のところアトミックスワップによる高速DEXくらいしか思いつかないが、Wrapped BTCなどはRGBでのZKによって可能か注視したい
・CAP定理で大局的に分析するとBitcoin L2とEthreum L2のトレードオフ構造は同じ。Cを犠牲にするが誤魔化すEventual Consistencyで、擬似的にCAP全てを手に入れる仕組み。
Layer2はリサーチャーやエンジニアから見ると今どのような状況なのでしょうか？
2017年には悲観されていたようにも見えたLightning Networkはここ最近で多くのBitcoinが流入してきています。ルーティング手数料で利益をあげ始めたノードも増えてることから、今までの研究やボランティアっぽい雰囲気のあった時からフェーズは変わっているのではないかと察します。
前はBitmex Researchなどの大手にチャネルが集中していましたが、今はそういった点でもずいぶん分散しているようです。
2018年に悲観されたEthereumのLayer2(当時はPlasma)が、2019年にデータアクセシビリティと呼ばれる理論的な問題が大きく解決され、2020年には送金用途に限らず、汎用なスマートコントラクトのL2が実用レベルになりました。これは汎用L2の完成には５年かかると悲観されていた2018からすると非常に早いスピードでの進歩です。
そして2021年、Bitcoinerの中でもかなり詳しい人の間で話題になっていたBitcoin L3 スマートコントラクトプラットフォームのRGBがローンチしました。
この記事ではBitcoin開発者とEthereum開発者のデータアクセシビリティに対する考え方の違いにかなり重点を置くことになります。
では、最初のL2にして最も有名なLightning Network（LN）について分析してみましょう。
Lightning Networkはペイメントチャネルのネットワーク上で高度な合意をすることで、送金を一瞬（文字通り）で手数料がほとんどかからない仕組みにしています。
ペイメントチャネルとはマルチシグアドレスに二人でデポジットしたBTCを条件付き支払い（HTLC）のコードで更新することで、支払いを行う仕組みです。この際、条件付き支払い（HTLC）の更新はオフチェーンで二人で署名し、ハッシュの原像を提出することで行われるため、途中の過程はオンチェーンに載りません。
最新の合意したHTLCでない昔の合意のHTLCを提出することで支払いをなかったことにしようとする（二重支払いしようとする）と、最新のHTLCを提出することでマルチシグのデポジットを奪われるので、悪意を持つことにはリスクが高いです。しかしながら、一応正直なノードにもオフラインだったりネットワークを見張るのにミスがあれば、勝手にそのようなことをされて見過ごすリスクがあります。
このオフチェーンの条件付き支払いの合意によって作られるペイメントチャネルのハッシュをみんなで合わせてセットすることで、全員の支払いを一緒のタイミングにすることができます。HTLCではハッシュの原像がネットワーク上で公開提出されることで条件が満たされ支払いが済む仕組みです。つまりハッシュの原像を「知る」ことがお金を受け取るということを意味します。情報を送って教えることは一瞬なので送金も文字通り一瞬になります。
XからAに送金したいとき、経路が（X>Y>Z>A）とすると、
- 「情報iを教えたら最終受取人AはZから1BTCを受け取れる」という合意をする。（つまり後に1BTC払ったときZはここで初めてiを知る）
- 同じく「情報iを教えたらZはYから1BTCを受け取れる」合意をする。
- 同じく「情報iを教えたらYはXから1BTCを受け取れる」合意をする。
ここでいう「送金」は全てペイメントチャネル、つまりはオフチェーンでの数字のアップデートで済まされるため、ブロックチェーンは使いません。
この1~3を同時に行えば、あとは情報iをAがZに教えたら連鎖反応が起き、送金ができます。ここで、中継のルートを公開されてるチャンネル(public channel)の資金容量を考慮して計画する必要があり、それはFlareというアルゴリズムでされるらしいのですが、僕はこれをまだ理解していないので触れないことにします。
このように、自分に関わる売掛金と買掛金のデジタルな契約書を自分で持っておくことにより、あとはオフラインになった時に昔のアップデート前の契約書で精算しようとする変な奴が自分の関わってる範囲にいなければ、プライバシーのある資産を低い手数料で扱えることになるのです。
Ethereanの視点では、これはより現実の世界での金融活動に近いように思えます。「本当に変な悪い奴に絡まれなければ、平和に暮らせる。そして、絡まれても適切に訴えれば、面倒ですが解決はできます。絡まれて放置してると面倒なことになりますが、それは運が悪かったですね。自分の契約書は自分で保管しましょう。」というスタンスです。
「データは自分で持つ」これがBitcoinのL2にある制約ではあります。
Lightning Networkのマルチシグアドレスは2020年のTaprootとシュノア署名のbitcoin coreへのマージにより、普通のアドレスと区別がつかなくなった上、コストも安くなったため、LNを使っている問うことがトレースできなくなり、LNのチャンネルオープンも低コストになることが決まりました。
さて、EthereumでもこのLightning NetworkにあたるアイディアとしてステートチャネルRaidenがありました。もう少し複雑な資産に関するステートを同様に行う方法です。
しかしながらEthereum Communityはこの考え方を支持しませんでした。なぜなら、まず一つ目に、ステートチャネルによる条件付き送金のみのスケーリングに甘んじる際、L1がBitcoinもEthereumもスケールせず使えない世界では、単にそれは元来やりたいことを捨てた撤退になり、わざわざBitcoinではなくEthereumを始めた意味がなくなるからです。
ここで1度、L2以前にBitcoinとEthereumでどういう設計思想の違いがあったか思い出しましょう。
EthereumはBitcoin Scriptに３つの拡張がついているものと考えて良いです。ループ、ストレージ、公共無人アカウントです。
公共無人アカウント（CA）は法人のようなものかもしれません。もともと決められたコードによってのみ動き、ここに資産を集めて取引することができます。Bitcoinでは設計上P2Pで特定の相手との取引をコードで行うことができますが、Ethereumではこの公共無人アカウントCAを仲介して不特定多数と取引ができます。このCAを動かすコードも、Bitcoinで危険だと禁じられていたループや、ノードへの負担が大きいとして導入されなかったストレージ（データベース）の読み書きも可能にして、自由性を高めました。多くの場合、このCA（を動かすノード)にデータを持ってもらうので、ユーザーはデータを自分で持たなくても資産は安全に保たれる構造になっています。
しかし、ここでステートチャネルによるスケーリングをする場合、無人でデータ管理はできないため、CAは存在することができず、多くのEthereumの特性が失われます。さらに、もともとEthereumはビットコインの慎重さを取り払って汎用（チューリング完全）にしているため、Ethereum L1の複雑さとLightining Networkの複雑さを両方取り入れるのは危険でしょう。スケールにはEthereumのままでいることを求められました。
ここで、Lightning Networkの発明者であるJoseph Poon（とVitalik）がEthereum CommunityにPlasmaを発明し、プレゼントしました。
Plasmaのプランでは、Ethereumの特性を失わずにスケールする方法が提案されていました。おおよそL1を裁判所のように使うという発想は似ていましたが、適用先に合わせて全く違うものを提案してくるのはとても凄いと思います。
Plasmaでは、Merkle Rootの短いコミットハッシュに、色々な資産やCAの情報が入っている証明(inclusion proof)ができることを利用し、Merkle Rootさえ適切に変えさせすれば、なんでもできるというスタンスでスケーリングを試みました。つまり、小さなMerkle Rootデータの変更をCAのコードによって変更すれば、Ethereumと同じセキュリティでオフチェーンに資産とコントラクトコードを拡張できます！！
しかし、ここで問題が起こってしまいます。下のHA〜HPの全てのデータを持っていないと青いプルーフ（証明）は作れないですよね？証明は短く青だけでできるのでブロックチェーンのCAの検証コードへの提出データは小さくて済みますが、しかし、HA〜HPのデータはこのEthereum L2(この時はPlasma)の全てのトランザクションの結果ですので、トランザクションを全て知っていなければ、再現できません。全てです！！一つでも欠けてしまうと、途中の青いデータ（シブリングと呼ばれます）が違ってしまい、如何なる証明も作ることができません！！トランザクションデータを一つでも共有し損ねたり、保存を失敗すれば、全員GOXします！！！！嘘だと思うなら適当にHEあたりのデータを無くしたと想像して、Proofを作ってみようとして下さい。
これが冒頭で話したデータアクセシビリティ問題です。
これに関するEthereumの開発者コミュニティの迷走はとても激しく、RSAアキュミュレータと呼ばれる素数を使ってコインを動かない証明をする案やBitcoin Cashを使ってトランザクションを保存する方法などを議論していました。
更に、この時はUTXO方式の資産を皆やたらと議論していたのも混乱に輪をかけました。最も堅牢でシンプルな資産の表現方法がUTXOだということで、UTXOから議論をスタートさせましたが、今思えばこうする必要は全くありませんでした。UTXOをマークルプルーフで細かい単位まで扱い、L1出金時に最終保有者であるProofをするのは難しいせいもあり、不正な資金を正当化する奴より早く出金しないといけなくなるイベント、Exit Gameという取り付け騒ぎが起こってしまうことについて頭を悩ませていました。
つまり、最悪データアクセシビリティの問題を利用して、Exit Gameに勝つことで不正な資産を正当化することができる問題だったのですが、これはL2のトランザクションを全部オンチェーンに載せて間違っていたら拒否する仕組みを導入することでデータアクセシビリティ問題を排除することで前者を解決しました（i1）。そして後のExit Gameは、不正なMerkle Rootにアップデートすることをゼロ知識証明で拒否すること、あるいは7日間ノードが見張って不正があれば証明（fraud proof）することで取り除かれました。前者をzkRollup、後者をOptimistic Rollupと呼びます。Rollupとは上記の(i1)の方式のことを言います。
さらに重要な進歩として、このゼロ知識証明のルールは汎用なスマートコントラクトのように書けること、そしてfraud proofできる対象もEVMコードのほぼ全般であったことから、zkRollupもOptimistic RollupもどちらもEthereumの汎用性を保つことができました。
もし、この２つのRollup本当に率直な理解をしたいのであれば、次の２つの原理によってスケールが保たれていると考えて下さい
- Merkle Treeのルートだけ刻むのでストレージコストを極限まで節約できる
- L1ではトランザクション実行コスト＝トランザクション検証コストである（実行して検証してるので当たり前だが）のに対し、L2は実行コストをオフチェーンでかけて、zkで圧縮したりfraud proofでサボったりしてL1での検証コストを下げているので、計算をオフチェーンに押し付けられる。つまり実行コストと検証コストのトレードオフが元来、実行＝検証だった部分を実行>>検証にずらし、実行をチェーン外に投げることでスケールしている。
ちなみに、２の部分をL1の検証コスト＝L2の実行コスト+Merkle Proofのコストという逆に増やしてしまう形をとるのがPolkadotのXCMPです。PolkadotではRelay Chainのshared securityにおいてトランザクションに全てMerkle Proofをつけて同期検証可能にすることでクロスチェーンを行えます。
さてBitcoin L2との比較をまとめると、Bitcoin L1は本当に取引自体をオンチェーンでほとんどやらず、訴訟取引をする可能性のみを持つことにより、情報の伝達だけで一瞬で変わる資産状況を持つことができます。EthereumのL2は結局L1に低コストですが処理はするため、より確実かつ汎用でユーザーに優しい形になりますが、Bitcoin L2ほどのスペックに今のところならないと考えてよりでしょう。
さて、EthereumのスケーリングというとRollupではなく、Ethereum2.0というイメージを持つ人が多いのではないでしょうか？
事実よく、Ethereum L2とEthereum2.0を混同して話している人をよく見ます。Ethereum2.0はシャーディングを目指しています。しかし構造はzkRollupに意図せずとてもよく似ることになりました。今のEthereum L1をKZGコミットメントという別のZKのような圧縮方法で検証コストを大幅に下げます。
L2のストレージデータを知らない検証コントラクトがZKを使って検証するのと同じように、シャードのストレージデータを知らないValidatorがKZGを使って検証できるのがEthereum2.0のステートレスイーサリアムです。
これによりValidatorがシャードのデータを同期できなくても正しいかどうか判断できるようになるので、次々と色んなシャードに割り振ることができ、同じ数のvalidatorでも不正ができないようシャッフルしながら、大量に並列実行されたシャードでマイニングができます。
ZKは秘密やプライバシーを扱うもので、スケーリングに使うというと違和感がある人は、「ZKは秘密を教えなくても秘密を知ってることを証明できる」という文章を「ZKは大量の実行過程を教えなくても大量の実行をしたことを証明できる」と書き換えれば一瞬で理解できるでしょう。
さて、Bitcoinで並列実行の構造について考えているプロジェクトがあります。RGBです。
スライドはこれが分かりやすかったので、次の章の後、読んでみることをお勧めします。（2023年4月にRGBのstate distructionの部分の理解が間違っていたことに気付いたので、大幅に訂正しております。）
RGBはBitcoinのチェーン外でスケーラブルなスマートコントラクト実行をするプロトコルです。そのコンセプトは、Lightning Networkのオフチェーンステート, CounterpartyのClient Side Validation,そして大きくはPeter Toddの発案したSingle-Use-Seal（1回だけ使えるタグ）に加上することができます。
「Scalable Semi-Trustless Asset Transfer via Single-Use-Seals and Proof-of-Publication」（Single-Use-Seals とProof-of-Publicationを用いて半分トラストレスでスケーラブルな資産の移転）で最初にまとまった形でこの概念が出されました。
Single-Use-Sealというのは、次のような性質を満たすもの全般です
「この一回だけ使えるタグ」はPeter Toddの言う通り、数学的には作れないことは自明です。「時間が経ったら解ける暗号」を数学的に作れないのと同等でしょう。つまりブロックチェーン上のステートを使ったりアンカリング（紐つけ）して作ることができます。最も簡単な実装は次の通りになります。
シングルユースシールは本当に退屈でシンプルです。要約すると、それらは、一度しか署名できない「魔法の」プロパティを持つパブキーに似ています。もちろん、これは数学だけでは不可能です。(中略)ビットコインでの明らかな実装は、シールを指定された
txoutとして定義し、証人をトランザクション（およびライトクライアントプルーフ）として
定義し、OP_RETURN出力がのハッシュにコミットするトランザクションでそのtxoutを使用することです。
最初の出力としてのメッセージ。より洗練された実装では、
ペイ・トゥ・パブキースタイルのコミットメントを使用できます（RGB¹はこれらの線に沿って何かを使用します）。(https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017257.html の訳)
とにかく、Single-Use-Sealは暗号学的な部品を指す概念であり、実装の方法やアルゴリズムは指定されていません。
これをCounter Partyプロトコルのようなクライアントサイド検証と組み合わせると様々なことができます。単純な実装は例えば次の通りです。
UTXOにアセットXのハッシュをアンカリングしてアセットXを定義します。Xは秘密です。UTXOは一度使うとUTXOではなくなるので、XはUTXOの利用と共に所有者を変え、次に最初にXの原像を使ってアンカリングした先となるUTXO所有者に移ります。（注：これはRGBの仕様ではありません）
Xはバレてしまえば誰でもアンカリングに使えるので、後続の人は沢山でてしまいますが、クライアントサイドで皆が誰が最初だか分かっていれば、二個目以降は無効にできます。
つまり、クライアントサイドで検証をする場合、ブロックチェーンに二重支払いのトランザクションが入ってもクライアントサイドでアルゴリズム通りプログラムを動かしてる人は皆何が正統なのか知っているので大丈夫だと言う話です。
Peter Toddのセッションでは次のように言っています。
Q＆AQ：では、誰かがあなたに非包含証明を与える責任がありますか？それはどのように機能しますか？それにはどのくらいのデータが必要ですか？そして、悪意のない場合、そのプロトコルは何をしますか？A：すばらしい質問です。そもそも二重支払いを回避する方法があることを前提としたシステムを構築しています。私は二重支払いを防ぐことができるビットコインまたはそのようなものを想定しています。そのブートストラップを取得したら、たとえばビットコイン上に構築されたより大きなシステムを構築し、よりスケーラブルな方法でそれらの保証を提供できます。そのベースレイヤーがなければ、私は有用な保証を提供することはできません。たぶん、他のデータ構造が機能する可能性があります。(http://diyhpl.us/wiki/transcripts/building-on-bitcoin/2018/single-use-seals/の訳)
これはどういう意味でしょうか？
例えば先程のXの例で考えれば、クライアントサイドでは自分の資産に関する情報しか検証しない場合、そのXが自分の前までに使われていないという証明ができるかどうか？と言う意味です。Xの所有者がハッシュの原像を使いまわして２重に支払いをできないようにするためにはチェーン上のデータに対して非包含証明を行い、Xが使われていないことを証明する必要はありますか？と言う意味です。
回答としてはUTXOなどにバインドすれば良いので、そういったものに頼ることを意図していると言う内容が示唆されてると考えれば良いでしょう。
基本的にはRGBはアセット移動の1つのトランザクションを1つのUTXOに紐つけるのでスケーラビリティはL1を利用するままでは低いです。L1でのRGBで行われていることは比較的高いプライバシーとbitcoin以外の多種多様なアセットです。後述の通りLNのスケーラビリティに載せることでLNの利点を全般的に引き継ぎます。
実際の実装であるOpenSealsではDAGがProofのために使われています。
<追記>
ここを詳しく見ると良さそうです
https://docs.rgb.info/design
やはり、大量の履歴データの検証が必要なようですで、他ノードからの補助でそれを短縮する予定だそう。注意すべき点は、コインが色んな人の履歴検証に混じっていくことでプライバシーは時間経過と共に弱くなっていく点ですね。
<追記終わり>
さて、RGBではOP_RETURNつまりはBitcoinのL1にアンカリングする場合とは別にLightning NetworkのHTLCにアンカリングする仕様もあります。
RGBではアンカリングされたProofを持った瞬間に資産になるのですが、アンカリング先がHTLCやその関連するデポジットコントラクトである場合、セキュリティはデポジット額になるのでは？と思いますが、ここはわかりません。
このLNに載せるRGBの仕様は非常にエレガントです。LNのチャネルをLN支払い時に更新しますが、このチャネルのコントラクトにRGBのステートも同時に載せます。もし、２者間でRGBの合意ができればLNのチャネルと一緒に新しいものにアップデートすれば良いですし、もし合意ができない場合はチャネルクローズによって最後の合意ステートを確定させることができます。
RGBのスマートコントラクトとは、次のように組まれます。
Practical single-use-seal implementations will also obviously require some way of generating new single-use-seals. Secondly, authentication is generally useful. Thus we have:Gen(p)→lGen(p)→l — Generate a new seal bound to pubkey pp.Close(l,m,s)→wlClose(l,m,s)→wl — Close seal ll over message mm, authenticated by signature ss valid for pubkey pp.Obviously, in the above, pubkey can be replaced by any cryptographic identity scheme, such as a Bitcoin-style predicate script, zero-knowledge proof, etc.https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
おそらくですが、RGBのコントラクトもまた、公共ステートのないP2Pのコントラクトであり、無人アカウントにロックしたりプールを作ったりするEthereumL1L2のコントラクトのようなことはサポートしないと予想します。おそらくLN同様P2Pのハブのような存在が生まれて大量のP2P取引が集まる現象は予想されますし、それがとても面白そうだと思います。
EthereumのL2はこれらBitcoinのL２とシナジーがあるか考えてみました。
おそらくEthereum L2でアトミックスワップができるようにコントラクトを組めば、LNのpreimageをセットしたり、RGBのコントラクトをセットすることで、DEXが構築できるでしょう。それは速さや分散性と言う点でEthereum L1のWrapped BTCを使ったDEXとは格別のものになると思います。
もっと贅沢なことを考えましょう。BTCの解錠条件をEthereum側で設定することです。事実上のWrapped BTCのトラストレス化を意味します。
もしBTC L1でなぜEthereumと同様にZKP（ゼロ知識証明）を使った取引をしないのか疑問に思う人がいるかもしれません。
Bitcoin Scriptでゼロ知識証明を利用する際には問題Xをハッシュの原像提出問題に変換し、その対応関係をゼロ知識証明で問題Xの答えを教えずに証明します。
Knowing(answer(X)) = Knowing(hash(hash(answer(X))))
であるため、あとはこれに対応する回路とそのVerifier Keyとhash(hash(answer(X)))を受け取った人は、answer(X)によって作成されたZKProofを検証することで、問題Xがhash(hash(answer(X)))の原像、つまりhash(answer(X))を提出することと等価であることを認めることができます。エレガントにBitcoin Scriptのハッシュ提出問題に変換されました。
これがPay2Sudokuで、５年前にGregory Maxwellに実証されたものです。
これには問題があり、あらかじめ答えを知ってる問題Xの変換にのみ使えます。ZKRollupのようにEthereumの将来取り込まれる誰のものとも知れないトランザクションの署名などを検証することはできません。これがEthereum上の未知の条件・状態でBTC L1を解錠できない理由です。
しかし前述の通り、RGBでこれをサポートできる可能性があります。彼らのZKPに関する可能性を注意深く見守ることには価値がありそうです。
この記事の読者にもし、アカデミックなモデリングや数理的な解釈に興味があるひとはL2をどう見るべきでしょうか？
おそらくCAPの定理で見るのが良いでしょう。C一貫性、A可用性、P分断耐性のうち、３つを両立するのはできないというトリレンマです。
ブロックチェーンは一貫性があり分散してるイメージがあるのでCP型でしょうか？けどよくダウンしない高可用性があるとか言いますね。全部？？それはだめでしょう。
答えはCが低いです。一貫性が低かったら二重支払いされてしまうのでは？と思われるかも知れませんが、Bitcoinでは少なくとも1confされるまでは、全てのmempoolの内容は別々で一貫性はないです。つまり、confされた瞬間に一貫性が回復される仕組みなのです。これはEventual ConsistencyとかBASE特性などと呼ばれ、途中一貫性を捨てて定期的に戻すことで全部達成するようにユーザビリティとして見せる手法です。
さてL2とは分散システムとして解釈すると、CAPでどんなタイプになりますか？どうやってAPシステムである公共ブロックチェーンをスケールさせるのでしょうか？
答えはさらにCを捨てることです。どうせ捨てても誤魔化せるんだからもっと捨ててもっと後から回復して誤魔化しましょう。各L2のステートはコミットされるまで全然同期されていません。一貫性は全くないです。しかしL1に最終的にはコミット可能です。こういった対局的な分析の元ではBitcoinのL2もEthereumのL2も同じです。
さらに詳しく分析したいです。CAPは実は提唱者は厳密にCAPから２つ選べとは言わなくなりました。そこで提唱されたのが新しい分析法であるPACELCです。
これはPネットワーク分断が起きた時、Aを選ぶかCを選ぶか、分断が起きてない時は低Latencyを選ぶかCを選ぶか？と言うフローチャートつきのCAPです。
BitcoinのL2はPAELですね。そしてEthereum L2はPAELです。やはり違いがでませんね。なぜ違いがでないか。それはこのシステマティックな分析にはインセンティブ設計の違いが反映されないからです。例えば、Pが起きた時には電気代で損を食らうのがBitcoinのマイニングシステムですが、そういったインセンティブ設計の違いはデータベース工学では考えられていません。BitcoinのL2とEthereumのL2は明らかに違いがありますが、それはインセンティブ設計の違いであり、データベース工学的なものではないといえます。ここも含めたモデリングは見たことがないと言えるでしょう。
最後に、
クリプトやブロックチェーンでの開発はL1にせよL2にせよ、決済をコードすることでもなく、お金を電子化することでもなく、財産権をコードすることです。この財産権へのスタンスの違いで今日紹介したシステムに違いが出ているとも言えます。
経済史学者のバーンスタインは「豊かさの誕生」と言う本の中で、四大発明をした中国で産業革命が起こらなかった理由を端的に財産権の有無で説明しました。中国では人民の発明は皇帝のものである一方、西洋では特許が生まれ財産権となりました。発明するインセンティブによる連鎖構造は中国ではその時起きなかったのです。
財産権をコーディングすることは、そのまま世界の発展に寄与することができると考えますし、クリプトで新しいシステムを見た時、この発明者や開発者は財産権をどう考えているのか、知ろうとすると面白いかなと思いました。
