発表された内容
Rippleは10月5日、SaaSとon-premises deployment向けのlong-term support releaseとしてCustody 1.43を公開しました。このreleaseはCanton Network、Circle Arc、Suiへの対応、Ethereum EIP-7702 delegation、notaryのhot failoverと選択可能なanti-rewind mode、Bitcoin系ledgerでのaddress単位のmanifest署名を追加します。1.34から更新する顧客向けに、short-term release 1.35から1.42で導入した動作とAPIの変更も含みます。
Rippleによると、on-premises deploymentが後続versionへ進む際、1.43を飛ばすことはできません。未完了のaccounting migrationは1.43上で実行し、phase 1をphase 2より先に完了する必要があります。phase 2ではEVM、Solana、Stellar、TRON、XRPLの処理を、書き直されたUnified Indexer ServiceであるUIS v2へ移します。ここまではRippleが公表した機能と更新要件であり、以下はIneezaの本番運用分析です。
更新は金融状態の遷移になる
Ineezaの分析: balance tracking、transaction preparation、nonceまたはsequenceの予約、broadcast、confirmation tracking、reorg handlingを変えるcustody更新は、単なるsoftware rolloutではありません。どの資金が存在し、transferがlifecycleのどこにあるかを判定する仕組みを変えます。移行計画では、softwareとchartのversion、有効なledger、最後に処理したblock、pending intent、予約済みnonce、account balance、reconciliation totalを、cutover直前と直後の署名済み状態境界として定義すべきです。
release noteによるとUIS v2 migrationは一度だけ実行され、対象networkは同時に移す必要があります。migration後に切り替えたnetworkは、tracked addressが移行されないまま稼働する可能性があります。したがって部分rolloutは、一時的な互換性問題ではなくdata completenessのriskです。稼働中のsystemから設定済みnetworkを棚卸しし、migration manifestと照合し、両方が一致するまで完了扱いにしてはいけません。
replay windowには明示的な復旧判断が必要
Ineezaの分析: Rippleは、UIS v2が各ledgerの最後に処理したblockからeventをreplayする一方、そのblockが24時間より古い場合はchain tipから開始し、間のeventをreplayしないと説明しています。maintenance windowには各ledgerの鮮度を測るgateと、gapがある場合の判断手順が必要です。「serviceが起動した」ことはcustody recordの完全性を証明しません。
trafficを再開する前に、onchain balance、内部position、pendingとfailed transaction、fee movement、sequence stateを、独立して保存したcheckpointと照合します。復旧試験では、cutoverがreplay windowを超えた場合、検証中にledgerが利用できない場合、一部networkが進んだ後のrollbackを扱うべきです。承認証跡はfinance、security、auditの各teamが後から判断を再現できる形で保存する必要があります。
delegationは永続するwallet権限を作る
RippleのEIP-7702対応では、Ethereum accountがdelegationへ署名し、別の資金を持つsponsorがそれをbroadcastしてdelegationのgasを支払えます。Rippleは、委任先contractがrevocationまでaccountを完全に制御し、delegationは自動失効しないと警告しています。sponsorが支払うのはdelegation transactionのgasだけで、この仕組みはRipple Custody Gas Stationとは別です。
Ineezaの分析: delegationの承認にはaccount、対象code address、検証済みcode hash、許可するnetwork、業務目的、予定するrevocationを結び付けるべきです。upgradeable codeは同じaddressの背後で変わるため、addressだけのcontract allowlistでは不十分です。監視ではdelegationを継続中の権限として扱い、予期しないcodeやimplementationの変更を検知し、運用policyが権限削除済みとみなす前にonchainでrevocationを証明する必要があります。
可用性と完全性は一つのpolicy選択である
RippleはnotaryにSTRICT、BALANCED、DISABLEDのanti-rewind modeも導入しました。STRICTは従来の動作を維持しfailoverを許可しません。BALANCEDは記録のないcollectionを受け入れ、競合するものを拒否します。DISABLEDはanti-rewind checkを行いません。BALANCEDとDISABLEDでは、稼働中のnotaryが設定時間応答しない場合、standby notaryが引き継げます。設定できる時間は10分以上です。
Ineezaの分析: この設定は一般的なhigh availabilityのtoggleではなくsecurity postureです。選択したmodeを正当化するthreat modelと復旧証跡を文書化し、すべてのfailoverとmode変更を警告し、独立承認されたintentによって変更を制限すべきです。disaster recovery試験では、実際の障害後に処理を再開できることと、復元済みまたは競合する状態が第二のhistoryを暗黙に認可しないことの両方を検証する必要があります。
Ineezaの見解
Ripple Custody 1.43は、一つのLTS境界に必須のaccounting migration、ledger対応の拡大、永続するsmart contract権限、完全性と可用性を選ぶ設定を集約した点で重要です。安全な導入には、rolloutをversion管理された金融状態の遷移として扱うことが必要です。移行前の完全な証跡を確立し、network集合を不可分にし、replay後に照合し、委任権限を拘束・監視し、本番と同じpolicyでnotary復旧を検証することが重要です。