Main Chain

Consensus Node

Consensus Mechanism

The system can coordinate the orderly participation of each system participant in the data packing and consensus process through the consensus mechanism. It can ensure the data consistency of the participants.

The system shall be able to reach a consistent and correct consensus and output correct results within the specified time if there are no faulty nodes or fraudulent nodes. The system shall be able to work properly if the total number of faulty and fraudulent nodes does not exceed the theoretical value.

The main chain of Ethanim adopts the Trias Layer-1 solution, and the supernode selected by TEE adopts Practical Byzantine Fault Tolerance (PBFT) , and introduces TEE-related contents in the consensus algorithm to strengthen the security of PBFT.

Firstly, the nodes involved in the consensus are obtained by the Ladder (Trias Node Ranking List), and the corresponding periodic changes are made; secondly, the consensus nodes make corresponding dynamic changes based on the confirmation results of the TEE; again, the penalty mechanism is introduced based on the confirmation results of the TEE, which improves the cost of the consensus nodes to do evil.

Assume that the number of total votes of all nodes in the network is n, the number of malicious votes is

f<={(n-1)/3}, and n=3f+1.

In practice, for each final consensus block, it needs to be voted twice, and both votes need to reach 2f+1. In the main chain network, the messages that nodes communicate with each other include the following three types:

PROPOSAL, PRE_PREPARE, and PREPARE.

PROPOSAL messages are used by the proposing node to propose a block in the current round, while PRE_PREPARE and PREPARE are used to vote on the block. In the PROPOSAL phase, the message sent by the node responsible for proposing will contain the entire block information. While in both PRE_PREPARE and PREPARE phases, only the hash value of the block information is sent as an identifier to reduce the network communication.

The main-chain consensus algorithm corresponds to each block, and all of them work in rounds. Each round corresponds to a designated consensus node responsible for distributing a proposed block. It is specified by a mapping function that conforms to a weighted polling scheduling algorithm, proportional to the votes held by the consensus node.

The message broadcast by node N that is responsible for each round of proposal contains all the contents of the entire block. Assume that after a time interval t, all consensus nodes have received the message of this proposed block. If other consensus nodes receive the message in the PROPOSAL phase, they will first validate whether node N is in the current set of consensus nodes and the node has been recently confirmed with no abnormal results. After the verification is passed, the content of the block is then verified. Index Server

The consensus node acts as an index server when RSM extracts the application image and snapshot files. The consensus module is integrated with the indexing service together in the same node, so that when the application is respawned or restored to a certain state, the image and snapshot hashes can be searched from the main chain ledger through the indexing service on the consensus node, and the hashes will be sent to RSM. The main chain ledger provides multiple block indexing methods to find the blocks quickly. These methods include block number, block hash, and transaction number.

As the figure shows, we can decompose the query object into a two-tier architecture of the database of the file system. The file system records the stored information of data in a chain structure of blocks. Each block contains a block header and metadata recording the current block information, and a block body consisting of validation records and mirrored hash values. To speed up querying or to implement specific query functions, the block information is categorically extracted and stored in the KV database.

State Database: Maintains the latest KV states, which are modified according to the latest block things. The state database supports key-based queries, combined key-value pair queries and key range queries.

Key history index: Record the key history change status, used for traceability query.

Block index: the corresponding hash value of the storage block and the location of the block in the file system; the storage block number and its location in the file system; the hash value of the image and its location in the file system. The quick location of blocks and transactions is achieved by the above three ways.

Shuffle Algorithm

All validators are randomly divided into n groups, and one group is randomly selected to validate the RSM using the VRF algorithm.

VRF is a verifiable random function (VRF), which has pseudo-randomness on the one hand, and validatability on the other hand (the output includes a non-interactive zero-knowledge proof).

• Pseudo-randomness

• Validatability

Suppose it is round 10 (the 10th round) and the consensus network layer randomly divides all registered validators into n groups, each group contains a fixed number of validators, and then randomly selects one of the validators to validate the status of RSM. The process is as follows.

1. The consensus layer proposer divides all validators into n groups using the VRF algorithm and obtains the validatable hash group_number_hash

2. Again use the VRF algorithm to select one group of validators combination x and get the validatable hash select_group_hash

3. Call validate combination to validate RSM state pending_state, get result validate_result

4. Broadcast [n, group_number_hash], [x, select_group_hash], [pending_state , validate_result], and other related information.

Finally, wait for the consensus result. VRF Process

The prover has a public-private key pair

1. approver generates a hash using the private key and alpha input beta

beta = VRF_hash(SK, alpha)

1. Generate random number pi

pi = VRF_prove(SK, alpha)

Validation by others

1. Validate the validity of random numbers using a public key, original message alpha , pi

VRF_verify(PK, alpha, pi)

1. If pi is valid, outputs beta and valid

Elliptic Curve VRF (ECVRF)

ref: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-vrf-07

• ECVRF Proving

ECVRF_prove(SK, alpha_string)

Input:

SK - VRF private key

alpha_string = input alpha, an octet string

Output:

pi_string - VRF proof, octet string of length ptLen+n+qLen

Steps:

1. Use SK to derive the VRF secret scalar x and the VRF public key Y

= x*B

(this derivation depends on the ciphersuite, as per Section 5.5;

these values can be cached, for example, after key generation,

and need not be rederived each time)

2. H = ECVRF_hash_to_curve(Y, alpha_string)

3. h_string = point_to_string(H)

4. Gamma = x*H

5. k = ECVRF_nonce_generation(SK, h_string)

6. c = ECVRF_hash_points(H, Gamma, k*B, k*H) (see Section 5.4.3)

7. s = (k + c*x) mod q

8. pi_string = point_to_string(Gamma) || int_to_string(c, n) ||

int_to_string(s, qLen)

9. Output pi_string

• ECVRF Proof To Hash

ECVRF_proof_to_hash(pi_string)

Input:

pi_string - VRF proof, octet string of length ptLen+n+qLen

Output:

"INVALID", or

beta_string - VRF hash output, octet string of length hLen

Important note:

ECVRF_proof_to_hash should be run only on pi_string that is known

to have been produced by ECVRF_prove, or from within ECVRF_verify

as specified in Section 5.3.

Steps:

1. D = ECVRF_decode_proof(pi_string) (see Section 5.4.4)

2. If D is "INVALID", output "INVALID" and stop

3. (Gamma, c, s) = D

4. three_string = 0x03 = int_to_string(3, 1), a single octet with

value 3

5. zero_string = 0x00 = int_to_string(0, 1), a single octet with

value 0

6. beta_string = Hash(suite_string || three_string ||

point_to_string(cofactor * Gamma) || zero_string)

7. Output beta_string

• ECVRF Verifying

ECVRF_verify(Y, pi_string, alpha_string)

Input:

Y - public key, an EC point

pi_string - VRF proof, octet string of length ptLen+n+qLen

alpha_string - VRF input, octet string

Output:

("VALID", beta_string), where beta_string is the VRF hash output,

octet string of length hLen; or

"INVALID"

Steps:

1. D = ECVRF_decode_proof(pi_string) (see Section 5.4.4)

2. If D is "INVALID", output "INVALID" and stop

3. (Gamma, c, s) = D

4. H = ECVRF_hash_to_curve(Y, alpha_string)

5. U = s*B - c*Y

6. V = s*H - c*Gamma

7. c' = ECVRF_hash_points(H, Gamma, U, V) (see Section 5.4.3)

8. If c and c' are equal, output ("VALID",

ECVRF_proof_to_hash(pi_string)); else output "INVALID"

Blockchain ledger

A blockchain ledger is a tamper-proof, shared digital ledger. It is used to record transactions in a public or private peer-to-peer network. The ledger is distributed to all member nodes in the network. The history of asset transactions occurring between peer nodes in the network is permanently recorded in the block.

Member nodes in a blockchain network do not rely on a third party (such as a financial institution) to arbitrate transactions; they use consistency protocols to negotiate the contents of the ledger, using cryptographic hashing algorithms and digital signatures to ensure the integrity of transactions.

Since tampering needs to be performed in many places at once, consistency ensures that the shared ledger is an exact copy and reduces the risk of transaction fraud. Cryptographic hash functions (such as the SHA256 ) ensure that any change to a transaction input, even the slightest change, will output a different hash value indicating that the transaction input may be corrupted. Digital signatures ensure that the transaction originates from the sender (who has signed it with a private key) and not from an impostor.

A decentralized peer-to-peer blockchain network prevents any single or group of participants from controlling the underlying infrastructure or corrupting the entire system. The participants in the network are equal and all follow the same protocol. They can be individuals, country representatives, corporations or a combination of all three participants. At its core, the system records the chronological order of transactions and all nodes agree on the validity of transactions using a selected consistency model. This will make the transactions irreversible and accepted by all members of the network.

Ethanim ledger

The Ethanim ledger does not store specific transaction information, but only the hash of address account status change and the validatable hash to ensure that the address account status change is legitimate. The details of the transactions are stored in the eternal file system.

Main Structure of Block

Block {

BlockID

Height

PreBlock

TxSet {

{address1, state_hash, per_state_hash, prove_hash,validator, ...}

{address2, state_hash, per_state_hash, prove_hash,validator, ...}

}

Proposer

Reward

Signature

PublicKey

...

}