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