WP1 Network Launch Code & Config

HyperQube
1

Coordination thread for the code/config

2

Acceptance criteria:

Repo with a fork of go-zenon and the following changes:

  • UTIL-Z and UTIL-Q tokens replacing ZNN and QSR
  • Tune network constants for appropriate throughput
    • Exact parameters TBD
  • Change pillar election from weight based to be round robin
    • Since we are incentivizing momentum production as part of Work Packages, this ensures that pillars do not try and use UTIL-Z and UTIL-Q to try and get more momentums.

Genesis file

  • pillars from sign up
  • genesis sporks for AZ and HTLC
    • bridge spork will be activated when we work on connecting mainnet and L2

Round 1 incentives based on median pillar votes

Network Launch Code & Config
6000 / 8025 Points
1121 / 15000 ZNN
11215 / 150000 QSR

Disclaimer : The payment amounts provided herein are intended as guidelines only and do not constitute a binding offer or guarantee of payment. The HyperQube Incubator framework works with Zenon Network Pillars to signal incentives which are subject to change over multiple rounds. Actual payment amounts will be based on Accelerator-Z grants that depend on the voting rules and requirement of Accelerator-Z.

We may need to use Network Launch Bonus/Placeholder to incentive review

3

I will nominate myself for this work since I want to make sure this is done right.
If there are no objections, I will begin the work.

4 Likes
4

no objection.

To be clear, initially there will be no connection between the L1 and L2. Just want to make sure everyone understands that.

5

Sorry for the late update. Been traveling full time last week and this week.
I think I can have the code done by EOM.
Can also have the genesis templated out waiting for pillar sign up work.

6

hyperqube_z node code is coming along. I have an extra goal to make the code backwards compatible with mainnet.
Binary will probably be called hqzd
Main features/differences from mainnet/znnd

  1. custom zToken and qToken, selected through first and second genesis tokens. Also a new rpc endpoint ledger.meta which dumps chainId, zToken, qToken to allow for wallets to easily configure themselves depending on the chain.
  2. uniform random pillar election. this is to discourage the native tokens from having value since pillar momentums are incentivized. still deciding how to trigger switching the election algo, probably through genesis extradata field for now which is fairly flexible for future things too
  3. configurable throughput, probably again through genesis extradata

Long term, in a future work package, I want to make many of these things defined in genesis directly, and changeable through governance

As a note, the go-zenon codebase uses some global/package level variables, e.g. types.ZnnTokenStandard. For hyperqube_z weā€™ll probably want to get rid of that over time.

I should have another update this weekend. Operational support work will be able to start soon.

2 Likes
7

Will push some code tomorrow after updating the readme and doing some basic smoke tests.

I will also update nomctl generate-devnet command with a flag to generate a a hyperqube_z compatible genesis.json so that others can test locally. Will also update nomctl to take advantage of the ledger.meta endpoint.

When it comes to configurable throughput and lowering the hardware requirements for hyperqube_z, it would ostensibly be simple to just adjust the hardcoded plasma per momentum cap. However currently on mainnet, most momentums are empty and still some nodes struggle.

Iā€™ve gone the more complicated route of adjusting BlockTime. I think we will go with 60 seconds, a momentum a minute, instead of mainnetā€™s 10 seconds. Iā€™m not sure what the overhead of networking is, but otherwise this should reduce the node load/requirements by a factor of 6.

It seems to be working as intended, but the relevant config is not straightforward, and itā€™s hard to be sure with such an invasive change without further testing.

8

One thing I am considering adding is a section in config for whitelisted addresses.
When producing a momentum, pillars would first check the whitelisted addresses for transactions. Currently it is random.

This would ensure that even with low throughput, as long as pillar is producing, they will be able to get in their incubator votes.

9
10

Is there something we need to consider regarding pillar registration in the embedded contract? Are non-mainnet backed pillars allowed to be launched?

1 Like
11

Ah! Good call out. I forgot I was supposed to disable that pillar registration method.

12

I will get the devnet code out first so that people can begin testing the current changes. Then I will fix the pillar registration.

13

Will push out some more code tomorrow and then we will have a test launch planned out over the weekend for next week.

2 Likes
14

Sorry for the delay. Pushed some more commits for Add hyperqube_z logic by georgezgeorgez Ā· Pull Request #1 Ā· hypercore-one/hyperqube_z Ā· GitHub.
A few rabbit holes. Some concluded. Others tabled.

Some notes: moved the applyHyperQubeConfig(config) call before CheckGenesis to make sure tokens are changed before checks such as hyperqube_z/chain/genesis/shared_tests.go at 429e853ba038be1eddc5c0708cb26cff79610101 Ā· hypercore-one/hyperqube_z Ā· GitHub run.

Used a spork to trigger pillar registration deactivation.

Hyperqube_z will activate htlc spork at genesis but will not activate bridge spork until it is time to integrate hyperqube_z with mainnet. This required a change to the logic which determines available embedded methods.

The existing code is hardcoded for mainnet where htlc is activated after bridge is activated. Future refactors will likely be needed.

I will migrate go-zdk and nomctl into hypercore-one organization.
A few more tweaks to those repos and they will have some updates pushed as well.

1 Like
15

go-zdk migrated and now supports ledger.meta endpoint with a utility to create a client connection from it

16

Oops forgot to stage all changes

17

At some point, it will probably make sense to add Spork dependency logic. E.g, you canā€™t activate spork B unless spork A is active. Also in the future, I am thinking of having on-chain feature flags and other dynamic configuration.

18

I am being a bit fast and loose with my changes to go-zdk and nomctl repos.
I figure it shouldnā€™t impact anyone.

Iā€™ll make it easy to review all the changes.
And once hyperqube_z is launched, now that the repos are under hypercore-one org, will go through proper code review for all changes.

1 Like
19

When big int was activated, i think several rpc unmarshalling bugs were introduced in go-zenon.
No one ever hits them because syrius uses the dart sdk with its own logic.

Let me see how far we can get without addressing themā€¦

20

This one is an easy fix. Will make an MR right now.