Commit 09915f4f authored by Nicolas Ochem's avatar Nicolas Ochem
Browse files

Add new tzip draft: testnet admin key

parent 9a9966b6
Pipeline #477200208 failed with stage
in 40 seconds
---
title: Testnet Admin Key
status: Draft - will remain "Draft" until accepted
author: Nicolas Ochem <nicolas.ochem@gmail.com>, Seb Mondet <seb@mondet.org>
type: Meta
created: 2022-02-16
date: 2022-02-16
version: 0
---
## Summary
We propose a protocol amendment where, for any chain other than Tezos mainnet, a chosen "dictator key" may force a protocol upgrade. The chain automatically upgrades to this protocol at the end of the voting period.
## Motivation
Tezos Testnets have historically been respawned at every protocol upgrade. Testnet users have to pay attention to their lifecycle. Common URIs for the currently active testnet change regularly, and contracts need to be redeployed. This hinders activity on testnet besides the core teams and is causing pains to those who do use it.
An administrative key with special rights to trigger protocol upgrades enables the creation of test chains that can be upgraded administratively. This chain would be de facto centralized, which is a desirable attribute of a testnet.
We intend to use this mechanism to deploy a long-running testnet that upgrades to mainnet protocol shortly (a few days to a week) before mainnet is poised to upgrade via governance.
## Specification
We introduce a new constant `testnet_governance_dictator_source`. This constant may be populated with the public key of the dictator account that may unilaterally trigger protocol upgrades if the chain is not Mainnet.
This impacts the following files:
* src/proto_alpha/lib_protocol/constants_storage.ml
* src/proto_alpha/lib_protocol/constants_repr.ml
The governance process in the protocol is amended, so that, if the chain is not Tezos mainnet, and the dictator key injects a proposal, then the chain upgrades itself to the injected protocol at the beginning of the following voting period, bypassing governance.
Specifically, if not mainnet and when proposal comes from the dictator-key, we intercept the [upvote call](https://gitlab.com/tezos/tezos/-/blob/master/src/proto_alpha/lib_protocol/apply.ml#L2450-2459) and call `Vote.set_current_proposal` that sets the current voting period to Adoption, and the proposal under consideration to the one upvoted by the dictator, bypassing the [governance state machine](src/proto_alpha/lib_protocol/amendment.ml).
The chain identifier is accessible by the protocol. To determine whether we are on mainnet, we compare the chain_id with the mainnet chain_id `NetXdQprcVkpaWU`.
The protocol where this mechanism is injected contains special constant migration code, which sets the dictator key to a key managed by Oxhead Alpha when the chain identifier is `NetXnHfVqm9iesp`, the chain id of Ithacanet (or, if this proposal is accepted later, the relevant network at the time). For mainnet and any other chain, this variable remains unset. This special constant migration code can be removed in future protocols.
## Rationale
The most common use case for a permanent testnet is to closely follow mainnet deployments. Testnet activity has no economic value, so users and bakers are less engaged than on mainnet. Because of this, using the regular governance mechanism to update testnets is not viable.
The core teams typically release software containing the Tezos protocol as it is going through the on-chain governance process. Most bakers and users use released software artifacts. Consequently, having Tezos mainnet and the Tezos testnets run the same protocol code and hash is important. Otherwise, the operational burdens in building, injecting, running and using a different protocol on the testnet would cause a decrease in partipation. Therefore, the mainnet protocol must contain the governance bypass code, even though it can not run there.
We are planning to keep Ithacanet alive, migrate it to J with a coordinated user-activated upgrade, and give it a new name. Thanks to the special migration code, the dictator key will be set to a key controlled by Oxhead Alpha. The chain can then keep following mainnet protocols after J using the mechanism introduced in this TZIP. If this proposal is accepted and included later than J, we will instead upgrade the active testnet at the time using the described method.
**Why not do user-activated upgrades?**
Octez offers a method to forcibly upgrade a protocol with user-activated upgrades triggered at a set level by the node configuration (specifically the network section). This however requires off-chain coordination between bakers to change their node config. In contrast, the upgrade method proposed here simply requires bakers to upgrade their node software, like they would do on mainnet.
**Why not use the central ``--network <URL>`` config download mechanism that already exists?**
`--network <URL>` is a shortcut that has been implemented to allow bakers to update their node configuration from a central source: the `--network` parameter to `tezos-node config init/update` can take a URL instead of a chain identifier. This URL exposes a JSON-encoded network config.
This method is used for example on Mondayet: to join Mondaynet, a baker can run `tezos-node config init --network https://teztnets.xyz/mondaynet`
When the remote network config changes, the node configuration can be updated by re-running this command. This allows node operators to introduce an user activated upgrade in their network configuration from a central source.
This is not viable for a widely used permanent testnet as it requires bakers to run `config update` commands regularly in order to follow the network. It is hard to coordinate in practice. Bakers who do not do that are eliminated from the chain each time there is an upgrade. This may make the chain stall.
But it could be extended so that every restart re-downloads the remote config. Furthermore, the remote config URL could be hardcoded into the node binary. For example, Octez could be hardcoded to interpret `--network acme` as `--network https://teztnets.xyz/acme` and re-download the config at every restart, picking up new network upgrades as they come.
Then, in order to be ready for an upgrade, a testnet baker only needs to update their software (as they would with their mainnet baker). They would pick up the right network configuration at the subsequent restart. With Tenderbake, there can be no minor fork, so even people who do not update on time can still do it later and catch up.
But this effectively would move the testnet centralizing power out of the protocol and into the Octez node binary. In our view, the control of the testnet must ultimately be within the protocol rather than outside of it.
**Why not allow arbitrary modifications of context?**
Instead of a simple democracy bypass, a more elaborate proposal would consist of giving an admin the ability to arbitrarily edit the context, which would supercede this proposal: in addition to upgrading the protocol, the admin would have the ability to perform maintenance operations such as spam cleanup and native token creation. It is however significantly more complex than this proposal and is not being considered.
**Why bypass at the end of the voting period rather than the end of the cycle?**
This would be more invasive than the current proposal. A future permanent testnet would likely be launched with `rolls_per_cycle == rolls_per_voting_period` to eliminate this problem. If we do extend Ithacanet life and turn it into a permanent testnet, we can not do that. But, it will take at most 3.75 days to switch protocol, which allows us to follow mainnet closely enough.
**Is testnet governance disabled in this proposal?**
The regular governance mechanism still exists on testnets and may still be activated. Based on historical experience we do not anticipate this will happen.
**Does this proposal totally eliminate testnet restarts?**
No:
* in case of an upgrade to a protocol that does not finally make it to mainnet (i.e. due to a last minute protocol override caused by a bug fix), it may be more practical to restart the chain,
* changes to the protocol constants controlled by governance make the chain too dissimlar to mainnet,
* extensive changes to the governance process itself that may interfere with the bypass code or mandate its removal.
We estimate that, when implemented, this proposal will make testnet restarts less common, more in line with testnets seen in other blockchains. But it will not eliminate them.
## Security Considerations
Special care is taken in the implementation so that the "if not mainnet" logic does what it is supposed to do.
## Test Cases
## Implementations
## Copyright
Copyright and related rights waived via
[CC0](https://creativecommons.org/publicdomain/zero/1.0/).
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment