support a new version of FullBlock serialization

[arvidn]

where the block generator is just a buffer.

This must be combined with a check in chia-blockchain that version == 1 iff the hard-fork has activated.

---

Note

High Risk
Changes consensus-relevant block serialization and parsing; v1 must be gated by hard-fork checks in chia-blockchain (not in this PR) to avoid accepting invalid blocks on the network.

Overview
Adds a versioned FullBlock wire format so post–hard-fork blocks can carry the transaction generator as raw length-prefixed bytes instead of a CLVM Program plus transactions_generator_ref_list.

FullBlock drops the derived #[streamable] impl in favor of a manual Streamable implementation. Version 0 keeps the legacy tail: optional Program generator and ref_list. Version 1 encodes the format in the optional prefix byte (bit 0b10, same pattern as ProofOfSpace): no ref list on the wire; optional generator is Bytes-style (4-byte length + payload) stored in new transactions_generator_buffer, with in-memory version driving encode/decode. Invalid versions return Error::InvalidFullBlock.

The Python surface (chia_rs.pyi) gains transactions_generator_buffer and version. Rust unit tests and a new tests/test_full_block.py cover round-trips, prefix-byte encoding, and v1 omitting the ref list.

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

[coveralls-official]

Coverage Report for CI Build 27024420785

Coverage increased (+0.6%) to 81.583%

Details

• Coverage increased (+0.6%) from the base build.
• Patch coverage: 29 uncovered changes across 1 file (267 of 296 lines covered, 90.2%).
• No coverage regressions found.

Uncovered Changes

File	Changed	Covered	%
crates/chia-protocol/src/fullblock.rs	296	267	90.2%

Coverage Regressions

No coverage regressions found.

---

Coverage Stats

Relevant Lines:	18879
Covered Lines:	15402
Line Coverage:	81.58%
Coverage Strength:	11957095.23 hits per line

---

💛 - Coveralls

[arvidn]

@cursor review

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 3932f65. Configure here.}

[richardkiss]

This seems reasonable. It's a bit sad that we have to write the code that was previously auto-generated. A way around it would be to extend the macros to allow enum variants with data; or generalize Option to be trinary : Option3<None, Type1, Type2>. Since we're doing this in ProofOfSpace already. But maybe it's overkill.

[arvidn]

I experimented with extending the macros, and also implementing this at the python boundary, but this ended up being far simpler. It's unfortunate that we have to manually implement this trait, but at least it's easy to review and understand what it's doing (compared to the alternatives I tested with ProofOfSpace)

[arvidn]

rebased over type-stub conflict. unchanged otherwise

[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.}

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

[richardkiss]

I experimented with extending the macros, and also implementing this at the python boundary, but this ended up being far simpler. It's unfortunate that we have to manually implement this trait, but at least it's easy to review and understand what it's doing (compared to the alternatives I tested with ProofOfSpace)

I was trying understand why this would be. Take a look at #1463 What am I missing?

[arvidn]

I experimented with extending the macros, and also implementing this at the python boundary, but this ended up being far simpler. It's unfortunate that we have to manually implement this trait, but at least it's easy to review and understand what it's doing (compared to the alternatives I tested with ProofOfSpace)

I was trying understand why this would be. Take a look at #1463 What am I missing?

I don't think it's obvious that this is a simpler solution.

1. Option3<> doesn't generalize that well. It would be cumbersome to use in ProofOfSpace for instance, where there are more fields that differ, so both Some1() and Some2() would need to be tuples.

2. You lose named fields on the rust side. I think the ideal, pure rust, implementation would use specific enums for each case.

3. I think you may have problems with the JSON interface. I believe it derives the json fields from the rust field names.