Technical Guide | Understanding the Generalized Plasma Technology Structure – part I

Brief

Most developers today just want an easy-to-use way to extend their dapps. People need good tools and a fully documented library. Of course they don't want to build the entire blockchain from scratch to run a single application.

So, we started creating a platform that made it easy to build scalable blockchain applications without having to become a Plasma expert. We ended up with a generic Plasma chain on which you can build applications (or "plapps"). Sounds weird?

Layer 2: Status Statement

The core idea behind "Layer 2" is that we can use data outside the main blockchain ("out-of-chain data") to provide guarantees for assets on the main blockchain ("chain data"). For example, out-of-chain data may give you the right to extract assets held in a escrow contract on the Ethereum chain. But the ownership of the asset changed without touching Ethereum.

Of course, out-of-chain data is useless unless interactions may eventually occur on the main blockchain. This is usually done by allowing the user to submit a "claim" for out-of-chain data to an in-chain smart contract that holds the claim asset. This statement may be similar to "I have a signed message saying that I can extract the asset X."

• Third-party code auditing and testing of Algorand test network: mature system and good anti-attack
• Technical Guide | Specifications for Plasma Cash Block Structure
• Introduction to Blockchain Technology | Atomic Exchange

However, what happens if the person making the above claim sends a message to send the asset X to someone else after submitting the claim? This will invalidate the above withdrawal. To ensure that any such invalid withdrawals are unsuccessful, we will add a dispute period to each claim. Anyone can challenge the claim before the end of the dispute period. Otherwise, the statement is considered valid. Very simple!

The Plasma chain consists of a series of blocks, each consisting of a series of transactions. Whenever a new Plasma chain is created, the encryption commitment for that block is posted to the main chain. These promises can be used to prove what is in that block. In our case, this promise is the merkle root created from all state updates in the block.

The Plasma Smart Contract on Ethereum records the order in which operators submit Plasma blocks and prevents promises from being overwritten. When a user wants to make a claim for something happening on the Plasma chain, they must also reference the time at which the event occurred by the block number. For example, the user might say, "This is transaction X in block Y, which gives me the asset Z." This extra time dimension is also important for controversy, because sometimes you want to know before or after something else happens. whats the matter!

Under-chain data theory

As we have just seen, the second layer is mainly about using some extra-chain data to influence the content on the chain. So far, out-of-chain data is mainly used to represent ownership – who owns what it is and whether it changes hands.

Alice will deposit an asset into Ethereum's smart contract, and she will become the owner of the asset. She can then sign an out-of-band message that transfers ownership of the asset to Bob. Bob can then use the signed message to make a claim to recover the assets on the Ethereum.

We can also represent something more complicated than ownership. Let's say Alice stores a CryptoKitty and signs a series of messages that change the color of the cat's fur. As in the example above, she can finally use the last message she signed to declare the kitten's fur color on the Ethereum!

Whether it's changing the kitten's fur color or eye color, the smart contract that goes back to Ethereum needs a way to understand these changes. Every new feature – or a new type of "state transition" – needs to change the logic behind the Plasma contract. In the previous Plasma specification, adding such functionality meant that the entire *Plasma contract had to be redeployed and everyone's assets moved from the old Plasma chain to the new Plasma chain. This is not safe, scalable or not upgradeable.

Predicates: use the Plasma instructions

We entered the Plasma chain design and we wanted to add new features, and we encountered this scalability issue. After some brainstorming, we realized that there is an easy way to add new features without changing the main Plasma chain contract.

So far, all the various scenarios we've discussed have something in common – out-of-chain data is always "arguing" for incorrect claims on the chain. A dispute over a particular claim is basically just evidence that the statement cited in the claim is outdated. The dispute over ownership proved that the user who filed the claim later transferred ownership to another person. The controversy about the color of the cat's fur needs to prove that the cat's fur color has changed.

Our main breakthrough is to recognize that dispute conditions do not need to be checked in the main smart contract. Instead, we can let other smart contracts implement a function that tells us if the dispute is valid. We can add new functionality by creating a new contract that implements the logic necessary for this functionality and then lets our main contract reference the new contract. We call these external contracts "predicates."

Adding new features is easy now, but we still need a way to know which assertions are used for specific state updates. The statement about the color of the kitten's fur cannot be disputed by changing the color of the kitten's eyes. So how do we know which predicates to use?

simple! We just added a status update and also stated which predicates it was subject to. Now, the update message to change the color of the kitten's fur may be, "I'm turning the cat's coat color blue, and the controversy can be handled by the predicates at (0x123 …)"

Since users can specify any predicates addresses they want, anyone can add new features to the Plasma chain at any time by deploying new predicates on Ethereum. Predicates are much more than dealing with disputes, but we will discuss this later. The important thing is that predicates only need to implement a standard interface, which is defined in the next section.

This article reprints the public number: Blockchain Research Laboratory

The content of Haina College will focus on: blockchain technology, product community, economic model and other comprehensive knowledge system output, welcome to contact the author WeChat: csschan1120

We will continue to update Blocking; if you have any questions or suggestions, please contact us!