RenVM グレイコアへの道
RenVMの次の最大のステップは、間違いなくGreycoreの導入です。 このブログ投稿では、Greycoreとは何か、Greycoreのサポートに至るまでに取り組んできた機能の概要、およびそれをどのように展開するかについての詳細を少し説明したいと思います。このトピックに関する以前のブログ投稿も読んでください。
Greycoreは、RenVMの分散化に向けた次のステップです。 現在、RenVMでのコンセンサスと実行は、Renコア開発チームが運営するDarknodeの責任であり、ピアツーピアネットワーキングはコミュニティが運営するDarknodeの責任です。 グレイコアは、コンセンサスとその後の実行に責任を持つサードパーティの最初のグループになります。 グレイコアは、最終的にはコミュニティによって補完され、将来のリリースでは、最終的にはコンセンサスと実行の制御も引き継ぐことになります。高レベルの構造の詳細については、こちらを参照してください。
準備において、どのような新機能を開発しているのか？
RenVMをMainnetにリリースすることで、ネットワーク、ネットワークの使用方法、ユーザーが経験している苦労、開発者が不足している機能、Darknodeオペレーターが望んでいたツールについて多くのことを学びました。 昨年のリリース以来、Renコア開発チームは、Greycoreを展開する前に実施したいと考えていたRenVMへのアップグレードに注力してきました。 ここにいくつかの大きな事項を記します。
- 監視ツール。これは、ネットワークがどのように動作しているかを理解するために重要です。特に、世界中の約2,000台のマシンがネットワークの電力供給に役立っている場合はなおさらです。
- ネットワークの安定性が向上しました。昨年、ハイパードライブの構造を改善し、より多くのバリデーターに拡張し、予期しない再起動からより効率的に回復し、発見されたいくつかのバグを修正できるようにしました。また、数千のピアに拡張した後に明らかになった安定性の問題のいくつかに対処するために、Airwaveに改善を加えました。
ガスコストの削減| RenVMはロックされた資産を管理するため、基礎となるチェーンにガス料金が発生し、最終的にユーザーに渡されます。これらの基礎となるガス料金が可能な限り低くなり、RenVMの使用が可能な限り安価になるように、RenVMの最適化に多大な努力を払いました。 - より優れたMPCライブラリとフレームワーク| MPCライブラリを改善（およびオープンソース）し、正確性、監査可能性だけでなく、パフォーマンスも最適化しました。発売以来、MPCの実装は大幅に改善され、以前よりも高速かつスムーズに実行されています。
- 堅牢なストレージドライバー|予期しないクラッシュは避けられないため、すべてのシステムはそれらに対応できるように設計する必要があります。昨年、ストレージドライバーのアップグレードに多くの注意を払い、RenVMがクラッシュしたときに、一貫性のない/破損した状態にならないようにし、回復を自動的に実行できるようにしました。
アセットとチェーンを追加|これにより、Renコア開発チームは、新しいアセットとチェーンを追加することの複雑さについて学ぶことができ、マルチチェーンの開発に至りました。この開発により、Darknodeが制御不能になった場合でも、下位互換性のある方法で新しいアセットとチェーンを簡単に追加できると確信しました。 - 上位互換性|これまでの最大の努力は、トランザクション形式とブロック形式をアップグレードして、RenVMが将来持ち込みたい新しい変更と上位互換性があることを確認することでした。分散型環境では変更が難しく、スムーズなアップグレードには上位互換性が不可欠であるため、これは重要です。
それは長いプロセスであり、当初の予想よりも時間がかかりました。ただし、最新バージョンのRenVM（v0.4.0）は、これらすべての学習を組み合わせており、非常に誇りに思っている実装に到達しました。昨年私たちが取り組んできたすべてのことは、Greycoreの展開がスムーズに行われ、ネットワークが中断される可能性が可能な限り低くなるようにすることに直接貢献しています。
グレイコアの次のステップ| どのように展開されますか？
現在、Testnetをv0.4.0にアップグレードし、発見された問題を修正しています。これらの問題がすべて修正されたら、Greycoreに制御を渡します。この時点で、TestnetはGreycoreによって運用されます（そして、将来にわたって継続されます）。これにより、すべてのメンバーは、Darknodeの実行の詳細、最新の状態の維持、予期しないイベントからの回復などに慣れることができます。また、Renコア開発チームは、より分散化された環境で効果的に作業する方法を理解する機会が得られます。最後に、これにより、Renコア開発チームは、制御できなくなったネットワークに対して広範なテストを実行する最後の機会が得られます。私たちは、モックトランザクションでネットワークを槌で打ち、それを壊そうとし、Greycoreメンバーを支援するために必要なプロセス/ツールを開発することができます。
これが発生している間、Renコア開発チームはMainnetの現在のバージョンをアップグレードして、この最新バージョン（v0.4.0）を実行します。この予備アップグレードにより、Greycoreに制御を渡す前に下位互換性の問題がないことを確認する機会として使用するため、次のステップがはるかに簡単になります。 v0.4.0には、Greycoreメンバーの追加を簡単で簡単なプロセスにするいくつかの機能が含まれているため、これも必要です。
Testnetが安定し、広範囲にテストされ、すべてのメンバーがセットアップに満足し、現在のMainnetがv0.4.0にアップグレードされたら、新しいGreycoreメンバーをMainnetに導入し始めます。
Renコア開発チームが最大限のサポートを提供できるようにするために、Greycoreメンバーを一度に1人ずつMainnetに紹介します。これにより、予期しない問題から迅速かつ効果的に回復し、すべてのメンバーが必要なサポートを受けられるようにすることができます。
要約すれば：
- v0.4.0を実行し、Greycoreのできるだけ多くのメンバーによって動作する新しいTestnetをデプロイします。
- 既存のメインネットをアップグレードしてv0.4.0を実行し、下位互換性の問題に対処します。
- グレイコアメンバーをメインネットに1つずつ追加します。 これは、手順1と2が開始されてから約4週間後に発生すると予想されます。
このプロセスの終わりまでに、RenVMコンセンサスはGreycoreによって強化されます。 これは、プロジェクトが開始されて以来、地方分権化に向けた最大の一歩となるでしょう。 ライブロードマップの進捗状況を最新に保つことができます。
*これはライブのドキュメントであり、すべてのタイムラインは変更される可能性があることに注意してください。 これらのタイムラインは、進捗状況を見積もるための最善の努力を反映していますが、最終的にはタイムラインを正確に予測することは不可能です。*
その後どうなりますか？
この後、次のステップはRenVMをアップグレードして、実行もGreycoreによって実行されるようにします。これは、最初にTestnetで起動し、次にMainnetで起動するという同様のプロセスを経ますが、一度に1つのGreycoreメンバーにアップグレードをロールする必要はありません。また、プロセス/ツールの大部分が開発されます。つまり、アップグレードは最初のアップグレードよりもはるかに速く行われる可能性があります。この時点で、RenVMはフェーズ0にあると宣言されます。これは、分散化への道の大きなマイルストーンです。
以前と同様に、ライブロードマップの進捗状況を最新に保つことができますが、すべてのタイムラインは変更される可能性があることに注意してください。私たちは常に、より高速でバグの多い開発方法よりも、低速であるがより正確でエラーが発生しにくい開発方法を優先します。
そうは言っても、私たちはこの進歩を前進させることに興奮しており、この作品がコミュニティにとって有用な再確認として役立つことを願っています。いつものように、ご不明な点がございましたら、Telegramにご参加ください。
それでは、
Loong、CTO