最新のNeo Core会議では、開発者は実行手数料とホワイトリストの変更に関するテストを進め、CryptoLibネイティブコントラクトにおけるイーサリアム互換のBLSサポート計画を精緻化し、ブロックされた資金を処理するための新しいガバナンスメカニズムを評価しました。また、この会議では、ステーキングやスラッシングに基づく設計など、バリデータ候補が実際のノードを運用できるようにするための選択肢についても検討されました。
バリデータ候補が実際のノードを運用していることを保証する
開発者たちは、GAS報酬の平準化に向けた要件である、評議会候補者が機能ノードを運用していることをどのように証明するかについて議論を開始しました。現在検討されているアプローチは大きく分けて2つあります。1つは候補者向けの軽量なプルーフ・オブ・ワーク方式、もう1つは候補者がNEOをロックし、一定期間内にライブネスチェックに失敗した場合にペナルティを科すステーキング&スラッシングモデルです。
コンセンサスノードは既にビュー変更動作を通じて生存性を公開しているため、新しいメカニズムは候補検証を目的とします。設計の詳細については、対応する問題で詳細化される予定です。
Neo v3.9.0 に向けた進捗
開発者は、v3.9.0ブランチがほぼ完成していることに同意しました。Flamingoから移植された任意のメッセージ署名サポートを含めるという提案が議論されました。この機能は追加のプルリクエストと署名メッセージのセマンティクスに関する明確な仕様に依存しているため、ドキュメントが期限までに完成しない場合は、後のリリースにスケジュールされる可能性があります。
NEP-25 はバージョン3.9.0では出荷されません。標準規格の計画的な変更により開発が1〜2か月遅れることが予想されるため、貢献者はリリースの遅延を回避するために延期することに合意しました。
マージされた変更のテスト: 実行手数料とホワイトリスト
実行手数料係数の変更とホワイトリストベースの無料トランザクションのサポートは、v3.9.0に既に統合されています。最終バイナリが公開される前に、専用の課題でこれらの機能のテストチェックリストを定義する予定です。
特にプロトコルレベルの動作に関わるプルリクエストについては、複数のコントリビューターによるより広範なレビューが推奨されました。これは、アップデートの適用後、エクスプローラー、ウォレット、および代替ノード実装間で動作が異なるリスクを軽減することを目的としています。
CryptoLib における Ethereum 互換の BLS サポートの再考
開発者は、CryptoLib ネイティブコントラクトに BLS12-381 の Ethereum 互換エイリアスを追加する提案も検討しました。
2つの主な懸念事項が特定されました。新しいメソッドはバイト配列を操作しますが、既存のCryptoLib機能は専用のシリアル化ヘルパーを備えた相互運用インターフェースを通じてBLSポイントを公開します。各操作でシリアル化とデシリアル化を繰り返すのは非効率的であり、現在のAPI設計と矛盾しています。
望ましい方向性としては、Ethereum互換のBLSサポートを既存のインターフェーススタイルに整合させることです。そのためには、内部BLSポイント表現に対する操作を実行する際に、Ethereumフォーマットのシリアル化メソッドを追加します。Ethereumのシリアル化フォーマットとの互換性が主な要件であり、ミラーリングされたAPIサーフェスではありません。実装の詳細は、C#ノードとneo-goの両方で改良され、動作の一貫性が確保されます。
ブロックされた資金のガバナンスツール
同グループはまた、一定期間後にネオ評議会がブロックされた口座から資金を移動できるようにするガバナンスの変更についても検討しましたが、これには21人中19人の署名が必要でした。
このメカニズムは、悪意のあるウォレットや侵害されたウォレットで資金が凍結された場合を想定しています。秘密鍵を紛失し、所有権を証明できないユーザーの資産を回復するためのものではありません。
投票により、デフォルトのブロック期間が決定されます。ブロック期間は6か月、1年、2年などの選択肢があります。この機能が最終決定されれば、制裁対象アドレスの取り扱いに関するプロセスがより明確になると期待されます。
会議の全録画は以下からご覧いただけます:
https://youtu.be/yhIhtkJHesw?si=bLxEPyBO_aa3Zpr