# L2 Light Clients as AVS

This draft is inspired by Noah Citron's work on L2 light clients.

Light clients are important for web3 users. Don't trust, verify is the motto we should abide by. Having light clients that can effectively and efficiently work inside our browsers and mobile phones is critical for their mass adoption into wallets.

Helios is a verifiable light client working on solving this probalem. It functions by fetching data from an unreliable RPC and then verifying if the data is correct or not.


It first syncs and then verifies the block headers on Ethereum (thanks to sync committess introduced in the Altair fork). With a verifed block header, it can get a state root agaisnt which you can verify merkle proofs about data requested from untrusted RPCs.

### Keypoints on Mainnet

In order to verify data, you need to
- know what the data is
- check if the data is correct

Ethereum solves these steps because of sync committees. But they don't exist on L2s. So how can we build a light client for an L2?

### Light client for L2s

For an L2 Light CLient, we need two things:
- Irreversibilty Gadget (checks if block data is posted on L1)
- Validity Gadget (checks if block data is valid or not)

For latency, we cannot wait for data to be posted on L1 and then waiting for (optimitic or zk) finality. We need new mechanisms that are practical.

### Solutions Involving AVS

Since we don't wait for an L2 block to get posted onto L1, an irreversibility gadget ensures that a block produced by the sequencer will eventually be posted. An exmaple could be a simple AVS that ensures that a block built by the sequncer will be posted. If the sequencer (or multiple sequncers) does not post the block, it will get slashed.

An AVS has a performer, attester architecture. Here the sequncer is the performer, commiting to post blocks on L1. The attesters then verify if the blocks are posted or not. If 66% attesters aggree that it's not posted, the sequncer can get slashed.

Instead of a single sequncer, there can also be a fast finality committee, each operator tasked with creating an L2 block and being responsible for posting it to L2.

With these economic garunttess, the light client gains more security then just trusting the sequencer to include a block on L1.

Similar AVSs can be built for Validity gadget as AVS. The sequncer AVS can also be slashed if the block was not valid. Watcher networks must be established that constanly monitor the behaviour of the sequencer, rasing flags on L1 whenever slashing conditions are met.

Another method of validity gadegt as an AVS is a TEE network. Note that TEEs can be verified through their signatures (which can happen directly onchain). The job of the AVS in this scenario is to ensure liveness of the TEE, and inflict penalities if it fails to validate the block entirely.

An added benefit that validity gadgets bring is the increased security of the rollup, as teh blocks are verified in a decentralised fashion even before they're posted on L1. This would elimnate the risk of a fraud proof from L1 that can burn several state roots on L2 if a malicous block is submitted by the sequencer.

### Benefits of restaked assets

Reason why AVSs are economically more secure then simple bond mechanism is re use of capital. AVSs uses shared security, so the same capital can be used to secure multiple protocols.

This allows AVSs to gain economic secuirty much larger than isolated proof of stake or optimistically bonded networks.