Litigable Protocol(落合提案)までの過程

開発者向けの文書

後進の参考として記事に残しておく。

1. いべさんが「田舎っていうのはexitableじゃないから協力できるっと思うんですよ」と話しをしていた。逃げれないということは、居所が割れてたり、悪い評判が広いコミュニティにすぐ伝わり永久に忘れられないということなんだろうなと思った。本人確認には解像度の高い低いがあるな、とも思った。

2. ミクロ経済学の「繰り返しゲーム」というジャンルであることを知った。フォーク定理もここで知った。

3. メルカリをPlasma上で作るときに信頼する第三者(Trusted Third Party)に配送承認してもらってお金をアンロックする「エスクロー業者」が必要になる。LNのLapps界隈でもそういう信頼する第三者を前提してることに気づく。重要なのは、信頼する第三者が可能な行動はアンロックかキャンセルか、つまりRisk Limitedであるということである。

4. 中央集権取引所も法人という繰り返しゲーム構造の中でやってるし、規制が強まると透明性が増して、より繰り返しゲームっぽくなるなと素人感想を抱いた

5. DEXは技術でダメージを限定して繰り返しゲームが成立しやすくした中央集権取引所かもしれないと思った

6. ほぼ全てが繰り返しゲームに見え始める病気になる

7. Compound Financeも繰り返しゲームを用いればPlasma上に構築できるかもしれないと思って素案を作った

8. Motokichiさんに投げたら立派に数理モデリングしてださって、ウォレットの残高は安全だが貸し出してる最中のお金が結託攻撃で被害にあいうるし、Compound的なP2P貸金だと潜在的な被害のダメージは結構でかくなるなということが確認できた。

9. Plasmaが俺の魂を震わせるのも繰り返しゲームと関係があるのかもと思った

10. 法人は繰り返しゲームだと思った

11. 前々から「子チェーンが止まったらどうなる？」という質問に、「現実的にはユーザーは信頼あるオペレーターなら復旧を待つと思う」と答えていたことを思い出す

12. Plasmaのプロトコルを守った状態でオペレーターを法人にすると、様々なメリットがあるなと思った

13. 検閲や規制や訴訟に弱いなと思った

14. 訴訟するためには所轄裁判所が同じ国(Territorial)でないとアンフェアで成立しにくいなと素人ながらに思った. Plasma以外でもonlyOwnerを訴訟可能にすれば似たようなことはできるかもしれないが、TxのFinalityはプロトコルレイヤーの話になるのでFast Finalityは与えられないかな。

15. エンドユーザーとオペレーターを同じ国で縛ることは、通信レイテンシやステーブルコインの側面からは都合が良いと思った

16. Plasmaチェーンが増えることは、将来的にCommit Aggregationでコストを下げれるから問題ないと思った

17. 訴訟できる(Litigable)ということは、訴訟されたくないので頑張るということもあり得るなと思った.

18. 訴訟も供託も「力」だなと思った

19. ひやさんに「それ、訴訟されるのが嫌で頑張るって仕組みなら、そもそも資産を守るExit Gameいらなくない？」と言われたが、それをすると「個々人の秘密鍵で資産を自己管理している」から「お金を預かってる」に性質が変わるので、ダメだと思った

20. 法的な抑止力は使えるとしてもミニマムに留めるのが効率的だろうなと思った. Risk Limitedな状態を確保した上で、そこに法を使うべきだ、と。

21. 利用規約において「『In-flightな0-conf Txを取り消さない署名』をしたTxがその後L1に記録されなかった場合、それによって生じる損害を法的に補填する旨」を明言することで、Fast Finalityと似た構造を構成できると考えた。しかしIn-flight Txの量が多く、オペレーターの法人の財務状況がよくないとき、オペレーターが利用規約を違反した二重支払い経由の利益を狙う可能性は残る。訴訟できたとしても被害額を取り戻せるとは限らないので、In-flight Txの量の分析と財務状況の監視は重要になる。とはいえ、不正を予想したり署名を法廷で積極的に用いるだけでもかなり先進的だなあと思う。この辺も「Exit Gameは残した方がいい」という直観を支える根拠だと思う。

22. 訴訟されたくないからTxをブロックに含める」というインセンティブは、サービス提供者が受領したTxが0-confであっても信頼することを可能にするため、300ms程度（つまり通信レイテンシ）でスマートコントラクトを実行でき、スマートコントラクトをHTTPと同じ価値にできるなと思った

23. なぜこれらの過程がPlasmaじゃないとダメなんだろうと考えたが、過去記事で考察した「複数人オペレーターだとFast Finalityできない」という結論を無意識に支持していたからだと気づいた. 他のオペレーター(ないしはバリデーター)が故意に起こした「利用規約違反」の責任を他のバリデーターも追う必要がある。

24. にわたこさんが「登記簿に公開鍵を保存するんじゃなくて, 公開鍵共有はSSL証明書でいけそう」と言っているのを見て、確かにと思った. ただ、Ethereumと適合する公開鍵じゃない可能性が高い。ECDSAでSSLは可能なはずだが、どんなハードルがあるだろう。

25. 色々考えた結果Litigable Protocolという呼び方をしようと思った

要約すると

Trusted Third Party

= TTP

Risk Limited TTP

= RLTTP

Litigable Territorial RLTTP

= LTRLTTP

= Litigable Protocol

という順番で理解を進めると良いかもしれない。

また、postalk.io と scrapbox.io がなければこれだけ広く深い範囲を育児とクライアントワークの間に途切れさせず思考することは叶わなかった. また妻とチームメンバーのサポートに感謝したい.

れおなくんと木村くんにも都度都度理論的な背骨を支えるために質問させてもらった。Plasma Cashを提案したKarl, Plasma Cashを実装したヨルゴス, Fast Finalityの素案を出したKelvin, Fast Finalityを一瞬で実装したひやさんがあってこそ演繹可能になったものだと認識している。

「私もたぶんコントリビュートしたはず」と思ったそこのあなた、私が思い出せていないだけなので知らせてください。悪く思わないでください。

以上参考までに