Upgrade to v. 8
8.0.0 consists of numerous significant changes. This page
summarizes some of the major changes that developers and exchanges will need to
take note of. The full release note of
v8.0.0 is available
|Upgrade start||Tuesday 11th May 2021 05:00 UTC|
|Upgrade end||Tuesday 11th May 2021 11:00 UTC|
Core Protocol Updates
1) Faster block production rate
We have made some changes to our pBFT (Practical Byzantine Fault Tolerance) consensus and transaction dispatching and processing implementation. This allows for faster block production rate.
|Peak final block production time||40 seconds||29 seconds|
|Expected Tx block count per 24 hours||~1600 Tx blocks||~2200 Tx blocks|
2) Block reward adjustment
Faster block production rate will result in an increase in inflation rate.
v8.0.0 will not include any adjustment to the current inflation rate.
Instead, in order to preserve the current inflation rate, the reward allocated
per DS epoch will be decreased from 275,000 $ZIL per DS block to 176,000 $ZIL
per DS block. We will update the
Please note that this change is considered an interim change. If the block production rate deviates from the expected value significantly, a new governance proposal can be introduced to adjust the value in subsequent Mainnet upgrades.
3) Payment transaction gas unit increase from 1 to 50
As per ZIP-18,
which passed Zilliqa governance vote, the gas unit of payment transaction will
be adjusted from 1 to 50 gas unit. We will update
NORMAL_TRAN_GAS as follows:
When handling payment transactions, developers and exchanges will need to call
gasLimit set to at least
50 instead of
v8.0.0 onwards. As a result of this change, the minimal cost of a payment
transaction fee will increase from 0.002 $ZIL to 0.1 $ZIL assuming the lowest
- Smart contract transaction gas unit remains unchanged.
- Developers and exchanges may proceed to make the
gasLimitchange above even before
v8.0.0is deployed. Until the deployment, the payment transaction fee will continue to be 0.002 $ZIL, with or without the
4) Deprecation and removal of
v7.0.0, we have released a new API
which tracks transaction status during the transactional lifetime.
GetPendingTxns will be removed with effect from
5) Non-interactive mode support for seed nodes
Seed node operators will now have the option of invoking
non-interactive mode. Operators will need to configure the following environment
variables when using non-interactive mode.
NONINTERACTIVE="true" IP_ADDRESS="x.y.z.a" IP_WHITELISTING="N" #optional
IP_WHITELISTING is set to
N, the script assumes the existence of the whitelisted keypair file called "whitelistkey.txt", and further assumes "mykey.txt" as the whitelisted key if "whitelistkey.txt" does not exist.
6) Bug fixes around mining node joining
We have fixed a few mining node joining issues. Special thanks to K1-pool for reporting a few issues to us.
1) Scilla disambiguation fix
To support Scilla features such as remote state read and external library, user-defined ADTs will need to be non-ambiguous starting from
v8.0.0. This means
that when calling a contract transition that contains a user-defined ADT, the user-defined ADT will need to be prefixed with the contract address that defines
For instance, let's assume a user-defined ADT named
SSNCycleInfo is defined in
a contract deployed at address
When using the user-defined ADT, it will need to be prefixed with the contract
your contract transition has user-defined ADTs, you will need to modify the way
you call the transition by appending the contract address prefix.
2) Introduction of new Scilla feature - remote state read
With effect from
v8.0.0, a Scilla contract will be able to read the state of
another contract by using the remote state read feature.
3) Smart contract parameters change
To support larger dApps and the need for more contract calls, we will adjust the following constant values
As part of the
v8.0.0 rollout, the current Staking Phase 1.0 feature will be
updated to the new Staking Phase 1.1.
1) Staking contract migration
Due to the Scilla disambiguation fix, we will be freezing the existing staking
contract shortly before the
v8.0.0 network upgrade commences. The contract
will be frozen permanently, and the contract states and funds will be migrated
to a new contract.
- Migration to the new contract is expected to take up to 7 days
- During the migration, the existing contract will be paused and no staking activities such as stake withdrawal can be conducted
- Rewards for staking will be retroactively distributed after the staking contract migration
- For wallets, explorers and exchanges, please note that the contract address will be changed and you will need to update it on your end. We will provide the address once we have deployed the Mainnet contract
- We will make Staking Phase 1.1 available on the public testnet shortly to help you prepare for the staking contract migration
- For community members, please kindly wait for your wallet provider to update to the new staking contract if you encounter any staking issue
2) Switching of staking wallet
The new staking contract will also have a new
swap delegate feature which
allows a delegator to swap his wallet address with another address without
incurring any unbonding period or rewards penalty.
3) Staking parameter adjustments
Due to faster block production rate after
v8.0.0, we will be adjusting the
following parameters to bring rewarding and unbonding timing back to parity.
|Rewards per cycle||1,548,800 $ZIL|
|Reward cycle||2,200 final blocks (~1 day)|
|Unbonding period||30,800 Final blocks (~2 weeks)|
Please note that this change is considered an interim change. If the block production rate deviates from the expected value significantly, a new governance proposal can be introduced to adjust the staking parameter accordingly.
4) $gZIL ending period
$gZIL minting period has been set to end on block
1483713. This value cannot
be changed. With the changes to block time in
v8.0.0, the ending wall clock
may vary as a result.