Plasma Chamber’s Fast Finality
Cryptoeconomics Lab’s Plasma Chamber allows for a quick and safe Plasma chain with instantaneous confirmation
If you’ve been following the technical developments over the last few years, you know that so much has already been done, and people have dedicated so much energy to invent solutions to the technical issues that stand in the blockchain’s way: many ideas are on their way, many protocols and models are being built to fit with each project’s specific goals, and a variety of tokens standards are invented for different use-cases.
Several protocols are also being researched to solve the scalability problem, also known as the Blockchain Trilemma: meaning that between security, decentralization, and scalability, you always have to sacrifice one of them.
And as decentralization and safety are both blockchain’s sacro-saint fundamentals, until now, scalability is usually the weakest point of the triangle. Which is why some passionate minds today are working on to drastically improve blockchain’s scalability while maintaining the highest guarantees of security and decentralization, both fundamental qualities of blockchain that can’t be replaced by traditional databases.
One of the most promising solutions to the scalability issue is Plasma, co-created by Vitalik and Joseph Poon, and researched by our team at Cryptoeconomics Lab: a network of child-chains, offloading a lot of work from the root chain, to which it commits only very light Merkle Roots instead of the full blocks. The goal is to accelerate the inspection process, and scale from 14 to millions of transactions per second.
In this model, one single operator validates the Plasma child chain’s transactions, which is much quicker than waiting for a lot of nodes in the network to agree with each other to validate them. But to resist potential malicious behaviors from this operator, the transactions he commits remain pending for a long period of time, during which users can challenge the transactions, meaning they can check that they are valid, and have them removed if they’re not: for instance, in the case of a double spend.
Fantastic: thanks to the combination of the exit game and Ethereum’s security to confirm finality, child chains are now secure, and thanks to all the work offloaded from Ethereum to the Plasma chain, the rock-secure Ethereum is now also fast.
Still, lightfast child chains now face slow blocks confirmation, due to the pending transactions’ legitimation period.
The reason is that the Plasma chain’s operator could fraudulently censor a Plasma transaction: for instance, in order to benefit a merchant’s service, but then to delete the transaction with which he actually pays the merchant.
This would require the malicious control of both the L2 confirmation mechanism, controlled by the L2 operator himself, and then of the L1 confirmation mechanism for the L2 block’s commitment, controlled by the L1 miner. Either the operator would also be a miner on the L1 layer, either he would collude with a fraudulent L1 miner.
This way, they would be able to maliciously cancel the commitment of the legal L2 block sent on L1, and send back the unconfirmed legal block on L2. The L2 operator would then propose a new block, without the legal transaction he wants to delete, and send the fraudulent block back to L1, where it will be confirmed by the malicious miner.
The legal block has been refused, and the illegal block has replaced it and been confirmed.
Therefore, slow blocks confirmation on L2 is a way to allow for the detection of such behaviours, and to avoid such scenarios.
So how does Alice pay for her last-minute travel so that her transaction is complete right away?
At Cryptoeconomics Lab, we believe that Bob and Alice are right, and we provide them with a way to jump in the plane in just the time to pack up their stuff: what we call Fast Finality.
In essence, Fast Finality is an option that a service provider (in our example, the travel company) will buy from the Plasma chain operator, and most likely provide in return to its customers (Alice or Bob), thanks to which the transaction will not be pending for days, but be processed immediately.
So how does that work?
First things first, who plays the roles: Alice is Alice, let’s call the Service Provider or merchant TravelWorld, and the Operator is most likely a legally registered entity, that has, 1) the ability to continuously run a network, 2) absolutely no interest in being associated with fraudulent behaviors, not only for its reputation but also because of the possibility for disputes to end up in court, and 3) a huge collateral capacity, to be able to refund potentially all users at once in case something goes wrong with their transactions. And in case the operator is proven fraudulent, his collateral is withdrawn and he loses it, which he will want to avoid. Example of such an operator: Amazon Web Services (AWS).
But don’t worry hearing « Amazon »: remember, Amazon doesn’t have access to anyone’s identity nor personal information. Amazon is strictly receiving transactions’ impersonal numbers (Plasma TxHashes), compressing these numbers into a Merkle tree, and sending the root hash to the root chain.
Now what happens when Alice wants to go to Bahamas right now?
Alice sends a transaction with her signature to TravelWorld. TravelWorld forwards it to Amazon Web Services, the operator of the Plasma chain. TravelWorld also buys a non-fungible Fast Finality Token from AWS, in exchange for Amazon to process Alice’s transaction right now.
The operator, AWS, sends back the transaction to the merchant, TravelWorld, now signed both by Alice and Amazon, and also takes care of including it in the next Plasma block, and of committing the appropriate Merkle Root to the root chain.
And in case the operator now decides to censor the transaction, the merchant has the Tx in hand signed by Alice and confirmed by the operator, and can send it to the Ethereum L1 root chain for dispute, like he would send a customer’s check to his bank, assured that he will receive his money.
Duration of the whole operation: 300 milliseconds.
TravelWorld can now issue the flight ticket for dear Alice.
In this model, the merchant can’t be fraudulent because he needs both signatures of Alice and of the operator, and Alice can not be fraudulent because she doesn’t have access to a sensitive part of the model. The operator can be fraudulent, but the challenges protocol allows the merchant to prove that although he bought the Fast Finality Token, Amazon didn’t process it quickly. Amazon can produce a counter-proof, and two disputes’ rounds of proofs production in both directions are allowed.
And as always, if the operator makes malicious actions such as block withholding or double spend, any user can dispute him within 2 weeks after the Fast Finality confirmation. In case the operator is proven fraudulent, his collateral is withdrawn and he loses it, which he will also want to avoid.
All boxes are checked: scalability, decentralization, security.
With Plasma Chamber, the whole process speeds up, and thanks to its Fast Finality feature, finality confirmation is instantaneous: blockchain is now fast, trustless and safe.
Know more
To know more about Plasma Chamber and see what it can do for you, use the Plasma Chamber SDK to develop your applications, or simply get in touch with the team, please check https://cryptoeconomicslab.com, or Yuriko Nishijima’s profile on Medium. You can also hear Yuriko introducing Plasma Chamber at EDCON 2019 in Sydney on 2019/4/13. Thanks to the team at Cryptoeconomics Lab, especially Yuriko Nishijima, Shogo Ochiai and Syuhei Hiya for their kind time answering my questions about the technology behind Plasma Chamber. Remaining errors are my own.
* * *
Author’s note: I’m the content manager for the European Union Blockchain Observatory & Forum, an initiative led by ConsenSys for the European Commission. If you wish to get in touch with me, I’m not such a heavy tweeter but you can find me on LinkedIn. And if you need a researcher / writer in Tokyo, don’t think twice and hit me up.
