Liquidity.Network and Plasma

We welcome all efforts to scale open and decentralized blockchains!

TLDR — Is Liquidity Plasma?

Is Ethereum (no UTXO) considered to be Bitcoin (UTXO)? No.
Is Bitcoin Cash considered to be Bitcoin? No, although technically near equal.
Is everything with a Merkle Tree Plasma? Blockchains would be a “flavor” of Plasma if we were to continue down this discussion path, so no.

We thank Poon and Buterin for their prior work. We also invite all teams working on Plasma or other solutions, to consider utilizing the Liquidity.Network when developing their scaling efforts. We hope that this will allow them to build scalable products.

Plasma compared to Liquidity

Both Liquidity and Plasma are off-chain scaling solutions inspired by a multitude of work. Here we outline the clear differences between Liquidity’s NOCUST and Ethereum’s Plasma, and here’s why:

Liquidity went Mainnet!

Last week, we happily announced the release of the Liquidity Network Ethereum mainnet under https://wallet.liquidity.network/.

In addition, we have released another academic paper called NOCUST, complementing our existing REVIVE paper: https://liquidity.network/NOCUST_Liquidity_Network_Paper.pdf.

REVIVE is an augmentation of 2-party payment channel networks while NOCUST introduces the first efficient n-party payment hubs into the field.

Previously we’ve compared Liquidity’s N-Party payment hubs with 2-party channel hubs, and would now like to give a comparison with Plasma to clear some misunderstandings, because:

Some try to misrepresent Liquidity!

After failed attempts to reverse engineer the current Liquidity.Network deployments, some have attempted to portray our contribution as a mere reproduction of Plasma for their own personal gain. This is quite underwhelming, and is not a good attitude that supports innovation in the crypto world.

The devil is in the details, and if you do not meticulously lay out the details and prove their correctness, you may only obviously postulate possibilities rather than rightfully lay claim to contributions.

As such, for those inclined to pay attention to detail, we provide the following comparison between NOCUST and Plasma to discredit these misrepresentations.

NOCUST and Plasma

It’s very important to note that the Plasma specifications do not detail any of NOCUST’s data structure specification, dispute process, or transfer enactment protocols, and the opposite is true as we do not rely on a UTXO ledger, nor do we use a dispute mechanism for UTXO child ledgers, nor do we authorize transaction output modifications.

In the NOCUST related work section, we describe Plasma [1] as a specification for connecting a UTXO ledger with a parent chain, where minting and reclaiming unspent transaction may only take place on the parent ledger. Parties transact through authorizing spends of their UTXOs towards the intended recipients, as in Bitcoin, and sending their authorizations to the UTXO ledger network, which then aggregates the transaction set into blocks and commits to them on the parent network. Malicious behavior such as double spending or forged minting can then be disputed on the parent ledger through submitting select pieces of the UTXO structure for evaluation on-chain.

Based on the available core specifications of Plasma [1–5], and all the claims presented therein, we’ve produced the following summary of several fundamental differences to NOCUST:

Purpose: Payment / Computation

Liquidity.Network is highly optimized for off-chain and scalable payments, while Plasma is originally designed for general purpose computation scalability.

The most relevant specification then to compare to here becomes the Plasma Cash adaptation targeted at payments.

Data: Bimodal Balance Ledger (NOCUST) / UTXO (Plasma/Cash)

At the core of NOCUST lies a balance ledger commitment scheme which permits the aggregation of non-fungible account balances.

Plasma incorporates a Bitcoin UTXO ledger structure, which uses individual transaction outputs to denote the transfer of fungible coins and/or a fraction thereof.

Dispute Targets: Accounts (NOCUST) / Transactions (Plasma)

Secure and efficient dispute resolution mechanisms are an essential aspect of any off-chain protocol, such as 2-party channels, TrueBit, and others, and it is essential to build one out thoroughly and prove its security guarantees when developing a new off-chain protocol.

NOCUST specifies a dispute mechanism to secure the updates performed on its bi-modal balance ledger on a parent chain, while Plasma specifies a dispute mechanism to secure transaction expenditures of a child UTXO ledger in a parent chain.

These two different specifications do not overlap at the core of their contribution to any significant extent as they are specialized for different ledgers, while providing similar security guarantees on their targets.

You can dispute your account’s balance update in NOCUST, or that your transfer was not properly delivered, while in Plasma you may dispute whether a transaction output was spent or not, in both cases to avoid maliciousness in the sub-ledger.

Authenticated Proofs: Allocation (NOCUST) / Membership (Plasma)

The use of Merkle Tree Proofs for authentication is a very simple and powerful theme common to almost every piece of blockchain technology, including Plasma and NOCUST and others.

This cannot be used as a blanket excuse to portray anything that utilizes it as just another “flavor” of Plasma. Plasma is not the first to utilize such authentication structures, nor does it claim to be! But some attempt to convey this as some point of overlap to belittle protocol differences as just another “flavor”.

Insofar, Plasma Cash relies on using merkle proofs of membership in their dispute processes to authenticate transfer expenditure status in the UTXO ledger, while NOCUST uses proofs from its augmented merkle tree data structure to prove correct exclusive balance allocation in its bimodal ledger.

#BUIDL

What matters most is making tangible progress.

Liquidity is live on the mainnet because we spend most of our time working towards building real products. We’ve been recently trying to avoid making such comparisons as there is always room to interpret them in a hostile manner.

We owe it to our community to address such understatements of the Liquidity.Network. If you feel that our endeavors threaten you, and all you can do is try to spread unsubstantiated opinions, then we’re probably doing something right!

References

[1] Poon J, Buterin V. Plasma: Scalable autonomous smart contracts. White paper. 2017 Aug 11.

[2] Buterin V: Plasma Cash, https://ethresear.ch/t/plasma-cash-plasma-with-much-less-per-user-data-checking/1298

[3] Floersch K: PoS Plasma Cash with Sharded Validation https://ethresear.ch/t/pos-plasma-cash-with-sharded-validation/1486

[4] Floersch K: Plasma Cash Simple Spec https://karl.tech/plasma-cash-simple-spec/

[5] Buterin V: Minimum Viable Plasma https://ethresear.ch/t/minimal-viable-plasma/426

Like what you read? Give Liquidity.Network a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.