VeChain has been designed with one aim in mind: to enable massive-scale adoption of the VeChainThor blockchain and thus changing the world by empowering its individual members. We are committing to providing a stable and predictable transaction cost as well as tools to better facilitate financial service. As such, we designed the Multi-Party Payment Protocol, and it is the key to understanding our new transaction model.

The VeChainThor Blockchain transaction model needs to be capable of the widespread adoption of enterprise users, programmers, and individuals that have already signed to use the platform and the solution must have better functionality than current systems. Not only that, but a successful transaction model must be fail-safe, user-friendly and easy to adopt. The goal for the VeChainThor Platform is to be usable by programmers of any level or age.

Current blockchain transaction systems, notably that of Ethereum, have proven to be deeply flawed when enterprises attempt to use them. We at VeChain Foundation have built several solutions into the VeChainThor Blockchain to deliver competitive advantages to enterprises and developers alike.

The VeChainThor Platform has fully reflected the enterprise easement and transactional stability through the technological design of the VeChainThor Blockchain mainnet. As we get closer to launch, we will continue releasing the technical details of the VeChainThor. This series of technical releases will lead to the release of the complete VeChain white paper.

What are some of the problems facing current blockchain transaction systems?

Issues for All Users:

It is frustrating when an Ethereum transaction gets stuck in the system for hours, or even days. If you want your transaction to go through quickly under Ethereum’s proof of work system, you have to offer a high enough fees to attract a miner to pack your transaction into their next block. An increased user base coupled with the lack of availability of blocks will drive up the transaction price unless an alternate solution is found. Enterprises do not like this kind of price competition while operating normal business activities, as they want to make sure the transaction cost is stable and predictable.

The VeChainThor Blockchain offers a powerful solution by allowing senders to utilize their own computational power to increase the gas of their transaction. Furthermore, by allowing senders to set a time in which a transaction lapses if it has not yet been processed, VeChain puts the power to stop transactions being stuck in the system into senders’ hands.

Issues for Enterprises:

In Ethereum, every transaction is recorded with a transaction number (a ‘nonce’). Later transaction numbers have higher values. The problem for Ethereum occurs when a user sends out multiple transactions at the same time, and one transaction fails. In this situation, Ethereum nodes would not only reject that transaction, but also all later ones in the same batch. This is unworkable for enterprise users, who will need to regularly send out multiple transactions to the blockchain when, for example, registering products or updating records.

The VeChainThor blockchain replaces the current system with Transaction IDs, ready for enterprise adoption.

Issues for Developers:

If you are a developer and you want to code, the VeChainThor Blockchain will be magnitude easier to develop and offers substantial advantages to Ethereum. Here is one example: suppose I want to code a dApp which deals with transactions. If I want to code for a transaction where Transaction A will occur only if Transaction B occurs, the only way to do this using Ethereum is by processing smart contracts. However, Ethereum smart contracts have been found vulnerable to security threats, at the same time its costly on a large scale. It is crucial that blockchain providers do not put their partners’ customers at risk, and to facilitate transaction cost savings when possible. .

VeChain has come up with a solution: embed the necessary functionality into the blockchain itself without a direct need for a smart contract when executing clauses. We have also made it easier for Ethereum applications and developers to move to the VeChainThor Blockchain.

How does the transaction model work? A deep dive

A transaction on the VeChainThor blockchain contains, in addition to the Transaction ID and transaction signature, the following information:

ChainTag — ChainTag is the last byte of the genesis Block ID;

— ChainTag is the last byte of the genesis Block ID; BlockRef — BlockRef is the reference to a specific block. When the BlockRef is a block ID in the future, it enables users to configure the transactions to be executed as a specific block height;

— BlockRef is the reference to a specific block. When the BlockRef is a block ID in the future, it enables users to configure the transactions to be executed as a specific block height; Clauses — Each transaction may contain multiple clauses, and each clause contains the “To”, “Value”, and “Data” fields that can be used to commence different tasks such as payment or smart contracts;

— Each transaction may contain multiple clauses, and each clause contains the “To”, “Value”, and “Data” fields that can be used to commence different tasks such as payment or smart contracts; Gas -the maximum amount of VeThor the sender is willing to pay to execute all the clauses in the transaction;

-the maximum amount of VeThor the sender is willing to pay to execute all the clauses in the transaction; Gas Price Coefficient — Users can modify the Gas Price Coefficient to increase the amount of VeThor they are willing to commit in the predefined range as to prioritize the transaction;

— Users can modify the Gas Price Coefficient to increase the amount of VeThor they are willing to commit in the predefined range as to prioritize the transaction; TxNonce — TxNonce is a random number in the transaction. Users are able to change the nonce to generate unique TxID as part of the “in-transaction proof of work” feature;

— TxNonce is a random number in the transaction. Users are able to change the nonce to generate unique TxID as part of the “in-transaction proof of work” feature; Expiration — The number of blocks that can be used to specify when the transaction expires;

The number of blocks that can be used to specify when the transaction expires; DependsOn — DependsOn is for the TxID of the prerequisite transaction of the current transaction;

— DependsOn is for the TxID of the prerequisite transaction of the current transaction; Reserved : Reserved field for backward compatibility. The initial default value must be 0;

: Reserved field for backward compatibility. The initial default value must be 0; Signature: Transaction signature

These ten values all determine the Transaction ID. A Transaction ID may be only used once. As such, a second attempt to use the same Transaction ID will be refused. This means that the system is safe from ‘replay attacks’, where a user sends multiple instances of the same transaction to drain another user’s account. If you send me ten VET, it is crucial that no-one can plug in the same values to make you repeatedly send VET until your account runs dry. This will not happen on the VeChainThor blockchain.

Multi-task Transactions — increased power and flexibility to deal with complex situations in real applications

Another novel built-in feature of the VeChainThor blockchain is the Clauses field. The Clauses field contains several clauses. Each single clause contains three fields:

To — the recipient’s address;

Value — the amount transferred to the recipient;

Data — this fulfils several functions, including determining whether the transaction is a standard transaction or a smart contract-creating transaction.

The major leap lies in the ability to include several clauses together in one transaction, defined by the Clauses field. Putting it another way, the Clauses field is a set of single clauses. This allows a single transaction to have multiple outputs. The Clauses system yields flexibility and power beyond other blockchains.

1. Multiple tasks contained in a single transaction will either all succeed or all fail. There will regularly be types of transaction which businesses want to be interdependent, and the Clauses field allows them to do just that. With the Clauses and the Transaction ID systems, the VeChainThor blockchain can accommodate businesses both when they require transaction dependency and when they desire independent transactions.

2. During the execution of the transaction, the relevant tasks are processed one by one in the order defined by the Clauses field. This provides a more efficient and secure way to guarantee that a multi-step process will be carried out properly than existing solutions.

A blockchain capable of wide-scale enterprise adoption must be able to deal with complex situations in the real world. The multi-task mechanism provides a simple and systematic solution, for example, to fund distributions and mass product registration. Furthermore, the multi-task transaction system is designed to substantially simplify the development of dApps on the VeChainThor blockchain. We expect this to attract developers to our blockchain, encouraging wide-scale use of the VeChainThor blockchain as an ecosystem.

This concludes Part 1 of the the Transaction Model release, in Part 2 we will be addressing exactly how this model has prepared the VeChainThor Blockchain to be the public blockchain with the most business activity in the world.