Implement Flash Layer with multi-hop payments #1610
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It's useful for other routines.
It will be needed for non-agora nodes to be able to connect to agora nodes in the Flash layer tests.
This class is responsible for maintaining a single 2-party channel. There may be multiple channels open between two parties, but the Channel class only cares about a single channel instance. The channel's ID is derived from the funding transaction's UTXO hash. The channel becomes open once the funding transaction is externalized in the blockchain. The channel becomes closed once the closing transaction is externalized, or may alternatively become closed after the externalization of the trigger / update and settlement transactions.
This `UpdateSigner` class is responsible for safely signing & collecting settlement and update transaction pairs. The settlement multisig must be validated before the update transaction signature is revealed, otherwise the node risks having their funds locked in the channel if this was the first (trigger) transaction pair.
Some of these may be replaced in the future as HTLC support is added. Each API endpoint which is expected to return a value may also return an error code with a diagonstical message.
The `Scripts` module contains the ability to create lock scripts for trigger / update transactions, as well as key-derivation methods for signing & validating the update & settlement transactions.
These types are used in the API. They contain the `ChannelState`, the various update / settlement transaction types, the nonce types used for signing, balance types for various balance requests and updates, and a `Result` struct to have a consistent error-handling mechanism.
These are the various error codes which may be returned by a call to a Flash API endpoint. Some errors are recoverable, while others signal that something went wrong. The errors typically come with an extra diagnostical message.
The `ChannelConfig` contains all of the information necessary to open a new channel with a peer. It contains only public information, leaking this data cannot cause a loss of funds - although it may cause privacy issues.
The invoice is used to route HTLC payments across the network. The node shares the hash of a preimage to the party which intends to pay for the invoice. The destination node can redeem the payment if the reveal the secret to the counter-party of the channel through which the payment was routed. The secrets are then revealed in the reverse path of the payment, thereby updating all the balances and collecting fees.
These packets ensure that each hop node in the payment route only knows to decrypt their own information and may only route the payment to the next channel. Note: Currently the size of the onion is not static. This should be improved for privacy / censorship reasons (See LN RFC spec).
Currently there are no routing algorithms. Only the path definition is implemented.
This class takes care of most book-keeping. A separate control class will be defined which allows client code to explicitly create or pay for invoices.
This API can be used to control the flash node, for example creating new invoices or paying for existing ones.
Added a bunch of tests. Some of this code needs to be folded into base classes later.
Do we have any intentions to have thin Lightning Nodes as well, in the future? |
I suppose that's not a bad idea. There could be an abstract flash node class, with implementations in the |
Codecov Report
@@ Coverage Diff @@
## flash-layer #1610 +/- ##
================================================
- Coverage 78.71% 28.53% -50.19%
================================================
Files 120 92 -28
Lines 10608 6687 -3921
================================================
- Hits 8350 1908 -6442
- Misses 2258 4779 +2521
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
omerfirmak
approved these changes
Feb 8, 2021
|
Fastest review in the west. |
This was referenced Feb 9, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Revival of #1415 with additional features.
As discussed with @omerfirmak there's still some wrong assumptions made in the code. These will have to be fixed, either in this PR or in a fixup later.
Also there is an occasional test failure, there's some timing assumptions that fail sometimes.
I plan to move the stuff out of
test/Flash.dand into a separate class. My goal is for a FullNode / ValidatorNode to also be a FlashNode if they have any funding transactions on the blockchain for which they are a part of. In this way we get some free features like getting the latest gossiped block, transaction validation, etc.But I want to focus on the internals first before it's capable to run it in release mode.