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.
A toolbar at the top of the desktop application should be always accessible and visible. Within this toolbar should be 4 main sections to interact with the Lightning Simulation Tool.
- 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.
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 decide 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 analysing 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.
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