Design
The design of the lightning network simulation is based on different modules but all of them following an Object-Oriented design. Each module is responsible to provide essential features during the simulation and the analysis of it. The main modules to be designed were:
- Analysis module. This included charts and graphs to represent the results of each simulation visually and therefore, reinforce the analysis comparison.
- Simulation module. This included different subsystems to be developed within this module such as the simulation creation, simulation loading and simulation result.
- Toolbar module. This included an elaborated list of settings to be applicable to the simulation, including information about the simulation, the program, start, stop or pause the simulation as well as creating or loading a lightning network.
The simulation tool required a GUI to be developed before creating/loading any simulation. Prior to this stage, mock-ups of each desktop application page were required to proceed with the design process of the lightning network simulator tool.
I used MarvelApp, a web application tool to generate sketches and mockups for my desktop application screens. This speeded up the development process focused on a pre-generated design for each screen.
The welcome screen should contain a welcome message with brief information about the project features, the problem exposed and the proposed solution.
I needed an intuitive General User Interface to represent complex interaction and network behaviours in the easiest way possible. Thus, the initial draft design for the simulation tool occupied the entire frame of the desktop application, attracting the entire attention to the simulation behaviour. The interaction from the user to the simulation was made by the toolbar, which is represented on the top of the frame, as a standard for desktop applications.
Creating a Lightning Network should be as intuitive as possible. Therefore, I focused on delivering a minimalist design with the minimum options to quickly create a network topology. The initial draft included a 5 input options, which were network size, number of channels, the range of channel capacities, range of channel fees and range of node balances. However, this could potentially become an issue for the average user without previous knowledge of The Lightning Network protocol. Thus, the next iteration design I reduced the input option from 5 to 2:
- Network size. The number of member nodes in the lightning network.
- Number of channels per node. The average number of channels for each member node in the lightning network.
As part of a minimalistic and intuitive design approach. I included the variations of the network topology such as the channel capacities, fees and the node balances within the analysis module once the lightning network topology is created or loaded on the simulator.
Loading a lightning network is quick since the lightning network simulator is a desktop application when the user clicks on loading a native file explorer should appear to click on the JSON file which contains a lightning network configuration.
The final design concluded with a relative small sidebar on the right side of the frame was minimal information about the network configuration settings were displayed to the user, such as network balance, transactions or congested channels.
Creating an efficient analysis of a lightning network simulation required a visual representation of the data obtained from the simulations results. Hence, I needed to implement a library to display charts and graphs when analysing each simulation.
When a lightning network is successfully loaded and ready to analyze, channel capacities and node balances can be modified to create a different test case scenario. There a visual element to differentiate between channel capacities and node balances should be implemented. My initial design included colours and sizes to represent these modifications.
Starting a lightning network simulation requires a visual representation of the network topology. By making use of the colours and channel sizes, I should be able to represent the lightning network intuitively. I decided to create a draft for the visual distinction of node balances. Initially, it should be three options to visually represent the channel capacities. The measures used are subject to change.
- Low: Random balance between 0 and 200. Nodes are highlighted with red colour to represent the low balance as a visual warning.
- Medium: Random balance between 200 and 600. Nodes are highlighted with orange colour to represent the medium balance as a visual warning.
- High: Random balance above 600. Nodes are highlighted with green colour to represent the high balance as a visual warning.
Following a similar approach, I decide to generate a different draft for the visual distinction of channel capacities. The measures used are subject to change. Initially, it should be seven options to visually represent the channel capacities. The measures used are subject to change.
- Low. Channels which capacities are between 0 and 40. It has a single size.
- Medium. Channels which capacities are between 40 and 70. These channels have 3 incremental sizes varying from each channel capacity in amounts of 10 to represent an extra width.
- High. Channels which capacities are above 70. These channels have 3 incremental sizes varying from each channel capacity in amounts of 10 to represent an extra width.
When the simulation has concluded by performing a standard stress test, nodes and channels should be visually represented following the design rules described above. When a channel is congested, becoming useless in the network should be visually removed from the simulation tool.
There are three main options of analysis:
- Analyze channels. When a lightning network simulation is performed after generating a transaction stress test what percentages of channels are congested and what are valid. This analysis is a valid constant to improve the routing mechanism when analyzing routing.
- Analyze nodes. Analyze the entire nodes map status, including balances, channels and transactions.
- Analyze routing. Analyze the routing mechanism to highlight the selected path to deliver a set of transactions.
The architectural design consists of a modular, object-oriented approach to enable a dynamic development process using agile tools while having a flexible integration for alternative solutions, such as different methods to optimize routing mechanisms or displaying network behaviours.
The simulation tool should cover the minimum viable features to display, simulate stress tests, provide routing mechanisms for one-hop and multi-hop transactions and create a network in the most frictionless way possible. Hence, a general user interface should be created based on the following design specifications:
- Creating and loading a lightning network. The creation of a lightning network must be done by writing a network map which contains the network model including nodes, channels and transactions. The loading process is reading such map network to create the required objects to display the simulation in the GUI. The network model should be in an object-oriented language such as JSON.
- Displaying a lightning network. The displaying process of the lightning network simulation must be achieved using an interactive graph able to meet the simulation criteria. Third party libraries to deliver this design specification such as MxGpraph, Swing and JGraphX are suitable to provide this criterion.
- Running a simulation. The simulation process of the lightning network simulation must be done by displaying the lightning network from the data inputs obtained from the network map to create a transaction stress test. This stress test consists of creating one-hop and multi-hop transactions until node balances reach zero or channel capacities reach the maximum consequently becoming congested. The GUI must be updated constantly when a transaction is sent to show interactivity within the simulation. On each GUI update, channel capacities and node balance labels should be updated as well as the visual representation of them should meet the design criteria. Alternatively, when a channel is congested due to a maximum capacity reach, it should disappear from the general user interface.
- Routing transaction in a lightning network. There are two types of routing mechanisms involved in the lightning network simulation to send and receive transactions:
Direct Transactions. Transactions which go from node A to node B through a channel created by node A pointing to node B which recipient amount is below the channel capacity.
Routed Transactions. Transactions which go from node A to node C through a channel or grouped channels created by node B pointing to node B which recipient amount is below the channel capacity. Forming a one-hop routed transaction in the following manner A-B-C. Since node B is routing a transaction from A to C through its channel, node B can add a fee for routing transactions.
The routing mechanism must be delivered to allow the generation of transactions seamlessly during the stress test simulation. Hence, the design specification should be as indicated in the visual pseudocode representation. All of the nodes should be stored in a data structure to, later on, check if there is a direct channel to the destination node in a random transaction. If there is a direct connection then, proceed with the transaction at no cost, however, if there is not a direct channel but there are open channels, check the other channels to find a route to the destination node iteratively. When a list of possible routes is obtained, then check the most optimum path by selecting the cheapest route over the shortest path, and here is where the analysis of the lightning network simulation starts.
The analysis tool should cover the minimum viable features to manage the simulation inputs and display outputs from the simulation in the most frictionless way possible. Hence, the use of interactive charts and graphs as well as tools to meet the analysis criteria.
- Managing simulation inputs. The inputs management process of the lightning network simulation must be delivered to instantly modify channel capacities and node balances. In order to offer a wide range of different network topology behaviours, the channel capacities and node balances should have 3 inputs each, low balances/capacities, medium balances/capacities and high balances/capacities.
- Exporting a lightning network. The exporting process of the lightning network simulations and results must be done by writing a network map which contains the network model including simulations results, nodes, channels and transactions. The network model should be in an object-oriented language such as JSON.
- Displaying simulation results. The results obtained from running a lightning network simulation must be displayed in the right sidebar within the main GUI, as described in the design criteria. The main result outputs from the simulation are:
Transactions. The number of transactions successfully sent in the simulated lightning network.
Failed transactions. The Number of failed transactions in the simulated network.
Hops. The number of hops successfully taken during the multi-hop stress test in the simulated lightning network.
Fees. The number of fees successfully raised for using channels during each hop.
Channels. The number of active channels in the simulated network.
Congested Channels. The number of congested channels in the simulated network.
Network Balance. The wealth of the entire simulated network.
Network Size. The number of nodes in the simulated network
The toolbar should contain options to manage and interact with the simulation at any time. At the top of the desktop application should be always accessible and visible.
The design specification to manipulate the simulation is divided into 4 tool types:
- File. In this section should be available options for loading, saving, exporting and creating lightning networks.
- Edit. In this section should be available options to manage the simulations such as starting the simulation and modifying the network topology to simulate different scenarios for analysis.
- Analyze. In this section should be available options to visually represent results obtained by the simulation tests. It should include charts and graphs so the simulation results can be easily interpreted and stored locally.
- Help. In this section should be available options for guidance, including a brief introduction to The Lightning Network, a contact point as well as an access point to the GitHub repository, where additional documentation and a wiki is available.
A UML Class Diagram was a helpful resource to develop the object-oriented development process.
NEEDS A TEXT DESCRIPTION OF THE RELATIONS IN THE UML CLASS DIAGRAM. THIS UML CLASS DIAGRAM IS TEMPORARY AS THE CODE IS SUBJECT TO A HEAVY REFACTORING PROCESS
NEEDS A TEXT DESCRIPTION OF THE RELATIONS IN THE UML CLASS DIAGRAM. THIS UML CLASS DIAGRAM IS TEMPORARY AS THE CODE IS SUBJECT TO A HEAVY REFACTORING PROCESS
NEEDS A TEXT DESCRIPTION OF THE RELATIONS IN THE UML CLASS DIAGRAM. THIS UML CLASS DIAGRAM IS TEMPORARY AS THE CODE IS SUBJECT TO A HEAVY REFACTORING PROCESS