ブロックチェーンとデジタルアセットシステムのための本番インフラ

有効な署名を生成できる者が、資産を支配します。したがってカストディのアーキテクチャは、3つの問いに集約されます。鍵素材がどこに存在するか、誰が、あるいは何が署名を起動できるか、そして署名が生成される前にどのようなチェックが走るかです。健全な設計では、一人の人間、一台のサーバー、一つの認証情報だけでは資金を動かせないことが保証されます。

主な3つの仕組みは、制御がどこに置かれるかが異なります。HSMは、鍵全体を耐タンパー性のあるハードウェアの中に保持し、HSM自身のポリシーでアクセスを制御します。MPCは、鍵を別々の当事者が保持するシェアに分割し、鍵を一度も復元することなく共同で署名を計算します。マルチシグは、クォーラムをオンチェーンに移し、複数の独立した署名を要求するコントラクトに持たせます。これらはしばしば組み合わせて使われます。たとえば、運用ウォレットにはHSMで保護したMPCシェアを、トレジャリーにはマルチシグコントラクトを使う、といった構成です。

仕組みの周囲にはポリシー層があり、現実のインシデントの大半は、ここで防がれるか、通ってしまうかが決まります。出金上限、ベロシティチェック、送金先の許可リスト、高額送金への時間遅延、起案者と承認者の職務分掌、改ざんを検知できる監査ログが、侵害されたアプリケーションサーバーや内部者に実際に何ができるかを決めます。復旧も同じく重要です。鍵シェアのバックアップ、セレモニーの手順、テスト済みの復元は、最初から設計の一部です。

ほぼすべてのブロックチェーンプロダクトは、オンチェーンのアクティビティを映すオフチェーンの記録を持っています。顧客残高、注文の状態、トークンの名簿、ポジションなどです。チェーンとデータベースを一つのアトミックなトランザクションで更新することはできないため、整合性は設計によって作り込む必要があります。標準的なパターンは、決済についてはチェーンを信頼できる唯一の情報源とし、ファイナリティに達したイベントから内部状態を導き、すべてのハンドラーを冪等にしてリプレイが無害になるようにすることです。

外向きの操作では、システムはまずアウトボックスを使って意図をデータベースに記録し、その後トランザクションを送信し、ファイナリティまで追跡してから操作を完了とします。内向きのイベントでは、インデクサーは必要な承認の深さまで待ち、トランザクションハッシュとログインデックスをキーとしてイベントを厳密に一度だけ適用し、リオーグに対しては、孤立したブロックから派生したものをすべて取り消すことで対処します。定期的な照合処理が内部の合計とオンチェーンの残高を比較し、差異があればアラートを上げます。

パブリックチェーンにデプロイされたコントラクトは、ネットワーク上のすべての参加者にさらされ、書かれたとおりに実行され、変更できない場合もあります。そのため、保守的なエンジニアリングプロセスが正当化されます。オンチェーンのロジックを最小限にし、十分にレビューされたライブラリコードを使い、ファジングとインバリアントを含む網羅的なテストを行い、静的解析を実施し、デプロイ前に独立した監査を受けます。アップグレード可能にするかどうかは意図をもって選択します。アップグレード用の鍵はそれ自体がリスクであり、タイムロックと複数当事者による管理が必要になるためです。

より大きな設計上の問いは、そもそも何をオンチェーンに置くべきかです。互いに信頼していない当事者の間で、共有され検証可能な形での強制が必要なロジックは、コントラクトに置きます。プライバシー、重い計算、頻繁な変更、大量のデータを必要とするロジックはオフチェーンに置き、コミットメントや結果だけをチェーンにアンカリングします。この線引きを適切に行うことで、コスト、攻撃対象領域、そして二度と修正できないコードの量を減らせます。