TokenScript question: can a developer put together a dapp using TokenScript combining few different functions from different tokens? e.g. : I want to develop an insurance DAO using cDai, Kyber, DAOstack, I’ll create an interface that leverages TokenScript to deploy my interface on AlphaWallet (or other platform) and the user won’t need to know about all the behind the scene protocol, all they see is the interface they have various tokens function options as per the ‘game’ they’re interested to play
If you have a stake in a smart contract you own a token on that contract, be it the standard ERC20 or something more specific like your "insurance token". Once you add sophisticated logic to it, like the one you want to make which involve insurance logic and various other tokens. I'd like to call such tokens "Smart Tokens" because of the additional logic beyond ERC20.
TokenScript is the only way we have today that allow user-agent communication to sophisticated smart contract like the one you are writing. e.g. if your insurance condition needs attestation, or you need to know when it expires and what to do when that happens, you can use TokenScript's attestation and event support (implementation in progress).
You can't easily do that with the current web-application style dapp, since a website can't talk to you when it's not running in the browser, doesn't have the full knowledge of what is in your wallet (especially attestations) and is modeled with an inappropriate security model. TokenScript is signed to run in the wallet, a website dapp runs on the web with different security model. Website based also couldn't finely handle the consistency between the node its backend is using and the node the user is using, which leads to confusing messages and token status to the users.
1 Like
Thanks for the clarifications @weiwu.zhang, from what was discussed here, is it correct to say when a developer integrates between protocols (say that DAO + MakerDAO CDPs/Compound + WBTC +0x + Cryptokitties etc). They’d need to use the smart contract that handles that and developer the “Smart Token” interface to their particular contract using TokenScript. They would not integrate each TokenScript file of each protocol right ?
tldr: If you are unsure, build it with Smart Contract and write TokenScript for it.
TokenScript can be loosely or strongly coupled with tokens. You can have a piece of TokenScript that can operate 100+ tokens. You can also have a "donation" action that works on a lot of tokens. However, they are stateless themselves and cannot take input from others. I'll explain the two separately.
Tokenscript is itself stateless
TokenScript is modelled after the concept that a SmartContract is a state machine. TokenScript serves to help the state transition, not to replace the state machine with its internal states.
Let's say you write an action that involves multiple animal tokens. Let's say it's called BalanceMyZoo Action, by which you buy a cryptokitty, cryptodog, cryptokangaroo... till you have one each. You can write a TokenScript which provides the action. Let's say animals die sometimes, and breed sometimes, and you want to "rebalance" your portfolio so that the quantity of each animal is 1. TokenScript's BalanceMyZoo action buys the missing animal and sells any additional animals of the same type until the quantity of that animal reaches 1. What it does is to count the total amount of cryptokitty, cryptodogs and calculates how many are missing and how many to sell. So far so good.
Let's suppose one day you come across a cute kitty and you want to have it personally, BalanceMyZoo action will lead to one kitty being sold to make sure every animal has a count of 1. You can't draw a circle around the latest cute kitty and say it's not part of the `Zoo' because TokenScripts are stateless. On the other hand, if you make a Zoo smart contract, you can make the animals in the contract are rebalanced to the count of 1 without affecting your personal pet.
Tokenscript doesn't accept input
TokenScript can follow events and prompt users to do certain actions, but it doesn't take direct input from non-users. Let's say you have a "DAO + MakerDAO CDPs/Compound + WBTC +0x + Cryptokitties" thing, which would immediately liquidate all kitties when a certain event happens. If it were a smart contract, you can accept oracle input, input from some outside Risk Manger or callbacks from other smart contracts as the trigger of liquidating kitties. You can't do this with TokenScript, but you can program TokenScript to prompt a user if it observes such a liquidation event from a smart contract and suggests the user to do something. Even that has to be done when the user can act. TokenScript doesn't do anything when the user is asleep.
In fact, not accepting input stems from the statelessness of TokenScript, since anything that can accept input and do something is changing state, therefore not stateless.
The next post explains what can we do about it (if you really, really want to use TokenScript and the task at hand requires some state).
What if we want some functions that needs states and we really want to use TokenScript to do that?
You can do some workarounds to add state to TokenScript, e.g. by setting up a centralised server with SQL database which tags each kitty, but then you lose the trust anchor. TokenScript's security is anchored from the smart contract it interacts with. If you try so hard (with servers) to avoid writing a smart contract, then you end up with something I call unanchored TokenScript, the TokenScript as secure as web-based dapps (which isn't very secure), not as secure as Tokens, and shouldn't be called TokenScript (AppScript is more suitable; some people are much in hurry to build that).
You might argue on the user-experience ground. "It's still a usability improvement if token actions can be done in the wallet, despite its logic depends on a centralised server, not a smart contract". I think that statement is sometimes valid†, and oftentimes not. If you agree "great user experience means the user knows when to trust", then unanchored TokenScript represents poor user experience. I think the good user experience has an essential element of trust in it, in user's words: "If it looks secure it should be secure" so the insecure stuff better is left on the web where the users feel insecure. In a design with good user experience, if your zoo portfolio is messed up, the user should be able to say "That smart contract sucks", instead of wondering "is my TokenScript messing it up or did I trust the wrong Smart Contract?".
Sometimes a server-based state source is more secure because you know how to secure a server and the equivalent knowledge of smart contract isn't available. In that case, you can write TokenScript with states - TokenScript is designed (not implemented yet) to whitelist some servers for input. Such TokenScript is unlikely to get express-of-trust transactions from the authors of token contracts, and you have to accept
- your user's states interact with other users states in very limited and non-critical fashion, so the shared state in Smart Contract isn't relevant;
- your users are okay with your TokenScript's availability depending on a server's availability - it's damn hard to make sure a server is always online and serving, also damn hard to make sure you are in business to serve.
† To give you a valid example when the state should be kept on a server instead of a Smart Contract: let's suppose you have a "My Travel Plan", which looks into your hotel bookings (tokens), bus tickets (tokens), airline tickets (tokens) and scenery tickets (tokens), as well as Travel Club membership (a token) and Ethereum balance (a token). It constructs an itinerary for you, with 8 possible travel plans. You selected 2 and deleted 6 outright. Now, where do you store the 2 itineraries? Ideally, some cloud-based server or swarm, not in a smart contract. But to serve such sophisticated needs right in the wallet you will also need other tools like full context-based programming framework, embeddable AI and probably multi-party computation, or you end up having something like the early 2014 iOS apps that are simply wrappers of a website. Let's not fall into the mental trap of 2017 ICOs characterised by because it's technically possible, it must be technically available. Analysing your current need, I feel you are interested in gaining profit and controlling risk by playing with a changing set of tokens, and I don't think that fits a server-side solution.
From Dainel: "There’s this concept in web3 people call composability - the ability to use contract as lego pieces. What I interpreted Weiwu’s deeper comments was as an additional profound feature of web3 - executability : the ability to use tokens in various forms. This is what led me to the description of smart assets input there"
From Weiwu: "Composition is just one way to integrate and TokenScript serves to make token work, which include integration and frictionless transaction. TokenScript's design has quite a few points to make it useful to those goals. e.g.
-
the model intends to encapsulates both attestations as they are essentially express of intention (e.g. You can embed muliiple transactions to run them in batch or under condition)
-
the model allows token to get updated and notify other tokens of needed updates (CDP liquidation). It also makes wallets expects things to happen, hence enable stuff like stacked transactions or transaction modifierers.
-
the attestation model allows a lot of data about token not to be on the blockchain.
-
the security sandbox to run tokenscript allows integration between token and web logic, making token useful in the context of rich web-side programs.
-
allows context based programming, e.g. presenting different features dependong on your phsical location, your previllege and the game you are in (if you participates), making token useful in different context."
From Weiwu:
"Okay, let's hold an internal sessions to talk about the features of tokenscript. In short tokenscript is what you need to have to use tokens. By use it means if you own a car you can drive off the car with it, get insured with it, join share-economy with it etc etc. If you have a DAI token you can authorise someone to take 30 bucks from it every month, or send red packets with it etc etc. If you have a facebook token you can prove your relationship with someone and see her message etc. But to connect the ways of use-cases and features we need a feature map and explain how this feature helps that use-case."
from Weiwu "What I believe TokenScript was largely influnced by my believe that blockchain has to function (serve a utility) in order to have a future. But having history like Witchcraft, South Sea Bubble, John Law's paper currency and China's Culture Revolution, I don't want you to be biased towards truth (that blockchain has to serve a function), since history witnessed many many dysfunctional systems to persist for many many years."