← CIP-0049 · citation graph
CITATIONS / CIP-0049
Incentivizing Cold Backups for Super Validators to Enhance Network Resilience · status: Proposed
Every place across CCPEDIA's corpus that references CIP-0049 — sibling CIPs, forum threads, the cip-* / grants-* mailing lists, GitHub issues + PRs across all indexed Canton repos, third-party blog coverage, and YouTube transcripts. Each section samples the most recent N; counts above the sample are the totals.
Mailing-list messages · 25 · across 1 thread
Messages on cip-vote, cip-discuss, grants-discuss, and other validator-announce lists. Items with cip_id_match badge come from CCPEDIA-parsed mailing_messages.cip_id — only-here join.
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 nee
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 LevelD
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 t
Good point. We would only need 2/3 of the SVs who are actually storing backups to accept the answer, right?
I don't want to make it too complicated, but there are "proof of storage" systems for e.g. filecoin, which I believe solve this problem. I'd be happy to look into this further if there is interest. On
Thanks Vinh, At a high level, that makes perfect sense and I've been toying around with the same idea in my mind over the last few days. One thing I currently do not have an answer for, which might be
Hi Itail, I think we need to develop a backup prover. The prover can be run by any SV. Periodically the prover will raise a challenge to ask among its peers for some pieces of data. The prover will ne
Chris, thanks for following up. I'm OK with caps, just don't know how much it changes the mechanism of minting/distributing tokens. If it's "minimal invasion" then I probably favour this one as well.
Not to distract the conversation, but wanted to close the loop re: being more precise on the weight changes associated with this. In short, I’m ok with focusing on the technical implementation details
> Can you please elaborate on this? My understanding is that we can query specific data timestamps. From a live system we can definitely query specific data timestamps. But here we're talking about da
Can you please elaborate on this? My understanding is that we can query specific data timestamps. thanks.
Hi Chris, this is great news, happy to have proof group as a sponsor!
Yiannis, Proof Group is a fan of your proposal here and will definitely support in running a backup node. I think the increased SV weighting works well to incentivize this. We would be happy to sponso
> random comparison of data between the backups That would require that the backups are taken at the same time, wouldn't it? Otherwise the backups that different SVs have will not be identical. Not su
Ok so based on the feedback from @stanislav and @moritz we agree that the verification should be in the form or random comparison of data between the backups, instead of full restore and validation of
Hi, I don't think the catchup option works for old backups unfortunately. SVs can only catch up iff they are within the cometbft and sequencer pruning interval of 30 days. So for the main goal here of
Yiannis, This could've been an option however there are some challenges: 1) there should be a way to restore data from the network inception till one month before current time without gaps 2) catching
Chris, you are right - this is very ambiguous and I realised that It's not complete. The idea was to have a relative bonus model of 20% with a cap of +1 in the weight, whatever is smaller. No validato
While some of the technical details are discussed I wanted to also raise a tokenomics questions. This line from the CIP could use some additional detail. >> Super Validators that maintain and verifiab
A regular process for DR testing like how the Fia does it might be useful. https://www.fia.org/fia/fia-disaster-recovery-exercise. From: cip-discuss@... on behalf of Eric Saraniecki via lists.sync.glo
Good point. I believe "Cold" should not be used there since it's confusing. Just backups that are recoverable. On how often, it has to do with the recovery and verification mechanism as well as I resp
Eric, I’m really open to any ideas here because the size of the network is massive and it's growing fast. In my mind, the simplest and probably quickest way to do it is to have a SV node operating as
Could we also define what we mean by cold? Are we talking about fully air gapped cold storage? Same question as Eric – how often? Is there a forum to discuss this CIP? Kinga Z. Bosse COO|MPCH|www.mpch
how will an SV prove they are actually maintaining backups the way this process would design / prescribe ? will there be some regularly ceremony (quarterly?) where a prod parallel instance is stood up
Hello, Please find the cip-0049 open for discussion at the PR https://github.com/global-synchronizer-foundation/cips/pull/31 In ord …
GitHub items · 2
Issues, PRs, and dev-fund proposals across all indexed Canton repositories that mention CIP-0049.
For AI agents
Same citation graph through programmatic surfaces:
get_cip_citations— MCP tool. Input:{cip_id}. Output: counts plus sample items per source. Use when an agent needs "everything that references CIP-X across CCPEDIA's corpus" in one round-trip.GET /api/v1/cips/0049/citations— JSON shape mirroring this page.- The legacy
/api/v1/cips/0049/mentionsstays for backward compat — it returns topic / thread counts; this new endpoint returns per-post / per-message granularity plus GitHub and YouTube coverage.
