Important: revision 008_PtEdoTez of protocol Edo contains a bug that is corrected in the latest version 008_PtEdo2Zk
This page contains all the relevant information for protocol 008 Edo. Each of the main changes is briefly described with links to relevant external documentation and merge requests. There are dedicated sections for all the changes to RPCs and operations. The changelog section contains all the Merge Requests and instructions to regenerate the protocol sources from the Gitlab branch.
The code can be found in the Gitlab branch master or in the release
8.2 and its full hash is
As usual a testnet called Edonet will be available during the full lifetime of the protocol.
The main novelties in the Edo protocol are:
An implementation of Sapling, enabling privacy-preserving transactions
The notion of tickets, making it easier for developers to write secure and composable contracts
An extended Voting procedure with a 5th period, ensuring smoother protocol upgrades
Here is the complete list of changes:
Edo is the first protocol that relies on a new environment V1 which introduces the new cryptographic libraries that Edo relies on for its features. Because of this, in case of a positive vote, all nodes will have to be updated to a shell containing V1 in order to run Edo.
update to OCaml 4.09 standard library
update of all libraries, Tezos specific or not (e.g. Lwt)
addition of Keccak and SHA3
addition of BLS12-381
addition of PVSS
addition of lib_sapling
votes/current_period_kind when called on the last block of
a voting period has always returned the kind of the following period.
This behavior is partly due to the need of the client to know the next
period kind in order to prepare operations that are valid for it.
However it was often the source of confusion and for this reason
votes/current_period_kind is deprecated in favor of two additional
votes/current_periodwhich returns information on the voting period of the current block and
votes/successor_periodwhich returns information on the voting period of the successor block, which can be used by the client to forge operations for example.
<block_id>/metadata reflects the changes described later for the
It is advised to stop relying on deprecated fields and use the new ones.
<block_id>/helpers/current_level reflects the changes described
later for the encoding block_metadata, two fields becoming
It is advised to stop relying on the deprecated fields and use the new
dedicated RPCs (see voting).
<block_id>/helpers/baking_rights when querying for whole
cycles now returns priorities up to 8 instead of 64.
Furthermore it is now more efficient when querying for a restricted set
Two encodings changed in 008, some fields were deprecated in favor of some new fields. If your software relies on the deprecated fields it should remain compatible with 008, however it is strongly suggested to use the new ones as the deprecated will be removed in a future protocol. If your software parses the entire encodings then it is not compatible with 008 because of the new added fields.
You can always use the binary
tezos-codec for more details on each
encoding, binary or json.
This encoding is returned by the RPC
<block_id>/metadata and is
included in the receipts of block validation.
The following fields are deprecated:
in favor of
The voting procedure has an additional 5th period called “Adoption”, at the end of which it is already established that the voted proposal will be activated. This period requires no action and serves purely as buffer time for users to update their infrastructure to the new protocol.
The length of each period has been reduced from 8 cycles to 5 cycles. The total duration of the voting procedure goes from 32 cycles (~3 months) to 25 cycles (~2 months and 10 days).
The duration of the testchain is also reduced to 5 cycles to match the new duration of voting periods.
update_listings, which updates the voting weight of
each delegate, is now called also at the end of the testing period.
Voting periods now end at the last but one block of a cycle, instead at the end of a cycle.
Integration of the Sapling protocol into the Michelson language. More information can be found in the Sapling documentation page.
Tickets are a generic and composable mechanism for authenticating data from smart contracts, managing permissions, and representing assets. More information can be found in the Ticket documentation.
UPDATE 2*k+bto respectively build a comb pair of size
nstack elements, decompose a comb pair of size
nstack elements, access the
k-th element in a comb pair, replace the
k-th element in a comb pair.
Optimized notations for comb pair types and values.
FAILWITHrestricted to packable types
New hash functions: instructions
LEVELto query the level of the current block
TOTAL_VOTING_POWER) to query the voting power of a particular delegate (resp. of all delegates)
SELF; ADDRESSbut allowed in lambdas
The following changes are not visible to the users but reflect improvements of the codebase.
improvements to support the tool
unification of big maps and sapling states as lazy storage
representation for bigmaps with id and diff (for trace mode)
improvements to support the tool
bisect_ppxto compute code coverage
This is the full list of Merge Requests that compose 008.
Development of 008 is frozen in the branch proto-008.
The sources are contained in the directory
src/proto_alpha/lib_protocol, which is a rolling home for protocol
This directory is snapshotted each time a new proposal is prepared
using the following instructions:
$ ./scripts/snapshot_alpha.sh edo_008 $ ls src/proto_008_*