In this post I’m analysing the guarantees we get from the proposed authorship verification mechanism for receive and intent logics.
Why do we need to prove authorship?
In the proposed design, for the transfer and swap transaction functions the KL logic verifies that the receiver authored the predicates associated with them:
- transfer TF - receive logic
- swap TF - intent logic
In the transfer case, the receive logic associated with the receiver is triggered by the sender (we are trying to avoid requiring the receiver being online to authorise the receive). In the swap case, the intent logic is triggered by whomever initiates the swap. We often imagine it being the user themselves, but the user might also delegate this requirement.
In case the [receive or intent] logic is triggered not by the author of the logic, it must be proven that the logic being triggered is indeed associated with the author (the prover acts on behalf of the author).
The proposed solution
It is already described in the main post, here - with a bit more details.
The proposed mechanism is as follows: the author signs the logic L using their identity keypair (the ephemerality of which is out of scope of this post). The prover fetches the logic L and the signature S and proves, as a part of the mandatory KL logic, that the logic is associated with the receiver’s identity public key pk.
Role | Known parameters |
---|---|
Author | (sk, pk), L, S |
Prover | pk, L, S |
Verifier | pk, S |
- Constraint: SignatureScheme.Verify(S, L, pk) = True
- Instance: pk, S
- Witness: L
The signature leaks information
.. might be the first thing you think about, at least I did. The ways to deal with it depend on how the prover gets the logic in the first place. But first of all, let’s make it clear: we are talking about leaking information to observers, not the prover (prover knows it all).
1. The logic is public
In that case the signature doesn’t leak much - the logic is public anyway.
2. The logic is not known to the prover
To allow receivers to transfer kudos to the receiver without requiring receiver’s online presence, we must give them access to the logic so that they could trigger it.
3. The logic is communicated [semi-] privately
- If the signature is static and deterministic, it leaks some information because the witness is the same every time the prover proves the receive logic compliance. In the function privacy setting, I think, it doesn’t leak much since it isn’t even clear input to what logic this is, but this is a layman’s judgement.
- The signature can be re-randomised by the sender (I guess), but the sender is not directly incentivised to do that.
- We can enforce some re-randomisation by requiring the senders use their identity to re-randomise the signature, but that only allows us to make sure that different senders make the signature look different.
- Another way would be to tie re-randomisation algorithm to both the sender’s identity and some verifiable and constantly changing variable, such as time. It might end up being predictable since time is predictable, but the guarantees we get depend on how reversible re-randomisation process is (how much we can infer about the signature knowing what randomness we used).
- If the receiver is sometimes online, they can update the signature periodically. In that case it must be enforced that the previous signature value cannot be used anymore
- Hiding the signature under a commitment could help a bit, but if the commitment is static as well, the problem is just transferred here instead.
Conclusion
I wrote this post to make it explicit what we get and what trade-offs we make to achieve our goal. If we can improve it - great, but I think the trade-offs are within the range of acceptable, given our priorities (conditional receive, less online time for the receiver, reasonable privacy). Further analysis won’t hurt.
TL; DR
- Signatures help to prove authorship of the [receive or intent] logic
- The prover must know the receive logic of the sender
- The signature leaks some information to the observers. The ways to reduce it include re-randomisation based on the sender’s identity and time, or periodic signature update when the receiver is online, with invalidation of the previous value
- Static values reduce privacy but allow the receiver to not have to be online often