C++、Rust、および分散型暗号交換: 適用性と効率

導入

システム自体が非常に誤解されやすいため、暗号通貨では言語に関する議論が特に誤解を招きやすくなります。人々は、分散型取引所が 1 つのレイテンシ プロファイル、1 つの信頼モデル、および 1 種類の障害を持つ 1 つの実行可能ファイルであるかのように「DEX を構築する」と言います。実際には、本格的な DEX は層状の有機体です。これには、オンチェーンロジック、バリデーターまたはノードのインタラクション、ブロック構築認識、メモリプール監視、市場データ収集、状態シミュレーション、価格設定、ルーティング、リスクチェック、オペレーターダッシュボード、そして場合によっては、ブロックチェーンボキャブラリーを身に着けた従来の取引所インフラストラクチャのように見えるオーダーブックまたはマッチング隣接サービスが含まれる場合があります。

この重層的な現実を認識すると、C++ と Rust の間の議論はより穏やかになり、より有益になります。正しい問題は、どの言語がアーキテクチャ全体の名誉として値するかということではありません。正しい質問は、どの層が Rust の安全性とエコシステムへの適合から恩恵を受けるのか、どの層が依然として C++ の低レベルのパフォーマンス制御に恩恵をもたらすのか、そしてどこのハイブリッド設計が妥協をやめてシンプルな良識を持ち始めるのかということです。

分散型取引システムはさまざまな圧力の下で運用されているため、その枠組みが重要です。一部のレイヤーは、正確性の失敗、監査可能性の問題、安全でない状態の遷移に対して最も厳しく罰せられます。他のレイヤーは、レイテンシー、スループット、および機会を十分に迅速に評価できないため、罰せられます。さらに、実際のコストが長期的なメンテナンスとチームの速度にかかる運用サービスもあります。ある言語は、これらの負担の 1 つに優れている場合もあれば、別の言語には十分である場合もあります。成熟した建築は、それを率直に認めることから始まります。

DEX はスタックであり、アイデンティティ ステートメントではありません

最初の最も重要な修正は概念的なものです。 DEX は 1 つではありません。 EVM 指向の AMM プロトコル、Solana ネイティブ プログラム エコシステム、アプリチェーンの永久交換、市場状況に反応するサーチャー システムはすべて、さまざまなエンジニアリングの本能に値します。オンチェーン AMM ロジックは、1 セットの制約内に存在します。オフチェーン シミュレーターとルート エバリュエーターは別の内部に存在します。オーダーブックのようなコンポーネントや高頻度の検索インフラストラクチャは、システムの観点から見ると、通常の Web アプリケーション開発よりも従来の取引所ソフトウェアにはるかに近いかもしれません。

言語に関する議論がすぐに迷走してしまうのはこのためです。エンジニアは Solana を指し、Rust がそこでのプログラム開発の自然なパスであることを正しく観察しました。別の研究者は、レイテンシーに敏感なルーティングまたはシミュレーション エンジンを指摘し、C++ が依然として非常に強力な選択肢であることを正しく観察しています。どちらも文脈上は正しいです。問題は、各観察がスタック全体の全体的な理論に膨らむときに始まります。

精神的なリセットに役立つのは、サブシステムごとに、どのような種類の痛みが罰せられているかを尋ねることです。コンポーネントが間違っている場合、その痛みは主に公的な正当性の欠如でしょうか?民間の運営費なのでしょうか？チャンスが閉まる前に、急速に変化する状態に対応できないのでしょうか?それは監査の負担でしょうか、採用の負担でしょうか、それともインフラストラクチャの負担でしょうか?レイヤーが異なれば、これらの質問に対する答えも異なります。そのため、公開討論で純粋性が求められている場合でも、成熟した DEX システムでは言語が混在してしまうことがよくあります。

Rust が正しくリードする場所

Rust は、状態遷移、安全規律、およびエコシステムの適合がアーキテクチャを支配する場所で最も自然にその地位を獲得します。 Solana のような Rust ファーストのブロックチェーン環境では、これはわずかな利点ではありません。それは重心です。この言語は、プロトコル チームがエコシステムに逆らうのではなく、エコシステムの粒度内で移動するのに役立つフレームワーク、サンプル、セキュリティ習慣、ツールに囲まれています。オンチェーン プログラムの場合、抽象的な言語の比較よりも適合性が重要です。紙の上で最良の言語であっても、その周囲のすべての重大な運用パスが別のことを期待している場合、多くの場合、より悪い言語になります。

Rust は、長期的な正確性と保守性が主な敵となる場合、DEX を取り巻くグリーンフィールド サービスでも魅力的です。コントロールプレーンサービス、調整層、および特定のプロトコル対応ツールは、Rust が奨励する規律から真の恩恵を受ける可能性があります。コンパイラは、C++ で制御するプロセス、警戒心、およびレビュー文化を必要とするミスのカテゴリを検出します。それはロマンチックな主張ではありません。実用的なものです。強力な Rust 人材を擁するチームは、早期にいくつかのクラスのリスクを軽減し、時間の経過とともにサービス境界を穏やかに保つことができます。

有用な反例は、これを根拠にしています。チームは、チェーンネイティブの作業における Rust の強みから、周囲のすべてのオフチェーン サブシステムもデフォルトで Rust であるべきだと推測することがあります。しかし、それは周囲のシステムが同じ支配的な痛みを持っている場合にのみ続きます。厳しいタイミングのプレッシャーの下で市場の状態を繰り返し評価するホットパス シミュレータまたは検索エンジンは、暗号商品内のパフォーマンス重視のネイティブ システムのままです。チェーンは Rust の形状になっている可能性がありますが、周囲の実行パスはほぼ C++ の形状のままです。

C++ が依然としてその地位を維持している場所

C++ は、DEX がアプリケーション プラットフォームではなく、交換インフラストラクチャのように動作し始めると、置き換えが困難になります。市場データの取り込み、メモリプールのリスニング、正規化パイプライン、ルート評価、状態シミュレーション、裁定取引検索、清算エンジン、およびオーダーブック隣接サービスはすべて、共通の特性を共有しています。つまり、これらのサービスはプレッシャーの下で低レベルの作業を繰り返し実行し、その作業は多くの場合、メモリ レイアウト、割り当て戦略、パーサーの効率、キューの動作、または CPU の予測可能性に近いものです。

これは、C++ のシステムと取引における長い歴史が引き続き重要な点です。この言語を使用すると、エンジニアは、データ構造、スレッド モデル、オブジェクトの有効期間、カスタム アロケータ、ベクトルに適したレイアウト、およびまさにこの種の環境で実戦テストされたパフォーマンス ツールを直接制御できます。また、高性能ネットワーク システム、シミュレータ、パーサー、ネイティブ ゲートウェイ、およびハードウェアを意識したコードのサンプルの古くて密度の高いエコシステムの恩恵も受けています。 AI アシスタントにもこれらの問題への支援が求められている時代においては、その密度が利点をさらに高めます。

市場のシグナルを聞き、経路をシミュレートし、機会を追う価値があるかどうかを判断する検索者を考えてみましょう。興味深いコストが、単独の 1 つの式であることはほとんどありません。興味深いコストは、取り込み、デコード、ルーティング、意思決定ロジックに囲まれた多くの式をステートフルに繰り返し使用することです。いくつかの回避可能なコピー、不適切に配置された 1 つのロック、または規律のないキューによって、パス全体の経済性が変化する可能性があります。 C++ は、エンジニアがマシンに正確な質問をするための非常に使い慣れた言語を提供します。時間的プレッシャーの下で繰り返し生きては死ぬシステムでは、それは依然として重要です。

経済学が言語の答えを変える

こうした議論が過熱する理由の 1 つは、エンジニアが勝利の条件がエレガントであるかのように話すことです。 DEX システムでは、通常、勝利条件は経済的です。チャンスを逃すとコストが発生するため、レイテンシが重要になります。大規模なシミュレーションの繰り返しにはコストがかかるため、効率が重要です。不適切な状態遷移にはコストがかかるため、安全性が重要です。オペレーターを常に怖がらせるシステムにはコストがかかるため、運用のシンプルさが重要です。いったん議論がそのような言葉で述べられると、言語の選択は象徴的なものではなくなり、経済的なものになります。

Rust は、将来の最大のコストがハードステートフル ロジックの正確性の失敗、または十分な構造的規律のない複雑なサービスの維持によって発生する場合に、多くの場合、それ自体で元をとります。 C++ は、ホットパスの非効率性、反復計算における過度の抽象化、または高パフォーマンスのネイティブ インフラストラクチャとの統合の難しさによって将来最大のコストが発生する場合に、多くの場合、元が取れます。賢明なチームは、サブシステムの寿命全体にわたってどのコストが支配的になるかを検討し、それに応じて選択します。

この視点は、よくある混乱の 1 つ、つまり決済速度と実行パス速度は同じものではないという問題にも役立ちます。ブロックチェーンはプロトコル レベルで 1 つのタイミング特性を備えている可能性がありますが、ブロックチェーンを囲むオフチェーン システムはまったく異なるレイテンシーの世界に存在します。オンチェーン決済が遅いからといって、迅速なオフチェーン評価が無関係になるわけではありません。実際、機会が争われている場合、誰が反応するか、誰が正確に価格を設定するか、誰が最初に有益なアクションを提出するかが決まるため、オフチェーンのスピードの価値はさらに高まる可能性があります。これら 2 つのタイミング領域を速度と呼ばれる 1 つの概念に平坦化するエンジニアは、通常、労力の置き場所を間違えることになります。

大人の答えはハイブリッド アーキテクチャであることが多い

ハイブリッド設計が尊重されるようになると、最も本格的な DEX アーキテクチャの多くは、容易に理解できるようになります。オンチェーン ロジックは、チェーンが期待する言語およびフレームワーク環境内で動作できます。コントロール プレーンと製品サービスは、メンテナンスを健全に保つ言語を選択できます。ホットパス シミュレーション、ルーティング、市場データ処理、または隣接コンポーネントのマッチングは、従来のパフォーマンスに近い状態を保つことができるため、調整や検証が容易になります。その結果はイデオロギー上の妥協ではありません。各部分が実際の負担に合わせて最適化できるシステムです。

これには成熟度が必要です。ハイブリッド システムは、境界が明確な場合にのみ健全です。チームには、明確なインターフェース、狭い責任分担、複雑さがどこに属するのかについての誠実さが必要です。しかし、それは言語に関係なく当てはまります。境界が混乱している 1 言語のアーキテクチャは、境界が明確な 2 言語のアーキテクチャよりも単純ではありません。場合によっては、同じ混乱を単一言語で表現しただけの場合もあります。

ここには人員配置の側面もあります。チームは、複数のネイティブ ドメインにわたって採用するのは難しいと感じるため、1 つの言語を選択しなければならないと想像することがよくあります。その懸念は理解できますが、それはアーキテクチャ上の怠惰の言い訳になる可能性があります。もっと良い質問は、最もパフォーマンスに敏感な層が本当に独自の言語を必要としているのか、それともプロファイラーがそのコストをまだ正当化していないのかということです。一部のチームは絶対にほとんど Rust に留まり、ホット パスが得られた場合にのみ C++ を導入する必要があります。すでに C++ の深い専門知識を持っている人もいますが、自分たちの最も強力なシステム本能と一致しない Rust 型のワークフローにすべてを強制することで、自分自身に害を及ぼそうとします。ここでもまた、名声よりもコンテキストが重要です。

AI によるエンジニアリング変更の内容

AI コーディング システムの登場は、文脈に応じた言語選択の根拠を弱めるのではなく、むしろ強化しています。 Rust ファーストのブロックチェーン エコシステムでは、エージェントはフレームワークを認識したスキャフォールディング、日常的なサービス コード、および一部のカテゴリのリファクタリングを以前よりも快適に支援できます。しかし、低レベルでパフォーマンス重視のネイティブ サブシステムでは、単純な理由からバランスは依然として C++ に傾いています。パブリック コード、パブリック ツール、パブリック統合サンプルがはるかに密集しているからです。現在、エージェントには、DEX システムが頻繁に必要とする種類のホットパス インフラストラクチャに役立つドラフトを作成するためのより多くの履歴資料があります。

これは、AI が C++ を普遍的に優れているという意味ではありません。これは、古いエコシステムの重力が新しいツールによって増幅されることを意味します。アシスタントが CMake 統合のデバッグを支援したり、キューの再設計を提案したり、パーサーを改善したり、シミュレーション ループのベンチマークの草案を作成したりする場合、パブリック C++ の世界のディープ ネイティブ メモリの恩恵を受けることができます。アシスタントが Rust ファーストのオンチェーン環境内で作業する場合、その逆が当てはまる可能性があります。言語の決定は依然としてワークロードに属しますが、AI の時代では、環境密度が以前よりもさらに重要になっています。

私の実践的な推奨事項

Rust ファーストのエコシステムでチェーンネイティブ プログラムを構築している場合は、言語レトリックのために地形と戦わないでください。 Rust がすでに正しさ、ツール、コミュニティの実践の自然な本拠地となっている場所をリードしましょう。パフォーマンス重視の交換エンジニアリングのように動作するオフチェーン インフラストラクチャを構築している場合は、C++ を暗号ドメインのテーブルに置いておきます。 C++ には、高速な取り込み、反復的なシミュレーション、厳密なルーティング ロジック、および低レベルのシステム制御など、依然として非常に優れた機能を備えた作業を実行させます。

そして、あなたのアーキテクチャが本当に両方の世界にまたがるのであれば、恥ずかしがらずにその事実を受け入れてください。すべてのコンポーネントが同じ種類の障害に苦しんでいるふりをしても、優れたエンジニアリングがより純粋になるわけではありません。これは、各コンポーネントに実際のジョブの物理学を尊重する言語を割り当てることによって強化されます。

このように問題に取り組むと、静かな楽観主義が生まれます。これはエンジニアに、建築は公共の場での議論よりも穏やかなものになり得ることを思い出させます。議論に永遠に勝つために、1 つの言語を選択する必要はありません。システムの次の正直な層に適したツールを選択するだけで済みます。それははるかに有益な種類のインテリジェンスです。

ハンズオン ラボ: 小さな AMM ルート エバリュエーターを構築する

理解できるほど小さく、触れられるほど本物のものを構築しましょう。

目標は Uniswap を再作成することではありません。目的は、シミュレーションと比較を繰り返すことで、DEX の作業がいかに早くなるかを実感することです。

main.cpp

#include <cmath>
#include <iomanip>
#include <iostream>
#include <string>
#include <vector>

struct Pool {
    std::string name;
    double reserve_in;
    double reserve_out;
    double fee; // 0.003 for 0.3%
};

double swap_out(const Pool& p, double amount_in) {
    const double effective_in = amount_in * (1.0 - p.fee);
    return (effective_in * p.reserve_out) / (p.reserve_in + effective_in);
}

double two_hop(const Pool& a, const Pool& b, double amount_in) {
    const double mid = swap_out(a, amount_in);
    return swap_out(b, mid);
}

int main() {
    Pool eth_usdc_a{"ETH/USDC pool A", 500.0, 1750000.0, 0.003};
    Pool eth_usdc_b{"ETH/USDC pool B", 650.0, 2262000.0, 0.0005};
    Pool usdc_dai{"USDC/DAI stable pool", 900000.0, 901200.0, 0.0001};

    const double trade_eth = 4.0;

    const double direct_a = swap_out(eth_usdc_a, trade_eth);
    const double direct_b = swap_out(eth_usdc_b, trade_eth);
    const double routed = two_hop(eth_usdc_b, usdc_dai, trade_eth);

    std::cout << std::fixed << std::setprecision(4);
    std::cout << "Input: " << trade_eth << " ETH\n";
    std::cout << "Direct via " << eth_usdc_a.name << ": " << direct_a << " USDC\n";
    std::cout << "Direct via " << eth_usdc_b.name << ": " << direct_b << " USDC\n";
    std::cout << "Two-hop via " << eth_usdc_b.name << " -> " << usdc_dai.name
              << ": " << routed << " DAI\n";

    if (direct_b > direct_a) {
        std::cout << "Best direct route: " << eth_usdc_b.name << "\n";
    } else {
        std::cout << "Best direct route: " << eth_usdc_a.name << "\n";
    }
}

建てる

Linux または macOS の場合:

g++ -O2 -std=c++20 -o amm_router main.cpp
./amm_router

Windows の場合:

cl /O2 /std:c++20 main.cpp
.\main.exe

なぜこれが重要なのか

この小さなプログラムでも、オフチェーン DEX 作業の実際の形をすでに示唆しています。

• 反復パス評価
• 手数料を意識した比較
• 状態依存の出力
• 正確さとスピードの間の一定の緊張感

これを数百のプール、頻繁な状態更新、敵対的なタイミングプレッシャーまで拡張すると、言語の選択がすぐに抽象的でなくなる理由がわかり始めます。

愛好家向けのテストタスク

1. スリッページ許容値を追加し、有効出力が設定されたしきい値を下回るルートを拒否します。
2. プログラムを拡張して、2 つではなく 5 つまたは 10 つのプールを比較し、時間の経過をプロファイリングします。
3. リザーブをわずかに変更してルートを 100 万回再評価するループを追加し、「おもちゃの」ルーターが実際のホット パスにどのように似てくるかを測定します。
4. 浮動小数点の出力フォーマットを構造化された数値ログに置き換えて、実際のルート ロジックの周囲にどの程度の「非数学的」作業が発生するかを観察します。
5. Rust または別の言語で 2 番目のバージョンを追加し、生のランタイムと、シミュレーション ループが作業の中心になった後の言語の快適さを比較します。

これは、微妙な点を明らかにするため、良い練習になります。Exchange ソフトウェアでは、多くの通常の数式を一度に繰り返し、ステートフルで、待ち時間に敏感に使用するという興味深い問題点が存在します。

まとめ

C++ と Rust は両方とも分散型交換エンジニアリングに属していますが、異なる理由でそこに属しています。 Rust は、状態の安全性、監査可能性、チェーンネイティブのワークフローが中心となるエコシステムとレイヤーで信頼を獲得します。 C++ は、繰り返しのシミュレーション、市場データ処理、ルーティング、検索、およびメモリ、スケジューリング、パフォーマンス検証の厳密な制御に報いるその他のホットパス システムなど、作業が再び取引所インフラストラクチャのように見え始めるレイヤーで信頼を獲得します。

したがって、最も有益な質問は、どの言語がスタック全体を獲得するかということではありません。それは、実際にどの層を設計しているのか、そしてその層がどのような種類の障害を最小限に抑えられるのかということです。この質問を正直に尋ねると、通常、アーキテクチャはより明確になり、議論はイデオロギー的ではなくなります。適切に設計された DEX が言語の純粋性の記念碑となることはほとんどありません。これはコンポーネントの実用的な配置であり、それぞれのコンポーネントが担う負荷を最大限に考慮した言語で書かれています。

参考文献

1. Uniswap v3 ホワイトペーパー: https://uniswap.org/whitepaper-v3.pdf
2. Uniswap v3 コア リポジトリ: https://github.com/Uniswap/v3-core
3. Ethereum.org MEV ドキュメント: https://ethereum.org/developers/docs/mev/
4. Solana プログラムの概要: Solana
5. Solana Rust プログラム開発: Solana
6. アンカードキュメント: https://www.anchor-lang.com/docs
7. dYdX チェーンのドキュメント: https://docs.dydx.exchange/
8. dYdX 統合ドキュメント: https://docs.dydx.xyz/
9. オンチェーン決済を使用したオフチェーン注文帳の dYdX: https://integral.dydx.exchange/dydx-closes-10m-series-b-investment/
10. Cosmos SDK ドキュメント: SDK

    システムにすでに圧力がかかっている場合はどのように見えるか

Dex インフラストラクチャにおける言語の選択は、チームが静かな四半期を望んでいたまさにその瞬間に緊急になる傾向があります。機能がすでに顧客の前に提供されているか、プラットフォームがすでに内部依存性を持っており、システムはその洗練された理論と実行時の動作が丁寧に別々の生活を送っていることを明らかにするために、その特定の週を選択しました。これが、多くの本格的なエンジニアリング作業が和解から始まる理由です。チームは、システムが行うと信じていることと、負荷や変更が加えられた状態、そして誰もが少し創造的になり、賢さが少し低下するような期限の下でシステムが実際に行うことを調和させる必要があります。

暗号システム エンジニアリングで最も重要なケースは通常、サーチャーとシミュレーターのバックエンド、レイテンシーに敏感なルーティング サービス、オフチェーンのリスクと決済インフラストラクチャです。このような状況は、技術的、予算、信頼、ロードマップ、そして場合によっては評判にも影響を及ぼします。技術的な問題は、複数のチームがそれに依存した瞬間に政治的に大きくなり、なぜそれが未だに壁の中でアライグマのように行動するのか誰も完全に説明できません。夜はうるさく、場所を特定するのは難しく、無視すると費用がかかります。

そのため、動作圧力と配送の現実というレンズを通して問題を読むことをお勧めします。設計は理論的には美しくても、運用的には破滅的なものになる可能性があります。別の設計は、ほとんど退屈なものであっても、測定可能で修理可能であり、トレードオフについて誠実であるため、製品を何年も使い続けることができます。真剣なエンジニアは、2 番目のカテゴリーを好むようになります。これにより、壮大なスピーチが減りますが、誰もが受動態で話し、誰が近道を承認したかを誰も覚えていないような緊急の振り返りも減ります。

常に老化を続ける習慣

最初の永続的な方法は、1 つの代表的なパスを常に測定し続けることです。チームは多くの場合、曖昧なテレメトリを収集しすぎたり、意思決定品質のシグナルが少なすぎたりします。本当に重要な道を選び、それを繰り返し測定し、議論が装飾的なストーリーテリングに流れないようにしてください。 DEX インフラストラクチャでの言語選択を回避する場合、通常、役立つ手段はホットパスの決定性、運用の明確さ、相互運用サーフェス、およびシミュレーションの現実性です。それらが可視化されると、残りの決定はより人間的になり、神秘的ではなくなります。

2 番目の永続的な習慣は、証拠と約束を分離することです。エンジニアは、システムがその結論を得る前に、ある方向性が正しいと言うよう圧力をかけられることがよくあります。そのプレッシャーに抵抗してください。特にトピックが顧客やお金に近い場合は、最初に狭い証明を作成します。検証されていない大きな野心よりも、検証された小さな改善の方が商業的価値があります。これは、四半期末のレビューで仮説が期限に変わり、組織全体が楽観主義をスケジュール作成の成果物のように扱うようになるまでは、当然のことのように思えます。

3 番目の永続的な習慣は、所有者の言語で推奨事項を書くことです。 「パフォーマンスを向上させる」または「境界を強化する」という文章は、感情的には心地よいものですが、運用上は役に立ちません。月曜日の朝に実際に生き残るのは、誰が何を、どの順序で、どのロールバック条件で変更するかを述べた段落です。多くのテクニカル ライティングが失敗するのはここです。スケジュール可能であることよりも、先進的に聞こえることを望んでいます。

時間を節約する反例

最も一般的な反例の 1 つは次のようなものです。チームはローカルで大きな成功を収め、システムが理解されたと想定し、測定規律をアップグレードすることなく、アイデアをさらに要求の厳しい環境に拡張します。これは工学的に言えば、ホテルのプールで泳ぎ方を覚えてから、海の天気について自信を持って TED トークをするのと同じことです。水ではなくなるまでは水です。

もう 1 つの反例は、ツールのインフレです。新しいプロファイラー、新しいランタイム、新しいダッシュボード、新しいエージェント、新しい自動化レイヤー、古いラッパーとの調和を約束する新しいラッパー。これらはどれも本質的に悪いことではありません。問題は、誰も明確に名指ししていない境界線の補償を求められたときに何が起こるかということだ。その後、システムはさらに装備され、より印象的になり、場合によってはより理解できるようになります。購入者はこれをすぐに感じます。そのような表現がなくても、積み重ねが決断の代償として高価なものになったことを彼らは嗅ぎ分けることができます。

3 番目の反例は、人間によるレビューを自動化の失敗として扱うことです。実際のシステムでは、多くの場合、人間によるレビューが自動化を商業的に受け入れられる状態に保つための制御となります。成熟したチームは、どこを積極的に自動化するか、どこで承認や解釈を可視化するかを知っています。未熟なチームは、スライド内で「すべて」が効率的に聞こえるため、マシンにすべてを実行させたいと考えます。その後、最初の重大なインシデントが発生し、突然手動レビューが変換体験の誠実さによって再発見されます。

弊社が推奨する配信パターン

仕事が順調に進んでいる場合、最初の成果物は、チームに輪廻議論をやめるのに十分な技術的な読み取りを提供することでストレスを軽減するはずです。その後、次の制限付き実装で 1 つの重要なパスが改善され、再テストによってエンジニアリングとリーダーの両方が方向性を理解できるようになります。その順序は、正確なツールの選択よりも重要です。それは、技術スキルを前進に変えるものだからです。

実際的な観点から言えば、最初のサイクルは狭いことをお勧めします。つまり、アーティファクトを収集し、1 つの厳密な診断を作成し、1 つの限定された変更を出荷し、実際のパスを再テストし、次の決定を平易な言葉で書くというものです。分かりやすい言葉が重要です。買い手が明確さを後悔することはほとんどありません。購入者は、領収書が届く前に感動したことを後悔することがよくあります。

ここでもトーンが重要になります。強力な技術的な作業は、以前にプロダクションに対応したように聞こえるはずです。穏やかで、正確で、誇大宣伝に養われるというよりは、それを少し楽しんでいます。そのトーンは操作信号を伝えます。これは、チームがシステム エンジニアリングの古い真実を理解していることを示しています。マシンは高速であり、ロードマップは脆弱であり、詩的であり続けることを許可されていたすべての仮定に対して、遅かれ早かれ法案が到着します。

これが準備完了であると判断する前に使用するチェックリスト

暗号システム エンジニアリングにおいて、準備は気分ではありません。それは結果を伴うチェックリストです。 DEX インフラストラクチャで言語選択を回避し、より広範な展開に備えて準備を整える前に、可能な限り最良の方法でいくつかのことを退屈にしないようにしたいと考えています。代表的な負荷の下で予測どおりに動作する 1 つのパスが必要です。矛盾しない 1 セットの測定値が必要です。私たちはチームに、境界線がどこにあるのか、そしてそれを壊すことが何を意味するのかを知ってもらいたいと考えています。そして、実装室の外にいる誰かがそこから正しい判断を下せるように、作業の出力が十分に明確であることを望んでいます。

そのチェックリストは通常​​、ホットパスの決定論、運用の明確さ、相互運用面、およびシミュレーションの現実性に触れます。数値が正しい方向に進んでいるにもかかわらず、チームが即興でシステムを説明できない場合、作業の準備ができていません。建築が印象的に聞こえても、現場からのささやかな反例に耐えられない場合、その作品はまだ準備ができていません。実装は存在するが、ロールバックの話がタイムスタンプ付きの祈りのように聞こえる場合は、作業の準備ができていません。これらはいずれも哲学的な反論ではありません。それらは単に、高価なサプライズが登場する傾向にある形式にすぎません。

これは、チームが実際の問題を解決しているのか、それともその問題に近い能力を単に練習しているだけなのかを発見する場所でもあります。非常に多くの技術的取り組みは、誰かが再現性、生産の証拠、または予算に影響を与える決定を要求するまでは、成功したように感じられます。その瞬間、弱い作品はぼやけてしまい、強い作品は妙に地味になってしまいます。プレーンが良いです。プレーンとは通常、システムがカリスマ性に依存するのをやめたことを意味します。

結果について話すことを推奨する方法

最終的な説明は、リーダーシップ会議に耐えられるほど簡潔であり、エンジニアリングレビューに耐えられるほど具体的である必要があります。それは思っているよりも難しいことです。過度に専門的な言葉は順序を隠します。過度に単純化された言葉はリスクを隠します。適切な中間点は、勝ち誇ったような感じではなく、穏やかに聞こえる方法で、道筋、証拠、限界のある変化、そして次に推奨されるステップを説明することです。

このような構造を推奨します。まず、どのパスが評価されたのか、そしてそれがなぜ重要なのかを述べます。次に、その道に関して何が間違っていたのか、何が不確実だったかを述べます。 3 番目に、何が変更、測定、または検証されたかを述べます。 4番目に、何が未解決のままなのか、そして次の投資で何が買えるのかを述べます。この構造が機能するのは、エンジニアリングと購買行動の両方を尊重しているからです。エンジニアは詳細を求めています。購入者は順序付けを望んでいます。サプライズを楽しんでいるふりをしている人も含めて、誰もがサプライズを減らしたいと思っています。

このように話すことの隠れた利点は文化的なものです。技術的な作業を明確に説明するチームは、通常、それをより明確に実行します。彼らは曖昧さを洗練されたものとして扱うのをやめます。専門用語では印象を与えることが難しくなり、難しいシステムでは信頼されやすくなります。これは、エンジニアリングの成熟度の最も過小評価されている形態の 1 つです。

私たちがまだ偽造を拒否したいもの

システムが改善された後でも、成熟したチームは暗号システム エンジニアリングにおける不確実性を正直に保ちます。弱い測定にはより明確な証拠が必要であり、厳しい境界には平易な言葉が必要で、より穏やかなデモには実際の運用準備が必要です。ある程度の不確実性は軽減する必要があります。正直に名前を付けなければならない人もいます。この 2 つの仕事を混同すると、立派なプロジェクトが高価なたとえになってしまいます。

同じルールが、DEX インフラストラクチャでの言語選択に関する決定にも適用されます。チームに再現可能なベンチマーク、信頼できるロールバック パス、または重要なインターフェイスの明確な所有者が依然として不足している場合、最も役立つ出力は、より大きな約束ではなく、より明確なノーまたはより狭い次のステップである可能性があります。この規律により、技術的な作業が改善を目的とした現実と一致した状態に保たれます。

このように作業すると、不思議な安心感があります。システムが楽観的なストーリーテリングに依存しなくなると、たとえ作業が困難なままであっても、エンジニアリングに関する会話はよりシンプルになります。そして生産現場では、それは多くの場合、ささやかな恵みとして数えられます。

Dex インフラストラクチャ計画に関する追加の注意事項

DEX インフラストラクチャにおける適切な言語分割は、通常、紙の上では控えめに見えます。ある言語は、予測可能性、レガシーの活用、または生のシステムの使いやすさが最も重要な場所を占めています。もう 1 つは、境界の規律と新しいコンポーネントの分離により、配信ストーリーがより健全になる場所を所有しています。間違いは、言語の選択をイデオロギーに変えようとすることです。取引システムはイデオロギーを気にしません。彼らは、パケットの欠落、不安定なキュー、偽りのシミュレーションの信頼度、およびそうでないふりをするための請求書を気にします。

そのため、言語がどこで交わるか、それらの継ぎ目がどのようにテストされるか、および各側にどの運用指標が属するかを正確に示すアーキテクチャ マップを推奨します。 C++/Rust の混合スタックの操作を 1 つの冷静な図で説明できない場合は、おそらく準備ができていません。そして、それが明確に説明できれば、混合スタックはまったくエキゾチックに見えなくなることがよくあります。それは単純に、ファッションよりもフィット感を選択することをいとわないエンジニアリングのように見えます。

実際の技術レビューからのフィールドノート

C++ システムの配信では、デモが実際の配信、実際のユーザー、実際の運用コストを満たしたときに、作業が本格化します。それは、きちんとしたアイデアがシステムのように動作し始める瞬間であり、システムは有名なドライなユーモアのセンスを持っています。彼らはキックオフデッキがどれほどエレガントに見えるかなど気にしません。彼らは、境界、障害モード、ロールアウト パス、そしてスタックに関する新しい神話をでっち上げずに次のステップを説明できる人がいるかどうかを重視しています。

C++, Rust, and Decentralized Crypto Exchanges: Applicability and Efficiency の場合、実際的な問題は、ロードマップ、プラットフォーム、またはセキュリティ レビューにすでにプレッシャーを感じている購入者に対して、より強力な配信パスを作成できるかどうかです。その購入者は、霧の中に磨き上げられた講義を必要としません。彼らは使用できる技術的な読み取りを必要としています。

最初に検査するもの

まず、ネイティブ推論、プロファイリング、HFT パス、DEX システム、および C++/Rust モダナイゼーションの選択肢という 1 つの代表的なパスから始めます。その道は測定するには十分に狭く、真実を明らかにするには十分に広くなければなりません。最初のパスでは、割り当て動作、p99 レイテンシ、プロファイル証拠、ABI 摩擦、および信頼性の解放をキャプチャする必要があります。これらの信号が利用できない場合、プロジェクトは依然として白衣を着た意見がほとんどであり、意見はそれ自体を戦略として宣伝してきた長い歴史があります。

最初の有用な成果物は、ベンチマーク、プロファイリング証拠、および範囲を絞った実装計画を含むネイティブ システムの読み取りです。計画会議で誰もが期待したとおりに動作するのではなく、システムが動作するとおりに示す必要があります。トレース、リプレイ、小さなベンチマーク、ポリシー マトリックス、パーサー フィクスチャ、または反復可能なテストは、多くの場合、別の抽象的なアーキテクチャの議論よりも早くストーリーを伝えます。良い工芸品は驚くほど失礼だ。彼らは希望的観測を中断します。

時間を節約する反例

高くつく間違いは、最初の有用な証明よりも大きな解決策で応答することです。チームはリスクや遅延を認識すると、すぐに新しいプラットフォーム、書き換え、全面的なリファクタリング、またはヨガをしているような名前の調達しやすいダッシュボードに手を出します。場合によっては、そのスケールが正当化されることもあります。多くの場合、これは測定を延期する方法です。

より良い動きはより小さく、より鋭いです。境界に名前を付けます。証拠を捕らえます。重要なことを 1 つ変更します。同じパスを再テストします。次に、次の投資がより大きな投資に値するかどうかを決定します。このリズムは変革プログラムほど劇的ではありませんが、予算、リリース カレンダー、および制作上のインシデントに影響されても存続する傾向があります。

弊社が推奨する配送パターン

最も信頼性の高いパターンには 4 つのステップがあります。まず、代表的な成果物を収集します。次に、これらのアーティファクトを 1 つの難しい技術診断に変換します。 3 番目に、1 つの限定された変更またはプロトタイプを出荷します。 4 番目に、同じ測定フレームで再テストし、次の決定をわかりやすい言葉で文書化します。このクラスの作業では、CMake フィクスチャ、プロファイリング ハーネス、小さなネイティブ再現、およびコンパイラ/ランタイム ノートの方が、一般的な方向性に関する別の会議よりも価値があるのが通常です。

分かりやすい言葉が重要です。購入者は出力を読んで、何が変化したのか、何が依然としてリスクが残っているのか、何を待てばよいのか、次のステップで何を購入するのかを理解できる必要があります。推奨事項をスケジュールしたり、テストしたり、所有者に割り当てることができない場合でも、それは装飾的すぎます。装飾的なテクニカルライティングは楽しいものですが、制作システムがその心地よさをもたらすとは知られていません。

結果が役に立ったかどうかを判断する方法

C++, Rust, and Decentralized Crypto Exchanges: Applicability and Efficiency の場合、結果により配信速度、システムの信頼性、商用化の準備の 3 つのうち少なくとも 1 つが改善されるはずです。これらのどれも改善されない場合、チームは何かを学んだ可能性がありますが、購入者はまだ有用な結果を受け取っていません。その区別が重要です。学ぶことは崇高なことです。有料のエンゲージメントもシステムを動かすはずです。

最も強力な成果は、より狭いロードマップ、危険なパスの自動化の拒否、モデルの境界の改善、よりクリーンなネイティブ統合、書き換えがまだ必要ではないという慎重な証拠、またはリーダーが実際に資金を提供できる短い修復リストなどです。真剣なエンジニアリングとは、より良い意思決定の連続であり、ツールの仮装コンテストではありません。

SToFU はそれにどうアプローチするか

SToFU は、これを最初に配信の問題として扱い、次にテクノロジーの問題として扱います。私たちは関連するエンジニアリングの深さをもたらしますが、その取り組みは、経路、境界、リスク、測定、そして行う価値のある次の変更などの証拠に基づいて行われます。重要なのは、ハードワークを簡単に思わせないことです。重要なのは、次の重大な行動を実行できるほど明確にすることです。

それは、購入者が通常最も重視する部分です。彼らはどこでも意見を採用できます。彼らに必要なのは、システムを検査し、実際の制約に名前を付け、適切なスライスを構築または検証し、通話終了後の混乱を軽減する成果物を残すことができるチームです。騒がしい市場では、明確さはソフトスキルではありません。それはインフラです。