All Research up to Blockchain Interoperability Completed
We are proud to announce that LIP 0034 and LIP 0035 have been successfully merged. That means the research for the four protocol roadmap phases “Security and Reliability”, “Network Economics”, “Network Consensus” and “Network Longevity” is now complete marking a major milestone for the research on improving the Lisk protocol.
Overall 35 LIPs have been completed and merged into the lips GitHub repository since starting the LIP process in June 2018 and publishing the protocol roadmap in November 2018. All LIPs are based on significant research work and have undergone thorough internal peer-review and public review as part of the open discussions in the Lisk Research forum. This process ensures that any changes of the Lisk protocol occur in an open, transparent, and collaborative manner and require a solid technical foundation.
Summary of Completed Research
The protocol changes of the four protocol roadmap phases will all be part of the next major Lisk Core Mainnet release and are already successively included in our Lisk SDK releases. We therefore want to take the time to summarize these significant changes here. More detailed explanations will be provided as part of a new research blog post series which will be published during the upcoming months.
Security and Reliability
The most important protocol change in this phase is the introduction of a consensus algorithm that provides block finality, that is, a guarantee that a block is never reverted. This finality guarantee holds as long as not more than 33 of the 101 delegates are Byzantine, meaning they maliciously try to manipulate the network and consensus algorithm. If you are interested to learn more about the new consensus algorithm, check out our research blog post Introducing Byzantine Fault Tolerance Consensus for Lisk.
The second significant protocol change is an improved peer-to-peer layer using a robust peer selection algorithm and introducing a banning mechanism. Some of the new peer-to-peer features are covered in this talk from Lisk.js 2019. Apart from that, this phase includes some further protocol improvements such as simplifying the transaction schema and introducing a network identifier, which binds a transaction to one blockchain and therefore makes it impossible to replay it on a different chain. The implementation of all these changes is already completed, and they are part of the Lisk SDK 3.0 released in February 2020.
This phase focuses on introducing a dynamic fee system. The proposed fee system allows users to freely choose a suitable fee for their transaction as long as this fee is at least the minimum fee required for the transaction type and size. For all transaction types except delegate registrations, the required minimum fee will be significantly lower than the fixed fee in the current fee system.
For instance, for a balance transfer transaction this minimum fee will be as low as 0.00136 LSK (slightly more if the transaction uses the data field or is sent from a multisignature account for example), meaning that balance transfers become more than 70 times cheaper as long as there exists no great competition for space in blocks driving up the transaction fees. A part of the transaction fee will go to the delegate who forges the block including the transaction, whereas the other part of the transaction fee is burned (therefore reducing the total supply).
Along with introducing the dynamic fee system, we provide a fee estimation algorithm that offers users guidance for choosing an appropriate fee, depending on the network usage and urgency of the transaction. Accounts will also be required to maintain a minimum balance of 0.05 LSK to avoid spam attacks that abuse the greatly reduced transaction fees and create a large number of accounts with almost no balance.
Further changes connected to the fee system are introducing a byte-based block size limit that replaces the limit on the number of transactions. This change increases the number of balance transfers that can be included in a block to over 100 and the number of transactions that can be processed by Lisk Mainnet in one day to around 1,000,000.
Additionally, this phase adds an invalidation mechanism for transactions that can be used to replace a broadcasted transaction with one specifying a higher fee, without worrying that both transactions could be included in the blockchain. Finally, multi-signature accounts in Lisk will become a lot more flexible and easier to use.
This phase encompasses several improvements of the Delegated Proof-of-Stake system used in Lisk. Users now have to lock the tokens they want to use for voting, and a LSK token can only be used to vote for one delegate simultaneously. Additionally, the delegate weight computation now takes into account how many tokens delegates have locked in order to vote for themselves.
By requiring that the delegate weight must contain at least 10 % of self-votes, we ensure that delegates have a significant amount of tokens at stake which further increases the security of the network. Apart from the changes in the voting system, the security of the consensus protocol is further strengthened by adding the possibility to report violations of the Lisk-BFT consensus protocol, hence resulting in a punishment of the misbehaving delegate.
Furthermore, standby delegates will be incentivized to run Lisk nodes as they have the chance to participate in forging blocks. The round length is extended from 101 to 103 blocks and the 2 additional blocks slots are assigned to standby delegates using a random selection algorithm proportional to the delegate weight. Additionally, we ensure that the delegate ordering in a round is more fair by shuffling delegates uniformly.
If you want to learn more about the changes of the DPoS system in this phase, check out this research blog post or the video from Lisk.js 2019. Note that the changes up to this phase are all part of Lisk SDK 4.0.
While all other phases have been successfully implemented into the Lisk SDK, this phase is currently in active development. It includes a change of the ID system, a new address system and a few more technical improvements of the Lisk protocol. The most visible change for the end-users will be the new addresses, which will now, for example, look like this: lskoaknq582o6fw7sp82bm2hnj7pzp47mpmbmux2g.
This length increase implies several security improvements: Registering your public keys is not needed any more, the probability of address collisions for different public keys becomes negligibly small, and mistyping up to four characters can always be detected (mistyping more characters will still be detected with a very high probability). Similarly, we extend transaction and block IDs from 64 bits to 256 bits, hence greatly strengthening the pre-image resistance and immutability of the Lisk blockchain for a long time into the future.
Additionally, we introduce a universal serialization method compatible with Protocol Buffers that can greatly improve the efficiency for storing and transmitting blocks and transactions. It further simplifies the development with the Lisk SDK as this method can be easily used for custom transactions.
We also now use Merkle trees for transactions in blocks enabling short inclusion proofs. Finally, we define a new genesis block schema and process for performing a decentralized snapshot of a Lisk blockchain, which will be very helpful for migrating the Lisk Mainnet to the next major Lisk Core release.
New Lisk Protocol Documentation
If you want to learn more about how the Lisk protocol will look like after the completion of the four protocol roadmap phases, then have a look at our new Lisk protocol documentation. The purpose of this documentation is to give a complete high-level overview of the Lisk protocol for developers and advanced users. The documentation assumes some basic understanding of blockchain technology, however the overall objective is for it to be easily understandable and less technical than LIPs.
Since the beginning of the year the research team has already been focusing on tackling the last protocol roadmap phase “Blockchain Interoperability”. We have completed our first internal milestone of obtaining an extensive state-of-the-art overview by looking in detail into different research papers, projects, and ideas tackling the problem of blockchain interoperability. We have covered a wide range of solutions and techniques such as state channels and atomic swaps, stateless validation, sharding, cross-chain certification, different variants of the Plasma framework and different pegging mechanisms.
Our current milestone is to decide about the interoperability direction for Lisk. As part of this milestone we are exploring different possibilities and how these would need to be adapted to meet the requirements of Lisk. We will then carefully evaluate and compare the different potential interoperability solutions.
After deciding for one interoperability direction, the next milestone is that the research team will draft detailed technical specifications of the solution. As usual, these specifications will be carefully reviewed, first internally by researchers and developers, then publicly in the Lisk Research forum.
In the last milestone for the interoperability phase we will publish the complete set of LIPs for the interoperability solution. Due to the complexity of the topic and importance of thorough research and evaluation, you will not see many updates in our research forum or new LIPs for some time. However, we will share our research and specifications in the Lisk Research forum as soon as they are ready for review and then look forward to your feedback.
AMA on Lisk.chat
We will host a live AMA on Lisk.chat on Friday, May 15th at 4pm CEST. Jan Hackfeld (Head of Research) and Iker Alustiza (Research Scientist) will answer your questions about the completed research up to Blockchain Interoperability. Further information about the research presented here is available on the Research forum. We invite all community members to read the LIPs and engage in discussion.