consensys / wittgenstein Goto Github PK

EIP for ENR itself it here: https://eips.ethereum.org/EIPS/eip-778

One of the proposal to communicate the ENDR, likely the simplest one actually, is that each node gossip periodically its ENR. There are at least three things to take care about:

1. we don't want to overload the network -> we need to know how much data we send depending on the period time
2. we don't want a new node to wait for ages before having access to the information it needs, not getting state data, even if the capabilities is rare.
3. nodes will need to connect to peers with the capabilities they need. But this could lead to partition the network by capability which may be a bad idea.

The basic protocol would be:

• we rely on a p2p flood protocol
• a node has a set of capabilities (a set of string for readiness), some of them rarer than other. The distribution is a parameter; Pareto & gaussian are likely interesting.
• for some (proportion being a parameter) nodes, these capabilities change regularly (representing a validator moving from one shard to another). The time between changes is a parameter of the protocol.
• a node gossips its capabilities
  • when it joins the network
  • when it leaves it (sometimes it dies w/o this step, proportion another parameter)
  • when the capabilities change
  • every X seconds (another parameters)
• nodes discard the information after a given amount of time if it didn't get an update (another parameter of the protocol).
• new nodes enter regularly and look for given capabilities then leave the network after a given amount of time. Another parameter, may be we need it to be a random variable on a gaussian rather than an integer.

We will measure, for around 20K nodes:

• the time it takes for a new node to get the capabilities it needs.

cc @carver

The real world latency measurement used in NetworkLatencyByCity are for rtt (round trip time), our model require one way latency time.
fix: divide latency time by 2

Add to gradle a measure of the test coverage
Increase the test coverage

That means:

• adding the WParameter for all of them
• checking that the json they generate is reasonable

The paper is here: https://fc18.ifca.ai/preproceedings/75.pdf

It didn't measure variance.

Add documentation that explain how to create new graphs, change parameters etc..

Hi,

I am planning on writing a Dandelion++ Simulation on top of a gossipsub network in order to test some ideas outlined in this issue.

As it currently stands, I would have to build 2-3 protocols, one for a gossipsub network, one for Dandelion++ and another for sharding.

As a potential future feature of this simulation library, would it make sense to have some default network protocols that simulators can choose from?

Today, they are implemented, but outside of the framework. Their implementation should be integrated in the framework.

We should be able to support dead nodes in the framework, including the fact that it's sometimes possible to detect dead nodes

Build a protocol that simulates pow algorithms, uses difficulty calculations and includes uncles:

For Uncle creation
Before adding as uncle:

• Validate that block received has the same parent as existing block at same height
• Check block by height in blockchain and add as uncle if same parent and hasn’t been included and there are less than 2 uncles at that height
• Prevent uncles past height+6 to be added

Refactoring

• Remove uncle reference from the node

Mining

• Adjust difficulty calculation to include uncles
• Validate calculations using real data from main net in a test
• Create reward functions that allocates funds for successfully mining: 1) block + transaction fees 2) an uncle

** Data collection**

• Generate stats for uncles and record them in a separate file (csv)
• Select minimal parameters necessary to feed to RL agent
• Set method that calls agent at decision points

Generate data and store it outside with minimum parameters necessary

Of course, all the graph should be generated

Node#start was just added, and it called at the first run.

Our current graphs don't allow us to appreciate what happens in the first rounds of the protocol. Having a log scale graph (i.e. plotting log_2(number of signatures aggregated) over time) would allow us to see what happens in the early stages of the protocol execution.

We might thus be able to see how vulnerable the initial phases of the protocol are wrt to byzantine actors etc...

It should be possible to have two types of nodes:

• actual signers
• peers that relay others' signatures but don't sign themselves.

In real life, there are multiple reasons for such deployments, including:

• some signers may want to be difficult to identify as actual signers
• some nodes may want to participate as simple observers
• nodes participating may change often making more interesting to keep the same peers even if the actual signers changed

We can use real latency measurements for latencies instead of the linear regression model.

For example, define multiple type of nodes and then proportion of each of them. This should be managed by the framework

For example, run a scenario with a partition at a given moment and try it on different blockchain.

It's obviously complicated to implement.

See libp2p doc here: https://github.com/libp2p/specs/tree/master/pubsub/gossipsub
The basic protocol is quite simple:
"With flooding, routing is almost trivial: for each incoming message, forward to all known peers in the topic. There is a bit of logic, as the router maintains a timed cache of previous messages, so that seen messages are not further forwarded. It also never forwards a message back to the source or the peer that forwarded the message."

The Network class should have an overloaded method send which takes an unique destination as argument instead of taking only a collection. That would relieve us to use the Collections.singleton() trick.

This will be possible by allowing external process to send/receive message through http/json

This will be slow however. But an interesting scenario will the one byzantine node (implemented externally) with all other nodes implemented in java. With just a few external nodes it should be fast enough

We have min/max/avg today.

Today it's independant

This will allow to have better results: today we run it once and we just hope it's representative

There is a link with a scenario requirement, but it's a design decision.

We will be allowed to use the position from the known ethereum projects (https://www.ethernodes.org/network/1)

We will use the project hanon for this.

Today all the nodes are connected at the beginning, we don't manage any disconnection/reconnection in the framework. We need it for the ENR

It's now possible to launch protocols using rest services. We need an UI on top of this