The renaming of ‘endorsements’ to ‘attestations’ is completed

The Nairobi protocol proposal started a process of renaming the endorsement and preendorsement consensus operations to, respectively, attestation and preattestation. This work, which also extended shell-side to Octez releases, is now complete with the Oxford protocol proposal and the release of Octez v18.0.

The renaming is due to the fact that a baker does not actually endorse a block as much as attest to its existence and validity, which the new terminology makes clear.

While most of these changes are internal, there are still some visible (and potentially breaking) changes for end-users and infrastructure providers. The new naming convention is used in the events, errors and logging infrastructure as well as in RPCs.

In order to reduce UX friction, Oxford and Octez v18.0 introduce a deprecation plan for the previous naming convention in the affected RPCs:

A new version argument allows the user to choose the naming convention for these operations:

  • version=0 denotes the legacy naming convention using (pre)endorsements.
  • version=1 denotes the new convention using (pre)attestations.

Octez v18.0 keeps version=0 as the default for these RPCs. However, future Octez versions will change the default to the new convention (version=1), and eventually remove support for the legacy convention.

As for the logging infrastructure, Octez v18.0 adopts the new convention for the Octez node and the Oxford baker and accuser.

To learn more about the deprecation process and the affected RPCs, see the new “Breaking changes” section of the Octez documentation:

As this project comes to an end, we want to thank all the community members who tested and provided feedback on this work to ensure seamless upstream compatibility with ecosystem tooling.

If you are unsure how these changes affect your Tezos applications, we invite you to test the new version=1 RPC naming convention – and don’t hesitate to reach out to us if you have further questions.