Tokens
Devcon 1 · November 2015 · 16:47
Simon de la Rouvière, a developer at ConsenSys, explains why tokens matter for Ethereum and why shared token standards matter for interoperability, since deployed contracts are hard to update. The draft standard he presents at Devcon 1 covers only transfers, balances and approvals that let another contract spend on a holder's behalf. He shows a basic standard token and a library version that is somewhat cheaper in gas, a concern driven by prediction markets that mint a token for every outcome. He then raises open questions: adding a total supply call, whether token metadata belongs in the contract or a registry, and how standards should be extended. In the Q&A he covers compatibility with Mist wallet tokens and duplicate token names.
Speakers
Topics
From Devcon 1, hosted by Ethereum Foundation.
Transcript
[Music] hi everyone uh before we start um I am Simon delier I am a developer at consensus um I've also been uh writing a book about blockchain technology for the for the past month um sorry not past month more than a year um and I'm still busy with that and um tokens are one of the things I'm focusing on which I think is very important because the timing is right for this so I'm going to talk about tokens token standards and then um what you can use tokens for um uh I had an
accident with my laptop last night we had some wine so I spilled over it so I don't have my laptop with me anymore but uh then I decided also thought that the Wi-Fi would be fine but it's not so the the slides might be a bit behind and a bit slow um so why are tokens important at this point in time it's because um soon and it it has already started um is that when you see the next picture you will see that this is what's pretty much going to happen soon and is happening um no there aren't tokens under your seats that would have been great but everyone's going to get a token people are going to Min tokens for everything so what are tokens why why do we care about it there are several reasons why we want to use tokens and tokens are
there are several ways to describe it um you can describe tokens as assets digital assets and so forth I like personally I like to use the words funga bles that's not a fungible that's a fun Geral um um but if you want to know what a fungible is it's a something that's of the nature of a kind to be freely exchangeable replaceable inho whole in part for any like nature of kind and fundability is a property of a Goods commodity whose individual units are capable of mutual substitution so that's just basically fancy speak for saying you can trade things around and you can measure the amount of units you have for something
so um when you think of tokens uh people often think that it's s of worthless play money but we use tokens in almost every facets of Our Lives we use tokens as coins currencies we think think about it as shares or equity and things um it can be prediction Market outcomes it can be used in energy meters to represent Energy hours tickets access tokens etc etc so it can it can represent almost anything and the reason why the talk is important at this point in time because this is the first thing that um a lot of people are going to use on ethereum and have already started using in ethereum is that we need to find a way for things for these kind of token systems to interoperate with each other and then also find a way for for um other adaps
to use these tokens in their ecosystems so there's been a community effort mainly um spirited by the foundation to design some of these standards um so that uh these things can interoperate easily and the current ones are around tokens Registries data feeds and foring contracts um the most important one at this stage is tokens because that's the first one most people will use the standards are important um usually standards are important but the reason reason why it's uh relatively more important in ethereum's case is that when you deploy things uh you can't it's more difficult to update it unless you Bol in these kind of features to allow it to change functionality in the future so if we assume we're going to have a
token for which is a share in a company that's going to last 150 years um then this thing needs to be uh future proof as possible so that's why these standards are important and why we need to um uh discuss this so one of the the problems with standards is the standards are not easy um this is a relevant SK CD comic that there would be a situation where there are 14 competing standards and then someone says that's that's ridiculous why don't we just make one universal standard that takes all use cases into account and what you end up with is just 15 competing standards um standards often um develop like uh JavaScript in a sense that all that you need to do is to be in the right place
at the right time the thing that gets the most adop adopted is the standard that wins JavaScript was B to be used in the browser and before we knew it it's used on Hardware so it's literally just being at the right place at the right time which standards being used the most often you can discuss at infinum about what kind of things should be in a standard but the one that will win at the end of the day it will be used by most people is the one that gets developed the most or deployed so with the Mist an ethereum wallet um recently launched they you can issue and create tokens from there and everyone already needs to consider that that a lot of people have really started issuing tokens so what do the current token
standards um look like uh they only deal with transfers and approvals so transfer is how do you send tokens around and the approval system is the possibility to to give custodian access to other people uh other contracts and um so forth it does not prescribe anything about how these tokens are created that's up to the Token Creator to decide and the general idea behind token systems is that a token system lives in a specific contract uh sorry at a specific address so these the standards look as follows um this was taken from the Wiki page so everyone can can go look at it so the first one is just a basic transfer you send you you are authorized
to send your own money to someone else then you have the transfer from which is once you've G someone else the possibility to send money on your behalf you specify who needs to send to whom then a normal balance of um um um API which is as it's obvious it Returns the amount of tokens at a certain address then these are the approval apis which is the first one is uh the possibility to give full custodian um over your account so it's essentially saying this contract can do whatever they want with my money you need to trust that contract is not going to do something stupid or crazy um then you can remove or revoke that access and this the unapproved uh
revokes both once of um once of control and full custodian control the once of control is where you essentially it's like a deposit type system where you essentially give a contract uh the ability to Once off up to certain amount withdraw money or extend money from your account and then you have helper functions which you use to basically check if the if the account has um access to do certain things so based on that we created a um basic standard token uh the the funds are created in the Constructor so essentially saying whoever mints the the contract is the owner of the initial
balance um I'm going to post these things on um the subreddit and um online so you can go find these some of these examples we've created um that's what it would look like um then uh we thought about the problem of well a lot of these functionalities will be duplicated uh substantially um so one of the things we considered was rewriting a lot of the core functionality into a library so for those that don't know this is really awesome libraries um like Christian explained earlier is you create the capability for code to live at a certain place on the blockchain and then uh you ually call those functionality and execute it in the current environment or
the calling code of the specific contract so you would for example have a token system that then uses transfer functionality but you don't have to deploy the transfer functionality for each token system each time so we wrote a library um to do this um it will also be available um and then the the actual implementation which is the stuff you deploy is much smaller so this is just what the actual token each time you meant to token contract what it would actually look like so we did some test to see if it's substantially cheaper and this was the estimated gas cost for the normal one and the library is it's a bit cheaper I'm sure uh there's still some gas optimization tricks we could employ to
make it even more cheaper um we'll see what happens most of this stuff most of the stuff came into uh when we started thinking about gas optimization was um the fact that um was the fact that nosis and other prediction markets they they essentially mint tokens for each event and and specific outcome so you would have the credential race then you would need a token system for uh Hillary Clinton uh Jeff Bush and whatever you would have Min a specific token contract for all of them and if we assume like we hope will happen there will be millions of prediction markets and millions of outcomes and we're predicting the future very wonderfully then it comes very um expensive to these tokens each time so
we thought about the possibility of adding an an identifier an optional identifier to a token system but it meant it adds some kind of complexity to the standards that most tokens might not use so this is an example of things where it gets it can get quite complicated in terms of what this the community ends up using um there are ways in which you can have exactly this type of um system and then it you use essentially a constellation of forwarding contra tracks around this kind of thing but it's out of scope of this talk um what we're going to do from Ur and out um is we've built the basic Nick dots and made this really nice simplistic interface um that basically
means anyone can create a token contract and because we conform to the wonderful standards it means you can just use that address in the current ethereum wallet and you can tra and exchange your Simon tokens for no I'm not selling beers but you can exchange it for something else um then eventually we're going to make more a more complicated token issuance and management system that will involve the options to pick and choose certain features so if you want an administrator or you want the possibility to Min tokens into the future if tokens should should Decay you know there are lots of VAR variables involved and then to make it easy to Plug and Play these kind of things um yeah just an example of the
identifier code given these things um there are still some thoughts that we have around the the token standards and that's why I thought this is a perfect time because we have all the developers in the room to consider these things one of the most pertinent ones that we want to introduce that U is the a get total or total amount API that's not currently in the token standards um this is what it should return is just based on whatever the token deems to be the case the amount of tokens in circulation and this is important for scenarios where you want to figure out hey how much how many like what's my percentage uh ownership in a company for example that's not possible at the
moment unless you store it somewhere else or or have previous knowledge um the order of the parameters uh was recently changed um we're not sure why but I'm going to talk to Alex and favian about it um it's not picky things but it's like very small change but it means that if we don't um if we don't think about it then it means future stuff won't be compatible then um which is going to be probably at next year's Devcon when the tokens have been flourishing then we need to start talking about registry standards um I say grown there because it's it see it seems like a lot more difficult problem than token standards um so it's the question of
should the metadata of the token be in the contract itself or should it be in a registry um and it's still up to debate which one is best we don't actually know um because in C some circumstances you don't actually need metadata sometimes you want it to be in a registry doesn't matter um then the question of like the the issue of uh creating a lot of tokens for various use cases um is it possible to make it cheap and flexible and modular enough so that you can have these kind of um several ones but keep the nice standard set of apis then I think generally um I think generally there's still the the issue of it's great that we have all these standards and hopefully people use
them to make everything nicely interoperable but there's still no clear way which we can think about how we potentially extend standards in the future so hopefully the community can give some ideas about how we go forth and once the standard's been defined do we do does everyone go yay like raise hands or like what does the process look like um so that's something we need to consider and the great thing is um I think it's tomorrow if you care about this kind of thing um then there's a standards panel tomorrow which we um which we should uh all attend so we can build many apps that interoperate um I have a I purposly left some few minutes for uh question and answers um so if you
have any questions please ask me that's fun durables not funes see is that yeah one yeah okay so yeah um yeah questions yeah they're back so in the beginning of your talk you mentioned the token creation built into the Mist wallet uh how strongly are you committed to stay compatible with uh with those tokens um those ones are as far as I know I looked at the code is it's it it didn't deviate at all to normal standards except the order of parameters and we haven't deployed any
tokens ourselves so it's it's just easy to switch to the changing of the parameters so to answer your question it's they will be compatible but those tokens don't have as far as I know and Alex and Fabion can correct me but those tokens don't have approval systems in them so uh they only their only apis they support is transfers at the moment but I might be wrong I might be wrong is there another question we have one more we have time for one more question Tiff or someone yes thanks um so you mentioned uh the problem with storing the metadata
whether that's on the contract or in a registry um would it not be possible to use ipfs and do you see any problems with using that approach yeah I mean you you can use ipfs I mean it's not a lot of data you need to store it's stff stuff like you know um a name and maybe a symbol or and then like how many tokens are in circulation that kind of stuff so it's fine to store it on the blockchain I think the the biggest issue is actually more the naming of things and um we've already seen that people have created tokens that have exactly the same names as other cryptocurrencies which is not the same thing so you know I mean that will always be the case people will be able to do that anyway but uh you sort of it would be ideal
that you know if I create uh Simon tokens and I decide my metad datas in a in the token itself uh token contract itself and then you know 5 years from now someone a new registry pops up that everyone uses for token Registries and someone just steals that name and then how does this interoperate like for example a decentralized exchange like ether X for example are they going to call the information from a registry or are they going to talk to the Token contract itself to to get that information and it's not it's not obvious yet what we should do cool thank you very much guys appreciate it