Coinbase Backed Start-up Launches Plasma Cash Sidechain Testnet For Ethereum Scalability

0

A San Francisco based start-up, funded by Coinbase Ventures and  UC Berkeley’s House Fund, has announced the launch of a Plasma Cash implementation on Ethereum’s Rinkeby testnet and a sidechain.

“By moving transactions and smart contracts onto a Layer 2 environment using the power of Plasma architecture, Elph can help Ethereum dApp developers scale, secure and speed up their applications, opening up the potential of what can be accomplished on the blockchain,” Ritik Malhotra, Co-Founder and CEO of Elph, says.

Elph Plasma Explorer, October 2018.

A live demo running on testnet took us through the initial transportation of our eth onto the Plasma Cash sidechain.

Elph Plasma eth transfer, October 2018.

Now we can do however many transactions we like, with this apparently running at 6,000 transactions a second.

“Backed by the security of Ethereum via Plasma, all transactions first occur on Elph’s network, are periodically consolidated into batches, and then recorded as a single transaction on Ethereum. This allows for hundreds of thousands of transactions to be recorded in a single block confirmation,” they say.

Interestingly, this is a sidechain running on open source code. The project says:

“Sidechains are layer-2 blockchains that allow digital assets from one blockchain to be used in a separate blockchain and moved back to the original one if needed.

They act as two-way pegs to move assets around for specific purposes (e.g., sidechains can compromise on certain aspects of decentralization to achieve higher scalability).

Elph’s Plasma Chain is a sidechain that’s backed by the security of Ethereum. This allows Elph to achieve scalability as a sidechain, while maintaining a peg to allow users to withdraw their assets back to Ethereum if needed.”

Elph Plasma explorer, October 2018.

“Elph Network’s Plasma contracts are a full implementation of Plasma Cash. With support for Ether, ERC20 & ERC721 tokens these contracts act as the root chain bridge allowing assets to be securely transfered to and from the Elph Network,” their Github says.

They also have an SDK for a MetaMask like tool to more easily connect. We wanted to learn a lot more, such as how is this sidechain peged, what role is plasma playing here exactly, and so on. Thus we held an interview with Ritik Malhotra, Co-founder and CEO of Elph and Tanooj Luthra, co-founder and CTO.

How is this a sidechain? A sidechain means a new blockchain where tokens are transported through a peg of sorts.

Luthra: Yea, so we’re running a separate blockchain, with a plasma bridge to Ethereum. By deploying these contracts on ETH, users can deposit funds into these contracts, our blockchain will listen for events and credit a user appropriately on our custom chain. Once a user has funds on our blockchain, they can transact however they want, while still having the option of withdrawing their funds through these contracts on Ethereum at any time.

“Our blockchain will listen for events and credit a user appropriately on our custom chain.” How does it do that?

Luthra: If you take a look here, we have our deposit function on Ethereum. The important part is a little bit further down where we call emit Deposit. That fires an event on the Ethereum main chain. Our blockchain is listening to all events that are fired from this contract, which is how we know when to credit a user on our blockchain.

How is your blockchain listening to those events?

Luthra: We use a websocket connection to an Ethereum node, and subscribe to all events from our contract.

So what prevents you from not listening to events?

Luthra: Technically nothing, however, if we don’t credit a user funds on our blockchain, they can at any time withdraw their funds from the same contract it was deposited to. Because of the plasma guarantees, even if us as operators behave maliciously (not listening to events, sending illegal side chain txs, etc.) users always have the right to withdraw their funds by proving they are the correct owners.

Plasma is not a sidechain, why is Elph?

Luthra: Plasma is a framework for building scalable applications, our sidechain is a plasma sidechain in the sense that we have all of the plasma framework’s guarantees around security.

Plasma is a second layer on eth, a sidechain is a sidechain. Plasma doesn’t need a sidechain, why does Elph?

Luthra: Sidechains are useful to get significantly more scalability than just a root chain (in this case ETH), however the issue with most sidechains is that trust needs to be placed in the operators of this sidechain. Plasma enables our sidechain to be trustless. We get the benefits of a sidechain (fast transactions, lower fees, etc.) without sacrificing any of the security tradeoffs that have historically been associated with sidechains.

Malhotra: So the best model to think about this is to imagine Plasma as a set of smart contracts that live on Ethereum, which a sidechain can work with (by listening to events and calling functions on the smart contracts).

There are also several other terms for the “sidechain” that people use, including “child chain”, “operator”, etc. which can make the terminology a bit confusing. You’re right in your definition of sidechains being separate blockchains that have a peg to another blockchain. This definition is not incorrect with respect to the Elph sidechain.

What we mean when we say “Plasma sidechain” is the combination of these two concepts. The Plasma framework is applied to the Elph sidechain so that the two-way peg the sidechain holds is trustless. Let’s go through a few cases:

1) If the sidechain does not listen to the Ethereum blockchain, user funds are not lost. The Plasma smart contract that lives on Ethereum allows a user to withdraw their funds that they deposited into the contract. They simply just call a function on it.

2) If the sidechain goes down, user funds are not lost. The Plasma smart contract on Ethereum allows a user to withdraw their funds by calling a function on it.

Plasma is linked to eth through a hash, how is eth linked to Elph?

Malhotra: Could you give me a bit more specifics as to what you mean by “Linked to ETH through a hash”?

As in once the funds are locked, hashes are exchanged which keep accounts, with those hashes kind of running on eth.

Malhotra: I think you’re referring to hashes that are published to the Plasma smart contract that lives on Ethereum. Those hashes are generated by the sidechain (or child chain, operator, or any other term people use to refer to the off-chain transaction processing tool) and sent to the Plasma smart contract, which stores them on Ethereum. Those hashes guarantee that a user can withdraw their funds, based on their most recent balance on the sidechain. (Note that there’s plenty of technical details here that we can go into to describe how these hashes are generated and why they work as stated).

Ethereum is not linked to Elph in the sense that no Ethereum miner or node needs to run any special software to communicate with Elph. The beauty of the Plasma framework is that only Elph sidechain nodes need to be able to listen and communicate with the Ethereum chain in order for all this to work. You may be wondering “how is this possible?” That’s a fair question and much more involved — I would highly recommend reading LearnPlasma.

Is the Elph node out?

Malhotra: Not yet, we’ll have this released in November for everyone to try out (with the appropriate instructions and documentation). For now, we’re running it in a private testnet ourselves to battle-test and benchmark.

So everyone will be able to run an Elph node?

Malhotra: Eventually, yes. The goal from a product perspective is to have developers be able to choose certain configurations for the sidechain that they want to run their dApp on. Some of those options including choosing the number of nodes validating the sidechain and the consensus mechanism used across the validators. So, for example, if there are 1,000 users running an Elph node, and the developer decides that she only needs 20 nodes to validate her dApp’s sidechain, the Elph Protocol will appropriately select 20 from the 1,000 running the nodes to validate that dApp’s sidechain.

So you can imagine if we have 50 dApps on the platform, each with 20 validators for each dApp’s sidechain, all 1,000 nodes will be utilized. And if you had 100 dApps, the requirement doubles — so each Elph node may be validating two sidechains at the same time.

So what would you say are the weaknesses of this approach?

Malhotra: One tradeoff is that there may be slight overhead for a developer to modify their smart contract / existing app logic to start using our sidechain. Our goal is to minimize this by giving them the appropriate tooling to do so easily.

How would you pre-empt your critics?

Malhotra: 1) We have something that’s working live, which many teams are far from producing. Our goal is to be pushing product out for people to see and use. We have our open source repositories, block explorer, and demo out. The downloadable node in Novemeber. And further product updates in the coming months scheduled as well. Our take is that it’s easy to critique with words, but producing something that’s functional trumps a theoretical whitepaper.

2) Some folks believe may say that Plasma-related techniques are new and untested. We think that’s a fair point and is why we’re investing so much into running a testnet to find the bugs — privately at first, then publicly. And investing into working on expanding our automated code testing suite.

3) Some may say that it’s better to work off a completely different blockchain (e.g. use EOS over Ethereum). While that preference is left to the developer, we have plenty of data proving otherwise. There’s an order of magnitude more developers (and, as such, much more robust developer tooling) on and using Ethereum vs. the next smart contract platform. There’s also many more dApps that have already started building on Ethereum. This makes it critical to work on a solution that works with Ethereum with minimal friction (hence why we’re creating tooling to make it as easy for developers to use their existing smart contracts as possible). Moving to another blockchain like EOS requires a large overhaul from a developer’s perspective — you have to understand a new ecosystem and its APIs, completely rewrite your smart contracts and app logic to work with it (huge requirement for time + effort).

Was thinking more of a critique by say Emin Gün Sirer. If we take a simple layer wish some security guarantees like the lightning network, we have the hash that kind of has some ground on the public blockchain. Where’s the ground here? As in, how does eth know what’s going on in the sidechain? The user might not lose funds because he can withdraw them, however there have been say 1,000 transactions on the sidechain. How do they link in a trustless manner?

Malhotra: For those 1,000 transactions, the sidechain publishes an update hash to Ethereum’s Plasma contracts. That hash validates that the state of accounts after the 1,000 transactions is valid. Anyone can check that on Ethereum by calling one function on the smart contract. You may say “but what if the sidechain doesn’t publish the hash?” First, if there are several nodes validating the sidechain, this makes that probability extremely low. But let’s say that it does happen. If the sidechain is not publishing the hash every few seconds, users can withdraw their funds and decide to abandon the sidechain. The validators running nodes for the sidechain also would experience a loss of funds that they’ve staked (slashing). There is no loss of funds for the users of the sidechain. And none of the transactions on the sidechain are considered valid so the only loss is that a few seconds are wasted.

So to your questions: “As in, how does eth know what’s going on in the sidechain?” -> Ethereum knows because of the hashes published by sidechain validators back to Ethereum. And if those hashes aren’t published every few *seconds*, users can withdraw and abandon the sidechain immediately.

With LN, you can publish an older hash, can the same be done here? As in, Alice sends 1,000 transactions, and then goes back to try and spend the first hash which now has a far bigger, but conceptually spent, balance.

Malhotra: No, that’s not possible. Hashes have timestamps associated with them that are recorded on the smart contract on Ethereum. This protects against using older hashes as the source of truth to send transactions from an older balance.

Luthra: Yea, the guarantees are much more nuanced than LN in my opinion. There is nothing that prevents you from making that transaction that does a double spend, however, because the root chain was being published to periodically there is a guarantee that a double spend cannot happen. Let’s break it down into a few more steps:

1) Alice deposits 5 ETH into the sidechain
2) Alice sends 5 different transactions each of 1 ETH all to Eve
3) Each transaction was included in a sidechain block
4) Each block root hash was published to Ethereum
—- Up until now this is totally valid behavior, and is expected
5) Alice tries to send 1 ETH again to Bob! (double spend)
6) At this point, Bob can actually check the Ethereum smart contract for the status of this specific 1 ETH.
7) Bob finds that this 1 ETH was already spent, and Alice isn’t the official owner anymore.
8) Bob knows that Eve was the rightful owner of the 1 ETH, and he can’t withdraw it because the root contract guarantees that Eve is only one who can withdraw the 1 ETH
9) This ‘double spend’ transaction becomes a no-op in the sense that Alice basically never sent anything to Bob since he can’t withdraw

Are you saying there are no weaknesses?

Luthra: None from a security perspective, there are some usability tradeoffs that might accompany plasma sidechains in general. Right now to do a withdrawal users need to submit an exit, wait for a fixed period of time for any challenges to come through, and then they’re allowed to take funds out.

There’s also some questions on the total amount of information users will need to store. For example, when Alice sent the first ETH to Eve, and then tried sending it to Bob. Bob has to have save some information (or get it from the root contract/side chain) about that specific ETH token. With extreme usages the amount of information required might be very large.

There’s potential solutions to both of these, but then the issues are just about more complexity and more systems that are required to keep everything and everybody in check

There’s also the question of capacity. Like how is routing performed?

Luthra: Routing of what? there is no routing in the Lightning Network sense, it’s more like just Ethereum where transactions are broadcasted and then included into blocks.

There is somewhat of a question of capacity in what’s referred to a ‘mass exit’ situation. If a few people detect malicious actions by the operator, they’ll start withdrawaing their funds, and then soon everybody else will as well. In one of these situations the rate of people leaving the sidechain is limited by the number of transactions being done on the root chain (Ethereum).

Routing of the hashes in the sidechain. Like, how does the 800th tx hash know how to get to whoever?

Luthra: The transaction hashes don’t need to be sent to the recipient, the recipient in fact doesn’t need to even be online to receive funds on a plasma sidechain. It behaves exactly like ethereum, anybody can broadcast a transaction, and once it gets included in a block, the funds are now owned by the recipient

So then, why can’t ethereum’s first layer do that? What’s special in the second layer or sidechain that adds capacity?

Luthra: The cool special part is that not everybody needs to be aware of every transaction. If people on a sidechain have 1k transactions amongst themselves, and they do not need to interact with anybody on the Ethereum network, all of these transactions can stay completely isolated. They don’t need to be globally run by all Ethereum nodes. Only when one of those people wants to take their balance out of the sidechain, does 1 transaction representing a ‘withdraw’ need to happen.

The first layer builds the global web of security that the second layer heavily relies on, but the second layer can be more targetted. For example, if starbucks started accepting ETH payments, they could run a sidechain and accept funds with the network of people who visit starbucks. The information about this never needs to be broadcasted throughout the rest of the Ethereum network, unless someone on the sidechain wants to take their balance out.

But how do you trust the information that is not broadcast on the public chain?

Luthra: Because you’re constantly verifying that the block hashes are being published to the root chain, and if you wanted at any point you can withdraw to the root chain and a single block hash contains proof for thousands of transactions that occurred then.

The end result is recorded, we have no clue what happened in between.

Luthra: It’s not the result that’s recorded, it’s a merkle root that contains every single transaction hash that occurs in that block. And this happens every block. So if you want to see if a specific transaction occured and a balance changed you can verify this directly against the merke root that was published.

FIN

A Plasma sidechain running on eth sounds like an interesting approach. A merkle root of all the hashes, stored on a smart contract, with public nodes verifying what’s happening on the sidechain, sounds like a fairly trustless and decentralized set-up.

So it may well be the road to scalability has begun as ethereum now prepares for mass adoption in usage.

Copyrights Trustnodes.com

 

Leave a Reply

100000
  Subscribe  
Notify of