#220 Manuel Araoz: Zeppelin and the Evolution of Smart Contract Development

Transcript

[Music] hello and welcome to epicenter the show which talks about the technologies projects and startups driving decentralization and global blockchain revolution my name is brian philbin train and i'm here today with manuel ross he is the cto and founder of uh zeppelin yeah so manuela's been on the show before which was i think around two years ago uh to talk about a project called streamium which at the time got quite a lot of attention

um and he's been around the blockchain space for for a long time so thanks so much for joining us today and can you just tell us how did you first get involved in bitcoin and blockchain sure so hey brian thanks for inviting me again it's great to be here once more um i got involved into the blockchain space around in 2012. i initially read about bitcoin through the white paper earlier in 2011 as i was in college studying cryptography and distributed systems and i saw this paper online which challenged all my everything that

i was learning in school and i took the paper to my to my professors and they dismissed it as as nonsense so that got me even more interested but i only got into working with the technology like a year later with proof of existence where i i was thinking about bitcoin and i had been reading and thinking about bitcoin for about a year and and i had this idea of creating a web app a user-friendly web application to timestamp data using the bitcoin blockchain and that's how i got involved in the space yeah i mean i actually remember that

i remember hearing about proof of existence and and your work that uh then i guess that was 2013 i didn't know about bitcoin 2012. now one thing that stands out to me here is so proof of existence is a non-financial application but at the time there's still so much focus on you know bitcoin payments money why do you think so were you from the beginning more interested in kind of other use cases besides payments and money then yes yes for sure to me in the beginning bitcoin seemed like a pretty weird monetary experiment and i was

at the time i was i had really no knowledge of finance or economics actually i got to learn many concepts in these fields thanks to getting involved in bitcoin technology and i just saw bitcoin as a cool geeky technology to to play around with and to try to hack so at the time i was trying to think how we can use this amazing new data structure of of the blockchain and this this network for other use cases other than just sending money internationally and if from the beginning i was really excited about anything that i read about in relation to bitcoin that was not

financial or not just an economic transaction and so from the early days i i followed the discussions around what what which transactions are spam or which are valid use cases of the protocol and this was what got me interested in some ideas about getting data into the blockchain and it was actually from an article i read saying that some someone was getting prayers into the bitcoin blog headers that got me thinking oh there's there's a way to get some extra data and maybe you can do something interesting but yeah i was interested in in non-financial use cases of of blockchain text since the early days and so prove existence for those who

don't know uh basically the idea is right because since we have this time stamped log and sequence of blocks that you can put hashes of documents in there so you can prove it exists at a certain time um was there any actual usage or traction of that project well in the beginning it was pretty early in the bitcoin days so it was mostly there there weren't many applications where you could use your bitcoins so where people were just finding it and using it to try something you can do with bitcoin other than playing on satoshi dice and so it was mostly early bitcoin adopters and many of them sent me emails i have a huge collection of emails from

the early users saying oh this is amazing this is a way to to spend my bitcoin in in some cool cool new application but after some month spots passed i started to see some real use cases of people like time stamping their ideas or research papers or trying to simulate a kind of paid patent for their what's what they were developing and then some weird use cases like um time stamping their own dna and that kind of things cool and and then you did you after that did you join bitpay

yeah i was after after i did proof of existence i worked as a freelance programmer in the space for like a year and that's when i met bitbase founders steven and tony at the latin american the first latin american bitcoin conference here in buenos aires and i was excited to see that that there were real companies for me the bitcoin space was like very small and i was getting freelance work but it it didn't sound as a as an actual industry to me until i met all these founders of actual companies like bitbay and i got really excited about joining a team and learning from other developers instead of just working on my own and that's why i joined

bitpay with the plan of focusing on their open source work like copay insight and bit core which was a great plan for me because the band i could learn more about the technology work on open source stuff and learn from a great team and it was a great decision when i think about it yeah and and then how did streamium come out of was that because did that kind of grow out of your work it did pay as well yes kind of i mean uh as part of i i was leading the development of bit core the javascript bitcoin library and we were designing like

sub modules for bit core one of them was a payment channels library that was built on top of pit core and in parallel to that uh here in buenos aires we had something sort of like bitcoin dinners what we called bitcoin dinners from with friends from college and we just got together and discussed about bitcoin news and latest developments back when you could get together and talk about those things in just one dinner and after some time of getting together to talk we decided to to build something so we organized a hackathon

among us just friends from college and we decided we wanted to build something with payment channels using the the payment channels library we had developed in bitpay because it was a hot topic at the moment but nobody was filling applications with it so we decided to finish the the implementation and create a first application for payment channels and we had this idea of live video and micro payments where you paid pay for each second via uh the payment channels protocol and so that was actually live on bitcoin or yes yes and i'm curious i mean i guess that that is one of the

use cases people often mention in the context of lightning network what's your kind of perspective of that did you feel like um this could have or how come this was possible without the lightning network no yes i agree i think lightning network is just well just it's payment channels but well-designed uh so i agree and streaming was just a really simple application and we didn't actually grow it into one it was like more like a technical prototype or or a very small mvp and at that time it didn't make sense for us to continue development because it was

very early in in consumer adoption of bitcoin so the market was really small to focus on streaming as a business uh but i do think like live video is a it's a great use case for payment channels in general or or the lightning network when it's when it's live so that early work was of use was all focused on bitcoin around bitcoin and now you guys are mostly focused and and we're gonna get to speak much more about zeppelin in a little bit uh on ethereum were you from the beginning when the ethereum white paper came out like kind of interested in opening to that did that come later um more or less i mean i i was part of one of the

mailing lists where vitalik presented the white paper which is the colored coins mailing list and at the time i thought this guy is crazy like he's he's aiming too high like we can't solve many simpler cases with bitcoin why why is he thinking about this crazy touring completeness for smart contracts like we still need to figure out simpler cases and so i followed him because i mean i followed the the white paper development back then and i read and i commented but to me it seemed like solving a non-existent problem unfortunately unfortunately i was wrong and some years later i revisited his work and which is basically ethereum

and i found that it was really amazing technology it took me many many months and many people i respect telling me hey you should look at ethereum again it's really good if you like smart contracts you should be looking at this and after many people told me this i said okay i will take a look again but i must admit that initially i was very bitcoin-centric and i didn't like any altcoins because i was like i was tired of reading ideas of all coins that seemed to be kind of scammy back then so in my mind i blocked many many opportunities to learn about new technologies unfortunately but after i i took a deeper look at

ethereum i was convinced that it was interesting and worth looking at and that's actually when we started uh working with ethereum uh with zeppelin yeah it's interesting though how you have this revolutionary new thing like bitcoin and then people get involved in obviously these are all people who you know question the status quo and like are kind of original thinkers and do things differently and then somehow over time right many of us so many people kind of become like almost conservative in the same way that those others come from and somebody else comes to question

their work and like no no this is like i mean i think in the bitcoin community right this is extremely common i i can't explain why i was that way and it it it relates to this what i was saying that i i started seeing other cryptocurrency projects and i got disenchanted because they were all very similar to bitcoin and they changed really little things and i eventually got bored and i realized that like the best developers were working on bitcoin and that bitcoin was like advancing the industry so i kind of shut off all the all the noise from altcoin development for a while because i thought it was a waste of time

but after some months of shutting it off as some some of it came through in the form of people i that i respect that were saying hey you should look at this new coin this is interesting and that's when i kind of opened my my mind again to to new projects and and even today i see some people are only focusing on bitcoin and i think that's very like narrow sided but i understand them because i i felt the same a couple of years back and it still happens that many like cryptocurrency projects are kind of smoke selling i i don't know how to translate this from spanish but like

selling smoke and mirrors like it's not actual tech it's just a new logo and very similar ideas but but fortunately there's many really interesting projects at the moment outside of bitcoin yeah i know i totally understand i actually have a somewhat similar uh situation today you know with all these new icos and stuff where i'm like where i tend to kind of be like oh there's like too much and the there's so much noise versus good projects that it's like it's not even worth looking at it um now of course that's dangerous too right because well i'm sure among all the noise and all the

questionable projects and all the smoke and mirrors there are also great new ideas great new teams exactly yeah so then you guys started working on ethereum and it sounds like i mean a lot of your focus is on on security why focus on that aspect yes so let me backtrack a bit there after streamium we decided to to start a company with my partner and to focus on when we realized that that streaming as a business was not uh a great idea because it was too early to require our users to own bitcoin back at the time and there were very few uh bitcoin users

back then uh we still wanted to sort of continue with the momentum we have we had and to experiment with what excited us most about blockchain which was smart contracts so we started zeppelin which at the time was called smart contract solutions which is a really generic name exactly because we wanted to be generic and to explore use cases and the technology of smart contracts um and after experimenting for like a year on many applications we realized that the biggest problem uh that that we had was that the tech stack was really immature and really early

and so after seeing that we had this problem and we realized that many other developers had this problem we decided to shift focus from trying to find an application to trying to build the tools to enable other developers to to create applications more easily and the biggest problem we saw in the space back then was security it was around the time the dao hack happened and we saw that the potential of creating amazing applications um was there with ethereum but the biggest hurdle at the time was that the tools were not very good and that developers were starting their projects from scratch which led to a critical backs which led

to hacks stealing money or locking contracts or very disastrous scenarios so we decided to launch open separating as an open source and community effort to try to tackle this problem and since then we've been focusing on security which is we think one of the cornerstones of of blockchain projects because if you if you can't get your smart contract to do what you intend it to and then you can lose money or you can lose other people's money uh as you know very well i imagine yeah so i read a post by you a blog post and and of course that we'll link to it in the show notes where

you had this figure which i thought was mind-blowing that you said that among those early contracts in ethereum that were holding substantial amounts of funds 50 of them got hacked is that is that accurate that seems incredible that that's a not not a very serious statistic i did like just manually looking at at projects that were interesting in the space or that had lots of transactions it's not a real survey but it is the the sense i got from sort of doing my research on the industry back then uh and the the tip of like the the

the the greatest ex exposure of that was the dow hack where suddenly like 50 million dollars were lost to a hacker and what we saw was that i think i think the dow was a great idea like the concept of modeling a fund and having anyone invest and anyone vote and have voting rights on which projects the fund should invest in it's a really great idea the problem was that the tools were not there to to develop such a complex smart contract in 2016 but i still think it's uh it's a great idea and that we should try to do it again with better tools to ensure security not only at the

like the code and technical level but also at the mechanism design and game theory level but the industry has moved forward a lot since then yeah absolutely now back then what what were the those big mistakes that people made that caused all these gigantic losses like why is it so hard to make smart contracts secure uh well it's it's funny because many were really silly mistakes that had to do with uh not understanding the solidity language in depth unfortunately also back then solidity was not

very good of a language for handling money and it has improved a lot since we launched open and also ethereum as a platform improved quite a bit uh but we saw like see silly mistakes in how to use the language that led to catastrophic losses or also some quirks in in how to use the platform uh some some very famous cases i can try to explain like this are um a contract called rubixi which was like a a pyramid scheme modeled as a smart contract and the

contract originally was called a pyramid dao or something like that pyramid contract but before deploying it and before sharing the code with the community the developer thought he didn't like to have the pyramid name in his contract so he changed it to rubixi which is more puzzling but when he changed the contract name he forgot to change the constructor name which in solidity means that that is now a public function that anyone can call er and that cost that anyone could call the constructor and take ownership of the of the contract so this is really basic stuff

and and it also relates to the fact that once you deploy a smart contract the code is immutable which is which is a it's still a big problem because if you find a bug in an already deployed contract it is a it is a quite a hassle to to fix it or to migrate your existing contract and data to uh to a new fixed contract um and it's one of the problems we're actually trying to tackle with our newest project separating os and another another kind of mistake that i can remember from back then was incorrect use of of the send

primitive which is a primitive in solidity to send money to another address basically that enables some code execution on the side of the receiver and many problems arise arose from that and actually the dow hack used this idea and the fact that you could re-enter the original code calling you to steal funds but if if you look back it's it's mostly basic programming errors or basic misunderstandings of how programming patterns should be used in in financial applications

but fortunately the the platform and the the community advanced a lot and we built lots of standards and and good practices around smart contract development that enable this kind of errors not to happen again in part a work like open sampling which is a set of modules where you can just reuse already audited code and you know that at least part of your application is is correct and also the solidity language improved a lot they added some keywords and and also the evm evolved adding some new up codes that enable safer

safer code execution so the state of the industry right now is much better than a year and a half back when we started open symphony so that brings up an interesting point right so you mentioned evm and solidity because many people have claimed that or kind of made the case that some of these uh problems and some of these security holes and hacks that have happened are kind of a you know a result directly uh of the nature facility and the evm and that there's something kind of fundamentally unsecure about that approach and and of course there are projects like you know tasers for example that i think is very

strongly informed by this thesis to say okay it needs to be totally different we need to have some kind of functional programming language um what's what are your thoughts on that yes i think those are very valid points uh and with with every as with every security problem there are many many layers of of courses uh and i think solidity and the evm design like even the fact that ethereum is turing complete it's kind of a a way that increases the the attack vector for smart contracts in ethereum uh but security is always like a compromise

between uh how how much you can express with the platform or with the tools you are you are you're using and and how restrictive you want it to be to prevent programmer errors so i tend to have a a more what i what what i like to think is a pragmatic approach which is uh let's focus on what developers are using and try to improve the experience there and i think it's very valid to try to build better tools like i'm not familiar with the details of what tesos is building but people that are working on new languages

maybe functional languages uh or or even new smart contract platforms that have a a different approach to security um but we like me personally and unsettling as an organization we like to focus on what everyone is using and trying to improve the security of that um because sometimes it's really hard when when a platform is already very popular and has a lot of adoption to get all the all the developers to move to a new platform so we try to be more reactive and just focus on what is what is most used and try to

to make it better yeah i mean you certainly write that it will be i i think that's one of the huge challenges i see for tasers ahead is first of all of course they don't have an existing developer community and then a lot of these tools that may well make smart contacts much more secure also just much more um arcane right nobody knows these languages they're very much harder to learn so i think that's going to be very hard to get people to to switch over to that yes and we're also ready to if we see a new platform or a new language or a new technology or a new tool that is

gaining in popularity we we will look into that and try to to collaborate on making that more secure and and easier for developers too we are not like tied to solidity and ethereum by any means so you have learned from your uh exactly start with bitcoin yes otherwise we would still be working just with bitcoin and smart contracts in bitcoin so you mentioned sampling before so let's kind of dive into that so you said it was a kind of a set of modules that came from you guys experiments and kind of playing around with smart contracts and kind of abstracting some rules can you share a bit more about how

zeppelin evolved sure um when we started we had built some small projects uh on our own um many doing smart contracts in bitcoin and some initial experiments in solidity for ethereum and that's where we realized that we wanted to build like a some kind of framework to make it easier for other developers and we saw this potential the potential of ethereum and that it was gaining popularity so we decided to focus there and we launched open sampling with really basic stuff like some helpers to to enable um sort of protecting your contracts

from common mistakes uh like very basic ownership patterns or some payment patterns like the the pool payments uh module that that protect you from re-entrancing cases uh and it was really really simple in the beginning i think less than eight contracts were there uh but we launched it and it got some attention from developers that wanted to contribute to a common cause and to improve the the ecosystem and after that we spent some months working with like consulting clients we just did development for projects in the space that liked our

approach uh to solidity development and basically what we did is we worked with the clients and we said okay we can develop your smart contracts but you need to agree that we can use the code for open separating so most of the initial code from open separating comes from those kind of consulting gigs which meant that that code was actually being used in production so the code in open sabling in the first months was just real code that was in production and that we had developed for real clients that wanted to do smart contracts and after we got it started with this

initial attraction we we we found a community of amazing developers that wanted to contribute their time into advancing the the framework and at the moment we have lots of of contributors and lots of external collaborators and maintainers and but that's how it got started so zeppelin today kind of the most comprehensive set of hearing libraries yes i think so uh it's it's certainly the the most used i know there are some uh sort of competing frameworks uh are arising in the in the ecosystem i haven't looked

at them in in much detail but um we certainly have the biggest community and many many projects in the space are using our code 25 of of the no even more maybe well i i don't want to throw numbers if i can't check them but a big chunk of of the projects we get as incoming audit requests are using open separating that we as part of aft after we launched opencycling um many projects contacted us to get their code audited by us because we were focusing on security and we were generating content on how to program

a smart contract securely so probably the developers reading our content were one wanted us to look at their code to give a final check to to their security and and that's one of our our main businesses right now at zeppelin uh so we receive lots of requests every week of auditing smart contracts and a lot of them use open cipillin cool so so how big is your team today and now how many of these security audits are you guys doing we are 12 mostly in buenos aires but some of them are remote and we're doing around four audits per

week wow that's a that's quite a volume yeah and we we publish some of them when when the projects and the teams agree we publish them on our blog so we we like to to make them public to to allow other developers to learn from everyone's mistakes so if you check our blog you can find many audits and learn about the latest security practices and what common mistakes appear on smart contract development and so there's zeppelin right which is on the community right then you have a kind of a set of modules and libraries and then there's also separate os um

what's the difference between zeppelin os and and those tools that we have so far spoken about sure so open sabling is the solidity development framework and in the past year by working with our audit clients and with the community on building open separating we found that there are some pending challenges that cannot be directly solved just by a framework like a library because open cycling is just code sitting on github that you can download uh compile your project with and just um deploy your contract with but there are some

pending challenges that cannot be solved merely by a library and last year we started thinking about uh starting this this new project settling os which can tackle this kind of greater challenges in the space which are also related to smart contract development and security and in particular we one of one of the pending challenges is what i was describing earlier about how to fix a bug in production once you have a smart contract deployed given the immutability of the ethereum blockchain you cannot change the code after the fact and that's very bad as a

smart contract developer because you can find a really simple bug that has an easy fix and that could be critical to the uh correct uh behavior of your contract but you cannot fix it and so that's one of the of the problems we're trying to to tackle with separating os which is how to upgrade your smart contracts once they are in production and this has has a lot of implications and spawns a lot of discussions um because it's not easy to uh maintain sort of the the balance between security and

trust from your contract because you don't want anyone to change i mean you don't want the developer to change anything they want but you want them to be able to fix bugs and so we for the upgradeability mechanism we designed a governance system where users of of these unchained libraries can decide and vote using special tokens for the system and decide which versions of of the code are the most secure and the and the the correct versions yeah so so let's say i i have i start some token sale

now there's a lot of owners of these tokens and there's some kind of bug in a critical contract there and you're saying that kind of the zeppelin os approach is that then there is you have a bunch of tools that they token someone can kind of vote on okay this is a better version of this contract so let's replace this block and the let's place his contract would then you know just kind of your library or this zeppelin os kernel allowed you know the existing token holders of that contract to fulfill that function or would that be a separate token

that's that's one of the goals but initially our approach will be less involved for smart contract development developers our initial proposal is to have a an unchained version of the contracts we already have today on open zeppelin so the development of sampling os will be iterative and we will improve it uh in the coming months uh so the end goal is what you described but in in the meantime like we are building an unchained set of libraries that can be upgraded so what what is upgraded is not the actual application code but

the library code that we provide so if if anyone using our libraries finds a bug we can use this governance uh mechanism for the upgradeability to fix the bug and that fix can can propagate to all the applications using sepulin os as a kernel um but eventually we want to provide the same mechanism for applications so they can upgrade their own code using their own token voting vouching mechanisms as we do for the library so let's say i'm developing some smart contract application and i want to use one of

your one of the functionalities that are in the open zeppelin framework is and you know so i could either just you know just take that code put it in my contract deploy it on ethereum or i could say i did deploy that my application on ethereum and i call that that function that's on chain like which one would you choose i mean i unders is it is the ability for the zeppelin community to upgrade the function and fix box is that the main selling point yes that's the the main value out of the kernel

i think you can still you still have the option of deploying just your own copy of open sampling as a library but then you cannot upgrade it on chain if you find a bug the the additional value provided by using sapling os kernel is that any bug that the community finds on on the deployed version of the kernel can be upgraded via this governance upgradability mechanism and as a as a user of the kernel you can decide whether you want to upgrade to the latest version automatically or you want to just have manual control of which version of the kernel you are using

and this way you you retain control of which code your application is running but you also have access like opt-in access to upgrades that can fix security problems and and this is a like this this solves a real problem of the industry we recently worked like last year we worked with the ogre team in migrating their rep token after we found a critical security vulnerability caused by them using serpent the serpent language which was very broken um and it was a lot of work to migrate the contract to

to a new version we had to freeze the old contract contact all the exchanges all the wallets it was like a 10-day project just to migrate the token to a new address with the fixed code it was the full auger team and the full settling team working on this for 10 days and it cost a lot of money also to migrate the data so all this would be prevented if a rep had been built on top of an upgradeable set of libraries it would just have been a deployment of a new version of the library and voting off of the new version by by the token holders

and we've seen many many other projects uh get into trouble because they found bugs in production so it's a it's a real need of of the industry now you mentioned the token here and how the zeppelin token is used to to upgrade those zeppelin contracts that live on chain where does the code token come from who has it um and and how yeah so how does that work yes so this is a it's an upcoming uh token it's it doesn't exist yet uh because we want to create uh an initial version of the kernel before we launch the token um and this token will be used

not only for for the kernel upgradability mechanism but also for other other components of separating os so far we have discussed only the kernel but we also have other other parts plan which are the smart contract development kit or the sdk and disabling os marketplace and this same token will be used in in these other components especially in the marketplace um but we we we are not planning to release the token until we have a an initial version of the kernel working which requires the token and so that's that's one of the reasons why

uh we we are not doing like a public crowd sale of the sep token uh we we want to have a working prototype with actual users before we we launch a token which is a huge responsibility so yeah i think that's a good point let's let's actually come back to the token in a little bit and briefly talk about these other two parts so first one being the sdk what is the zeppelin os sdk sure so the sdk is response to another need of of the space which is better contract development tools this involves on-chain tools

um which i can expand on in a minute and off-chain tools like web applications to manage and monitor your contracts like what what what we like to think as a a heroku for smart contract developments or for decentralized applications where you can on a single web application see your contracts perform operations on them like upgrading their code or changing ownership or changing the the state variables directly from from a web app and also developer tools like command line interfaces or testing if frameworks so we we want to build

a better development environment around smart contract development and and this also involves on-chain tools like what we call the sapling os scheduler which is basically a set of tools to enable asynchronous execution in smart contracts and this this would give like right now any any interaction between contracts is done in the context of one user transaction so a user needs to like a real human or a or a or an application needs to initiate a transaction but all the interactions between contracts

that are internal to that transaction are in the context of that initial one transaction so it's all like synchronous calls with the scheduler it's basically a way to to enable smart contracts to execute asynchronously and enable calls that can react to external events from the world or just delay execution of some function to say two months from now and this is this is some really simple tools that will make a smart contract development easier and we decided to focus on the kernel first because it solves a more

basic problem of the industry which is like fixing bugs but once we have the kernel in place we're going to work on the sdk with with the basis of this secure kernel once you have simple secure contracts we can work on more on better tools to create more complex contracts and the third phase is the marketplace because we think that once we can create complex contracts the next step in increasing the usefulness and complexities via interaction of of the contracts so the marketplace is basically a set of standards and tools to enable contracts to

interact with each other and pay for each other's services but this comes later in the roadmap because we think upgradability and better development tools are in more in more dire need for developers today so so just let me give one example and please correct me if i'm wrong regarding your scheduler maybe to kind of illustrate what this is about so let's say we had some kind of organization on the chain that's owned by different people and then it pays out let's say quarterly dividend then you can't actually have that contract

send that out at the end of each quarter but maybe it would have some kind of functionality that it becomes claimable by the user and they have to send a transaction to actually get that money uh and and then if something like that schedule you could actually have that contract itself initiate that transfer is that correct it is correct in how it would work but actually it's a it's a platform limit that every operation of a smart contract has to be initiated by a user so that will still happen but the scheduler is a set of development tools that you include into your contract and it's also a off-chain tools that anyone can can run

so the scheduler is a smart contract that wants a execution say at the end of the month they can signal this to the network by emitting a special event where they say i want this method to be executed by the end of the month and the network of that is looking at these kind of events they can decide okay i want to i want to call this contract later in the future in in exchange for a bounty so instead of having the actual user of the smart contract pay for the gas cost of executing you can sort of decouple who pays for the gas cost and at what time so basically there's there's a network of nodes looking at

the blockchain for these events and when the time comes for the contract to be executed any any of them can choose to actually do the transaction and get a bounty in return okay cool and now the marketplace so you said it's about allowing contracts to kind of call other contracts and pay them for it can you give some examples of that sure so this is these examples will sound uh maybe futuristic and it's because we don't see many interactions between contracts today um but we think about settling os as solving problems in the next five to ten years in the industries that's why we are planning so far ahead

but think about developing an application for example a betting a betting adapt where you need to store some images or the description of the bed on ipfs and you want to create a prediction market on augur to to represent the bet so this contract would connect to the separating os marketplace to higher to higher ipfs to store the files and to hire augur to create the prediction market this could be this is a really simple example but an app that wants to interact with two other adapts has no way

at the moment no there's no standard and no tools to enable this kind of interactions um in an easy way so the marketplace will will be just that like the standardization and the tools to enable contracts to to pay for each other's services it involves like a registry where contracts can publish their services or off make their service offerings and define the payment schedule they they require to access those services for example um a per call payment or a one-time payment and you can access to all my services or a monthly payment uh and that's that's how the marketplace would work okay and and so in the example of

filecoin right platform is its own it's going to be their own blockchain and stuff so that's not a smartphone so how would that work would you have to have some kind of i don't know link smart contract on the insurance chain that yes exactly like at the moment uh given that the marketplace doesn't exist existing smart contract applications would have to be sort of proxied to the marketplace and we're planning to write those applications ourselves first like to to enable existing smart contract applications to interact in the marketplace so it's it's easy for us to write an application that just receives payment through the marketplace and just reroutes the the service request to the to the

other net network uh but eventually our um our plan is for new new applications to be developed directly on top of the os which will enable them to participate in that in the marketplace natively okay and so i i imagine this in the end you will have almost like a registry of okay all these it's almost like an api call register right like all of these functionalities are available like here's how you call them here's how much they cost and and then that happens via open zeppelin and you guys so so you guys kind of simplify the developer experience yeah and i also need to like a

disclaimer here is that given that this this component of the os is so far in the future that we still this is our uh sort of intention of what we want to build but as with open circling the approach we try to take is to listen to the actual community needs and we think this this need will arise but the the guiding principle will always be what the industry needs so we see that the kernel is greatly needed today that's why we started working with that and after that we know that there are many things in the smart contract development experience that could be improved

but if two years from now we see that the marketplace was not a very good idea and that we have another more important thing we need to be working on that's what we we will do like the the the objective of settling os is to improve the smart contract development experience to make it easier and more secure for people to develop smart contracts so one of the of the zeb token or the zeppelin token right one of the use cases then would be that okay let's say i'm developing an application and i'm calling a bunch of different smart contracts that each have their own token and they expect to be paid in their own

uh token that instead of somehow having to acquire each token that smart contract would just maybe hold zeppelin tokens and then pay uh kind of the zeppelin smart contract presumably in in that token and then you guys would also build some kind of marketplace so that gets exchanged for those other tokens yes part of the marketplace idea is to provide better payment mechanisms for smart contracts we are assuming here and this again we don't know what will happen but it seems that future smart contracts applications will each have their own

native token and this is what we see now and we think this will happen in the future too so part of the service provided by the settling os marketplace is better ways for these contracts to pay each other in their own native currencies and we have uh some different approaches we we think we we want to build to tackle this this payment problem and one is as you said making the on chain exchanges we we will probably use existing decentralized exchanges like 0x to do that but also there are some other ideas where

parties can hold a buffer of tokens and provide these these exchanges really fast without the need of a market which we think could be more efficient and and better for some use cases and even like a third method would be just to act for each a contract to accept seb tokens so we just do the the price conversion uh so a contract can state it can like denominate their services in any currency but then they can actually settle the payments with any other currency so they don't need to do the conversion and they co they can convert manually every month or

every every time the the contract owner wants but the the objective of the marketplace is to build these tools to enable contracts to do these payments more easily so we were talking briefly before about the zap token and you mentioned you guys are not doing a token sale which is uh you know unusual in this day of um the industry so what are your plans how are those gonna get into the hands of people um you know that you need when when this actually launches on mainnet ethereum yes we will eventually sell tokens because we need the developers and actual users

of the kernel to hold sub-tokens to participate in the governance mechanism of the upgrades and to to fund their applications using the marketplace um but we decided not to do a a crowd sale because with with our work with our clients and also by just looking at the at the industry we saw that there's it's a like a double-edged sword when you when you do a crowd sale you get access to a lot of funding but we also saw that many times the communities become very focused on on the economics or or on the trading aspect of the token

so we didn't want to have our slack filled with traders talking or pressuring us to get listed on an exchange or to focus on the investment side of the token until we have an actual product that works so our plan is to actually build a working prototype of of the kernel which gives utility to the sub-token and only then uh offer the token as as a in a sale to the general public and even like even when we have a working prototype we are not sure when we want to open the the token sale to anyone like we first want to focus on the projects that are going to use

the the product the the kernel so initially we will probably sell er directly to projects that want to use the upgradability kernel and we we don't have any any plans or or concrete dates on on when we want the general public to access the the tokens um and we we want to be very cautious in this because we think that it's it's tempting to try to get a lot of money from the community and and get a big community behind you but it also has lots of risks uh i mean not only legally but also like uh with what i explained about

the community shifting heavily towards the trading part and not focusing on the technology you're building so we we will delay the the public sale of the token as much as we can yeah and of course you you pointed out before the functionality initially of this token is to to kind of vote on the upgrades of these kernel contracts and and so if you have to choose between two different versions of the contract i mean most cryptocurrency investors don't have the knowledge nor interest uh in being able to do that right so you're really gonna have a very very small

number of you know potential parties that can actually make informed decisions there and you're also going to be willing to to even spend the time on that exactly yes that's also another another reason um and just in in general we think that creating like doing a crowd sale before having any product like makes your project public from day one and that has a lot of cost for for the team because you need to communicate and you need to have a very detailed plan on how you want to spend the funds from day one because you will have to be held accountable to the huge community of people that trusted your money

on your project and we prefer a more iterative approach where we have maybe more control from the beginning and can still build things that are the value to the community but we don't necessarily have to explain everything we do to the whole investor community and that will give us more flexibility in the beginning i think cool no that makes perfect sense manual so what's what's the road map like when are you going to launch on the main net and which parts of this plan do you think are going to get or become available or what about timeline yes so the we're planning to launch

a very early prototype of the kernel actually next week but this is just like a micro kernel version of just an upgradable token you can you can check online our like we started development of separating os in a repo a repo we called sapling os labs because it's all very experimental code and we called it labs so that people don't use it in production yet just yet uh but we are launching this this initial version of the upgradable erc20 token which is something that is like a very simple use case of an upgradability mechanism

it's um it's it's not it doesn't include the token-based governance yet it's just a like a centrally governed upgrade ability mechanism but we all we already have projects that want to use it we're working with the winding tree team and they're launching their their token this week and they want to use this upgradability mechanism for their own token because they want to be able to fix bugs in production once they once they launch um and after we have this initial erc20 upgradable erc20 version we're working on

on a more on a on a bigger bigger version of the kernel and we think we'll have the whole open sampling library migrated into on-chain library form with token based governance upgradability by the second half like by mid 2018. so in five months that's what we're aiming for and after that we will continue working on this this would be like the mvp for the kernel with a token governance and after that we are planning to work on other

less core features of the kernel this year in the second half of the year which are like creating bug bounties or or enabling token holders to vouch for future versions so it's it's a way for users of the kernel to signal they want to fund development of new features even before they are built um another other less core mechanics of the kernel you can you can read about them on on our white paper and next year we're working on the sdk which will be a lot of work and after that we are focusing

on the marketplace on the third year that's the plan for now but i i want to add again that the disclaimer that we want this to be a a community driven effort so we will follow what the when the industry needs and fortunately from our work with open separating we have access to lots of teams building smart contracts so we are already collaborating with other teams on the on the code and on the direction of the project cool well manuela thanks so much for coming on this was uh super interesting to learn about open zeppelin and what's coming up here i think this is very interesting approach to building a smart contract and i'm curious if things are gonna go that

way but certainly sounds like a good and coherent thesis okay thank you for inviting me i had a great time once again and and so if people want to get involved in zeppelin of course we'll have links to i mean both zeppelin you know open zeppelin and zeppelin os and we can link to github is there any other ways people or things resources people should check out no i think that's pretty much it i also mentioned our blog which has lots of content just to to learn ethereum from the basics and also some more advanced stuff on how the the os will work and on smart contract security we have a pretty big

community on slack in our open circling slack and we're also hiring so if everything i talked about really excited you you can contact us to work with us and help us from the inside cool well again thanks so much manuel it was a pleasure and thanks so much for a listener for once again tuning in if you want to support the show you can do so by leaving us an itunes review and otherwise we're going to be back next week so thank you and see you then [Music] you