Operational Level

Operational Choice Level

The operational choice level is categorized as the node environment (reference to earlier post). This post will delineate the action processes in the node environment and aim to test the network’s resilience when subject to flooding attacks (1/3 & 2/3).

The processes in the node environment are illustrated and described below.

  1. Any user can become a node over time and must first become a prospect node. The transition is based on an unpredictable deterministic random (UDR) selection, a lottery, to help ensure a broad representation of users as nodes. When going from a user to a prospect node, the user is no longer anonymous but a public servant with a public name record in the system.

  2. When prospect nodes have been socially verified and earned enough prospect score, that is being available for the network for a period of time, then the prospect node becomes a node, i.e. born and receives a gene number and a birth date.

  3. Available and active nodes are swapped back and forth continuously to make it impossible to predict which nodes are active in 10-minute intervals to enhance security. A node is selected by an Unpredictable Deterministic Random (UDR) algorithm, where the probability of being chosen as an active node or to continue as an active node depends on four variables: Gene score (gs), active time (at), node age (no) and contribution loyalty (cl) – also referred to as the reputational score later.


  4. A node can go from online to offline and vice versa.

  5. If an active node distributes false information, the active node pool will identify the node through the consensus protocol. When the malicious node is detected, it will be banned by a voting protocol embedded in the consensus algorithm.

Step 3 is exciting when evaluating the network security. To test the probability of a flooding attack (1/3 & 2/3), a dynamic flooding model was developed that performs the action of swapping nodes between the available node pool and active node pool. For each round (epoch), one available node is designated as an active node and vice versa.

The flooding model introducing several variables to work with

  • Number of total nodes
  • Number of nodes in active node pool
  • Number of evil nodes
  • Reputational score for each group

We will perform a test case for each variable (in total 4 test cases) to assess the variables impact on the swapping processes and ultimately conclude how many evil actors there exists over time (Rounds = Epoch) in the active node pool. To ensure the reliability of the generated output, we will be consistent when choosing values for variables.

To simulate the test cases, we use Monte Carlo Simulations. A Monte Carlo simulation is a method for approximating different outcomes using random samples. An approximation is, in mathematical terms, called an expectation. Thus, it can be derived


The first variable assessed is the number of nodes in the active node pool . All other variables are kept stable as constants to isolate the effect.

Testcase 1

Variables Value Scenario1 5 %
Total nodes 1.000 Scenario2 10 %
Nodes in active node pool x Scenario3 15 %
Number of evil nodes 20 % Scenario4 20 %
Reputational score for each group 1 Scenario5 25 %

As illustrated in the above graph, there is a clear correlation between the number of active nodes and the possibility of a 1/3 attack. 2/3 is not reachable at 20 % evil nodes in any of the test scenarios. As we increase the number of nodes in the active node pool, the probability for a 1/3 attack declines rapidly due to falling volatility, where the number of evil actors in the active node pool is more stable around its mean.

Let’s proceed to test if network adoption has any effect. Our point of departure will be test scenario3 that generated zero 1/3 attacks.

Testcase 2

Variables Value Scenario6 (same as 3) 1000
Total nodes X Scenario7 2000
Nodes in active node pool 15 % Scenario8 3000
Number of evil nodes 20 % Scenario9 4000
Reputational score for each group 1 Scenario10 5000

The test scenario indicates that, as the total nodes in the system accelerate, the resilience advances. Again, the volatility decreases, and the network becomes more robust as a consequence. When evaluating test scenario6 (dark blue) and test scneario10 (light blue), the graph shows that test scenario10 does not provide any significant peaks as scenario6.

For further analysis, we will proceed using the most stable outcome (scenario10). The test case will aim at testing how many evil nodes the network can process before 1/3 and 2/3 attacks become a reality.

Testcase 3

Variables Value Scenario11 (same as 10) 20%
Total nodes 5000 Scenario12 25%
Nodes in active node pool 15 % Scenario13 30%
Number of evil nodes X Scenario14 35%
Reputational score for each group 1 Scenario15 40%

To test larger pools of evil nodes five extra tests are included.

Scenario16 45%
Scenario17 50%
Scenario18 55%
Scenario19 60%
Scenario20 65%

The graph shows how a five percent increase in evil nodes is affecting the active node pool. As you could expect, the number of evil nodes is a strong driver for potential attacks. Still, the graphs give a good overview of the different levels.

Now let’s include the reputational score. Test scenario20 will be the baseline to test the impact of the reputation score. By utilizing test scenario20, we can test if we can avoid a 2/3 attack.

Testcase 4

Variables Value Scenario6 (same as 3) 1000
Total nodes X Scenario7 2000
Nodes in active node pool 15 % Scenario8 3000
Number of evil nodes 20 % Scenario9 4000
Reputational score for each group 1 Scenario10 5000

The results generated were not as expected. The assumption was that by including the reputational score, the percentage of evil nodes in the active node pool would decrease since the probability to be chosen as an active node is calculated by


Instead, the reputational score delays the attack but does not prevent it. Still, the results illustrate that the percentage of evil actors in the active node pool inevitably will reach the same level.

What we will seek to do in the next post is to change the swapping method from the active node pool to the available node pool.

Please share any comments, concerns, and ideas you may have :blush:

1 Like