Rough notes #1: LazyLedger

LazyLedger: A Distributed Data Availability Ledger With Client-Side Smart Contracts by Mustafa Al-Bassam, published in May 2019.

“We propose LazyLedger, a design for distributed ledgers where the blockchain is optimized for solely ordering and guaranteeing the availability of transaction data. Responsibility for executing and validating transactions is shifted to only the clients that have an interest in specific transactions relating to blockchain applications that they use.”

Sounds intriguing, right? Let’s dive in!

Offloading responsibility to a client is not a novel approach and been used in client-server architecture for quite some time. In the world of blockchains, the concept again appeared with Mastercoin.

This design choice has some interesting properties:

The downsides include:


In LazyLedger, the client ONLY verifies & executes transactions, which are related to the application it’s running. When a client requests transactions, it uses the namespace ID (e.g., “cryptokitties”) to tell which transactions it’s interested in. Namespace IDs, therefore, are used as shard keys (virtual shards).

Consensus nodes use either PoW or PoS consensus to agree on the order of transactions.

On Availability

To familiarize yourself with the data availability problem, read “A note on data availability and erasure coding” or this article from Near protocol.

For light clients, we want to guarantee not only that the headers form a valid chain (like in Tendermint), but have the guarantee that corresponding blocks are valid too. To solve this, LazyLedger makes use of erasure coding, fraud proofs, and random sampling.

What differentiates LazyLedger from earlier approaches (1) is using data availability proofs to prevent clients from having to download everyone else’s transactions to validate the (data availability) of the chain, thus truly offloading responsibility.

A block header contains a Merkle tree root of the erasure coded block data. Light clients randomly sample the block parts to ensure data availability. While 100% guarantee is possible, in practice probabilistic guarantee is given (99%).

“if an adversarial block producer has withheld k out of n shares, then there is a high probability that the client will sample an unavailable piece and reject the block”

“a block … divided into 4096 shares, only 15 samples corresponding to 0.4% of the block data needs to be downloaded by a node to achive a 99% guarantee”

“because all applications in LazyLedger share the same chain, the availability of the data of all their transactions are equally and uniformly guaranteed by the same consensus group, unlike in traditional sidechains where each sidechain may have a different (smaller) consensus group”

There’s no “Plasma” sharding, just a single chain.

“clients gossip downloaded samples to full nodes that request it, so that they can recover the full block with enough shares”

Clients and full nodes form a single p2p network, communicating block parts on demand.

“sufficient minimum number of nodes in the network making a sufficient number of sample requests”

LazyLedger has an interesting property: as the number of clients grows, the security of the network strengthens. More clients => more requests proving block availability => better guarantee that block is indeed available. With the number of clients increasing, block size can be increased too.

On Liveness and Safety

“We assume that honest nodes not under an eclipse attack and are thus connected to at least one other honest node”

“We also assume that there is a maximum network delay Y”

LazyLedger assumes a synchronous gossiping network for both liveness and safety.

On Security

Because consensus nodes do not validate transactions, it’s possible for a malicious block producer to create a block filled with bad transactions. Clients won’t accept it, but it will still be created and stored by full nodes.

Therefore, it’s important for applications to have a way to punish the malicious block producer in PoS networks.

Social coordination

Social or other means of coordination are required when upgrading an application to a new version. Since here we don’t have a common runtime (e.g. EVM), we need a way for applications to signal that a new version is available.

This can be done through some off-chain registry or another application.

The LazyLedger team plans to provide tooling for deployment, so deploying an application is “easily as deploying a smart contract on eth or spinning up a docker container”.

Future plans

The LazyLedger team plans to use optimistic rollups. Each application will have a state root (along w/ fraud proofs), which will be used by light clients.


To learn more, you can go to their website. Don’t forget to like this and subscribe.

Thanks to Ismail Khoffi and Mustafa Al-Bassam for answering my questions!

Comments

comments powered by Disqus