Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[WIP] Relative Kernels #19
A few days ago while pondering relative kernels, I thought it might be useful to introduce reference kernels. A relative kernel would only be able to refer to a reference kernel. Which would require a slightly higher fee. That means there would be much fewer kernels to refer to, which would reduce resource usage of the necessary indexing data structures.
But then I realized such a distinction on kernel types is a privacy leak, so I scrapped the idea...
Anyway, thought I'd write it down for future reference:-)
It only needs 8 bytes, namely the leaf or full index of the reference kernel in the kernel MMR.
We could allow the broadcasted tx to have the full 32 byte reference kernel, and let the miners convert it to an 8 byte index. But normally you would only broadcast such a tx if you see the references kernel being confirmed, so it may be simpler to require the broadcaster to set the index. Then only the slate would have the 32 byte reference kernel.
Yes. We have discussed this before I think? And then I forgot about it...
Agreed. I think this is the conclusion we came to previously. The parties transacting (via a slate) would require the full excess commitment. But once the tx is built and ready to broadcast we can translate these to the more compact MMR indices.
The kernel excess would be required when verifying the signature, but verifiers can quickly lookup the excess based via the provided MMR index.
The one edge-case here that we need to think through. If we do support a height of 0 for a relative lock height then we can potentially build a tx that references a kernel that does not yet exist in the MMR, it will be added in the same block as the new tx. In this situation we would not yet have a MMR index for the referenced kernel. Maybe we do not allow this and the relative height must be non-zero?
If we do allow relative height of 0 then we would potentially also need to handle the case where
The big benefit of requiring relative height to be non-zero is the fact that a referenced kernel must have a lower MMR index than the kernel referencing it. This would not always be the case for two txs within the same block as no guarantees are made about the order of kernels within a block.
The other complexity here is how to deal with forks and reorgs if we are passing the MMR index as part of the tx (and not the referenced kernel excess).
So we may need to reference kernels by the excess commitment up to the point where they are actually added to a block (by the miner).
Yes. I remember some of the earlier conversations now (one reason why we should be documenting these proposals as RFCs...) As long as txs are re-orderable (i.e. before inclusion in a block) we need to explicitly reference the excess commitment itself.
And we do need to be careful with handling reorgs and forks from the perspective of the txpool as a reorg can order previously accepted txs differently - txs with relative lock heights can re-enter the txpool and we need to revalidate the lock height criteria carefully.
In the top comment I wrote:
After more careful thought, there is another resource we should be more concerned about.
BUT this approach would be severely handicapped by kernels that can freely reference older kernels.
It may therefore be wise to limit the relative height to that same horizon.
Actually, I find 2 days to be a little short, and would prefer to change STATE_SYNC_THRESHOLD to match CUT_THROUGH_HORIZON, i.e. one week.
Can anyone think of a use case of relative kernels where one week would be considered insufficient?
Ignoring specifics around STARKs for a second - it sounds like the issue could be restated to -
Do we want to allow arbitrary relative heights between relative kernels and the kernels they reference? And if we want to limit this to a shorter period what should the limit be?
Intuitively it makes sense to have some kind of limit and not simply allow arbitrary relative heights here.
Some follow up questions -
I would argue that we do.
I think a week is quite reasonable. With payment channels, monitoring the chain for illicit close transactions is a minimal burden with a 1 week window. I suspect very few people would want to wait longer than a week to reclaim funds from a channel closure. Most will probably set it shorter.
Yes, a graph-rate majority of miners can enforce shorter limits, by considering longer limits invalid.
That is indeed a hard-fork, as all nodes would need to upgrade to accept the longer limits.