№ 12·0212 · ロードマップ4 min read · Section 2 of 4

12.2 フェーズ 2: PoB とエージェントのコラボレーション

Uniswap v2/v3 とイーサリアムのベンチマークでは、ロールアップが中心的な段階として取り上げられ、標準が強化され、構成可能性が強化されています。 PoB を調整したり、エージェントを監査したりロールバックしたりできます。

UpdatedOct 20, 2018

12.2 · PoB とエージェントのコラボレーション

手動スプライシングからシステム運用まで、標準、ログ、権限、複製可能なメソッドが同じ段階で調整されます。

最初の段階では、「ネットワークが実行できる」ことを証明します。この段階では、「ネットワークが大規模に実行できる」ことが証明されます。PoB は構成可能な信頼台帳になり、エージェントはブラックボックスの自動化ではなく、制約付きの実行レイヤーになります。

中核的な目標PoB 標準化 + エージェントエンジニアリングガバナンス

成功基準人間とマシンのコラボレーション SLA、PoB バージョン管理、および例外に対する説明責任

まだやってないすべての値をチェーンに割り当てます。エージェントが独立して高リスクのコミットメントを行えるようにする

Uniswap v2→v3: 一般的なプールから一元的な流動性と手数料層まで、「ルールの洗練 + 資本効率」の二重の進化です。 WCN フェーズ 2 は、PoB フィールド、監査レベル、インセンティブ、帰属ルールのバージョン管理に対応します。
イーサリアム L2 ルート: レイヤーの実行と決済、およびメインネットワークがファイナリティを保証します。 WCN は「人間の意思決定/エージェントの実行/PoB 記録」を階層化しており、エージェントはコンプライアンスと最終レビューの境界を置き換えません。
成熟した Web2 市場: Uber/Airbnb は、拡張する前に信頼とセキュリティの中間層を完成させます。フェーズ 2 では、単に機能を追加するのではなく、監査可能な自動化が完了します。

PoBの安定化配信: PoB スキーマのバージョン、変更ログ、SLA の確認、異議申し立てと再検討のプロセス。取引タイプ別の PoB テンプレートライブラリ。指標: 月をまたいだ PoB 構造の一貫性、レビューのバックログ日数、帰属に関する紛争率の傾向。

エージェントの正式化提供: 役割権限マトリックス、ツールホワイトリスト、セッション/タスクログ保持ポリシー、人間参加型トリガー条件。指標: エージェント出力の採用率、不正な傍受の数、ロールバックとパッチの数 (安定性エージェント)。

ノード方法論の製品化配信: 高価値ノードのプレイブック (チェックリスト、テンプレート、トレーニング資料) がシステムに入力されます。指標: 新しいノードが「一次認定」に達するまでにかかる時間、プレイブックの使用率、および出力の比較。

閉ループ密度配信: 単位時間内に同じネットワーク上で並行して進めることができる取引の数、およびリソース競合ルール。指標: 1 人/ノードあたりのディールスループット、ステージ停滞率 (どのカードが最も多いか)。

PoB v1.x 凍結期間中、重大な変更はガバナンス/バージョン番号を通じてのみリリースされ、移行ガイドが提供されます。
エージェント関連のインシデント (誤った紹介、データ漏洩、不正な操作) には、復元可能な事後分析パッチとルールパッチがあります。
複製可能: 新しいリージョンまたは新しい業種では、事前に設定されたプレイブックに基づいて 90 日以内にベースラインと同等のファネル指標 (運用によって定義) を達成します。

和解オブジェクト（誰が誰に支払うか、どのPoBに基づくか、紛争がどのように解決されるか）を紙とシステム内で調整できます。 ID と権限のモデルは、一時テーブルに依存せずにアカウンティングと監査をサポートするのに十分です。詳細については、12.4 を参照してください。

自動化された信頼の不一致エージェントはエラーの伝播を高速化します。 リリース: 階層自動化、シャドウモード、ランダム検査、レッドチーム化。

PoB のオーバーエンジニアリング基準が細かすぎるとビジネスが遅くなります。 リリース: 「最小限の監査可能なセット」を最終行とし、残りのフィールドは段階的に入力します。

組織はヒーローノードに依存していますスケーリングは依然として少数の人々に依存しています。 リリース: 必須の文書化と引き継ぎメカニズムが KPI に含まれています。

事前に大文字にするNFT/トークンはビジネスのリズムから外れています。 リリース: アセットレイヤーは、12.4 しきい値が満たされた後にのみプロジェクトを開始します。

安定した Deal and Proof サンプルがなければ、PoB 標準は空中の城となります。明確な手動プロセスがなければ、エージェントは混乱を増幅させるだけです。これは、L1 料金と輻輳が「実際に発生した」後、ロールアップが厳格な要件になるのと同じです。複雑さは実際の負荷によって決まるはずです。

第 2 フェーズの終わりには、人間とマシンのコラボレーションが同じルールセットの下でより検証可能な結果を安定的に生み出す方法と、発生したインシデントの責任を追及してパッチを適用できることを外部の世界に実証できるはずです。