ABOUT VECHAINTHOR
Secure,
efficient
and adaptable
Since the start, we have worked on building a transparent, efficient, scalable and adaptable blockchain platform. But these qualities were just the tip of the iceberg. Research, innovation, collaboration and a strategy aimed at long-term viability brought us to today as we seek to multiply individual impact to unleash our collective potential for sustainability.
In preparation for the Web3 era in which digital and physical worlds merge to create a phygital universe, we teamed up with Boston Consulting Group (BCG) to undertake an extensive analysis of the sector. The research performed has proven pivotal as we fine-tune our approach to bringing our vision for a more sustainable, inclusive and equitable world to life. Fostering trust, collaboration, holistic value and a thriving environment where everyone can participate in creating their own sustainable ecosystems is our priority. This is our Whitepaper 3.0.
Our society needs sustainability to flourish; and fortunately, the transition is near. But to gain traction, everyone must work together to combat society’s greatest threats. Technology and digital innovation are the key to our better future. We want to even out the playing field and empower everyone – individuals, businesses and institutions alike – to participate in the development of interconnected ecosystems where every single action is accounted for and its impact is multiplied to benefit all. The catalyst for participation is trust, granted by blockchain. That is in turn furthered by this safe, transparent system we are creating, called the Blockchain Biosphere for Sustainability.
1.0
The proof of authority (“POA“) consensus mechanism mainnet upgrade from poa 1.0 to POA 2.0
In November 2022, the next-generation PoA 2.0 was successfully implemented, adding value to the previous PoA 1.0 and providing the needed security and stability to support the ever-growing, on-chain business activities on the VechainThor blockchain.
The new PoA 2.0 delivers 3 key feature updates:
1. Absolute finality (or safety guarantee) on blocks and transactions;
2. Significant reduction of the platform’s risk of being temporarily disrupted, which will result in better stability of blockchain service;
3. Faster-converging probabilistic finality, which results in faster transaction confirmation for applications.
Two new mechanisms were introduced into the existing PoA 1.0 protocol.
The block finality mechanism grants qualified blocks absolute safety guarantee. Once a block acquires its finality, the consensus assures it cannot be modified, replaced or removed from the public ledger, even when the network encounters extremely asynchronous situations, such as being subject to large-scale network partitioning.
In theory, a block can be considered final if it is confirmed by the BFT consensus. We adopt the framework Yin, et al that implements the BFT consensus as a consecutive three-phase process. In each phase, more than two-thirds of nodes must agree on the block to be confirmed.
To apply the framework, we embedded features that carry information of the finality process in blocks and consider endorsing a block as the way the committee member confirms such information. As a result, we can achieve one phase of the BFT consensus on a particular block once observing more than two-thirds of nodes having participated in the chain that descends from the block. We also introduced additional rules to assure the system’s consistency and liveness.
This way, instead of asking more than two-thirds of all the nodes to respond simultaneously, our algorithm requires only the block producer and committee to respond in time. As a result, the service will be less likely to be delayed or temporarily halted.
The committee-endorsing mechanism fundamentally changes the way a block is created. More specifically, besides the selected block producer, it demands other nodes to participate in the process of forming a new block.
In each round of consensus, some nodes are randomly selected as committee members.
Committee members need to validate the proposal sent from the block producer and formally endorse the proposal by signing it. The consensus algorithm demands the block producer combine sufficient legitimate endorsements into the new block to validate it. Furthermore, the verifiable random function (“VRF”) is used to ensure committee members are truly picked randomly from all the nodes. Note that VRF functions similarly to a cryptographic hash function, except that it requires a private key as input.
As a result, to create multiple conflicting blocks, the block producer must now work with a designated number of committee members.
Due to the use of VRF, it can do so only if:
1. It colludes with a number of nodes;
2. Among those nodes there are, by chance, a sufficient number of them being selected as committee members.
The above conditions make it much harder for the block producer to do so to disrupt the blockchain system. In other words, the probability of a node manipulating its right to add a new block is kept extremely low. An important implication is that we are able to reach a satisfactory probabilistic finality (e.g., the probability of a transaction being reverted is smaller than 0.0000001) much faster than the former PoA.
In summary, PoA 2.0 has introduced:
1. A committee-endorsing mechanism that significantly lowers the possibility of a node manipulating its right to produce a new block, thus resulting in faster converging probabilistic finality.
2. A block-finality mechanism that grants absolute safety guarantee to blocks (as well as the included transactions) that qualify certain criteria.
Both probabilistic and absolute finality are allowed to coexist by the consensus protocol, providing different levels of security guarantee for applications running on the blockchain platform. In general, the higher security is required, the less efficient the application is, and vice versa.
Consequently, enterprises can select the security guarantee that best suits their needs to maximize application performance.
Proof of Authority 2.0 is the evolution of our Proof of Authority (PoA 1.0) consensus algorithm. As the first blockchain platform to launch with a Proof of Authority algorithm, we worked extensively with our community to understand how to improve it. PoA 2.0 boasts many new features to optimize performance, though the efficiency and security of the original framework were fundamental in making the upgrade successful.
The Proof of Authority (PoA 1.0) consensus is a consensus algorithm that demands nodes to be authorized in order to participate in the blockchain consensus. Once authorized, authority master nodes are given equal chances to publish new blocks and gain rewards. As a result, there is no need for nodes to spend vast number of resources to compete. In addition, richer nodes do not have more advantages than other nodes in the system.
PoA 1.0 is also an efficient consensus algorithm in terms of network bandwidth usage. It takes little time to decide block producers and thus, allows more time for transmitting transaction data. The system can, therefore, have a high throughput, or TPS (“Transactions Per Second”), within the range allowed by the underlying network.
PoA 1.0 uses a heaviest chain rule to determine the canonical chain, or in other words, the “trunk”.
When forming a new block, the round leader adds the number of active consensus nodes observed locally to Total Score of the latest block on the trunk and stores the result in the new block. Other nodes have to agree on the value to accept the block.
A node is marked ‘inactive’ by other honest nodes after it misses generating a new block in the round when it is the leader. An inactive node is considered ‘active’ once it produces a new block again.
Despite all the above-mentioned advantages and the fact that the VechainThor blockchain had been working securely and smoothly on this consensus since its launch, PoA 1.0 still had its own limitations.
For example, like Ethereum, its algorithm lacked an effective means to deter a node from manipulating the system when given the right to add a new block, although PoA did make sure that any traced misbehavior could be used as evidence against the node later.
Moreover, PoA 1.0 belonged to the family of the Nakamoto consensus and therefore, only provides probabilistic assurance to the safety of transactions, which wasn’t always sufficient to maintain system consistency when confronted with extremely asynchronous situations, such as being subject to large-scale network partitioning.
Summary of Proof of Authority (PoA) 1.0 and 2.0
PoA 1.0
PoA 2.0 implemented Nov. 2022
101 whitelisted
Authority Masternodes (AMs)
These AMs are given an equal chance to publish new blocks and gain rewards
Yes
Yes
Efficient network bandwidth usage
Takes little time to decide block producers
Allows more time for transmission of data and high throughput
Yes
Yes
Committee Endorsing Mechanism
Lowers the possibility of a node manipulating its right to produce a new block, and results in faster converging probabilistic finality
No
Yes
Block Finality Mechanism
Will assure that blocks cannot be modified, replaced or removed from the public ledger
No
Yes
Finality with one Bit (FOB) gadget
Enables VechainThor blockchain to run dual modes of consensus – the Nakamoto and Byzantine Fault Tolerance (BFT) consensus, at the same time
No
Yes
2.0
Meta transaction features
The VechainThor blockchain implements an enhanced transaction (TX) model to tackle some of the fundamental problems that hinder the adoption of blockchain technology.
Every blockchain system must find a way to uniquely identify each TX; otherwise, it would be vulnerable to the TX replay attack. For a UTXO-based blockchain like Bitcoin, TXs are linked and can be uniquely identified and verified by the associated spending history. However, such uniqueness no longer holds for an account-based blockchain. For such systems, we need to inject additional information into TXs to make them uniquely identifiable.
The VechainThor blockchain achieves its TX uniqueness as follows. First, it defines the TX Nonce as a 64-bit unsigned integer that is determined totally by the TX sender. Given a TX, it computes two hashes, the hash of the RLP encoded TX data without the signature and the hash of the previously computed hash concatenated by the sender’s account address. The second hash, which is 256-bit long, is used as TXID to uniquely identify the given TX. Note that the calculation of TXID does not require a private key to sign the TX.
Further reading of TX uniqueness here.
The VechainThor blockchain allows a single transaction to carry out multiple tasks. To do that, we introduce the Clause structure to represent a single task and allow multiple tasks to be defined in one transaction. A task is defined by fields: To, Value and Data. A Clause array, named Clauses, is then introduced in the transaction model to accommodate multiple tasks.
The multi-task mechanism has two interesting characteristics:
• The execution of tasks in a single TX is atomic, meaning that either they are all executed successfully or rejected all together.
• Tasks in a single TX are processed one by one in the exact order they are put in Clauses.
The multi-task mechanism provides a secure and efficient way to handle tasks such as fund distribution, token airdrops, mass product registration.
The VechainThor blockchain provides a safety mechanism that allows users to force a TX to depend on the success of another TX. It has been done with the help of field DependsOn in the TX model. If DependsOn has been assigned a valid TXID, the system will check the status of the referred TX. Only if the status remains successful, is the current TX accepted for processing. By successful, we mean two things: 1) the referred TX has been included in the ledger; and 2) it has been executed without being reverted.
The second requirement is particularly important since seeing a TX included in the ledger does not guarantee that it has been successfully executed. A TX can be included, but with a status “Reverted”, which means that the system does not actually do what the TX asks it to do. For the dependent TX, there is no limitation on who sends it or when it is sent or what it is about. It offers developers much-needed flexibility.
Further reading of the forcible transaction dependency can be found here.
The VechainThor blockchain gives users control of the lifecycle of the TXs they send. Users can tell the system the earliest time their TXs can be processed and how long until a pending TX expires via fields BlockRef and Expiration defined in the TX model.
BlockRef can be used to store the reference to a particular block whose next block is the earliest block the current transaction can be processed. Expiration stores a number that can be used, together with BlockRef, to specify when the transaction expires. Specifically, the sum of Expiration and the first four bytes of BlockRef infer the height of the last block that the current TX can be packed into.
The transaction lifecycle control is particularly useful when the blockchain is running at high capacity, because it gives users and developers definite control over when the transaction is executed or abandoned, which is highly demanded by business applications.
The TX fee delegation mechanism allows anyone to be able to use decentralized applications (dApps) without having to purchase cryptocurrencies, directly paying the TX fee caused during their interactions with dApps.
In this way, users, when using dApps, can have the same kind of experiences as when they are using normal mobile or web-based apps. This is crucial for the mass adoption of blockchain technology, especially in this stage when cryptocurrency regulation is still unclear.
The VechainThor blockchain is the first public blockchain to successfully implement the TX fee delegation mechanism.
There are currently two protocols running on the VechainThor blockchain that enable such a mechanism: the Multi-Party Payment (MPP) protocol and the Designated Gas Payer protocol.
The former exists as a built-in protocol from day one of the mainnet launch while the latter was proposed in VIP-191and implemented on July 22, 2019, in the VechainThor blockchain v1.1.2 release.
MPP allows an account on the VechainThor blockchain to pay fees for TXs sent from some designated accounts.
As illustrated in the above figure, there are three types of accounts involved in the protocol:
• USER: account sending TXs
• PAYER: account receiving TXs from USER and paying the TX fee
• MASTER: account from which the TX fee is deducted from. MASTER can be either PAYER itself, if it is a normal account, otherwise the account deploys PAYER, if it is a contract account (i.e., a contract with code)
Users can use the built-in contract Prototype to set up the MPP relation between PAYER and USER. Once such a relation has been established on-chain, when executing a TX from USER to PAYER, the VechainThor blockchain will attempt to deduct TX fee from one of the three accounts in the order of MASTER, PAYER, then USER.
Users owning multiple MASTER accounts can also set up a SPONSOR account, so that all the TX fees are deducted from a single SPONSOR account rather than from individual MASTER accounts, easing the work of managing multiple on-chain accounts.
MPP was designed from the point of view of a dApp owner who controls multiple contract accounts running on chain. It is the sole responsibility of the owner to set up MPP and the protocol can only affect TXs sent to those contracts. Moreover, since MPP requires writing data on chain and therefore, causes certain overhead costs, it is more cost-effective to use the protocol for a relatively stable relationship between a user and the dApp, rather than some temporary arrangement.
VIP-191 is aimed to supplement MPP in order to provide more flexibility for TX free delegation on the VechainThor blockchain. Specifically, it allows a TX sender to seek an arbitrary party – not necessarily the TX recipient – willing to pay for the TX. The protocol works quite simply. It requires both the TX sender and payer to put their digital signatures in the TX. The sender also needs to turn on the VIP-191 feature to inform the system that it is a VIP-191 enabled TX. Once the TX is accepted and executed, the fee is deducted from the payer account.
Comparison
In comparison to MPP, VIP-191 gives control back to TX senders to activate the protocol. Moreover, it does not introduce any overhead costs. However, it does require the TX sender and payer to both be online to complete the TX while MPP does not. MPP tends to be most transparent since the payer explicitly puts their intention to fund TXs from a particular account on chain (via executing functions of contract Prototype).
Implementation
VIP-191 has been implemented in the Thor v1.1.2 release. There have been two major changes made to implement the protocol:
• Extending the TX model;
• Adding extra logic for deciding the actual gas payer for a VIP-191 enabled TX.
Field Reserved in the TX body structure has been re-defined to be of type reserved as shown below:
type reserved struct {
FeaturesFeatures
Unused []rlp.RawValue
}Within the structure, we define field Features as a bitmap where each bit marks the status (1 for on and 0 for off) of a particular feature. For VIP-191, the least significant bit is used. Moreover, VIP-191 requires two valid signatures to be included in the TX. The TX sender’s signature is concatenated by the payer’s signature and assigned to field Signature as usual. Moreover, the protocol requires the payer to sign TXID, which is a unique identifier of the TX.
The extra logic brought by VIP-191 is added in function BuyGas in the Go source file THORDIR/runtime/resolved_tx.go. When determining which account pays the fee, the system first checks whether there is a dedicated payer. If the answer is yes, it then tries to deduct the initial cost of the TX from the payer’s balance. If the balance is too low, the system responds with an error. Otherwise, it marks the payer in the runtime context associated with the TX and passes on the context to the code that executes its clauses.
Further reading of VIP-191 Designated Gas Payer here.
VechainThor blockchain’s on-chain governance is about stakeholders or its governing body making decisions regarding critical on-chain actions and executing those actions.
(The governing body of the mainnet is the Steering Committee of vechain.)
The actions can, for instance, be authorizing or revoking consensus validators (i.e., the Authority Masternodes), changing network parameters, such as the base gas price and block reward ratio, or any on-chain activity embodied by a smart contract deployed on the VechainThor blockchain.
On-chain governance consists of three phases: Decision Making, Authorization and Execution:
• Decision Making is the first phase where decisions on executing certain on-chain actions are made. Decisions are obtained through voting. Voting can be conducted either on chain via a voting contract or off chain within the governing body. The former provides maximal transparency and often involves all stakeholders, while the latter complements the former to offer efficiency and agility.
• Authorization is the second phase where a voted on-chain action is proposed to the governing body for final approval. Each proposal must be approved by a majority of the members of the governing body. This is an extra security measure put in place to safeguard on-chain governance against malicious activities (e.g., exploitation of voting-contract vulnerabilities).
• Execution is the final phase of on-chain governance. Once a proposal has been approved by the required majority, anyone can trigger the execution of the on-chain action defined in the proposal.
The VechainThor blockchain provides a flexible framework for implementing the described on-chain governance, as illustrated in the above figure. At the center of the framework is the Contract Executor that is deployed both on the mainnet and testnet.
The Contract Executor provides propose and approve functions to carry out the authorization phase. Only authorized voting contracts or members of the governing body can invoke function:
propose(target_contract_address, encoded_data);
(marked by 1 in the above figure) to submit a proposal in Executor. The two function arguments define an on-chain action, i.e., invoking a specific function at a specific target contract address. A proposal is an instance of struct proposal stored in Executor and is created by function propose. Once a proposal is logged in Executor, members of the governing body are given one week to authorize it. Each member can invoke function approve (marked by 2 in the above figure) to complete their authorization.
The execution phase is implemented simply by function execute of contract Executor. Once a proposal has been approved by the required majority (two thirds by default) of members of the governing body, anyone can invoke function execute to trigger the execution of the on-chain action defined in the proposal using low-level call function:
target_contract_address.call(encoded_data)
It is often a safety practice to code the target function of the target contract so that it can only be invoked by Executor. In this way, we are guaranteed that the action can only be executed after going through the process of on-chain governance. A good example of such a contract is the built-in contract Authority that manages Authority Masternodes.
Finally, a voting contract must be authorized before it can call function propose to submit proposals. Contract Executor provides functions attachVotingContract and detachVotingContract to manage the list of authorized voting contracts. Note that both functions have been coded such that they can only be invoked by Executor itself, meaning that any change to the list must be done through on-chain governance. This ensures that voting contracts are managed securely and transparently.
Further reading of the on-chain governance here.
There are seven built-in smart contracts deployed on the VechainThor blockchain. Their source code can be found in path thor_root/builtin/gen. They are called the built-in contracts not only because they are shipped together with the Thor source code, but because many of their methods are implemented natively in Go rather than in Solidity for the sake of efficiency. In fact, all functions whose names begin with native are such methods. Whenever these functions are called, the system will intercept the normal EVM procedure and run the native Go code instead.
Here is a brief description of each of the built-in contracts.
1. Source code: authority.sol
Deployed Address: 0x0000000000000000000000417574686f72697479
Contract Authority provides methods to deal with the Authority Masternodes (AMs). Users can use function get to query the status of a particular AM; and use first and next to iterate existing AMs. It also provides functions add and revoke to authorize and deauthorize an AM. These two functions can only be invoked by contract Executor via on-chain governance.
2. Source code: energy.sol
Deployed Address: 0x0000000000000000000000000000456e65726779
Contract Energy defines the interface for operations on VTHO.
3. Source code: executor.sol
Deployed Address: 0x0000000000000000000000004578656375746f72
Contract Executor provides methods to facilitate on-chain governance on the VechainThor blockchain. We provided an extensive explanation of this in the previous section.
4. Source code: extension.sol
Deployed Address: 0x0000000000000000000000457874656e73696f6e
Contract Extension is implemented to allow contract code to query information of a previous block or be aware of the runtime information of the current TX. For the former purpose, it provides methods blockID, blockTotalScore, blockTime and blockSigner; while for the latter purpose, it provides methods totalSupply, txProvedWork, txID, txBlockRef and txExpiration. We can also invoke the natively implemented Blake2 hash function via method blake2b256.
5. Source code: extension-v2.sol
Deployed Address: 0x000000000000000000457874656e73696f6e5632
Contract ExtensionV2 is an extension of contract Extension. It defines a new method to query the actual gas payer of the current TX.
6. Source code: params.sol
Deployed Address: 0x0000000000000000000000000000506172616d73
Contract Params provides methods get and set to check and set the global network parameters. There are two such parameters: the reward ratio and base gas price that are indexed by keys (32 bytes) 0x00000000000000000000000000000000000000007265776172642d726174696f and 0x000000000000000000000000000000000000626173652d6761732d7072696365 in the system, respectively. The keys are required as the input to the above two functions and are used to locate the parameters in the blockchain state. Function set can only be invoked by contract Executor via on-chain governance.
7. Source code: prototype.sol
Deployed Address: 0x000000000000000000000050726f746f74797065
Contract Prototype is implemented to facilitate MPP and query information of a particular account. For the former purpose, it provides methods master, setMaster, creditPlan, setCreditPlan, isUser, userCredit, addUser, removeUser, sponsor, unsponsor, isSponsor, selectSponsor and currentSponsor. To query account information, it provides methods balance, energy, hasCode and storageFor.
As mentioned above, the VechainThor blockchain has implemented many unique features to establish the foundation for a sustainable and scalable business blockchain ecosystem. To enable third-party developers to fully leverage the aforementioned features, Connex API Standard proposed to unify the communication between a client application and a running VechainThor blockchain node.
Connex is not simply a client-side library, but a set of well-designed APIs that allows re-implementation across different environments by different vendors. If the implementation adheres to Connex Standard, the third-party developed dApps can be expected to run on those platforms without modification.
Currently, the Connex.js definition library released demonstrates the common behaviors according to the standard. Frontend applications running on alike browser environments can be a benefit with said interface, regardless of whether it is on a mobile device or desktop computer.
Connex exposes several crucial yet useful APIs to third-party developers to fully utilize the VechainThor blockchain features such as MTT and ease the developer’s life with the latest blockchain updates. Here are some examples:
Always Up-to-Date Tip of Blockchain Status
Connex defines a connex.thor.ticker() object which is a Promise. Once the ticker ticks, the application can be sure a new block is included in the VechainThor blockchain. This event trigger keeps dApps informed whenever there are new changes and prevents the application from polling the blockchain mindlessly.
Multi-Task Transaction (MTT) Support
Once the application depends on Connex as a low-level environment, the MTT feature comes out of the box. Whenever a contract method is called, for example, transfer() method, a developer can chain-up several tasks by calling transfer().asClause(…) to box several operations into a single blockchain transaction.
Signing Service and Fee Delegation
As Connex definition does not include wallet implementation details, vendors can freely define the proper secure mechanism suitable for each environment according to devices (e.g. Ledger, browser or mobile apps). However, they all adhere to the same signing interface as vendor.sign(‘tx’).
vendor.sign(‘tx’) is called right before the application sends out the transaction. The dApp calls signingService.request(…clauses) to ask the user to sign the blockchain transaction. To utilize the feature of VIP191 Designated Gas Payer fee delegation, the vendor should further support signingService.delegate(…) to obtain another level of signature of a sponsor, thus the end-user can use the VechainThor blockchain without the hassle of paying for it with cryptocurrency.
Advanced User Identification
The Connex standard also includes a user identification API which allows the dApp to identify an account holder without a single online transaction to be performed. When the dApp triggers vendor.sign(‘cert’) method, the user will be prompted and sign a self-identifying message. After the successful identification, the dApp can be sure this user holds the specific account. This unique feature eliminates the friction to ask a user to sign an on-chain transaction which is costly and less time-efficient.
More details about the Connex API can be found here.
Vechain Improvement Proposals (VIPs) are ideas from developers and communities to improve the VechainThor blockchain. As an open-source project, vechain has a lively community that has proposed many features such as fee delegations and user identification.
There are four types of VIPs: core, application, interface, and information.
The core type needs a consensus fork to take effect; Application type will modify the standards and conventions; Interface type requires a modification of the client API and message structures; the Information type does not require changes to the blockchain itself but rather provides information on guidelines.
Any VIP will go through several stages, known as the draft, accepted/deferred/withdrawn or final. When a VIP is in the draft stage, it can be modified by the proposer or the reviewer. After the technology committee review and development team discussion, it will either be accepted or deferred. Once accepted it will soon be implemented; however, if deferred it will be postponed for future implementation. Once implemented, the VIP then will go to the last stage of the life cycle: final.
3.0
VechainThor: Low-carbon and energy-efficient layer 1 infrastructure
In pursuit of vechain’s goal to cultivate a healthier planet through green technologies, the VechainThor blockchain is one of the most energy-efficient blockchains, using just 0,000216 kWh of electricity per transaction (0,04% of comparable blockchains)
Using the highly effective and stable PoA 2.0 consensus mechanism, vechain solves the largest problem facing the energy use of a blockchain platform; that is, achieving consensus and updating the public ledger in an energy-efficient manner.
Over the years, several assessments have demonstrated the platform’s energy efficiency. Most recently, a study developed in collaboration with DNV found that the 2022 carbon footprint of vechain’s core network of 101 authorities’ nodes was calculated to be 4.46 t CO2e/year.
According to these calculations, vechain is one of the most energy efficient blockchains, using just 0,000216 kWh of electricity per transaction, or roughly 0,004% of other comparable blockchains. The calculation methodology is based on the Life Cycle Assessment as described in ISO 14040 and ISO 14044.
Energy costs per transaction on a decentralized network are a preliminary step in determining whether a network can successfully achieve long-term sustainability. The VechainThor blockchain is currently using the PoA consensus mechanism which does not require nodes to compete with each other in order to produce a new block. Instead, rights are equally distributed to all the 101 consensus nodes, i.e., the Authority Masternodes (AMs).
4.0
Authority masternode management
The VechainThor blockchain uses a Proof of Authority (PoA) consensus in which each transaction is validated by Authority Masternodes (AM), however, the VechainThor blockchain node program is open source, which means it does not require any permission to synchronize the full ledger of VechainThor blockchain and initiate transactions on it.
An AM is a network-connected server running the VechainThor blockchain full node program, which keeps a complete copy of the blockchain. Additionally, Authority Masternodes are the full nodes authorized via an on-chain whitelist to validate and produce blocks of the VechainThor blockchain. The whitelist of Authority Masternodes is managed through the Authority built-in smart contract, which requires multi-signature authorization by vechain Steering Committee members to make any modification.
All AM holders must do the following:
a) Be vetted to ensure they have a legitimate identity;
b) Hold 25M VETs as collateral; and,
c) Run and manage a server with a certain guaranteed level of performance and availability.
More importantly, in addition to those minimum qualifications, AM holders are responsible for actively contributing to the vechain ecosystem in their own fields.
As an incentive to AMs for maintaining the integrity of the blockchain, contributing to the vechain ecosystem, and participating in the platform governance, the network rewards the AMs with VTHO tokens which is a native VIP180 token representing the transaction fees of the VechainThor blockchain. In each block, 30% of the VTHOs consumed by transactions are paid out to the AM that produces the block. The other 70% of VTHOs are burned. On the VechainThor blockchain, Authority Masternodes do not compete to produce blocks, rather the block producer is selected by a random algorithm. This helps solve one of the key concerns from enterprises to run a consensus node on a public blockchain regarding computing power andenergy consumption: the PoA consensus consumes far less energy than Proof of Work. In addition, Authority Nodes are entitled to the highest weight per vote among all stakeholder votes, based on the vechain Governance Model. Collectively, AMs hold a total of 40% of the total voting authority.
The design of the PoA consensus and Authority Masternodes lies at the center of the vechain Governance Model. Unlike most public blockchains on the market, the vechain AM holders are subject to strict Know Your Customer (“KYC”) verification, and their reputation is part of the stake, in addition to the financial collateral. Vechain conducts strict identity verification and holds AMs accountable for their activities and obligations to the ecosystem.
Vechain seeks corporates and individuals that have aligned interests and are able to contribute to the growth of the vechain ecosystem to apply to be AM holders, which may include but are not limited to the following roles:
• Enterprise users,
• Blockchain development teams,
• Business and technical development partners,
• Community contributors,
• Academic research partners.
For corporates or individuals interested in becoming an AM holder, please contact us here. The vechain operation team and its Steering Committee review the applications based on a set of selection criteria, and approved applicants are eligible to become Authority Masternode holders. The criteria cover both quantitative basic requirements and the ability to contribute to the ecosystem.
As the foundation of the VechainThor blockchain, AM holders must maintain the security and availability of the Authority Masternode as well as contribute to the vechain ecosystem. In order to measure the performance of AM holders, the vechain operation team continuously monitors metrics relating to Authority Masternode Performance and vechain Ecosystem Contribution. Failure to meet the requirements may result in the AM holder being disqualified.
For more details of the AMs management lifecycle, please refer to the Authority Masternode Handbook.
It has always been vechain’s goal to provide the community with transparency. The Proof of Authority consensus relies on the public reputation of the node holders. On the other side, we all witnessed the fallout of the Libra association where enterprises chose to withdraw as masternodes due to regulatory ambiguity. Though the VechainThor blockchain was launched in June 2018, our AM holders – especially enterprise holders – shared the same perspective and some of them preferred to keep their identities and activities on the blockchain from the public. However, vechain and its Steering Committee (who is elected by the stakeholders with voting authority) apply strict identity verification and assessment during the onboarding process to ensure that legality of AM holders’ identities and AM holders are able to make contributions to the vechain ecosystem. For the stability of the vechain ecosystem in its early stages, we understand that while AM holders are pioneers and innovators in their own fields to join a public blockchain network for a distributed business ecosystem, many of them want to spend more time to explore and gain more clarity from both technical and regulatory perspectives.
Therefore, during the trial phase of the vechain Authority Masternode program, vechain has decided that it would be the AM holder’s discretion to disclose the status as an Authority Masternode holder to the public. New Authority Masternode applicants that are willing to disclose the status will be favored in the on boarding assessment. As the AM program matures, vechain aims to work closely with the AM holders to provide more transparency.
