Protocol Update 4 - Sirius - Delegation and new contract state¶
Effective on Mainnet |
Jun 23, 2022 |
|---|---|
Effective on Testnet |
Jun 13, 2022 |
Specification hash |
|
Specification¶
Protocol update
Protocol Version: 4
Builds on Protocol Version: 3
Protocol Name: Sirius
Abstract
This document describes the changes in Concordium protocol version 4
compared to protocol version 3.
The protocol change adds support for delegation, new smart contracts
that support larger state, synchronous calls, and a number of
cryptographic primitives.
Background
Protocol version 4 changes protocol version 3 in two areas,
tokenomics and smart contracts.
With regards to tokenomics, in protocol versions 1, 2, and 3 accounts
can either be bakers and thus stake their own CCD, or do nothing. In
protocol version 4, each baker is associated with a baker pool.
A non-baker account can delegate stake to a baker pool, which
contributes to the lottery power of the baker. A delegator receives a
proportion of the rewards from the baker pool, but cannot spend their
stake while it is delegated, and are subject to a cool-down period when
reducing their stake. Instead of delegating to a specific baker pool, an
account can opt for passive delegation, which does not back any specific
baker and (typically) gives a lower rate of return.
With regards to smart contracts, in protocol versions 1, 2, and 3
smart contracts have limited state (16kB) and communicate via message
passing. The former limitation prevents use-cases such as exchanges,
or stablecoins which require a large database. The choice of
message-passing is not a technical limitation, but it does make
contracts harder to write. In protocol version 4 a new version 1 of
smart contracts is introduced whose state will not have an explicit
upper limit, however its growth is still limited by the costs. The
message passing communication in new smart contracts is replaced with
direct contract calls. Existing version 0 smart contracts continue to
have the same semantics as in protocol version 1, 2, and 3.
Changes
1. In protocol version 4 the existing baker transactions (`AddBaker`,
`RemoveBaker`, `UpdateBakerStake`, `UpdateBakerRestakeEarnings`,
`UpdateBakerKeys`) are no longer allowed and will fail with a
`SerializationFailure` error.
2. Two new transactions are added, `ConfigureBaker` and
`ConfigureDelegation` for adding, modifying, and removing a baker
pool, and for adding, modifying, and removing delegation of an
account, respectively. An account can delegate to one of the
existing baker pools, or delegate passively. Passive delegation
does not change the distribution of the stake of active baker pools.
3. The minting and distribution of rewards are changed as follows:
* Minting does not happen once per slot, but at each payday. Paydays
occur at intervals of a specified number of epochs. As before, the
minted CCDs are divided between baking rewards, finalization
rewards, and the foundation.
* Transaction fees are not paid out at each block, but at each payday.
The transaction fees are split between the GAS account, an amount
accruing to the foundation, an amount accruing to the pool of the
block's baker, and an amount accruing to the passive delegators. A
proportion of the GAS account is also accrued to the baker pool.
* Baking rewards (from minting) are not paid out at each epoch
boundary, but at each payday. Each pool receives a share
proportional to the number of blocks baked by the pool's baker,
while the passive delegators receive a share proportional to their
relative stake.
* Finalization rewards (also from minting) are not paid out each time
a finalization proof is included in a block, but at each payday.
The finalization rewards are distributed to the baking pools that
signed finalization proofs that were included in blocks since the
previous payday. The reward to each pool is proportional to its
relative stake.
* Transaction fees, baking rewards, and finalization rewards are
distributed to the participants of a baker pool in proportion to
their relative stakes, with the baker taking an additional
commission from the delegators. (The commission rates can be set
independently for the three reward types.) The passive delegators
are similarly rewarded in proportion to their relative stakes, with
separate commission rates applying to passive delegation.
4. Two new chain parameter update types are added, updating cooldown
parameters (for bakers and delegators), and updating payday length
together with the mint rate. The mint distribution update is changed to
no longer update the mint rate. The minimum baker stake threshold update
is replaced with a broader pool parameters update, which determines: the
commission rates for passive delegation; the allowable commission ranges
for baker pools; the minimum equity capital that must be staked by a
baker; the maximum effective stake a pool may have as a proportion of
the total staked capital; and the maximum effective ratio between a
pool's effective stake and the baker's equity capital.
5. The `DeployModule` transaction supports module versions 0 and 1 in
protocol version 4. The difference between the two is the set of host
functions that are allowed. Additionally, module size limit is 512kB
for version 1 modules, but still 64kB for version 0 modules.
6. The version of the smart contract module determines the version of
the smart contract instance. The behaviour of `InitContract` and
`Update` transactions is dependent on the module version. Version 1
contracts can access the new contract state, can call other contracts
and synchronously transfer CCD to an account. Version 1 contracts also
have access to cryptographic primitives `verify_ed25519_signature`,
`verify_ecdsa_secp256k1_signature`, `hash_sha2_256`, `hash_sha3_256`,
and `hash_keccak_256`. Finally, version 1 contracts can have a
fallback entrypoint, which is invoked if none of the other entrypoints
in the contract matches. The semantics of version 0 contracts stays
exactly as it was in protocol versions 1, 2, and 3.
Effects
1. All other existing transactions not explicitly mentioned above
retain their exact semantics.
2. All bakers existing at the time of the protocol update will be
converted to baker pools. The parameters of the pool will be
determined by the payload of the protocol update instruction.
3. The initial parameters related to payday duration, cooldown
duration, for bakers and delegators, as well as allowed ranges of
parameters are provided by the protocol update instruction.
4. All existing contracts are migrated with no change in their
behaviour.
5. New version 0 contracts can continue to be deployed and
initialized.
Protocol update instruction
The protocol update instruction is identified by the SHA256 hash of
this file. The instruction needs the following auxiliary data
- The commission rate to apply to bakers on migration (commission
rates for finalization, baking, and transaction rewards).
- The initial state state of a baking pool on migration. Either open
for all delegators, closed for new delegators, or closed for all.
- Access structure defining the keys and threshold for cooldown parameter
updates.
- Access structure defining the keys and threshold for time parameter
updates. Time parameters are the mint rate per payday and the length
of the payday.
- New cooldown parameters, for bakers and delegators.
- New values of time parameters, length of the payday and mint rate
per payday.
- New baker and passive pool parameters. These are
- passive finalization, baking, and transaction commissions
- commision ranges for baker pools
- minimum equity capital for new baker pools
- capital bound and leverage factor for baker pools
Commentary¶
Protocol update commentary
Protocol Version: 4
Builds on Protocol Version: 3
Protocol Name: Sirius
Protocol version 4 adds support for two major features, delegation and
improved smart contracts.
In the delegation model in protocol version 4, bakers can open pools,
and accounts can delegate part of their capital to such a pool.
Rewards for baking are distributed proportionally to each pool’s
stake. The baker gets a portion of the pool rewards, the remaining
rewards are then distributed amongst the pool participants,
proportionally to their stake. To ensure security of the chain each
pool has a leverage bound, ensuring bakers have to stake a minimum
amount of their own capital, and there is a global bound to ensure no
pool grows too large relative to all other pools.
The smart contracts are updated by adding a new variant, version 1
contracts. The new smart contracts expand the range of use-cases
supported on the concordium chain, make it easier to build smart
contracts that interact with other contracts, and natively support
cryptographic functions `verify_ed25519_signature`,
`verify_ecdsa_secp256k1_signature`, `hash_sha2_256`, `hash_sha3_256`,
and `hash_keccak_256`.
The key technical features of the new contracts are unlimited contract
state based on a key-value store API, synchronous contract calls to
make it simpler to interact with other contracts, and increased
contract size allowance. Version 1 contracts can also support fallback
or default entrypoints to enable easier building of proxy contracts.
Existing version 0 contracts will retain their semantics and continue
to function as they have. New version 0 contracts can still be
created.