Upgrade Your Node Before the Ceramic Hard Fork on February 21, 2023

Ceramic’s first hard fork will take place on February 21, 2023.

All Ceramic nodes operating on Ceramic mainnet must upgrade to (at least) version 2.18.0 of the @ceramicnetwork/cli package by February 21, 2023.

The ‘HistorySync release’ will result in changes to Ceramic’s anchoring system, this work will enable the upcoming release of ComposeDB. These changes will allow nodes to discover and sync existing data, for a given data model, from other nodes on the network.

Nodes that do not upgrade by February 21st will no longer verify anchor commits from the network, which will lead to the corruption and loss of all writes due to CACAO timeout errors. If you are operating a Ceramic mainnet node, please let us know if you have any concerns about upgrading on the forum.

Protocol Changes

Two main changes will affect how anchoring (time-stamping) works:

1. There will no longer be simple, or regular, transactions to put Merkle tree roots onto Ethereum. Instead, an anchor smart contract will call an “anchor” function resulting in an “anchor event” that Ethereum RPC clients can subscribe to. This will make it easier for Ceramic nodes to discover when anchors happen and to sync the history of anchor events.
2. The second change is designed to make the system more resilient to block reorgs on Ethereum. Ceramic anchor commits will no longer include the specific blockNumber and blockTimestamp that the anchor event was included in, as it’s possible the transaction could later be reorged into a new block. Instead, Ceramic will only use the transaction hash and will look up which blockNumber the transaction was included in from Ethereum directly.

Both of these updates require changes to the js-ceramic node implementation, so that the node can still know how to verify and apply anchor commits with the new behavior. Nodes that haven’t upgraded will experience failures when applying anchor commits. Data update commits that are not anchored within the CACAO timeout period will then fail to apply since the node will not be able to verify that the update was created during the time when the CACAO (the capability that gave the app permission to write into the stream on behalf of the user) was valid. Over time this can corrupt the state of streams and invalidate writes that seemed to be applied successfully at first, but then are later invalidated when CACAO times out.

Please get in touch with us on the forum for assistance or if you have any other questions!