Try to fast confirm past nodes too #2520
Conversation
cla-bot
bot
added
the
s
| @@ -683,6 +683,43 @@ func (s *Staker) Act(ctx context.Context) (*types.Transaction, error) { | |||
| StakeExists: rawInfo != nil, | |||
| } | |||
|
|
|||
| if s.config.EnableFastConfirmation { | |||
There was a problem hiding this comment.
as we discussed, we also need a solution for the WatchTower that missed confirming an assertion, or who'se confirm transaction was sent but was later lost
There was a problem hiding this comment.
Updated to account for this
| @@ -326,6 +333,9 @@ func NewStaker( | |||
| return nil, err | |||
| } | |||
| } | |||
| inactiveValidatedNodes := btree.NewG(2, func(a, b validatedNode) bool { | |||
| return a.number < b.number || (a.number == b.number && a.hash.Cmp(b.hash) < 0) | |||
There was a problem hiding this comment.
do we want to compare block hashes?
Since you're using ReplaceOrInsert - it makes sense to me to only keep the last inserted (number,hash) pair that fits a node number
There was a problem hiding this comment.
Part of my concern here was when I used Get, it could return a validated node with a different hash than requested. I explicitly check for that too, but I thought it'd be safer if they were seen as different. That said, I think you're right that the most recently validated node will always be the canonical one, so we could change it.
Fixes NIT-2699
In #2434 we added support for fast confirming nodes as we create them, but if a node is restarted at the wrong time, it's possible we'll miss a fast confirmation opportunity. Since the rollup contract only supports fast confirming the first unresolved node, this PR attempts to fast confirm the first unresolved node if possible before doing work on future nodes.
This also pulls in OffchainLabs/nitro-contracts#215 because there would be merge conflicts doing it separately.