NEAR
Redacted: Reclaim your sovereignty at no cost. Click to be there IRLRedacted: Bangkok, Thailand, November 9-11
NEAR Lunch & Learn Ep. 03: Light clients in Proof-of-Stake systems – NEAR Protocol

NEAR Lunch & Learn Ep. 03: Light clients in Proof-of-Stake systems

Community
November 14, 2019

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:


Share this:

Join the community:

Follow NEAR:

More posts

We use our own and third-party cookies on our website to enhance your experience, analyze traffic, and for marketing. For more information see our Cookie Policy