Update: 2020-09-07, the Tezos Core developers decided to move forward with a different set of changes for Delphi, so this article no longer refers to Tezos 007. It's likely, some of the features described here will become available in Tezos v008.

Note: 2020-08-11, corrected the privacy description on Sapling contracts.

At Blockwatch we started reviewing the upcoming Tezos protocol upgrade 007 (codename Delphi) and I would like to share a first round of insights from reading the code, the documentation and from talking to core developers.

The 007 upgrade is the biggest feature upgrade made on Tezos so far. This blog post is quite technical and written for engineers to help you understand the impact of upcoming changes.

There is no fixed time schedule, but my assumption is that a proposal for voting will be ready sometime in fall 2020 and if accepted by the network will go live in December 2020 or January 2021. Make sure you understand the amount of migration work and plan accordingly.

In our TzIndex blockchain indexer we deal with all the bits and pieces of each protocol, so we need to stay on top of all the changes ourselves. We encourage all wallets, exchanges and tooling providers to read this post, read the docs, experiment with Dalphanet, an early prototype of the new network, and integrate/test on top of the upcoming Delphinet to be prepared.

Metastate and Nomadic Labs have written about their rationale before and have explained some of the details in individual blog posts. Here is a list of posts I'm aware of: Sapling, BLS12-381 Curves, PVSS, New Michelson Opcodes, Delegation Toggle, Baking Accounts.

So let's jump right in. The top 3 topics this protocol upgrade will touch are

  • baker account management
  • zero-knowledge proofs
  • governance system extensions

Right now the new protocol is running in a pre-release testnet called Dalphanet. Apparently nobody wants to call it Delphi just yet, thats why the D-alpha-net gymnastic.

Protocol Hash PryLyZ8A11FXDr1tRE9zQ7Di6Y8zX48RfFCFpkjC8Pt9yCBLhtN 
Dalphanet ID  NetXyQaSHznzV1r

New Baker Accounts

For a long time, Tezos bakers have struggled with the inflexibility of the current system, especially when it comes to disabling public delegations or upgrading their private keys. 007 completely reworks how baker accounts are managed and luckily all the changes are fully transparent, i.e. backwards compatible, for bakers who use the Tezos CLI client or existing payout tools. For developers who maintain deeply integrated systems the story is different, but APIs may still change a bit in the next weeks.

So what's new? In 007 baker accounts are becoming multisig smart contracts which provides greater flexibility but also changes a lot of things under the hood. The most visible change is that implicit addresses (tz1/2/3 base58 prefix and a 21 byte binary encoding) will be replaced by contract addresses (SG1 base58 prefix and 22 byte binary encoding). Actually, bakers are reachable on multiple addresses going forward, the implicit tz1 address that belongs to the consensus key and at the same time the new SG1 address of the baker contract. Both addresses are supposed to be usable interchangeably. You probably already imagine where this is going. I already opened two issues to clarify the situation and avoid ambiguities.

The baker contract will manage a baker's state containing

  • the baker's balance
  • the replay protection counter
  • a consensus key (you can change it, but it takes 7 cycles to activate)
  • a list of owner keys (for multisig to control spending and voting)
  • a threshold (how many owner keys are required to sign an operation)
  • a delegation toggle switch
  • a PVSS key (will be used for new random numbers in v008+)

This also means anything a baker does beyond bake/endorse such as changing its state, spending funds, and voting on protocol upgrades becomes a multisig contract call with a new internal, so called baker operation. Michelson was extended with new types and opcodes to make all this possible inside a contract. Actually, all the existing operations, such as voting and spending, can still be authorized by the consensus key. This means the old way of sending baker operations still works for backwards compatibility purposes, so some of us have to support both ways.

The actual contract code for bakers is pre-defined and fixed right now. Bakers are no longer self-delegated, instead registration is done through a new operation baker_registration (tag 111) instead of an origination like for regular contracts. Re-activation of inactive bakers becomes a contract call. All the new baker functions also require sending a contract call. Existing bakers will automatically be migrated to contracts during the protocol upgrade, their funds including all frozen funds will move over into the contract.

The new baker contract provides the following entrypoints:

  • toggle_baker_delegations (bool) to toggle accepting new delegations on or off. When off, delegation and origination operations to this baker will fail with a descriptive error message.
  • set_baker_consensus_key (pubkey) Sets a new consensus key to be activated on the beginning of the seventh cycle from the current cycle. If there is a pending consensus key update for the given baker, it will be overridden and the activation cycle resets.
  • set_baker_active (bool), a replacement for reactivation by self-delegation.
  • set_baker_pvss_key (Pvss_secp256k1) Allows to set a new key to be used for the upcoming PVSS (Publicly Verifiable Secret Sharing) upgrade in v008.

Sapling and zero-knowledge proofs

The second biggest change in 007 and a long awaited feature is the introduction of transaction privacy through Sapling, a zero-knowledge proof technology originally introduced by ZCash. The way Tezos interacts with Sapling is through smart contracts, i.e. there are new Michelson types, new instructions, new transaction parameters sapling_transaction and a new storage type sapling_state which works similar to bigmaps.

All smart contracts that use Sapling to shield tez will use the same shielded pool which is great for privacy. Correction: actually there is one private shielded pool per Sapling smart contract – internally it works similar to bigmaps, so unless all wallets agree to use the same contract it's not as ideal for privacy. However, 007 is only the first step towards more privacy. It's tricky to stay private all the time since all interactions with shielded pools (shield, unshield, transfer) still require to send a cleartext transaction and pay fee from a source account which can be traced. It's up to wallets (and future protocol amendments) to develop best practices and a fool-proof UX.

Internally Sapling uses an UTXO model for tracking shielded coins. An outside observer like a block explorer will only see who shields/unshields tez (also when and how many) and who interacts with shielded tez in any of the contracts (also when and how often), but we will no longer see how many shielded tez are moved inside the pool and from whom to whom.

Wallets will need to scan/decrypt all shielded transactions to identify which UTXOs belong to local keys in order to show the most recent balance and a transaction history. Block explorers will be blind, unless users provide a viewing key.

Governance Changes

007 adds three major extensions to the Tezos governance system, but remember, these changes only apply to post-007 voting and only if 007 is accepted.

  1. Add a 5th Adoption period to provide more time for the ecosystem to upgrade after a promotion vote was accepted and before the new protocol activates.
  2. Delegators will be able to override their baker's votes using a new ballot_override operation (tag 112).
  3. Bakers and delegators will be able to split their voting power between yay, nay and pass.

The new Adoption voting period is an empty cool-down time with the same duration as any other period (8 cycles). It's supposed to give tooling vendors and service providers some extra time after the final decision to activate a new protocol has been made.

The vote splitting and override feature is still work in progress which means the actual implementation will change from what's available in the current release candidate. Stay tuned for updates from Tezos core devs about these new features.

Michelson Extensions

007 extends the Michelson language with new types and instructions to support the above features. Read here for a detailed overview.

New Michelson types

never               // parameter type to finalize entrypoint list, forbid extra branches
bls12_381_g1        // types for pairing equipped elliptic curve BLS12–381 elements
bls12_381_g2        //
bls12_381_fr        //
baker_hash          // SG1 baker address type
baker_operation     // internal baker operation type
pvss_key            // new PVSS key type
sapling_state       // new type for Sapling stored state
sapling_transaction // new type for Sapling state updates

New Michelson instructions

LEVEL                     // get current block level
SELF_ADDRESS              // calling contract address, may be used in lambdas
NEVER                     // implements a forbidden branch
UNPAIR                    // UNPAIR macro promoted to instruction to save gas
VOTING_POWER              // number of rolls for a baker at start of current voting period
TOTAL_VOTING_POWER        // network-wide number of rolls at start of current voting period
KECCAK                    // cryptographic hash Keccak256
SHA3                      // cryptographic hash Sha3
PAIRING_CHECK             // BLS12-318 curve point pairing check
SUBMIT_PROPOSALS          // create internal baker operation to submit proposals
SUBMIT_BALLOT             // create internal baker operation to submit ballot
SET_BAKER_ACTIVE          // activate an inactive baker
TOGGLE_BAKER_DELEGATIONS  // set baker delegation toggle switch
SET_BAKER_CONSENSUS_KEY   // schedule baker consensus key update
SET_BAKER_PVSS_KEY        // set new baker PVSS key
SAPLING_EMPTY_STATE       // create a new empty Sapling storage
SAPLING_VERIFY_UPDATE     // verify a sapling_transaction against current Sapling state

Besides the above, a new default entrypoint name main with tag 5 was added so that call parameters, specifically calls to the new baker contract, save some bytes.

Miscellaneous

A few other notable changes and extensions include

  • renamed field delegate to baker in freezer balance updates, endorsements
  • a new protocol constant max_anon_ops_per_block for unsigned/anonymous operations like seed nonces (this was called max_revelations_per_block before, but was not enforced)
  • a new protocol constant votes_per_roll to define vote splitting granularity
  • a new operation failing_noop (0x7 tag, signed, will never be executed but included in block receipts, no gas cost, no counter update)
  • a new RPC field lazy_storage_diff for Sapling state updates and bigmaps, big_map_diff is deprecated and will be removed later
  • balance updates in protocol migrations generate receipts in the first block of the new protocol now (identified by balance update kind migration)
  • many new error types, mainly for the new baker management
  • only a single denunciation per block level is allowed, so double baking/endorsing slashes can only happen once per level
  • since SG1 is of type contract it's necessary to introduce a new binary encoding for origination (tag 209) and delegation (tag 210) operations
  • work-in-progress: the new origination/delegation types are reflected in transaction receipts as origination_new and delegation_new, but strictly speaking this is not necessary because only the base58 encoded address has changed, so this may change
  • work-in-progress: a new gas cost model is currently designed, what will change is the unit for gas amounts reported in block receipts which will become milli-gas

Wrapping up

Dalphanet is an early prototype and a few issues are still in flux. The amount and depth of changes is considerable: the baker subsystem is completely rebuilt internally, with Sapling an entire new subsystem is added and the voting subsystem is extended. For the first time brand new operation types are introduced and for the second time binary encodings for operations are updated. Although interacting with baker accounts is supposed to be backwards compatible, I urge everybody to take a close look because there are subtle changes that may impact deep system integrations.

We still have to wait a few weeks for a second release candidate and for more documentation about all the new features. My gut feeling is that a proposal will not be ready before October, but that's actually a positive. Right now it's also unclear if we will see different feature sets as independent proposals. There are at least no cross-cutting dependencies, so all the three subsystems could be upgraded independently.

I'm extremely happy the Tezos core devs put up a dedicated pre-release testnet this time. While integrating support for some of the new features in our Tezos indexer and block explorer I found a few inconsistencies which were acknowledged and fixed next day. This is very professional and I truly enjoy working in such an innovative environment.

If you have questions about this article or Tezos 007 in general feel free to reach out to me on Twitter or Discord.