-
-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Further improvements to consensus ordering #267
Conversation
rationale: in eltoo the graph can grow up to u48 transactions. Even though not of all would be published, some may, and all of them must be ordered appropriately
If we have two different state transitions of different mined into the same block, which (by mistake) have the same nonce, we still can order them using type. This allows usage of type id value as a way of setting strong ordering overriding nonce values (for instance token issues can be always ordered before spendings)
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #267 +/- ##
========================================
- Coverage 13.3% 13.2% -0.1%
========================================
Files 29 29
Lines 3867 3883 +16
========================================
Hits 513 513
- Misses 3354 3370 +16
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
tACK 1f6e982
This PR introduces two things:
nonce
value is extended fromu8
tou64
, basing on @zoedberg suggestion form RCP-240731A: Improvements to consensus ordering of state processing RFC#10 (comment), in order to support eltoo and similar future versions of lightning;nonce
. If we have two different state transitions of different mined into the same block, which (by mistake) have the same nonce, we still can order them using type. This allows usage of type id value as a way of setting strong ordering overriding nonce values (for instance token issues can be always ordered before spendings)