Sui テストネット Wave 2 の価値のあるネットワーク更新は何ですか?

Foresight News

特邀专栏作者

2023-02-28 09:45

この記事は約2472文字で、全文を読むには約4分かかります

テストネットワークの Wave 2 の複数データのパフォーマンスは Wave 1 のパフォーマンスをはるかに上回り、大規模なトランザクション、型パラメーターの入力、コンセンサス遅延が改善され

AI要約

展開

オリジナル編集: Babywhale、Foresight News

Sui テストネット Wave 2 は無事終了し、このテストは、Sui にステーキングするという目標を達成するのに役立ちました。ネットワーク上のアクティビティの量を確認すると、メインネットの立ち上げに向けての重要な一歩を踏み出したという確信がさらに高まりました。参加してくださった皆様、Sui をさらに良くするためにご協力いただいた皆様、本当にありがとうございました!

Wave 2 から多くのことを学びました。今後、Wave 2 のすべてをレビューする 3 部構成のブログシリーズを投稿する予定です。最初のブログではネットワークの側面について説明し、今後の記事ではトークン経済学とフレネミーゲームについてさらに詳しく説明します。

統計スナップショット

ウェーブ 2 では、コミュニティは 3 週間、つまり 33 エポックのテストで集合的に複数の新記録を樹立しました。

7000 を超えるノードが 41 のバリデータに接続
169万アドレス
3,650 万トランザクション (ウェーブ 1 から 1.6 倍)
324万NFT
発行された契約数は 118,614 件 (ウェーブ 1 から 45 倍)
134万SUIを誓約
735 万件のステーキング操作が処理されました
67 個の TPS スパイクが観察されました
ウェーブ 2 では、Sui Wallet の DAU は 2.2 倍の 171,000 に増加し、Sui Wallet のインストール数は 1 月の最初の 3 週間と比較して 3 倍以上の 333,000 に増加しました。
スイブロックエクスプローラーは 100 万ページビューと 571,000 のユニーク訪問者で過去最高を記録
Sui Discordこのコミュニティには 600,000 人を超えるメンバーがおり、世界最大の Web3 コミュニティの 1 つとなっています。

特に、ウェーブ 2 中に 100 万件を超えるトランザクションを処理したスマートコントラクトが 4 つあり、合計するとウェーブ 2 のトランザクション量全体の 40% を占めました。

スイのシステムオブジェクトがリストのトップとなり、730万件を超えるステーキング関連のトランザクションを処理しました。
Frenemies game2 位は、わずか 5 日間のプレイで 350 万件以上のトランザクションが完了しました。
3 番目にアクティブなスマートコントラクトは、8192 game、コントラクトは 0x 137 aebf 47 cd 16956 b 68633 b 6 f 6 f 00 a 99 2d 87 d 9 c 6 で、200 万件を超えるトランザクションを処理します。
4 番目にアクティブなスマートコントラクトは、Sui Capys、コントラクトは 0x 4 c 10 b 61966 a 34 d 3 bb 5 c 8 a 8 f 063 e 6 b 7445 fc 41 f 93 で、160 万件のトランザクションを処理します。

100 万トランザクションマークを突破したコミュニティプロジェクト 8192 ゲームに、特におめでとうございます!また、Wave 2 データ分析を提供するコミュニティプロジェクトにも感謝します。Suiscan。

これらの新しい記録とネットワークアクティビティのレベルにより、重要なソフトウェアアップデートを特定し、バリデーターおよびノードオペレーターコミュニティとさらに協力して運用能力を向上させることができます。

注目すべきウェブ更新

ウェーブ 1 と同様に、ウェーブ 2 の目的は、Sui のインフラストラクチャの改善領域を特定することです。

大きなメッセージまたはトランザクションを処理する

Wave 2 はステーキングに焦点を当てていたため、ネットワークでは多くのステーキングとステーキング解除のトランザクションが発生し、それが大規模なネットワークメッセージとトランザクションを処理する能力を向上させるのに役立ちました。特に、保留中の各ステーキング委任および委任解除トランザクションは、エポック変更中にイベントを生成します。生成された各イベントはトランザクションの影響の一部であるため、これはエポック変更トランザクションのトランザクションサイズに影響します。ウェーブ 2 では、1 エポックで最大 230,000 件のステーキング操作が発生したため、そのエポック変更によるトランザクション効果は非常に大きくなりました。

こうした大規模なトランザクションは多くの問題を引き起こします。エポック変更トランザクションの効果が大きすぎてネットワーク経由でダウンロードできない場合、エポック変更は失敗します。トランザクションの影響が最大 JSON RPC 応答よりも大きい場合、トランザクションを取得できません。このような大規模なトランザクションをロードしようとするアプリケーション (エクスプローラーなど) はクラッシュする危険性があります。このような大規模なトランザクションは、ネットワークで処理するには計算コストが高すぎる可能性もあります。 Wave 2 の間、私たちのチームは大量のトランザクションを処理しながらネットワークを稼働し続けるために、緊急制限をいくつか引き上げる必要がありました。

上記に対応して、オブジェクト、パッケージ、およびさまざまなトランザクションデータ (入力パラメーター、トランザクション効果、イベント) に対する保護サイズ制限の追加を加速しました。これらの制限は、メインネット上の非常に大規模な交換によってストレージ、ネットワーク、およびコンピューティングリソースが圧倒されないようにするのに役立ちます。

トランザクションタイプパラメータ入力のより堅牢な処理

2 月 1 日、Move モジュールが type パラメーターのトランザクション入力として指定された場合、トランザクション処理ロジックが Move モジュールの依存関係 (つまり、その型が属するモジュールが公開されているかどうか) を適切に検証できないというバグを発見しました。 Move パッケージの公開は Byzantine コンセンサスブロードキャストファストパスを介して行われるため、一部のバリデータは公開された Move モジュールについて他のバリデータより先に学習し、このモジュールを type パラメータで使用するトランザクションの有効性について意見が一致しない可能性があります。このようなトランザクションの 1 つにより、システムが次のチェックポイントを形成できなくなり、多くのフルノードが停止し、結果としてバリデーターがネットワークをフォークする原因となりました。これが、2 月 1 日の早朝に発生したウェーブ 2 の停止の主な理由でした。

type パラメータに無効な入力モジュールを含むトランザクションが送信された状態でもテストネットの実行を継続するために、私たちのチームはいくつかの緊急修正を実装しました。

型パラメーターのモジュールが公開されていることを常に確認してください。
送信された無効なトランザクションが失敗しても実行を完了できるようにします。
未公開の型パラメータを使用したさらなるトランザクションの送信を防止します。

次に、トランザクション入力チェックロジックが、型パラメーターへの入力として Move モジュールではないコントラクトの挿入を拒否しないという 2 番目のバグを発見しました。 type パラメータは Move モジュールである必要があるため、トランザクションを完了することはできず、次のチェックポイントを形成することもできません。同様に、私たちのチームは、ネットワークを復元するために、実行エラーにより問題のあるトランザクションを強制的に失敗させる緊急修正を追加する必要がありました。

Sui のコードベースに次の 2 つのバグの修正を追加しました。入力オブジェクトの生成を修正 #7940。

イッカクのコンセンサスメカニズム遅延改善

Wave 1 と同様に、Testnet Wave 2 は、41 の分散型バリデーターを使用して Narwhal コンセンサスをさらにテストする貴重な機会を提供します。 Wave 2 では、いくつかのコンセンサスレイテンシー削減の最適化を行う機会を利用しました (2 つのバリデーターに並行してコンセンサスをコミットする、並行証明書検証、min_header_delay パラメータ、1 秒の min_header_delay)。私たちは常に機能を改良しており、すぐにさらに多くの機能が追加される予定です最適化プラン。

開発者が学んだ注目すべき教訓

ネットワークの安定性を確保することが最優先事項ですが、私たちの長期的な目標は、Sui を、開発者が Sui に基づいて Web3.x の最高のエクスペリエンスを作成できる最高のスマートコントラクト開発者プラットフォームにすることです。この目的のために、私たちはウェーブ 2 中の開発者とユーザーの摩擦点にも焦点を当てました。

トークン管理

Wave 2 では、いくつかの要因により、ユーザーはトークン管理で問題に遭遇する可能性がありました。これらの問題は通常、不十分なガス料金エラー、またはユーザーが取引に十分な SUI 残高を保持しているように見えるときに表示される灰色のステークボタンとして現れます。

なぜならValidator Gameネットワーク上でアクティブであるため、基準ガス価格は変動し、各エポック間で通常よりも大きく上昇する可能性があります。ガス価格の変動が激しいと、ユーザーが保有する 1 つのトークンの価値がガス料金を支払うのに十分ではなくなる可能性があります。第二に、ユーザーが複数のトークンを保持する可能性が低くなり、トークンが早くなくなる可能性があるため、初期の参照ガス価格は Devnet の価格よりも高く設定されています。最後に、ステーキング操作には基本的に、ユーザーが既存の SUI 残高を 1 人以上のバリデーターに委任することが含まれます。ただし、ユーザーが保有するSUIのレイアウトは、意図したステーキング操作と必ずしも一致するとは限りません。

これを軽減するために、Wave 2 中にいくつかの変更を加えました。

私たち
私たち解決しましたSui クライアントが、gas_budget * Gas_price ではなく、gas_budget より大きい Gas オブジェクトを選択する SDK のバグ。
Sui ウォレットステーキング用の基本的なトークン管理を追加しました。このうち、各プレッジ操作では、paySui トランザクションを使用して、それぞれプレッジとガス支払いのモジュールを構築します。
近々サポートする予定ですプログラム可能なトランザクションこれにより、アプリケーションのトークン管理が簡素化されます。