Ouroboros Leios[ input endorsers ]デザインドキュメント概要翻訳🎉
1 現在のPraos版Ourorbosoの課題：ネットワークやCPUの利用において、設計的に生じている無駄がある＝スケーラビリティに限界がある
2 デザイン目標：次の２点のスループットを、レイテンシー（取引が確定する時間）の犠牲とのバランスを保ちながら、セキュリティは（50％の敵への耐性を）保持しながら最大化すること
1. データスループット。1秒あたりのバイト数で測定される（通常、1秒あたりのキロバイ ト数、kB/s）。
⇨現在：ブロックサイズ最 大88kB、生成頻度平均20秒ごとなので88kB/20s=4.4kB/s
2. スクリプトのスループット。ウォールクロック時間あたりのCPU秒数で測定される3 （ 通常、ウォールクロック秒あたりのCPUミリ秒、ms/s）。
⇨現在：1 ブロックあたり40msなので40ms/20s = 2ms/s。
※1,2の最適化の結果としてTPSが上がるが、TPSは役立たない指標です。スマコンなしの小さなものをたくさん処理する前提かそうでないかで全く違う数値になります。
3.デザイン戦略
みんなで「順番に処理」するから無駄があります。さまざまなやり方がありますが、基本的には互いに相入れないトランザクションがたくさん出てこないと思われるものについては一旦処理し、最後に無効だったことが判明したものを破棄する方法があります。この方法はUTXOの場合、それを判断することが簡単なので適しています。
4.デザイン概要
(A)大まかな流れ：IB、EB、RBの3種類のブロックとERという概念が登場
-1.Input blocks（IB）作成：0.2-2秒1回選ばれたSPOが（ステークが多いほどに選ばれすい）トランザクションからRBを参照して入力ブロックを作って署名する。これはRanking blocks になります。
-2.IB検証：他のSPOがそれをチェックします。これは独立して検証できます。
-3.Endorsement blocks（EB） 作成：5-10秒に1回選ばれたSPOがIBに対して検証して署名します。
-4.EBの検証とEndorsement reports（ER）発行：一定時間経ったら、選ばれたたくさんの50%以上ぐらいのSPOがEBを検証してERを発行します。
-5.Endorsement certificatesの作成：ERが50％以上ぐらい集まったら、証明書を作ります。
-6.Ranking blocks （RB）作成：5-10秒ごとに選ばれたSPOが証明書の作れる平均的に2-4個ほどのEB達についてRBを作成します。含められるEB数は上限があり、また、選べる場合は多くのIBのあるものを選びます。（RBのセキュリティなどは現在のPraosと同じようなものと考えて良いです）
(B)他のデザイン上の論点
・Mempoolシャーディング：いろいろな方法があるので試行錯誤必要だが、現在考えられているのはトランザクションに色が付され、例えば赤、青、緑があるが、赤のみの入力ブロックを作るとなったら赤のトランザクションのみを含めていく方法。例えば互いに影響し合うものについては同じ色で送信すればスムーズになる。
・IB、EBの有効となる最小最大の期限：最小期限を決める理由：より早くブロックを作成したもの勝ちの仕組みにすると同じ地域に集積した方が有利となり地理的分散性を害する。最大期限を決め理由：フラッディング攻撃対策（多くのブロック生成権があるので、一旦生成を遅らせて、後になって一気に放出する攻撃）や検閲攻撃対策
・二重署名対策：また矛盾したIB、EBにサインされたものがたくさん送られるというのの対策が必要です。RBは不要です。
・大きなステークを持つ場合、IB、EBなどを恣意的にコントロールできてしまう可能性があるので、対処も必要です。
・最新の状態に追いついてないと、いずれにしてもプロトコル参加は難しいです。
・参加者が減少してERが十分集まらなくなったら、Praosモードに切り替わる「悲観モード」も必要です。悲観モードではトランザクションが直接RBに入ります。
・タイムスロットについてはPraosでは単にスロットだったが、Leiosではいくつかの選択肢がある。IBやRBを基準にする方法も考えられるがメリットデメリットがある。
（その他色々話されてますが4.4-4.7以降細かいので割愛）
5.開発戦略
数年かかりになるだろう。設計の査読、パラメータの分析、形式言語で記述検証、今まで以上の入念なプロトタイプ、切り替えの実装方法、アプリのためのテストネットなど。
6.他の機能との依存関係
・メモリ要件をレジャーの状態をオンディスク保存する機能で削減。Leiosにも必要。
・GenesisはLeiosより前に実装されると考えられるため、この対応が必要
・Leiosの要件に合うようにPraosの台帳を変えていく必要がある。
7.今後の方向性
・Leiosをそのまま導入するとレイテンシー（取引確認遅延）が増加するので、これを短縮する工夫が必要。１つのアイデアはIBがRBだけではなくEBも参照すること。チャンレンジングな方法です。
・Leiosが目指すものは「垂直」スケーラビリティですが、水平スケーラビリティも加える兆候もある。必要な入力ブロックのみを検証するなど。
8.どれぐらいの速さが欲しいですか？
Leiosはトレードオフを要求するものです。無駄になっている資源を利用してスケーラビリティを高めますが、さらに望む場合は、それもできます。ただしテラバイトのディスク、重いメモリ等々で、例えばラズパイ利用者や一般家庭からSPOになったり、フルノードウォレットを利用したりすることを不可能とします。Bitcoinでもこのような議論があり、分散性を守るためにスケーラビリティを拡張し過ぎない選択肢を取りました。