documentation: why don't we simply trust tokenscript by URI

[SmartLayer]

trafficstars

I answered in an email but wonder if others who read the documents want to see something like this before continuing to read how things works.

tokenURI wouldn't be our choice of mechanism to achieve that because it brings down the level from blockchain to the web (i.e. security-wise, the file is as reliable as how easy it is to hack the website that serves the URI; reliability-wise, a website might be under maintenance when the smart contract is still serving)

Ideally, smart contracts return a <SignedInfo> or its digest so that it is irrelevant how the TokenScript file is delivered to the user, as long as it passes the integrity check. By our design, a TokenScript file for a new token A is served at the same website where the user conducts a transaction to obtain A token for the first time. Alternatively, they can be fetched from IPFS. (Currently, we serve them collectively in a github repo but will move there when the file format stabilises a bit more)

Writing a smart contract is a tough job and we didn't want to load the contract developers with the additional task of maintaining TokenScript trust relationship in the smart contract while they struggle to minimise the attack surface. For that reason, we designed Express-Of-Trust transactions. Such a transaction is a simple (non-smart-contract) transaction sent from the contract's deployment key to a recipient address calculated from the TokenScript and the contract. (revocation is done in a similar fashion). The detail in the docs. This allows smart contract authors to deploy the contract first, and write TokenScript later and entrust it without having to update the contract.

Eventually, some smart contract will want to express trust to TokenScript through explicit functions, as the management grows beyond the "single-admin-key-does-everything" paradigm. For example, the deployment key might be safeguarded for upgrading smart contracts only, and a separate key is designated for updating of the TokenScript it trusts, allowing them to be taken care by two different departments or released at different intervals (e.g. release a TokenScript to ready users for a smart contract migration; then update the smart contract). When things get to that level of complexity, we will introduce a spec for smart contracts to return a <SignedInfo> or its digest

Might @jzaki help to sort out the doc https://github.com/AlphaWallet/TokenScript/blob/master/doc/authenticity%2Btrustworthiness.md so that it makes sense to readers?