Welcome to the multiverse: bridging the Zenon ecosystem

Development ╰ Funding | Submissions
,
108

I looked into it. They cost about $20/mo on digital ocean.

109

Updated the answer: However, this doesn’t account for the resources required by the nodes, just the orchestrator.

110

@sumamu are you planning a final PR to the orchestrator code to remove the BNB node? Is there anything else you are planning to change?

I have everything I need to write a How To setup an orchestrator. I just want to test it before finalizing the article.

111

Yes, that and some other improvements are WIP, but the setup & configuration will stay the same.

112

I appreciate the nomination but I will have to decline.

Is anyone updating an SDK + CLI to meet this objective?

Edit: https://forum2.zenon.org/t/dart-sdk-cli-updates/1166/42

2 Likes
113

Understood, so it’s similar to a THORNode stack, just that it’s deployed all manually while I think they use Kubernetes or some tooling to build the whole automatically? If that’s correct, do you see a path to make the infra deployment experience more streamlined?

114

I can help with the automatic deployment.

@mehowbrainz do you have a link so I can check it out?

115

At the moment there’s no utility to do this automatically, but fortunately it’s rather simple to do so manually. @0x3639 is writing a guide.

1 Like
116

@sumamu we you be giving us a message to sign to confirm our ZTS address?

Looking at the Orchestrator setup I honestly don’t think we need anything automated initially. It’s literally, download the bin, modify the config.json, and start.

We do need a local znnd node and eth node.

I could add the Orchestrator to the znndNode project to automate the znnd / Orchestrator setup.

117

@sumamu I’ve changed the ZNN address to:

z1qzup2zm6c9g68t085zjn5ycvdnr0u4pt0k4c80

EVM address:

0xE34FB7aadc91f0d95757125F9FB546712846feeB
118

Hello! I am very excited to be one of the guardians protecting the bridge!

ZNN address: z1qprccs7kjvx9q78m5v5ghwwfvxr6py8rtwcfrd

EVM address : 0xc752B223c87327A8A6e2CBE9D3A3E334F1a96fD3

3 Likes
119

So only kainu-sama remains :thinking:

120

Since most addresses have been used onchain and they’re pretty much tied to the guardian’s identity already, that won’t be necessary for the initial guardians subset.

1 Like
121

After looking at their docs, the full nodes may be part of the cluster launcher: THORNode Overview - THORChain Docs

Full nodes - for every chain that is supported by the network, each THORNode operator will run their own full node of each chain (Bitcoin, Ethereum, Binance, etc).

Checkout their cluster launcher and deployment docs: Cluster Launcher - THORChain Docs

Kind looks like the full nodes are part of the solution as they mention the delays required to sync.

122

As we expend to other chains this might be required. The skills required to operate a Kubernetes Cluster are higher than just running the binary and a few nodes.

If we end up adding many chains we could use the TC cluster and node scripts. They are very good and work well last time I tested them.

Maybe we should start with a docker setup. That would be pretty easy to setup and we can do that now. I could adapt the znndNode setup to include the orchestrator and ETH. Also, running znnd, orchestrator, and ETH in docker will be a LOT cheaper than running a Kubernetes cluster.

1 Like
123

@sumamu concerning the documentation I’ve found a couple of inconcistencies I would like to point out.

The Liquidity Embedded Contract

The page mentions 14 methods, but only 12 are described of which 1 is described double while the actual contract has 15 methods.

  • The method names vary with the actual contract names.
    UpdateEmbeddedLiquidityMethod => Update
    SetTokenTupleMethod methd => SetTokenTuple
    LiquidityStakeMethod => LiquidityStake
    CancelLiquidityStakeMethod => CancelLiquidityStake
    UpdateRewardEmbeddedLiquidityMethod => Update
    ChangeAdministratorLiquidity => ChangeAdministrator
    NominateGuardiansLiquidity => NominateGuardians
    ProposeAdministratorLiquidity => ProposeAdministrator
    EmergencyLiquidity => Emergency

  • The description of the following method names are missing.
    Donate
    Fund
    BurnZnn
    CollectReward

The znn-sdk-go

  • Calls CancelLiquidity instead of CancelLiquidityStake.
  • Why does the sdk only implement 5 of the 15 contract methods?
  • Why doesn’t the Liquidity contract uses the common CollectReward definition?
124

Thanks for going over the Documentation and go sdk! We’ll fix those issues asap.

Those methods were predefined in the pre-upgrade liquidity embedded contract, so we didn’t cover them in our documentation, but I agree they should be covered.

The embedded contracts code has been refactored a few times and while the go sdk was kept up to date, that method was likely missed during one of the refactors. If you’d like, please submit a PR an it will be fixed.

I’ll check it out.

The liquidity embedded contract does use common.CollectRewardMethod and also the common.addReward method.

125

You’re right…

Will do.

126

@sumamu some of the community devs are currently in the process of implementing the embedded liquidity/bridge contract in some of the SDKs with the goal of writing alternative tools for interacting with the bridge and maybe even setting up some testnets… However, looking at the docs and contracts alone doesn’t give enough information to completely understand the process.

Would you be willing to share some more insight in the bridging process. Maybe some sequence diagrams between the different actors for a wZNN/ZNN and or ETH/zETH scenario.

127

We don’t have them, yet, but please DM me on TG or Discord and I will do my best to assist in every way.