Skip to main content

Enclave Light Client (ELC)

ELC is a light client implemented within the LCP Enclave. Its two main roles are:

  • To manage the light client that implements ICS-02
  • To generate commitment and proof indicating the results of light client verification

ELC verifies the state update by the Header of the upstream and the commitment proof after initialization through the App. As a result of these verifications, ELC generates two corresponding commitments: UpdateClient Commitment and State Commitment. These commitments are signed with the Enclave key and are considered proofs. An LCP client can verify these commitments with the public Enclave key.

UpdateClient Commitment

UpdateClient Commitment is a commitment that indicates the transition state of the ELC client by “initializeClient” and “updateClient”. Downstream tracks Upstream's state by verifying this commitment using LCP Client.

UpdateClient commitment includes the state of ELC's Client when its Header is verified, and the state after the Header is applied. Each state of the client is represented by a StateID, described below. The definition is as follows:

pub struct UpdateClientCommitment {
pub prev_state_id: Option<StateID>,
pub new_state_id: StateID,
pub new_state: Option<Vec<u8>>,
pub prev_height: Option<Height>,
pub new_height: Height,
pub timestamp: u128,
pub validation_context: ValidationContext,
  • prev_state_id is a StateID that indicates the referenced state of ELC. This is included only with update_client.
  • new_state_id is a StateID that indicates the state after the ELC has been updated.
  • new_state is the post-update state of the ELC corresponding to new_state_id. This is included for each light client update specification.
  • prev_height and new_height are the pre and post-height of the ELC, respectively.
  • timestamp is same as the timestamp of the upstream header corresponding to new_height.
  • validation_context indicates the context of the ELC validation to be described later in Validation-Context.


StateID is an identifier that uniquely indicates the state of an ELC's Client at a certain height. For Client following ICS-02, StateID is the hash value of the byte array which is the concatenation of ClientState and ConsensusState.

Usually, the ClientState of each client is initialized with parameters for verification, which are not changed afterwards. ConsensusState exists for each height and is generated from the Header information of the target chain. Note that many light clients have their own parameters. This may result in different validation results depending on the configuration despite using the same client definition.

Therefore, ELC includes both the pre-update (i.e., at verification) and post-update StateIDs in the UpdateClient Commitment. (Note that the commitment of the initializeClient shall be null in the pre-update state.) This guarantees that the sequence of updates leading to a certain UpdateClient Commitment is uniquely determined based on the post-update StateID contained in the initial commitment. That is, by verifying this chain of commitments and the proof, the verifier can ensure that the verification parameters from a particular light client are only updated by consistent commitments.

Validation Context

Validation Context indicates the context during Header validation by the Client of ELC. It includes the current timestamp of the validator.

In general, a light client checks the following two conditions during Header validation:

  1. The Header includes sufficient signatures based on a ValidatorSet for a certain state
  2. The state of the client to be verified is currently valid

The first is the verification of signatures obtained by algorithms such as ECDSA. ELC does this in Enclave. The second is often defined as validation predicates that take a timestamp associated with the current time and its state as input and returns a boolean value. For example, the trusting period in Cosmos is a validation predicate. However, in general, there is no reliable timestamp in TEE, thus verification using the current time in TEE is unreliable.

Therefore, ELC includes a predicate in the UpdateClient commitment that returns a boolean value of validity using the current time as input. Thus, in addition to verifying the signature of the commitment proof using the public Enclave Key, a verifier needs to evaluate this predicate using the current time of the verifier. For example, if the verifier is an on-chain LCP Client, it must refer to the latest block timestamp as the current time.

State Commitment

ELC generates a State Commitment that includes the commitment to the upstream state and its own state at the time of verification of the commitment by ELC.

The definition of StateCommitment is as follows:

pub struct StateCommitment {
pub prefix: CommitmentPrefix,
pub path: Path,
pub value: Vec<u8>,
pub height: Height,
pub state_id: StateID,

The prefix is a store prefix and is applied to the path at verification. The path is the upstream's commitment path and the value corresponds to the path. The height corresponds to the upstream's commitment and state_id is the StateID indicating the ELC state used for verification.