Consensysが発表した内容
Consensysは11月2日、独立運営されるinstitutional ledger間でtransactionをrouteし、調整し、追跡するsupported technology stack「Sovereign Network Interoperability」を発表しました。Bank、custodian、asset manager、financial market infrastructureを対象とし、collateral mobility、securities settlement、wholesaleおよびcross-currency payment、fund servicingのworkflowを想定しています。
Consensysはこの設計をbridgelessと説明しています。Assetはnative ledgerに記録されたまま、cross-ledgerのstateとexecutionをcryptographicに検証します。Cross Ledger Interoperability Protocolを中心に、Ethereum Economic Zone standard、IBC、その他protocolへの対応を計画しています。同社によるとEVM-based chainは現在利用可能で、Canton接続が次に続きます。
またConsensysは、network構成に応じてsynchronousまたはasynchronousに、全supported connectionでatomic settlementを提供すると説明しています。Recovery guarantee、hosting、key、administration、monitoring、incident responsibilityはdeploymentごとに割り当てるとしています。ここまではConsensysが公表したproduct claimとavailability statementであり、以下はIneezaの本番運用分析です。
「Atomic」には明示的なState Machineが必要
Cross-ledger atomicityは単一の普遍的mechanismではありません。Synchronous transaction、compensationを伴うasynchronous protocol、運用によるrecovery processでは、不確実な期間が異なります。その間、一方のledgerがlockまたはprepared stateを受理していても、もう一方は停止、reorganization、policy approval待ちの可能性があります。
Ineezaの分析: Routeごとにatomicityをstate machineとして定義し、precondition、irreversible point、timeout、abort権限、terminal outcomeへ名前を付けるべきです。各transitionでどのledger stateがauthoritativeかを記録し、protocol completionとlegal settlement finality、cash availability、downstream books and recordsを分けます。Product levelの約束を、asset pair、network pair、workflowごとのtest可能なcontractへ変える必要があります。
Proofが検証するのはStateでありBusiness Authorityではない
Assetをnative ledgerに残すことで、bridge-issued representationが持ち込むcustodyとliquidityのriskを回避できます。Cryptographic verificationはremote stateに関するclaimを追加intermediaryへ依存する度合いを下げられます。しかし、instructionが認可済みか、assetがeligibleか、counterpartyが最新controlを通過したか、economic termが正しいかは証明しません。
Ineezaの分析: すべてのproofをinitiating institution、legal entity、account、asset identifier、amount、route、policy version、approval evidence、expiryへbindすべきです。Cross-ledger assertionが正しく証明されても、verification software、ledger consensus、administrator key、contract upgrade、data inputはtrust dependencyとして残ります。Proof verificationをauthorization chainの一つのcontrolとして扱い、それ自体をauthorizationにしてはいけません。
Route Selectionは規制対象のDecision Logicになる
発表されたstackは、institutionが承認したrequirementからeligible routeを選び、adapterとprotocol releaseを維持します。Bespoke integrationは減りますが、route configurationとsoftware-version compatibilityへ重要なdecision logicが集中します。
Ineezaの分析: Route eligibilityをdeterministic、versioned、explainableにします。Evidenceには検討した全candidate route、alternativeを除外したpolicy、protocolとadapter version、feeとlatencyのbound、verification method、最終的に選んだrouteを残すべきです。これらのinput変更にはcontrolled rollout、counterparty revalidation、rollback criteria、pending transactionを使ったreplay可能なtestが必要です。
PrivacyはCoordination Layer全体で維持する
Consensysは、参加institutionが各ledger内のdisclosureを決め、proof-based approachによりsovereign dataがexternal participantへ漏れないと説明しています。一方、transaction payloadを秘匿しても、routing request、identifier、timing、failure response、monitoring、support recordからsensitive metadataが現れる可能性があります。
Ineezaの分析: Operatorとincident responderを含む各hopで、開示する最小dataを文書化すべきです。可能な限りpairwise identifierを使い、business dataとprotocol telemetryを分離し、retentionとregional processing ruleを強制し、failure pathからの漏えいをtestします。Privacy assuranceはproofやledger payloadだけでなく、log、trace、support bundle、recovery toolingも対象にする必要があります。
RecoveryはSettlement Correctnessの一部である
Product Q&Aでは、選択したflowごとにrecovery time objective、recovery point objective、backupとrestore procedure、責任主体を合意するとしています。Cross-ledger incidentでは、各participantが何をcommit済みか把握せずに一つのcomponentを再起動できないため、これは重要です。
Ineezaの分析: Recoveryはinstruction、policy decision、proof、route、各ledger transaction、downstream reconciliationを結ぶdurable evidenceから始めます。Operatorには安全なresume、abort、compensate procedure、exceptional actionのseparation of duties、network停止、incompatible upgrade、stale proof、completion不明を想定したdrillが必要です。Automatic retryが二つ目のeconomic instructionを作ってはいけません。
Ineezaの見解
このlaunchが重要なのは、institutional tokenizationが単一のshared execution environmentではなく、多数のcontrolled ledgerを生み出しているためです。維持管理されるinteroperability stackは、それらを接続する運用負荷を下げられます。本番で問うべきなのはassetがbridgeを渡るかではなく、各routeにauthority、verification、privacy、finality、recoveryの正確なoperating contractがあるかです。Cross-ledger coordinationを一つのsettled transactionとして扱う前に、workflowとnetwork pairごとに保証をqualificationすべきです。