Comprehensive understanding of ethereum expansion: Plasma

The original article is from Unitimes. It takes about 10 minutes to read.

Plasma (1) : a zero-base introduction

Extending ethereum is an unprecedented challenge, and Plasma is a Layer 2 extension framework designed to increase transaction throughput.

What is Plasma? How does it work, and what is the state of the art?

Introduction to the

In August 2017, Vitalik Buterin and Joseph Poon published the Plasma white paper, presenting a new and promising solution to the world. The solution aims to increase the throughput of cryptocurrency transactions and solve the congestion problem that has long plagued users. As if overnight, Plasma became the most popular Layer 2 extension framework in the ethereum ecosystem. In the end, Plasma is basically a running joke.

Of course, it's still a great and exciting thing to do. Unfortunately, Plasma's fast-paced evolution and technical complexity make it difficult for those not directly involved in research and development to grasp its essentials. For outside participants, you may have more questions than answers: what are the capabilities of the Plasma chain in reality? What obstacles do we still face before we see Plasma come to life and work effectively? What are the trade-offs for Plasma? How does it work?

The first part of this series will cover:

1. Plasma is the theoretical basis of Layer 2 technology

2. Explained the internal working principle of the first specific Plasma specification, "minimum viable Plasma (MVP)"

Background overview: Layer 2

The family of protocols we call "Plasma" is actually a subset of the Layer 2 solution for the blockchain scalability problem. The "scalability issue" here refers to the limited trading capacity faced by the block chain that is open and does not require permission to enter. Layer 2 tries to get around this bottleneck by making (certain) transactions final without touching the blockchain itself.

If you want, you can think of the Layer 2 transaction as a check. The funds in the checking account can be verified directly without actually being deposited into your bank account. Such a check can be effectively processed as paper money and delivered directly to the other party for payment -- provided that the next party to receive the check has the ability to self-verify the validity of the account's funds (just roughly speaking, to claim credit).

The general pattern for the Layer 2 system is that, initially, a certain amount of money is locked up in the base Layer of the blockchain (presumably ethereum, same below). Next, other participants (not necessarily the same party that made the deposit) can trade down the chain through the upper system with the locked funds and only occasionally interact with the main chain, if at all. At any given time, the owners of any capital can pull out all the money they have.

The defining attribute that differentiates Layer 2 (because we're using this term) from other payment systems down the chain is this: while avoiding ongoing base Layer interactions, Layer 2 transactions retain the decentralized and trustless security guarantees we expect from Layer 1. Through properly keep personal private key, and the necessary software, you can guarantee: whether counterparties to be evil, personal money must always keep in your hand, and it is safe in the main chain - the "counterparty" may be individuals, institutions, consensus mechanism or any other you can't control factors. Even in a nightmarish, conspiratorial world of the Truman show, where all the other users of the system conspired to steal your money, they would fail.

Why is this technique called & NBSP; Plasma?

In the past few years the & NBSP; Layer  2 & have spent In research and development, a kind of classification emerged gradually. In this way, we skillfully combine the & NBSP; Layer  2 & have spent Mechanisms fall into two categories: "Plasma" and "channel technology" (such as "status channels" or "payment channels").

The first way to distinguish the two categories is to determine the minimum number of transactions required on the chain: in channel technology, the finalization of a channel transaction does not require any interaction with the main chain; As for & have spent Plasma  Transactions, which must have one interaction with the main chain (by & NBSP; Plasma  Operators, not users, broadcast, as described below.

Plasma  It's defined as & NBSP; Layer  2 & have spent The extensibility solution (despite the need for regular on-chain transactions) is due to the fact that at & NBSP; Plasma  Every stroke of the pen & NBSP; Layer  1 & have spent Transactions can effectively complete multiple transactions at one stroke. You can imagine a pile of & NBSP; Layer  2 & have spent A transaction is compressed into a transaction. Still, it appears to be a scaled-down version of channel technology. No block validation on the chain means (almost) instant finalization, and as little interaction as possible on the chain is usually a good thing.

On the other hand, channel technology requires that all channel participants fully agree to status updates of any channel scope, which means that a single channel with multiple parties is difficult to implement in practice. When you need to trade with participants who don't share the same channel with you, you need to "forward" the trade through your channel partner. As a result, your financial activity will be limited to people whose liquidity path you can map to.

However, at & NBSP; Plasma  Only the sender of the transaction needs to say yes or no. In addition, all relevant participants do not need to perform liquidity lock-ins/restrictions to enter, exit, and trade freely (" who needs to agree to status updates "also turns out to be the equivalent of distinguishing" channel technology "from" Plasma ").

Thus, on the one hand, we can say that channel technology is more suitable for applications that rely on the just-in-time finalization feature, and that have a relatively fixed set of actors that interact, whereas & NBSP; Plasma  More suitable for scenarios that involve multiple participants, emphasize high transaction throughput, and have relatively low importance to nail down features in real time.

Minimum viable Plasma

Although the initial white paper only covered the overall concept of Plasma, the concept was broad and ambitious (and, frankly, extremely long). Some of the ideas mentioned in the white paper, such as nested Plasma chain trees, are still outside the scope of current Plasma research and may not even be implemented.

Thus, the first important step in getting real working code is a specification called minimal viable Plasma (MVP). Minimal viable Plasma, as the name implies, aims to filter out all the fancy features and refine everything into the simplest possible implementation. "Feasible" here means that it must simply satisfy the above definition of layer&cake; 2 & have spent The Plasma system is basic, and has only A minimal amount of functionality, namely A replacement asset from A to B (presumably ethereal, but also available for other erc20-compliant tokens).

As we mentioned earlier, the key property of Plasma is that multiple transactions are compressed and finalized, and only one transaction interacts with the main chain. In MVP, "compression" is done through the merkeltree: the trades are combined and merkelized to get a root, which is placed at Layer  1. The transaction itself follows a bitcoin-like UTXO model. That is, the transaction takes inputs that are authenticated by the sender and creates outputs that are affected by the new owner's public address. That said, a Plasma chain is itself a blockchain! By using the necessary off-chain Plasma block data and merkel-root data on the chain, users can verify their legal rights and rely on ethereum's on-chain smart contracts to enforce rules and resolve all disputes.

The entity that will be responsible for carrying out the above processes (i.e. merkelization transactions, broadcasting roots, and sharing data with users) - the Plasma "block creator" - will be called Plasma operator. Notably, Plasma itself has no idea what kind of operator it is: it can be a single "centralised" entity, an affiliate side chain, and a block authentication system based on proof of interest. The fundamental goal of the Plasma structure is that all fund management needs no custodial support. And in the Plasma implementation, this factor should remain the same regardless of who is responsible for creating the chunks. A more "decentralized" mechanism might bring other benefits associated with distributed peer-to-peer systems, such as censorship resistance, fault tolerance, and so on -- but the no-hosting nature would not change. Therefore, for the sake of simplicity, let's assume that the operator is just a single entity to derive the Plasma mechanism more explicitly.

First of all, Alice  Store the ether currency in the & cake by sending an Ethernet currency transaction on the chain to the contract; Plasma  In the chain, the operator includes the transaction in & NBSP; Plasma  In the block. These ethereum COINS were initially priced with a & NBSP; UTXO  The form falls into the category & NBSP; Alice. As usual, Alice wants to pay Bob. It doesn't have to be a chain deposit, and maybe he never will. UTXO, & have spent And for & have spent Bob  Create a new & NBSP; UTXO  And send this transaction to the Plasma operator. Operators combine this transaction with other (possibly unrelated) transactions into one & NBSP; Plasma  Blocks, and "merkelize" them to get a merkelroot, and then (and only) send that root to the main chain.

Then the operator sends this & NBSP; Plasma  The block is sent to all users (including & NBSP; Alice  And & have spent Bob). After receiving the latest block, Alice  And & have spent Bob  Verify them individually. This verification process is designed to ensure that the transaction itself is valid and that the block corresponds to the merckle root on the blockchain. If all goes well, then   Alice, Bob  And other users can continue to live happily ever after.

However, if at this point Alice feels she's had enough of this crazy Plasma business -- she wants to get her money back into the ethereum chain -- she can initiate a "withdrawal request" by sending an in-chain transaction (note: this withdrawal request does not require permission from the operator). In this transaction, she needs to include the UTXO of the Plasma chain she wants to withdraw, as well as the number of the Plasma block to which the UTXO belongs and the merkle path to prove the inclusion process. Now she must wait for a "contentious period" (let's say a week) before she can get the money through. During this time, other users can challenge Alice's exit if they detect a request foul.

This can lead to two things:

(1) & have spent Everyone is happy: everyone involved is honest.

In & have spent Alice  At the start of the exit, other users browse their own copies of the Plasma chain to check and verify & NBSP; Alice  Trying to quit & & NBSP; UTXO  It actually still belongs to her. They also validate all blocks in other ways. Plasma  Alice  She can only leave with her own money, other users' money is safe.

(2) & have spent It's outrageous: Alice  Is the bad guy

Now, we might as well replace the ending of the previous scene: Alice  "Was" correct enough "to be initially accepted by the smart contract. In other words, it was a valid deal, and Mrs Merkel proved that it did indeed correspond to the old merkel roots - but it was really a double cost. This means, Alice  Try using her earlier send to & NBSP; Bob  The same & have spent UTXO  To exit.

But it doesn't matter! Bob (or any other user) has a week to take action. He checks against his Plasma copy & NBSP; Alice  The & have spent UTXO, and note that this is a double cost. To prove it & NBSP; Alice  For his crimes, he submitted a "certificate of fraud". This proof involves & NBSP; Alice  Used to cost related & NBSP; UTXO  The old deal, as well as the expense deal, is included in the & NBSP; Plasma  Block merkel proof. Due to & have spent Bob  Given & have spent Alice  Cryptographic proof that the money has been spent, therefore. Alice  Caught red-handed, her request to withdraw the funds was cancelled.

A description of "punishment"

At this point, we might want to further punish Alice's attempted crime in some way: creating a credible threat to her that would cause her even greater loss, ideally nipping such behavior in the bud. These penalty mechanisms are typical of channel structures. For example, at & NBSP; Poon - Dryja  In the payment channel (the payment channel structure currently used in bitcoin's lightning network), trying to cash in an overdue transaction and getting caught will result in all your channel money being transferred to the counterparty. Although the punishment at & NBSP; Plasma  Neither is absolutely necessary in either the channel technique, but plastic & NBSP; There is a stronger demand for such penalties. If the concept of punishment is absent, then Alice may repeatedly attempt improper withdrawals, forcing & NBSP; Bob (or another participant) has to pay gas each time to respond. The irony, however, is how the & NBSP; Plasma  Such penalties are not so easy to impose. To cut back on; In & have spent Plasma  The money in the chain, we need to determine what belongs to the & NBSP; Alice, this requires a claim/dispute window mechanism -- let's go down this challenging rabbit hole.

Therefore, Plasma  The structure usually requires & NBSP; Alice  "Exit the mortgage" when trying to withdraw cash. At its core, it's a big deal. "I want to withdraw five ether COINS. If you find that my exit certificate is fraudulent, you can take an ether coin from me as a penalty." We are free to set the terms of the contract, that is, the size of the collateral required and the response to a particular infraction (such as giving the deposit as a reward to the doubting participant, or cutting it to zero, or covering only the doubting participant; Gas  Cost, etc.) and adjust its leniency/severity to personal preference.

Tragic situation: evil operator

So far, things have gone relatively smoothly. This is largely due to the simplistic assumption that operators have everyone's best interests at heart. Now it's time to consider the scenario we don't want to imagine: what if the operator is a complete fraud and thief?

Like, ice  And & have spent Bob  Are developing their business. One day, they discovered that the operator had sent them a block. Merckgen in this block has been authenticated on the chain, including a nakingly invalid transaction, such as spending & NBSP; Plasma  90% of the ether on the chain. Recall that the operator was solely responsible for creating the block, so he could theoretically include anything he wanted. Worse, the operator then demanded that the invalid transaction be used for chain withdrawals.

With & have spent Alice  The fraud in this case is different because it's just & NBSP; Alice  Trying to do a double cost, and this deal costs a "UTXO" that doesn't even exist. Therefore, we are unable to use the previous doubt and withdrawal scheme.

It might be tempting to think that we could construct a different kind of proof of fraud to deal with this different kind of malpractice: "if we ask the operator to prove the input & NBSP; UTXO  Is existence ok? And if this & NBSP; UTXO  It comes "out of thin air," so we can demand proof of this & NBSP; UTXO  Is it legitimate?"

In this case, fraud certification can be complex and may even be unrealizable. But even exploring this route is pointless and futile because it will eventually run into bigger problems. Since we assume there is an evil operator, let's go for it -- not only does the operator create an invalid deal and try to cash out, but it never even shares the invalid Plasma block with its users. Alice, Bob and the other participants are now presented with a highly suspicious exit request that contains a huge amount of money, but they have no idea of the details.

So what now? How do we make sure our operator doesn't run away with money that doesn't belong to him? In this terrible situation, we turn to & NBSP; MVP  Since we cannot directly prevent operators from exiting, we can allow other participants to exit first: the smart contract is responsible for enforcing an exit queue and ensuring that the previous & NBSP; UTXO  Exit first. So as long as everyone -- and yes, everyone -- USES the Plasma chain to withdraw their money before the operator's massive withdrawals are complete, the ether that the operator is trying to steal will be emptied, and his malicious attempts will ultimately fail.

Theoretically, the scheme works. Users keep their money, no matter what the other participants do -- that's our goal. But let's be honest: it's far from ideal for malicious operators (or, more likely, hacked/compromised operators) to use no more than one transaction to force all users to withdraw the main link within a certain period of time. In fact, in the really worst case scenario, if the main chain block is congested long enough, users may not be able to exit in time, and thus may actually lose their money. In theory, we could reduce the number of trades required for a large exit with more advanced exit strategies - such as combining lots of trades by signature aggregation - but this is still an open research question. Even if this is an effective solution, it requires coordination and collaboration among users, so it is still suboptimal.

But & have spent MVP  There is another (arguably) more serious flaw in the structure. Even in a happy scenario, we require all users to fully validate the whole & cake; Plasma  Chain. This puts us on a availability catch-22. Plasma  It is useful in expanding ethereum's transaction throughput, but Plasma  The higher the transaction throughput per second provided by the chain, the greater the burden on the client in terms of bandwidth and memory. Recall that one of the key advantages of the Plasma architecture is that it can easily support many users, and limiting its user base to those who can only run large applications can seriously undermine its value proposition.

Plasma (2) : discussion on Plasma Cash

Let's return to the MVP forced mass exit loophole: in a sense, the root of the "problem" lies in the fungibility of the assets discussed in this article. Let's say Bob "owes" five ether COINS. Since ethereum is an alternative asset, it makes no sense to talk about which specific ethereum Bob owes. For this reason, in our "tragic case" where the operator attempts to exit with more than his share, we cannot clearly determine "whose ether currency he stole". Ethereum is ethereum, so what the operators are stealing is money from the collective Plasma pool. At some point, therefore, other users will have to pull money out of the Plasma chain.

So, is there a way to specify the owner of a particular "block" of ether COINS?

Plasma Cash!

Plasma Cash, a variant of Plasma structure, has become the basis for most of the research on the Plasma community since its birth. It USES a "minimum viable" approach similar to MVP, but adds a new limitation from the start: all assets in the Plasma Cash chain are irreplaceable tokens. A NFT (we call it the "c") can represent anything: the etheric currency denomination, a fixed ERC - 20 tokens, a bundle of ERC - 20 tokens, a nest of mystery love cats, or be able to continuously created 100 block in Plasma chain Plasma operators rights (disclaimer: I don't know what are the consequences of doing so, suggest don't imitation), etc. The only requirement is that the thing represented above can be expressed as an erc-721 asset. In other words, this thing is inseparable or merged, and unique.

Plasma Cash ditches the bitcoin-like UTXO trading model in MVP. For irreplaceable COINS, the concept of creating new transaction outputs no longer applies. Instead, each coin in each Plasma block needs to be accounted for: the presence of a coin indicates a change in the ownership of the coin in the Plasma block (that is, Alice sends it to Bob); The absence of the coin means that the owner of the coin is still the same as the owner of the previous block. Thus, the full history of a coin can be described by its presence in each Plasma block -- we simply traverse the current block all the way back to the block where the coin was first deposited.

As we shall soon show, the full history of a coin fully protects the ownership of its holder. And even better, in this model, the history does not need to contain all the data in each Plasma block: if Bob wants to prove that his COINS exist in a block, he just needs to provide the merkel-path for the transaction. However, to prove that the coin is not transferred in a block, Bob needs to be able to prove that the data is absent. This is a feature that the merckle tree, as we know and love it, does not support.

Therefore, in order to implement this "proof of absence" function,Plasma Cash USES the enhanced merkell tree structure we call sparse merkell tree (SMT). SMT is a merckle tree with additional special functions: each leaf of the tree (in this case, COINS) is given a unique identification number to determine the location of the tree in which they are located. Essentially, we sort the leaves so that each coin can only be placed in its own slot. This means that if the coin is absent, then we must know where it is; Conversely, if the coin is present, then we can prove that the coin has changed ownership by proving that the slot is' empty '(that is, equal to some null value, such as 0 or' undefined ', etc.).

So, since we can prove the existence of COINS in each block, we can track the full history of COINS, which might look something like this:

And so on.Crucially, the data needed to prove this history is only a paltry merkel-per-block, not the full Plasma required for MVP.

Now let's take a closer look at merkel's claim that the sequence is sufficient for the currency's current owners to protect their own money. In other words, as long as the user Steve has a complete history of his COINS (in the form described above), he is objectively assured:

1) if/when he attempts to withdraw money, he will be able to respond appropriately to any challenge.

2) if/when another participant attempts to withdraw his coin, he will be able to challenge and successfully reverse the withdrawal request.

In the example above, Steve is the rightful owner of the coin as of block 505. Want to stress a point here is that if Steve want to confirm your payment (in this case, is at the 504th block from another user Bill received payment) whether they have been finalised, he must first receive and verify a complete history of the currency (that is, to verify each block in the previous merkel proof). Then, and only then, can he really own the coin.

Now, let's take a look at all the possibilities and how Steve might respond (some of the solutions have a familiar formula for MVPS) :

Since Steve has established ownership of the coin in block 504, there are two ways for the perpetrator to steal Steve's coin, namely by claiming ownership in a previous or subsequent block.

For example, Alice tries to steal the coin in block 501 by broadcasting her "proof of existence." At this point, Alice justifiably states that the transfer taking place in block 501 is the latest and valid currency transaction. In other words, she never spent it again. Steve's response is essentially the same as Bob's in the "outrageous" case of MVP. He points out that Alice has transferred the money to Bill in block 502 (note that Steve cannot falsify this evidence because the transaction requires Alice's signature). Alice was caught red-handed and her request to quit was withdrawn. Again, because Steve has a full history with the currency, he knows he's ready to deal with any such fraudulent exit attempt.

Now, suppose Alice tries to withdraw her COINS from block 506 (after Steve establishes ownership of the coin). It should be noted that if Alice's merckle inclusion proves to be acceptable to the smart contract (i.e., Alice's hand and eye access), then the operator may have to include the invalid payment in block 506 maliciously and fraudulently. As usual, we assume that either operator could be malicious.

In this case, Steve responds by providing the transactions that took place in block 504. At this point, he stated that he not only owned the coin in the block, but that he could justifiably claim that he had not spent it since. Now, Alice is obligated to provide the transaction for Steve to send the coin to the other party, but Steve knows she can't do it because he knows he hasn't actually spent the coin at all (and he's been protecting his precious private key with his life). Again, Alice's exit request is revoked.

Although the examples above hide some tricky edge cases, these exits suffice to summarize the gist of Plasma Cash's execution rules.

Recall the tragic MVP case mentioned earlier: the operator stopped providing block data and then continued to attempt invalid withdrawals. This time, with Plasma Cash, the withdrawal process will consist of only one coin. Thus, in the case of wrongdoing, only the actual owner of the coin in question needs to act. Due to irreplaceable restrictions, the risk of withdrawal funds "spilling" into the asset pie of other users will no longer exist. This equates the risk of forced withdrawal with that of the channel center. If the Plasma chain does not work, the user will eventually exit. But such an exit would not entail any panic, time sensitivity or failure to force a mass exit.

Finally, let's take a moment to realize what we've learned: we've upgraded the MVP Plasma architecture so that users can now run lightweight clients and basically eliminate the ugly mass exit hole.

Does this mean we've found the Plasma silver bullet we're after?

Not exactly. First, although we've minimized the amount of data that each user needs to process, the amount of data is still huge. We can do some quick calculations. When a coin stays in the Plasma chain for a long enough time, the size of the single merkel of each coin in each Plasma block will become very large. Also, keep in mind that each payment means that the user needs to transfer the full history of the transaction to the recipient.

However, let's not forget the initial limitation we implemented with Plasma Cash: irreplaceability. This may provide enough functionality for some applications -- such as the NFT marketplace -- but ultimately, we expect Plasma assets to give users the feel and utility of real money. It's important to be able to spend your personal money in any denomination. Without this feature, the user experience of the payment network on the Plasma Cash chain could be like being in a cash-only restaurant where you don't have change and you just rip the check open.

Click to view the original article

Plasma (1) : a zero-base introduction

Plasma (2) : discussion on Plasma Cash

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia