FAST ∙ SCALABLE ∙ DEVELOPER FRIENDLY
The TrustME-PoW Consensus Scheme
Decentralized, Network Partition Tolerance, Minable
TrustNote Institute of Technology
May 2018
TrustNote Institute of Technology and Research & Development section hereby declare that, this package is under MIT open source software license and this software is distributed without any warranty. TrustNote Institute of Technology declares that we are NOT responsible for direct, indirect, incidental or consequential damages resulting from any defect, error or failure to perform. This package is experimental and a work-in-progress, use at your own risk. TrustNote R&D team can update (add/remove packages) any time without informing the users.
We do not guarantee the faulty or misleading data available in documents downloaded from any other website rather than two official websites introduced above.
Business Enquiries: foundation@trustnote.org
Technical Support: community@trustnote.org
© 2018 TrustNote Institute of Technology. All rights reserved.
- Node: Refers to any active user, installed TrustNote client (any devices such as phone, pc, IoT, etc.) and having a valid wallet address.
- Unit: Refers to a data structure which can contains many messages generated by the nodes including: Transactions messages, text messages and etc.
- Full Node: Refers to Cloud Host Server/Workstation, and PC, which maintaining synchronization and verification of ledger data.
- Super Node: Refers to Mining Systems, Cloud Host Server/Workstation, and PC, which generates a deposit contract and paying the deposit, and running the TrustME-PoW mining program.
- Parent Unit: Refers to units generated at an earlier time and Child Units can reference them.
- Child Unit: Refers to units generated at a later time and referencing one or more parent unit.
- MC: A single chain along Child-Parent links within the DAG which is determined by applying the Parent Selection Algorithm recursively.
- MCI: Main Chain Index.
- Attestor: Refers to a Super node, which participates in a round of consensus and successfully obtains Attestation power.
- PoW Unit: Refers to unit containing Equihash solution.
- TrustME unit: Refers to unit, used to determine the MC and its first message is a TrustME Coinbase message.
- Micro-Node: Refers to client running on Microcontrollers and Smart Cards.
- Light Node: Refers to client running on Smartphone and Tablet PC.
- Fine-grained PoW consensus: Each Super Node independently starts PoW, and there is no direct bound between nodes.
- Coarse-grained PoW consensus: The Super Node periodically starts PoW. Each round selects a certain number of Super Nodes as Attestors. These Attestors only belong to that specific round. Once that round finished, the Attestors automatically lose their Attestation power.
- Silent-locking time: Refers to the period of time when, a super node doesn't send any attestation unit.
TrustNote is a minable public DAG-ledger with an innovative, two-tier consensus mechanism designed to be "lightweight, efficient and trustworthy". Such two-tier consensus mechanisms can improve transaction throughput and reduce transaction confirmation delay, which effectively solving the problem of "Excessive Bifurcation" and "Double Spending". TrustME-PoW enables support for high concurrency transactions, fast transaction confirmation, and decentralized transaction unit strict sequencing mechanism. Even more, it also provides an important capability for TrustNote to support advanced declarative smart contracts and Micro-Nodes.
This report explains fundamental protocols governing the TrustNote platform, such as, super nodes management protocol, Main chain selection and best parent selection, Main chain stabilization protocol, and etc. After introducing all the prerequisites, TrustME-PoW consensus mechanism will be fully explained in detail.
The TrustNote network supports four types of nodes: Super-nodes, Full-nodes, Light-nodes, and Micro-nodes. A comparison between these four types of nodes presented in the table below.
Table 1-1 Comparison of four types of node
| Super Node | Full Node | Light Node | Micro Node | |
|---|---|---|---|---|
| ledger | full ledger | full ledger | light ledger | N/A |
| transaction | √ | √ | √ | commissioned |
| DAG consensus | √ | √ | indirect | × |
| TrustME-PoW | √ | × | × | × |
| TrustME-BA | √ | × | × | × |
| Hosting Micro Node | √ | × | × | × |
| deployment | Mining systems, Cloud Host Server/Workstation, PC | Cloud Host Server/Workstation, PC | Smartphone, Tablet PC | MCU, Smart Card |
Figure 1-1 P2P network Connection diagram between nodes
- Decentralized Attestor selection among super nodes.
- Users who want to become Super Nodes are required to create the deposit contract and pay the deposit. Full Nodes can become Super Nodes and join TrustME-PoW by paying 50,000 MN (Mega Notes) to their deposit contracts which would be created by themselves. Once the silent-locking time be over, the deposited TTT will be returned to the super node specified address. Super nodes won’t lose their deposit under any circumstances. Any malicious unit or suspicious behavior would only extend the silent-locking time.
- Super Node Clients are enjoying the premium package.
- Super Node Clients will be running multi-threaded platform (Full ledger thread, Super Node thread, Attestation thread, etc.). see figure 1-3
- Full ledger thread is used to synchronize and verify the generated units.
- Super Node thread let the Super Node clients to run Equihash. Once the super node thread finds the Equihash solution and after a specific procedure, they will receive Attestation power.
- Equihash solutions will be filtered by Difficulty filter. Also, Difficulty Adjustment performed by modified version of Digishield v3/v4 algorithm.
- The Main Chain selection algorithm, best parent selection and MC stabilization are triggered by the generation of each unit, to provide a high throughput for transactions confirmation while it preventing from creation of any forks and double spending.
- The PoW units and other units will be stabilized after the MC is determined and stabilized.
- The Attestors selection protocol is triggered once the PoW units are stabilized.
- Attestation thread will be started once Super Node client can establish a stable unit (containing Equihash solution) on the MC of DAG-ledger and its result would be evaluated as high performer.
- Attestation rewards are provided for Super Node clients who are having an active Attestation thread in a consensus round. Calculation of the rewards are according to the share of issued stable TrustME units located on MC.
Figure 1-2 TrustME-PoW Protocol Sketch
Figure 1-3 Illustration of the underlying mechanism of TrustME-PoW
The remainder of this technical report is organized as follows. In chapter 2, the node taxonomy, network topology and importance of Super nodes will be explained. Also, more detail about how a user can become a super node and the procedure the user should be through explained. Then, we will explain why the user should pay the deposit to become a Super Node and the procedure the user would be through to get it back. Chapter 3 is dedicated to Main Chain selection and stabilization algorithm, and the best parent protocol and its importance in MC stabilization and determination will be explained. In chapter 4 the innovative TrustME-PoW consensus with all detail will be explained. Even more, the reason why we have Attestors, what Attestors are doing, how Attestors benefit from helping the maintenance of the DAG-ledger, the switching procedure between rounds and so on are carefully explained. The procedure of calculation of the rewards and the procedure of sending rewards to Attestors also explained in this chapter. Finally, in chapter 5 the required steps that TrustNote should be taken to upgrade the network from Witnesses mode to TrustME-PoW mode fully explained.
Why do we need super node?
- Select Attestor in a decentralized way.
- Verification and analysis of the new units.
- Increasing the total computing power of the whole network.
- The more super nodes, the higher security of network.
- Super nodes and adoption of a Coarse-grained network algorithm make the whole network, partition tolerant.
Super nodes playing a key role in verification of the transactions, selection of parent units, transaction units sequencing, and micro-node protocols. In order to encourage nodes with high computing storage and network resources to become Super nodes, TrustNote has a total bonus of 500,000,000 MN. The total amount of bonuses is equal to the total circulation in the previous period. These bonuses prized during 30 years to those Super Nodes who will help in maintenance of the TrustNote DAG-ledger. The Attestation Reward Policy allocates 6.79% of Total Attestation Rewards for the first year, after which the yearly allocated Attestation Rewards decays year by year according to Figure 2-1, of these, 90% of Attestation Rewards are allocated to the Super Nodes who provide valid Attestation Units, 10% of Attestation Rewards are allocated to TrustNote Foundation to support community operations, project incubation, and rewards to contributors etc.
Figure 2-1 Attenuation Chart of Attestation Rewards
Full nodes can become Super node, while light nodes and micro-nodes cannot become Super nodes. To become a Super node, first it is required to download and install the Super node client program, then create the deposit contract and pay it, also it needs to assign the address that the deposit will goes to it later. After the Super Node obtains the Attestation power, it must synchronize and verify the rapid growth of the DAG-ledger data, while participating in the competition for the next round of Attestation at the same time. Even more, it will become the agent of the micro node in the future. Therefore, Super nodes need to have high computing performance. Super Node resource consumption:
- Synchronous DAG-ledger consumes network, memory, and hard disk IO resources.
- Verification of ledger consumes CPU, memory, and hard disk IO resources.
- PoW consumes RAM and CPU/GPU resources.
- Database operations consume hard disk IO, CPU, and RAM resources.
The Super node can generate normal units and TrustME units. The address of the generated TrustME unit must be the same as the one used to generate the deposit contract. There is only one Super node address for each deposit contract. If a Super node wants to have more than one competing Attestors’ address (such as a mining pool), it needs to generate multiple deposit contracts and pay them. By considering the safety issues of the Super Node itself and security of the network, the deposit required for the Super Node assigned as 50,000 MN.
The main purpose of the deposit is to guarantee the trustworthy of the super nodes, if any super node tries to violate the rules the deposit value will be reduced; also, it reduces the malicious node's attack on the consensus mechanism. When there is a sufficient number of TTT in the deposit contract address issued by a certain node, the node can immediately participate in the TrustME consensus to obtain Attestation power in certain rounds, send Attestation units and then get its Attestation rewards. In order to prevent the loss of the Super nodes’ deposit and the witch attack due to hacking, the Super nodes deposit has a silent locking time (SLT) when the Super nodes’ deposit is frozen in a smart contract. The Super node deposit silent locking time is 17,280 consensus rounds. If the Super node has not sent any TrustME unit or wrong unit within the lock time, all the TTT in the deposit contract can be transferred to the specific address assigned by that Super node in the smart contract, otherwise the silent-locking time reset.
Super nodes are always online and vulnerable to attack. Therefore, a shorter consensus round duration should be set. If it is set to 5 minutes, the probability of the Attestor node being invalid or being hacked is reduced significantly. In order to improve the security of the Super Node funds, the deposit contract sets the deposit payable address and the Attestation bonus receive address. Super Node should set different addresses as the deposit payable address, payout address, and the Attestation bonus. Even more, Super Nodes are required to use the cold wallet to set the Attestation bonus receive address to increase the security of the Super node deposit and Attestation bonus.
messages: [{
app: 'Deposit',
payload_location: 'inline',
payload_hash: 'hash of payload',
payload: {
silent-locking time: '17280',
payout_address: 'Wallet Address of Node',
reward_receiver_address: 'Wallet Address of Node'
}
}]In this section it is explained that:
- What the Main Chain is and introducing some basic concepts about it.
- How the main chain is determined and what the best parent is.
- How we determine the best parent and what the procedure for main chain stabilization is and more.
TrustNote does not have a block limitation. Any node can generate a new unit (e.g. a transaction) at any time and broadcast it to other nodes. The unit can select one or more previous units as parent units, each new unit validates its own parent units and adds the parent units' hash value to its own header. In this manner, the parent-child relationship between them can be expanded into a directed acyclic graph. DAG is a finite directed graph with a topological ordering (a sequence of the vertices such that every edge is directed from earlier to later in the sequence). The Acyclic property of the graph means there is no way to start at any unit U and follow a sequence of vertices that finally loops back to U again.
Figure 3-1 TrustNote simplified DAG-ledger
Assume an attacker wants to modify a unit. The attacker will be successful if it would have conspiracy with all other nodes to gossip the new ledger which containing the modified unit; which with the existence of honest nodes it’s impossible. Even more, assuming that the digital signature is unforgeable, the greater the number of nodes on the entire network, the more difficult it is for an attacker to tamper a unit. Consequently, it’s about to impossible for an attacker to do so
- Unit Inclusion: If "A" verifies "B", the unit "A" header contains the hash of the unit "B", so we say the unit "A" includes the unit "B". This inclusion relationship between the nodes is represented by a directed arrow between edges "A" and "B" on the DAG. If unit "A" includes unit "B" and the minimum path between the two units is "1", then it is said that unit "A" includes unit "B" directly; if unit "A" includes unit "B" and the minimum path between the two units is greater than "1", then unit "A" includes the unit "B" indirectly. Examples of unit inclusions are presented in figure 3-2 (a) and (b) below.
- Parent Units and Child Units: If unit "A" directly includes unit "B", we say unit "A" is the child of unit "B", and unit "B" is a parent of unit "A".
- Genesis Unit: The genesis unit has no parent and is the first unit in TrustNote DAG ledger which indicated with the letter "G" in figure 3-2.
- Childless Unit: The units without child are called childless units. Unit "A" in figure 3-2 is an example of a childless unit.
- Sequential Units: Any two desired units are defined as sequential units if they would have a directed path connecting those units, otherwise they are called non-sequential units. All the units sent by an Attestors from a certain address must be sequential units, otherwise they will be eliminated from the DAG.
Figure 3-2 Examples of inclusion relationship between units: a) Unit "A" verifies and contains unit "B" directly Unit "B" is the parent of unit "A". b) Unit "A" contains unit "B" indirectly and unit "A" is called a childless unit.
- Unit Level: The unit level is defined as the longest path length from that unit to Genesis unit. For instance, the Unit level of unit "A" in figure 3-2 (b) is 3
- Attestation Level: To determine the Attestation Level for any unit labelled as starting unit, follow the path along best parent chain, until finding more than half of all Attestors’ Attestation unit along the path. Then calculating the unit level of the stop unit, this value is the Attestation Level of the starting unit. The genesis unit is created by all initial Attestors, so it’s the best parent naturally.
Each unit (except Genesis unit) in DAG ledger has one or more parent units. According to a consistent algorithm, we can select the best parent units among the available parent units. The best parent unit selection algorithm is showed as below:
1. Start from a unit.
2. Selecting the parent unit with the highest Attestation level as its best parent unit.
3. If there are multiple candidate units, the unit with the lowest unit level will be selected as the best parent unit;
4. If there are still multiple candidate units, the unit with the smallest unit hash is the best parent.
Figure 3-3 the best parent selection explained in four slides.
In this way, you can get a path starting from any Childless Unit, connecting the selected best parent units and finally reaching the Genesis Unit. This path is called the "Main Chain". As many childless units exist, there might be many "Main Chains", but the one which starts from the Childless Unit with the highest Attestation Level finally will be selected as Current Main Chain.
According to the Best Parent Unit Selection algorithm, all main chains started from childless units will merge at a point. The part from the merging point to the Genesis Unit are completely same. If any new childless units added to DAG ledger cannot change the merging point, the part of main chain from the merging point to the Genesis Unit can be called stable. All units included by the stable main chain unit directly or indirectly will be stable too. The last stable main chain unit is called the Last Stable Unit. All stable main chain units have an index, called Main Chain Index (MCI).
- The MCI of the Genesis unit is 0, which increases sequentially along the stable main chain.
- The MCI of a normal unit is equal to the minimum MCI of the stable main chain units which include that unit.
According to MCI, we can obtain the total order of all stable units and can use this definitive total order to prevent double spending. This process is called "unit final confirmation". With the addition of new units, the stable main chain on DAG ledger will continue to grow and all related units will be confirmed.
The main chain stabilization algorithm uses the Current Main Chain as a reference to determine whether the last stable unit can be transferred to the next unit of the Current Main Chain or not. According to the child unit number of the last stable unit, this algorithm can be divided into two cases:
Assuming that UL is the unit level of the unique child. By tracing back along the Current Main Chain from the child until more than half of the Attestors of the current consensus round’s Attestation units are meet, the minimum Attestation level of these Current Main Chain units is denoted as minAL. If minAL > UL, the last stable unit can be transferred to the unique child. This procedure (simplified as much as possible) is presented in the slides below:
If these child units that are not on the current main chain, are not the best parent of the other units; they have no chance to compete for becoming a main chain unit, so we should turn back to use Case 1. Otherwise, we can get a complete alt-branch according to that best parent chain. The maximum unit level of all alt-branch units is called maxUL. If maxUL < minAL, we can push the last stable unit to next unit along the current main chain. Even if less than half of the other Attestors all support the alt-branch, the Attestation level of any unit on the alt-branch will not exceed maxUL. Continue presenting the previous example to reach this condition as below.
TrustNote adopts a two-tier consensus mechanism comprising "base consensus" and "TrustME consensus". The base consensus, also known as "DAG consensus", requires new units sent by nodes to verify previous units and reference them. The TrustME consensus is used to select a main chain on DAG ledger and give out the total order of all stable units based on the main chain. Such two-tier consensus mechanisms can improve transaction throughput and reduce transaction confirmation delay, thus effectively solving the problem of Excessive Bifurcation and double-spending.
TrustME-PoW designed in two different types during the conceptual design phase:
- Fine-grained
- Coarse-grained
Both methods studied carefully, but in fine-grained PoW schemes, there is not any bound between Super Nodes necessarily. In case of network-partitioning, as long as there are Super nodes in each partition, MC growth and stability will still be promoted, which will lead to successful confirmation of a double spent unit. To resolve this issue some attributes suggested for strengthening the bounds between the Super nodes. Eventually, it observed that nodes’ bounding that achieves a fine-grained consensus is equivalent to transforming the fine-grained consensus into a coarse-grained consensus. Therefore, in final design Coarse-grained PoW selected.
In addition, when the network is divided, networks with more than (n/2) Attestors will continue to expand, and the main chain will continue to grow and stabilize over time. If in the partitioned network, the Attestors number is less than or equal to (n/2), all the units in the network will not become stable and a new round of TrustME-PoW consensus cannot be completed until the network get more than (n/2) Attestors.
TrustME-PoW conducted in separate rounds. Each round lasts until the next round Attestors list will be completed. Eighteen Attestors will be selected in each round and two other Attestors maintained by TrustNote will be added to the consensus round, which results in twenty Attestors in each consensus round.
Continuing the example in section 3.4 of this report, we will demonstrate more detail about the working mechanism of consensus round. Assuming three units in gray presented in figures below are PoW units each for one of the Attestors to take part in the next consensus round.
Once unit "l" becomes stable, at T14 last PoW unit, unit "i" for one of the Attestors interested in taking part in next consensus round becomes stable and next consensus round starts immediately. The partial MCI order of each PoW unit becomes stable determines the priority of the Attestors in next consensus round.
For ith consensus round, the super node thread calculates pubSeed(i-1),Coinbase(i-2) and pubSeedi = blake2256(pubSeed(i-1) || hash(Coinbase(i-2)) || hash(FirstStableMCUnit(i-1))). Finally, it uses pubSeedi to calculate the Equihash calculation input for one super node n as Seed(i,n) = blake2256(pubKeyn||pubSeedi), and then calculates Equihash difficulty factor "d". The difficulty factor "d" is designed and adjusted for each consensus round based on desired time of about five minutes to find the solution of Equihash. It means this parameter is a threshold and the result of solving Equihash must have a certain number of leading zeroes to be accepted. This parameter will be adjusted with respect to desired time of generating a PoW unit and it will be applied to the system smoothly.
Super nodes are running the Equihash Algorithm with the calculated parameters to find Equihash solutions as quick as possible. Once they find a right solution, they will generate a PoW unit containing the solution and publishes it to the DAG ledger. The first eighteen addresses owning a stable PoW unit will obtain the Attestation power and to be an Attestor in the ith consensus round. If there are multiple Super nodes submitting many PoW units at the same time, the priorities are determined according to the MCI of the PoW units. If the MCI is the same, the smaller the unit hash is, the higher the priority of the Attestor it provides. In each consensus round, 18 different Super nodes corresponding to the first 18 stable PoW units will be given the Attestation Power. TrustNote Attestors are having the highest priority among others. The first two Attestor of each round are TrustNote Attestors and the other eighteen Attestors will be sorted based on their PoW unit priority from 3 to 20.
{
unit: {
version: 'Protocol Version',
alt: ‘Alternative Currency’,
messages: [{
app: 'payment',
payload_location: 'inline',
payload_hash: 'Hash of Payload of this Transaction Message',
payload: {
outputs: [{
{address: 'Destination Wallet Address', amount: 9989459}],
inputs: [{
unit: 'Wallet Address of Origin of the Message',
message_index: 0,
output_index: 0
}]
}
}],
messages:[{
app: ' PoW-Equihash ',
payload_location: ' inline ',
payload_hash: ' hash of payload ',
payload: {
round: ' round number ',
seed: ' string of seed ',
difficulty: '',
solution: '',
attestor_address: ' Wallet Address of Node '
}
}]
authors: [{
address: 'Attestor Address',
authentifiers: { r: 'Attestor Signature' }
}],
parent_units:['FZvSHUDsqG+TDJizrqzkNBrQUv7PDE4EwWdm68FNMuU='],
headers_commission: 60% of Total PoW unit Size,
payload_commission: 40% of Total PoW unit Size,
unit: 'Hash of this PoW unit'
}
}The fact that consensus round switching happens is deterministic, but there are still some questions might be tickling your mind such as when the right time is to switch to next consensus rounds, or How to determine the validity of an Attestation unit and so on. The slides below (continued from section 3.4 and section 4.2) presenting additional details to answer all these questions.
An Attestor can send multiple TrustME units within its consensus round. The TrustME units will be selected as the MC unit with a large probability. Each Attestor in the consensus round sending TrustME units according to the priority order. To reduce the delay in confirmation of the transactions, if any of the Attestors don’t send the TrustME message during a certain time the next two Attestors can send the TrustME unit. (e.g. if Attestor "5" doesn’t send the Attestation unit during a certain time, the Attestor "6" and "7" will start sending units.)
The first TrustME unit which sent in each round should be sent by foundation Attestor and should contains the full Coinbase list of (i-2)th round’s Attestors. The only difference between this unit and unit sent by other Attestors is, to reduce the unit fee for other Attestors they only contain hash of Coinbase message in their first TrustME message which is the consensus on Coinbase message. If any of the Attestors don’t agree upon this message they can calculate the Coinbase list and generate their own Coinbase message and send it.
| TrustME unit Sending Mechanism |
|---|
|
Attestation threads At any Consensus round: (a) Top twenty Attestors, aware of their priority joining the consensus round. (b) First Attestor should sends its first TrustME unit within 5 seconds, otherwise it will be replaced with the next eighteen Attestors on the list. (c) First Attestor on the list send the first TrustME unit. (d) The first TrustME unit contains the Coinbase list of rewards for previous consensus rounds which will be sent by the first Attestor. (e) All the Attestors should send their units with respect to priority list. (f) The consensus round finishes and (a) will be performed again. |
{
unit: {
version: 'Protocol Version',
alt: ‘Alternative Currency’,
messages: [{
app: 'payment',
payload_location: 'inline',
payload_hash: 'Hash of Payload of this Transaction Message',
payload: {
outputs: [{
{address: 'Destination Wallet Address', amount: 9989459}],
inputs: [{
unit: 'Wallet Address of Origin of the Message',
message_index: 0,
output_index: 0
}]
}
}],
messages: [{
app: 'TrustME',
payload_location: 'Inline',
payload_hash: 'Hash of Payload',
payload: {
round: 'Round Number',
PoW_solution: 'The PoW Unit Hash',
priority: 'Priority of Attestor',
coinbase of (i - 2)th round：[
{address: ‘...’, amount: 21 MN},
...
]
}
}]
authors: [{
address: 'Attestor Address',
authentifiers: {r: 'Attestor Signature' }
}],
parent_units:['FZvSHUDsqG+TDJizrqzkNBrQUv7PDE4EwWdm68FNMuU='],
headers_commission: 200,
payload_commission: 200,
unit: 'Hash of this PoW unit'
}
}If TrustNote Attestors or any of other eighteen Attestors in the consensus round wouldn’t be available for any reason the next priority Attestor in current consensus round will immediately start sending TrustME units. (e.g. if Attestor “5” is not available, the Attestor “6” start sending units.)
If the TrustME unit sent by the Attestor of a consensus round is a stable unit on MC, the Attestor will receive Attestation reward and the larger the proportion of the TrustME units it sent, the more Attestation reward it would receive. In the absence of stability in the main chain, it is impossible to determine which TrustME units are on the main chain and it is not fair to calculate the Attestation bonus. Therefore, this consensus mechanism does not provide Coinbase directly (like Bitcoin) in the unit. Only after all the TrustME units belonging to the same round on the main chain are stable, TrustNote Attestors calculate how many Attestation bonuses can be obtained for each Attestor in that specific round; the reason for this is to eliminate the cost of generation of this unit for Attestors. After all the TrustME units of a consensus round are stable, the number of TrustME units at each address in the statistical chain shall be calculated according to the proportion of the Attestation bonuses. Even more, if any Attestors has doubt in calculated share of Attestation reward, they can generate the Attestation share list of that specific round by themselves and reference the TrustNote unit to make sure.
At a certain time, the ith round’s Attestors are on duty.
| Round Number | Attestor | TrustME unit |
|---|---|---|
| i-1 | invalid | being stable |
| i | sending TrustME units until all units in round (i-1) has been stable and there are enough Attestors for round (i+1) | not stable |
| i+1 | waiting until the first TrustME unit of round (i) to become stable, and making consensus with the seed of round (i), the Coinbase of round (i-1) and First Stable MC unit (i) | N/A |
At the junction, there might be cases where the ith TrustME unit is sent after starting the (i-1)th round of TrustME. At this time, the TrustME unit of the ith round will be deemed as illegal.
This section gives out the list of steps about how to convert to the TrustME-PoW consensus mechanism.
| Round Number | Attestor |
|---|---|
| 1 | Wait for a MC unit with a specific MCI value (e.g. 1,000,000) to become stable. |
| 2 | The R1 consensus round is initiated. The R1 public seed is an initial random number and then the respective seeds of the R1 round super node are calculated. The initial difficulty factor is 1. The super node using difficulty and node specific seed to calculate the Equihash solution. The super node proceeding to take part in the R1 consensus round should issue one PoW unit. |
| 3 | Wait for Witnesses to make first eighteen PoW units to become stable and select all twenty Attestors for R1 round. |
| 4 | Once the list of Attestors are determined, the witness consensus mechanism is deactivated, and the R1 Attestors start sending the TrustME units. |
| 5 | Wait for the first TrustME unit of R1 to become stable on MC. |
| 6 | The super nodes proceeding to attend the R2 consensus round, calculates the R2 public seed based on the public seed of the R1 and the genesis unit. The super node using difficulty and node specific seed to calculate the Equihash solution. |
| 7 | The super node proceeding to take part in the R2 consensus round should issue one PoW unit. |
| 8 | Wait for Attestor of the R1 to make first eighteen PoW units to become stable and determine the top eighteen Attestors for R2. |
| 9 | The R1 Attestors end the mission, and the R2 Attestors start sending the TrustME units. |
| 10 | Wait for the first R2 TrustME units to become stable on MC. |
| 11 | The super nodes proceeding to attend the R3 consensus round, calculates the R3 public seed based on the public seed of the R2, the Coinbase(i-2) equal to Coinbase of round R1 and the FirstStableUnit(i-1). The super node using difficulty and node specific seed to calculate the Equihash solution. The super node proceeding to take part in the R3 consensus round should issue one PoW unit. |
| 12 | Wait for Attestor of the R2 to make first eighteen PoW units to become stable and determine the top eighteen Attestors for R3. |
| 13 | The R2 Attestors end the mission, and the R3 Attestors start sending the TrustME units. The first TrustME unit contains the Coinbase result for the Attestors of R1. |
| 14 | Wait for the first R3 TrustME units to become stable on MC. |
| 15 | The super nodes proceeding to attend the R4 consensus round. |
Eventually, all the consensus rounds after R3 following the same procedure as R3.