私は理由がリーダーボードのメトリクスとは何の関係もなく、チェーンが開発者にアーキテクチャの成熟を静かに強いる方法に関してであることをフォローします。SVMベースのLayer-1に基づいて構築することは、単に速度を選択するだけではありません — それはクリーンな状態設計を報酬し、弱い設計を即座に露呈させるシステムを選ぶことです。
Fogoはシンプルな信念の周りに構築されたと感じます: 速度は見た目だけであるべきではありません。ブロックが本当に速く、ランタイムが独立した作業を同時に処理できるなら、実際のボトルネックはアプリケーション自体になります。だからこそ、SVMモデルは興味深くなります。なぜなら、実際のユーザーが到着すると、すぐにすべての開発者に同じ質問を投げかけるからです — あなたのトランザクションは実際に独立していますか、それとも偶然にみんなが触れなければならない共有ロックを構築しましたか？
並列実行は理論上はシンプルなように聞こえる。トランザクションは一緒に実行される。しかし、実際には、トランザクションが同じ状態を争わないときにしか機能しない。SVMチェーンでは、状態はチェーンがあなたのために管理する目に見えない塊ではない。それは明示的だ。すべてのトランザクションは、何を読み取り、何を書き込むかを宣言する。それにより、ランタイムはオーバーラップしないときにタスクを自信を持ってスケジュールできる — そしてそれはまた、設計がどこでもオーバーラップを強いるときにチェーンがあなたを救えないことを意味する。
ここがほとんどの表面的なコメントが本質を見失うところだ。人々はパフォーマンスがチェーンレイヤーだけに存在するかのように話すが、Fogoではパフォーマンスはアカウントとデータの構造を設計することで実現できる。それが、同じチェーン上の2つのアプリケーションがストレス下で全く異なる動作をする理由だ。片方はスムーズに動き、もう片方は停滞することがある。どちらも同じ速い環境で動いているにもかかわらずだ。
逐次システムから来る開発者は、SVM上では安全に感じるが高価になる習慣を持ち込むことが多い。それは中央のグローバル状態オブジェクトだ。それは推論を容易にし、分析を単純化する。クリーンな単一の真実のソースのように感じる。しかし、SVMチェーン上では、その設計は静かなスロットルとなる。すべてのユーザーアクションが同じ場所に書き込まれる。ランタイムが並列作業の準備ができていても、アプリが単一のレーンを作ってしまったのだ。
Fogoでは、状態のレイアウトは単なるストレージではなく、同時実行ポリシーになる。すべての書き込み可能なアカウントはロックのように機能する。1つのロックの後ろにあまりにも多くを置くと、コンポーネントを遅くするだけでなく、全体のフローにわたって並列性が崩壊する。そして、チェーンが混雑する必要はない。自分のコントラクトの設計が混雑を生み出すのだ。
実践的なマインドセットのシフトはシンプルだが強力だ。すべての書き込み可能な状態オブジェクトは、同時に前進を許可される人についての決定だ。目標は不必要な衝突を減らすことになる。それは共有状態を完全に排除することを意味しない — 一部の共有状態は不可欠だ。しかし、それは本当に共有する必要があるものと、便利さのためだけに共有されたものを問い直すことを意味する。便利さは並列実行が静かに死ぬ場所だ。
Fogoでは、速さを保つ設計は複雑ではなく、規律がある。強力なアプリケーションはユーザー状態を積極的に分離する。彼らは市場特有のデータを隔離し、すべてをグローバルプロトコルオブジェクトを通じてルーティングする代わりに、共有トラッキングアカウントへの書き込みを強制することをやめる。なぜなら、メトリクスと分析は重要な書き込みパスに座らなくても導出できるからだ。
成功した並列に優しいシステムは、ユーザーアクションを主にローカルに保つ傾向がある。ユーザーは自分の状態に触れ、真に必要な狭いスライスの共有状態だけを触れる。その共有スライスは、無関係なユーザーが衝突しないように構造化されている。ユーザーごとの分離は単なる組織ではなく、スループット戦略だ。市場ごとの分離は単なるクリーンアーキテクチャではなく、1つのホットマーケットが全体のシステムを遅くするか、独立して流れるかを決定する。
隠れた罠はグローバルな真実だ。開発者はグローバルな手数料合計、ボリュームカウンター、活動トラッカー、またはリーダーボードを即座に更新したいと思っている。その問題はそれらのメトリクス自体ではなく、すべてのユーザートランザクションの内部でそれらを更新することだ。すべてのトランザクションが同じ報告アカウントに書き込む瞬間、すべてが対立する。並列ランタイムの中にシーケンシャルアプリケーションを構築してしまったのだ。Fogoがどれだけ速くても関係ない — 自分の設計が直列化を強いている。
並列実行はビルダーに正確性の状態を報告状態から分けることを促す。報告は異なるインターバルで更新でき、シャードセグメントに存在できるか、イベントログから導出できる。すべてのトランザクションが同じ報告オブジェクトを変化させることを強制するのをやめると、ランタイムはついに真の並列作業をスケジュールできるようになる。それがアプリケーションがSVMチェーンにネイティブであると感じるようになる瞬間だ。
これはトレーディングシステムで明らかになる。そこで活動が集中し、争いが爆発する。すべてのインタラクションが1つの中央オーダーブック状態を変化させると、チェーンはアクティビティを直列化する。たとえブロックがどれだけ速くても、それは変わらない。だからこそ、より良い設計は状態を分割し、決済パスを狭くし、重要なパスから不必要な書き込みを削除する。違いは需要がピークに達した瞬間、つまりユーザーが最も気にする瞬間に現れる。
インタラクティブなリアルタイムシステムは同じ現実に直面している。単一の常に変化する世界状態は衝突を保証する。より良い設計は参加者ごとに状態を隔離し、共有エリアを局所化し、グローバル集計を制御された更新として扱う。みんなが同じオブジェクトに触れることを強制するのをやめる瞬間、同時実行が現実のものとなり、速度が実感としてついてくる。
高頻度のロジックは設計上の欠陥をさらに早く露呈させる。多くのアクターが素早くアクションを送信すると、共有可能な状態は戦場と化す。独立したフローが進行する代わりに、みんな同じロックを求めて競争する。それはシステムを遅くするだけでなく、市場の動作自体を変えてしまう。なぜなら、オーダリングが戦いによって駆動されるようになるからだ。優れた設計は書き込みを隔離し、争われるコンポーネントを狭く意図的に保つ。
データ重視のアプリケーションも静かにこの罠に陥る。ほとんどのユーザーは共有データを読むだけで済むので、読み取りは問題ではない。しかし、フローが共有キャッシュや便利のためのグローバルマーカーを書き始めると、並列性が毒される。よりスマートなパターンは、消費者が共有データを読み取り、自分自身の決定だけを書き込むようにし、共有書き込みを制御された更新パスに限定することだ。
Fogoが開発者に求める本当の要求は、並列に優しいアーキテクチャが無料ではないということだ。状態をシャードしアカウントを分けると、より多くのコンポーネントを管理することになる。テストはより厳しくなる。アップグレードにはより注意が必要だ。可観測性を向上させる必要がある。しかし、その報酬は真のスケーラビリティであり、独立したアクションが本当に一緒に実行され、グローバルボトルネックの後ろに並ぶことはない。
ほとんどの並列の利点を破壊する誤りは、先進的ではなくシンプルだ。すべてのトランザクションによって触れられる1つの共有書き込み可能なアカウント。Fogoのような速いチェーンでは、その誤りは痛々しく目に見える。ランタイムが速くなるほど、自分の設計が制限要因であることが明らかになる。それはチェーンの失敗ではなく、アーキテクチャについての真実を明らかにすることなのだ。
Fogoが面白いのは、ビルダーの会話をより正直にするからだ。チェーンが速いと言うだけでは不十分だ。モデルは開発者にその速度に値することを証明させることを強要する。そしてその証明は、状態がどのように構造化され、分割され、アクセスされるかに存在する。
並列実行はマーケティング機能ではない。それは規律だ。そして、FogoのようなSVMベースのレイヤー1は、単に速いだけでなく、より要求が厳しい。なぜなら、それはビルダーに状態を同時実行の表面として扱い、パフォーマンスをアーキテクチャに設計されたものとし、ランタイムから与えられたものではないように強制するからだ。