#dusk @Dusk @Dusk $DUSK
チェーンの過去データにアプリがアクセスする必要がある場合、単に「バリデータを実行する」だけでは、背後にあるインフラの役割を正しく反映していないことがあります。私はこれまでDuskのノード運用をかなり基本的なやり方で見てきましたが、調べれば調べるほど、その分類にはまだ多くの不足があると感じました。

Hmm.. これは、バリデータ以外の別の役割に注目させられます。Ruskでは、finalizedされたデータは、Moonlightの活動や過去のイベントを含め、アプリが後から参照できるように保持できます。重要なのは、このアーカイブ部分を運用する人はバリデータになる必要がないことです。つまり、コンセンサスに参加する必要もなく、ステーク（stake）を行う必要もありません。

これにより、システム内での責務の分担を見直す必要があると気づきました。APIのproduction環境では、Duskは汎用的なクエリ処理部分をprovisionerと一緒に置かないことを推奨しています。これにより、リクエスト処理や過去データの保存は、コンセンサスを担うノードとは独立して実行できます。

過去のデータ、イベント、そしてトランザクションは、アプリが必要なときに確実に参照できるだけの十分な安定性をもって保存されなければなりません。作業範囲は小さくなりますが、軽いという意味ではありません。つまり、オペレーターはvalidatorの役割に参加せずとも、アプリケーション層向けのインフラを提供できます。

私はDuskで「ノードを動かす」ということが、単に異なる種類のデプロイを選ぶだけではないと理解しました。アーカイブ・オペレーターは、アプリケーション向けに過去データを保存し提供する役割を担い、provisionerはコンセンサス部分を担当します。
$AOP $UAI
#USCanadaTradeTalksCollapseCanadaVowsRetaliation #SP500EndsWeeklyWinStreak #NvidiaAIServerPricesRiseOver15% #AnthropicIPOCouldTopSpaceXRecordReportsSay