ZenIP 42406 PROPOSED: Technical Roadmap for the Migration of $ZEN and EON

[zain]

Preamble

• ZenIP: 42406

• Title: Technical Roadmap for the Migration of $ZEN and EON

• Owner: Zain Cheng

• Discussions-To: zain@horizenlabs.io

• Status: Draft

• Type: Technical

• Created: June 6, 2024

• License: MIT

Abstract

This proposal details the strategic technical plan for transitioning the $ZEN cryptocurrency from the current Horizen Mainchain and Horizen EON EVM to an advanced blockchain architecture, EON 2.0. The initiative seeks community approval for this migration, which aims to improve blockchain performance, incorporate the latest advancements in zero-knowledge proof systems, and enhance the utility of $ZEN.

Please note that this is a technical ZenIP, laying out the technical roadmap for the migration mechanics for $ZEN and EON. Tokenomics are not in scope for this ZenIP. Topics such as allocations and emissions are explicitly excluded, since they will be covered in greater detail in a separate proposal. Regardless of the circumstances, the max supply of 21 million $ZEN is sacrosanct and will remain untouched.

Motivation

Horizen ($ZEN) and EON are currently built on older technology stacks. The Horizen Mainchain is a fork of the Bitcoin C++ codebase with a block time of 2.5 minutes, while EON is written in Scala based on the Scorex SDK with an 18-second block time. To address the limitations of these legacy systems and align with the vision of Horizen as a home for ZK and an enduring utility for $ZEN, we propose migrating to EON 2.0.

EON 2.0 will be a fully compatible EVM, allowing DApp developers to develop and deploy Solidity smart contracts. Under the hood, EON’s EVM itself will be built on Substrate, allowing it to tightly integrate with zkVerify (which is also built on Substrate). This integration will enable direct access to zkVerify’s optimized proof verification pallets, which will provide zk app developers with seamless access to new proving systems and more cost efficient proof verification, thus enhancing the overall utility of zk applications within the Horizen ecosystem.

Rust also plays a pivotal role in this ecosystem, particularly given its reputation as the language of choice for cryptography and secure software development. The Substrate framework, written in Rust, benefits from the language’s robust memory safety features and performance efficiency, which are critical for implementing secure and fast cryptographic operations. Additionally, developers can use Rust to create custom pre-compiled contracts to extend EVM functionality and bridge operations to Substrate-based pallets.

Horizen’s migration to EON 2.0 is crucial for advancing the ecosystem, and this proposal will reassure the community that there is a robust and forward-looking plan in place to enhance the functionality, security, and scalability of the Horizen ecosystem.

Specification

The specification section breaks down the technical aspects of EON 2.0, detailing how each component will function to create a robust and efficient blockchain environment.

Figure 1: EON 2.0 as a fully compatible EVM, optimized for zk applications and built with Substrate framework (written in Rust).

• Consensus

  • Mechanism: Delegated Proof of Stake (DPoS).

  • Target Block Time: 6 seconds.

• Incentives

  • Staking Rewards: Continuation of previous EON 1.0 staking mechanisms.

  • Coinbase Rewards: Emissions-based rewards for producing blocks.

  • Transaction Fees: Percentage of transaction fees go to block producers.

• $ZEN Emission

  • The technological framework of EON 2.0 is designed to accommodate any emissions schedule for $ZEN, ensuring flexibility to maintain or adjust the current emissions rate as needed. This robustness underscores that emissions schedules are not a technical limitation.

  • It is important to stress that this ZenIP does not discuss tokenomics, emissions, or allocations, which are reserved for a separate, dedicated ZenIP. In all scenarios, we acknowledge that the max supply of 21 million $ZEN is sacred and will be strictly preserved.

• Staking

  • Continuing the approach of EON 1.0, EON 2.0 will also adopt a delegated proof-of-stake model, offering users the option to delegate $ZEN to nodes.

  • Through this delegation, users can participate in the network and receive rewards proportional to their staked amounts.

• Snapshot-Based Migration

  • State snapshots of both EON 1.0 and Horizen will be taken to ensure a seamless transition to EON 2.0.

  • More information is detailed below in the Migration Path section.

• Core Technology & Execution Environment

  • EON 2.0 is a fully compatible EVM, ensuring that developers can seamlessly deploy existing Solidity smart contracts on EON 2.0 without requiring any modifications.

  • EON 2.0 integrates tightly with the zkVerify protocol, ensuring fast and cost-efficient verification of zk proofs.

  • zkVerify (built using the Substrate framework and written in Rust) will operate as its own Relay Chain. To achieve this close integration, EON 2.0 will also utilize the Substrate framework as a parachain to zkVerify.

  • It’s important to emphasize that while EON 2.0 uses the Substrate framework, it is entirely independent of the Polkadot ecosystem.

  • EON forgers will be known as EON collators to reflect their role in producing blocks within the parachain structure.

Migration Path

Figure 2: High-level steps for $ZEN & EON 2.0 migration, including the prolonged claim window for $ZEN from the Mainchain. $ZEN in EON 1.0 will not require any claim, since balances will be migrated with the state snapshot.

The migration to EON 2.0 will involve the following key steps and features:

1. Communication Assurance & Transparency.

   • We will ensure transparent and timely communication with the entire ZEN community, ecosystem partners, and other stakeholders throughout the migration process.

   • Before any significant actions are taken, detailed announcements will be made to explain the changes, the reasons behind them, and their impact.

2. Disconnect EON from the Horizen Mainchain (ZEND).

   • Remove the ability to transfer ZEN between EON and ZEND by disabling forward and backward transfers.

3. Snapshot State.

   • Take comprehensive state snapshots of both EON and ZEND.

   • Captures all relevant data to ensure a seamless transition to EON 2.0.

   • This means that existing smart contracts on EON will be transitioned over, including $ZEN in current liquidity pools.

   • No action is needed by $ZEN holders.

   • Ability for anyone to independently verify the integrity of both snapshots.

4. Transition Exchanges, DEXs, partners.

   • Allow a period of time to transition exchanges, DEXs, and partners.

   • This would be a short period of time, on the order of hours, not weeks or months.

5. Launch EON 2.0 Chain.

   • Launch EON 2.0 genesis block from EON 1.0 state, maintaining all deployed smart contracts, storage and account balances, but not carrying over transaction history.

   • Expose ZEND state through a precompile in EON 2.0.

6. Prolonged Claim Window.

   • Eligible users can claim their old Mainchain $ZEN by proving the ownership of their address.

7. Migration Support.

   • Provide comprehensive support to assist with the transition.

   • Monitor the new network for any issues and address them promptly.

   • Continue to engage with the community to gather feedback and improve EON 2.0 even further.

Rationale

The Horizen Foundation currently engages Horizen Labs as its technical service provider for Mainchain Horizen and EON. The Horizen Foundation can leverage this existing relationship to utilize the expertise of Horizen Labs to support large and expansive initiatives. This would avoid delays and incurring additional costs, such as legal fees.

Backwards Compatibility

EON 2.0 will ensure backward compatibility to provide a smooth transition for existing $ZEN holders and EON developers, including incentives, emissions, staking, partner integrations, exchange continuity, and EVM compatibility.

Security & Privacy Concerns

The migration path has been designed with a strong emphasis on security. The snapshot-based approach ensures data integrity and minimizes the risk of data loss or corruption. By requiring proof of ownership, the manual claim process for ZEN balances further enhances security. EON 2.0’s use of Rust ensures reliable performance and safety, strengthening the overall security of the ecosystem.

Estimated Timeline and Cost

Blockchain migrations are complex undertakings that require meticulous planning and execution to ensure a smooth transition. We recognize the critical nature of this process and are committed to maintaining our reputation for high-quality software.

The migration is designed to be thorough and efficient, with an estimated timeline of roughly 8 months and a projected development cost of $1.5MM - $2.5MM from the start of development to Mainnet. Additional details are illustrated in the Gantt chart below. Considering the typical duration and expense of blockchain migrations, it is comparable to other similar migrations. For instance, Ethereum’s transition from Proof-of-Work to Proof-of-Stake consensus spanned over several years. We are dedicated to allocating the necessary resources and attention to detail to ensure the migration is handled correctly, emphasizing our commitment to quality and community trust.

Figure 3: High-level Gantt chart of activities for the migration of $ZEN and EON.

[blockops]

This is great! Love it!!

[domenico]

Very detailed, exciting and bullish on this vision

[RME18]

Appreciate all of the detail and work…it’s clear that the team put a lot of thought into this.

[PVM]

Love it! Looking forward to see ZEN 2.0

[rocket]

Fully support this initiative.

ZEN and EON will migrate to a modern tech stack.

Zen supply is preserved.

Integration with the zkVerify protocol is an advantage over competing EVMs.

Tokenomics is not covered in this ZenIP, but these changes mean that Zen could potentially have a bigger incentive pool for its ecosystem.

Looking forward to ZEN 2.0

[nrdl]

1. Transition Exchanges, DEXs, partners.

• Allow a period of time to transition exchanges, DEXs, and partners.
• This would be a short period of time, on the order of hours, not weeks or months.
  I don’t understand this part, why does it have to be a short period, please explain further?
  And ledger wallet holders can keep it as it is without any conversion to sphere, right?

[blockops]

as soon as the snapshot happens, there is no reason for any transactions to happen on Horizen mainchain or EON, because they don’t matter anymore. I would expect exchanges to stop deposits and withdrawals of ZEN right before the snapshot.

After the snapshot, in order for any ZEN transactions to happen, EON2 mainchain with ZEN as the governance and gas token has to be running reliably. This should happen quickly.

Regarding ledger…my recommendation is to move all ZEN from ledger to a sphere wallet before the snapshot to be able to claim ZEN on EON2 in a more straightforward way

[nrdl]

If I want to continue using hardware wallets, should I move them to EON before the snapshot and connect them with MetaMask??

[blockops]

ZEN on EON using Metamask (with the Ethereum app on Ledger) is a good idea!

The ZEN that is on EON will be available immediately when EON2 is live. ZEN that is on Horizen mainchain will have to be claimed by some way showing the ownership of the ZEN. I expect connecting metamask to EON2 will have the ZEN on the new chain already, as far as I understand that process.

Not sure exactly how, it might be by private key or recovery phrase is what I am thinking, but it also might be by signature using wallet.

[domenico]

All ZEN on EON will be preserved in the new chain, meaning anything on EON 1.0 will also be there when EON 2.0 is spun up.

Users who have assets on the mainchain will have to claim tokens through another process. It will be secure but obviously not as seamless as if a user forward transferred ZEN to EON prior.

It is likely easier to move assets to EON prior

[AstarZens]

Thank you.

These are the questions.

Q1. ZEN in ZEND is also included in the snapshot = Is ZEN in sphere wallet also the target of the snapshot?

Q2. It is expected to be complicated to prove ownership of ZEN in ZEND(Sphere wallet) = Is it a simple solution to move to ZEN in EON?

Q3. Do exchanges with significant ZEN support migration? = Are ZEN on exchanges eligible for migration?

Q4. Is the ZEN in the sphere wallet impossible to move the ZEN after the snapshot until the migration ends?

[PVM]

Buzzing about it so had to spread the word!
Horizen 2024: Technical Roadmap for the Migration of $ZEN and EON https://www.publish0x.com/mind-puzzle/horizen-2024-technical-roadmap-for-the-migration-of-dollar-z-xnkzwkk?a=pmbk1p5ezJ

[finpunk]

That’s a good point about what we can do with $ZEN tokenomics. It’s clear the community doesn’t want to change the total supply from 21M (incl me), but we have plenty of other options on what to do with the remaining emission. I’m a huge fan of introducing a big incentive pool for zk projects to launch on EON 2.0 and to use zkVerify. Ideally, we could even have a joint incentive program using both $ZEN and $ZKV.

[zain]

Great questions.

1. Yes, $ZEN held in a Sphere wallet is also covered by the snapshot.

2. The proof of ownership / claim process will be straightforward and easy to follow, with clear instructions designed for simplicity and ease of use. We will craft these instructions with great care to ensure a smooth and hassle-free experience for the ZEN community.

3. $ZEN held in exchanges will be included in the migration. We will partner closely with exchanges to minimize any impact on ZEN users.

4. To ensure a smooth transition, the timeframe between the snapshots and the launch of the EON 2.0 chain is kept intentionally short. It is not recommended to move ZEN during this period. Comprehensive instructions will be given well beforehand. We are committed to keeping the ZEN community updated with clear and transparent communication in advance of the migration.

[Andreas]

It’s smart that you have thought about disabling forward / backward transfers between the mainchain and EON. Obviously you can’t make the snapshot on mainchain and EON at the same time as they have different blocktime and also it would be a big problem how to handle the ongoing fw bw transfers at the time of snapshot. Well done!

[luisantoniocrag]

I love this idea! Both environments could joint in an incentive program.

[mscryptofu]

Love it and I fully support this proposal!

The strategic transition to EON 2.0 is a game-changer for Horizen, promising significant improvements in blockchain performance, integration of advanced zk technology, and enhanced $ZEN utility. The move to a fully compatible EVM built on a more advanced tech stack, coupled with robust staking rewards and incentives, sets a solid foundation for future growth and innovation on Horizen.

The focus on security, backward compatibility, and community involvement reassures me that this transition will be seamless and beneficial for all stakeholders. Kudos to the team for their forward-thinking approach and dedication to making Horizen a leader in the crypto space. Excited for what’s to come!

[blockops]

if it is going to be easier to transition ZEN from EON to EON2, then maybe a few months before the change we should move the supernode reward from the supernodes on mainchain to forger nodes on EON

[ZenMan2024]

Im slightly confused on a few parts of this, so any clarification would be great.

Sphere will be deprecated? Why?

No more forger nodes? Forger nodes have been around for a very short time, and now they are going away? The change to forger nodes was a big change, and now a few months later that is going to change?

What would be a reason for me to buy some more ZEN or support this project over other ZK projects? Maybe the first sentence can’t be answered as it’s more of a financial question, but there are other projects involved in ZK that seem to be very strong and making noise. I don’t see as much about Horizen. Why Horizen? Thank you!