8.4 · 検証プロセス
起こったこと≠確認されたこと。検証チェーンが完了した後でのみ、結果が PoB 台帳に入力され、長期的な価値の入力となります。
オンチェーンのコンセンサスで確認されるのは、トランザクションのシーケンスと状態の遷移です。 PoBが確認しているのは、「このことがビジネスの世界で主張されているとおりに起こったかどうか」ということだ。検証プロセスでは、主観的なナラティブが監査可能なワークフローに圧縮されます。つまり、資料の完全性、時間の一貫性、帰属の自己一貫性、除外ルールとの比較 (8.3) です。
検証までの 5 つのステップ (ワークフロー ビュー)
①イベント投稿
最終状態の 一意のイベント番号を生成し、取引、タスク、関連ノードおよびステートメント タイプ (財務/サービス/成長など) をバインドします。提出には立証責任がかかります。資料の不足点は提出者が期限内に埋める必要があります。
② 証拠パッケージをアップロードする
テンプレートに従って、契約書、オンチェーン参照、銀行/エスクローパス（コンプライアンス解除）、電子メール/議事録、受諾書などを提出します。 GIPS の類似: データは、独立した当事者が単に「出願人を信頼する」のではなく、合理的な努力を払って結論を検討できるようにするのに十分である必要があります。
③ レビューキュー
監査人は次をチェックします: 信頼性 (第三者またはチェーン上と一致しているかどうか)、完全性 (最終状態がクローズされているかどうか)、時間シーケンス (過去のものであるかどうか)、帰属境界 (8.5 と矛盾するかどうか)、除外ルール (8.3 に該当するかどうか)。マルチシグネチャ、ローテーション、またはサンプリング監査と組み合わせることができます。
④結論生成
可決 / 補足 / 拒否 / 紛争エスカレーション。際限のない遅延を防ぐために、補足書類の作成には頻度と期限を設ける必要があります。 「沈黙を通り過ぎる」ことを避けるために、異議申し立ての記録は紛争のために保存されるべきです。
⑤ 口座への申告
合格後、PoB イベント台帳 (結論ハッシュ、キー メタデータ、バージョンを含む) が書き込まれます。この記録は監査されたパフォーマンス エントリに似ており、その後の和解、評判、再検証のアンカーとして機能します。
PoW との比較: マイナーが証明するのは 計算能力です。 PoB 監査で証明されるのは、資料と事実の一貫性です。 PoA との比較: PoA は 認証者の ID を信頼します。 PoB には依然として 証拠パッケージ が必要であり、査読者の ID が資料に置き換わることはありません。
Proof Desk: ネットワーク ディスクではなく検証センター
証拠を集める構造化フィールド + 添付ファイルのバージョン。チャット ウィンドウ内のファイルが失われて監査できなくなることを避けます。
マネジメントレビューキューの優先順位、SLA、二重レビューまたはランダム検査ルールを管理できます。
論争の余地を残す異議と裁定の理由は、その後のレビューとルールの反復を容易にするために残されます。
結論を出力する最終状態を明確にする: PoB に参加するかどうか。失敗した場合、長期的な価値配布セマンティクスには入らないものとします。
不正行為対策がプロセスレベルで行われる場所
- クロスチェック: オンチェーン時間、サードパーティの電子メール ドメイン名、契約番号は公開情報と一致していますか。
- 相互に排他的なイベント: 裁定によって分割されない限り、同じ資金調達ラウンドおよび同じ受け入れターゲットに対して許可される アーカイブ ドミナント チェーンは 1 つだけです。
- 冷却と周波数: 異常に高い周波数、テンプレート化された材料は、手動またはアルゴリズム支援によるレビューをトリガーします。
この検証プロセスにより、WCN は「誰が最も大きな声を持っているのか」から「誰が最も厳しい資料を持っているのか」へと押し上げられました。この手順を行わないと、PoB はオフチェーンの Excel 記録クレジットと何ら変わりがなく、改ざんされやすくなります。