Upgrade to v. 8
Zilliqa version 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
here.
Upgrade Duration
Date/Time | |
---|---|
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.
Before v8.0.0 |
v8.0.0 |
|
---|---|---|
Peak final block production time | 40 seconds | 29 seconds |
Expected Tx block count per 24 hours | ~1600 Tx blocks | ~2200 Tx blocks |
References:
2) Block reward adjustment
Faster block production rate will result in an increase in inflation rate.
Zilliqa 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 COINBASE_REWARD_PER_DS
as follows:
Before v8.0.0 |
v8.0.0 |
|
---|---|---|
COINBASE_REWARD_PER_DS |
275000000000000000 | 176000000000000000 |
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:
Before v8.0.0 |
v8.0.0 |
|
---|---|---|
NORMAL_TRAN_GAS |
1 | 50 |
When handling payment transactions, developers and exchanges will need to call
CreateTransaction
with gasLimit
set to at least 50
instead of 1
from
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
gas price.
Important
- Smart contract transaction gas unit remains unchanged.
- Developers and exchanges may proceed to make the
gasLimit
change above even beforev8.0.0
is deployed. Until the deployment, the payment transaction fee will continue to be 0.002 $ZIL, with or without thegasLimit
change.
4) Deprecation and removal of GetPendingTxn
and GetPendingTxns
API
Since v7.0.0
, we have released a new API
GetTransactionStatus
which tracks transaction status during the transactional lifetime.
GetPendingTxn
and GetPendingTxns
will be removed with effect from v8.0.0
.
5) Non-interactive mode support for seed nodes
Seed node operators will now have the option of invoking launch.sh
in
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
Note
If 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.
Scilla Updates
1) Scilla disambiguation fix
Warning
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
the type.
For instance, let's assume a user-defined ADT named SSNCycleInfo
is defined in
a contract deployed at address 0xb55cc7894536ac015350790550b0c03f49eb8ebd
.
When using the user-defined ADT, it will need to be prefixed with the contract
address (i.e., 0xb55cc7894536ac015350790550b0c03f49eb8ebd.SSNCycleInfo
). If
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
Before v8.0.0 |
v8.0.0 |
|
---|---|---|
MAX_CONTRACT_EDGES |
10 | 20 |
MAX_CODE_SIZE_IN_BYTES |
51200 | 76800 |
Staking Updates
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.
Important
- 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.
Parameters | New value |
---|---|
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.