relative lock height optimization (reference kernel MMR pos)

[antiochp]

For relative lock height kernels I think there is pretty nice optimization that we can make once txs are confirmed and on-chain.

Relative kernels - k2 references k1 with a relative lock height of 100, for example.
i.e. k2 will only be accepted 100 blocks later than k1.

We can do this with a combination of two pieces of information -

kernels have a known position in the kernel MMR
each block header commits to the current kernel MMR size
Our plan was to include the referenced kernel commitment in the subsequent kernel.
i.e. k2 would reference the excess commitment for k1

This provides a lot of flexibility for txs that are not yet confirmed.
i.e. The tx containing k2 can be built ahead of time, before the tx containing k1 is confirmed.
They can be built at the same time. This is useful for things like refund txs in payment channels.

The downside is we need to store an additional 33 bytes for the referenced kernel commitment.

But I think we can optimize this once txs are confirmed and on-chain.

Recall that this works because kernels have a known fixed position in the kernel MMR.
We can simply reference prior kernels by their MMR position.

k2 would reference k1, not by its excess commitment but by its position in the kernel MMR.
k2 must be confirmed and on-chain for k1 to be accepted, so it will have a corresponding MMR position.

To verify the kernel signature (for relative lock height kernels) we can simply retrieve the excess commitment
based on kernel MMR position and reconstruct the message for the signature that way.

So relative lock height kernels need to maintain the full referenced excess commitment when in transaction form.
But once they are included in blocks and subsequently included in the full chain state we can replace these commitments
with simple MMR positions. This is 8 bytes instead of the full 33 byte commitment.

[garyyu]

@antiochp Nice to have this 33 bytes commitment replaced by 8 bytes MMR position 👍

• One question about:

Once they are included in blocks and subsequently included in the full chain state we can replace these commitments with simple MMR positions.

Is this safe for reorg/fork?

• And another question, I see we have a lot of 8 bytes uint64 on the chain data including the block header, including this one. May I suggest to use Variable Length Integer for these uint16 data type? to save transaction & chain data. One usable crate is https://docs.rs/varuint/0.6.0/varuint

[antiochp]

Is this safe for reorg/fork?

Yes. In a reorg all affected blocks would need to be rebuilt and we would need to recalculate the MMR positions based on the revised blocks. The reorg blocks would be built from txs in the tx pool (or reorg cache) and would be based on excess commitments, not the optimized MMR positions.

May I suggest to use Variable Length Integer

This may be something we want to investigate further but would impact a lot of the assumptions made around fixed size data.