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.
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 codes in TRST (Taylor Sustainable Run Time). The Taylor-VM is a high-performance virtual machine based on WebAssembly, this is a relatively new language that is used to run modern web browsers. In comparison to Ethereum EVM, Taylor-VM is superior due to the ability to provide more flexible contract interfaces and also due to the running speed, which is similar to a computer’s native hardware code.
Taylor-VM is designed especially to support consensus execution, with enhanced functions adapted to “contract code execution” that V8, Chakra and Spidermonkey do not possess. As well as obtaining the standard specifications on WebAssembly, Taylor-VM has also been developed to provide these advanced functions:
For Soft-Floating Point Operations, operations on the contract are determined by the Execution Environment Deterministic Operations. Because Taylor-VM uses soft-floating-point operations, it can result in illegal instructions and exceptions if the CPU does not have any floating-point processor units. Every machine has a different set of CPU instructions, hence, discrepant floating-point operations. Soft floating-point operations provide absolute consistency, the contract code runs in different environments with certainty and consistency, and all abnormal calls and operational errors can be handled accurately. Compared to V8, Chakra, and Spidermonkey, the highly optimized Taylor-VM engine ensures absolute consistency in computing processes and calculations results.
Taylor-VM is a stack-based virtual machine, it can provide self-defining import and export function interfaces similar to JavaScript. A set of standardized host functions are imported in Taylor-VM which are defined as MEI (Taylor Environment Interface). MEI provides basic API’s to sustain WebAssembly operations including algorithm signatures, digestions, block data and state storage.
Delta is based on static typing and is syntactically similar to JavaScript, which is specifically designed for contract programming. The ABI (Application Binary Interface) is similar to WebAssembly and different to Solidarity, the programming language used by Ethereum. In TSRT, Delta is used by Taylor to implement the run time code. In comparison to Solidarity, Delta provides higher performance when supporting basic types, provides greater transaction processing throughput and Delta contract code can also be complied into WebAssembly format. In order to adapt to contract operating environment, Delta has built in event functions and statements which can be directly called by Taylor ABI defined by TSRT. The most important improvement of the Delta language is to support global state variables. Variables defined in Solidity need to be mapped to the modifier declaration in the contract to be in the storage structure of the global state. However, Delta supports this machine by providing storage types to operate operate states in a safer manner.
Contract developers can define global variables more intuitively and design secure contract code. In the TSRT architecture, for example, runtime protocol can be implemented in the Delta language, and can also be compiled into a WebAssembly binary file using a compiler. Taylor-VM loads the compiled WebAssembly code and waits for the transaction to executive after first initializing the global environment. The code running on Taylor-VM can provide transfers, token function interface and community voting for a series of applications.
Taylor-VM defines the following basic protocols:
(i) Pledge;
(ii) Assets;
(iii) Management
In TSRT, the Taylor-VM’s ABI calls are defined as transactions. In Taylor ABI calls, all transactions use a unified message format, and ultimately all are decoded into WebAssembly code for execution. The 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 input the transaction log and transaction hash through the index to obtain the current transaction status.
Transactions in the Taylor are universal collections of signature data; the transaction structure 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 a special hash will be generated. After the transaction is packaged into the block and executed by TSRT, the user can check the account status.
See the figure below: Taylor-VM architecture
Taylor-VM transactions in the Taylor can be expressed with the state transfer formula:S0 = TSRT — Excel (account, func, input, S)
S is the account state before the transaction; input is the encoded data called by the contract, func is the function signature called by the contract, and account is the sender. The Taylor can obtain the sender’s information from their signature data; it’s also possible to decode the transaction data to obtain the signature function and input pentameters, the chain can support a variety of signature formats. After the user has initiated the transaction, the data is packaged, verified and the account status is changed in Taylor’s VM.
Unlike Bitcoin and Ethereum, Taylor supports multiple digital signature algorithm formats without having to disclose the specific key hash. Since the account address can use/hold multiple signature algorithm formats, Taylor can support a variety of encrypted assets that use different signature formats and produce multi-currency payment scenarios.
