The research for the four protocol roadmap phases “Security and Reliability”, “Network Economics”, “Network Consensus” and “Network Longevity” is now complete. Therefore, we published a blog post to summarize the significant changes which contribute to an improved Lisk protocol. As a compliment to our blog post, on Friday, May 15th, Jan Hackfeld (Head of Research) and Iker Alustiza (Research Scientist) hosted a live AMA (Ask Me Anything) on Lisk.chat about the completed research up to Blockchain Interoperability.
In this blog post we recap the full live AMA session and feature the questions asked by community members, as well as the answers of Jan and Iker.
Jan Hackfeld opens the AMA:
Hello everyone! I hope you had time to read the recently published blog post that summarizes the protocol changes from four phases of the roadmap. Further details are also given in our new Lisk protocol documentation released this week. @IkerLIsk and I are now happy to answer any questions related to our research.
korben3: How will you enforce accounts to have 0.05 LSK?
Jan: There can, of course, be old accounts, from before the hardfork, that will have less than 0.05 LSK. But afterwards, any transaction that results in the sender or recipient to have less than 0.05 LSK is invalid.
korben3: Are there any issues expected with this change? How are old accounts handled with less than 0.05 LSK?
Jan: We don't expect any issues. The only change is the transaction validation logic. There is no account validation that requires the balance to be actually at least 0.05 LSK.
forger_of_lisk: What is the purpose of accounts having to have a min balance of 0.05?
Jan: 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. The basic reasoning is that things that increase the state of the blockchain (accounts) should be more expensive than things that belong to the blockchain history (transactions). A full node can always prune the history without weakening the security guarantees.
ducktank: It would be interesting to know if the current "sidechain" research also implements an outlook how lsk-coin could gain value through interoperability.
Iker: We are considering right now three main ways through which LSK token will gain value in our sidechain/interoperability approach:
- It could be enforced that transaction fees have to be paid in LSK token everywhere in the ecosystem.
- It could be enforced that all the crosschain messages are required to be in LSK.
- To be a block producer/delegate in a sidechain you may need to “stake” LSK in mainchain.
These are not final ideas and we don't have them properly specified. For example, it may be that we want to give the sidechain developer the freedom to have their own internal fee system with the sidechain native token.
Captain_Slow: What is the dev team going to dev when 5.0.0 is done (incl. mainnet migration etc.) and research for interoperability has not yet been completed?
Iker: We are aiming to have the Mainnet migration approximately at the same time the interoperability research is done and specified. Also, as far as we know, the dev team has planned several tasks to improve the developer experience of the SDK, I am sure they won’t run out of work any time soon.
Jurre | Moosty: The accounts that have a 2nd passphrase how will these accounts transform in the version where the 2nd passphrase will not be a thing anymore?
Jan: 2nd passphrase will be a 2-out-of-2 multisig. So the account rules are exactly the same, 2 passphrases required for any transaction.
przemer: Is the ability to set a minimum fee by a delegate really necessary?
Jan: Of course delegates can have their own logic and not include transactions from the transaction pool into blocks if they think these pay too little. But then other delegates may include the transactions and receive the fees. The minimum fee defined in the dynamic fee system is part of the protocol and cannot be changed by delegates.
korben3: What would be a reason for a delegate to set a higher fee?
Jan: Delegates could say it is not worth the effort to include a transaction in a block if it only pays 1 beddow (on top of the minimum fee that is burned).
przemer: For example a coalition to increase fees for greater revenue
Jan: As long as there is enough space in blocks and some delegates are willing to include transactions with lower fees, such a strategy will not be successful. Note that also standby delegates will be forging.
Iker: Also, with the new voting system, coalitions are going to be much weaker and most of these strategies will not be profitable to be done as a group
korben3: In what way does it benefit the user (not the delegate)?
Jan: In general there are two ways how delegates/miners are incentivized for securing the network: - Block rewards: everyone pays because of the inflation (also Hodlers) - Transaction fees: only people using the blockchain pay. The minimum fee that is burned means that the people using the blockchain pay something from which everyone benefits (the total supply is reduced).
reem1x: From your technical / quant point of view, after the Longevity stage (so excluding interoperability), is Lisk ready to deliver on its core promise: side-chain based dapps in JS at scale?
Jan: After the interoperability phase is implemented, the basic infrastructure to create sidechain-based Dapps that are scalable is ready. Note that a successful Dapp is not only the blockchain protocol layer, but also requires a lot of UI development by the Dapp developer.
distort: Which industries is Lisk addressing? Are you in contact with any big enterprises to implement Lisk for their use cases? Do you consider the DPoS system to be trustful enough for enterprises (I personally wouldn't trust a couple of anonymous delegates to secure my blockchain operations if I had a large company)?
Iker: I think the first two questions are much better asked to our business development team or to Max himself. As far as I know, in the last months we have been doing exactly that, trying to define use cases and develop proof of concepts for Lisk by targeting a set of enterprises with innovation labs in Berlin and the region, but I don't know any specifics about it, sorry.
Jan: We are also currently exploring what consensus algorithms will be possible for sidechains (e.g., PoS, DPoS, PoA). It could be that an enterprise prefers to run a PoA sidechain instead. We also hope that the new DPoS system encourages delegates to be much more open and transparent because of the competition for voters and the possibility of punishment of delegates/voters (e.g., website with hardware setup, people/company behind the delegate).
korben3: Does the burning of the fee have a significant impact since 1 lsk per block is still forged forever. What part will be burned of the fee, the minimum required fee or other?
Iker: As Max said some days ago here, the impact is limited even assuming that all the blocks are full for a whole year. For the specific figures you can check the appendix section of LIP 0013 where we study exactly this point. You can see in the graph that the decrease in inflation will be around 15% in that "extreme" scenario. And what is burned is the minimum fee which is the required one by the protocol. The user is free to set any fee above that and the delegate will get that remaining part of the fee. So if a user wants her transaction to be included quickly, she should set a high fee to incentivize the delegate
korben3: How will violations of the Lisk-BFT consensus protocol be reported? In what way?
Jan: Regarding reporting violations of Lisk-BFT. There is a special Proof-of-Misbehavior Transaction that anyone can issue that includes 2 block headers as proof and then punishes the respective delegate. Probably there will be a plugin that anyone can run that would issue the transaction automatically in case of the misbehavior.
reem1x: I think it's quite unique to have the 'luxury' of a senior research team likes yours in Lisk. Not many projects have that. Especially not all PhDs. Just out of curiosity: Once the interoperability stage has been resolved, what will be your next focus?
Jan: There will still be a lot of exciting research for us to work on such as light clients, privacy-preserving transactions, interoperability with existing chains (e.g., BTC), smart contracts (as a sidechain plug-in), non-fungible assets, post-quantum cryptography, on-chain governance, etc.
Corbifex | Moosty: Will the protocol sort transactions automatically for the delegates most profitable first?
Iker: Yes! we have reimplemented the transaction pool completely to account for this new scenario together with the ordered nonces per account. To design the sorting algorithm, we assumed that the delegate naturally tries to maximize the fees collected from all transactions in their block while obeying to the 15 KB block size limit. This problem reduces to a well-known combinatorial optimization problem, the Knapsack problem (which is NP complete, so very complex to get an optimum output). We solve the problem efficiently using a standard greedy algorithm that yields a close-to-optimal solution while respecting the order of the nonces per account.
distort: How are you going to tackle the cartel problem?
Jan: We are changing the whole voting system in a way that should increase competition and disincentivize cartels, see the following blog post.
Lisk Magazine: In relation to the "special Proof-of-Misbehavior Transaction", will it be something mathematically proven or delegates will vote if punished or not? (this second case seems very dangerous, as delegates can cooperate to vote against someone)
Jan: There is no voting whether to punish. The PoM transaction contains an irrefutable proof of the misbehavior (2 block headers).
Jurre | Moosty: Would you also be setting/identifying/prescribing standards for custom transactions/tokenomic models for the lisk ecosystem?
Jan: We have looked into token economics and bonding curves, for instance, as part of the interoperability research. In the end it will likely be up to the sidechain developer to set the appropriate incentives, but we may give some guidance / suggestions / best practices.
Iker: Regarding your previous question, I would like to add also that writing your business logic with custom transactions is more powerful than doing it with smart contracts, but this also comes with drawbacks. The custom transaction developer must be aware of the scope and impact of their custom logic (for example, a custom transaction which requires to modify millions of values in the sidechain account state every time it is confirmed in a block does not look like a good practice). In the ecosystem context, the Lisk mainchain will be safe from these effects thanks to the interoperability protocol, but it will be up to the sidechain developer at the end to do this in their sidechain. Of course, we will provide good practices and standards, but the SDK developers will have this flexibility and freedom always.
Jurre | Moosty: What time span can we think of you need to complete the interoperability research?
Jan: As Iker mentioned our aim is to complete the interoperability research at a roughly similar time as the next mainnet release. But as we haven't decided yet on the exact solution, there is still quite a lot of uncertainty about the complexity and how much time it will take to properly specify all details and carefully review them.
Thanks to everyone in the community for their participation in the live AMA on Lisk.chat. Further information about the research presented in the blog post is available on the Research forum. We invite all community members to read the LIPs and engage in discussion over there.
Lisk has embarked on an exciting mission to enable developers to create decentralized, efficient, and transparent blockchain applications. Stay up to date and join us on: