You want to store the time directly
My issue with this is: What if in the future other comparable needs emerge that need other header data? Why restricting our-self to the timestamp?
For example for ickb/v1-bot performing a dao withdrawal request transaction, it would be nice knowing that the 180 epochs has already passed or not.
I think we do need to store the header hash in
data to verify linkage between the blocks, so there are 2 fields,
Sure, if I’m able to tell the aggregator that it needs to include prevHeaderHash (so h-2) in the headerDeps, my script should still be able to compute the required information to understand if 180 epochs has already passed or not
- script loads entire header through header_deps for block h-1
- verifies that prevHeader (header h-2) value in data matches prevHeader value loaded in header_deps
- stores new header hash and time value in cell
A few considerations:
- The idea you propose is a trust-less oracle. It could work even without a consensus change with a signature based oracle, but in this case the special cell users would need to trust the cell creator.
- Without a consensus change, it cannot be proven (feel free to show me wrong) that it is actually loading the header of block h-1, it is just loading a header which happens to be the header of the block after the one notarized in the previous cell. Maybe the previous notarized cell is a few epochs old…
- With the Script Verification you proposed this consensus change is a breaking change. After the consensus change, no block without this special cell can be mined as it would either break the script chain of verification or lead to load older timestamps.
- The verification can be accomplished without checking anything in the script and fully relying on the consensus rules to check the changes to this cell. Not saying it’s an improvement, just it’s a possibility.
if we only store the hash, each script will need to present the preimage to verify the time is correct.
Can you explain a bit more this point?
I’m a bit conflicted about storing this kind of transient information into a cell.
On one side, it’s a great idea because:
- Once a special cell is consumed, any transaction referencing it is invalid, sooo mission accomplished
On the other, traditional L1 transactions are kind of left into the dust as they would need to:
Get super fast this cell (from the miner packing the block? )
Pack super fast a transaction referencing it
Send it super fast so that it get included in the current block or ends up invalid
Then again, how would a script be able to reference this Cell Dep?
Looking at ckb-std functions, I see no method able to directly fetch the data from this special cell as all functions depends on the index of the cell.
The only ways I see to do it would be either:
Iterate over all Cell Deps and find the one whose Type Script matches the special cell type script (this can be wrapped into a utility function of course)
Put the special cell in a conventional position of Cell Deps (first, last…) and directly load that one.
As you see, this issue is very similar to issue with the solution I was proposing yesterday, a similar but different solution which basically boils down to the following:
Script flags itself as wanting to access the tip header (h-1), this could be done by reserving one bit in Script Type. Think of (“Type”, “Data”, “Data1”, “Data2” …) x (“Not access tip Header”, “Access tip header”), so it’s backward compatible.
The consensus rejects the transaction if tip header is not included in header deps.
To get the tip header in a script, either the script know already which is the tip header at construction time or it’s in a conventional position or iterates thru all Header Deps and gets the one with maximum block number.
Another competing idea to play with the
Off-chain determinism TxPool Optimization is to introduce a transaction expiration. A cell in a transaction can readily specify a since epoch, so an epoch before which is invalid. What if additionally we could specify an expiration epoch, so an epoch after which is invalid?
Closing this reply, the solution you propose is great as it fits with the L1 model and it doesn’t create issues, but since changing the consensus is on the table, I’d like for all possibilities to be explored and then choose the best