-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
routing+channeldb: use a more minimal encoding for MC routes #8911
routing+channeldb: use a more minimal encoding for MC routes #8911
Conversation
Important Review skippedAuto reviews are limited to specific labels. 🏷️ Labels to auto review (1)
Please check the settings in the CodeRabbit UI or the You can disable this status message by setting the Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
Concept ACK, great idea to remove unused data and simplify the encoding! 🚀 I think in the end the choice of encoding (whether to use TLV or not) is not super important as eventually we should fully migrate to SQL. |
2268ccb
to
b37d014
Compare
b37d014
to
f30310c
Compare
1c44d76
to
43f787e
Compare
4f0c2eb
to
1c0bba2
Compare
1c0bba2
to
3cf0d5f
Compare
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.
Did a first pass. Looks good to me, nice work on the commit structure (as always 😉 ). Might need some updates after recently merged PRs, but other than that this is pretty close.
// first hop in the path. A route is only selected as valid if all the channels | ||
// have sufficient capacity to carry the initial payment amount after fees are | ||
// accounted for. | ||
type Route struct { |
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.
Oh, I think I just made this a bit more complicated by merging #9049, which added a new field to this struct, including new encoding/decoding logic that probably needs to be copied (lnwire/custom_records.go
). Although no existing records should ever have that data. But if this PR only goes in with 0.19, there could be such records from 0.18.4 to 0.19.
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.
This is the relevant commit btw: 4804cbf
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.
thanks for pointing this out 🙏
I think we should still be good here though if im not mistaken since the new records would never have been encoded in the mission control store right? since that uses SerialiseRoute directly which does not use the new fields.
but I'll add the new fields to the struct for completeness sake 👍
3cf0d5f
to
9d45dc9
Compare
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.
Thanks @guggero 🙏
Updated with the hasCustomRecords
suggestion & also added the new fields to Route
// first hop in the path. A route is only selected as valid if all the channels | ||
// have sufficient capacity to carry the initial payment amount after fees are | ||
// accounted for. | ||
type Route struct { |
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.
thanks for pointing this out 🙏
I think we should still be good here though if im not mistaken since the new records would never have been encoded in the mission control store right? since that uses SerialiseRoute directly which does not use the new fields.
but I'll add the new fields to the struct for completeness sake 👍
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.
LGTM and tACK (on a copy of my mainnet node's MC history) 🎉
9d45dc9
to
74b6af9
Compare
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.
shweeeeet - updated! thanks @guggero
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.
Nice work 🎉! I'm curious how much this saves us, I'll also run a test migration next.
If we would like to add more data again in the future, how would that look like? Would adding a tlv stream make sense for extensibility?
@ellemouton, remember to re-request review from reviewers when ready |
It will save us a lot especially once route blinding is more frequently used since currently, that would mean storing the encrypted data for a blinded route for each mission control entry
Yeah i had the same thought before & chatted to oli about this but we decided this is fine for now especially given the shift to SQL land. If we do need to add more fields here before we get to sql land, then we can just do a migration at the time to shift to TLV form. |
To prevent the need to copy the entire onion_error.go file for a new Mission Control migration, this commit just updates the existing lnwire21/onion_error.go file with the new CodeInvalidBlinding code. The lnwire21 should not really ever be updated but adding a new code should be fine as it does not affect old migrations since this is a new code.
We add the new custom records encoding/decoding logic to the "frozen" lnwire21 package. We can do this because nothing uses this logic yet. If the custom records logic changes, the changes should _not_ be added to the lnwire21 version.
74b6af9
to
5c8c5e0
Compare
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.
Thanks for the review @bitromortac 🙏
Ready for final round
The other thing I forgot to mention above re the question regarding "how much are we actually saving here": The main reason we are doing this PR is so that we dont need all the currently needed Route info in order to construct an MC entry - this is so that we can create MC entries on Route blinding receives as is done in #8991 |
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.
LGTM 🎉, I tested the migration as well
In preparation for the commit which will add the main logic for migration 32 (which will migrate the MC store to use a more minimal encoding), this commit just adds some of the code that the migration will need to the package.
Add a new mcRoute type that houses the data about a route that MC actually uses. Then add a migration (channeldb/migration32) that migrates the existing store from its current serialisation to the new, more minimal serialisation.
5c8c5e0
to
eb6c552
Compare
eb6c552
to
34303e7
Compare
Before this commit, Mission Control would serialise the entire route.Route for each mission control entry. However, MC only uses a fraction of the info in route.Route. Continuing to persist the entire encoding may become more constly once we start sending to more blinded routes because then this encoding will also include the encrypted cipher text sent to each hop on the blinded path.
So this commit migrates the MC store to only persist the data that the MC actually uses.