In this video we discuss the challenges of implementing light clients in Proof-of-Stake systems that either do not use BFT consensus at all, or use some sort of BFT finality gadget, but allow a large sequence of blocks to be created without any of them being finalized.
We start by covering light clients in Proof of Work systems. In a Proof of Work system for as long as the client can verify proofs of work in the headers, it is extremely complex for an adversary to convince a light client that a particular chain is canonical without executing an Eclipse attack, or carrying out a several hours long 51% attack.
We then cover light clients in BFT systems, in which each block is finalized. In such a system the light client can just confirm that each block has the signature of a super majority of validators, and confirm locally that the validator set transitions were executed properly. Unless the adversary at some point controlled a super majority of validators, or executed a long-range attack, they cannot trick a light client into believing that an adversarial chain is canonical.
Finally, we cover a major challenge of designing a light client in a proof of stake system that doesn’t use BFT finality, or allows epochs without finalized blocks. We argue that to support the clients a Proof-of-Stake system either needs to require each epoch to have at least one block finalized, or to use some scarce resource (such as work or space) in addition to Proof-of-Stake.
Watch the full episode here:
