Variable Size Kernels

[antiochp]

Rendered link to RFC document
Tracking issue: mimblewimble/grin#3038

This is a pre-requisite for "relative kernels" as we need to be able to introduce new kernel feature variants, with additional associated data.

The proposal is to support kernels of variable size, with each kernel variant supporting additional data specific to the variant. Height locked kernels have an associated lock height for example.

[lehnberg]

In accordance with our RFC process, as of today this can be considered in Final Comment Period with a disposition of merge

[lehnberg]

The Final Comment Period is due to expire for this RFC tomorrow. The proposal will then be merged and considered accepted unless there is a strong case made against it.

[jaspervdm]

This might be a stupid question, but do block headers commit to the full kernels that are contained in the block?

• If yes: does this versioning affect this? I.e. if i convert the kernels inside a block from protocol v1 to v2, will it invalidate the PoW?
• If no: what does it commit to, the excess only? Wouldn't that make kernels malleable to some extent? Maybe this is not a big deal because creating a kernel with the same public excess but different features requires knowledge of the excess, so only the original creators could do it.

[DavidBurkett]

This might be a stupid question, but do block headers commit to the full kernels that are contained in the block?

• If yes: does this versioning affect this? I.e. if i convert the kernels inside a block from protocol v1 to v2, will it invalidate the PoW?
• If no: what does it commit to, the excess only? Wouldn't that make kernels malleable to some extent? Maybe this is not a big deal because creating a kernel with the same public excess but different features requires knowledge of the excess, so only the original creators could do it.

No, block headers just commit to the excess, MMR roots, and MMR sizes. Kernels aren't malleable because changing them would change the MMR root

[antiochp]

do block headers commit to the full kernels that are contained in the block?

Headers commit to the kernel MMR root. Which in turn commits to the hashes (and positions) of all the kernels contained in the kernel MMR.

So headers don't commit to the full kernels contained in the block directly.
But they do commit to all kernel hashes in the kernel MMR in its entirety (which includes the kernels in the block in question).

tl;dr not the full kernels in the block, but the kernel hashes in all blocks

Kernel hashes currently are based on the full kernels (even for 0 fee on coinbase kernels etc). And we need to be careful to preserve this for historical data even when moving to future protocol versions.

[quentinlesceller]

👍. Minors formatting and typo comments.

[lehnberg]

🎉 Wohooo! This RFC has now been merged! 🤸‍♀️
Tracking issue: mimblewimble/grin#3038