We have taken a look at your Github and especially at TokenScript, and we have a few questions for you to clarify for us:
It is said that with the aid of TokenScript, you can describe serialization and deserialization and then use it in Solidity (same as protobuf).
Question: Can TokenScript be compiled in Solidity and how it happens? We have not found any information on it in the documentation; perhaps it is not implemented yet.
It is said that ready-made TokenScript files with description of the smart contract can be signed by the Creator, so the user can verify the signature and be sure who is the Creator of this smart contract.
Question: On which stage in their applications this signature is being verified and how it happens?
Question: Do I need to provide my public key as the Creator, or how do I need it to do it?
If it is not being validated on the application level, then what mechanism is suggested to validate the truthfulness of the signature? Or is this all based on the initiative of the user who must do it individually?
Question: Can you elaborate more on the Express-of-Trust procedure, which can help to identify if this smart contract belongs to TokenScript?
Question: Do we need to add some additional functionality to the smart contract for this procedure and how it should be running on the user side in your application?
Question: Is it possible to build with TokenScript interaction between two different smart contracts?
Question: Is it possible to insert javascript code into TokenScript or any other programming languages?
Non-related Questions and suggestions:
Have you thought of integrating with the TON (Telegram) platform? TokenScript looks very suitable for it.
Please let me know your answers so we can better understand your product.
You must be talking about the data objects defined in TokenScript.
The data object modules (module = the "schema" of the data object) is 100% ASN.1 so any ASN.1 compiler is able to compile a parser to read such data objects. The catches are:
There isn't a solidity ASN.1 compiler yet (despite every other language got one).
The modules are written in ASN.X. This is for extending it so that it can be encoded in Ethereum ABI encoding on top of traditional DER), the downside is that most ASN.1 compilers today don't read ASN.X (XML equivalent of ASN.1) however a translation routine should be simple to write.
Most data objects are going to be signed (we call signed data objects attestations) so just parsing ASN.1 blob isn't sufficient.
I actually think we should be doing an ASN.1-parser-and-attestation-verifier in Solidity or EVM bytecode soon - I was holding it off in 2018 because Vitalik was to move EVM to WASM, then we never got around to finish this.
A TokenScript was designed to be downloaded from the web or IPFS when the user uses web3 sites. Different from traditional web2 websites, web3 website might offer or be compatible with many tokens, and each token issuer signs their TokenScript to be distributed on the web or IPFS so that their tokens can be used safely on websites. The signature is verified when the user-agent (AlphaWallet or any dApp browser) obtains such token script. However, due to the TokenScript schema not stable enough yet, we haven't opened them for web access, instead, we cluster all known TokenScript in a single github repo so we can change all of them when schema updates. 2020 is the year we looked forward to making TokenScript available to the wider community.
There are two public keys related to the signing.
One is the reputational key, which currently we recommend to use the one that matches their main SSL certificate. This is a misuse of SSL certificate (as it is intended to generate Diffie-Hellman session keys but few have real reputational keys for signing). "Reputation" here simply means that the certificate is not anonymised.
The other is the smart contract "express-of-trust" key, which is either returned from the smart contract or the smart contract deployment key itself. Such key has no certificates (it's true if the smart contract emits it), and you need as many such keys as you have smart contacts.
So let's say a token has 1 website and 3 contracts, it needs to be signed 4 times in total. Note that a signature doesn't have to be enveloped into the TokenScript, you might leave it on the blockchain, but this design may change.
With smart contracts that has key management features, they need additional functionality to return what is the current signing key to link contract with TokenScript. Otherwise, if a smart contract deployment key is used, no additional functionality is needed. I expect most smart contracts have key management features in the future.
Yes! Most people currently think contracts as a set of functions, therefore from one contract calling another is merely a delegation of function. This is principally wrong. Often, a contract calling another is crossing the trust boundary, and typically, a less trusted contract calls more trusted contracts. We take it into our core goal to manage the trust relationship to achieve security.
Traditionally, contact calling is done by the user first sending approval of contract B (short for business) to contract T (short for Token contract), then calling B which in turn calls contract T. This model is coarse because contract B might be compromised and there is often no limit what it can do. TokenScript will be designed with some additional feature called "DvP Security", which work like this:
Instead of recognising B as trusted, contract T would trust any contract to call it, however, the call must be in a proper DvP secured format similar to X.509 with additional counter replay measurements, that expresses to very fine detail what the token owner intended and signed by the token owner.
For example, if all B does is selling web-hosting, it might call T to move 0.01Ξ to the Pizza shop, and delivers a web-hosting token (with the right to access a hosting account) to the caller. It might be compromised and take all user's 1Ξ instead of 0.01Ξ.
In TokenScript's design, the caller generates an authorisation of 0.01Ξ and calls B with that. B uses that authorisation to move 0.01Ξ. The authorisation may even include fine details like "it only works if a hosting-token is delivered". Contract T will move no more than the authorised 0.01Ξ and only do that if it verified the transaction result has a hosting-token delivered. An adversary, therefore, has to compromise both contracts.
That authorisation in question is something like X.509 and is a singable data object defined in the TokenScript.
This design is only possible if users can individually sign instructions to multiple contracts calling each other and explicitly define what the user wants them to do. Creation of such instruction must be done on the client-side by signed components from each contract's author. This is one of the core reason TokenScript was invented as a user-agent (dapp browser) technology.
Yes.
TokenScript contains the runtime code needed for a user-agent to interact with a smart contract and accept user's input and choices in a safe manner. Currently, only JavaScript is supported, but ideally, we will encourage the use of WASM instead, so that there is a boundary between the web and the token logic.
The reason is: we don't envision a world where the token and the website that uses it enjoy the same level of trust from the user. e.g. you might have a book token which you trust its contract and TokenScript, but you might rent it to a library website which is less trust-worthy. WASM provides the VM that is separate and not directly inspectable by the website.