CIP-0049: Incentivizing Cold Backups for Super Validators to Enhance Network Resilience

Abstract

This proposal calls for a network-wide adoption of a formal backup and backup verification method of the network. The goal is to incentivise Super Validator nodes to maintain full, cold backups of the network’s historical state—from the network’s inception to the present. By ensuring these offline backups, the Canton Network will bolster its resilience, uphold decentralization, and guarantee data immutability. In return, nodes that comply will receive enhanced rewards (an extra bonus of approximately 20–30%, or a +1 weight adjustment on their existing reward scheme). Additionally, this proposal highlights the need for a future standardized backup procedure and a formal verification mechanism to ensure that claimed backups are complete and secure.

Specification

Backup Requirement:

A minimum of 60% of Super Validator nodes shall keep full cold backups of the network’s ledger and state data, covering all historical data since the network’s launch.
Backups must be stored in secure, tamper-resistant cold storage environments to prevent unauthorized access or network-based attacks.

Incentive Structure:

Super Validators that maintain and verifiably prove the integrity of their backups will receive an enhanced reward, equivalent to an approximate bonus of 20–30% (in Canton terms, a +1 weight boost on current rewards).

Backup Standardization Process (To Be Discussed):

Itai Segall

Apr 15, 2025

Thanks Vinh,

There are still many questions in my mind that need to be answered. Just to name a few:

- How storage-efficient is this format of backup? Sounds like it cannot be very succinct, if it needs to support sql-like querying. So what's the expected cost of maintaining all these backups in this format for eternity?

- Does this mean that every SV needs to implement their own export, given that cloud providers do not support an export of this format? CloudSQL supports only pg_dump format for example

- How is this verification step planned to be carried out, in practice? Manually? By whom? Automatically? By what service and how?

Best

Itai

toggle quoted message Show quoted text

Show quoted message

On Tue, Apr 15, 2025 at 2:54 AM Vinh Nguyen via lists.sync.global <v=fivenorth.io@...> wrote:

As discussed in the last weekly ops meeting, I would like to share a few approaches to bring this up for discussion again.

In the new CometBFT we are going to use Postgres as storage instead of LevelDB so we can focus all the effort on proving Postgres data. If we do need to perform that, LevelDB is actually quite easy to prove because they are just key<-> values with limited functionality and can easily restore a snapshot and mount. Backup tooling like `restic snapshot` even allow to mount a snapshot and we can read the leveldb file with any client example https://github.com/liderman/leveldb-cli/blob/master/main.go

For Postgres, the primary challenge is access postgres backup data in a timely manner without restoring it into a real database.

There are however many modern Postgres tools that allow us to export Postgres data as CSV or Parquet file to object storage and allow us to query these directly using SQL interfaces without the need to restore the data to a Postgres instance.

The process is very similar to a full pg_dump, but instead of exporting to CSV/SQL or custom format, we export the data to Parquet files, and the file can be stored on object storage like S3/GCS.

Example tooling: https://github.com/CrunchyData/pg_parquet/ https://bnmoch3.org/notes/2025/postgres-iceberg-sync-duckdb/

These parquet files can then be query directly using SQL with tool such as AWS Athena(https://docs.aws.amazon.com/athena/latest/ug/columnar-storage.html), Druio, DuckDB(https://duckdb.org/docs/stable/guides/network_cloud_storage/s3_import.html)

We then can write a service that performs SQL queries to verify data consistency between the backup. If we take backup daily, we will need to craft a query that has not been modified in say the last 24 hours, then no matter when a backup was taken, as long as it's in the 24 hours window, the backup is correct and will be consistent across all SV.

Example, today is 2025-04-15. We can ask "give me a list of transfers between 2025-04-13 -> 2025-04-14. Then no matter when the backup is taken on 2025-04-15, the data will be consistent.

Let me know if this idea is sound and we can expand further into some real http service that can perform this kind of query.

On Wed, Mar 19, 2025 at 9:31 AM Yiannis Varelas <y@...> wrote:
Hi all - just bringing this up again since we have now gone through the devnet reset.

@Wayne I believe 2/3 is what we need yes.

@Ryan this is an excellent idea. Had a look at filecoin and seems that they spin out

a business that does exactly that.

https://destor.com/solutions/backup

Might worth looking into this as a complete solution.

Itai Segall

Director of Engineering, Canton Network / +1 551 208 8835

Digital Asset, creators of Daml

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Incentivizing Cold Backups for Super Validators to Enhance Network Resilience

Abstract

Specification

Discussion

Leave a reply

Motivation

Rationale

Backwards Compatibility

Reference Implementation

Copyright

Changelog