who signs a TokenScript

Tokenscript Design
1

Tokenscript declares a few smart contracts to be used in its header.

  • For a TokenScript that manages a token, we need to know that it is trusted by the token's smart contract's stewardship team.

  • When a TokenScript uses a smart contract, it implies trust to that smart contract, so we need to know who signed the TokenScript.

The straightforward way to achieve π‘π‘œπ‘‘β„Ž is to let a TokenScript be signed 𝑑𝑀𝑖𝑐𝑒 with 2 keys.

  1. By the smart contract key - by default the deployment key, if the smart contact doesn't have its own administrative key management functions;

  2. By a reputation key - by default a TLS key, since it's commonly available and you can ascribe a CommonName (the domain name of a website) from it.

This straightforward approach can't work because a TokenScript is updated a lot more frequently than a smart contract. One can update a TokenScript for a simple reason as "adding Russian translation" or "making the collaboration action more accessible (to blind folks)", while these are trivial reasons to update a smart contract. Therefore, the TokenScript's signing key is expected to be used a lot more frequently, while the smart contract key should be guarded more safely. The smart contract key is usually not available when the team wants to update a TokenScript.

Instead of 𝑠𝑖𝑔𝑛𝑖𝑛𝑔 𝑑𝑀𝑖𝑐𝑒 π‘€π‘–π‘‘β„Ž π‘‘π‘€π‘œ π‘˜π‘’π‘¦π‘ , we can use a π‘œπ‘›π‘’-π‘˜π‘’π‘¦, π‘‘π‘€π‘œ π‘π‘’π‘Ÿπ‘‘π‘–π‘“π‘–π‘π‘Žπ‘‘π‘’ method.

A TokenScript is signed by a reputation key (the lowest kind of which is a TLS key), with two certificates attached. One from a certificate authority; another certificate signed by the smart contract key.

Regarding revocation, since there is no standard way to revoke a certificate signed by a smart contract, we need either π‘Ž) a new EIP for a smart contract in question to express distrust of specific certificates; or 𝑏) deploy a revocation list smart contract.

Sometimes, even π‘œπ‘›π‘’-π‘˜π‘’π‘¦ π‘‘π‘€π‘œ π‘π‘’π‘Ÿπ‘‘π‘–π‘“π‘–π‘π‘Žπ‘‘e method can't work because the smart contract key is not available to sign a certificate. Scenarios:

  1. The smart contract key was discarded after deployment, to publically demonstrate trust, yet there is no commonly agreed way to certify the stewardship's current key for management.

  2. The smart contract is unattended, and someone provided the TokenScript needed for it to function.

  3. A wallet provider (e.g. AlphaWallet) provided a temporary, overriding TokenScript when finding a security issue with the existing one.

So a TokenScript signed only with a reputational key is still acceptable with a suitable level of warning.

Dual-signing creates some security-policy issues with revocation and expiry. For example:

  • in the case that the certificate from reputation authority expired, but the certificate from smart contract key has not, I feel that TokenScript should be trusted to execute with a suitable level of warning to the user.

  • in the case that the certificate from a reputation authority is revoked, but the certificate from a smart contract key is not, I feel that TokenScript should not be trusted to execute.

2

Regarding the signing of Tokenscripts I believe that what we actually want to do is to have the smart contract’s stewardship, and reputation key holder, sign the Tokenscript provider’s certificate. The rationale is that we would like to avoid signing the Tokenscript itself, as it changes so often. So instead we assert that we trust the people who holds stewardship over the script. That way we don’t need to resign things every time there is an update to the Tokenscript. This could also be combined with the one-key, two certs approach; by signing both the Tokenscript public key and the CA and smart contract certs.

For revocation I think you are right that we need to use a smart contract revocation list.

Another thing I want to mention regarding when certificates are good: I feel that in regards to Tokenscript, and blockchain in general, we would like things to work indefinitely, even if the private key has been lost or a project abandoned. Thus scrips and relevant contracts should not only be signed by the relevant parties, but also by a trusted third party timestamping service. If this is done, then it is possible to trust signatures even if the certificates on the signing keys have expired (assuming none of the certificates have been revoked and that they were all valid during signing)

3

@weiwu.zhang

Not sure if this is the right place for this, but seems as good as any…

Let's say I create a copy of the compound.finance website, and also copy the Compound smart contracts.

As I understand it, if I only need to use my website SSL certificate, the Tokenscript would look correct?

How does one get around that problem? Feels like there needs to be a strong link between the account that deployed the token contract, and the account signing the tokenscript? Then it could be verified automatically by wallets etc.

Quite possible I have missed something though!

4

Exactly, that association is designed to be done through an express-of-trust transaction. Basically the deployment account calculates a special address from the smart contract address and the transcript digest (hash) and sends 0 ether to that address. The user-agent (like wallet or browser) finds that transaction and confirms that the "strong link" exists. This is the main mechanism to ascribe trust between TokenScript and the contract. The SSL certificate mainly provides the user with an real-world identity (e.g. to prevent someone deploy a contract which is a copy of an existing token and fool user into thinking they are manipulating the real contract).

In shorter words, "express-of-trust" is used to ascribe trust; 'ssl certificate and signature' is used to provide authenticity. in practice both are needed (trust and authenticity).

Unfortunately "express-of-trust" code was not hooked up with the rest of AlphaWallet due to development schedule reasons so currently on AlphaWallet there is only authenticity (by signature), no express-of-trust (by transaction), hence

Yes it would look correct, presently. Shortly, when Ξ±Wallet has hooked up the validation of express-of-trust code, it will display the lack of trust between the TokenScript and the contracts, even if the TokenScript is signed with a certificate (like SSL).

P.S. We are aware that a SSL certificate isn't intended for signature. It's the lack of proper signing certificate in the community that we decided to accept SSL certificate in these years.