WIP - Overbook validation nodes

[samuelmanzanera]

Description

This aims to resolve issue regarding the number of valiation nodes which not be availalbe during the transaction's validation and the election chose them.

This proposes an overbooking system for the validations based on the minimum validations nodes and to filter/jump nodes based on the election keeping the sorted algorithms and heuristic constraints.

Fixes #913, #980

Some changes are still required in that PR to improve the validation election verification

Type of change

• Enhancement

How Has This Been Tested?

• Unit test
• Integration test

Use the following patch to use deterministic validation node to help determine the validation to shut down

diff --git a/lib/archethic/election.ex b/lib/archethic/election.ex
index 465b55bb..d5d3cf03 100755
--- a/lib/archethic/election.ex
+++ b/lib/archethic/election.ex
@@ -22,29 +22,34 @@ defmodule Archethic.Election do
   Create a seed to sort the validation nodes. This will produce a proof for the election
   """
   @spec validation_nodes_election_seed_sorting(Transaction.t(), DateTime.t()) :: binary()
-  def validation_nodes_election_seed_sorting(tx = %Transaction{}, timestamp = %DateTime{}) do
-    tx_hash =
-      tx
-      |> Transaction.to_pending()
-      |> Transaction.serialize()
-      |> Crypto.hash()
-
-    Crypto.sign_with_daily_nonce_key(tx_hash, timestamp)
+  def validation_nodes_election_seed_sorting(_tx = %Transaction{}, _timestamp = %DateTime{}) do
+    # tx_hash =
+    #   tx
+    #   |> Transaction.to_pending()
+    #   |> Transaction.serialize()
+    #   |> Crypto.hash()
+
+    # Crypto.sign_with_daily_nonce_key(tx_hash, timestamp)
+    <<195, 51, 61, 55, 140, 12, 138, 246, 249, 106, 198, 175, 145, 9, 255, 133, 67,
+    240, 175, 53, 236, 65, 151, 191, 128, 11, 58, 103, 82, 6, 218, 31, 220, 114,
+    65, 3, 151, 209, 9, 84, 209, 105, 191, 180, 156, 157, 95, 25, 202, 2, 169,
+    112, 109, 54, 99, 40, 47, 96, 93, 33, 82, 40, 100, 13>>
   end
 
   @doc """
   Verify if a proof of election is valid according to transaction and the given public key
   """
   @spec valid_proof_of_election?(Transaction.t(), binary, Crypto.key()) :: boolean
-  def valid_proof_of_election?(tx = %Transaction{}, proof_of_election, daily_nonce_public_key)
-      when is_binary(proof_of_election) and is_binary(daily_nonce_public_key) do
-    data =
-      tx
-      |> Transaction.to_pending()
-      |> Transaction.serialize()
-      |> Crypto.hash()
-
-    Crypto.verify?(proof_of_election, data, daily_nonce_public_key)
+  def valid_proof_of_election?(_tx = %Transaction{}, _proof_of_election, _daily_nonce_public_key) do
+      # when is_binary(proof_of_election) and is_binary(daily_nonce_public_key) do
+    # data =
+    #   tx
+    #   |> Transaction.to_pending()
+    #   |> Transaction.serialize()
+    #   |> Crypto.hash()
+
+    # Crypto.verify?(proof_of_election, data, daily_nonce_public_key)
+    true
   end
 
   @doc """

You should run at least 6 nodes because the overbooking will try to get 5 nodes by default based on the min validation which is 3.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[samuelmanzanera]

TODO:

• start mining message can check if the level of decreasing is the same as the welcome node and send back otherwise to start the forward of the transaction
• ensure the replication confirmations respect the storage node heuristic constraints (in the mining & beacon chain & self-repair) --> NEW ISSUE TO CREATE