Kaizen - A perpetual, incentivized, every-improving testnet

Community Updates
1

pl-999631829520
pl-9996318295201920×1074 42.4 KB

Kaizen, coming from the Japanese phrase “continuous improvement” has officially been launched in parallel to the Tezos blockchain. This testnet has no governance, and will have a baker-synchronized upgrade approximately 7 days before mainnet during every upgrade cycle. This testnet aims to fix many key issues plagueing both devs and bakers alike. In this post, I aim to outline the problems and how Kaizen testnet will solve those problems. We also encourage anyone interested in baking(becoming a validator node) on Tezos to contact me or one of the other members to get started.

Currently, the Tezos testnet has been a whirlwind of confusion, at least it has been for me. We have a testnet for the new protocol, we have a testnet for the current protocol, and we have testnet for older protocols. The main issues with the current testnet include:

  1. Developers need to re-deploy their smartcontracts every time Tezos upgrades, costing them approximately 2-5% of their time every year JUST redeploying contracts.

  2. There are 3 testnets right now, Granada, Hangzhou, Iadabalzu, and we have to keep the old protocol name if we want to keep the smart contracts, and there is no real community effort to upgrade the testnet along with mainnnet in order to keep the old data. We would like the testnet to keep the same name from now on to prevent any more confusion.

  3. There are no incentives for users to use testnet, meaning it is difficult for devs to have their smart contracts properly tested before deploying to mainnet.

  4. There is no incentive to bake on testnet. Bakers can run nodes on testnet, but it doesn’t really reflect mainnets’ issues, so it doesn’t necessarily become practice for the real world. There is very little traffic and it is hard to stress test nodes properly without real traffic.

Polkadot, for example, has a testnet called “Kusama”. "Kusama is a place for devs to test their contracts and such before launching a similar project on mainnet(Check out Moonbeam/GLMR and Moonriver/MOVR for example). Tezos is known as a salvager and innovation chain, yet we are stuck with a rather useless testnet, even when this great testnet model is standing right in front of us.

With Kaizen testnet, we aim to keep Tezos at the edge of innovation by freeing up devs time, and putting power of the testnet in the hands of the bakers and dapp owners. We shouldn’t have to rely on Nomadic to provide these things for us(even though they have done that graciously in the past). Its time for us to be pro-active and work together to make the Tezos the blockchain more user friendly and help Nomadic/Marigold make mainnet run as smooth as butter by allowing dapps to have a proper testnet to test on. With Kaizen we aim to fix these issues by:

  1. Upgrading earlier than mainnet to give dapps more time to test the features of the upgrade and get user-feedback to fix small bugs to enhance the user experience.

  2. Make it so smart contract devs never have to re-deploy their contracts on another testnet(except for maybe the beta ones, such as Idiazabal network, or tenderbake now).

  3. Onboard fresh bakers and users by lowering the barrier to entry for baking. We will have a multisig wallet to deal out fresh Kaizen tez to new bakers with the hopes of eventually building a bridge to mainnet that will allow anyone to get Kaizen Tez really cheap in the future. This will allow for hobbyists to start baking for $100 bucks or so, if dapps want to run a cheaper version of their product or game, they can do so on Kaizen(we are literally thinking, .0001 Tez per Kaizen Tez, but this is all up in the air still).

  4. Keeping governance on mainnet will keep our founding focus of “never hard forking”.

With Kaizen testnet, we have several idea’s that will be implemented, some of which we have already implemented and some of which we would like the communities input and feedback:

  1. Deploy Kaizen testnet by upgrading Granada-net and redeploying bakers on Kaizen-net(done, with 8 bakers registered now).

  2. Build a communication channel between Nomadic and the bakers to make sure upgrades happen on-schedule with Kaizen-testnet(done, but will be improved).

  3. Build out our team of bakers, and start on-boarding new bakers, people interested in baking but need proper guidance and help getting started. Kaizen net will have almost no barrier to entry, just filling out a form and joining our forumns. I will make youtube video’s and tutorials on how to join(started).

  4. Build out a set schedule for Kaizen-net upgrades so that dapps can test all of their functionality properly before mainnet upgrades(mostly done).

  5. Have an application process to give out Kaizen Tez through a multisig contract. This is done to:

    a. get a proper list of bakers on testnet for communication purposes.
b. point the new baker to the proper communication channels and tutorials to make sure they have a smooth experience baking on Kaizen.
c. Kaizen Tez will be free during this application process period, we just don't want people spamming the faucet.  This is to improve decentralization.

  6. Build a bridge to take out the manual labor of giving out Kaizen tokens through an application process. Set up a liquidity pool on quipu at an extremely low price to keep the barrier to entry for baking on testnet extremely minimal($100-$500 to set up a baker). We feel even a low price will bring a LOT of interest from hobbyists and newer crypto enthusiasts WHO CANNOT AFFORD ETHEREUM FEE’s(we feel this should be our target audience)(registered baker target before liquidity pool is undecided, still in discussion).

  7. Make a dedicated website with Kaizen-net information, tutorials, etc(pending).

Thank you all for reading, I hope this resonates with some of you. If you feel like their are area’s in need of improvement, please let us know. I will go ahead and make a youtube video to compliment this post if you want to check it out, I’ll add the link later.

If you have any questions feel free to join our slack channel:

2

Kaizen, […] has officially been launched.

What does it mean to officially launch a test network?

Currently, the Tezos testnet has been a whirlwind of confusion, at least it has been for me. We have a testnet for the new protocol, we have a testnet for the current protocol, and we have testnet for older protocols.

I don’t see what’s confusing about having a testnet for each version of the protocol, especially when the name of each testnet tells you which version it runs. What I find very confusing however is the current status of test networks. Now that Granadanet has been renamed into Kaizen and migrated to Hangzhou, we have two testnets running the same version of the protocol and many places still referring to Kaizen as Granadanet.

Developers need to re-deploy their smartcontracts every time Tezos upgrades, costing them approximately 2-5% of their time every year JUST redeploying contracts.

Note that they don’t need to synchronize redeployment with mainnet upgrades because the network running the proposed successor of the protocol is launched months before the upgrade.

putting power of the testnet in the hands of the bakers and dapp owners

Who are you calling dapp owners? The devs or the users?

We shouldn’t have to rely on Nomadic to provide these things for us.

Nomadic is still involved in testnets, for example to add the default configuration in Octez and simply to participate in the network, but most of the actual work of launching test networks is done by Midl Dev (especially @nicolasochem).

Upgrading earlier than mainnet to give dapps more time to test the features of the upgrade and get user-feedback to fix small bugs to enhance the user experience.

Sorry but that does not make sense. The test network for a new version of the protocol is launched as soon as the code for that version is ready to be injected and we even launch test networks with experimental versions of the protocol to give dapp devs even more time to test features. On a regularly updated test network however, you need to wait for the mainnet vote procedure to enter the last period before updating the test network because you cannot be certain that the proposal will be adopted before that.

I am afraid that Kaizen will disincentivize users to test proposed protocols.

Onboard fresh bakers and users by lowering the barrier to entry for baking. We will have a multisig wallet to deal out fresh Kaizen tez to new bakers with the hopes of eventually building a bridge to mainnet that will allow anyone to get Kaizen Tez really cheap in the future.

What is the barrier to entry for baking on testnets that you are lowering here? IIUC mainnet tokens are currently free and the faucet is publicly available and you want them to become cheap and handled by a multisig so you are actually raising the barrier!

3

I think it makes sense to have a long running testnet to avoid DApp redeployment, I’ve suggested it many times. But I don’t think one with its own cryptocurrency is a good solution, otherwise it’s just a fork by another name.

2 Likes
4

Hello Rafoo, thank you for the comment. I will just number my responses here:

  1. It has been spawned. Launched when Granada was discontinued. Kaizen bakers started running Hangzhou endorsers/baker daemon so we can keep the smart contracts people deployed over the past few months.

  2. Testnet should be run in parralel to mainnet, and it has never done that. It has always been restarted with each Tezos upgrade. Kaizen’s name will not change, it will always be there, and never change names as Tezos upgrades.

  3. Yes, they still need to redeploy smart contracts on the new testnet every time a new one is spawned. Kaizen aims to prevent that.

  4. dapp owners is just what it sounds like, the dapp/project owners. Not the end users.

  5. Yes, and this was mentioned in the article. Midl dev is involved in Kaizen(@nicolasochem was the one to spawn it)

  6. Please state what doesn’t make sense. We don’t want bakers to be upgrading both mainnet and testnet at the same time, they would be overwhelmed. Also, smart contract devs get more time to test their older smart contracts(think back 6 months) without redeploying them on a new testnet.

Yes I understand we need the vote-in from mainnet for an upgrade to be adopted, that is why we would upgrade Kaizen at the beginning of the adoption period and the proposed upgrade is implemented on mainnet.

I’m not sure why it would dis incentivize users to test protocols. Please elaborate.

  1. The barrier to baking on mainnet is $40,000 dollars. I want to lower the barrier to entry by allowing people to bake on testnet(Kaizen) for a much lower amount or free if they jump aboard in the next few months. The incentivization I am talking about would come way down the line when we have many bakers on Kaizen(number is undecided).
6

It wouldn’t be a fork, because all of the NFT’s and tokens with intrinsic value purchased on mainnet would remain on mainnet. Mainnet would still remain responsible for all governance.

What do you think about Polkadot and Kusama? This system works very well for those blockchains. Technically they are “relay” and “testnet” chains and not a “fork”.

7

My first impression is that Kusama directly competes against Polkadot. Yes Parity / the Web3 Foundation is behind it but it was more likely than not a result of wanting double dip.

8

They eventually became competitive due to separate governance. but many projects launch on both. This would keep governance on Tezos making it not possible to fork. My main goal is to open up baking to the wider population. Maybe there is a better way to implement this.

For example, I often start up a baker on testnet, but forget about it because it isn’t critical and it isn’t making any real income, then when I need to test again I have to get rights to bake again. If we even had a small value to testnet tokens, hobbyists could jump in and get their hands dirty with Tezos.

9

There are many ways to achieve that kind of testnet without raising the concerns I’m raising, for example by ensuring that 90% of the tokens are available in a faucet for developers to use, having a large amount of inflation, admin keys that can periodically reset part of the state, etc. These are all very useful things to have in a testnet and very bad thing to have in a standalone L1.

10

Alright, well that was just an idea to incentivize more bakers on testnet. Maybe another idea will come along down the line.

Like I said, I always start up a baker on testnet but forget about it because it has no intrinsic value to me. So I think that will always limit the amount of bakers and users on testnet.

It would be awesome to bring new bakers in on testnet, then slowly migrate them to mainnet as they build their rewards. Maybe applying for a grant to reward these new bakers would be a better idea. A prize for the most efficient baker on testnet, and consolation prizes to bakers who have 95% uptime.

11

Prizes for testnet bakers are a great way to incentivize it because the bakers does not need to purchase any kind of token to participate.

3 Likes
12

A perpetual testnet I would use, would have a token with no value, central control keys, and would replicate governance ( need to test that too ).

It would also be used for and presented to the general public as a place and way to learn about cryptocurrency with no risk.

In my opinion it has plenty of commercial potential on its own and does not need to be further incentivized.

3 Likes
13

Personally, I don’t agree. Unless we had some sort of reward system it will remain as it is now, a ghost testnet. I can promote it and bring people in, but there isn’t really an incentive and people have to pay rent somehow. Tezos baking takes a lot more time than people assume.

Now I do think that having long term hackathons on testnet, or pay rewards to testnet bakers from foundation grants is a great alternate method. However, I’m not sure how the normal grant process would work for this scenerio, maybe Tezos commons could help out. I would definitely need help figuring out what good incentives would be and how to propose this budget to the foundation.

On top of this, another idea would be to have the foundation run testnet bakers along with mainnet bakers? Would be good as well.

14

(regarding 1. and 4. I was uselessly nitpicking on the use of “officially” and “owner”; I apologize for this).

  1. Testnet should be run in parralel to mainnet, and it has never done that.

Alphanet was actually upgraded from “Alpha III” to Athens. We switched to the current model of one test network per protocol when Babylon was proposed.

  1. Please state what doesn’t make sense.

What does not make sense is to expect that upgrading the testnet two weeks before mainnet gives more time for testing the new protocol than the current model.

Yes I understand we need the vote-in from mainnet for an upgrade to be adopted, that is why we would upgrade Kaizen at the beginning of the adoption period and the proposed upgrade is implemented on mainnet. I’m not sure why it would dis incentivize users to test protocols. Please elaborate.

Let’s say I am a dapp developer who wants to launch on a testnet to get feedback from beta-testers. Without Kaizen I have the choice between:

  • launching on Hangzhounet and have my application testable there until the end of life of Hangzhou on mainnet (so about 3 months);
  • launching on Idiazabalnet and contribute to the finalization of the next protocol proposal, my application will be testable there for a few weeks at most;
  • waiting for the finalization of the next protocol proposal, its injection, and the launch of a new testnet for it, let’s call it Inet. My application will be testable there for the lifetime of the I proposal/protocol, assuming the proposal is approved this means at least 5 months.

So currently the incentives for participating to protocol testing are that, if you participate to experimental test network such as Idiazabalnet your feedback can be integrated before injection and if you test the proposals your application will be supported longer.

Now with Kaizen I would have the choice between:

  • launching on Kaizen with the promise that I won’t have to ever redeploy my application;
  • launching on Hangzhounet, same protocol but no promise about what will happen to my application;
  • contribute to testing new protocols.

I don’t see why anyone would use Hangzhounet in these conditions so I guess it will either be stopped sooner than usual or it will be maintained for no users. This means that there is little reason to expect that Inet will be maintained for 5 months.

  1. The barrier to baking on mainnet is $40,000 dollars. I want to lower the barrier to entry by allowing people to bake on testnet (Kaizen)

What’s the barrier to entry for baking on Hangzhounet?

15

Then, in order for Tezos to prosper the most we must compete and the market shall decide! Good luck good sir! :grin:

1 Like
16

1/4 yeah, I speak Japanese most of the time so my English can be rusty at times, even though I’m from the USA.
2. Granada-net ran parallel to mainnet, so I’m a bit confused by this comment. Instead of stopping Granada-net and adopting Hangzhou-net, we are upgrading the current Granada-net to keep the old contract/trans data.

  1. Yes, Kaizen would replace Hangzhou completely since it has already upgraded to the Hangzhou protocol. Dapp owners can do light test on Iadabazu(sorry for the spelling), then test more heavily on Kazien when it reaches adoption 9 days before mainnet reaches adoption.

The main point of this is to get rid of the networks that only last one governance cycle, so the developement cycle would look like this →

beta net(current Ialdabazu, sorry for the spelling), testnet (Kaizen), and mainnet. These three networks are rather normal in the IT world, and now testnet name will remain “Kaizen” and not change with every protocol upgrade, and contracts would be persistant…

  1. Barrier to baking is on mainnet, not Hangzhounet, sorry if I mistyped before. $40k to bake on mainnet now.
1 Like
17

Assuming enough usage of Kaizen, I think this will definitely bring more attention to the upgrade, which may uncover more bugs.

I don’t see what’s confusing about having a testnet for each version of the protocol, especially when the name of each testnet tells you which version it runs. What I find very confusing however is the current status of test networks. Now that Granadanet has been renamed into Kaizen and migrated to Hangzhou, we have two testnets running the same version of the protocol and many places still referring to Kaizen as Granadanet.

You are right that Kaizen, if successful, will make Hangzhounet less relevant, and will also make future protocol-specific testnets less relevant after activation.

Proto-specific testnets are useful to highly engaged devs that pay attention to proto proposals. But if a proto proposal breaks an app, Kaizen will give a less engaged app developer an advance warning that their app may break and/or require changes.

Alphanet was actually upgraded from “Alpha III” to Athens. We switched to the current model of one test network per protocol when Babylon was proposed.

Alphanet also had a coordinated attempt to replicate mainnet protocol upgrades with democracy, which was difficult to get right. Octez now has the option to fetch the network definition from a http endpoint (--network https://teztnets.xyz/kaizen). Given that, coordinated user-activated upgrades are easier to orchestrate.

1 Like
18
  1. My point is that we did that in the past and stopped when Babylon was injected (and Babylonnet launched).

The main point of this is to get rid of the networks that only last one governance cycle

They last two governance cycles. Granadanet was launched in May.

Barrier to baking is on mainnet, not Hangzhounet, sorry if I mistyped before. $40k to bake on mainnet now.

You did not mistype. You are solving an inexistent problem. It’s true that you cannot be assigned baking and endorsing rights on mainnet if you + your delegates don’t own 8k tez but you are not changing that. What you are changing is the barrier to entry for baking on test networks but you are increasing this barrier. Your comparison point should not be mainnet, it should be the other test networks.

1 Like
19

Yes but the bugs will be uncovered so late that the only way to fix them is an emergency hard fork. We should encourage testing of protocols before they are voted!

What kind of breakage are we talking about? AFAIK, no smart contract has ever been locked by a Tezos protocol upgrade. What has happened in the past is that some typing rules were restricted for new contract originations (for example, you cannot reoriginate the Dexter v1 script anymore) but to detect this you need dapp developers to try to deploy their applications which is exactly what they won’t have to do on Kaizen.

User-activated upgrades were coordinated before Athens, even on mainnet. The reason the Alphanet protocol was updated using the voting procedure is simply that the testing procedure itself was considered worth testing; after all Athens was the first voted amendment.

1 Like
20

I was thinking of RPC changes.

21

I think that Arthur makes a great point, and it is something that I have been contemplating for about the past month, since I first heard the idea in the Twitter Spaces meetup mentioned in the Baking Slack. If the Kaizen testnet tez have a value of their own, then it’s not really a testnet anymore. It would be dangerous to test things on it if you could end up losing money due to accidentally locking testnet tez away in a contract or similar. And you couldn’t have a faucet while maintaining value for the testnet tez, because anyone could grab some from the faucet and then “cash them out” however it was bridged. Et cetera.

That said, I still think that having an incentivized, long-running testnet is a great idea. We just need to figure out a good way to incentivize it without turning it into a fork of its own.

Here’s my half-baked idea on how to financially incentivize participation on Kaizen.

  1. Acquire some funding, perhaps through a Tezos Foundation grant, to set up a “Kaizen Incentive” baker on mainnet.
    • This would be a private baker in the sense that it would not make payments to any delegators. At least not in the traditional sense.
    • Ideally the funds in this baking account would be controlled by a multisig to prevent a Gevers-esque situation.
  2. Require those who wish to participate in the incentivization aspect of the Kaizen testnet to fill out an application, which includes their Kaizen baking address, maybe some contact info (on Discord or Baking Slack, etc.), and an operation hash on mainnet providing proof of a relatively small deposit of tez to the baker (or some smart contract alternative).
    • The exact amount can be decided later, but 8 tez (about $35 at current prices) would maintain the aforementioned ratio of 1 tez per 1000 Kaizen tez.
    • The main point of the deposit here is to make sure people are serious about baking on the testnet and won’t just start up a baker and abandon it, harming the testnet by slowing it down.
      • i.e., anyone who abandons the testnet would risk forfeiting some or all of their deposit.
    • Alternatively, maybe the deposit could be placed into a smart contract delegated to the baker, which will lock the funds for some time (such as the average length of 2 incentivization periods), allowing the depositor to withdraw it at some future date.
  3. At the end of each incentivization period, all accumulated baking rewards (minus a fee) are split amongst the incentivized participants. The exact way the baking rewards are split can be decided later. But here are a few ideas:
    • Rewards could be split evenly amongst all inventivized testnet bakers who maintained at least n% efficiency over the course of the incentivization period.
    • Rewards can be split proportionally, according to baking efficiency of each incentivized testnet baker.
    • Combining both of the above: Reward allotments could be split evenly amongst all participants, and then paid according to their efficiency. The leftover amounts are forfeited to the baking account.
      • Example: The accumulated baking rewards (minus fee) are such that each participant is allotted to receive up to 10 tez.
      1. Alice had 97% efficiency, so of her 10 tez, she is sent 9.7 tez, with 0.3 tez remaining in the baking account.
      2. Bob abandoned the testnet, shutting down his baker partway through the incentivization period, and ended up with 10% efficiency overall, so of his 10 tez allotment, he gets 1 tez and 9 tez remain in the baking account.
    • Various criteria can be determined in advance, such as baking efficiency, responsiveness to software updates, activity in the Baking Slack, etc. Each participant can be graded on these criteria and they will receive an amount based on their grade.
    • Personally, I am against making it a competition. I wouldn’t want to encourage bakers to try to sabotage others in order to benefit themselves, or otherwise cause hard feelings between testnet bakers because of a winner-takes-all approach. The idea here is to fairly reward all involved and active participants on the testnet, while discouraging people from setting up and then abandoning bakers on the testnet.
  4. A portion of the baking rewards is kept for two purposes:
    • To fund the running and maintaining of the mainnet “incentivization” baker itself.
    • To increase funds in the baking account over time, perhaps leading to some kind of self-perpetuating treasury to further advance the goals of the Kaizen testnet.

In short, my proposal is to keep the financial incentives fully on the Tezos mainnet, but base it on participation/performance on the Kaizen testnet. Also note that anyone would still be able to use a faucet to get Kaizen tez for free to start up a baker or test smart contracts, etc. But only those who apply and make a deposit are eligible to receive the rewards for participating.

3 Likes