Background & Objectives
Bitcoin is an open-sourced peer-to-peer electronic cash system. The maximum transaction capacity is seven transactions per second on its best-case scenario. This is a relatively low number in comparison with the current transaction processing from commercial standards such as visa, performing 24 000 transactions per second.
The lightning network protocol emerges as a solution to overcome this problem. The protocol is a second layer protocol to leverage the power of blockchains currencies like Bitcoin. The architecture of the protocol is composed of bidirectional payment channels to allow the creation of microtransactions within the bitcoin network while being off-chain.
This project is a simulation of the lightning network to showcase the current challenges on the routing mechanisms and address solutions to improve it. As part of the research involved, a qualitative and behavioural analysis of the network topology is performed by simulating different scenarios of the lightning network. Lightning Network Simulation is a desktop application. This simulation tool enables me to run simulations of the Lightning Network Protocol or any payment channel network with a similar architecture.
The simulation tool takes assumptions over the network status and the underlying protocol to allow the creation of lightning network simulations fast, easy and frictionless. Here there are some assumptions:
- The underlying protocol exists, and therefore, the protocol stack layer is implemented.
- The lightning network simulation tool assumes all the nodes in the network are synced. Thus, When creating a lightning network, there is no need to wait for the nodes to sync or create channels.
- Create a minimum simulation tool able to create, load and save mesh networks.
- Create an event-based simulation tool able to view, analyse and compare mesh networks.
- Create the Lightning Network on top of the simulation tool.
- Simulate the lightning network topology behaviour under different network scenarios.
- Analyse, compare and propose a solution(s) to improve the current routing mechanism.
My interest in networks started in 2015 when I first read about Bitcoin. Since then, I have always been researching in my free time whenever I had a chance. During the beginning of summer 2018, I found a solution to the famous Bitcoin scalability problem, called lightning network. I read the Lightning Network paper from Joseph Poon and Thaddeus Dryja and jumped into practice.
I created a lightning progressive web application focused on micro-transaction for games. While doing this personal project, I was self-learning skills in web development and distributed off-chain networks. Nowadays, what started as a personal project to implement an application lightning network protocol became a for-profit venture and a gaming reference in the Bitcoin industry.
My passion and enthusiasm about the lightning network protocol brought me to contribute to the lightning development and adoption by contributing to proposed solutions such as LNURL-RFC, a bech32-encoded HTTPS query string to leverage the power of lightning network clients.
On the 27th of March of 2019, I had the opportunity to give a talk about the lightning network protocol in Startupole. During this talk, I had the pleasure to show and introduce my lightning network simulator. The audience was pleasured with the helpful utility of the project to understand how the lightning network works. A more technical public liked the fact to create simulate lightning networks with different behaviours and properties in a matter of seconds as well as having the opportunity to add theoretical proposed routing mechanisms on top of the simulator to analyze, compare and research.
Bitcoin is a peer-to-peer decentralised cash system. With no central point of control/failure, it uses a proof of work consensus mechanism to avoid the double spent issue and the Byzantine general problem. Transactions are stored in the bitcoin network in the format of blocks. To be confirmed, a block is completed when it reaches 10mb. When a block is completed is sealed with a timestamp from its parent block and a new block is generated, creating a blockchain. The maximum transaction processing capacity is seven transactions per second.
The block size limit resulted in a bottleneck effect, creating an increased transaction fee and delayed processing of transactions. The lightning network protocol emerges as a proposal to overcome these technological barriers.
The Lighting Network protocol drastically improves the performance of distributed ledger technologies for censorship-resistant payment systems like Bitcoin by conducting each transaction through payment links in the network off-chain, while such payment links remain on-chain. A standard on-chain Bitcoin transference is transmitted, verified and stored by all the node members of the network.
Lightning Network architecture is based on bidirectional payment links which connect the member nodes of the network. This connection allows to send and receive transaction off-chain, without the need to transmit, verify and store the transaction on-chain. These payment links are commonly known as channels and leverage the power of blockchains to enable unlimited cheap, fast transactions.
In a lightning network, channels are similar to digital tubes where payments can be processed. These transactable links between nodes in a lightning network have a capacity, which stands for the maximum transactable unit that can be transferred through a channel. Therefore, a transaction with a recipient higher than the channel capacity would fail. Unlike other digital and distributed payment systems, lightning requires an inbound capacity to receive funds. Inbound capacity is acquired when other nodes (preferably well connected to the network) open channels to your node. The inbound capacity is the result of the sum of all the channel capacities which are open to your node.
The development process model used to develop the Lightning Network Simulation was FDD (Feature-Driven development) in conjunction with Kanban.
Initially, I created an overall model containing notes about each feature of the lightning network simulator. The model that concluded as a feature list divided into sets and subject areas. Then, for each different feature, I created a kanban board with subtasks to identify easier possible solutions and improve the continuous development of each subject. The main subject areas were:
- Simulation tool
- Lightning Network
- Analysis and comparison
- Routing
The simulation tool subject was composed of UI components to enhance intuitive user experience. The Lightning network subject had the minimum requirements to simulation a realistic behaviour of the protocol using the simulation tool. Analysis and comparison of the Lightning Network Simulation had UI elements to display charts, graphs and statistics about the behaviour and topology of the simulation. The routing subject included a minimum replication of the current model to route transaction using a similar implementation of the Gateway Border Algorithm and a proposal routing solution(s) to overcome the friction with the current model.
I used GitHub Projects for the creation of Kanban project that met my development process needs for agile development and bug testing. Consequently, I created two projects within the repository:
I used this kanban to create, update and delete task boards. Within each task board, I could break down the task into a detailed description, subtasks and requirements to target more efficiently the development process as units. My kanban columns were divided into three sections to keep a basic structure:
- To Do. Tasks or issues that are pending to be done.
- In Progress. Tasks or issues that are currently in development.
- Done. Tasks or issue that has been completed and there is tested evidence of the solution submitted.
Alternatively, I added labels for each task according to the nature of the task. This allowed maximizing the visualization and management of the process development by filtering the tasks and finding the problem easier to target a possible solution. Some labels used in the kanban board were:
- Enhancement. New feature or request.
- Performance. Improve the current feature.
- Good first issue. Good for newcomers.
- Simulation. Feature or request from the simulation tool.
- Analysis. Feature or request from the analysis tool.
- Design. Task from the design specifications.
- Documentation. Task from the analysis tool.
- Testing. Task from the testing specifications.
Possible draft solutions were submitted by myself in the format of a pull request. Once a pull request was submitted and reviewed by me, in some cases, I could improve the solution by updating the pull request.
Following this approach, I could unlock the potential of my git client within the project. As part of the Feature-Driven development, I had the base branch for the ultimate version of the lightning network simulator and on the other hand branches for each different feature subjected as commented before. This procedure brought a feature singularity in the development process to focus on each branch as a unit, and then, create a pull request once the feature was completed.
In GitHub Projects, I added six sprints for the agile development process. These six iterations were following an exponential strategic. The first sprints were relatively long in comparison with the latest ones, and after an iteration was complete, the next iteration was shorter. This approach grants me enough time, in the beginning, to focus on task completion and implement potential solution while focusing by the end on polishing details and perfecting the tool.
-
Sprint 0. This sprint was based on theoretical and practical tasks. The theoretical side was based on research and problem analysis to find an efficient solution for the addressed problem. The practical side was focused on build the design specifications including graphics resources, set up the required tools such as the git client or design screen sketches meeting the design criteria. The length from this sprint was from 03/01/2019 to 10/02/2019.
-
Sprint 1. This sprint was based on implementing the main feature subjects from the simulation tool. This included creating, loading, exporting and displaying a network with the minimum viable design requirements to allow a functional service. It also included building the toolbar to have an interaction endpoint for the user. The length from this sprint was from 10/02/2019 to 03/03/2019.
-
Sprint 2. This sprint was based on implementing the main feature subjects from the analysis tool. This included managing the simulation inputs once loaded, implementing the simulated transaction stress tests to simulate the network and a routing mechanism draft to simulate direct and routed transactions. The length from this sprint was from 03/03/2019 to 07/04/2019.
-
Sprint 3. This sprint was based on creating the documentation report. This iteration required to set up a wiki on the GitHub repository and extract information about each chapter from the required criteria. The length from this sprint was from 07/04/2019 to 21/04/2019.
-
Sprint 4. This sprint was based on testing the lightning simulator, the fitness function and the GUI. This iteration required to run the bug triage and debug all the corrupted code to pass the tests. This The length from this sprint was from 21/04/2019 to 30/04/2019.
-
Sprint 5. This final sprint was based on the completion of the documentation report and details to perfect the project. This last iteration required to do tasks from design, to implementation if needed. The length from this sprint was from 30/04/2019 to 03/05/2019.
A Defect triage kanban was created to prioritize and triage bugs during the fifth and sixth sprints. This helped me to filter bugs and issues based on severity, risk or frequency. The columns created for this project were:
- Needs Triage. Issue or bug that requires emphasis.
- High Priority. Issue or bug to do with a high priority to be resolved.
- Low Priority. Issue or bug to do with a low priority to be resolved.
- Closed. Issue or bug resolved.
Additionally, I added labels for each issue according to the nature of the bug. This allowed maximizing the visualization and management of the process development by filtering the issues and finding problems easier to target a possible solution. Some labels used in the bug triage kanban board were:
- Caution. Severe bug or issue.
- Frequent. Issue or bug with frequency.
- Simulation. Bug or issue from the simulation tool.
- Analysis. Bug or issue from the analysis tool.
I used third-party applications to improve the code coverage tests, automate finding & fixing vulnerabilities in the used dependencies, optimize images sizes without affecting the quality and to automate identifying new issues in an early stage and prevent Lightning Network Simulator to be affected.
Using Codacy I had automatic code status checks on every pull request to improve my code quality standards.
Codacy comes with a dashboard to keep track of the code quality status, issue resolution, code coverage tests among other essential features to deliver professional software.
