DLVP DESIGN
We mentioned earlier that some Cross-Chain Technologies use SPV Technology, but for the SPV Technology to query the data of a Block, the nodes need to download the full Block Header Info. Of course, SPV can verify by randomly selecting all nodes to request the corresponding Merkle Branch Proof. Then, based on existing data data, SPV verifies the Merkle Branch Proof and verifies whether the locally stored block is consistent with the valid block information from the full node. The first step for DLVP is to use Random Sampling and MMR to verify whether there is a target block in the Blockchain. The second step is similar to SPV. The Validating nodes need to get the corresponding block header information to ensure that the Merkle Branch Proof is associated with the15 target block. The working principle of the Discrete Lock Verification Protocol (DLVP) is described below. First we introduce a new data structure called MMR (Merkle Mountain Range).
This is a variant of the Merkel Tree, the Leaf Node MMR is the block header, and the root of this MMR will be stored in B12. The MMR data structure can easily provide the Merkle Branch Proof corresponding to any block, for example, B12 corresponds to the Merkle Branch Proof from B0 to B11.
If the current Merkle Root Data is stored in block B12, a verification node needs to verify the B5 orange mark) contained in the end of the blockchain, then, the validator can generate a Merkle Branch Proof (marked in blue) and forward it to other Validators so other Validating Nodes can restore the Merkle Root Data. The Root Data recovered using the Merkle Branch Proof is compared with the
Merkle Root Data stored in B12. If the two root data are the same, it means that B5 exists in this Blockchain, if not, B5 does not exist.
Figure: Merkle tree of MMR structure
The first step of DLVP is to verify whether the target hash exists in the blockchain, this means that the aim is to verify that a middle block fits into the end of the specific blockchain.
For a blockchain based on “Proof of All” protocol, few resources are needed by nodes to verify the validity of a block. Only with the creation of a new block will large quantities of resources be spent. POW uses energy as a resource to fuel computational power whilst POS uses the percentage of coins held by a miner as a resource to generate more mining power.
In the event that an attacker is unable to control more than 50% of the network’s mining hash rate, said attacker will not be able to generate more blocks. Therefore, if the attacker wants to circumvent the validator, they will need to create malicious blocks. DLVP aims to prevent this by designing a sampling algorithm that will better enable the validator to detect malicious blocks.
The validator uses a small block header set to check the validity of the last block on the blockchain. For example, for a blockchain based on POW, the main resource used to validate blocks is computational power or hash rate.
If we state that the advantage of the honest nodes is α, the attacker will also be able to generate an α block when the honest node generates a new block.
See the figure below: Malicious block attack
Suppose that α = 0.4, when 5 blocks are generated by an honest node, the attacker will generate 2 blocks (in orange). In order to circumvent the validator the attacker will need to further generate another 4 malicious blocks (in red) to supplant the honest node. If the algorithm is able to discretely sample enough verification samples, it will be able to identify these malicious blocks. Therefore, DLVP protocol uses discrete lock verification to identify malicious blocks. In order to prove that a most recent block is a valid mined block, the validator will need to compare and choose the block with the longest “length”. It is only with this verification method that the most number of validators and honest nodes can be assured to select the same block.
The question now becomes one in which how a discrete sampling algorithm can be designed to ensure that the validator will be able to detect the majority of malicious blocks in the following case. If the random sampling distribution of a block is defined as non-increasing, it can be said that there is an equal or higher probability that there exists a distribution of the same block, therefore, the optimal sampling distribution of the block must be defined as increasing.
In addition, according to Bunz et al., the sampling distribution g(x) =1(x-1)lnδ is the most optimal at identifying malicious blocks. By employing the usage of this sampling distribution to sample （λ∗log-1α）n, the probability of a block suffering a failure and being captured by a malicious block is lower than 2n-λ, wherein n is the number of blocks.
To summarize, the DLVP protocol can meet Taylor’s needs and provide a cross-chain foundation for its’ real network environment.
TAYLOR-VM
Taylor-VM is a virtual machine that runs contract code in TSRT.
Taylor-VM is a high-performance virtual machine based on EVM, which enhances the performance of the original EVM. Taylor-VM has a running speed close to that of the computer's native hardware coding, while also providing a more flexible contract interface. Taylor-VM is designed for consensus execution and has enhanced various functions that adapts to contract code execution. In addition to implementing EVM standard specifications, Taylor-VM also provides the following enhancements:
Taylor-VM utilizes soft floating-point operations; the operations on the contract depends on the deterministic operations of the execution environment. Different from floating-point operations, each CPU has a different instruction set; If the CPU does not have any floating-point processor units, floating-point calculations will generate illegal instructions and exceptions. Soft floating-point operations can therefore provide absolute consistency, the results of contract code running in different environments are deterministic and consistent, and all abnormal calls and operation errors can be accurately handled. The highly optimized Taylor-VM engine can ensure the absolute consistency of the calculation process and calculation results.
Taylor-VM is a stack-based virtual machine that can provide the functions of a custom interface. Taylor-VM will import a set of standard host functions, defined as MEI (Taylor Environment Interface). The basic API provided by MEI supports algorithm signatures, digest operations, block data, state storage, etc.
The code running on Taylor-VM can provide Token function interface, transfer and community voting for a series of applications.
Taylor-VM defines the following basic protocols:
(i) Pledge;
(ii) Assets;
(iii) Management
In TSRT, a series of Taylor ABI calls of Taylor-VM are defined as transactions. In the Taylor ABI call, all transactions use a unified message format, and finally all are decoded into Solidity code for execution. Taylor will separate the execution process of the transaction and store the data in the log. The log data supports fast index query. When the user wants to determine whether the transaction is executed correctly, he can query the transaction log and transaction hash through the index, and extract the execution data from the stored data to obtain the current transaction status.
The transactions in Taylor are a universal collection of signature data. Like Ethereum, the transaction structure in Taylor does not have a separate transfer amount value field and uses a transfer function contract provided by a similar system. When a user initiates a transfer, the sender needs to use the signature package to call the contract data and send it to the P2P network. The sender will not get any return value but will generate a special transaction hash. After the transaction is packaged into the block and executed by TSRT, the user can query the status of the account after the transaction.
See the figure below for details: Taylor-VM architecture
Taylor-VM transactions in Taylor can be expressed by the state transition equation:
S is the state of the account before the transaction, input is the encoded data called by the contract, func is the signature of the function called by the contract, and account is the sender. Taylor can obtain the sender's information from the signature data, and can also decode the transaction data to obtain the signature function and input parameters, and can support multiple signature formats. After the transaction data initiated by the user is packaged and verified, the account status is changed in Taylor-VM. Taylor's account system is different from Bitcoin and Ethereum. Taylor's account does not disclose the key hash of a certain signature algorithm, but the account address supports multiple signature algorithm formats. Since the account address can use the multi-signature algorithm, Taylor can natively support a variety of encrypted assets with different signature formats, realizing multi-currency payment scenarios.
Taylor-VM accumulates gas consumption during transaction execution, and Taylor-VM has built-in calculations and measurements. Gas consumption can be calculated in batches for all instructions, stack occupation and resource consumption states. When gas is insufficient or execution error occurs, Taylor-VM will deduct gas consumption and restore the account state to the state before the transaction.
No comments:
Post a Comment