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.
- Where can I find DeFi data? Here is your strongest strategy
- QKL123 market analysis | Bitcoin plummeted, "delivery day effect" pot? (0927)
- In 19 days, 44 policies are favorable, and the blockchain industry is accelerating into the fast lane.
- Wuzhen·Zhu Xi, Da Yu, Zhang Li, Dominic on Wuzhen, who is the future of POW and POS?
- Babbitt column | Yang Haipo: Bitcoin forks past events
- Report | Uncovering the currency circle to quantify team operations
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.
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.
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:
- The actual node of the Merkle sum tree, representing the complete `inclusionProof` of the branch
- The index of the leaf used to calculate the binary path of the branch trace
- The parsed bottom.sum described in the sum tree specification above
- 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.
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.
The way we track history ownership is called snapshots.
The snapshot represents the verified owner of the range in the block:
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:
- Verify that the given certification element is valid. If not, prompt error
- 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