Skip to main content

Architecture

The LCP works with the IBC Relayer, which relays messages and packets transmitted between two blockchains. Since the receiving chain does not directly perform light client verification, the relayer requests the LCP to verify the source chain. The Relayer then submits the verification results to the destination chain, which verifies it.

The following figure shows the architecture and packet-relay flow between the two chains using the LCP.

An overview of each component is as follows.

Components​

LCP Node​

The LCP Node is equipped with Intel SGX and executes the App and the LCP Enclave. It stores the App's plaintext data and LCP Enclave's encrypted data in the storage.

App​

App loads and initializes the LCP Enclave, and it interacts with Upstream and requests verification to ELC based on the request from Relayer.

App also interacts with AE for Remote Attestation and creates a Quote containing information on the LCP Enclave. By sending this Quote to an Attestation Service such as IAS, a Verifiable Quote can be obtained.

LCP Enclave​

LCP Enclave is an Enclave consisting of the Enclave light client, Enclave Manager, and handler modules. After being loaded at the startup of the App(the Host Application), the Handler processes requests from the App by routing and dispatching them to the appropriate module.

Enclave Light Client (ELC)​

ELC provides a light client that runs within Enclave; ELC supports light clients for multiple chains.

ELC verifies the upstream's commitment and proof given by Relayer through the App and generates a new commitment as a verification result. The relayer receives them from the App and submits them to the downstream, where the LCP client verifies them.

See here for detail.

Enclave Manager (EM)​

EM generates and manages the Enclave key which is to generate the ELC's proof of commitment. It also generates a Report containing the public key of the Enclave key using the Remote Attestation process for validating the Enclave.

Attestation Service​

Attestation Service is a service that provides remote attestation to enable remote parties to validate enclaves. IAS and Microsoft Azure Attestation (MAA) are such examples. ECDSA attestation is a method that does not require an external service. LCP initially supports IAS. In this document, Remote Attestation refers to IAS unless otherwise noted.

By verifying the signature of the Verifiable Quote obtained by the Attestation Service, the verifier confirms that the target Enclave correctly constructed the data contained in the Quote. The same goes for the validity of the Enclave key in the Quote. We describe the details of this process in RemoteAttestation.

Relayer​

Relayer exists between two communicating chains and interacts with the verifying chain and LCP Node to provide the necessary data to the chain. It is equivalent to the relayer in the IBC.

LCP Client​

LCP Client is an IBC client that verifies the commitment and proof of ELC. A chain that uses LCP to validate the target chain should use this client as an IBC client. An LCP client verifies the Verifiable Quote for LCP Enclave generated by App and obtains and stores the public Enclave key. The LCP client on the downstream uses the key to verify the commitment generated by the ELC for validating the upstream's commitment.

See here for detail.

Packet-relay flow​

Each step of a packet relay is as follows:

  1. First, a Relayer detects that chain A sent a packet to chain B.
  2. The relayer requests the App of the LCP Node to verify chain A.
  3. App sends VerifyPacketCommand to the LCP Enclave to verify the packet. The Handler in the enclave handles the command and requests the ELC to verify the packet.
  4. The ELC verifies the packet commitment with the light client corresponding to chain A and generates proof by signing the commitment with the Enclave key.
  5. Enclave returns the commitment and proof in step 4, and the App returns them to the relayer.
  6. The relayer submits the commitment and proof of step 5 to chain B, and the LCP client on chain B verifies them using the key.

Note that before relaying a packet, it is necessary to initialize the LCP client on the chain. We describe this initialization in LCP Client.