Security Properties of Light Clients on the Ethereum Blockchain

Abstract

Ethereum is a decentralized blockchain, known as being the second most popular public blockchain after Bitcoin. Since Ethereum is decentralised the canonical state is determined by the Ethereum network participants via a consensus mechanism without a centralized coordinator. The network participants are required to evaluate every transaction starting from the genesis block, which requires a large amount of network, computing, and storage resources. This is impractical for many devices with either limited computing resources or intermittent network connectivity. To overcome this drawback Ethereum defines a light client protocol where the light client fetches the blockchain state from a node operating as a light protocol server. Light clients are unable to maintain blockchain state internally, and as a consequence can only perform partial validation on blocks. Thus they rely on the light server for full block validation and to provide the updated blockchain state. Light clients connect to multiple light servers to mitigate the risk of relying on a single potentially dishonest server. Ethereum light clients are known to suffer from a probabilistic security model, but they are widely assumed to be secure under normal operating conditions. In fact, the implicit security assumptions of light clients have not been formally characterised in the literature. We present and analyse the probabilistic security guarantees under three different adversarial scenarios. The results show that for any adversary that is able to manipulate the network, the security assurances provided by the light protocol are severely impacted, and in some cases entirely lost. These results clearly demonstrate that the assumption of normal operating conditions is insufficient to justify the security assumptions of light clients. Our work also provides insight to the security of light clients under different security parameters, allowing light client implementers to more accurately understand the potential security trade-offs.