nion-network / core Goto Github PK

Implement protobuf using https://kotlin.github.io/kotlinx.serialization/kotlinx-serialization-protobuf

Progress:

• Quorum selection
• Periodic snapshot generation
• Snapshot submission to blocks
• Subset of validator selection for verification
• Backtracing and finding nearest snapshot
• Querying the subset to retrieve states
• Attempt to restore
• Submit votes to the block producer via aggregation through clusters

Currently, there is no verification being done on nodes running containers. To account for byzantine behavior in public networks, verifying the state of containers to make sure they are running is crucial. Otherwise, malicious nodes may simply extract keys from containers and submit signed proofs without actually running the container.

The suggested protocol is as follows:

• Nodes running containers must periodically extract the state using CRIU, and submit the hash of the state to be saved in the block.
• Each k slots, a new subset of validators $V$ self-elects into the a new roles "quorum member". These nodes form a quorum $Q$.
• Each slot, the quorum uses the same RNG to select one or more nodes ${k_0, ... k_n } € K$ for verification such that $K \subset V$, $n \lt |Q|$ and $k \notin Q$
• For each $k_n$, Quorum members trace-back the chain to find the last state verification proof $k_p = hash( proof(k_n, block))$
• Quorum members query $k_n$ using the obtained proof $k_p$ to receive the actual CRIU state, which is verified again with $k_p$,
• Quorum members attempt to restore the container given the state.
• Quorum members submit their votes based on the success of restoration, the aggregated vote is included in the next block.
• Validators verify the votes.

To produce periodic proofs, nodes must continuously submit valid state proofs. The only reasonable way to produce valid CRIU states is for nodes to actually run the container, and store the submitted proofs locally pending verification.

There are a few parameters that need to be defined pending some simulations and testing such as:

• Determine the best quorum size, and frequency of election (likely not per slot).
• How many nodes should be verified per each Quorum.
• What is the retention rate enforced on nodes to store the CRIU state considering storage. This must reflect the Quorum proof selection algorithm.

DigestUtils is not needed because hashing can be done without external dependencies.

Let OS choose ports used for communications between nodes.

Allow for nodes to use preferred Kademlia port.

Implement Kademlia protocol:

• - Buckets
• - Lookup
• - Bootstrap
• - Replace old nodes
• - Ping old nodes upon arrival of new candidates

Many nodes are left without their cluster representatives.

An application with the capability to connect to nodes and observe the network state while also handling new information and eventually pushing applications into the network can serve various purposes and provide valuable functionalities in a distributed computing environment.

Implement CRIU for use of container migration.

Information: https://criu.org/Main_Page

Have a few options on how to apply configurations

• Command line arguments for simple overrides
• Pass file path of the configuration file
• Read current destination for configuration file

Remove incomplete packets from UDP server after a period of time.
Period in minutes is set in Configuration file.

• jungle-boogie testnet setup
• Github actions setup
  • Build
  • Test
  • Push to docker hub

Using a m-ary (k-ary) tree structure for broadcast messsges.

Implement proper difficulty adjustment for VDF computation.