-
Notifications
You must be signed in to change notification settings - Fork 122
Description
// TODO: append recovery from rejected announces
In file ethexe/consensus/src/announces.rs
gear/ethexe/consensus/src/announces.rs
Line 192 in c72ab5d
| let mut count = 0; |
Problem
Presently, logic of accepting announce for inclusion in chain is very simple: if parent announce is included in chain, then we accept the inclusion. Or, if node finds out that some not included announce was committed on ethereum, then it would request unknown committed announces from other validators in order to build a chain synced with one committed on main chain. This algo satisfies the consensus correctness condition, because finalisation happens on the main chain (ethereum/hoodi/anvil), where validators guaranties that only one chain is finalised.
But some times this could damage possibility of other nodes to sync with ethexe (Vara.eth) network. For example when a new node is connected, it starts to build announces chain from some finalised on main chain announce (or genesis announce which is always finalised) and trying to catch up majority of validators. But this could be impossible, because each time node recieves announce with not included parent, it just rejects it and forget about existence. But if majority of validators know that chain and then commit it on ethereum (without the most fresh one announce because of commitment delay, transactions cannot be applied on ethereum immediately) so node would sync with main chain, but would reject next announce producer, because last time node rejected it.
For example here node would reject A5 announce because A4 was rejected
Majority chain:
A1 <- A2 <- A3 <- A4 <- A5
Node chain
A1 <- A2 <- A3 <- A4` <- A5`
Committed on main chain
A1 <- A2 <- A3
Here A4` and A5` - base announces
Possible solution
Pool of rejected announces. Each time node rejects announce by unknown parent (also can be wrong producer, block and other problems, we do not consider this cases here, and this announces should not be added to the pool) - it appends the announce to some in-memory pool, then if node finds out that unknown chain is committed on the main chain, it recover the chain using announces from this pool and accessing remainder from the network. If announce with not included parent is comming from producer, then this parent (and maybe parent's parent) could be found in this pool and extend the node local chain, so that new announce could be included.
The node chain and pool progress:
1) initial state
chain: A1 <- A2
pool: ()
2) rejects A4 because A3 is not known, saves A4 in the pool
chain: A1 <- A2
pool: (A4)
2) find out that A3 is committed, so request it from the network
chain A1 <- A2 <- A3
pool (A4)
3) receive A5, takes A4 from pool and build the chain
chain A1 <- A2 <- A3 <- A4 <- A5
pool ()