Skip to main content

Security Model

LCP serves as a substitute for blockchain light client verification functionality and currently utilizes Intel SGX, an implementation of a TEE (Trusted Execution Environment), to ensure execution integrity. This section describes the security model of LCP, explaining the assumptions the system must satisfy and its resilience against attacks.

Security Assumptions​

The security of LCP is based on the following assumptions:

  • TEE Security: LCP relies on the security assumptions of the TEE. The TEE provides a secure execution environment, preventing unauthorized manipulation and incorrect reading of data within the Enclave. Verifiers are aware of the legitimate Enclave's MRENCLAVE and can verify that the Enclave is in a correct state through Remote Attestation.
  • Availability and Consensus Correctness of Blockchains: The two blockchains involved in interoperability must satisfy their respective availability and consensus correctness.
  • Existence of Honest LCP Node: Regarding liveness, it is assumed that there is at least one honest LCP node operator.

Safety and Liveness Guarantees​

Based on the above assumptions, LCP guarantees safety and liveness even against the following types of attacks:

  • Enclave Tampering: Verifiers initialized with the correct MRENCLAVE of the Enclave can confirm that commitments were generated by the expected Enclave by verifying the Remote Attestation and commitments from the ELC. This prevents attacks by malicious Enclaves.
  • Control of Node's OS and Network Stack: Even if an attacker can control the OS or network stack of an LCP node, the safety of LCP is ensured. All verification processes are protected by the TEE, so interference at the OS or network layer does not compromise the integrity of the verification. Moreover, this can be verified externally (i.e., by the LCP Client) using Remote Attestation.
  • State Rewriting, Rollback, and Loss of Nodes: Even if an attacker can arbitrarily rewrite, roll back, or erase the state within an LCP node, thereby corrupting the node, LCP continues to operate correctly. This is because the state of each LCP node can be recovered based on data from the interoperating blockchains, meaning it does not depend on the availability of a specific LCP node. Furthermore, verifiers can ensure safety by verifying the commitments output by ELC. They reject any commitments that include State IDs based on improperly constructed states.

State Recovery Protocol​

LCP does not depend on the availability of a specific node and allows an honest relayer to set up their own LCP node again. This is achieved through the following procedure (assuming an LCP node including the ELC for the upstream chain has been corrupted):

  1. The operator sets up a new LCP node.
  2. Through the relayer, obtain the ClientState and ConsensusState of the LCP Client on the downstream chain.
  3. The relayer verifies that each parameter of the ClientState obtained in step 2 matches its own configuration. If they do not match, the relayer retrieves the emitted state from the transaction of the first updateClient of the LCP Client and reconstructs the ClientState based on it.
  4. The relayer generates the ELC's ConsensusState based on the latest_height from the ClientState obtained in step 2. This process depends on the implementation of the ELC but generally involves obtaining the header corresponding to the height from the target chain and generating the ConsensusState based on it.
  5. The relayer requests the new LCP node to initialize the ELC withbased on the ClientState and ConsensusState from steps 3 and 4.

Through the above procedure, the relayer can perform update_client to a new height based on the latest_height of the LCP Client.

This recovery protocol guarantees the liveness of LCP, ensuring that the system continues to operate correctly even if an attacker corrupts a node.