SymSensus

SymSensus Features

SymSensus has the following features:

• SymSensus is devised based on game theory. In particular, the Mechanism Design technique was applied using the most important theorem of social selection theory.

• SymSensus uses PBFT (Practical Byzantine Fault Tolerant) with voting including veto.

• The Warrant Node that creates blocks consists of two groups, A and B, with group A having the right of group veto.

• Group B selects through the Autonomous Bench Marking Test among the Work Nodes (Full Nodes not participating in the consensus).

• Unlike the existing blockchain consensus method, coins are not issued when creating blocks, and coins are distributed once a day by measuring network contribution.

• Primary nodes are determined randomly every block.

• Support Multi Block consensus.

• Communicate between nodes using SymSensus dedicated consensus protocol (N2N).

SymSensus Algorithm

SymSensus is a protocol that transforms PBFT into a form suitable for application to a blockchain. Nodes in charge of block creation are defined as warrant nodes by consensus in the blockchain network composed of multiple nodes. Warrant Node consists of 3F + 1 to endure F fault(malicious) nodes and is divided into Group A and Group B.

In order to create a new block, Group B must proposes a block and obtain group A's consent. The role of each group is as follows.

• Group A consists of F + 1 nodes and performs only the role of Verifier Node. Group A is elected according to the SymVerse Foundation operating rules.

• Group B consists of 2F nodes, of which one primary node serves to proposes block creation and the rest to act as verifier nodes. Group B is elected through real-time BMT.

Warrant Nodes are divided into the following roles.

• Primary Node: The node that proposes block creation among nodes in B group.

• Verifier Node: All Warrant Nodes except the Primary Node verify the proposed block as Verifier Node.

At the time of agreement, more than 1/2 + 1 of the number of A group nodes is considered as the opinion of the whole group A. This allows for a collective veto that shows the same result.

• Passed Conditions (Consensus Terms)

  • If 1/2 + 1 node of A group node approves and more than 1/2 node of B group node approve, it is considered to be agreed.

• Non-consensus condition

  • When 1/2 + 1 node of A group node is opposite (the opposite of F / 2 + 1 nodes)

  • When 1/2 + 1 nodes of the number of B group nodes are opposite (the opposite of F + 1 nodes)

A block is created and confirmed through ‘Propose’, ‘Verify’, ‘Pre-Commit’, and ‘Commit’ steps. If each of the stages meets the conditions, it moves on to the next stage. If one or more of the conditions are not satisfied, it restarts from the Propose stage.

• The Propose step is a step in which a primary creates a valid block and proposes it to another node. Primary constructs a block using a set of Transaction, Reward, etc. and propagates Propose Message including this to all Warrant Nodes. (Transaction sharing is done before block creation)

• The verify step is to verify the proposed block. In the verify step, after verifying that the proposed node is justified, the validity of the proposed block is verified through a set of transactions that have been shared beforehand. Once verified, the Node constructs a message containing the pros and cons of creating a new block and propagates it to other nodes. A node agreeing to create a new block waits for a message from another node to enter the next step.

• In the Pre-Commit step, the Primary collects the signatures of the nodes in favor, combines them into one signature, and sends a Pre-Commit Message to the other nodes.

• In the commit step, the proposed block is confirmed. Wait for Commit Messages from other nodes to confirm the block. If the pass condition is satisfied, the block is cereated and propagated.

FE-VoW Algorithm

VoW (View of Warrant) is a group of candidate nodes that can be a Primary Node among B groups, denoted by V.

FE-VoW works with SymSensus and supports the election and management of Primary Node. It is designed in a suitable form to agree on the fault of multiple nodes at a time.

FE-VoW starts when an event occurs and repeats indefinitely until the end condition is met.

• VoW agreement outset

  Warrant Node will proceed with VoW consensus once one or more of the following events are issued.

  • When Primary Node doesn’t send a Propose or Pre-Commit Message for more than a certain time.
  • When the connection status of Warrant Node is changed.
  • When receiving Suggest Message from Warrant Node of 2/3 + 1 or higher.

  Each Warrant Node can have a different starting time for consensus.

• VoW agreement in process

Warrant Node stops creating all blocks, including the Main-Block, when VoW agreement begins. Except for F in group B, V containing node ID (SymID) is created and Suggest Message is repeated to other Warrant Nodes until the end of the agreement.

In this case, A node of Group B not participating in VoW agreement is considered as F.

Each node can change own V until the node reach an agreement.

• End of VoW agreement

  If all the following conditions are met, the VoW agreement ends.

  • 2/3 + 1 Warrant Nodes must participate in VoW agreement.
  • A agreement must be made for each node included in V.
  • The total number of nodes in V must exceed the minimum number of quorums in group B.
  • There should be no new V for a period of time. (If the list of nodes included in V is the same, it is regarded as the same V.)

• Primary election

  Norwegian mathematician Hylland summarized the following about voting. “In a civil society, no one can benefit from the stochastic dictatorial (Veto) voting method.” Applying Hylland’s results to the BFT leads to the following theorem.

  “When the primary node (probable dictator) creates a block in the BFT consensus process where the Veto rights exist, voting participants can’t benefit from manipulating the consensus process.”

  SymSensus is a random number that uses the hash value of the final Main-block as a seed value. Therefore, Primary changes randomly in every block.

N2N Protocol

N2N (Node to Node) protocol is a protocol that supports reliable communication in consensus(agreement) between Warrant Nodes.

N2N is a TCP high protocol and accesses Warrant Boot Node to get a list of active Warrant Nodes and communicates with each Warrant Node 1:1. All Warrant Nodes include the functionality of the Warrant Boot Node.

N2N provides the following functions.

• Handshake

  Based on t he SymID and the final Warrant Block, the validity of the Warrant Node is determined, and the handshake is performed using the consensus-only key.

• Security (PKI)

  All packets are digitally signed and transmitted.

• Node Share

  Provides the ability to share a list of active Warrant Nodes.

• BMT (Benchmarking Test)

  It provides a function to BMT the Work Node that wished to be a new Warrant Node.

• Reputation Management (Yellow list, Black list)

  It manages faulty nodes and malicious nodes to support reliability and persistence in consensus and block creation.

• Node Management

  Group B among Warrant Nodes is changed periodically. Therefore, each node has a term and needs management. We define Warrant Nodes that are active during a certain period as ToW (Table of Warrant) and manage them by dividing into Previous, Active, Next, Candidate based on the final agreed MainBlock Number.

  • Previous: Previous Warrant Node
  • Active: Currently active Warrant Node
  • Next: Next Warrant Node to be active
  • Candidate: Warrant Node in BMT

Warrant Node Election (BMT)

Group B of the Warrant Node works for a term. Group B is elected from the Work Nodes that wish to become Warrant Nodes among the Work Nodes. (Not available in the current version)

BMT for the election of group B among the Warrant Nodes is conducted every day, and the 1/4+α (Fault Node) nodes of the number of B group nodes are elected and have the following activity cycle.

1. Work Nodes that want to participate in certification must meet the conditions of Full Node.
2. Nodes elected through BMT act as Warrant Nodes for 4 days.
3. Warrant Node, whose term ends, serves as the Work Node.

Candidate Node Evaluation

The candidate node applies for BMT to the currently active Warrant Node. The decision of the election is made by sharing and agreeing the evaluation table at each stage. It proceeds by reducing the number of nodes elected in stages, and only nodes elected in the current stage are eligible for the next stage evaluation. Nodes elected as Warrant Nodes may not withdraw deposits during the active period.

New Node Election Criteria

1. Reputation Assessment: Exclude nodes with a history of malicious activity.
2. Contribution Assessment: Deposit Absolute Assessment
3. Inter-Operability Test: Evaluates the ability to act as a Warrant Node.
4. Conformance test: Evaluates the normal functioning by participating in consensus.
5. Final rating: Random

Exclusion node selection criteria

1. The oldest Warrant Node is used. (If there are several nodes with the same participation time, they are randomly elected.)
2. Fault Node (α)

Processing when new node election fails

Warrant Node Election if there is not enough Work Nodes applied for BMT or the number of nodes that have passed BMT, the term of existing Nodes will be extended.

Known Issues(Attack) Countermeasures

• Nothing at Stake

  In the event of a Fork (branch of the blockchain), the stakeholder votes on all Forks so that he or she does not lose anything at stake. Fork does not occur in SymVerse blockchain.

• Bribe Attack

  Incentives to block creators and the creation of transactions containing malicious transactions. Since SymVerse operates a term guarantee node, it is only possible if an attacker buys 2/3+1 Warrant Nodes and the purchased Nodes act as Warrant Nodes at the same time. This is very difficult.

• Coin Age Accumulation Attack

  Issued when a block generator is selected as the coin holding period. It does not occur in SymVerse.

• Denial of Service

  An attack that delays verification work due to the occurrence of a large number of small transactions. SymVerse solves this with a fee policy.

• Sybil Attack

  The attacker makes an unnecessary transaction by making a fake node. SymVerse is based on SymID and can be defended in various ways such as Black list, Yellow list policy, Work node verification, Warrant node verification, and primary node election policy. It is almost impossible for a malicious transaction to reach the block creator.

• Double payment

  In SymVerse, only one primary node creates a block at a time, so no double payment occurs.

• Transaction malleability

  It is an attack method that generates a false transaction by modifying a transaction ID in a normal transaction. SymVerse embeds all transactions in the signed message, which is inherently impossible.

• 51% (66.6%) Attack

  SymVerse is inherently impossible because the Foundation directly manages 1/3+1 assurance nodes of all assurance nodes.

• Transfer to the unknow address/wrong address

  Since all users are recorded in the Citizen Block, false transfer can not be occurred.