Add Ability to Run as Full Simulator #6
Closed
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
This commit adds a ChannelState struct which is used to track the policy and state of a channel in the *outgoing* direction. This will be used to check forwards against the node's advertised policy and track the movement of outgoing HTLCs through the channel. Note that we choose to implement this state *unidirectionally*, so a single channel will be represented by two ChannelState structs (one in each direction).
Add a single representation of a simulated lightning channel which uses our state representation to add and remove htlcs. For simplicity, each side of the channel is represented as a separate state, with the only interaction between the two through the changes to local balance that happen when we settle htlcs.
Add an implementation of the LightningNode trait that represents the underlying lightning node. This implementation is intentionally kept simple, depending on some SimNetwork trait to handle the mechanics of actually simulating the flow of payments through a simulated graph.
We want to be able to distinguish between expected and critical payment errors in our simulated payments. An expected error occurs due to a lightning-related failure (such as running out of liquidity), and a critical one happens because something has gone wrong with our simulator (for example, an assertion failure about balances). This commit adds an some utilities to ForwardingError to make this distinction and display errors properly.
Add an implementation of our SimNetwork trait that will do the heavy lifting of propagating htlcs through a simulated network.
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.
This PR is a WIP that adds the ability to run SimLN without any real lightning nodes, instead providing "simulated nodes" that copy the the routing policies and liquidity constraints of real nodes. The last commit hard-codes a graph to run this "full simulation" on as an example, whereas in reality we'd load from a json description of the desired topology/policies.
High Level Overview
Lightning implementations in SimLN are abstracted using the LightningNode trait. The steps that we follow to support a simulated implementation of this trait (SimNode) are as follows:
–from_graph option, which allows starting the simulator with a graph file (format tbd) that provides channel policies and topology (not included in this PR).SimGraphstruct to manage:SimGraphstruct to manage payment dispatch.Graph Abstraction
Management of payments through the simulated network is separated managed with the following layers:
IMGPLACEHOLDER0
These structs are primarily used to provide send/track payment APIs, receiving updates on the state of their payments from SimGraph.
Channel State Machine
Implementation of channel state is broken down into three layers:
IMGPLACEHOLDER1
Each channel state is responsible for handling tracking of liquidity and HTLC limits in one direction, and the simulated channel is responsible for enforcing sanity checks across the channel (eg, that we don’t exceed our capacity).
An example state machine update is provided in the table below:
tl;dr
IMGPLACEHOLDER2