発表された内容
RedStoneは10月8日、Ethereum mainnetでSanctions Oracleを公開しました。同社によると、このcontractはOpenSanctionsを通じて463の公的sourceから集約したwallet designationを公開し、単一addressとbatchのcheck、最終更新時刻のonchain記録を提供します。review済み更新は週次で行い、contract変更は地理的に分散した4-of-6 multisigが管理します。ここまではRedStoneが公表した設計と運用上の主張であり、以下はIneezaの本番運用分析です。
contractは既存のChainalysis oracleで使われるisSanctioned(address) interfaceを維持し、areSanctioned(address[])とgetLastUpdateBlockTimestamp()を追加します。RedStoneのdocumentationは、list ageが定義済み上限を超えたtransactionを拒否する実装例を示しています。検証済みEthereum addressはtransparent upgradeable proxyであり、addressの固定は連携点を安定させますが、背後のimplementationとpolicyが不変であることまでは保証しません。
鮮度は実行可能なfailure policyにする
RedStoneは、OFACが2026年5月20日に追加した6つのEthereum addressが、同社の9月の調査時点でもChainalysis oracleに含まれていなかったと報告しています。米財務省のreleaseでも、この6 addressを独立して確認できます。この例が運用上重要なのは、lookupが技術的に成功しても古い回答を返し得るためです。
Ineezaの分析: 利用するcontractは許容できるlist ageの上限を定義し、timestampがない、過去へ戻る、または上限を超える場合にfail closedにすべきです。運用側には期限前のalert、緊急時の判断経路、検証済みの復旧手順も必要です。これらがなければ、updater障害が暗黙のscreening不足かprotocolの無期限停止になり、incident発生時に偶然の判断へ委ねられます。
address判定は対象者の特定ではない
oracleは渡されたaddressに対してbinary resultを返します。RedStoneのdocumentationも、msg.senderは実際のdepositorやbeneficiaryではなく、routerや別contractの場合があると警告しています。一方、OpenSanctionsはconsolidated sanctions dataを各国と国際機関が指定したentityの集合として説明しています。entityとblockchain addressの対応付けは、それより狭い派生controlです。
Ineezaの分析: protocolはactionごとにsender、recipient、beneficiary、owner、operator、fee payer、withdrawal address、delegated accountのどれをscreeningするか定義する必要があります。proxy、smart account、bridge、mixer、address rotation、新たなattributionは、直近callerが対象者を表すという前提を崩します。onchain predicateは、identity、transaction monitoring、escalation、法務reviewを含む広いprocess内の決定的なexecution gateとして扱うべきです。
interface互換でも移行riskは消えない
RedStoneはChainalysis contractからの移行をaddress constantの変更として説明します。interface互換はcode変更を減らしますが、置き換えによってlist source、更新governance、cadence、contract管理、revertするtransactionの集合も変わり得ます。
Ineezaの分析: teamは過去およびpending transactionを両oracleで再実行し、すべての結果差分を説明し、新しいlist policyをenforcement前に承認すべきです。rollout証跡にはchain、proxyとimplementation address、adminとmultisig設定、code hash、source snapshot、更新timestamp、test結果、activation block、rollback経路を結び付けます。settlement時に判定集合の変化を初めて知るより、canaryまたはshadow期間を設ける方が安全です。
upgrade権限もcompliance boundaryに含まれる
公開されたEthereum addressはTransparentUpgradeableProxyで、implementationはEtherscan上で別に確認できます。RedStoneはcontract変更に分散multisigの承認が必要だと説明しています。single keyより強い設計ですが、利用側はdata更新経路とsoftware upgrade経路の両方へ依存します。
Ineezaの分析: monitoringはproxy admin変更、implementation upgrade、signer rotation、quorum変更、想定外のupdate caller、timestampの進行、return valueの意味変更を対象にすべきです。高額を扱うprotocolは、未reviewのimplementation変更時にtransactionを停止するか、最後に承認したversionを維持するか、別のscreening経路へ切り替えるかを事前に決める必要があります。contract addressだけでは完全なversion identifierになりません。
Ineezaの見解
RedStoneのreleaseは、制裁dataの鮮度をoffchainの前提にせず、transaction execution内で観測・強制できるようにした点で重要です。安全な導入にはoracleをversion管理されたcompliance dependencyとして扱い、すべての関係者をscreeningし、明示的なstaleness policyに従ってfailureを処理し、proxy upgradeとlist updateを分けて統制し、判断証跡を保存し、誤判定対応とupdater障害の両方を訓練する必要があります。