なぜダスクは1つのノードで全部をやらせないのか
2週間前、VPSでお金を節約しようとしていました。メインアプリ、データベースのバックアップ、そして重い画像処理ジョブを、同じ小さなサーバーにまとめて載せたんです。効率的に見えました。ですが違いました。画像ジョブが始まると、突然メインアプリからリクエストが消えるようになったんです。
このくだらないVPSの問題は、ダスクのノード構成を読むときにまた思い出されます。ダスクは、Provisioner、Archive、Proverという役割に仕事を分けています。これらは「全部を1台でやる」ための、ただ格好いい名前をつけただけのものではありません。
Provisionerは合意に集中し、少なくとも1,000 DUSKをステークする必要があります。Archive Nodeは、"moonlightHistory" や "finalizedEvents" のようなものの最終化済み履歴を保持します。Proverは、より重いゼロ知識（Zero-Knowledge）証明の作業を担当します。
そしてProverの話になると、またしてもハードウェアの問題の様相が変わります。ダスクは、証明生成はシングルスレッドだと言っています。だから強力なシングルコア性能が重要です。Archiveのインフラは出発点が異なり、4コア、8GB RAM、500GBストレージ、100Mbpsのネットワークです。
そしてここが、なんだか見覚えのある部分です。ダスクは、生産用のAPIインフラをProvisionerの職務とは分けておくことを勧めています。クエリのトラフィックやメンテナンスが、合意の作業と競合し得るからです。あのVPSで、私は同じことを面倒な形で学びました。
今では、3つの役割を少し違った見方で捉えています。合意、履歴クエリ、そしてZKの証明がすべて同じリソースを奪い合うなら、すべてを1台でやる方が本当に単純な選択肢なのでしょうか。
@Dusk #dusk $DUSK
2週間前、VPSでお金を節約しようとしていました。メインアプリ、データベースのバックアップ、そして重い画像処理ジョブを、同じ小さなサーバーにまとめて載せたんです。効率的に見えました。ですが違いました。画像ジョブが始まると、突然メインアプリからリクエストが消えるようになったんです。
このくだらないVPSの問題は、ダスクのノード構成を読むときにまた思い出されます。ダスクは、Provisioner、Archive、Proverという役割に仕事を分けています。これらは「全部を1台でやる」ための、ただ格好いい名前をつけただけのものではありません。
Provisionerは合意に集中し、少なくとも1,000 DUSKをステークする必要があります。Archive Nodeは、"moonlightHistory" や "finalizedEvents" のようなものの最終化済み履歴を保持します。Proverは、より重いゼロ知識（Zero-Knowledge）証明の作業を担当します。
そしてProverの話になると、またしてもハードウェアの問題の様相が変わります。ダスクは、証明生成はシングルスレッドだと言っています。だから強力なシングルコア性能が重要です。Archiveのインフラは出発点が異なり、4コア、8GB RAM、500GBストレージ、100Mbpsのネットワークです。
そしてここが、なんだか見覚えのある部分です。ダスクは、生産用のAPIインフラをProvisionerの職務とは分けておくことを勧めています。クエリのトラフィックやメンテナンスが、合意の作業と競合し得るからです。あのVPSで、私は同じことを面倒な形で学びました。
今では、3つの役割を少し違った見方で捉えています。合意、履歴クエリ、そしてZKの証明がすべて同じリソースを奪い合うなら、すべてを1台でやる方が本当に単純な選択肢なのでしょうか。
@Dusk #dusk $DUSK