Security Model
LCPは、ブロックチェーンのLight Clientの検証機能を代替する役割を持ち、現在TEE（Trusted Execution Environment）の実装であるIntel SGXを利用して実行の完全性を保証する。本セクションでは、LCPのセキュリティモデルについて記述し、システムが満たすべき仮定と、攻撃に対する耐性について説明する。
Security Assumptions
LCPのセキュリティは以下の仮定に基づいている。
- TEEのセキュリティ：LCPは、TEEのセキュリティに対する仮定を前提としている。TEEは、安全な実行環境を提供し、外部からの不正な操作やEnclave内のデータの不正な読み取りを防ぐ。また、検証者は正当なEnclaveのMRENCLAVEを知っており、Remote AttestationによりそのEnclaveが正しい状態であることを検証可能である。
- ブロックチェーンの可用性とコンセンサスの正確性：相互運用を行う2つのブロックチェーンは、それぞれの可用性（availability）とコンセンサスの正しさを満たす必要がある。
- 正直なLCPノードの存在：Livenessに関しては、少なくとも1人の正直なLCPノードオペレーターの存在を仮定している。
Safety and Liveness Guarantees
LCPは、上記の仮定を前提に以下のような攻撃に対しても安全性とlivenessを保証する。
- Enclaveの改ざん: 正しいEnclaveのMRENCLAVEで初期化された検証者は、Remote AttestationやELCのコミットメントを検証することで、期待されるEnclaveが生成したコミットメントであることを確認できる。これにより、悪意あるEnclaveによる攻撃を防ぐことができる。
- ノードのOSとネットワークスタックの制御: 攻撃者がLCPノードのOSやネットワークスタックを制御できる場合でも、LCPの安全性は保証される。すべての検証処理はTEEによって保護され、攻撃者がOSやネットワーク層に干渉しても、検証の完全性が損なわれることはない。また、これはリモートアテステーションを用いて外部(i.e., LCP Client)から検証可能である。
- ノードの状態の書き換え、巻き戻し、消失: 攻撃者がLCPノードにおいて、状態の書き換え、巻き戻し、消失を任意に実行可能で、ノードを破損させることができる場合でも、LCPは依然として正しく動作する。これは、各LCPノードの状態は相互運用するブロックチェーン上のデータに基づいて回復可能であるためであり、特定のLCPノードの可用性に依存しないことを意味する。また、検証者がELCが出力したコミットメントの検証により、不正に構築された状態に基づいたState IDを含むコミットメントを拒否することで安全性についても保証される。
State Recovery Protocol
LCPは、特定のノードの可用性に依存せず、誠実なリレイヤーが自身のLCPノードを再びセットアップすることが可能である。これは、以下のような手続きによって達成される。(Upstream chainのELCを含むLCPノードが破損した場合を想定する)
- オペレータは新しいLCPノードをセットアップする
- Relayerを通じてDownstream chain上のLCP ClientのclientState, consensusStateを取得する
- Relayerは2で得られたclientStateの各パラメータが自身のconfigと一致するか検証する。一致しない場合は、LCP Clientの最初のupdateClient時のトランザクションからemitted stateを取得し、それを元にclientStateを再構築する
- Relayerは2で得られたclientStateのlatest heightを元にELCのConsensusStateを生成する。これは、ELCの実装に依存するプロセスであるが、一般的には対象chainの高さに対応するheaderを取得し、それを元にConsensusStateを生成することが可能である
- Relayerは新しいLCPノードに対して、3,4のClientState, ConsensusStateを元にELCの初期化を要求する
上記の手続きにより、RelayerはLCP Clientのlatest_heightを元に新しい高さへのupdate_clientが可能となる。
この復旧プロトコルがLCPのlivenessを保証しており、攻撃者がノードを破損させた場合でも、システムが正常に動作することを保証する。