Extension Chains: smart contracts for NoM

Development ╰ Funding | Staging
1

WHAT ARE EXTENSION CHAINS?

I see extension chains as sidechains (think of a layer-2 solution similar to Liquid Network) that complements and enhances NoM (with smart contracts) and has the following properties:

  • Allows users of the ext-chain to move ZTS tokens between the two networks with a two-way peg. ZNN used in the extension chain is referred to as eZNN/xZNN, and each xZNN has a verifiably equivalent amount of ZNN secured by the Extension Consensus Group: ECG.

  • The ECG is operated & governed by a (sub)set of Pillars. With no single entity in control and a geographically diverse membership, there is no single point of failure - similar to how orchestrators work. Also Pillars have strong incentives to grow the ecosystem and will be additionally rewarded in xZNN to run & manage the extension chain infrastructure (via a fee sharing mechanism). We can re-use some implementation details from @sumamu’s multi-chain technology.

  • We can adopt the peg-in and peg-out mechanisms from Liquid.

WHY EXTENSION CHAINS?

In my opinion this type of sidechain implementation that can bring EVM/WASM compatibility for NoM will greatly expand the ecosystem. As Mr Kaine already emphasized, extension chains are the fastest way to bring smart contracts to NoM. And we really need EVM compatible smart contracts to grow the ecosystem. Moreover, the base layer remains minimal & efficient as Mr Kaine strongly suggested and all the heavy work/bloat is kept in a separate execution domain.

ARCHITECTURE DESIGN

Pillars are the largest producer of ZNN inflation in the network. They also run orchestrator nodes for the bridge. It makes sense for them to also act as validators for the ext-chain where fees are paid in xZNN. It is important to note that the ext-chain cannot produce additional/separate inflation.

Users, Pillars and every other network participant can peg-in funds into the ext-chain to benefit from smart contracts for example. We can also incentivize/penalize ext-chain users via peg-in/peg-out fee similar to @sumamu’s affiliate fee. It is up to the ext-chain deployer make this decision.

ZNN is not a gas token because the ext-chain will use a wrapped representation of it. It can be called eZNN or xZNN (execution ZNN).

As I already mentioned earlier, we can re-use parts of @sumamu’s bridge and tweak them to support this type of wrapping. If we go with the burning fees, it would be a little bit different from wrapping ZNN to wZNN and unwrapping it later because xZNN will actually be consumed/burnt in the ext-chain (it won’t be a 1:1 backing).

xZNN can be associated with the gas concept for the ext-chain.

BUILT-IN POSITIVE FEEDBACK LOOPS

Since there won’t be any inflation within the ext-chain, we must rely on a fee distribution mechanism.

That’s why I propose the following fee distribution mechanism:

  • 33% distributed to builders (contract deployers)
  • 33% distributed to ECG (ext-chain validators)
  • 34% burned (similar to ETH)

This single piece of ingenuity attracts builders which in turn attracts users.

I’ve already investigated Canto and why it mooned: they’ve implemented the “golden” fee mechanism (contractDeploymentFee).

Users will bridge/swap/convert ZNN for xZNN through an embedded contract (eg ext-chain-embedded) in order to be able to use their favorite dApps that will be run on the ext-chain (for example Unizwap, games, meme tokens, NFT collections, etc.).

Users will be required to pay gas fees to interact with the EVM smart contracts. Therefore, they will pay/consume xZNN and it will be redistributed according to the specified percentages directly by the system contract to the contract deployer, burn address and ECG (ext-chain validators).

Positive feedback loop:

More users => more activity => higher gas fees => more `xZNN` gets consumed => higher payouts for builders & validators => less ZNN in circulation

A win-win-win situation for the whole ecosystem.

The embedded that will convert ZNN to xZNN needs to be carefully designed, because there won’t be a 1:1 backing (we need to take into account xZNN burning).

WEN EXTENSION CHAINS?

I’m already working on a testnet that will go live during sometime during Q3 2023. I plan to release a fully functional mainnet release by the end of Q4 2023 or sooner.

9 Likes
2

Will extension chains be faster in term of confirmation time and throughput than the base layer? Also people talk a lot about L2 being less secure, can you elaborate about that when it comes to ext-chains and the NoM?

3

Great questions, zir!

So far I’ve achieved >1000tps with deterministic finality (1 confirmation required). I have other good news, but I want you to see it with your own eyes first.

We trade-off security and decentralization (of the base layer) for scalability & smart contracts (on L2).

4

What does the copying the burn accomplish on an L2?
If there’s another extension chain that does 50% to contract, 50% to validators, all things being equal, why won’t people choose that chain instead?

1 Like
5

Make ZNN more scarce.

This is up for debate.

6

Topic moved to ╰ Funding | Staging

7

I’m not questionning your design here but I’m really curious about how sidechains and L2 works in general. In this case, can you go deeper (if you have time) about how the tradeoff works? How the validation works etc.

8

Sidechains are a type of L2 (eg Liquid Network). Payment Channel Networks (PCNs) are another type of L2s (eg Lightning Network).

A sidechain is basically another chain that can have different consensus, validator set, etc. and interoperate with the L1 via different mechanisms (in this case the peg-in/peg-out mechanism).

Yes, I’ll compile a list with trade-offs and what design we should approach.

8 Likes
9

On a sidenote and for better UX I’d say that txs should be send seemlessly between L1 and sidechain. A different address structure would probably exists but I’d advocate for a transparent bridge interaction.

10

Definitely. EVM requires secp256k1 so the addresses will be different for sure.

What do you have in mind? We can change the name wrap and unwrap to move across extension chains, but you’d still need to wait for confirmations to move funds between the L1 and the ext-chain.

11

What I meant is that from a user perspective it would be WAY more simple to copy paste the ext chain address and send over there without interacting with the bridge UI if they don’t want to. Less clicks. Better experience overall. Bring a popup about fee and confirmation to keep them informed but it’d be a better UX for those who seek for simplicity.

1 Like
12

Can you check how Avalanche is doing this? They have a similar concept.

1 Like
13

I think Harmony has this kind of trick too, with different kind of address but it’s transparent for the user.

14

Thinking from a positioning standpoint for the sake of marketing/comms, does this proposal essentially allow us to say you can “launch your own chain on NoM” in its final form?

This seems to be the way the market is headed:
https://twitter.com/yiryan/status/1671635818732040193?s=46&t=i2nSc9tNKGroSzBMw8_UiQ

1 Like
15

Exactly. Extension chains will inherit some security properties from NoM, and in the future, from Bitcoin.

6 Likes
16

Amazing. This might be the perfect use-case for buildcities. Each city its own token, the entire ecosystem its own chain

3 Likes
17

Can’t wait for that last part

3 Likes
18

Super excited for this as well. Will the extension chain have its own name?

Alpha Centauri – it’s the closest star system to earth, and this Zenon sidechain is EVM compatible and therefore the closest alien ecosystem to crypto space/humans

3 Likes
19

No please don’t bring more cringe scifi thanks

4 Likes
20

THORchain had all these crazy mythical names that were hard to say, remember, and type.

Look at the top 20 names. They are all easy to remember, say, spell, and type. Much better.

2 Likes