Lisk Research – Quick Overview of LIPs 5 and 6
The series of articles on the Lisk Improvement Proposals continues with the exploration of LIP 5 and 6: the first concerns a new application architecture for Lisk Core while the second improves the processing of transactions.
The LIP 5 was drafted by Nazar Hussain, with the contribution of Oliver Beddows, Andreas Kendziorra and Jan Hackfeld. They suggest a new application architecture for Lisk Core, that has a more flexible and modular design. There are several strengths in the new system. To begin with, a looser coupling between modules takes place through functional insulation and there is an optional elastic scaling for modules over multiple cores/threads/machines. Furthermore, the new architecture makes easier the extensibility, using a plugin pattern and a supporting API, and is more resilient to individual module processing failure.
Nazar explained that the limitations of single-process architectures and tightly coupled code logic (as NodeJs applications like Lisk Core) can have different impacts on the system. For example, it is not possible to use all available hardware cores or easily modify any particular module without effects on the whole application. In addition, if a component has a problem, it may affect the functioning of others, or a heavy load on the HTTP API affecting the resources can influence the performance of block propagation and other components.
For the above reasons, a new flexible, easy to manage, scalable and resilient architecture for Lisk Core has been designed.
The LIP 6 has been proposed by Usman Khan, with the contribution of Oliver Beddows, Andreas Kendziorra and Jan Hackfeld. They propose to enhance the processing of transactions by optimizing the verification of transactions, applying transactions in memory and consolidating database queries. In addition, their proposal bring improvements for the management of transactions in the transaction pool.
Their motivation is that, as regards the current implementation, transactions are processed by performing application logic and database queries by turn. Moreover, the database, in relation to transactions which have not yet been included in the blockchain, keeps track of the accounts state that would result if all these transactions were applied. This accounts state is called unconfirmed state and it ensures that transactions do not conflict with each other.
As a result, this type of implementation is inefficient and does not scale for two main reasons. First of all, the execution of application logic and database queries alternately slows down transaction processing. In addition, the storage of unconfirmed states in the database is not necessary and its maintenance requires external database writes.
For these reasons, their proposal suggests to improve the performance trying to separate application logic from database logic, implementing parallel database queries with fewer round trips. In addition, the proposal introduces the calculation of unconfirmed states during transaction verification, avoiding unnecessary writes to the database.
For more detailed information, you can read the full description on the LIP page on GitHub.
———————————————-
Lisk Magazine is a project supported by Lisk Italian Group and EliteX.
Support our work, vote for Lisk Magazine.
