Network Topology #43
Network Topology #43
Conversation
| 1. the replicas agree on the order of the events (validator addition and removal). | ||
| 2. the transition function is deterministic. | ||
|
|
||
| Regarding condition (1), it's possible that a replica misses an event and produces an inconsistent state. To mitigate this issue, we can delay an event processing by some time interval to increase the probability of receiving all events before that. This is already included in the implementation which set the events to be processed only after 8 eth1 blocks. |
There was a problem hiding this comment.
hmm I am adding a task on how on general a node should sync itself to the contract state... this is not related to the SIP
sips/network_topology.md
Outdated
|
|
||
| In our case, there are extra assumptions that must be met depending on the nature of the model. Namely, upon an event, we say that: | ||
| - a model has "map dependency" if it may change the assignment of other validators added previously. | ||
| - a model has "map isolation" if it does not change the assignment of other validators added previously. |
There was a problem hiding this comment.
maybe "map stability" is a bette name..
but I dunno... maybe your name is better
There was a problem hiding this comment.
Yes! Stability is a much better name. Thanks!
|
|
||
| For a model with "map dependency", since nodes use the state to communicate on the correct topic, it's fundamental that the events are processed at the same time. Due to the possibility of unstable network conditions, we can't ensure that this condition holds by the time that the assignment of a changed validator is used. A mitigation technique is to set the state to be updated on pre-defined periods and execute only events older than a certain threshold. For example, it could be set that the state updates in the last slot of an epoch (to be used for the following epoch) for all events received up to the 22nd epoch's slot. | ||
|
|
||
| If one does not want to rely on these assumptions and mitigation techniques, it's also possible to add a consensus protocol for the entire network to agree on the replicated state machine. |
There was a problem hiding this comment.
I think relying on eth's consensus is good enough
sips/network_topology.md
Outdated
| for topicIndex <= t.maxTopics { | ||
| t.topicMap[topicIndex] = make(map[phase0.ValidatorIndex]struct{}) | ||
| } |
There was a problem hiding this comment.
if it is in go you need to add topicIndex++
I hope in spec redesign we stop using go
| for topicIndex, topicValidators := range t.topicMap { | ||
| // compute cost | ||
| equalOperators := t.NumberOfIntersectingOperators(committee, t.operatorsInTopic[topicIndex]) // Compute intersection in O(n + m) time | ||
| cost := (len(committee)-equalOperators)*len(topicValidators) + (len(t.operatorsInTopic[topicIndex])-equalOperators)*numberOfValidators |
There was a problem hiding this comment.
what's the difference between the left side and the right side exactly?
There was a problem hiding this comment.
I believe you are referring to the equation, am I right?
So, the aggregation impact of joining operators
So, on the left side, we have [the number of existing validators in the topic] * [new operators].
On the right side, we have [the number of new validators] * [operators in the topic that will start listening to these validators]
| ```R | ||
| 1. procedure Add_Validator(Topics, Validator, committee) | ||
| 2. existsInTopic, topic <- Topics.Has(committee) | ||
| 3. if existsInTopic then | ||
| 4. Topics.AddValidator(topic, Validator) | ||
| 5. Topics.Split(topic) | ||
| 6. Topics.AggregationStep() | ||
| 7. else | ||
| 8. topic <- GenerateTopicID(committee) | ||
| 9. Topics.AddValidator(topic, Validator) | ||
| 10. Topics.AggregationStep() | ||
| ``` |
There was a problem hiding this comment.
Not saying it is bad to stop using go (to the contrary). I was thinking about stopping with go when we do the spec redesign.
However,
- Kinda weird that before in the same document you used go and now you are using R
- I was thinking about switching to python actually
- must we have the line numbers?
There was a problem hiding this comment.
hmm I am guessing you just copied from your simulator?
There was a problem hiding this comment.
1 - The R label is just for looking like pseudo-code
3 - Not mandatory but I like it in pseudo-codes for references.
Yes, it was taken from the simulator repo and I added some little adjustments.
| 3. if existsInTopic then | ||
| 4. Topics.AddValidator(topic, Validator) | ||
| 5. Topics.Split(topic) | ||
| 6. Topics.AggregationStep() |
There was a problem hiding this comment.
this is undefined in the SIP
There was a problem hiding this comment.
Adding the split operation definition.
sips/network_topology.md
Outdated
| 3. if existsInTopic then | ||
| 4. Topics.AddValidator(topic, Validator) | ||
| 5. else | ||
| 6. bestTopic <- Topics.FindTopicWithMinimumAggregationImpact(Validator, committee) |
There was a problem hiding this comment.
This is the same as GetTopicWithLeastImpact as defined by go code?
sips/network_topology.md
Outdated
| The first algorithm requires more processing time, produces a better solution in terms of non-committee messages, and forces the model to have "map dependency". | ||
|
|
||
| The second algorithm requires less processing time, produces a worse solution in terms of non-committee messages, and allows the model to have "map isolation". | ||
|
|
||
| We propose going with the second solution due to the "map isolation" feature. |
There was a problem hiding this comment.
Over time we may pay a price for "map isolation"?
There was a problem hiding this comment.
For sure. However, I believe that the addition/removal operations may be changed in a future fork if we want.
sips/network_topology.md
Outdated
| ## Drawbacks | ||
|
|
||
| - A bigger number of nodes in a topic increases the reliability of a node receiving a published message by propagation in the network. For example, two geographically distant nodes may have connection problems and intermediary nodes may help propagate a message. | ||
| - Usually, more nodes in a network (or topic) represent a stronger defense against attacks. However, the model indirectly reduces the number of operators in topics, which is understood to be a trade-off of this approach. |
There was a problem hiding this comment.
In some topics you mean
In some it increases them
Network topology SIP with the proposal of changing the network structure, namely how validators are assigned to topics, to reduce the number of non-committee messages an operator needs to handle.