Technical Guide | Plasma Core Certification Structure and Inspection

Unlike traditional blockchain systems, a complete Plasma node does not store every transaction, they only need to store information about the assets it owns. This means that the sender must prove to the recipient that the sender actually has the given range. A complete proof contains enough information to ensure that if the Ethereum chain itself does not fork, the token can be redeemed on the main chain.

The root hash must be checked against the block hash that the operator submitted to the smart contract on the main chain. By tracking the chain of custody verified in the proof scheme, the redemption ability is guaranteed from the initial deposit of the token.

Plasma Core uses a relatively simple method to verify incoming transaction proofs. This section describes the method.

Proof Format

• Interview | Kevin Kelly: Blockchain is a great tool, but it doesn't necessarily change the world
• The joint petition deletes the signature of the copyright document, and who has become the eye of Ou Bencong
• 5.27 Market Analysis: Bitcoin accelerates the upside, how will the follow-up market develop?

The historical proof includes a set of deposit records and a long list of corresponding transactions and the corresponding TransctionProofs.

Plasma-utils exposes a static checkTransactionProof(transaction, transactionProof, root) method, and Plasma-core uses it by calling ProofService.

Transaction Proof

The TransactionProof object contains all the necessary information to check the validity of a given Transaction. That is, it's just an array of TransferProof objects. According to the above section on atomic multiplication, a given TransactionProof is valid if and only if all TransferProofs are valid.

Transfer Proof

TransferProofs contains all the necessary information needed to recover a valid branch corresponding to a given Transfer in a transaction in the correct block number. This constitutes:

1. The actual node of the Merkle sum tree, representing the complete `inclusionProof` of the branch
2. The index of the leaf used to calculate the binary path of the branch trace
3. The parsed bottom.sum described in the sum tree specification above
4. Specific sender's signature

Just like the plasma-utils architecture:

Note that inclusionProof is a variable-length array whose size depends on the depth of the tree.

Proof steps

Starting with deposits, the core of the verification process is to apply each proof element to the current "verified" state. If any proof element does not result in a valid state transition, we must reject the proof.

The process of applying each proof element is public; we only apply the transaction in each block according to the regulatory rules of the contract.

Snapshot object

The way we track history ownership is called snapshots.

The snapshot represents the verified owner of the range in the block:

Deposit records

Each received range must come from the corresponding deposit.

A deposit record consists of its token, start, end, depositor, and block number.

For each deposit record, the verifier must carefully review Ethereum to confirm that the alleged deposit did occur and that no exit occurred during this period.

Verify that the snapshot array will be initialized to these stores, and each snapshot.owner is a store.

Next, we apply all the proof of the transaction and update the verified snapshot accordingly. For each transaction and the corresponding TransactionProof, the validator performs the following steps:

1. Verify that the given certification element is valid. If not, prompt error
2. For each transfer in a transaction, do the following:

a. "Split" any snapshots updated on transfer.typedstart, transfer.typend, implicitstart, and implicitend.

b. Increase the .block number of all result verification snapshots, the block number of these snapshots is equal to transaction.block number-1;

c. For each split snapshot between transfer.start and transfer.end:

i. Verify snapshot.owner==transfer.from. If not, throw an error.

Ii. Set snapshot.owner=transfer.sender.

TransactionProof must be applied to the incremented BlockNumber.

Once the operation is recursively applied to all transaction proofs, the customer can check for new coins that they now own by searching for all the elements in the verified snapshot (the block number is equal to the current Plasma block and the owner is equal to its address).

Transaction Proof Validity

The transaction validity check in step 1 above is equivalent to checking the validity condition of the smart contract. The basic validity checks based on the above and tree specifications are as follows:

1. Check if the transaction code is in the correct format.

2. For each transfer and corresponding transfer proof:

a. Check if the signature is resolved to its transfer.sender address

b. Verify that the root of the inclusionproof is equal to the root hash of the Plasma block and the binary path defined by leafindex.

c. Calculate the implicit start and implicitend of the branch and verify implicitstart<=transfer.start<transfer.end<=implicitend

This article reprints the public number: Blockchain Research Laboratory

The content of Haina College will be centered on: blockchain technology, product community, economic model and other comprehensive knowledge system output.

Feel free to contact the author WeChat: csschan1120

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