誕生日のお祝い アーカイブ 記事 プロジェクト 言語 English العربية Deutsch Español Français עברית हिन्दी Italiano 日本語 한국어 Português Русский 中文 ← 記事に戻る 発見September 19, 202615分で読めますKitsune2: 検索が速くなった251x、更新パス33x、そしてゴシップが早く始まった15x Holochainのネットワーキングレイヤーでの朝の実験の中で：ノードがピアを見つけ、欠落データを取得し、ゴシップを再開し、そして6の小さなパッチが途中で何を変えたか。
Developed by Robert E. Beckner III (Merlin) | rbeckner.com
最近、4:30 a.m.頃に起きて、日の出直前にそれを楽しんでいます。 9月19日、私はその朝を使ってHolochainの下にあるピアツーピアネットワーキングレイヤーであるKitsune2のラボを始め、そこが時間を費やしている場所を探しました。12:20 p.m.までに、ラボは6パッチを生成しました。 エンドポイントルックアップ：251× faster at 10,000 retained identities. それらを呼び出すピアアップデートパス：33× faster . 完了したフェッチ後のゴシップ開始：3,002 ms down to 202 ms . バーストリクエストトラフィック：96.9% fewer messages . 3 変更の修復された作業が不要に待っていた、または決して起こらない何かを待っていた。私は25年以上コードを書いており、GPT-3以降AIで構築しています。 私はそれを使って、気になることやまだ理解していないことを分離し、処理し、私たちが学んだと考えていることをテストします。 私はその部分が好きです：質問を実験に変えて、何が成り立つかを見る。 今朝、AIコーディングエージェントとともに、私はHolochainノードが互いに最新状態を保つ機械にそのアプローチを適用しました。Holochainアプリケーションは参加コンピュータ、またはノード 間でデータを共有します。 各参加者は自分自身の署名付き履歴を保持し、アプリケーションの共有データの一部を検証し保存するのを手伝います。 共有ストアは 分散ハッシュテーブル 、または DHT です。コピーは複数のピアに存在するため、データは著者がオフラインになっても利用可能です。 Holochain's DHT guide は、これらの責任がどのように分散されるかを説明しています。Kitsune2 はその下でピアツーピア通信を処理します。 ノードが追いつく様子を想像してください：それはピアがどこにいるかを学び、保持しているものとピアが保持しているものを比較し、欠けているピースを要求します。 Gossip は、ピアが差異を発見するための交換です； fetch は欠落した操作を取得し、Kitsune2 が転送するデータ単位です。 受信ノードはそれらをホストの操作ストアに渡します。 Holochain はそれらの検証と統合を処理します。graph TD
A[ピアのアイデンティティとエンドポイントを学習する] --> B[Gossip を通じてデータを比較する]
B --> C[欠落した操作を特定する]
C --> D[ピアから操作を取得する]
D --> E[受信した操作をホストストアに渡す]
E --> F[保留中のフェッチが完了したことを示す]
F e1@--> B
e1@{ animation: fast } Copy source各6変更が実際に何を動かしたか# 私たちは上流コミット 06555ee0.6.0-dev.1。 各比較は、そのベースラインと記録されたパッチシーケンスを使用します。 下のラベルは発見を実験記録に結び付けます。すべての6パッチは現在上流レビューに提出されています。ラベル 何が変わったか 測定結果 K3a フェッチ完了時に既存のドレインヘルパーを呼び出す 完了したフェッチ後のゴシップ開始：3,002 → 202 ms K3b 受信者ロックをデキューに限定 実効並列性は1 でした。設定されたワーカーは現在本当に重なります K3c 生成タグ付き入場所有権 キャンセルされた呼び出し側のストランド0 は保留中のキーを持っていました。ベースラインは8 で立ち往生しました K3d-P1 Setベースのレスポンスクリーンアップ 1.9–6.1× 大量の保留ロードで高速なレスポンス処理K3d-P2 同一ピアバッチングのオプトイン（デフォルト 1） バースト：87.5–96.9% リクエストメッセージが少ない K1 URL をエージェントインデックスに逆変換 10,000 で保持されたアイデンティティ：更新 21–33× 、ルックアップ 118–251× が高速、3.10× ストアメモリ
最初の修復はフェッチ完了を待機中のゴシップタスクに再接続します。 変更は既存のヘルパーを呼び出し、リスナーに保留マップが空になったことを通知します。 完了したフェッチと意図的に開いたままにしたフェッチの両方をテストしました。Gossip initiation after a fetch completes, with the control that must not move (ms) Chart datamillisecondsUpstream 06555ee With the drain notification restored Fetch completed 3001 202 Fetch still pending (control) 3002 3001
すべての変更は1つのクレートにあり、5 は 6 の1つのファイルにあります# Rust クレートはコードのパッケージです。 すべての 6 パッチはコアクレートにあり、そこにはピアレコードとフェッチ機構が含まれています。 それらはゴシップがデータと完了信号を取得する方法を変更し、ゴシップアルゴリズムや基盤となるネットワークトランスポートを編集しません。 バッチングはオプションのコア設定フィールドを追加します。ラベル ファイル 行 K1 core/src/factories/core_known_peers.rs+33 / −10 K3a core/src/factories/core_fetch.rs+1 K3b core/src/factories/core_fetch.rs+11 / −3 K3c core/src/factories/core_fetch.rs+71 / −53 K3d-P1 core/src/factories/core_fetch.rs+6 / −1 K3d-P2 core/src/factories/core_fetch.rs, 1つのテストファイル+89 / −17
5つのパッチが記録された順序で core_fetch.rs にスタックされ、欠落した操作を要求し、応答を処理します。 残りのパッチは core_known_peers.rs にあり、どのアイデンティティがどのネットワークエンドポイントに関連付けられているかの保持された記録です。 その後、すべての 6 を単一のソースツリーに適用し、それらを一緒に実行しました。データは到着していたが、ゴシップはまだ待機していた# CoreFetch は要求した操作とその送信者のマップを保持します。 ピアの応答が到着し、操作が正常に保存されると、コードはそれらの識別子をマップから削除します。 ファイルの他の部分、送信エラー経路とピアクリーンアップ経路は、エントリを削除した直後にnotify_listeners_if_queue_drainedというヘルパーを呼び出します。 成功経路はそれを呼び出しません。ノードは、ストレージアーク と呼ばれるDHTの保存部分を拡張できます。 それを行うには、より大きな範囲内のデータを追いつく必要があります。 アーク成長経路でテストしたように、ゴシップは未完了のフェッチが終了するまで待ち、ピアと開始する前にタイマーをフォールバックとして使用します。 データが到着し、保留マップが空になったが、その信号を待っているタスクはタイマーが切れるまで眠り続けました。sequenceDiagram
participant G as Gossip arc-growth loop
participant F as CoreFetch
participant P as Peer
G->>F: Register a drain waiter
P->>F: Final response, operations stored
F->>F: retain() empties the pending map
Note over F: helper exists, never called
F--xG: Notification that never arrives
G->>G: Initiate after the roughly 3-second fallback Copy source完了前に 登録しました。 データが保存された後、あのウェイターは元のコードで通知を受けていませんでしたが、パッチを適用すると通知を受け取りました。 これはデータ受信と次のゴシップ交換開始の間のハンドオフを修復します。私たちはまた、部分応答、ストアエラー、いくつかのリスナー、リクエスト完了または新しい作業が到着したときに登録されるリスナーも確認しました。 部分応答はウェイターを保留にしたままにする必要があります。最終的な未完了フェッチが完了したときにのみウェイターが起動します。5 ワーカーが設定され、1 が実際に送信していた# CoreFetch の送信側は、1 つの共有チャネルからタスクを引き出す設定された数のワーカータスクを実行する。 ループは次のように書かれていた：rustCopy sourcewhile let Some(..) = outgoing_request_rx.lock().await.recv().await { // send the request} ロックは 1 ワーカーが共有キューから次のリクエストを取得できるようにする。 しかし Rust はその一時的なロックガードをこの while let の本体全体で保持し、ネットワーク送信の待機も含めている。 1 ワーカーが送信している間、他の 4 は次のリクエストを集めることさえできなかった。 すべてのリクエストは最終的に到着できるため、設定された同時実行度が使われていない状態で配信テストが合格することがある。受信を短いブロックに移動し、送信が開始される前にロックを解放した。 ワーカーは引き続きリクエストを収集し、次にそれらを同時に送信する。 送信が遅い場合でも、他のワーカーがリクエストを用意している間にキューのロックを保持しない。Outgoing sends in flight at the same moment, by configured worker count Chart dataconcurrent sends observedUpstream 06555ee Dequeue-scoped guard 1 worker 1 1 2 workers 1 2 5 workers 1 5
コールラーをキャンセルすると、ノードは 8 未送信操作を待機し続けました# フェッチリクエストは 2 レコードを通過します：保留マップはノードが待機しているものを示し、送信ワーカー用の作業は送信キューに保持されます。 request_ops は、操作を要求するメソッドで、キューに空きがあるまで待つ前に保留マップに一括で追加しました。コールラーが容量待ち中にキャンセルされた場合、いくつかの操作はすでに保留としてマークされていましたが、ワーカーはそれらを受信していませんでした。 私たちはキューを満たし、ブロックされたコールラーをキャンセルし、すべての 16,385 承認済みリクエストを完了させました。 8 操作は保留のままでした。 それらは送信キューに入っていなかったため、クリアするための応答がありませんでした。これは最初の修復に直接つながります：マップに未完了の作業が残っている間に完了通知は発火できません。 ここでは、ノード自身の帳簿管理が待機を続けていました。パッチはまずキュー容量を確保し、次に操作を記録してキューに投入しますが、その間に別の await はありません。 各エントリは世代タグも持っているため、古い失敗送信からのクリーンアップが同じ操作の新しいリクエストを消去することはありません。 すでに承認された作業はコールラーのキャンセルを生き残ります；承認待ちの作業は保留エントリを残しません。これによりリクエストの所有権が修復されます。 総メモリ制限は別の設計上の質問であり、コールラーはまだ大きなバッチを提供できます。リクエストメッセージを減らし、各メッセージの最大サイズに制限を設ける# キャッチアップ中のノードは、同じピアから多くの操作を必要とする場合がある。 Kitsune2のリクエスト形式はすでに識別子のリストをサポートしているが、アウトゴーイングコードはメッセージごとに1を送信する。 それらのリクエストを結合する前に、より大きな応答がどのように処理されるかを確認した。保留中の各操作について、応答クリーンアップは返された識別子のリストをスキャンし、そのエントリを削除できるかどうかを確認した。 8,192保留エントリと1,024返された識別子があると、検索が大量に繰り返される。 返された識別子のHashSetを構築すると、各メンバーシップチェックが安価になり、応答処理はその場合6.1×速く 測定された。 返された識別子が16だけの場合、データの保存が支配的で、変更はほとんど効果がなかった。その後、同じピアの準備ができたリクエストを結合した。 64小さな操作のバーストでは、8と32のバッチサイズがリクエストメッセージをそれぞれ87.5% と96.9% 削減した。Burst behaviour relative to the default batch size of 1 (percent of control) Chart datapercent of controlRequest messages Elapsed time Batch 1 (control) 100 105.4 Batch 8 12.5 72.6 Batch 32 3.1 67.7
27–32% 早く終了した。 同じ操作はまだ転送および保存される必要があった；節約はそれらを運ぶリクエストの数にあった。 バッチ-1制御はベースライン経過時間の105.4%を測定し、バッチングが無効でも約5%のタイミングドリフトを示した。ワーカーはすでに準備ができているリクエストだけを結合するので、単独のリクエストはバッチが満たされるのを待つことはない。 バッチ分割は、設定された識別子制限と4,096-byteエンコードされたリクエスト閾値 の両方を使用する。 アイテム数だけを数えても総サイズを制限できない；200識別子を使ったテストでは、それらをいくつかの上限付きメッセージに分割する。 単一の識別子がその閾値を超える場合でも送信されるので、これは普遍的なワイヤサイズ制限ではない。 応答は実際のデータを持ち、応答ノードに別のサイズ制限が必要になる。候補者はバッチサイズ 1 をデフォルトとして保持し、既存の設定を変更せずに受け入れます。 単一リクエストの別テストが一貫性のない末尾レイテンシ結果を生じたため、より大きなバッチをオプトインに残しました。以下で説明します。スキャンを更新パスから外すことは33×の価値があり、ルックアップ自体では251×だった# CoreKnownPeers はアイデンティティとそれに関連付けられたネットワークエンドポイントを記憶する。 複数のアイデンティティが同じエンドポイントを共有でき、ブロックされたアイデンティティはアクティブピアストアから削除された後も識別可能である必要がある。 というのは、このストア内のアイデンティティの履歴を意味し、同時に接続されている10,000 コンピュータではない。 ピアストア更新時に、アクセス制御はどのアイデンティティがエンドポイントに属するかを尋ねる。 ルックアップ、get_by_url、は各回ロック下で保持マップ全体をスキャンした。 その履歴が増えるにつれて、現在のピア情報の更新はよりコストがかかるようになった。エンドポイント URL からそれに関連付けられたアイデンティティへのインデックスを追加した：HashMap<Url, HashSet<AgentId>>。元のレコードは権威を保持する。アイデンティティがエンドポイントを変更すると、インデックスはそれを対応するセットに移動させる；ルックアップはそのセットに直接アクセスできる。両バージョンは、更新、古い広告、削除、共有エンドポイントをカバーする 19,422 結果チェックを通過した。Microseconds per 16-advertisement update call (log scale) Chart datamicroseconds per update callretained identities Upstream linear scan Derived URL index 100 6.857 4.911 1,000 18.103 4.774 10,000 154.849 4.72
155 µs から 4.72 µs に減少し、ペアで 33× の利得を得た。 インデックス版は、リスナーが成長する履歴をスキャンしなくなるため、これらのサイズでほぼ平坦に保たれる。API で測定し、呼び出し元ではなく、ルックアップ自体はスキャンからハッシュへ移行する。 10,000 保留アイデンティティでのミスは 11,423 ns から 45 ns に減少し、ペアで 251× 、単一ヒットは 9,309 ns から 79 ns に減少し、118× . 多くのアイデンティティを返すクエリは、返すものに応じてスケールし続けるため、共有-URL ケースは 2 桁の大きさではなく 4.4× の利得を得る。 251× は孤立したルックアップ結果である。 33× はそれを使用するより大きな更新コールを測定するものであり、これらの利得は追加または乗算できない。Requested store memory at 10,000 retained identities, by endpoint shape Chart datamegabytesUpstream With the index Mixed endpoints 1.2 3.71 All shared 1.2 1.74 All URL-less 1.2 1.2
すべての 6 パッチを合わせると、ノードは完了して継続できる# 組み合わせたリプレイは Kitsune2 の実際のゴシップ、フェッチ、ピアアクセス、メモリストアコンポーネントを使用し、インメモリテストトランスポート を通じて通信した。 元のソースツリーとパッチ適用後のツリーで 5 ステップのシーケンスを実行した：ピア情報を更新する。 アイデンティティがエンドポイントを変更する。 後から到着した古い情報は新しいレコードを保持し、ブロックされたアイデンティティはアクセス制御で解決可能である。 両方のバージョンが通過し、インデックスは既存の決定を保持する。フェッチ完了後にゴシップを開始する。 パッチ適用ノードは 202 ms 後に開始する。 元のノードは 3,002 ms でフォールバックパスを取る。順不同でデータを受信する。 3 が要求した操作は 4 応答として到着し、重複も含む。 両方のバージョンは一貫して保存し、バイト数を正しい操作に関連付ける。フェッチを完了する。 保存された操作は取得可能である。 パッチ適用ノードは、これらの操作が保留中である間に登録されたリスナーも起動する。失敗したピアの後に継続する。 制御送信失敗はそのピアのリクエスト状態をクリアする。 別のピアが操作を供給し、保留マップが空になり、後続のフェッチが成功する。 元のノードでは完了通知のチェックが失敗する。各利益がコストするもの# インデックスはメモリを消費し、エンドポイント変更をより高価にします。 元の小規模ストアテストでは、固定セットのアイデンティティを新しいURLに更新すると、0.946×ベースライン速度で実行され、100保持されたアイデンティティがありました。 10,000で、孤立したエンドポイント変更書き込みは3.68×のコストがかかりました。 追加インデックスを維持するには代価があり、検索節約がそれを返済しなければなりません。そのトレードオフが実際にあるため、インデックスが失われるワークロードを探しました。 36構成は測定前に事前宣言され、432ペア実行が実行され、結果トランスクリプトはバリアント間で同一にハッシュされました。Paired speedup across the 36-config workload envelope, by mix (log scale) Chart datapaired speedupretained identities Steady, no rebind 100% rebind Shared endpoints URL-less heavy 100 1.61 1.47 1.42 1.09 1,000 7.2 6.26 4.12 2.13 10,000 55.56 36.42 5.55 12.16
Reference line, parity: 1
結論が出ていません ：その1.09×中央値にはパリティを下回るペア結果が含まれていました。 特定のワークロードに対してインデックスを推奨する前に、保持されたアイデンティティ数、エンドポイント変更、および検索頻度を示す実際のノードからのトレースがまだ必要です。同時送信はクリーンアップ相互作用を露呈しました。 ワーカーが重複できるようになると、失敗した送信のクリーンアップが同じピアへの別のリクエストが進行中の間に実行される可能性がありました。 これにより、既存のピア全体のクリーンアップが失敗した作業よりも広範になりました。 所有権パッチは、削除をそのリクエスト生成にまだ属するエントリに限定しました。 パッチを一緒にテストすることがここで重要でした。バッチングの単一リクエスト遅延は結論が出ていません。 p95を測定し、95%のリクエストが完了する時間を測定しました。 単独で送信されたリクエストの場合、ワーカーの最終実行は1.01–1.08×ベースラインp95を示し、独立した再実行は1.44–1.58×を示しました。 これらの装置は数十マイクロ秒かかり、制御もドリフトしました。 バースト改善は再現されましたが、単一リクエストの結果は安定せず、したがって大きなバッチはオプトインのままです。繰り返し比較と停止した送信は未解決のままです# 同じキャッチアップシーケンスの 2 他の部分も調査しました。 どちらも受理されたパッチを生成しませんでした。仲間が既に保持しているものを比較する（K4）。 Gossip は保存されたデータのコンパクトな要約を使用して差分を見つけます。 最大のテストでは、変更されていないスナップショットを生成して比較すると 262,144 個のハッシュが生成されました；それを 10 回繰り返すと毎回同一の出力が得られました。 以前の要約を再利用するのは魅力的に見えますが、ホストストアが信頼できる無効化シグナルなしに変更される可能性があります。 キャッシュされた要約は、仲間間の差分を隠す可能性があります。 評価した代替案も、インメモリストアで必要な 20% 時間節約を満たせませんでした。 実際の Holochain ストアからの測定値が次の欠落した要素です。Gossip 送信が停止したときの回復（K2）。 ソースを読むと、送信がロックを保持し、タイムアウトタスクもそのロックを必要とするという疑問が生じました。 その送信が途中でキャンセルされた場合、基盤となる Iroh トランスポートストリームに何が起こるかも確立する必要がありました。 エージェントプロバイダーは再現ドライバーの作業をブロックしたため、ランタイムテストは完了しませんでした。 これは未テストの懸念であり、パッチや信頼性の結果はありません。私たちが測定したこと、そしてまだ測定されていないこと# これらの実験は開発ソース 0.6.0-dev.1 で実行され、1台の共有 Apple M4 Max（16論理コア）で行われた。 コアピンニングや第二の物理ホストなしでローカルテストノードとインメモリトランスポートを使用した。 結果は名前付きコンポーネントとその相互作用をカバーする。 ネットワークスループット、全ネットワーク収束、総ノードメモリ、Holochainアプリケーション遅延は未測定のまま。この方法は私のベンチマーク駆動開発 に基づく。 各質問と受理閾値を記録し、比較ごとにソースとフィクスチャを固定し、コマンド、サンプル、失敗をアペンドオンリーのレシートに保持した。3修復のために、同じテストは元のコードで期待されるアサーションで失敗し、パッチで合格した。 最適化では、両バージョンが動作を保持し、測定値が述べられた閾値を満たす必要があった。 タイミング実行は順序を交互にし、コンパイルを測定ウィンドウ外に保った。 監督エージェントは凍結されたソースで受理コマンドを再実行し、各結果を受理する前に単一リクエスト遅延に関する不一致を最終報告に残した。完成したパッケージには204レシートディレクトリが含まれている。 組み合わせテストは12:17 p.m.に受理され、ターミナル結果は12:20 p.m.に記録された。最終クローズチェックは2:38 p.m.に保持された。すべての6つのパッチは現在アップストリームレビューのために開かれている： completion notification 、worker concurrency 、admission ownership 、response cleanup 、request batching 、および endpoint indexing 。主な帰属# 私による。 ラボ自体：私のベンチマーク駆動型メソッド、Kitsune2 が時間を費やしている場所を特定するために指向しました。GPT-6 Astra による。 完了通知と受入れ所有権修復：診断、パッチ、および元のコードで失敗するテスト。 それはまたラボ記録からこの記事を洗練しました。GLM-5.3 による。 ワーカー同時実行修復、応答クリーンアップとバッチング、インデックス用の 36 構成ワークロードマトリックス、オープン K4 質問の背後にある DHT 要約プロファイリング、およびすべての 6 パッチの統合再生。AI による。 エンドポイントインデックスとその測定、凍結ソースで各受入れを再実行する監督エージェント、およびこの記事の最初のドラフト。残った批判。 私から：ドラフトは内部メカニズムを説明した後に Holochain ノードが何をしているかを述べ、2 オープンクエスチョンは何にも結びつかずに到着しました。 キャッチアップシーケンスは現在すべてのパッチを導入し、各オープンクエスチョンはそれが関係するステップに位置します。 AI から：朝が「ブレークスルー」という言葉を得たかどうか尋ねました。 それは派生インデックスと復元されたヘルパー呼び出しが正しい修正であり、新しい技術ではないと主張しました。 記事は発見として提出されました。 GPT-6 Astra から：いくつかのドラフト主張がその受領を上回りました。 それは測定されたものに対してそれらを保持しました：10,000 の保持アイデンティティは歴史であり、10,000 の接続されたコンピュータではありません；インデックスのメモリコストは記録に残ります；単一リクエスト遅延とほぼ URL-less ケースは未確定のままです。 一緒に到達。 記事が従うキャッチアップシーケンス：ノードはピアを学び、保持しているものを比較し、欠けているものを取得し、保存し、続行し、各パッチは変更するステップに配置されます。構築元。 Holochain コアチームの交換可能なコンポーネントファクトリーとインメモリトランスポート、これによりラボは実際の Kitsune2 コンポーネントでこれらの動作をテストできます。#benchmarking#distributed-systems#rust#performance#AI#agents#open-source#experiential#insights—Robert E. Beckner III (Merlin)読み続ける前へ知能は従えない：判断、権威、そして拒否が示すもの 次へプロンプトキャッシュのミスは、組織に AI の各ターンでほぼ 6 倍のコストをもたらす可能性があります Qwen 3.8-27B M1 Ultra 上で： 12.1から20.3まで tok/s すべてを測定して発見August 14, 20268分で読めます MTPLX 上で M1 ウルトラ： その 25 トーク/ス 調整 その 提供した 16.5発見August 15, 20268分で読めます 最後の CLI: 私のツールが構築されたベース51を再構築する発見August 19, 202610分で読めます 関連プロジェクト175-Page Chinese ManuscriptAI Innovation AI Translation SystemAI Innovation