Part 2: How the Transaction Model Enables The Necessary Public Blockchain Adoption
In Part 1 of the Transaction Model we made it clear that 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.
In order to convey that truth, we must suggest how VeChain differs and improves upon industry standards and leaders. By utilizing the Transaction Model, developers, enterprises, and individuals have far more control of their transactions empowering them to automate workflows without inherit security risks. We have designed this model to be stable in cost while still accessible to those needing near instantaneous transactions.
How VeChain’s transaction model is prepared for blockchain adoption by the masses
Solving issues for all users
The problem of spiraling transaction fees, outlined in Part 1, is solved by the VeChainThor Blockchain. Under this system, senders can still choose to pay a transaction fee for the Authority Nodes to put in the Proof of Work validating the transaction. Alternatively — and here is the innovation — senders can use their own computing power to raise the required transaction fee. This means that transaction fees will stay realistic, offering a more effective ecosystem for end users.
The overall gas price is determined by three factors, which are base gas price, gas price coefficient, and the In-transaction Proof of Work (“In-tx PoW”) index.
- Base gas price
The base gas price is the exchange rate between VeThor and gas.
2. Gas price coefficient
Users can adjust the Gas Price Coefficient setting the gas price they want within the defined range. In VeChainThor, users can only pay 2x the base gas price with their own VeThor and generate the additional VeThor to reach the maximum 3x base price by using In-transaction Proof of Work.
3. In-tx PoW index
With the Gas price coefficient, users can option to double the gas price to improve the speed in which the transaction processes. But to prevent malicious attacks where someone may congest the network with transactions at 2x gas price there must be another step. Therefore, we designed the in-transaction proof of work mechanism to enable users to further increase the gas price by proving the computation work done by the user end through devices such as a laptop or a cellphone. By utilizing In-Transaction Proof of Work, the user is not charged any additional VeThor, nor does it increase any workload on behalf of the authority node.
In-Transaction Proof of Work makes it harder for malicious attacks trying to congest the network. In Ethereum, you can launch such attacks if you have enough Ether, while in VeChainThor the attacker needs to have a large amount of VeThor and consume computing power for each transaction.
We have redesigned the TxID in VeChainThor in a way that users can perform PoW over the TxID from the user end by numerating the nonce. Before the user broadcasts the transaction, he/she can choose to perform PoW for a short period of time to accelerate the transaction.
Users can only perform so much PoW that the height difference between the block in which the transaction is processed and the block in the BlockRef does not surpass the predefined threshold.
TxID is usually the hash of all fields in a transaction. In order to improve the syntax, scalability and function, we redefined TxID in VeChainThor. The TxID is now correlated to the transaction hash and transaction sender. In addition, this process solves the transaction malleability problem with ecdsa signature.
Furthermore, a user can set the Expiration field to any point they choose. This has two key benefits:
- Transactions will no longer be stuck waiting to be processed while the user looks on helplessly.
- Increased security, because the payment cannot be hijacked at a later point in time and reused to cause problems.
Solving additional issues for enterprises
Where transaction dependency is desirable
Company A distributes wine. Company A wants to show their customers that they conducted their distribution process in the precise order required by their clients. The VeChainThor blockchain offers the ideal solution to Company A’s requirement. By using the field DependsOn to formally define the order for Company A’s sequence of transactions ensuring that the current transactions only execute after the specified transactions were effective. The DependsOn field enables Company A to provide their clients with an immutable record describing a series of events which happen in the real world.
Where transaction dependency is not desirable
Company B wants to register 100,000 products to the blockchain in one batch. Using Ethereum, if one registration is rejected, all registrations later than that one will fail too. This needlessly puts the entire process at risk, resulting in costly delay. In the VeChainThor Blockchain, when validating a given transaction, instead of checking the current account nonce, the system computes its transaction ID. So if Company B uses VeChain, if one registration fails, that does not mean all registrations after that will fail. Rather, only the single repeat transaction will fail and the bulk of registrations will succeed, allowing Company B to immediately achieve its objective of registering their products in bulk.
The single transaction which was rejected can then be manually set with a new transaction nonce, allowing it, too, to succeed. Getting rid of this interdependence, where it is not required, while keeping it where it is desirable, is the key advantage of the Transaction ID system.
The Transaction ID system will deliver further benefits for Company B because it is extremely likely that different transaction IDs will be created for each product even where Company B wishes to register 100,000 similar products at the same time. This is because, for any two transactions having any single field with different values, their transaction IDs will be different. Additionally, because the transaction nonce can be adjusted by Company B so that, even where every other aspect of the transaction are the same, the two transactions will have different IDs and both will go through.
Increased customization
The transaction model used by the VeChainThor Blockchain allows far greater customization than existing solutions, in particular through using DependsOn, BlockRef, and Expiration fields.
Company C wishes to accurately monitor the conditions inside their car through time. By filling in the BlockRef field with the details of the existing block available to them, Company C can prove the precise time when a set of conditions inside the car were present.
The BlockRef field ensures that the transaction can only be executed after a certain block height. The BlockRef field has eight bytes which can be broken into two parts, i.e. BR1 and BR2. BR1 is the block height and BR2 is the next four bytes after the block height. If you want to specify a future block, BR2 can be left blank. When the node validates the block, it will check all transactions contained in the block that must be satisfy:
is the block height of the current block. Therefore, the transaction can only be executed in a block of which the height is greater than BR1.
BR2 does not participate in the block validity check, while it is used for “In-transaction Proof of Work” (please see the next section).
Company D wants to send staged payments once per month for six months, for purchase of a flat, which they will offer for rent. It is easiest for Company D to set the payments up all at once, for them to go through once every month. Company D can fill in BlockRef in advance for each payment, so that each transaction runs every month as planned.
Company D can gain further advantage by using the Expiration field, to ensure that their transaction will be cancelled if it is not accepted on the day it is sent. By doing so, they will be reassured that their transaction will never become stuck in the system, and benefit from increased security as outlined above.
Solving additional issues for developers
The VeChainThor blockchain has an inbuilt option on the blockchain itself to make Transaction A dependent on Transaction B (‘conditional transactions’), without the need for smart contracts. This makes coding such transactions easier for developers, and results in a more secure solution for businesses. Developers will no longer be required to code using smart contracts on top of the blockchain for such clauses. This makes coding dApps on the VeChainThor blockchain significantly easier than on Ethereum’s blockchain. Businesses will no longer need to worry about the added layer of vulnerability to hacking inherent in using smart contracts to execute every conditional transaction.
As Sunny Lu wrote in his open letter, the VeChainThor blockchain is designed to deliver mass adoption of blockchain through enterprise adoption. With the already growing number of companies, governments, and individuals signing up to use the VeChainThor Blockchain, the world will quickly realize the true power of a mass adoptable public blockchain solution. Our transaction model contains several innovative features which solve real-world problems affecting other blockchain solutions.
We will release more technical and design innovations to our blockchain and its SDKs as we get closer to our mainnet launch. We firmly believe that with the toolkit provided, more developers will begin to use our innovations, there will be geniuses that will discover numerous new usages and applications of our blockchain that we have never thought of. History always repeats itself, the wisdom of the ancients:
“There are not more than five musical notes, yet the combinations of these five give rise to more melodies than can ever be heard.
There are not more than five primary colors, yet in combination they produce more hues than can ever been seen.
There are not more than five cardinal tastes, yet combinations of them yield more flavours than can ever be tasted.”
—— Sun Tzu, The Art of War
