Light clients are crucial to blockchain environments due to their capability to verify transactions or states without downloading the entire chain information. However, the light clients on the Ethereum network depend on a randomly reselected sync committee every 27 hours to follow the correct blocks.

EIP-7657 is an Ethereum Improvement Proposal (EIP) that introduces a slashing condition for malicious sync committee messages. By signing a malicious beacon block root, sync committee members can deceive the light clients. Providing faulty information to light clients may lead to exploits of bridges that rely on light clients. This makes light clients vulnerable to malicious sync committee members. This analysis seeks to dissect the value of EIP-7657 in enhancing the security and reliability of light clients on the Ethereum network.

Contents:

• Introduction - nodes and clients

• What is a light client?

• Light client use cases

• An example: Bitcoin SPV

• Problem of PoS

• LMD-GHOST: the fork choice algorithm

• Altair

• Solution: Sync Committee

• What EIP-7657 proposes

• Cost of tricking light clients after EIP-7657

• Open research topics

Introduction - nodes and clients

Let’s start from the beginning. Ethereum is a distributed network consisting of computers communicating with each other. These network participants, i.e., computers, are called nodes. To be integrated with the Ethereum network, nodes have to run software called clients. The words “node” and “client” are sometimes used interchangeably, but in this report, "node" means computer, and "client" means the software of the node. There are various types of nodes and clients for different purposes, such as:

• Full node

• Archive node

• Validator node

• Light node

The sync committee is about light clients, but before diving into light clients, let's recall these node types.

Full node: Full nodes check every block announced by validators to determine whether the block is valid. If it’s valid, full nodes add the block to the end of their ledger. Full nodes store the complete data of every block and transaction from the genesis block onward, but they only retain the state information for the most recent 128 blocks. Their primary function is to verify blocks, not to maintain the entire blockchain's state history.

Full nodes run two clients, the execution client and the consensus client. The execution client is responsible for transaction handling, transaction gossip, state management, and supporting the Ethereum Virtual Machine, while the consensus client is responsible for block building, block gossiping, and handling consensus logic.

Archive node: Archive nodes are responsible for maintaining the historical archive of the blockchain. They verify and store every block from the genesis block onward. Due to the large size of blockchain data, an archive node requires more robust hardware than a full node. As of May 2024, the size of Ethereum data is about 3.5  terabyte. Archive nodes can be thought of as full nodes that store all states at any historical point in time.

Validator node: Validator nodes are full nodes that meet the requirement of staking 32 ETH to become a validator. They run a validator client in addition to the execution and consensus clients of a full node. This allows them to generate blocks and announce them to full nodes when it is their turn.

Light node: Light nodes download only block headers instead of all block data. These headers contain summary information about the blocks. Similar to full nodes, light nodes run a dual client structure: a light execution client and a light consensus client. Light clients are responsible for verifying the correctness of data by checking the block headers. Since light clients do not need to download all chain data, they can operate on mobile phones, web browsers, or wallet extensions, making them the most cost-effective way to interact with the blockchain.

What is a light client?

A light client does not store the entire blockchain locally or verify all changes independently. Instead, it retrieves necessary blockchain data from a provider, which could be a full node or a centralized RPC server. The light node then validates this data to stay updated with the latest blockchain information. Typically, light nodes handle only block headers and occasionally download full block contents. Therefore, they don’t verify the validity of blocks themselves, which is why light clients are less secure than full clients. There are several types of light clients, classified by the data they verify:

• Consensus verifiers

• State verifiers

• Data availability (DA) verifiers

• Full verifiers

Light client use cases

Bridges

One of the primary use cases for light clients is creating bridges. Consider a bridge between Ethereum and another blockchain, say chain X. Since it is not possible to transfer an asset directly from one chain to another, bridges lock the asset in the departure chain and mint an equivalent amount of the asset in the destination chain. The newly minted asset is sent to a user, for instance, Alice, who sends her asset to the bridge contract in the departure chain. The crucial aspect of this setup is ensuring that Alice truly sent her asset to the corresponding smart contract. She should not be able to receive the newly minted asset before sending an equivalent amount.

Hence, the contract on chain X has to be certain that Alice actually sent ETH to the contract on Ethereum. The least secure way to prove this is by creating a multi-signature layer, where the contract on chain X mints representative ETH only if a set of multisig wallet signers verifies that Alice sent ETH on Ethereum. This is a very centralized approach; the committee may censor some users or allow minting ETH for malicious users who didn’t send any ETH at all.

Another approach is verifying Alice’s transaction on-chain. Thanks to the virtual machine structure of many blockchains, they can act like small computers. For example, one can perform some basic mathematical calculations on-chain using the computational power of the Ethereum nodes by paying gas fees according to the complexity of the calculation. If blockchains can act like computers, then one can create a smart contract that directly connects to a node of the other chain and reads the contract to verify whether Alice sent ETH or not. However, this is not preferred either, as it depends on a node, making it quite centralized like the multi-signature setup. For instance, the node can trick the bridge contract by providing missing or incorrect information to exploit the bridge.

One may ask, if it’s possible to use blockchains as computers, why aren’t bridge contracts running their own node of the other blockchain on-chain? It’s possible but too costly in terms of gas, making it inefficient. Even if the gas consumption is fixed, data storage poses another problem since the data of the chains can reach terabytes. However, this idea leads to another type of solution: light clients.

Running a full client of a blockchain on-chain is impractical, but running light clients is. Since light clients download only block headers but not blocks themselves, they don’t require as much data storage and gas consumption as full clients. Thus, a contract can verify whether a user sent an asset to a contract on another chain. These types of bridges are called light client bridges and are known as the most secure bridges. However, they are more expensive compared to multi-signature wallet-backed bridges since running a light node requires more gas than creating a multi-signature on-chain.

Wallets

The security concerns of wallets are as important as those of bridges, and they can increase their security by using light clients. To understand the importance of light clients for wallets, let’s consider an example given by Etan Kissling in his speech, "Light Clients After the Merge," at Devcon-Bogota, 2022.

Imagine a scenario where someone, let’s say Bob, is paying you 0.5 ETH. You give him your address, and he signs the transaction. Then he claims he made a mistake and sent 5 ETH instead of 0.5 ETH. You check your balance with your Metamask or another wallet and see that he really sent 5 ETH. As an ethical response, you send back 4.5 ETH. After some time, you check your wallet and realize that your balance has not increased by 0.5 ETH but has instead reduced by 4.5 ETH compared to before meeting Bob. But how can this happen?

Wallets get information from nodes, just like every app working on-chain. Every wallet connects to a node to read the user’s balances to show in the app and delivers users' transaction requests to the chain as well. In this scenario, there are some possible flaws. The first case is Bob somehow changing your wallet’s connected node. Most wallet apps give users the option to choose the node they communicate with. In that case, Bob may connect your wallet to a malicious node to gain some profit. Hence, that node is giving false information, showing the wrong balance. A couple of factors may cause this situation, like the node acting maliciously and giving faulty information on purpose or the node starting to follow a forked chain, not the canonical one, etc. The second case is not changing the wallet’s connected node, i.e., using the default node set by the wallet. In this case, it's unlikely that the node would provide false balance information to gain profit, as the attack scenario mentioned above is specific to a user. However, it can still provide incorrect balance information due to an error.

However, you don’t need to worry about whether the node your wallet is connected to is problematic or not. Since light clients don't deal with the entire blockchain data, you can run them on your own computer, smart watch, or even in a web browser. For the Ethereum network, it takes a couple of seconds to sync, and typically, a few gigabytes of free space are enough. Once you have an up-and-running light client, you can easily connect your wallet to your light client and avoid the risks coming from third parties.

An example: Bitcoin SPV

Although light clients have a long way to go, they are not new concepts. The first example of a light client was mentioned in the Bitcoin whitepaper, known as Simplified Payment Verification (SPV). To understand how SPV works, let’s recall the block structure of Bitcoin.

Bitcoin blocks consist of a block header and the transactions within that block. Block headers contain the Merkle root of the transactions, and SPV allows checking if a transaction is verified by examining the Merkle root and Merkle path of the transaction. This is much easier compared to checking each transaction in the block.

Merkle trees are data structures built with hash functions, allowing the creation of a summary of the data. Hash functions have two main features: firstly, they are irreversible, meaning it’s impossible to determine the input from the output. Secondly, they are injective, which means the outputs of different inputs are distinct. The Bitcoin protocol uses SHA-256, which produces 256-bit outputs, regardless of the size of the inputs. For more detailed information, check the section about Merkle trees at "Verkle Trees for the Rest of Us - Part 1."

To generate the Merkle root of a block, first, every transaction in the block is hashed. Then, the hashes are paired together and hashed again. This process continues until the final hash output is reached. The final result of this process is called the Merkle root of that Merkle tree. Here is an illustration with 8 transactions. Note that, in general, a Bitcoin block contains more than 3,000 transactions.

Here, we have 8 transactions from A to H, called leaves of the Merkle tree, each used as an input for the SHA-256 function and resulting in hashes H(A) to H(H). Then, each pair of these hashes is combined and hashed until reaching H(ABCDEFGH). Note that to prevent confusion, we omit the function notation H in the parentheses. In this context, H(AB) means H(H(A)H(B)), and vice versa. Each output H in that tree is called a branch.

To check if a transaction, say C, is in the block, one can download the block header and all transactions (in this case, 8) and generate the Merkle root to see if they match. However, this may take time and consume storage. Instead of downloading all the leaves, one can verify the transaction using specific branches; this is called the Merkle path. For example, to verify that transaction C is in the Merkle root, one needs only D, H(AB), and H(EFGH). By combining these with C, one can generate the Merkle root and check if it’s consistent with the block. Here is an illustration:

In this illustration, the green ones are the needed branches to reach the Merkle root, and the blue ones are the ones that can be calculated with the knowledge of the yellow ones. Hence, instead of downloading all block data, it’s enough to download three hash outputs, each 256 bits. And that’s exactly what SPV does. It downloads only the relevant branches of the Merkle tree and the Merkle root of the chain, then checks if the transaction that needs to be verified fits. Due to the “randomized” structure of hash functions, if the transaction is slightly changed, then the entire Merkle path and the Merkle root will be completely different, and since it’s injective, there is no way to generate the same root using another Merkle path.

In the above example, we had 8 (which is equal to 2^3) transactions, and SPV needed three branches to verify a transaction. This is not a coincidence; to verify a Merkle tree containing N leaves, log_2(N) branches are sufficient. To prove this, it’s easy to see that for each layer, we need one additional branch to reach the root. Having N leaves means there are log_2 N layers to reach the root. In our example, the number of leaves is a power of 2. One may ask how to build a Merkle tree with a number of leaves that are not a power of 2. The solution is hashing with itself if a leaf or branch does not have a neighbor. With this approach, it’s possible to build a Merkle tree with any number of leaves (transactions, in this case).

As stated above, SPV can verify if a transaction is valid or not in a block with N transactions by just checking the Merkle path. Currently, the average block size of Bitcoin is around 1.5MB per block, and the average number of transactions per block is around 3,000. So, to check if a transaction is valid, SPV needs to download log_2 3000 ≈ 12 hash outputs. Since each SHA-256 output is 256 bits (32 bytes), SPV needs to download 12 * 32 = 384 bytes instead of downloading all block data, which is 1,500,000 bytes. This demonstrates how efficient light clients are.

One issue with SPV is having more than one different chain. In that case, the SPV node has to decide which one is the canonical chain. Thanks to the nature of proof of work (PoW) chains, the SPV node can easily determine this by checking the longest chain. If a node wants to trick the SPV by providing incorrect information, it needs to add a faulty block at the end, but it has to “mine” that block with its own computational power, whereas all the nodes are trying to mine the real block. Even if by chance, the malicious node mines the fraudulent block  before the others, it has to find the next blocks as well to make its chain the longest, which is impossible without having more than 50% of all resources. Therefore, it’s effectively impossible to trick SPV while it’s following the longest chain. However, this is not the case for proof of stake (PoS) based chains.

Problem of POS 

Before diving into the problem, let's first do a quick recap of the Ethereum consensus mechanism:

Before 2022, Ethereum’s consensus mechanism was based on PoW, just like Bitcoin. After the merge, this changed, and since then, the validity of blocks is decided via PoS. Validators are analogous to miners in PoW; however, the block generation process is not exactly the same. In the Ethereum network, every full node runner can be a validator by staking 32 ETH and running a validator client. Currently, there are more than a million validators.

Ethereum timing consists of epochs and slots. Each epoch consists of 32 slots, and each slot corresponds to 12 seconds. Essentially, slots are the potential spaces for blocks. Each slot can have zero or one block. How does  block generation work? At the beginning of each epoch, all validators are assigned to slots such that those responsible for each slot are 1/32 of the validators. Therefore, each validator is assigned a block for each epoch. Additionally, for each slot, a proposer is chosen pseudo-randomly using RANDAO, the random number generator (RNG) protocol used by Ethereum. Note that the proposer of a slot is not chosen from the validators of that slot. Instead, for each slot, a proposer is selected from among all validators. Consequently, there is a 1/32 probability that the proposer will propose the block for the same slot he is attesting to, and a 31/32 probability that the proposer will be responsible for proposing a block for a different slot than the one he or she is attesting to. 

The proposer’s duty is to create the block with the transactions waiting in the mempool and update the Ethereum state. Afterwards, it informs all validators assigned to the state with the candidate block, and then the validators attest the block by signing the attestation message with their validating key if they see it’s valid. If the proposer tries to trick the network, they lose some or all of their staked ETH.

However, due to the decentralized structure of the network, some problems may occur when distributing blocks. For example, let’s say Alice is responsible for proposing block 15, and Bob is responsible for block 16 of the current epoch. Alice signs a valid block and distributes it to the network. However, Bob may not receive it due to connection problems. What will he do in that scenario? He can’t wait for Alice’s block since he has only 12 seconds to generate his block, but he needs Alice’s block header to create his block. In this scenario, instead of waiting for Alice’s block, Bob creates his block with the header of block 14. Here is an illustration:

This means, effectively, he created block 15 in slot 16. Here, the next proposer must follow either Alice’s block or Bob’s block. This causes a fork. Neither Alice nor Bob is a malicious actor; the limitations of the connection caused this, so neither of them will be slashed. The Bitcoin network handles this type of situation by following the longest chain, as mentioned in the SPV section. Unlike proof of work, creating a longer chain that benefits a malicious actor does not require more than 50% of the total computational power. A group of validators can create a longer chain with faulty blocks to trick a light client. These types of attacks are called long-range attacks.

To prevent long-range attacks, the Ethereum protocol uses checkpoints. Attestation messages signed by the validators contain the last checkpoint according to their view, in addition to their vote for the proposed block. Each epoch has a checkpoint, generally the first block of that epoch. If the first block of the epoch can’t reach validators, they refer to the previous checkpoint they accepted as the checkpoint of that epoch. 

If a checkpoint is accepted by 2/3 of the validators, then the previous blocks of that checkpoint are tagged justified. If another checkpoint becomes justified after a justified checkpoint, then the justified checkpoint and its preceding blocks become finalized. If there are two blocks as a candidate checkpoint and neither of them reaches the 2/3 threshold, then the fork choice algorithm (explained below) is used to decide the checkpoint. If a block is finalized, then it is very unlikely to be a malicious block. To create an alternative finalized chain block, an attacker would need to control 2/3 of the total staked ETH. This is the economic security that Ethereum’s consensus relies on.

LMD-GHOST: the fork choice algorithm

In the Ethereum network, the process of determining the canonical chain differs from the longest chain rule. Instead of simply following the chain with the most blocks, Ethereum employs a fork choice rule known as the "latest message-driven greedy heaviest observed sub-tree" (LMD-GHOST).

The LMD-GHOST algorithm works by analyzing the number of attestations—essentially votes from validators—associated with the blocks that follow a fork. When a fork occurs, the algorithm doesn't just count the blocks to determine which chain to follow. Instead, it looks at how many attestations have been accumulated by the subsequent blocks on each forked path. A key aspect of this algorithm is that a shorter chain can sometimes accumulate more attestations than a longer chain, making it the "heaviest" subtree. This means that the chain with more attestations is considered more legitimate, even if it has fewer blocks. The illustration below shows how a shorter chain can get more attestations and become the heaviest.

In this case, block A is followed by a chain with 2 blocks, while block B is followed by a chain with 4 blocks. According to the longest chain rule, the chain consisting of B would be considered the canonical chain because it has more blocks. However, under the LMD-GHOST rule, the decision is based on the number of attestations. Here, the number of accumulated attestations for A is 5, whereas the number of accumulated attestations for B is 3. Therefore, LMD-GHOST chooses A over B. This approach ensures that the security and consensus of the network are maintained by prioritizing the validators' votes rather than just the number of blocks, making the fork choice process resistant to long range attacks.

Altair

Ethereum has its own light client protocol, named Altair, which takes its name from the Altair fork implemented in October 2021. Altair is a more sophisticated protocol compared to Bitcoin’s Simplified Payment Verification (SPV). While SPV focuses on verifying transactions, Altair goes a step further by enabling the verification of the entire state of the blockchain, encompassing all chain activities.

One of the significant challenges that Altair addresses is the potential issues arising from the longest chain rule, which is used by SPV. The longest chain rule might not always lead to the accurate chain, as discussed in the LMD-GHOST section. Therefore, Altair does not follow the longest chain rule. Instead, it should follow the canonical chain decided by LMD-GHOST. 

However, there is a problem: how can Altair determine the canonical chain determined by LMD-GHOST? Some might suggest solving the problem of finding the canonical chain by checking the validators' attestations. While this is a valid approach, it is not a straightforward task, especially for light clients. Currently, there are over 1 million active Ethereum validators, making it impractical for light clients to track all attestations to determine the canonical chain. Additionally, the information about the validator set can only be verified by checking the state of the previous block, adding another layer of complexity.

Verifying a header is more complex than verifying a transaction compared to SPV. This is because some of the necessary data relies on the previous header. For example, to know the previous block's hash, the previous block's header must be verified first. Consequently, for a light client to confirm the legitimacy of a specific header, it must recursively verify all headers back to the Genesis block's header. This recursive verification process is resource-intensive and not feasible for light nodes with limited capabilities. To address these problems, the notion of the sync committee was developed and implemented with the Altair fork.

Solution: Sync Committee

The Altair update introduced the sync committee to address the issue of selecting the canonical chain. The sync committee is made up of 512 pseudo-randomly chosen Ethereum validators who serve for 256 epochs (approximately 27 hours). Each block header includes the aggregated signature of the validators in the sync committee and a bitfield indicating which validators signed. Additionally, each header lists the validators expected to sign the next block. This allows a light client to quickly verify that the sync committee has approved the data they receive and confirm the authenticity of the sync committee by comparing it with the one expected from the previous block. Therefore, light clients keep track of the head of the blockchain without needing to access the entire validator set.

One might think the sync committee is pointless due to the slashing of validators. For example, if a validator tries to fork the canonical chain for their benefit, they will be punished by slashing, so why do we need an indication for the canonical chain? However, as mentioned above, forks are not always the result of malicious validators; they can occur naturally.

Sync committee members are rewarded with 0.1 ETH in exchange for their service, and they are responsible for signing each block header. If they do not attest, they are charged the same amount. However, as stated in the beginning, they are not slashed if they attest to a faulty block. This makes light clients less secure than full clients since they rely on 512 pseudo-randomly chosen validators instead of the entire validator set. There is nothing preventing the sync committee from being bribed and tricking light clients.

To reach a quorum, 2/3 of the sync committee must attest to a block. If they can’t reach the threshold, the next block header is still signed but with a bad aggregate, meaning that the sync committee couldn’t agree on that block. In that case, light clients simply skip that block and import it when the 2/3 majority is reached. Light clients are able to backfill missed block headers using the parent root.

It's natural to have concerns about how much 512 validators represent 1 million in terms of security. However, getting a malicious sync committee is statistically unlikely. Our first assumption is that 2/3 of the 1 million validators are reliable and less than 1/3 are malicious. Otherwise, the malicious group would already be able to manipulate the chain because of the nature of CASPER FFG. The remaining calculations are basic probability.

Say we have an urn containing 999,999 balls such that 666,666 of them are blue and 333,333 are red. The blue ones represent honest validators, while the red ones are malicious. The probability of having 11 blue and 501 red balls when choosing 512 from the urn, i.e., 11 of the sync committee members are malicious, is: C(11, 512)∗(1/3)11∗(2/3)501 = 4.828∗10−72

This expression is nothing but the random variable X Bin(512, 1/3) which is a binomial distribution, with P(X = 11)

Since the threshold for the sync committee is 2/3, the tolerance for malicious members in the sync committee is 342. If they reach 342 or more, they can provide faulty information to light clients, i.e., they rule the sync committee. The probability of the sync committee being ruled by attackers is given by P(X>342) where X is the same random variable. This value is equal to: 2.047∗10−54 which can be checked using WolframAlpha and tested for different values. Hence, one can expect this event to happen once in: 1/(2.047∗10−54)=4.885∗1053 sync committees. Considering each sync committee works for approximately 27 hours (1.125 days), the expectation for this event is in: 4.885∗1053∗1.125 = 5.496∗1053

days, or in: 1.5047 × 1051 years. This is an enormous number, considering the universe is approximately: 1.38∗1010 years old. This shows us that the sync committee is statistically reliable. However, 27 hours is more than enough time to communicate and agree on an attack, or for a third party to bribe them to organize an attack.

What EIP-7657 proposes

Motivation

The proposal addresses a critical vulnerability in Ethereum's light client sync protocol. Specifically, it highlights the risk posed by a dishonest majority within the sync committee. In the current protocol, the sync committee plays a crucial role in helping light clients efficiently sync with the blockchain by providing periodic updates. However, if a majority of the sync committee members act dishonestly, they can manipulate these updates in a way that could have severe consequences for the network.

One of the primary risks is that a dishonest majority could cause applications that rely on the light client sync protocol to accept a non-canonical (incorrect) finalized header. This incorrect header would mislead the light clients into believing that they are following the correct chain when, in fact, they are not. This could lead to a range of issues, including incorrect transaction validations and disruptions in the operation of decentralized applications (dApps).

Furthermore, a dishonest majority could potentially seize control of sync authority for future periods by signing a fraudulent beacon block root. By doing so, they could establish a foundation for continuous exploitation. This fraudulent root could be used to create a malicious but technically valid LightClientUpdate message. Such a message could exploit trust-minimized systems, like bridge contracts, that depend on the light client sync protocol. These bridge contracts facilitate cross-chain interactions and are particularly vulnerable because they rely heavily on the integrity of the sync updates to function correctly.

Proposal

To mitigate this risk, the proposal introduces an additional type of slashing penalty specifically designed to deter and punish malicious behavior by sync committee members. This new penalty targets those members who sign non-canonical beacon block roots. By imposing strict penalties, the proposal aims to ensure that validators adhere to the correct protocol and do not engage in actions that could compromise the network.

Similar to existing penalties for ProposerSlashing and AttesterSlashing, this new slashing rule is focused on malicious behavior. It includes actions such as participating in contradictory actions across multiple chain branches simultaneously. For instance, if a validator signs off on conflicting beacon block roots from different forks, they would be subject to this new slashing penalty. This helps to maintain the integrity of the canonical chain by punishing those who attempt to create inconsistencies.

Crucially, any slashing must be verifiable without needing access to historical data. This requirement ensures that the slashing process remains efficient and transparent. For example, a checkpoint-synced beacon node, which has synchronized to a recent checkpoint without needing to process the entire chain history, should be able to verify slashing conditions. This approach simplifies the slashing verification process and supports the scalability and usability of the Ethereum network by reducing the data load on individual nodes.

By implementing this additional slashing penalty, the proposal aims to fortify the security of the Ethereum network. It addresses potential vulnerabilities in the sync committee mechanism, ensuring that validators remain aligned with the canonical chain and discouraging any form of malicious activity that could disrupt the network's consensus. This enhancement is particularly crucial for maintaining the trust and reliability of decentralized systems that rely on the light client sync protocol.

Cost of tricking light clients after EIP-7657

EIP-7657 requires a hard fork as it introduces new consensus validation rules. However, if the proposal is enabled, tricking a light client will become highly expensive, discouraging a third party from offering a bribe. Since there are 512 members in the sync committee, taking over the sync committee requires bribing at least 342 validators. This means it costs 32*342=16384 ETH which is more than $63 million at the current price. 

This economic security dramatically increases if EIP-7251 is accepted. In short, EIP-7251 proposes increasing the maximum effective balance of validators from 32 ETH to 2048 ETH. It's hard to say that in a scenario where both EIP-7657 and EIP-7251 are accepted, the economic security of the sync committee would rise to 512*2048=1,048,576 ETH which is more than $4 billion. Since the balance of sync committee members will vary between 32 ETH and 2048 ETH, the security will still be increased compared to the scenario where EIP-7657 is implemented but EIP-7251 is not.

Open research topics

Even though EIP-7657 proposes bringing significant economic security on top of the statistical security of the sync committee, there are still some open problems to work on.

For instance, with EIP-7657, malicious sync committee members will be punished after the attack. Since malicious sync committee members can only be slashed after the block they signed is finalized, slashing them without waiting for finalization would be unfair. This is because when they signed, the block was correct, but after a reorganization as a result of the fork choice algorithm, that block may become faulty. In that case, the sync committee members can’t do anything. Single slot finality might solve this problem, but in the current situation, this is still an open issue.

A bridge may be designed to bypass this problem by sending the assets after the block containing the sync committee’s related sign is finalized. Another implementation would be creating a fund with the slashed ETH due to the malicious activity of the sync committee, instead of burning them. This fund could be used for bridge hacks, making bridges secure for transactions up to 32*342=16384 ETH. However, this amount is far from the total balance of most bridges. Even if the max effective balance is increased, many bridges would not be fully secure, considering the current TVL of all bridges is more than $25 billion in total.

Another open problem is caused by the fact that the sync committee message keys cannot be revoked. If a validator is slashed, the light client remains unaware and continues to accept signatures from that validator until the end of the sync period. This issue is compounded by the ability of validators to exit the validating network while part of a sync committee. A potential solution could involve delaying the exit until the sync period concludes.

Summary

To conclude, light clients are essential for verifying on-chain information without needing all the chain data and the hardware required to check it. Due to the nature of PoS-based chains, light clients face challenges in finding the canonical chain. With the Altair fork, Ethereum addresses this problem by introducing the sync committee, which signs the correct block headers to guide light clients. However, currently, there is no deterrent mechanism to prevent sync committee members from providing faulty information.

It is statistically unlikely to have more than 2/3 malicious sync committee members in a committee where 2/3 of the entire validator set is trustworthy. However, since a committee serves for 27 hours, members could be bribed to provide faulty information. EIP-7657 proposes adding an economic security layer to improve the security of light clients by introducing a slashing condition for malicious sync committee members. However, as mentioned under the open problems section, there is still a long way to go to reach perfection.