Web2 identifiers as token owners, off-chain tokens, and other attestation use-cases
https://github.com/TokenScript/documents/blob/main/src/Cheque/send_token_by_identifier.md
Summary
The requirement for the user to have a crypto wallet has long been a user experience challenge that prevented large-scale adoption of tokens and is a barrier for businesses and brands to issue tokens to their existing customer base. While it is impossible to forgo crypto wallet and gas costs for a token holder to send transactions, the ownership of tokens can be designed to use web2 identifiers such as Email addresses and Twitter handles. This allows users who do not own cryptocurrency to own tokens, easing the adoption.
The technology to enable this is attestation — a terminology to denote signed messages by reputable attester that can be used on the blockchain directly or through the cryptographic proof generated from it. The technology is successfully deployed in DEVCON 6, an Ethereum developer conference, for ticket holders to mint NFT tokens long after they own it.
This paper goes through the mechanism of how this works, which involves hiding the user’s identity through zero-knowledge proof. Furthermore, the paper generalizes the approach and introduces a few new use cases for attestations, and establishes a general pattern of how attestations can be used on the blockchain.
Problem definition
We need a mechanism to mint (issue) tokens, such as NFT, to a user whose Ethereum address is unknown. In practice, such a user probably does not have an Ethereum address. The only way to issue the token is to issue it to the user’s web2 ID, such as email address or Twitter handle, as web2 ID is the only identifier available. This is a common situation when brands/businesses need to issue membership tokens to all existing members so that the members have a presence in web3 and access web3 functionalities.
Traditionally, this is done by asking every user to create a wallet, generate an Ethereum address, and link it to their web2 ID by logging in and creating a signed message from the newly created Ethereum address before a deadline. Then, the brand/business creates a bloom filter to “airdrop” membership tokens to all the users who finished the above process.
As of 2023, the success rate for this traditional process is very low due to the UX burden on the user. Furthermore, the tokens are periodically, batch processed. If not, an individual user must claim their token as they go; the gas cost and blockchain space abuse can be significant.
Therefore we seek a way to give tokens to the user that satisfies the following criteria:
- No wallet required: it must be possible to give tokens to the users without the users owning a wallet. In the meantime, the users who already own a wallet should still be able to access the token without significant overhead.
- Attester-agnostic: although it will not be possible to achieve the above without the involvement of an attester, the issuer or sender of the token must not force the user to choose any specific attester. This is important because the attester will necessarily know the user’s web2 ID in order to attest it, and can link the web2 ID to the user’s Ethereum addreess, therefore the users should be free to choose which attester can be trusted with this confidentiality. Furthermore, we require that the user does not need to do anything — including choosing an attester — at the time a token is sent or minted to their name.
- Privacy-preserving: it must be possible to give tokens to the users by their web2 ID, without revealing that ID to the blockchain. We further require that the user who do transactions with the said token — after they own an Ethereum address — do not reveal their web2 ID in the process.
Starting case: sending an Ethereum token to a user who does not have an Ethereum address
A user, Alice, wishes to send a token to Bob who might not have a crypto (Ethereum) address. Alice, however, knows an identifier of Bob that can be attested. e.g., Bob’s email address or Bob’s mobile phone number.
This section describes an approach by Alice sending a virtual and anonymous attestation, attesting to Bob’s right to redeem that token from Alice through a smart contract.
Cheque
We call this kind of attestation cheque as it is actionable with a smart contract, comparable to a traditional cheque being redeemable with a bank.
Such a cheque would identify Bob by an identifier and is only actionable if Bob possesses an identifier attestation that binds his crypto (Ethereum) address with that identifier.
Identifier Attestation
The identifier — email address or mobile number† — cannot be learned from an observer with access to the Ethereum blockchain. However, it will be possible for Alice to see that Bob is redeeming cheques from other parties in the future if he redeemed the cheque he received from Alice.
We wish to ensure that only Bob (the attested owner of the identifier and the person holding a copy of the cheque) can redeem the cheque. Neither a malicious attestor (or someone controlling Bob’s identifier) nor a man-in-the-middle who might extract the cheque, will be able to redeem the cheque alone.
Furthermore, we want to allow Bob to be able to reuse his attestation once issued to him. So that after redeeming a cheque from Alice, he can also receive a cheque from Carol and redeem it using his attestation without the need for Alice or Carol to communicate.
The protocol is secure under any composition of senders (Alices) and receivers (Bobs) based on a one-more discrete logarithm-like assumption.
Protocol
- We assume that both Alice and Bob know Bob’s identifier i.
- We use multiplicative group notation. Thus Gx denotes the generator element, G, taken x times as apposed to G·x in some other works (when using additive group notation as normally done over elliptic curves).
Identifier Attestation
This only needs to be done once for Bob. It can be done either before or after receiving the first cheque.
- Bob generates an Ethereum key (if he hasn’t already).
- Bob generates a /non-signing/ privacy key p.
- Bob computes a hiding to his privacy key; S=Vp, where V is a generator for a large prime-order subgroup.
- He then constructs a zero-knowledge proof that he knows the exponent p: He picks a random r and computes R=Vr, c=H(V, S, R) and d=r+c·p. The proof is a function of (V, S, R, d).
- Bob signs a CSR (signing request) which includes the proof and his identifier i using his Ethereum key.
- An attestor verifies that Bob owns the identifier, that the signature is valid and that the proof is valid by computing c=H(V, S, R) and verifying that Vd=R·Sc.
- If all the checks pass then the issuer constructs a Pedersen commitment; W=GH(i)·S where G is a generator for a large prime-order subgroup.
- Finally the attestor issues an attestation that binds Bob’s Ethereum address to the commitment W as its subject.
Cheque
- Alice wishes to send Bob a certain amount of a token and knows Bob’s identifier i. She creates a /non-signing/ one-time-key t, and computes a Pedersen commitment U=GH(i)·Vt.
- Alice writes a cheque for anyone to redeem that amount of the token from her smart contract (valid for a certain amount time period). The cheque requires a valid attestation to a commitment W and a zero-knowledge proof of knowledge of x such that W/U=Vx.
- Alice sends t and the cheque to Bob.
Redeem the Cheque with the Attestation
Bob computes a value x=p-t and, in a redeeming transaction, constructs a Fiat-Shamir based Schnorr proof-of-knowledge that it knows x such that W/U=Vx. That is, Bob proceeds as follows:
- Pick random r and compute R=Vr
- Next compute c=H(G, V, W, U, R)
- Finally compute d=r+c·x
- Bob then signs (G, V, W, U, R, d) and the attestation (whose subject is W) and sends all these values and the signature to the smart contract.
The smart contract computes:
- That the amount in the attestation is less than Alice’s balance.
- The attestation is a valid attestation that binds W to Bob (transaction sender)’s Ethereum address.
- That the signatures is correct.
- c=H(G, V, W, U, R) and verifies that Vd=R·(W/U)c
- That the cheque is still valid.
If all predicates are satisfied, emits the pay to Bob.
Generalisation of the protocol
Token attestation
This protocol has two signed messages (besides the redeeming transaction which is to be signed):
- cheque, which is a kind of attestation to trigger an action.
- identifier attestation, issued by an identifier attestor, which enables the beneficiary of the cheque to perform an action (redeem).
The first here does not have to be a cheque. Instead, it can be a normal attestation. Such generalisation was used in, for example, ticketing, where the first attestation attests to the rights of entering the venue corresponding to the ticket. This allows the user to use such an attestation as a blockchain token despite such a token not existing on the blockchain, so we call the first “Token Attestation” and the second “Identifier Attestation”. Token Attestation’s one-time-key should be more appropriately called “Token Key” since such generalisation allows it to be used for more than once. The symbol doesn’t need to change since t can represent either one time key or token key.
Attestations on token attestation
The “subject” of the token attestation, for example, numero=1280
, indicating the ticket ID 1280, can be used as an identifier attestation for another 3rd party attestation, which attests something to the ticket (although the hiding might not be necessary in such a use case). Here two examples are provided:
- A speaker of the conference can invite a ticket holder to a closed-door meeting. Such an invitation is an attestation on the ticket ID. Such an invitation is, again, used as a ticket.
- CO2 coin is an issuer of carbon credits for someone who paid to offset their carbon footprint. They can issue an attestation on the ticket ID, attesting to the fact that the ticket’s carbon footprint has offset. Such attestation enables access to privileged online services or discounts.
Issuing new attestations on the subject of the token attestation instead of its fingerprint (hash) has the advantage that if a specific attestation is revoked thanks to the leak of its token key, a new one — with a different fingerprint — can be issued without affecting the use of such attestations.
Implementation Issues
Implementations based on elliptic curves
We note that despite having described the protocol using general multiplication group notation, the implementations will be based on elliptic curves. Therefore, G, V, W, U, R will be points on an elliptic curve where W, U and R are computed using generator points G and V. This also means that the computation in step 4 for Bob and step 4 for the smart contract will happen over the integers, modulo the curve order.
We note that the generators G and V must be constructed such that they work over the same (large) subgroup. I.e. that V∈ <G> and that no-one knows the discrete log of V to base G (and vice versa). Otherwise, breaks become trivial.
Furthermore, it is also crucial that the curve has co-factor 1, or if not, the point G generates a subgroup of large prime order.
This post mentions some standards for EC-based Fiat-Shamir Schnorr proofs and thus where to look for further details.
In the case of using a JavaScript deployed as a service
Furthermore, we note that there do not seem to be standard Javascript libraries to compute such an elliptic curve Fiat-Shamir Schnorr proof. Thus this could be allowed to be supported by a third party (specifically step 1–3 for Bob). However, if such a library is malicious, it will learn x and thus be able to send this value back to its author, who will, in turn, be able to impersonate Bob. This must not happen. Thus instead of constructing a proof of knowledge of x Bob uses such a library to construct a proof of knowledge of x+w for a random w. Based on this Bob will instead send (V, S, R, d, w) in step 3 and the server will instead verify Vd=R·Sc·w. (A similar trick must be done for the proof used to redeem the cheque using the smart contract.) Still, even this approach allows for a front-running displacement attack if the Javascript library sends the query to its owners who also do mining, so the miner will learn x and thus be able to impersonate Bob once he tried to redeem the cheque.
However, it might still be possible to easily implement this in Javascript, as SubtleCrypto.deriveKey supports the construction of an ECDH key which can be used to construct the value r and t in step 1 for Bob over an elliptic curve. Since hashing is also readily supported, step 2 can also easily be implemented. Furthermore, Javascript also supports big integer arithmetic through BigInt, which is needed to compute step 3. Thus the only real issue that might not be trivial is to extract the BigInt representation of r along with the curve order.