Introduction

This project entails the development of a lightweight client designed to efficiently validate particular events occurring on the Ethereum blockchain and relay them to the Axelar network for utilization by the Axelar amplifier. In particular, a relayer/prover was implemented to effectively track events taking place on the Ethereum side through the Axelar Gateway. These events are then made accessible in a standardized format within a CosmWasm verifier module following a successful verification process. Notably, our implementation is built upon the sync committee protocol introduced during the Altair upgrade of the Ethereum network

This page describes all components and APIs for implementing the light client.

Prerequisites

Before delving into architecture, the following prerequisites should be familiar.

Sync Committee Protocol

The Sync Committee Protocol is a feature introduced in the Beacon Chain on the Altair fork. Specifically, alongside the actual validators of the Ethereum Beacon Chain, a set of 512 validators are randomly selected that serve as the sync committee for a fixed sync committee period lasting about 1 day. The sync committee is responsible for signing the block headers of every block that is minted, that way attesting that the new block is indeed the head of the chain at each slot. The sync committee is an important component for implementing light clients since a verifier can easily verify the head of the chain, with minimal operations, without having to store the full validator set (a magnitude of hundreds of thousands).

In our implementation, we will use the sync committee protocol to implement an on-chain component that is always aware of the latest sync committee and can easily verify that a block is part of the chain.

More information about the sync committee protocol can be found here.

Finalization

Understanding the concept of our light client finalization requires a look at the structure of a sync committee update message. These messages are essential in the verification process and contain two key elements. Note that in both cases we are referring to finalization via the sync committee protocol. When we verify an update via the sync committee, we are relying on a >1/3 honesty assumption of the sync committee members.

1. Attested block: This refers to a specific block on the Ethereum blockchain that the sync committee has signed.
2. Finality block: This is the finality checkpoint that the attested block points to. Noting that the finality checkpoint is the first block of a finalized epoch per CasperFFG.

With these components in mind, the system supports two distinct types of block verification processes:

• Optimistic Verification: The verification is deemed optimistic if the block that we want to verify is a predecessor to a block that the sync committee has attested to (the attested block). Using optimistic verification is faster since the super-majority of the sync committee (almost) always signs the tip of the chain. On the other hand, since those blocks are not finalized yet, there is the possibility for that block to be dropped after a re-org.
• Finalized Verification: In this type of verification, a block is verified if it precedes a block that has been finalized as per the sync committee. This means that the block that we want to verify is a predecessor of the finality block.

Components