Research up to Blockchain Interoperability Completed!

We are happy to announce that all research up to blockchain interoperability has been completed.  

Hey there, we have exciting news for you. 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 Thee 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 complete and they are part of the Lisk SDK 3.0 released in February 2020. Network Economics 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. Network Consensus 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. Network Longevity 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. 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.  Read more about the New Lisk Protocol Documentation and our Blockchain Interoperability Research in our blog post.   Stay updated with Lisk:   Newsletter Settings Want to change how you receive these emails? You can update your preferences or unsubscribe from this list. Lisk Foundation ・ Dammstr. 16 ・ 6300 Zug・ Switzerland

This email was sent to contacto1745.send-mail@blogger.com why did I get this?    unsubscribe from this list    update subscription preferences Lisk Stiftung · Dammstrasse 16 · Zug 6300 · Switzerland