Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Manuel Aráoz: Zeppelin and the Evolution of Smart Contract Development

Episode Date: February 1, 2018

Zeppelin Co-Founder and CTO Manuel Araoz joined us to discuss his journey from building one of the first non-financial Bitcoin applications in 2012 to improving development and security practices for Ethereum smart contracts. We discussed the OpenZeppelin framework, a library of audited smart contracts as well as their new project zeppelin_os. Through on-chain, well-vetted and upgradeable smart contracts zeppelin_os aims to make developing Ethereum applications both easier and more secure. Topics covered in this episode: Manuel’s journey in the blockchain space from proof of existence to BitPay to Streamium to Zeppelin Why Manuel moved away from a pure Bitcoin focus to working on Ethereum Why Zeppelin focuses on smart contract security How smart contract security evolved since the start of Ethereum The OpenZeppelin framework of audited Ethereum contracts Why zeppelin_os and standardized, upgradeable on-chain contracts are the next evolutionary step The core component of zeppelin_os: Kernel, SDK and markeplace The ZEP token and its role in zeppelin_os Episode links: Zeppelin Website OpenZeppelin Framework zeppelin_os zeppelin_os Whitepaper This episode is hosted by Brian Fabian Crain. Show notes and listening options: epicenter.tv/220

This is Epicenter, Episode 220 with guest Manuel Araos. To Epicenter, the show which talks about the technologies, projects and startups driving decentralization and global blockchain revolution. My name is Brian Fabian Crane. And I'm here today with Manuel Ara Raus. He is the CEO and founder of Zeppelin. Yeah, so Manuel has been on the show before, which was, I think around two years ago, to talk about a project called Streamium, which at the time got quite a lot of attention. And he's been around the blockchain space 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. 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 everything that I was learning in school.

And I took the paper to my professors and they dismissed it 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 was thinking about Bitcoin. And I had been reading and thinking about Bitcoin for about a year. And I had this idea of creating a web, 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 your work then. I guess that was 2013. I didn't know about Bitcoin in 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 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 the blockchain and this network for other use cases other than just sending money internationally. And 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. So from the early days, I followed the discussions around what, what, which transactions are spam or which are valid use cases of the protocol. 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 someone was getting prayers into the Bitcoin block headers that got me thinking, oh, there's there's a way to get some extra. and maybe we can do something interesting. But yeah, I was interested in non-financial use cases of blockchain text since the early days. And so prove existence for those who don't know, basically the idea is, right, because since we have this timestamped lock and sequence of blocks that you can put

hashes of documents in there so you can prove it exists at a certain time. 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 weren't many applications where you could use your Bitcoins. So 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 spend my Bitcoin in some cool new application. But after some months passed, I started to see some real use cases of people like timestamping their ideas or research papers or trying to simulate a kind of patent for what they were developing. And then some weird use cases like timestamping. their own DNA and that kind of things. Cool. 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 BitPay's founders, Stephen and Tony, at the Latin American, the first Latin American Bitcoin conference here in Buenos Aires. And I was excited to see that there were real companies. For me, the Bitcoin space was like very small and I was getting freelance work. But it didn't sound as an actual industry to me until I met all these founders of actual companies like BitPay. 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 co-pay, Insight and Bitcor, 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 then how did Streamium come out of? Was that, did that kind of grow out of your work at BitPay as well? Yes, kind of. I mean, as part of, I was, I was leading the development of Bitcore, the JavaScript Bitcoin Library. And we were designing like submodules for Bitcoin. One of them was a payment channels library that was built on top of Bitcoin. And in parallel to that, here in Buenos Aires, we had something sort of like Bitcoin dinners, what we called Bitcoin dinners 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 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 payment channels library we had developed in BitPay. because it was a hot topic at the moment, but nobody was building applications with it. So we decided to finish the implementation and create a first application for payment channels. And we had this idea of live video and micropayments where you pay for each second via the payment channels protocol. And so that was actually live on Bitcoin or... Yes.

Yes. And I'm curious. I guess that is one of the use cases people often mention in the context of the Lightning Network. What's your kind of perspective of that? Do you feel like 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. So I agree.

and streaming was just a really simple application. We didn't actually grow it into an... It was more like a technical prototype 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 consumer adoption of Bitcoin. So the market was really small to focus on Streamium as a business. But I do think, like, live video is a great use case for payment channels in general or the lighting network when it's when it's live.

So that early work of years was all focused on Bitcoin or around Bitcoin. And now you guys are mostly focused and we're going to get to speak much more about separately in a little bit on Ethereum. Were you from the beginning when the Ethereum white paper came out like kind of interested in opening into that or did that come later? more or less i mean 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 white paper development back then and I read and I commented but to me it seemed like solving a non-existent problem. 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 tired of reading ideas of alt-coins that seemed to be kind of scummy back then. So in my mind, I blocked many opportunities to learn about new technologies, unfortunately. But after 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 working with Ethereum with Zeppelin. Yeah, it's interesting, though, how you have this revolutionary new thing like Bitcoin,

and then people get involved in it. And obviously, these are all people who, you know, questioned 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 Derek and like, no, no, this is like, I mean, I think in the Bitcoin community, right, this is extremely common. I can explain why I was that way. And it relates to this, what I was saying, that I started seeing other, uh, 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 noise from Altcoin development for a while because I thought it was a waste of time but after some months of shutting it off, some of it came through in the form of people 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 mind again to new projects. And even today, I see some people are only focusing on Bitcoin and I think that's very narrow-sighted. But I understand them because I felt the same a couple of years back.

And it still happens that many cryptocurrency projects are kind of smoke selling. 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 fortunately there's many really interesting projects at the moment outside of Yeah, no, I totally understand. I actually have a somewhat similar 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 there's so much noise versus good projects that it's like,

it's not even worth looking at it. And 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, they are also great new ideas, great new teams. Exactly, yeah. So then you guys started working on Ethereum and it sounds like a lot of your focus is on security. Why focus on that aspect? Yes, so let me backtrack a bit there. After Streamium, we decided to start a company with my partner and to focus on...

When we realized that Streamium as a business was not not a great idea because it was too early to require our users to own Bitcoin back at the time. There were very few Bitcoin users back then. We still wanted to sort of continue with the momentum 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.

And after experimenting for like a year on many applications, we realized that the biggest problem that we had was that the tech stack was really immature and really early. 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 create applications more easily. And the biggest problem we saw in the space back then was security. It was around the time the Dow hack happened. And we saw that the potential of creating amazing applications 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 critical bugs which led to hacks and stealing money or locking contracts or very disastrous scenarios. So we decided to launch Open Sepeling 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 blockchain projects. if you can't get your smart contract to do what you intend it to,

then you can lose money or you can lose other people's money, as you know very well, I imagine. Yeah, so I read a post by you, a blog post, and of course 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 accurate?

That seems incredible. That's not a very serious statistic. I did like just manually looking at projects that were interesting in the space or that had lots of transactions. It's not a real survey, but it is the sense I got from sort of doing my research on the industry. industry back then. And the tip of like the the greatest exposure of that was the Dow hack where suddenly like $50 million were lost to a hacker. And what we saw was that I think I think that 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 funds should invest in. It's a really great idea. The problem was that the tools were not there to develop such a complex smart contract in 2016. But I still think it's a great idea and that we should try to do it again with better tools to ensure security, not only at 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 were those big mistakes

that people made that caused all these gigantic losses? Like, why is it so hard to make smart contracts secure? Well, it's funny because many were really silly mistakes that had to do with 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 Sepelin. Also Ethereum as a platform improved quite a bit. But we saw like silly mistakes in how to use the language that led to catastrophic losses. Or also some quirks in how to use the platform. Some very famous cases I can try to explain like this are a contract called Rubiksy, which was like a pyramid scheme modeled as a smart contract. And the contract originally was called Pyramid Dow 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 Rubiksy 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 and that cost that anyone could call the construct and take ownership of the contract. So this is really basic stuff.

And it also relates to the fact that once you deploy a smart contract, the code is immutable, which is still a big problem, because if you find a bag in an already deployed contract, it is quite a hassle to fix it or to migrate your existing contract and data to a new fixed contract. fixed contract and it's one of the problems we're actually trying to tackle with our newest project, Sepulingo West. Another kind of mistake that I can remember from back then was incorrect use of the send primitive which is a primitive insolidity to send money to

another address. Basically that enables some code execution on the side of the receipt, and many problems arose from that. Actually the DAO hack used this idea and the fact that you could re-enter the original code calling you to steal funds. But if you look back, it's mostly basic programming errors or basic misunderstandings of how programming patterns should be used in final

financial applications, but fortunately the platform and the community advanced a lot, and we built lots of standards and good practices around smart contract development that enable these kind of errors not to happen again. In part, work like OpenCepeling, 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 correct. And also the solidity language improved a lot. They added some keywords and and also the EVM evolved adding some new upcodes 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

OpenCepin. 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 problems and some of these security holes and hacks that have happened are kind of a result directly of the nature of the utility anti-EVM and that there's something kind of fundamentally unsecure about that approach and of course there are projects like you know tasers for example that I think is very strongly informed by these thesis to say okay it needs to be totally different we need to have some kind of functional programming language what's what are your thoughts on that yes I think those are very valid

points and with with every as with every security problem there are many many layers of of causes and I think solidity and the EVM design like even the fact that Ethereum is during complete it's kind of a a way that increases the attack vector for smart contracts in Ethereum. But security is always like a compromise between how much you can express with the platform or with the tools you're using and how restrictive you want it to be to prevent programmer errors. So I tend to have a more What I like to think is a pragmatic approach

Which is let's focus on what developers are using And try to improve the experience there 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 or even new smart contract platforms that have a different approach to security. But we like me personally and Sepelin as an organization,

we like to focus on what everyone is using and trying to improve the security of that. Because sometimes it's really hard when a platform is already very popular and has a lot of adoption to get all. all the developers to move to a new platform. So we try to be more reactive and just focus on what is most used and try to make it better. Yeah, I mean, you're certainly right that it will be, I think that's one of the huge challenges I see for Tesos 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 contracts much more secure, also just much more

more arcane, right? Nobody knows these languages, they're much harder to learn. So I think that's going to be very hard to get people 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 will look into that and try to collaborate on making that more secure and and easier for developers too. We are not tied to solidity and Ethereum by any means. So you have learned from your stocking with Bitcoin. Yes.

Otherwise, we would still be working just with Bitcoin and smart contracts in Bitcoin. So you mentioned Zeppelin before. So let's kind of dive into that. So you said it was a kind of a set of modules that came from your 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. When we started, we had built some small projects on our own.

Many doing smart contracts in Bitcoin and some initial experiments in solidity for Ethereum. That's where we realized that we wanted to build like 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 sepling with really basic stuff like some helpers to enable sort of protecting your contracts from common mistakes like very basic ownership patterns or some payment patterns like the the pool payments module that protects you from reentrancy cases. And it was really, really simple in the beginning. I think less than eight contracts were there.

But we launched it and it got some attention from developers that wanted to contribute to a common cause and to improve 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 to solidity development. Basically what we did is we work 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 sepaling. So most of the initial code from open sepeling comes from those kind of consulting gigs, which meant that that code was actually.

being used in production. So the code in Open Sepling 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 traction, we found a community of amazing developers that wanted to contribute their time into advancing the framework. And at the moment, we have lots of contributors and lots of external collaborators and maintainers. But that's how it got started. So is Zeppelin today kind of the most comprehensive set of theorem libraries? Yes, I think so. It's certainly the most used. I know there are some

sort of competing frameworks arising in the ecosystem. I haven't looked at them in much detail, but we certainly have the biggest community and many many projects in the space are using our code 25% of the no even more maybe well i don't want to throw numbers if i can't check them but a big chunk of the projects we get as in coming audit requests are using open sepeling that we as part of after we launched open sepeling 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 smart contracts securely so probably the developers reading our content were wanted us to look at their code to give a final check to their

security and that's one of our our main businesses right now at sepalin so We receive lots of requests every week of auditing smart contracts and a lot of them use open sepillar. Cool. So how big is your team today? 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 quite a volume. Yeah. And we publish. Some of them, when the projects and the teams agree, we publish them on our blog. So we like to make them public 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. of a community, right? And you have a kind of a set of modules and libraries. And then there's also Sepaline OS. What's the difference between Zeppelin OS and those tools that we have so far spoken about? Sure. So open sepeling is the solidity development framework. And in the past year, by working with our audit clients and with the community on building open sepeling, We found that there are some pending challenges that cannot be directly solved just by a framework like a library

because open sampling is just code sitting on GitHub that you can download, compile your project with and just 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 starting this new projects, ZeppelinOS, which can tackle this kind of greater challenges in the space, which are also related to smart contract development and security. In particular, 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 bag that has an easy fix and that could be critical to the correct behavior of your contract,

but you cannot fix it. So that's one of the problems we're trying to tackle. with Sepuling OS, which is how to upgrade your smart contracts once they are in production. And this has a lot of implications and spawns a lot of discussions because it's not easy to maintain sort of 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. So we, for the upgradeability mechanism, we designed a governance system where users of these

on-chain libraries can decide and vote using special tokens for the system and decide which versions of the code are the most secure and the correct versions. Yeah. So let's say 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 someone can kind of vote on, okay, this is a better version of this contract, so let's replace this buck, and let's replace this contract. Would then, you know, does kind of your library or this ZeppelinOS kernel allow, you know,

the existing token holders of that contract to fulfill that function or would that be a separate token? That's one of the goals. But initially, our approach will be a less, involved for smart contract developers our initial proposal is to have an on-chain version of the contracts we already have today on open sepalin so the development of sepeling OS will be iterative we will improve it in the coming months so the end goal is what you described but in in the meantime like we are building an on-chain

set of libraries that can be upgraded. So what is upgraded is not the actual application code, but the library code that we provide. So if anyone using our libraries finds a bug, we can use this governance mechanism for the upgrade ability to fix the bug and that fix can propagate to all the applications using Cepelin OS as a kernel. But eventually we want to provide this 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 the functionalities that are in the Open Zeppelin framework.

is, 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 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 understand. Is it, is the ability for the Zeppelin community to upgrade the function in fixed box? Is that the main selling? point. Yes, that's the main value add of the kernel, I think. You can still, you still have the

option of deploying just your own copy of open sepeling as a library, but then you cannot upgrade it on chain if you find a bug. The additional value provided by using Seppelin OS kernel is that any bug that the community finds on the deployed version of the kernel can be upgraded via this governance upgradability mechanism and 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're using and this way 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 This solves a real problem of the industry.

We recently worked, like last year we worked with the Oger team in migrating their rep token. After we found a critical security vulnerability caused by them using the serpent language, which was very broken. And it was a lot of work to migrate the contract 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 Ogur team and the full Zeppelin 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 upgradable set of libraries. It would just have been a deployment of a new version of the library and voting of the new version by the token holders. And we've seen many other projects get into trouble because they found bugs in production. So it's a real need of the industry. Now you mentioned the token here and how the Zeppelin token is used to upgrade those

sepling contracts that live on chain. Where does the token come from? Who has it? And how, yeah, so how does that work? Yes. So this is an upcoming token. It doesn't exist yet because we want to create an initial version of the kernel before we launch the token. And this token will be used not only for for the kernel upgrade ability mechanism, but also for other components of Sepuling OS. So far we have discussed only the kernel, but we also have other parts planned, which are the smart contract development kit or the SDK and the Sepuling OS marketplace. And this same token will be used in these other components, especially in the marketplace.

But we are not planning to release the token until we have an initial version of the kernel working which requires the token. So that's one of the reasons why we are not doing like a public crowd sale of the SEPToken. We want to have a working prototype with actual users before 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 be if you talk about these are the two parts. So first one being the SDK, what is the Zeppelin OS SDK? Sure. So the SDK is response to another need of the space, which is better contract development tools. This involves on chain tools. which I can expand on in a minute and off-chain tools like web applications to manage and monitor your contracts like what we like to think as 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 state variables directly from a web app. And also developer tools like command line interfaces or testing frameworks. So we want to build a better development environment around smart contract development. And this also involves on-chain tools like what we call the Sepuling OS scheduler. which is basically a set of tools to enable a synchronous execution in smart contracts. And this would give, like right now, any interaction between contracts is done in the context of one user transaction. So a user needs to, like a real human 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 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 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 the basis of this a secure kernel. Once you have simple secure contracts, we can work 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 complexity is via interaction 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 upgrade ability and better development tools

are in more dire need for developers today. 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. 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 sent 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. And then with 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 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 off-chain tools that anyone can run. So the scheduler is a smart contract that, you're that once 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 that is looking at these kind of events, they can decide, okay, I want to call this contract later in the future 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 notes looking at the blockchain for these events.

And when the time comes for the contract to be executed, 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 eclamps of that? Sure. So this examples will sound maybe futuristic, and it's because we don't see many interactions between contracts today.

But we think about Sebeling OS as solving problems in the next five to 10 years in the industries. That's why we are planning so far ahead. But think about developing an application, for example, a betting da app where you need to store some images or the description of the bet on IPFS and you want to create a prediction market on augur to represent the bet. So this contract would connect to the Sepuling OS marketplace to hire IPFS to store the files and to hire auger to create the prediction market.

This is a really simple example, but a DAP that wants to interact with two other DAPs has no way at the moment. There's no standard and no tools to enable these kind of interactions in an easy way. So the marketplace will be just that. The standardization and the tools to enable contracts to pay for each other's services.

it involves like a registry where contracts can publish their services or make their service offerings and define the payment schedule they require to access those services. For example, a per call payment or a one-time payment and you can access to all my services or a monthly payment and that's how the marketplace would work. Okay. So in the example of FileCone, right? Falcon is its own, it's going to be its own blockchain and stuff. So that's not a smart, so how would that work?

Would you have to have some kind of, I don't know, link smart contract on the interim chain that? Yes, exactly. Like at the moment, 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 enable existing smart contract applications to interact in the marketplace. So it's easy for us to write an application that just receives payment through the marketplace

and just reroutes the service request to the other network. But eventually our plan is for new applications to be developed directly on top of the OS, which will enable them to participate in the marketplace natively. Okay. And so I imagine this in the end, you would have almost like a registry of, okay, all these, it's almost like an API call registry, right? Like all of these functionalities are available. Like, here's how you call them. Here's how much it costs. And then that happens via Open Zeppelin. And you guys, 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.

This is our sort of intention of what we want to build. But as with Open Sepalink, the approach we try to take is to listen to the actual community needs. And we think this need will arise. But 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 will do. The objective of Sepuling 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 ZEP token, 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 token that instead of somehow having to acquire

each token, that smart contract could just maybe hold Zepelin tokens. then pay the Zeppelin smart contract presumably 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 Sebelingo S marketplace is better ways for these contracts to pay each other in their own native currencies. And we have some different approaches we think we want to build to tackle this payment problem. one is as you said making the on-chain exchanges we will probably use existing decentralized exchanges like zero x 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 better for some use cases and even like a third method would be just to act for each contract to accept Cep tokens so we just do the the price conversion so a contract can state 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 can convert manually every month or every time the contract owner wants. But 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 Zep token and you mentioned you guys are not doing a token sale, which is unusual in this day of the industry. So what are your plans? How are those going to get into the hands of people that you need 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 fund their applications using the marketplace. But we decided not to do a crowd sale because with our work, with our clients, and also by just looking at the industry, we saw that it's like a double-edged sword 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 the economics or on the trend. trading aspect of the token. So we didn't want to have our slack filled with traders' token 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 the kernel, which gives utility to the sub token and only then offer the token as 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 token sale to anyone. Like we first want to focus on the projects that are going to use the product, the kernel. So initially, we will probably sell directly to projects that want to use the upgradeability kernel. We don't have any plans or concrete dates on when we want the general public to access the tokens. And we want to be very cautious in this because we think that it's tempting to try to get a lot of money from the community and get a big community behind you.

But it also has lots of risks. I mean, not only legally, but also like with what I explained about the community shifting heavily towards the trading part and not focusing on the technology you're building. So we will delay the public sale of the token as much as we can. Yeah, and of course you pointed out before the functionality initially of this token is to kind of vote on the upgrades of these kernel contracts. 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

in being able to do that, right? So you're really going to have a very, very small number of potential parties that can actually make informed decisions there and are also going to be willing to even spend. to time on that. Exactly. Yes. That's also another another reason. And just 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 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 accounts. 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 add 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, Manuel. So what's the roadmap? 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 at what timeline? Yes. So we're planning to launch a very early prototype of the kernel actually next week. but this is just like a microcaronel version of just an upgradable token.

You can check online our, like we started development of SepulingOS in a repo, a repo we called SeppelinOS 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. But we're launching this initial version of the upgradable ERC20 token. which is something that is like a very simple use case of an upgrade ability mechanism. It's not, it doesn't include the token based governance yet. It's just a centrally governed upgrade ability mechanism. But we already have projects that want to use it.

We're working with the Winding Tree team and they're launching their token this week. this week and they want to use this upgradeability mechanism for their own token because they want to be able to fix bugs in production once they launch. And after we have this initial ERC 20 upgradeable ERC 20 version, we're working on a more, on a bigger version of the kernel. And we think we'll have the whole open sepeling library migrated in the into on-chain library form with token-based governance upgradeability by the second half, like mid-2018, so in five months. That's what we're aiming for.

After that, we will continue working on... This would be like the MVP for the kernel with token governance. And after that, we're planning to work on other less core features of the kernel this year in the second half of the year, which are like creating back bounties or enabling token holders to vouch for future versions. So it's a way for users of the kernel to signal they want to fund development of new features even before they are built. Another other less core mechanics of the kernel,

you can read about them on our white paper. And next year we're working on DSDK, which will be a lot of work. And after that, we're focusing on the marketplace on the third year. That's the plan for now, but I want to add, again, the disclaimer, that we want this to be a community driven effort, so we will follow what the industry needs. And fortunately, from our work with Open Zeppelin, we have access to lots of teams building smart contracts.

So we are already collaborating with other teams on the code and on the direction of the project. Cool. Well, Manuela, thanks so much for coming on. This was super interesting to learn about Open Zeppelin and what's coming up here. I think this is a very interesting approach to building. a smart contract and I'm curious if things are going to go that way, but it certainly sounds like a good and coherent thesis. Okay.

Thank you for inviting me. I had a great time once again. 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 learn Ethereum from the basics

and also some more advanced stuff on how the OS will work and on smart contract security. We have a pretty big community on Slack in our Open Seppelin 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