はじめに
Ethereumステーキングにおいて、Validatorはブロック提案や、他のブロックの正当性を承認する投票（Attestation）への署名を担います。同じValidatorが互いに矛盾する内容へ署名すると、Ethereumプロトコル上のスラッシング対象となり、ステークの一部没収とValidatorの強制退出につながります。(Ethereum.org)
スラッシングは、悪意のある行為だけで起きるものではありません。次のような運用上の事象も原因になります。
- 障害復旧時に旧環境と新環境が同時に起動する
- Validator Keyが複数のValidator Clientへ誤って割り当てられる
- 設定変更やソフトウェア不具合により、過去と競合する署名要求が生成される
Ethereumでは、同時期に多くのValidatorがスラッシュされると相関ペナルティが大きくなり得ます。(Ethereum.org, Kiln) そのため、発生確率を下げる対策に加え、事故が波及する範囲を抑える設計が欠かせません。
この設計で最も難しいのは、可用性と署名の安全性が衝突する場面です。署名を止めないために同じKeyを持つ環境を増やすほど、競合署名が成立する機会も増えます。
Validatorの一時的な停止は、機会損失や一部のペナルティにつながることがあります。しかし競合署名はスラッシングとValidatorの強制退出につながり、同時期に多数のValidatorへ波及した場合には影響がより深刻です。(Ethereum.org)
そのためOmakaseの基本方針は、可用性を回復するために署名の安全性を犠牲にしないことです。安全な署名状態を確認できない局面では、無理に署名を継続せず、制御された停止を選択します。
鍵のライフサイクルで防御を重ねる
Omakaseがこのリスクに対して採る戦略は、単一の対策に頼らないことです。変更統制、鍵アクセスの分離、署名履歴の照合、署名環境の排他制御、Signing Shard（内部の運用単位）による隔離、監視とインシデント対応を重ね、単一の障害や誤操作が大規模な事象へつながりにくい構造としています。
多層で考える理由は、個々の対策を万能視できないことです。
インフラ構成をコードとして管理し、変更をコード上の差分として記録・反映するInfrastructure as Codeは、意図しない構成変更を減らします。しかし、ソフトウェア不具合や権限設定の不備まで単独で防げるわけではありません。
Validator Clientのローカルな保護機能も、別の環境で同じKeyが動いた場合には相手側の署名履歴を把握できません。起動時の重複検知も、ネットワーク伝播や検知タイミングに左右されます。(Kiln)
この考え方を、Omakaseは鍵のライフサイクル全体に当てはめています。鍵の生成、保管、利用（署名）、運用という各段階に、独立した防御層を配置する設計です。
鍵の生成段階でも、Omakaseは人手による鍵の取り扱いを介さない運用を採っています。Validator鍵の生成は自動化されたプロセスで行われ、生成から保管に至るまで人が鍵材料へ直接触れる工程を挟みません。
保管段階ではアクセス制御されたKey Storeへ鍵を隔離し、利用段階では署名経路を一つの環境に限定したうえで、署名のたびに過去の履歴と照合します。そしてSigning Shardという単位で、影響範囲を限定する設計です。運用段階では、構成変更や異常を継続的に監視し、定義済みの手順で対応します。
ある防御層に問題が生じても、別の層が競合署名の成立を止めることを目指した設計です。
この各段階の防御が実際に働く場面は、通常運用時、障害・メンテナンス時、そして全段階に共通する統制の三つに分かれます。
通常運用時: 安全に署名しながら可用性を高める
通常運用時、Omakaseは署名の安全性を保ったまま可用性を確保します。安全に署名し続けるための三つの対策に加え、事故が起きた場合の影響を限定するリスク管理を、通常運用に組み込んでいます。
署名鍵をValidator Clientから分離する
OmakaseのValidator Clientは、Validator署名鍵を直接保持して署名するのではなく、外部署名コンポーネントであるWeb3Signerへ署名要求を送ります。
Validator署名鍵は、アクセス制御されたマネージドKey Storeに保管されています。通常の開発・運用権限からは、鍵の読み取り、書き換え、復号に関わる操作を分離し、署名処理に必要なサービスだけが利用できるように権限を限定します。
この分離には、二つの目的があります。第一に、Validator Clientや一般的な運用アカウントが秘密鍵へ直接触れる範囲を減らすこと。第二に、すべての署名要求をWeb3SignerとSlashing Protection DBを経由させ、署名判断を一か所で実施することです。
署名履歴に反する要求を拒否する
Web3Signerは、ブロック提案やAttestationに関する過去の署名履歴をPostgreSQLベースのSlashing Protection DBへ記録します。新しい署名要求を受けると、保存された履歴と照合し、競合する要求であれば署名を生成しません。
Web3Signerの公式仕様でも、複数のSignerが同じSlashing Protection DBへ接続する場合、データベースロックによって同一Keyへの競合署名を制御する仕組みが示されています。(Consensys Web3Signer)
このデータベースは、署名の安全性を支える基盤です。同時に、SignerとDBの間で発生する複数回の通信は署名レイテンシへも影響するため、Omakaseでは署名性能、接続状態、キュー遅延などを監視対象として扱います。
大規模なWeb3Signer運用に関する公開知見でも、SignerとDBを近接させ、処理キューとワーカースレッドを監視・調整すると遅延を抑えられると報告されています。(Kiln)
安全な冗長化で可用性を高める
Validator Node、Validator Client、署名関連コンポーネントは、複数の障害ドメインへ分けて配置します。これにより、一部のインフラ障害が直ちにサービス全体の停止へつながる可能性を下げます。
ただし、Validatorの冗長化は、一般的なWebサービスのActive-Active構成とは異なるものです。同じKeyを持つ署名主体を単純に二重化すると、可用性向上のための構成そのものがスラッシングリスクになります。
Omakaseでは、ノードや実行基盤は冗長化しつつ、署名権限は常に一つの環境へ限定することで、可用性と署名安全性を分けて設計しています。
Signing Shardで相関ペナルティの影響を限定する
Omakaseでは、Validatorの署名系をSigning Shardという単位に分離しています。
ここでいうSigning Shardは、Ethereumプロトコル上のshardingとは異なり、Omakaseが署名処理と障害影響を分離するために設ける内部の運用単位です。
各Signing Shardには、限定されたValidator Key群を割り当てます。それを担当するValidator Client、Signing Gate（署名を通してよいか判断するコンポーネント）、Web3Signer、Slashing Protection DBも、同じShardの中に割り当てます。
設計上、一つのValidator Public Keyは一つのSigning Shardにのみ所属しています。また、各Shardが保持するKey群には内部上限を設けます。これにより、特定のSigner、DB、Key Store、設定、デプロイに問題が生じた場合でも、影響がValidator全体へ一斉に波及しにくい構造としています。
これは単なるスケーラビリティ対策ではありません。Ethereumの相関ペナルティは、同時期に多数のValidatorがスラッシュされるほど影響が大きくなり得ます。そのため、Signing Shardは「事故を起こさない」ための予防策ではなく、「一つの事故を大きくしない」ためのリスク管理としてアーキテクチャへ組み込んでいます。(Ethereum.org)
障害・メンテナンス時: Signing Gateで遮断と排他制御
高可用性を目的としてPrimary環境とRecovery環境を用意する場合、最も避けなければならないのは、同じValidator Keyを持つ両環境が同時に署名することです。環境を切り替える瞬間こそ、競合署名が成立するリスクが高まります。そのためOmakaseは、障害時に何よりも早く別環境で署名を再開するのではなく、まず署名の排他性を確立することを優先します。
Omakaseでは、Validator ClientとWeb3Signerの間にSigning Gateを配置しています。Signing Gateは、署名環境とは独立したControl Store（どちらの環境が署名してよいかを記録する状態ストア）の状態を参照し、その署名要求をWeb3Signerへ通してよいかを判断します。
制御状態は、次の三つです。
| 状態 | 署名可能な環境 | 役割 |
|---|---|---|
| PRIMARY | Primary環境のみ | 通常運用 |
| PAUSED | なし | 両環境の署名を停止 |
| RECOVERY | Recovery環境のみ | 障害復旧時の運用 |
Primary環境からRecovery環境へ切り替える際は、直接遷移せず、必ずPAUSEDを経由します。直接切り替えると、移行の過程で両環境が署名できる瞬間を許す余地が残るためです。PAUSEDでまず両環境から署名権限を取り上げ、その後にRecovery環境へ署名権限を付与します。
PAUSEDは単なる停止状態ではありません。旧環境と新環境のどちらにも署名させないことで、安全な切替を行うための明示的なセキュリティ状態です。
Primary環境が障害から復旧しても、Control Storeの状態がRECOVERYである限り、Primary側のSigning Gateは署名要求を通しません。
この仕組みは、複数環境からの同時署名を避けるための排他制御を担います。一方、Web3SignerとSlashing Protection DBは、個々の署名要求を過去の履歴と照合する制御です。Omakaseは両者を代替関係とは考えず、異なる失敗モードを受け止める独立した防御層として組み合わせています。
この考え方は、可用性を軽視するものではありません。可用性を回復するプロセス自体が、新たなスラッシングリスクを生まないようにするための設計です。
フェーズ横断の統制
最小権限やInfrastructure as Codeのような統制、そして継続監視は、鍵のライフサイクルの特定の段階に閉じず、生成から運用までの全段階に横断的に効く層です。
インフラの障害がなくても、人の操作一つでスラッシングリスクは生まれます。Keyの重複割当や誤った設定変更も、競合署名につながり得る操作です。(Cubist)
Omakaseでは、本番環境へのアクセスと変更を次の原則で管理します。
最小権限と多要素認証
開発者・運用者のアクセスは一元的なIdentity管理の下に置き、多要素認証を求めています。各ロールには業務上必要な権限だけを付与し、Validator署名鍵を格納するKey Storeへの直接アクセスや、鍵の復号に関わる権限を通常の開発者権限から分離します。
Infrastructure as Code
署名系を含む重要なインフラ構成の変更は、管理画面やコマンドによる手動操作ではなく、Infrastructure as Codeを通じて反映します。これにより、誰が何をいつ変更したかが、コードの差分として明らかです。
複数人による承認
本番変更には、変更内容をコードの差分としてレビュー依頼するPull Requestの提出と、他の担当者による承認を必要とします。承認済みの変更は自動化されたデプロイ経路から反映し、誰が、何を、なぜ変更したかを追跡できるようにします。
これらの統制は、人が常にミスをしないことを前提にするのではなく、危険な変更を一人の判断だけで完結しにくくするためのものです。
継続監視とインシデント対応
アーキテクチャによる予防策に加え、OmakaseはValidator Nodeと署名関連コンポーネントを継続的に監視します。
主な監視対象は、次のとおりです。
- ノードとValidator Clientの稼働状態
- Attestationやブロック提案のMiss傾向
- 署名レイテンシと処理キュー
- Web3SignerとSlashing Protection DBの接続・性能
- Signing Gateの制御状態
- インフラ構成と権限に関する重要な変更
- その他、Validator運用に影響する異常
重要な異常を検知した場合は、詳細情報を添えて運用チームへ通知します。監視は競合署名を直接防ぐ制御ではありませんが、性能低下、設定異常、障害の長期化を早期に把握し、影響が拡大する前に対応するための防御層です。
想定事象と防御層
| 想定事象 | 主に機能する防御層 | 設計上の狙い |
|---|---|---|
| 鍵の生成・保管の過程で人為的な取り扱いミスが混入する | 自動化された鍵生成プロセス / 最小権限 | 人が鍵材料へ直接触れる工程を減らす |
| Recovery環境が誤って起動する | Signing Gate / Control Store | 署名可能な環境を一つに限定する |
| re-org（チェーンの再編成）や再起動後に競合する署名要求が生成される | Web3Signer / Slashing Protection DB | 過去の署名履歴に反する要求を拒否する |
| 特定のSigner、DB、設定に問題が発生する | Signing Shard | 影響範囲を限定されたKey群へ閉じ込める |
| 本番構成が意図せず変更される | 最小権限 / Infrastructure as Code / 複数人承認 | 単独の誤操作や無承認変更を成立しにくくする |
| 署名性能やノード状態が悪化する | 継続監視 / アラート / Runbook（対応手順書） | 早期検知と制御された対応につなげる |
リスクはゼロにはならない
未知のソフトウェア不具合、プロトコル変更、依存コンポーネントの脆弱性、運用手順からの逸脱など、すべてのリスクを完全に排除することはできません。
Omakaseが採るこの戦略が目指すのは、スラッシングが発生しないことを保証することではなく、次の四点です。
- 競合署名が成立する条件を減らす
- 一つの制御が機能しない場合に別の制御で補う
- 障害や侵害が波及する範囲を限定する
- 異常を早期に検知し、制御された手順で対応する
Omakaseは、構成・権限・運用・監視を継続的に見直し、Ethereumと周辺ソフトウェアの変化に合わせて防御層を更新していきます。
まとめ
運用に起因するスラッシングは、障害復旧時の二重起動やKeyの誤割当といった、ありふれた単一の事象から始まります。Omakaseの戦略は、可用性より署名の安全性を優先するという方針のもと、鍵の生成から保管・利用・運用までのライフサイクル全体に防御を重ねることです。この防御が働く場面は、通常運用時・障害・メンテナンス時・フェーズ横断の統制の三つです。
一つの失敗が次の失敗を呼ばない運用を、こうした性質の異なる防御の積み重ねで続けています。
本記事は、Omakaseの設計思想と公開可能な範囲のアーキテクチャを説明するものです。特定のクラウド製品、内部のKey割当上限、セキュリティ閾値などは抽象化しています。本記事は、スラッシングその他の損失が発生しないことを保証するものではありません。参考資料は一般的な技術的背景と設計原則を示すために参照したものであり、各社との提携・認証・同一性を示すものではありません。