Improving the Decentralization of the Zilliqa Network

At Zilliqa, we are always striving to provide the best Layer 1 blockchain available, which requires our mainnet to be both a sufficiently resilient and decentralized network. To help realize this goal, we are today proposing a number of changes to core components of the network.

Improving the Decentralization of the Zilliqa Network

At Zilliqa, we are always striving to provide the best Layer 1 blockchain available, which requires our mainnet to be both a sufficiently resilient and decentralized network. Both of these factors are essential to providing the best possible blockchain solution – for the businesses that rely on Zilliqa, for the developers that build with us, as well as the community that has come to count on the network and the services it supports.

To ensure that we continue to realize this commitment and are leading from the front, we are today proposing some important technical changes to the core components of the Zilliqa mainnet – the first step in a multi-faceted decentralization improvement plan for Zilliqa.

Understanding Decentralization on the Zilliqa Network

At present, a fault in the underlying infrastructure running the core components of the Zilliqa network may be disruptive for the entire network. This does not align with our commitment to providing the best Layer 1 blockchain solution available.

To alleviate these potential issues and to further the evolution of the Zilliqa network, this post  proposes a number of changes to both our regional presence and the deployments of our cloud operations, in addition to implementing improvements related to the onboarding of both mining pools and node operators.  These changes will result in a more cost-effective and energy-efficient network, as well as ease  the  longer-term transition to a Proof-of-Stake based blockchain with Zilliqa 2.0.

It is important to understand that decentralization encompasses multiple dimensions, each of which individually contributes to the overall resiliency and reliability of the Zilliqa network.

The current architecture of the Zilliqa network is such that Zilliqa Research operates several core components of the mainnet, which are separate from the functions of the miners and validators on the network – both of which already exhibit a strong degree of decentralization. These Zilliqa Research operated components include:

  • Some of the Directory Service nodes
  • Shard Guard nodes - special shard nodes used to ensure the network stability
  • Seed Pub Nodes – responsible for exposing Zilliqa’s mainnet API
  • Persistence Storage and Backup – which currently resides in Amazon’s S3 (Automatic backup of persistence occurs every 88th block on the network – i.e., every DS epoch) and is used by miners and node operators prior to starting the node.

The reality of the current infrastructure setup of the Zilliqa network is that the mainnet services are overly centralized. Our immediate efforts will focus on decentralizing some of the elements under the direct control of  Zilliqa Research, as they are achievable without requiring substantial action from the wider-Zilliqa community and will result in significantly de-risking mainnet operations.

Dimension

Description

In scope

Region

This dimension provides an indication on which country and sub-countries are running the Zilliqa mainnet nodes operated by Zilliqa Research.

yes

Availability Zone

This dimension specifies how many data centers within the region are used to host the Zilliqa mainnet nodes operated by Zilliqa Research.

yes

Cloud Providers

This dimension specifies which cloud providers have been in use to host the Zilliqa mainnet nodes operated by Zilliqa Research.

no

Mining pools

This dimension provides an indication of the level of decentralization in terms of different mining pools which are mining ZILs.

no

Miners

This dimension provides an indication of the level of decentralization in terms of different miners mining ZILs.

no

Node operators

This dimension provides an indication of the level of decentralization in terms of operators running Zilliqa mainnet nodes, seed staking Nodes, seed nodes and DS guards.

no

The first phase of improvements to the Zilliqa network are focused around three primary goals:

1. Enable the multi-availability zone deployment of the core components of the Zilliqa mainnet, as well as their associated multi-region disaster recovery protections by leveraging infrastructure as code and S3 cross-region replication.

2. Establish a multi-region deployment of the core components of the Zilliqa mainnet that are currently operated by Zilliqa Research.

Deploying the Zilliqa core components across at least two different regions - USA and Singapore - will make us tolerant from AWS region failures, insulate us against changes to regional regulations, in addition to increasing our direct presence in Asia-Pacific.

3. API decentralization and externalization.

By improving our API DNS resolution design, we have the ability to externalize the execution of our seed nodes and include them in our API, increasing our resiliency to DDoS attacks and reducing the latency between API requestors and our endpoints.

A Window to the Future of Zilliqa

As we look towards Zilliqa 2.0 – which represents the long-term future of the network and a potential major uplift in our capabilities – we are looking to tackle the issue of decentralization head-on, with plans to build a blockchain that can offer greater levels of decentralization without requiring as many miners.

The reality is that following ‘The Merge’ on the Ethereum Network, the landscape for both miners and validators has – and will continue to – change quite significantly. We are therefore evaluating our options as we consider the next long-term moves for Zilliqa.

We are confident that there are many different ways to achieve decentralization that go beyond merely waiting for more participants to join the network and remain committed to working closely with network validators to ensure that positive options and outcomes are achieved for everyone.

Additional reading