Techhack for life

テクノロジー関連で学んだことを書いていきます。

VitalikのCasper に関するTweet Stormまとめ

VitalikのCasper に関するTweet Stormまとめ

2018年8月15日にVitalikがTweetしたEthereum Casperに関する研究報告に関して、日本語でまとめてみました。

このTweetは合計75にも及びます。

 

みなさんには概要を掴んでもらえればと思い、翻訳のまとめを作ってみました。

  1. 今日私は、EthereumのCasper研究の歴史と現状を説明したFFG 対 CBC戦争に関するつぶやきをしていきます。これは以下の内容も含みます。PoWとのハイブリッド => PoSへのフルスイッチ・ランダム性の役割・メカニズム設計問題
  2. EthereumにおけるPoSの研究は、2014年1月にSlasherの研究から始まりました。このアルゴリズムは最適ではありませんでしたが、いくつかの重要なアイデアを与えてくれました。特に、”Nothing at Stake” 問題の解決のために罰金を使用するというアイデアを見つける助けになりました。
  3. つまり、私が使用した罰金は非常に小さく、サイン報酬をキャンセルするだけでした。Vlad Zamfirは2014年中頃に参画し、不正行為を防ぐために、報酬よりもはるかに大きな *デポジット* をおくバリデーターを必要とする方向に素早く方針を変えました。
  4. ここにVladの主張があります。
  5. 2014年後半には、攻撃者がメインチェーンの預金からデポジットを引き出し、主力チェーンよりも多くの署名を持つ別の「攻撃チェーン」を作成するために使用する”ロングレンジアタック”問題に対処しようと多くの時間を費やしました。この攻撃チェーンを用いることで、 使用するチェーンをこのチェーンに切り替えるようクライアントを欺くことができます。
  6. 現時点では攻撃チェーンがメインチェーンから分岐している場合、これは問題ではありません。バリデーターが2つの競合するチェーンに2つの矛盾するメッセージに署名すると、これを罰金としてデポジットを没収する証拠として使用できるからです。
  7. しかし、分岐がずっと前に起こった場合(以下ロングレンジアタックと呼ぶ)、攻撃者は預金を引き出していずれかのチェーンに対するペナルティを防ぐことができます。
  8. 私たちは最終的に、PoW支持者が言っている理由では、長距離攻撃が避けられないと結論づけました。しかし、私たちは彼らの結論を受け入れられませんでした。
  9. 追加のセキュリティを導入することで、ロングレンジアタックに対処できることを発見しました。クライアントは少なくとも4ヶ月に1回ログオンし(預金は引き出しに4ヶ月かかります)、クライアントはそれ以降の巻き戻しを単に拒否します。
  10. これは、信頼がある前提の話に思えるので、PoWの提案者にとっては賛成しかねるものでした。最初に同期するときに信頼できるソースからブロックチェーンを取得する必要があるためです。
  11. しかし、われわれの汚れた主観主義者にとって、それは大きな問題のようには見えませんでした。どのような場合でもブロックチェーンのコンセンサスルールが何であるかを(ソフトウェアアップデートを忘れないで)伝えるために信頼できる情報源が必要であるため、このPoS仮説によって必要とされる追加の信頼性はそれほど高くありません。
  12. Vladが言及した記事
  13. デポジットと罰金を適用したため、これらのデポジットと罰金が何であるかを決定しなければなりませんでした。私たちは、「経済的ファイナリティ」属性を自分たちが望んでいたことを知っていました。ここでバリデーターは以下のような方法でブロックに署名します。
  14. ブロックが一度「ファイナライズ」されると、ブロックチェーンが検出し罰することができる方法では、バリデーターの大部分が以前のメッセージと競合するメッセージに署名しないと、ファイナライズされる競合ブロックは存在しませんでした。
  15. 私は長い間、究極的に非生産的で、私が ”consensus by bet” と呼んでいたものに触れていました。
  16. ”Consensus by bet”は、バリデーターがブロックをファイナライズする賭けを行う興味深い方式であり、賭け自体が、コンセンサスがどのチェーンを好むかを決定します。
  17. 理論的には、PoWにもこの性質があります。マイニングは正しいチェーンに賭ければ(報酬・マイニングのコスト)を受け取ることができ、そして間違ったチェーンに賭ければマイニングのコストは失われます。PoSを除けば、私たちはベットのオッズをもっと高くすることができました。
  18. バリデーターの賭けに対するオッズは低い値から始めますが、バリデーターが互いのブロックについてより確信するのを見て、すべての人のオッズは指数関数的に並行して上昇し、最終的にブロック全体に預金を賭けるだろう。これが ”ファイナリティ” となるでしょう。
  19. その間、Vladはメカニズム設計の研究を開始しました。特に、独占に対してCasperをより堅固にすることに目を向けました。また、Tendermintなどの従来のビザンチンフォールトトレランス理論からインスパイアされたコンセンサスアルゴリズムも検討し始めました。
  20. Vladは伝統的なBFTは不自由であると判断しました(特に、PBFTやTendermintの2/3のような厳しい閾値を嫌いました)。そして、彼は 自らが “Correct by Construction” (CBC)と読んでいるアプローチを用いて、BFT理論をゼロから作り直すことを試みました。
  21. Vlad自身の言葉①Vlad自身の言葉②
  22. CBCの考え方は、「ファイナリティ」が完全に主観的であるという点で、伝統的なBFTとは非常に異なっています。 CBCの哲学において、バリデーターはメッセージを署名します。もし、以前のメッセージと衝突するメッセージに署名した場合、
  23. 彼らは、彼らが過去に投票したものよりも新しく投票したものの方が ” より支持 “ されていて、新しい方に切り替える権利があるという正当性を証明しなければならなりません
  24. ファイナリティを検出するために、クライアントは、多くのバリデーターがBブロックに対して信頼できる投票をしていることを証明するメッセージのパターンを探します。この方法では、大部分のバリデーターが”違法に”自分たちの投票を切り替えることなしでは、Bブロックから切り離すことはできません。
  25. 例えば、もし全ての人がBブロックに投票し、その後全ての人のBブロックに対する投票を含んだあるブロックを、全ての人が投票するとします。これは彼らがブロックBをサポートし、他の全ての人がBをサポートすることに気づいていることを証明することになります。なので、Bブロック以外に切り替える正当な理由はありません。
  26. 私は結局のところ、アプローチが根本的に危険すぎるように思えたので、consensus-by-betを断念しました。そのため、PBFTのようなアルゴリズムの仕組みを理解しようとしました。それはしばらくかかりましたが、数ヶ月後に私はそれを理解しました。
  27. 私はPBFTを簡素化し、それをブロックチェーンの文脈に翻訳し、4つのルール「Slashing Conditions」として説明しました。メッセージのどのような組み合わせが自己矛盾し、したがって違法であるかを述べたものです。https://t.co/ch1rcaPLLl
  28. 私は、ブロックがファイナライズされる時期を決定するためのルールを定義し、キーの “安全”と “妥当な生存”プロパティを証明しました:(i)ブロックがファイナライズされた場合、1/3以上がスラッシング条件に違反することなしでは競合するブロックがファイナライズされる方法はありません。
  29. (ii)ブロックがファイナライズされた場合、2/3の正当なバリデーターが常に協力して新しいブロックをファイナライズすることができます。したがって、2/3以上が正直である限り、アルゴリズムは「過去に戻る」ことも、「その場に立ち往生する」こともできません。
  30. 私は最終的に最小スラッシング条件を4から2に単純化しました。そこから、ファイナリティの保証を追加するためにPoWまたはPoSまたは他のブロックチェーンの上にオーバーレイとして使用できるように設計されたCasper the Friendly Finality Gadget(FFG)が考案されました。
  31. ファイナリティは非常に重要な進歩です:ブロックがファイナライズされると、ネットワーク待ち時間に関係なく安全です(PoWにおける確認方法とは異なります)。ブロックを元に戻すには、バリデーターの1/3以上が検出可能でデポジットを失う方法で不正行為する必要があります。
  32. したがって、ファイナリティを取り戻すコストは、数十億ドルにも達する可能性があります。 Casper CBCとCasper FFGのアプローチは、どちらも技術的に異なる方法でこれを達成しています。
  33. Casper CBCとCasper FFGは、どちらも既存のフォーク選択ルールの上に適用する必要がある”オーバーレイ”であることに注意してください。抽象化は異なる方法で動作します。
  34. 最も簡単な言い方をすれば、Casper CBCでは、ファイナリティのオーバーレイがフォーク選択ルールに適応しますが、Casper FFGではフォーク選択ルールがファイナリティのオーバーレイに適応します。
  35. Vladが最初にフォーク選択ルールに選んだのは、GHOSTをPoSに適合させた「latest message-driven GHOST」であり、私の初期の好みは、 ベースフォーク選択ルールとしてPoWを使用した、ハイブリッドPoSでした。
  36. Casper FFGの最初のバージョンでは、PoWはブロックごとにチェーンを「実行」し、PoSはブロックを確定するために後ろから追うことになります。 Casper CBCは、最初から完全なPoSでした。
  37. 同時に、Vladと私は共にコンセンサスのインセンティブ化の理論についてそれぞれの考え方を閃いています。
  38. ここで、非常に重要な違いは、誰が責任を負っているかを知ることができ、それにペナルティを課すことができる、「一意に起因する障害」と、複数の当事者のうちの1人がその障害を引き起こしていた「一意に起因しない帰結」です。
  39. 古典的な一意に起因しない障害の例は、”speaker-listener fault equivalence”とも呼ばれ、検閲とオフラインで行われています。
  40. 一意に起因する障害(例えば、Casper FFGのSlashing条件)を罰則することは簡単です。 一意に起因しない不具合を罰することは困難です。
  41. 少数派がオフラインになったり、多数が少数派を検閲しているために、ブロックがファイナライズを停止したかどうかを知ることができない場合はどうすればよいでしょうか?
  42. この問題には、基本的に3つの考え方があります。(i)両方を少し罰する(ii)両方を強く罰する(Vladの好み)(iii)チェーンを2つに分割し、各チェーンの一方の側にペナルティを課し、市場がどのチェーンがより価値があるかを決定させる(私の好み)。
  43. または、私はこれに関してブログを公開しました。
  44. 2017年11月、「1/3がオフラインになる」問題を「二次的なリーク」メカニズムによって解決するための私の考えを加えたCasper FFGのスラッシング条件は、論文になりました。
  45. もちろん、私は、51%の攻撃を解決するためにソーシャルレイヤーを魅力的にすることは非常にうれしいことではないことをよく知っていたので、少なくともオンラインのクライアントがどのチェーンが「正当な」もので、どれがリアルタイムに”攻撃されている”ものかを自動的に検出できる方法を探し始めました。
  46. ここに私の以前のアイデアがあります:それは何かしらの価値がありましたが、依然として最適ではありませんでした。ネットワークの待ち時間がまったくゼロでない限り、クライアントの疑いスコアが最大差異で異なることが保証されているだけで、クライアントは完全に同意しませんでした。
  47. その間、Vladのモデルに対する私の主な批判は、誰もがお金を失う原因となる51%攻撃を攻撃者が確実に実行でき、それによって他のすべての人が離脱してゼロに近いコストでチェーンを支配する “discouragement attacks”に対処する方法を考えなければならないことでした。
  48. Vlad(Georgios Piliourasと一緒に)は、彼のモデルの下でそのような攻撃にかかる実際のコストを推定するために経済モデリングを始めました。
  49. これらのすべての問題は、PoSに特有のものではないことに注意する必要があります。 実際PoWでは、人々は単純にあきらめ、51%の攻撃が完全に不可能であると想定する傾向があり、51%の攻撃はいかなる場合でも防がなければならない最悪の終焉です。
  50. しかし、Ethereumの伝統と同様に、Vladと私は、この研究は”野心的である”という言葉はお世辞ではないことに気付かず、51%の攻撃から消し去り、緩和し、回復する別々のアプローチに取り組み続けていました。
  51. 2018年の早い段階で、VladのCBCに関する作業は早く進んでおり、安全性の証明について大きく進展しました。 2018年3月の進捗状況については、この壮大な2時間のプレゼンテーションをご覧ください。
  52. その間、Casper FFGは大きな進歩を遂げていました。 Ethereumブロックチェーンに公開されるコントラクト として実装することで、開発が容易になりました。 2017年12月31日23:40に、pythonで書かれたtestnet版をリリースしました。
  53. 残念なことに、FFGの開発は遅くなりました。 FFGをコントラクトとして実装するという決定は、いくつかのことを楽にしましたが、他のことを困難にし、EVMからEWASMへの最終的な切り替え、そしてSingle chain CasperからShardしたCasperへの移行が困難になることを意味しました。
  54. さらに、チームの仕事は “Main Chain Casper”と “Shard Chain Casper”に分割されており、CasperとShardingチームの間では不要な重複作業が行われていたことは明らかでした。
  55. 2018年6月には、「Hybrid Casper-FFGをコントラクトとして実装することを廃止する」という運命的な決定を下し、代わりにShardingの統合がはるかに簡単なように設計された独立したチェーンとして完全なCasperを選びました。
  56. 完全なPoSへの切り替えを考えるときに、私はPoSの選択ルールについてより深く考え始めるようになった。
  57. Casper FFG(とCBC)はブロックを完成させるために、すべての “Epoch”で投票するように設定された全体のValidatorを必要とします。つまり、1秒ごとに数十から数百の署名が来るでしょう。BLS署名集合は、計算上のオーバーヘッドの点でこれを実用的にします。
  58. しかし、私は、これらの余分な署名をすべて利用して、チェーンをはるかに「安定」にして、数秒以内に「100 confirmation」分の価値のあるセキュリティを得ようとしました。
  59. これは私の最初の試みです。
  60. しかし、フォーク選択ルールへのこれらのアプローチはすべて、弱点を持っていました。バリデータを「保証人」と「提案者」に分割し、ブロックの生成において主要な推進要因となる提案者は圧倒的な力を持っていました。
  61. これは、主に提案者を公正に選ぶために、連鎖乱数生成の強力なソースを必要としていたため、望ましくありませんでした。 また、RANDAOのような単純なアプローチでは、チェーン上のランダム性は*厳しく*、見れば見るほど問題を抱えているように思えました。(https://t.co/ZaW2itzq2o)。
  62. Justin Drakeと私はこの問題を2つの方法で解決しようとしました。確定可能で検証可能な出力を持つ遅延関数を使用して計算します。しかし計算のために並行不可能な連続時間を大量にとり、事前に操作を不可能にします。
  63. そして自分自身、Vlad™のCultに大きな譲歩をして、GHOSTベースのフォーク選択ルールを使って提案者への依存を大幅に減らし、証明者の50%以上が友好的である限り、提案者の90%以上が悪意のある場合でもチェーンを途切れることなく成長させることを推奨しました 。
  64. Vladは非常に満足していましたが、完全なものではありませんでした。検証者の”latest messages”に基づいたGHOSTのバージョンを好んでいましたが、私は”immediate”バージョンを使うことを好みました。https://t.co/Q8rBq6bcoC
  65. この頃、私はCasper FFGを「パイプライン化」する方法を考案し、ファイナリティに至る時間を2.5エポックから理論上最適な2エポックまで短縮しました。https://t.co/0eutcy7Rhp
  66. RPJのフォーク選択ルール(” immediate message-driven GHOST ”と改名)は、ほとんどの他のものがうまくいかない方法で、Casper FFGとうまく適合していることをとても嬉しく思います。
  67. そして、それは非常に重要な “Stability” 特性を持っているということです:フォークの選択は将来のフォーク選択の良い予測です。これは明らかですが、このプロパティを持たない” fork “の選択ルールを誤って作成するのは非常に簡単です。
  68. 全体の最新の開発は以下の結果です、” latest message driven GHOST ”は、2つのラウンドで25%のフォールトトレランスしか得られないが、FFGまたはCBCの”immediate diriven message GHOST”はまだ完全な33%を提供できます(まだまとめていません)。
  69. FFGとCBCとの間の主なトレードオフは、CBCがより良い理論的特性を有するように見えるが、FFGは実装が容易であるように見えるところです。
  70. その間に、検証可能な遅延機能は大きく進展しました: https://t.co/XsRUmZH2ap
  71. また、私は最近 Leslie Lamportの1982年の古い論文を見ることにしました。そこでは、オブザーバーを含むすべてのノードがオンラインでネットワーク遅延が少ないという前提を追加すると、99%のフォールトトレランスを持つコンセンサスアルゴリズムがありました。https://t.co/PnDBzRRT9w
  72. ネットワーク待ち時間を仮定すると、主なコンセンサスアルゴリズムとしてこれを確実に不適当なものにします。 しかし、51%の検閲の疑う値の代用として、本当にうまく機能するユースケースが1つあります。
  73. 基本的に、51%の連合がブロックの検閲を開始すると、他のバリデーターとクライアントがこれが起こっていることを検出し、99%のフォールト・トレランス・コンセンサスを使用してこれが起こっていることに同意し、マイノリティフォークを調整します
  74. この研究の長期目標は、社会層への依存をできるだけ減らし、社会層への復帰を必須にするために、チェーンを不安定化するのに必要なコストを最大にすることです。
  75. 後は何が残っているでしょうか? FFG側では、安全かつ迅速な展開に焦点を当てることで、正式な証明、仕様の改良、実装の進捗状況(すでに3つ以上のチームによって開始されています)などです。 CBC側でもほとんど同じです。

以上、VitalikのTweetを訳してみました。

結果、これだけ見ても、深くは理解できないですね。

実際はここで紹介されているブログ記事・論文などを読み漁っていくしかないと思います。

参考文献:https://twitter.com/VitalikButerin/status/1029900695925706753