feat: add spec for publically verifiable timestamps for UCANs with drand #27
Conversation
alanshaw
changed the title
alanshaw
requested review from
Gozala,
gobengo,
hugomrdias,
mikeal,
olizilla,
vasco-santos and
yusefnapora
|
|
||
| 1. Issuers **may** include the "chain hash" of the drand randomness chain in the [`nb`](https://github.com/ucan-wg/spec#241-nb-non-normative-fields) field. | ||
|
|
||
| The chain hash uniquely identifies the drand chain the randomness value was taken from, if it is different from the mainnet chain operated by the League of Entropy. If omitted, it is assumed to be `8990e7a9aaed2ffed73dbd7092123d6f289930540d7651336225dc172e51b2ce`. |
There was a problem hiding this comment.
I am not sure the above "chain" can be reasonably assumed to be "LoE mainnet"
@yiannisbot @jsoares can you chime in?
There was a problem hiding this comment.
According to https://api.drand.sh/info hash, is the chain hash and also this is the only chain right now according to https://api.drand.sh/chains.
Maybe I should just call it the default/original?
There was a problem hiding this comment.
That is, indeed, the LoE mainnet chain. However, note that the new high-frequency "chain" (not actually a chain) is planned to go live on 22 February. While there's no schedule for Filecoin consensus to transition to the new chain or for the old chain to be deprecated, that will eventually happen (I'd imagine the former in late '23 and the latter in '24, but I don't speak for the drand, Filecoin, or LoE). Plus, the new chain gives you higher resolution, in case that seems useful.
tl;dr: depending on the timeline, you may or may not want to replace this with the new chain id
There was a problem hiding this comment.
As @jsoares says this chainhash is the LoE mainnet one and will continue to be valid until at least the end of 2023. We expect that Filecoin will switch to the new drand network (and chain hash) within the next couple of quarters. We'll make announcements and we'll have a docs page with references to the chain hashes in existence.
@alanshaw how easy will it be to change the hash to the new one we'll have next week? The new network setup has been postponed to March 1st, so we can provide the new chain hash shortly. We expect that this new one will be longer-lasting than the existing one.
| 1. Issuers **should** include the drand randomness _round number_ in the [`nb`](https://github.com/ucan-wg/spec#241-nb-non-normative-fields) field. | ||
|
|
||
| If included, the round number **must** correspond to the randomness value in the `nnc` field. This field is **required** for ["unchained" drand randomness chains](https://drand.love/blog/2022/02/21/multi-frequency-support-and-timelock-encryption-capabilities/#unchained-randomness-timed-encryption). |
There was a problem hiding this comment.
If it is optional, I would move forward not including it for now. We can just spec as "should" and not implement I guess, but I would favour keeping things less complex until there is a reason where we would want to use "unchained" drand randomness chains
|
|
||
| By including a drand randomness round in a signed UCAN, anyone can prove that it was created _on_ or _after_ that randomness round was generated. There’s a number of uses for this, an example is allowing the web3.storage service to account for `store/add` invocations, publicly proving that we were asked to store data within a given time frame. | ||
|
|
||
| Services may choose to reject UCANs with timestamps that do not correspond to a recent randomness round. In this case it's reasonable to assume that the UCAN was _probably_ not generated long after the included randomness round. There is no incentive to do so if it is likely to be rejected on receipt. |
There was a problem hiding this comment.
I want to better understand this. Is the idea that service will reject invocation even if it still valid (has not expired yet) if it has been issued before some timestamp ?
If so what does drand provides over regular nbf / exp time bounds in UCANs
https://github.com/ucan-wg/spec/#322-time-bounds
E.g. service could deny requests unless nbf is specified and is with-in some time bound. It could also deny service unless exp is specified and is with-in desired time bound. More concretely service could demand that invocation be valid within 24h.
Only difference that I can see here, that unlike drand it would allow issuing a UCAN that will be valid in the future, which seems like pro rather than con, although perhaps there are cases where you want to prevent this ?
If so it might be a good idea to call those out explicitly.
There was a problem hiding this comment.
also cc @ribasushi as he had mentioned desire to do something along those lines & might be able to provide extra context.
There was a problem hiding this comment.
I don’t think the point here is to replace the timestamp functionality that already works within the trust model of the delegations.
A certifiable method is most useful for reconciling duplicate, similar, or conflicting transactions that happen to be UCANs.
The upload interface has a wonderful lock free mutex we write into, so we don’t have to worry about two people trying to do the same thing, that can both succeed easily.
However, what if an FVM contract wants to award the “first” uploader of the content a reward? DRAND is an easy way to reconcile who the winner would be from two claims.
As we get into mutations and as our internal system gets more complex, will we find distributed system challenges where we have to reconcile UCANs from different actors and this provides a simple and expedient means of reconciliation without any prior knowledge that the transactions would need to be reconciled in this way. If we wait until we have specific definitions for these conflicts, we will no longer be in a position to place information in them that could provide a means of reconciliation. Let’s just add it to everything now so that we won’t ever have this problem :)
There was a problem hiding this comment.
However, what if an FVM contract wants to award the “first” uploader of the content a reward? DRAND is an easy way to reconcile who the winner would be from two claims.
But you can always pretend to be the older invocation, but you can’t pretend to be the newer, so I’m not sure this helps
|
|
||
| By including a drand randomness round in a signed UCAN, anyone can prove that it was created _on_ or _after_ that randomness round was generated. There’s a number of uses for this, an example is allowing the web3.storage service to account for `store/add` invocations, publicly proving that we were asked to store data within a given time frame. | ||
|
|
||
| Services may choose to reject UCANs with timestamps that do not correspond to a recent randomness round. In this case it's reasonable to assume that the UCAN was _probably_ not generated long after the included randomness round. There is no incentive to do so if it is likely to be rejected on receipt. |
There was a problem hiding this comment.
also cc @ribasushi as he had mentioned desire to do something along those lines & might be able to provide extra context.
|
|
||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119). | ||
|
|
||
| 1. Issuers **must** include a drand randomness round in UCAN [`nnc`](https://github.com/ucan-wg/spec#323-nonce) field. |
There was a problem hiding this comment.
Any reason to require it in nnc as opposed to fct ? I'm bit hesitant to overloading nnc and it would also prevent issuing two UCANs with same time stamp.
There was a problem hiding this comment.
No reason, in fact I'd prefer to put it there now you suggest it :)
|
Reading the spec I do not feel convinced of the value this brings. Lets go with the popular (in UCAN world) movie ticket analogy here. With UCAN you can:
What this drand seems to offer is no 2 that is specify when the ticket was printed, but what is the practical use of this, given that:
|
|
|
||
| 1. Issuers **must** include a drand randomness round in UCAN [`nnc`](https://github.com/ucan-wg/spec#323-nonce) field. | ||
|
|
||
| 1. Issuers **should** include the drand randomness _round number_ in the [`nb`](https://github.com/ucan-wg/spec#241-nb-non-normative-fields) field. |
There was a problem hiding this comment.
Is this intentionally vague about how to include this in nb? i.e. under what key (e.g. nb.drand or nb.time)
There was a problem hiding this comment.
What's the motivation of this should vs not including it at all? If we can agree on a place to store it in nnc or fct, do we really need to strongly encourage it in nb too?
There was a problem hiding this comment.
@gobengo the proposal is to put the actual random value in nnc and the round number in nb. Not intentional under which key in nb - needs specifying (I just forgot).
If fct is more appropriate place for any/all of this then we should put it there! I think it probably a better place seeing as this is not really a nonce but a timestamp.
|
@Gozala knowing a UCAN was not created before an included randomness value was published feels slightly different from expiration or validity to me. Maybe this is more useful for things that are not the given example...like I think it'll be important to know a receipt was not generated before a certain time... Apologies it is late - I maybe need to think about this more and offer some clarification. Will revisit in the morning 😴 |
|
I was thinking a bit more about this last night. Having verifiable timestamps for UCAN invocations would likely be one of the items to solve |
This is a proposal for publically verifiable timestamps using drand randomness rounds.
Originally drafted here: https://hackmd.io/PlhTjh7YT0eyEY5FRceYGA?view (old out of date - please see PR for truth)