数日前、私はふとしたことで単純な疑問を自分に投げかけていました。

なぜ、ハードウェアがワークロードを処理するのに十分に見えるのに、いくつかのバリデータノードは遅くなるのでしょうか？

最初は、答えはネットワークの混雑かストレージのレイテンシだろうと決めつけていました。

深く調べるほど、その説明はますます驚くものになっていきました。

最新のバリデータ用ソフトウェアは、受け取った作業を複数のCPUコアに分散します。署名検証、トランザクションの実行、認可チェック、ネットワークイベント、データベース操作などはすべて並列に実行されます。紙の上では、これは性能をスケールさせるための理想的なアーキテクチャに見えます。

しかし、並列計算はそれ自体の見えにくいコストを生みます。

複数のワーカスレッドが同じ共有ポリシーデータに繰り返しアクセスして更新すると、プロセッサはCPUコア間でキャッシュ所有権を常に交換します。エンジニアはこの挙動を「キャッシュのピンポン」と呼びます。

有用な作業を実行する代わりに、プロセッサは貴重なサイクルを使って内部キャッシュ状態を同期し続けます。

技術的に壊れているわけではありません。

CPUは動き続けます。

ソフトウェアは動き続けます。

それでも、連携のオーバーヘッドが生産的な計算に置き換わり始めるため、全体のスループットはひそかに低下します。

この種のボトルネックは、ブロックチェーンのマーケティングではめったに姿を現しません。

ほとんどの議論は、トランザクション速度、スループット、またはブロック生成を中心に展開されます。

非常に少数の人しか、数千件のリクエストが同じハードウェア資源をめぐって競合し始めたときに、バリデータソフトウェアの内部で実際に何が起きるのかを探究していません。

その考え方は、私が @NewtonProtocol に興味を持つようになった理由の一つです。

プログラマブル認可は、実行の前に高度なポリシー評価を導入します。自動化がますます一般的になるにつれ、バリデータソフトウェアは単により高速なプロセッサを必要とするだけでは済まないでしょう。

より賢いスケジューリングが必要になります。

効率的なワークロード分配。

キャッシュ競合の低減。

並行実行経路間でのより良い連携。

こうした最適化は、追加のハードウェアを単に増やすよりも、最終的に長期的なスケーラビリティにより大きく貢献する可能性があります。

ブロックチェーンの性能は、単一の指標で決まったことはありません。

ネットワーク帯域は重要です。

ストレージは重要です。

暗号技術は重要です。

しかし、ソフトウェアアーキテクチャは、それらの資源が実際にどれだけ有効に使われるかを左右することが多いのです。

次の世代のインフラは、最速のマシンによって定義されることはないのかもしれません。

より複雑化するワークロードを扱う際に計算を最も無駄にしないシステムによって定義されるかもしれません。

@NewtonProtocol $NEWT $US $TAC #Newt #SKHynixADRBiggestForeignCorporateFundraising #USNaturalGasFallsOver6% #CorningJumpsOver8% #SpaceXAddedToValueIndexes