Finally implement the "sticky" chain node #9
2 Participants
dimitar.p.ivanov
uwiger
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: QPQ-AG/hakuzaru#9
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "designated-hitter"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The first node in the list of chain nodes you configure is considered "sticky".
What this means is that posting transactions and requesting "next nonce" will always be directed to that node, but other queries will be submitted to the rest of the nodes in a round-robin fashion.
This solves the problem of high frequency TX posting being dangerous (you can get into a nonce nightmare that takes a generation or two to sort out) if you have more than one post TX coming from the same sender in quick succession posting to different backend nodes.
Nice! Nonce issues get pretty annoying, so this is super handy. I like that the user can decide whether the sticky node can help bear the dry run load by putting it in the list twice or just once.
Also
connect_slowlymade me laugh.I should do a little documentation update to this, now that I think about it. I don't know that the purpose is explained well in the project docs, and this is a fairly significant, if small in terms of code size, change.