Over Protocol「 Towards True Decentralization」翻訳③
この記事ではOverProtocolの「Towards True Decentralization」というホワイトペーパーの翻訳を行なっています。
引用元：https://drive.google.com/file/d/1DNK0FFOVhnVDRnz8h9RJ1NoDUN4W0He8/view
3 コンセンサスの解放：障壁の打破
ブロックチェーンの世界において、コンセンサスアルゴリズムは試合の審判のようなものです。全員が同じルールに従っていることを確認し、ネットワーク内のすべての台帳を同期させ、トランザクションを検証し、参加者間の信頼を醸成する分散型で改ざん不可能なシステムを維持します。これらのアルゴリズムにはさまざまな種類があり、例えば、マイナーに複雑な数学パズルを解かせるProof-of-Work（PoW）や、トークン保有量に基づいてバリデーターを選択するProof-of-Stake（PoS）などがあります。
Over Protocolでは、PoSが運用の中心にあります。参加者は市場から相当量のOVERトークンを準備し、それを担保としてブロックの作成と検証を行います。役割を成功裏に果たせば、OVERで報酬が与えられます。しかし、悪意のある活動は、一時停止から賭けたOVERトークンの完全な喪失まで、様々なペナルティにつながる可能性があります。つまり、公正にプレイすることは単に推奨されるだけでなく、必須なのです。
PoSアルゴリズムには幅広い選択肢がありますが、Over ProtocolではEthereumのGasperに沿うことを選択しました。私たちのミッションは、一部の選ばれた人々を不当に優遇しないブロックチェーンを構築することであり、コンセンサスアルゴリズムの選択もそれを反映させたいと考えました。
多くの新しいブロックチェーンは、少数のバリデーターが選ばれるDelegated Proof of Stake（DPoS）形式を採用する傾向にあります。しかし、これらのバリデーターが高い基準を満たさない場合、パフォーマンスの問題を引き起こす可能性があります。彼らはブロックチェーンコンセンサスの速度とパフォーマンスを確保するために、堅牢なノード運用環境を管理することが期待されますが、高度なインフラストラクチャと多額の資本が必要なため、一般の人々にとっては高いハードルとなっています。
対照的に、EthereumのGasperはより多くのバリデーターのプールを許容し、洗練されていないノード運用環境を持つ人々にもより適応しやすくなっています。Overのフィロソフィーとブロックチェーンのビジョンに沿って、私たちはGasperを少し調整したバージョンを採用しました。この動きにより、より包括的なコンセンサスプロセスが確保され、リソースに関係なく、誰もがブロックチェーンへの参加がより容易になります。
実際には、Ethereumのステーキングは中央集権化の傾向を示しており、ステーキング額の約56%が上位4つのバリデーターによって保有されています。この集中は分散化の核心的な目標に反し、重大な障害となっています。私たちは、その根本原因が高いハードウェア要件にあると考えています。理論的にはコンセンサスプロトコルは数百万のバリデーターをサポートしていますが、ノードを運用するための実際の要件は依然として大きな障壁となっています。
Over Protocolは、軽量クライアント技術の力を活用することで、この問題に正面から取り組むことを目指しています。これらの技術は、リソース要件を大幅に削減し、基本的なPCを持つ誰もがノードを運用し、バリデーターの役割を担うことを可能にします。これらの技術をGasperと統合することで、Overはホームステーキングの概念を実現します。結果として、リソースに関係なく、誰もがネットワークのセキュリティと安定性に貢献できるようになります。
3.1 バリデーターの要件
Over Protocolにおいてバリデーターとなり、その地位を維持するための要件は、積極的な参加の必要性とアクセシビリティのバランスを取るように設定されています。以下は主な要件の説明です：
バリデーターになるために必要な最小限のOVERをステーキングすること
OVERの最小ステーク要件は、バリデーターが重要なものをリスクにさらすことを確保し、コンセンサスに積極的に参加するよう動機づけます。これはコインの価値を安定させ、迅速なコンセンサスを支援します。しかし、Over Protocolはアクセシビリティの必要性を認識し、不必要な障壁を作りたくありません。現時点では、システムの完全性を損なうことなく、可能な限り多くの参加者を含めることを考慮して、256 OVERがステーキング要件として選択されています。
少なくとも70%のアップタイムを維持すること
すべてのバリデーターは少なくとも70%のアップタイムを維持しなければなりません。この基準はシステムの安定性にとって重要です。なぜなら、コンセンサスプロセスはバリデーターの数と各バリデーターの平均アップタイムの両方に依存しているからです。重要なことに、私たちの数学的モデリングは、システムが専門的な運用expertise（例：ブロックチェーンインフラストラクチャプロバイダー）を持つ選ばれた少数ではなく、普通の個人のみによって運営されるという仮定のもとで行われています。計算によると、16,384以上のバリデーターが関与していると仮定した場合、普通のバリデーターの70%のアップタイムがシステムの安全性を保証します。
これらの数字の詳細な説明については、付録Cを参照してください。私たちのシステムでは、各バリデーターのアップタイムを評価するためのリスクスコアと呼ばれる評価スキームを導入しています。バリデーターがアップタイムのベンチマークを満たさない場合、そのリスクスコアが上昇します。スコアが特定の閾値を超えると、そのバリデーターのコンセンサスへの参加が重大なリスクを示すため、バリデーターは検証ネットワークから除外されます。この戦略により、バリデーターはオンラインプレゼンスを維持することに専念し、ネットワークの信頼性にプラスの影響を与えることが保証されます。包括的な理解のために、次のセクションを参照してください。
要するに、Over Protocolのバリデーターになるための要件は、参加をできるだけアクセシブルに保ちながら、安定で堅牢なネットワークを確保することを目的としています。バリデーターの利益をネットワークの安定性と一致させ、慎重に調整された一連のルールを提供することで、Over Protocolはバリデーターが重要な役割を果たす繁栄するエコシステムを育成することを目指しています。
3.2 バリデーターの報酬とペナルティ
報酬とペナルティのシステムは、ブロックチェーンネットワークをより高いセキュリティに導くメカニズムとして機能します。報酬は、誠実で勤勉な参加者がネットワークへの貢献を続けるよう奨励するように設計されるべきです。一方、ペナルティはネットワークに害を与える可能性のある参加者を抑止または迅速に除去するように設計されるべきです。ただし、過度に厳しいペナルティが心理的な障壁を作り出すことで参加を妨げないよう注意が必要です。
Gasperの報酬とペナルティの構造は、これらの要因を考慮して繊細にパラメータ化されています。バリデーターは、ブロックを作成する機会が与えられたとき、比較的大きな報酬を受け取ります。しかし、長期間の積極的な検証では、各エポックでの証明に参加することからの報酬がより重要になります。本質的に、システムはバリデーターが勤勉に活動し続けるほど、より多くの報酬を与えます。
逆に、参加しないことに対するペナルティは潜在的な報酬とバランスが取れており、短期的なノードの停止のような一時的なダウンタイムに対して過度に罰則的にならないようにしています。
しかし、コンセンサスに対する直接的な脅威は、スラッシングとして知られる厳格なルールを発動し、強力なペナルティを課します。スラッシングは、1）提案者が矛盾するブロックを配信した場合、または2）証明者が矛盾する投票をしたり二重投票に関与したりした場合などの状況で適用されます。これらの違反を目撃したバリデーターは内部告発者となり、ネットワークに証拠を提示します。違反者は厳しい資産没収に直面し、検証権を失います。
オフラインバリデーターの救済
Over Protocolでは、この基本的な報酬とペナルティ構造に、オフラインバリデーターの救済メカニズムが追加されています。救済メカニズムは、適切なアップタイムを維持していないバリデーターをコンセンサスから迅速に除外します。バリデーターのリスクスコアが設定された閾値を超えると、ネットワークから救済（除外）されます。このスコアは長期的なダウンタイム中に増加し、アップタイム時に減少します。システムはこのようにして、一貫して適切なアップタイムを維持できない者を監視し、救済（除外）します。
このリスクスコアを実装する主な理由は2つあります：
バリデーターの残高の保護：
コンセンサス駆動型のブロックチェーンシステムでは、バリデーターは一定量の資産を担保として提供します。これにより、ネットワークの適切な機能とセキュリティに対する彼らの既得権益が確保されます。バリデーターが非アクティブまたは不正行為を行った場合、ペナルティが課され、この担保残高から控除されます。時間が経つにつれ、バリデーターが非アクティブのままであれば、これらのペナルティが蓄積し、担保を大幅に侵食する可能性があります。
救済メカニズムは、このようなシナリオにおける保護措置として機能します。一貫して非アクティブなバリデーターを検出し排除することで、システムは彼らの残高が過度に枯渇するのを防ぎます。これは安全網のようなもので、バリデーターが長期的な非アクティブ状態（技術的な不具合や予期せぬ障害など、時には彼らの制御を超えた要因による）によって取り返しのつかない財務的損害を被らないようにします。
さらに、このメカニズムは個々のバリデーターだけでなく、ネットワーク全体の財務的インセンティブも保護します。バリデーターが長期的なダウンタイムにより大量の担保を失っているのを見れば、潜在的なバリデーターが大きな損失を恐れてネットワークへの参加や継続を躊躇する可能性があります。システムのセキュリティと最適なパフォーマンスの確保：
ブロックチェーンネットワークは、バリデーターの積極的な参加によって繁栄します。彼らはチェーン内のトランザクションやブロックの提案、検証、最終決定に責任を負います。非アクティブなバリデーターはこのプロセスを遅らせる可能性があります。さらに、大量の非アクティブなバリデーターの存在は、ネットワークを攻撃に対してより脆弱にし、全体的なセキュリティを低下させる可能性があります。
救済メカニズムは、これらの非アクティブな参加者を特定し除去することで、アクティブで信頼できるバリデーターのみがコンセンサスプロセスに貢献することを保証します。これにより、ネットワークのパフォーマンスを最適化し、セキュリティ基準を維持します。
本質的に、救済メカニズムは保護的かつ先制的な機能であり、バリデーターの財務的健全性とネットワークの運用の完全性を維持します。リスクスコアは、ネットワーク内に少なくとも16,384のバリデーターがいると仮定して、バリデーターが67%以上のアップタイムを維持するよう奨励するように設計されています。ネットワークの初期段階でバリデーターが少ない場合、必要なアップタイムの閾値は70%に設定されます。バリデーターの数が増えるにつれて、この閾値は徐々に67%のアップタイムまで下がります。
この設計は、より多くのバリデーターが統計的観点からシステムの回復力を本質的に向上させることができるため、バリデーターのアップタイム閾値を下げることができることを考慮しています。しかし、バリデーターの数に関係なく、ダウンタイム中にはリスクスコアが増加し、アップタイム中にはスコアが減少します。公式と図の詳細については、付録Dを参照してください。
この記事が気に入ったらサポートをしてみませんか？