Lisk is joining the Optimism Superchain ecosystem in 2024! Learn more about our planned migration to Ethereum, and what it means for our community, here

AMA Recap: Betanet v4 Launch

All objectives of the Economics and Consensus phase have been successfully implemented into Lisk SDK 4.0.0 and therefore Lisk Core 3.0.0-beta.1 has been released. This comes with a multitude of new features on the protocol and various improvements on the code level.

The Betanet v4 will replace the current Betanet v3 which was running stable since February 2020. Therefore from now onwards betanet.lisk.io will run on Lisk Core 3.0.0-beta.1. We published a blog post showcasing the new protocol features of this release and further code improvements. As an addition to our blog post, on Friday, November 13th, Manu Nelamane Siddalingegowda and Shusetsu Toda (Lead Backend Developers) hosted a live AMA (Ask Me Anything) on Lisk.chat about the Betanet v4 launch.

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 Manu Nelamane Siddalingegowda and Shusetsu Toda.

By Lisk

16 Nov 2020

AMA recap Betanet v4 launchMAIN@2x_0.png

Mateusz Abramczyk opens the AMA:

Hello everyone! Manu Nelamane Siddalingegowda and Shusetsu Toda are here to answer your questions regarding the Launch of Betanet v4.

Manu: Hi everyone! Looking forward to your questions.

Shusetsu: Hi!

Korben3: What are the hash onions for?

Shusetsu: Hash onion is to generate the random seed. Each hash onion is included in a block header by delegates. Using block header for last 103 blocks, it creates 2 random seeds which are used for shuffling delegates list and picking standby delegates

korben3: _What does the forger info file contain and why is this needed if you switch forging nodes?_

Shusetsu: Forger info contains information about which block the delegate forged, which is used to create the next block. This is to ensure the BFT protocol and preventing double forging. whenever a forger creates a block, it saves the information regardless of if it was forked and reverted, and if a delegate fake this data, it can be punished by the protocol by report a misbehavior transaction. So it's very important to keep the forging info.

korben3: _When sending a transaction. Do you need to retrieve the nonce of the last tx from the sender's account and add 1 and what's the easiest way to do that? For instance when building a user interface._

Manu: When sending a transaction you need to make sure to include the updated nonce from your account. The increment will be taken care of, in case if you have the counter locally then you can increment. But it is recommended that you always get the latest nonce from the account and send it.

Krishna: _Hey! Sorry for interrupting the flow, posting my questions too. Could you tell us if any companies are using your services to develop applications on the blockchain? Next, do you plan to develop interoperability? Would it be with different blockchains or is it going to be sidechains?_

Manu: Hey Krishna,

1) We have many projects built on top of Lisk SDK, you can check out the blog to see the projects https://lisk.io/apps, we also have a section for enterprise https://lisk.io/enterprises .

2) Yes, at the moment we have completed the development of our roadmap up to interoperability, the research team is finalizing the interoperability solution. You can get more information about our interoperability solution on November 20th. Please subscribe to the event lisk.io/livestream

Korben3: _In what cases do some have "in case if you have the counter locally then you can increment"?_

Manu: If you are building an application to send transactions and if you have a counter stored locally then you increment without querying the blockchain for the updated state. Let’s say the initial nonce will be 0. After a successful first transaction (the account nonce will be 1), for the next transaction, you can increment it by 1 as it was 0 before (if you do not have the account state synced). But if you are using the synced account state information then you do not need to increment it as it will be up to date all the time. I hope it's clearer now.

Splatters: _The v4 is going to stay only on beta like the v3 or will move to test and main after it'll be fully tested on beta? How long do you think will last before moving the v5? And when the v4 will be available to be installed on delegates nodes?_

Shusetsu: SDK v4 will be only for the betanet. Testnet and mainnet Lisk-Core release will be Lisk-core v3 which uses Lisk-SDK v5. Current betanet v4 is already available for delegates to join the network, in fact, some delegates are running the node. Betanet v4 will be relatively short compared to the one before. We haven't fixed the date yet, but the v5 SDK development is already complete and we are currently working on documentation and some improvement at the same time. As soon as that's done, I think we will be publishing to the betanet.

Korben3: _Another question, last one, for custom transactions is it possible to choose between static and dynamic fees?_

Shusetsu: We didn’t support static fee explicitly. However, setting minFeePerBytes to 0 and manually validating the fee should work as a static fee.

Lemii: _Is there specific testing you guys would like to see done on betanet at the moment? How can delegates assist with this? Apart from the usual stress testing._

Manu: Lemii, thank you for asking. It’s an important question. We have conducted our own internal alpha testing and fixed all bugs. However, we want the community to try out all the Network Economics and Consensus Protocol features (dynamic fees, new voting system, etc.)

Korben3: _Isn't the register delegate fee sort of a static one?_

Shusetsu: The delegate fee is static, but the transaction fee can be greater than the static fee, therefore it's not the same static fee as we have in the mainnet.

Przemer: _If I wanted to set a second forging node do I have to include the same onion hash?_

Manu: Usually it's not recommended to double forge, you will get punished. But if you want to safely enable forging when another node not forging then yes, you can copy the forging config from node1

Shusetsu: Don't forget to migrate the forging info tho.

Manu: Use the back script and take forger info back and restore in the node2.

Przemer: _I found this in the documentation: “When you enable forging as a delegate on a new node, you need to use the same hash onion in the config as on the old node, to enable forging successfully” . _What if I lost the onion hash?

Manu: This was meant to communicate for migrating to a new node. Not double forging, I guess.

Shusetsu: Even if you lost it, you can create a new one and forge although you will lose the first block reward.

Korben3: _Is that the same when you can't make the forging info file, for instance, if the server is destroyed?_

Shusetsu: Yes, for hash onion. You just lost your first block reward. However, if your whole forging info is gone, it needs to be activated forging safely. In v4, we didn't include the feature, but in v5, enabling forging will be always checked for safety unless forced.

MateuszAbramczyk: Thanks for the interesting questions everyone, and thank you Shusetsu and Manu for your time. Have a good Friday!

Shusetsu: Have a good weekend everyone. Anyway, I'm always around so if you have questions or feedback, let me know!

Manu: Have a good Friday everyone, feel free to get in touch if you need any help regarding v4 Betanet or in general

Thanks to everyone in the community for their participation in the live AMA on Lisk.chat. Further information about the Launch of Betanet v4 can be found in the published blog post.

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: