CHIP-0061: Remote compact VDF proofs

[danieljperry]

Note

Low Risk
Documentation-only addition of a draft CHIP; no runtime or consensus code changes in this PR.

Overview
Introduces CHIP-0061 as a new Draft informational CHIP in CHIPs/chip-0061.md.

The document specifies an optional full node optimization: fetch pre-compacted challenge-chain VDF witnesses from static HTTP compactvdf JSONL archives (10k-height chunks), apply them to blocks before pre_validate_block, and persist compactified bytes—without changing consensus or header_hash. It defines config (remote_compact_vdf_base_url), file schema, lookup/apply rules, integration hooks (add_block, batch sync), is_fully_compactified persistence guidance, and optional no-op of P2P compact VDF gossip when using the remote path exclusively.

Also covers backwards compatibility, security (untrusted publisher; validation still required), a reference-implementation module map for chia-blockchain, and a test plan.

^{Reviewed by Cursor Bugbot for commit 4ce1433. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 4ce1433. Configure here.}

[cursor]

sub_slot_index ignores field_vdf

Medium Severity

The lookup steps use sub_slot_index whenever it is present, but elsewhere sub_slot_index applies only to CC_EOS / ICC_EOS and should be omitted for CC_SP / CC_IP. A CC_SP or CC_IP line that includes sub_slot_index can resolve the wrong vdf_info, mutate the in-memory block before validation, and cause pre_validate_block to fail on an otherwise valid block during sync.

 

^{Reviewed by Cursor Bugbot for commit 4ce1433. Configure here.}

[danieljperry]

CHIP-61 is now a Draft. It specifies an optional full node optimization that:

• downloads compact VDF proof data from static HTTP files
• applies the proofs to incoming blocks before header validation, and
• persists the compactified block bytes

Please leave your reviews here, and feel free to discuss it in the #chips channel of our Discord.

[Ealrann]

Hello,

One question: will Wesoforge be able to publish the new compressed proof to https://www.xchos.com/vdfs somehow?

Now, In my opinion, we should rather improve the gossip algorithm somehow, it would respect more the p2p philosophy and at least all the network would eventually be updated. For example, maybe the nodes should actively ask they neighbors, sometime, "do you have the compressed proofs X, Y, Z... ?".

[danieljperry]

@wjblanke see above question

[wjblanke]

https://www.xchos.com/vdfs is just for the proof of concept. BTW all the compact vdf proofs there were harvested from the Chia DB torrent and were mostly done by Wesoforge.

Wesoforge is the main effort for creating compact vdfs and is a centralized service, so my hope is that Wesoforge would dovetail neatly into this CHIP, either by publishing the compact vdfs directly to a known URL for the CHIP to process (instead of xchos) or forwarding those compact vdfs to a different server run by another entity to vend. All compact VDFs are validated by the client as per the CHIP so I don't think its a problem to include an outside URL as a default--there is no trust implied.

[Ealrann]

Ok, I can publish our compact proofs in the same format, e.g. https://weso.forgeros.fr/vdfs

Two concerns with the current design of CHIP-61:

1. The remote path can only help catch-up, never the live tip. A compact witness takes minutes of VDF recomputation, so it never exists yet when the block is ingested at the tip. The remote path only ever helps catch-up sync.
2. Disabling the P2P handlers removes the only channel for post-sync compaction. Combined with (1), a synced node accumulates uncompacted blocks forever.

Suggestion: keep remote fetch for batch sync (older blocks), keep the P2P handlers enabled for the live tail, and add a slow background task that retroactively fetch compact blocks stored in the archive. That way every node converges to near-full compression, without making normal operation depend on an HTTP endpoint.

[danieljperry]

@wjblanke See above review.

[wjblanke]

Yes, if a node no longer needs to long sync, it is gathering uncompacted proofs.

Another option: the tool in the repo can fully compact offline DBs. That is another way to bring an older node's DB completely up to date with all compact proofs.