This is a joint post from TriliTech, Nomadic Labs, Marigold, Oxhead Alpha, Tarides, DaiLambda, Functori & Tweag.
We are happy to announce Ithaca 2, a revised version of Ithaca that contains an important performance improvement of metadata RPCs.
(As is usual, Ithaca 2’s “true name” is its hash, which is Psithaca2MLRFYargivpo7YvUr7wUDqyxrdhC5CQq78mRvimz6A.)
Ithaca 2’s sole difference with Ithaca is the deprecation of a redundant field in an error message. When the interpretation of the Michelson script of a smart contract results in a runtime error, the script code will not be passed anymore to the error message. This will save a lot of space because the script is typically large and is duplicated in each error message - i.e. each time the smart contract will be called and its execution results in a runtime error. Furthermore, the script code can already be fetched from the contract address, so there is no need to record this information again. Storing script code in the block metadata is an anomalous behavior and the deprecation of this redundant field will result in an important reduction of disk usage.
Other features of Ithaca 2 are contained in Ithaca and we refer to our previous announcement.
We also encourage you to look at the changelog for a full description of the contents of the proposal.
As it was the case with Ithaca, testing is critical. A testnet for the Ithaca 2 protocol will launch in the coming days. It is critical to have as many bakers as possible participating in this testnet, by running nodes, producing blocks and deploying apps. We are looking for more bootstrap bakers to participate from day one. If you are interested, please join the baking slack and make yourselves known in the #test-networks channel.
Once more, we strongly encourage you to test your own Tezos-based applications to check for compatibility problems. Ithaca 2, and the configuration for its test network, will be included in the next release candidate of Octez version 12.
Similarly to Ithaca, should the Ithaca 2 protocol proposal be accepted by the community, the following minimal version of Tezos node (shell) software will be necessary to participate in the consensus, due to necessary changes introduced to the protocol environment: v12 of Octez, or v2 of TezEdge.