Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Adam Perlow & Asher Manning: Zen Protocol – A Decentralized Financial System

Episode Date: December 6, 2017

We were joined by Founder Adam Perlow and Developer Asher Manning of Zen, a public blockchain project focused on building a decentralized financial system. The core premise of Zen is that none of the public blockchain networks are focused on financial asset. Zen is aiming to fill that gap through a Bitcoin-like UTXO architecture that supports multiple asset and smart contracts to enforce complex ownership rules. We talked through their original design choices, their use of formal verification, connection to Bitcoin and vision for a fully decentralized financial system. Topics covered in this episode: Why existing public blockchains are ill-suited for financial instruments Why Zen chose to use a Bitcoin-like UTXO architecture How Zen uses formal verification to allow smart contracts without a virtual machine or needing gas How the Active Contract Set reduces the burden on the miners Walking through creating, trading and settling a call option on Zen How Zen allows payments to be settled in Bitcoin Getting data from the outside world with oracles Zen’s use of Proof-of-Work regulated by on-chain governance Episode links: Zen Protocol - A Financial Engine Zen Protocol - Whitepaper Zen Protocol - Deck Google Campus Presentation - YouTube Zen - Alpha Version Zen Protocol Founders Film - YouTube Oracles and Zen – Zen Protocol Zen’s contract lifecycle – Zen Protocol This episode is hosted by Brian Fabian Crain. Show notes and listening options: epicenter.tv/212

This is Epicenter, Episode 212, with guests Adam Perlow and Asher Manning. This episode of Epicenter is brought you by Shapeshift.io, the easiest, fastest, and most secure way to swap your digital assets. Don't run a risk of leaving your funds on a centralized exchange. Visit Shapeshift.io to get started. Hello and welcome to Epicenter, the show which talks about the technologies, projects, and startups driving decentralization and the global blockchain revolution. My name is Brian Faruan Crane. I'm here all by myself today. It's been a long time that I've done an episode by myself.

I think it happened like once or twice before. But I'm here today with Adam Perlow and Ash of the Zen Protocol. And it's super interesting, crazy and lots, lots of new ideas, a project to build a decentralized financial system. So Adam and Ash, thanks so much for joining me today. Hi Brian, thanks for taking the time to meet us. Yeah, thanks. Yeah, so I spent quite a bit of time today, you know, kind of looking at what you guys are building and it's very interesting.

I think there are a lot of, a lot of sort of key things that we have, a lot of key components of blockchains, how they work today. You guys are doing kind of differently and it works out very interestingly. So there's going to be a lot of stuff to cover here and I'm sure we won't get to everything. thing, but I look forward to that. But maybe before we get into Zen, Adam, can you share with us? Like, how did you first get involved in Bitcoin and what has been kind of like your journey in this industry? So personally, I found out about Bitcoin in 2011. At the time, a friend just showed me about this website. And, you know, he said, oh, you know, there's Silk Road. And I essentially saw, oh, well, that's really cool that you have bitcoins there.

Didn't go much on the site after that point, but I was very fascinated with the fact that there's a technology that could survive in such an environment. And, you know, I researched it. I saw the economic aspects of it, and I dived into it. Then essentially, I first started with trying to, you know, help build communities. I was one of the found, like, first people in the Israeli Bitcoin community.

Then we essentially, maybe when I came up, there were about another five people in Israel that knew about Bitcoin. After that, I was developing internally a wallet for essentially me and Nathan were building a wallet and another individual called Ellie that essentially was some sort of combination between changed a bit and auger. Essentially, it was one-click, one-click social media tipping and essentially entering, let's say, contracts over Facebook, YouTube, and whatever, Twitter. then essentially after that we decided to move on to Zen and I can talk more about that later and what about you Ash?

So I first thought about Bitcoin also in 2011. I suppose I've always been very interested in technology. Bitcoin was new and exciting then. I didn't really touch Bitcoin for a long time, not until I met Adam actually. I was in Israel working with a cybersecurity. company and a mutual friend introduced me to Adam and Nathan and they told me about this idea they they had um for the Zen protocol we discussed this we decided to go and do it together cool interesting well Adam I'm curious to serve on a high level can you tell me how do you look at

blockchain like what what do you think is interesting about blockchain sure so um I think that what's interesting is it that it's for the first time where you're essentially people have a way to assert and transfer ownership of things without needing to rely on, you know, some trusted third party. I think that's really the heart of it. I think Bitcoin was like a goal and the blockchain was a mechanism to achieve that goal. And I think although this may sound very simplistic, I think that it's most obvious that, you know, the blockchain is going to excel at the goal that it was initially designed for.

Okay. And now, so you mentioned, In 2016, you guys started working on, or you started working on the Zen Protocol. What's kind of the origin story of that and the vision that you guys came up with then? So personally, I was kind of, it's very funny by serpentipity. I was somehow found myself, you know, behind them, whether it was, like somehow had a personal connection with colored coins or a master coin, you know, even Ethereum. And I saw how all these projects came and went or some of them are still ongoing. And essentially, you know, Color coins was motivated by this idea of let's move some asset around,

but we don't want it just to be Bitcoin's, right? Let's have more assets. And then you had Mastercoin that said, you know, the Bitcoin 2.0, the first go round of this, like, new blockchain projects. And Mastercoin said, let's have more complex conditions. So essentially, you know, we want to have, let's say, let's say there's 20,000. or 30 different types of transactions you can do on MasterCoy. And Vitalik was working on that at the time, and he said, well, I want to have more programmability.

I don't want to have this restriction of just, you know, let's say 20 or 30 functions that I can do. And I think that Ethereum went in that direction of enabling something very generalized and programmable. But essentially, what I think that still the focus is, is you want really two things that Bitcoin doesn't provide. I'm not talking about like adjectives, like more transactions. actions per second or something. I mean, two like core things, which essentially, you know,

support for multiple assets and ownership under complex conditions. And we felt that none of these platforms are doing it correctly. And if you want to essentially facilitate a financial system, not just, you know, digital money, but actually have a bank in your pocket. You need to build something that, you know, is custom designed to do that. And that was essentially the motivation that we saw, you know, we saw in 2016, after the Dow hack happened, we had this feeling that there was something like that could be done better for a while looking at Ethereum grow. But then actually the Dow hack happened, it was like confirmed. He said, okay, for sure we can do something better. It's not better with Ethereum. Like each project has its own things that it's good at. But for this specific

use case of, let's say, owning your assets and transferring them under conditions, we felt that we could do something better. And that's how essentially Zen came about. Okay, this is good. I like this definition, right? So you say, okay, decentralized financial system, you need basically, well, Bitcoin has, right, the money transfer, but then you need to be able to do it with multiple assets. And you need to have, like, complex conditions.

And of course, if you talk about complex conditions, you start talking about loans or derivatives and options, et cetera, et cetera, right? Yeah. Sure. many people would say, but you can do that on Ethereum, right? You can have multiple assets. You can write smart contracts to mirror basically any kind of derivative. So what makes Ethereum ill-suited for this? So I don't want to attack Ethereum in any way because I think that the design decision there is to enable a platform which is programmable and that allows people to try to innovate.

And in order to be able to do that, you have to kind of say, you know, we're not going to specialize, we're not going to do any one thing good in order to leave, you know, room, air in the room for the other kind of like use cases, let's say. Um, now if you look at it how Ethereum came about, by the way, excuse me for my cold, um, but yeah, so if you look at how Ethereum came about, um, it was like, first it was going to be, you know, more complex scripts on Primecoin. Um, and then it moved into its own thing. And currently the architecture is such where you have like these, these accounts and you, you, You have these externally owned accounts and internally owned accounts, and that's how the whole thing works.

But what people essentially really want to do is they don't want to have these daps. They don't want to have a DAP that's acting like a token or a doubt that's acting like a contract and just like this sort of programmability in there. What I think they really want is, again, they want to own assets under some conditions. And they want to reason about these assets in that way. And that's where, let's say, with us, you know, we don't have any ERC20. we actually have tokens. It's a distinct object. Even in Bitcoin, actually, it's like,

it's just presumed because there's only one coin, right? That the input and output is always Bitcoin's. But with us, we actually, you know, each token has like an identifier. And we have tokens as first class citizens, as we call them. And then we have contracts. And contracts you can think of very similar to like a pay to script hash in Bitcoin. Except with us, the pay to script hash, rather than being like a one-time use transaction,

that pay-to-script hash is essentially held in the active contract set. So if you want to spend something locked to pay-to-script hash, you have to be able to validate it against a contract. And the contract is a logic that will say, okay, you're allowed to release this under if these conditions are fulfilled. Okay, so let's take a step back from here to provide some context for this. So I think we, you know, you kind of described, I think, quite well, right? this general idea of Zen as his decentralized financial system and, you know, define kind of what

those additional pieces are that are needed. So multiple tokens and the complex conditions, there are anything else? Is that, that's in view of you. That's kind of the full thing. Those are like, let's say the, I'd say the components of it, but there's a lot of prerequisites, I'd say, in there as well. So no one's going to be using. this if there's unnecessary exposure to risk. So you don't want to replace your banker with a contract that could essentially, you know, lose your money by mistake. And you don't want to replace your banker with, let's say, being exposed to assets, which are very volatile as a cryptocurrency. Maybe I'm just a normal individual, you know, I just want to do my banking without a bank, essentially. But I don't,

I'm not even interested in, you know, Bitcoin or ether, any sort of crypto token. So this necessary exposure to, let's say, a native token is something that, that, that, that, you know, that, you know, I think is going to hold, you know, the current crypto system is back. So one prerequisite is, you know, essentially security, predictability of the outcome. And then another one, I'd say, is actually being useful, doing something that actually makes a difference in people's lives. That's essentially the whole motivation for us building an Oracle mechanism because, you know, it's nice to have some more contracts and everything, but what are they worth if they can't,

you know, operate on, let's say, interesting events. And the final one I'd say is scalability. And I hate to say that because it's kind of like become like a meme already, blockchain scalability. But you do, we have seen with Bitcoin where it's at the point where if you don't take that in mind when designing the system initially, then it may make something bad may happen that may permanently change the course of, you know, the outcome of that protocol. Okay, very good.

So we have this additional kind of design requirements, the security thing. And of course you mentioned the DARA incident before, and I think we see that continuously in the theorem, the challenges of that. Then the usefulness. And of course, I think everybody or almost most people listening will understand the significance of oracles in that context that you can basically have outside information so that some of these contracts or instruments can actually. respond to events in the world and scalability. Of course, that's also a perennial topic. Great. Okay, I think that gives a good context. Now, it seems you guys are very inspired by Bitcoin and you built this in this kind of UTXO approach. Now, actually, maybe, I think a lot of people will not be familiar with UTXO versus Ethereum's model. Can you explain?

Just very briefly, kind of like, what is this UTXO approach? What is Ethereum's model? And like, why did you guys choose the Bitcoin way? Well, actually since I think this is a great question to also have Ash come on and comment about that. Right. So I suppose I said the UTXO approach is much more simple, actually, than to have an account space system.

You're envisioning tokens. as something that can be spent and split into more tokens. And they are just representative of some kind of value. You can split them, you can consume them to make new ones at the same amount. Every transaction outputs the same amount that it was input. That's pretty much it really. There's nothing more than that. You don't need to keep track of any kind of account balance. You don't need to exchange anything through any kind of smart contract.

you're just locking something to a public key saying, okay, this isn't mine anymore, now it's on an analysis. The accounts-based system in Ethereum is far more complex. Probably the reason Ethereum ended up with an account system is because they decided they wanted to be able to do general-purpose computation. So they designed Ethereum not to be a network

that can send around assets, but to actually function as a computer. So once you're functioning as a computer and you have the ability to stall state, you might as well represent assets as just part of this state as entries in some database. So the accounts base system in Ethereum is probably not nearly as simple as a Bitcoin-style system. It's just that once you already have all of the complexity of maintaining some kind of decentralized computer, you might as well go the extra mile into accounts as well.

Okay, maybe I can just sort of like paraphrase that. And let me see if I get this right. Because you guys say as a sort of primitive unit in the system, right, is assets, right? So different types of assets. And then the other thing, right, the computation is kind of like associated with particular asset. And it manages like ownership of that asset, right? So kind of the asset stays as this like fundamental unit and like it is in Bitcoin, right? Or the Bitcoin is the fundamental unit.

So it's kind of natural to just extend that a bit. Whereas in Ethereum, right, because you general computation, you can do anything and contracts calling each other, there's no assets aren't a fundamental unit, right? So you get rid of assets and you kind of build it later in and of course you end up with a completely different architecture. Yeah, I think that's very accurate. I'd also say that one of the things that you could get around, maybe quantum is trying to do it right now. but essentially using a gas system not knowing what the transaction fee is ahead of time kind of would require an accounts approach. I find it very hard to, how would you do UTXOs if you don't know what the transaction fee

you're offering is ahead of time? So I think that's kind of like a design requirement on Ethereum set. Okay, okay. So this is now, again, you kind of rephrases. So of course in Ethereum, right, we have this system like, okay, people sending computation, I mean, the network doesn't necessarily know how long it's going to take, right? So they have to send along with it basically money and then that gets paid to minus depending on how much computational steps it takes.

And of course, in Bitcoin, it's just paid based on the size of the transaction. And then I guess in the theorem, right, the size of the transaction doesn't really tell you anything about the computational complexity. And so with you guys, I guess you have a similar thing, right, where the size of a transaction isn't a good indicator of how much work it is going to be to execute that transaction. Is that correct, right? So with us, actually, that's our, I'd say, main scientific contribution that Ash has done,

which changes that up. I want to, yeah. Yeah, so in a theory, because you want to be able to do any kind of computation, they designed Ethereum to be able to support this by having this gas system where you tell the Ethereum virtual machine to do all of these instructions and each time it looks at the instruction,

it looks up the gas price for that instruction. It looks up how much gas you've paid for. If you have enough gas to cover that instruction, then it subtracts, It subtracts the gas from the gas you paid for, and then executes the instruction, and it proceeds in this loop. Now, this model of giving the virtual machine

a load of instructions is part of Ethereum's architecture of being a computer. They wanted to make it operate at the lowest level possible to give it the greatest possible generality. We saw with incidents like the Dow and the Parity Multisig, or what hacks, having a very low-level system doesn't necessarily make your system very secure. And if you want to be doing any kind of decentralized finance,

you need to be able to inspire a large, a high degree of trust within smart contracts. So we looked at what we could be doing to give greater security guarantees in smart contracts. We're interested in language-based security. So instead of going with the absolute lowest level language, because it's the simplest, we decided actually, we're going to go with something extremely high level.

And it turns out when you have extremely high level languages, you can actually use them to express things like their own resource costs, which is very unusual. Probably very few people outside of academia would ever have seen this done. But we've kind of brought this into the real world somewhat. So we're having smart contracts that must express their own resource cost, which can then be quickly verified.

So because we know the resource cost of any contract, which can be parameterized by inputs or whatever you want, it doesn't have to be fixed, but there has to be some expression that you can give for it. Since you know how long a contract is going to take to run before you run it, you don't have to do all that keeping track of gas. Essentially, let me just add the way I see it is that, you know, yeah, in order to enable, like, loops and recursion, the only way to do it is by implementing this, putting everything under this, like, virtual machine umbrella and having this counter in there. And I think that we're probably the only system that both allows you to do recursion on arbitrary inputs, while at the same time not requiring this sort of counter or virtual machine to do that.

And that's all this F-star formal verification stuff, Ashthas has been talking. that sounds cool right so I get that in Ethereum it's kind of complex because you send your contract in there or your transaction in there is going to result in some computation you have to send money along with it so it has enough for that computation you don't know exactly how much or maybe or the network at least doesn't know when that transaction comes how much it's going to be and and of course if you can if I can prove okay this is going to be this many steps, I can send exactly that amount, pay for exactly the transaction, so I don't have, we don't have gas anymore. That sounds good. Is that such a huge deal? Like, why is it so great

to get rid of gas? So it's not that, I mean, beyond, I think Ash previously pointed out, let's say those four times as much steps just to like kind of monitor the gas. It's beyond that. It's like, I think the gas is pushing the requirement for this virtual machine rather than the other way around. Once you can get rid of gas, then you can start treat, you can treat a contract as its own independent object. You don't need to look at a contract as part of the greater thing. Because think of it, if you have no way of determining the price of executing the contract, then the only way that you can be able to deal with it as a miner is by using this virtual machine. But with us, since you don't need the gas and you don't need the virtual machine,

you can evaluate each of these contracts on its own. Not to confuse the viewers, but that's like essentially what our analogy for, let's say, maybe a virtual machine, although very different is our active contract set. So this set of contracts that can currently operate. But you can view each of these contracts as its own independent computer. Now, and the benefit of this is essentially a few things. Not only do we have language-based security, which is the whole form of verification, and that kind of stuff.

It's also, I don't even know how to call it, architecture-based security. So let's take the recent bug that you had where someone essentially deleted, committed suicide on an ether account. And that ether account was used to validate a multi-sid contract. Now, because of this paradigm where you have a virtual machine and one thing calls the other to get things,

rather than these independent components, not even like each independent contract, you didn't have built in, let's say, good mechanism by which you could like reactivate that contract, revive that contract, and a lot of money was lost. So this idea of having this isolation and this idea of this isolation and independent evaluation enables you to essentially enables a lot more scalability because it's not a single threaded process anymore. It's like a multi-threaded process. It's like running a GPU rather than a CPU. You can think of it that way. Each of our contract can run in parallel and they can

run in compiled version because they can run compiled, that's also a lot faster. So we don't interpret things with us essentially. Once you've activated a contract, miners take its code. They extract the S-star into essentially native machine code. They compile it to that. And then whenever you're doing an operation that depends on one of these contracts, it just runs super quick at the machine code level essentially. Okay, I think I sort of get it. Given that you don't know the cost, you must have gas. And given that you have gas, you can't essentially compile the code in the contracts, natively. You're forced to interpret it, if you don't know the gas cost. You're forced to go along one

instruction at a time, keeping track of the gas cost for every instruction. Every instruction you're looking up its gas price. You're saying if the user has enough gas, you're subtracting it and going on to the next instruction. Why can you compile it and have gas? Because you have to be doing this interpretation one by one of these instructions. You're not necessarily going through these instructions. You want to be able to stop when you run out of gas. Right, right.

I mean, I guess I could imagine, let's say I have to run the contract before. Then maybe you can compile it in some of the sense that you, you already know how much gas it costs. Well, no, you only know how much gas it's going to use if it's given the exact same. it's given the exact same input and the exact same state. Yeah, okay. You're not invoking it every time with the exact same input on the exact same state. So you have no way of knowing. Yeah, okay. No, I mean, that sounds, uh, it sounds great.

And of course, the whole formal verification thing, right, is also something that has been, uh, much talked about. I think mainly in the context of security, right? Uh, but that's also very interesting. I think these kind of other simplifications. that come along with it. I want to note that this isn't theoretical also. I encourage to your viewers to go right now to alpha.zmproticle.com. It's not a concept.

It's like we actually have something working. So yeah, let's see. Let's see if we're right. Let's see if it breaks. Yeah. So what I found interesting reading through you guys' material is this, this UTXO approach. And of course, what actually it reminded me of a lot

was Corder by R3, right, which is also very, very Bitcoin inspired. And it also has this kind of like modular thing where things are kind of their own entities and get like executed and they can have their own like kind of verifiers or little consensus processes as opposed to having like one big global system. Do you also see a lot of parallels to Cora? Personally, I got to say, although we just talked about it right before the show, the last I remember looking at Korda was a few years. It's been a while until I really took an in-depth look at it.

And essentially, you know, my current went, right? And I think he had maybe a lot of input on the design. So maybe that's why they went with Bitcoin. I'd say it is probably a lot, a lot very similar because they're a blockchain built for finance and we're a blockchain built for finance. The difference is just that, you know, one of them is for selling it to banks and we're, you know, for giving people more freedom. So, yeah, they may very well have a lot of similarity there, I'd say.

Yeah, yeah, of course, that is the big difference, right? Is that this is meant to be a public network, or this is a public network and Corda's permission network, I think. But, yeah, I mean, I mean, I'm not, I don't understand Corda that well. You know, we did, I guess, a podcast about it with Mike and Richard once upon a time and kind of read about it and stuff, but, um, but it sounds very similar. I think a lot of things are similar and I haven't seen that elsewhere. I don't think I've ever seen another project that kind of went a similar direction. The UTXOs you mean? Yeah, this yeah, this kind of UTXO smart

contract mix. I think it's a lot, you know, simpler for a developer to reason maybe about accounts initially, right? Maybe you want to abstract that stuff away. Maybe you want to have the tools like SDK where the developer is sinking in terms of a wallet rather than in terms of which, you know, UTXO is you going to spend right now. That I'm very empathetic to. I guess the thing is, like, imagine that for a second that you were as a node or as a user, you were like partitioned from the Bitcoin network. So, like the UTXO isn't itself like a cryptographic thing of, it's like a cryptographic object of importance. And you know it's yours. You don't know if it's been spent or not, but you still have something. Whereas with the account system, it's like,

you kind of need everything or you have nothing. So it's like, it's a very, it's a minute difference, but yet it can be important. So yeah, I think, I think that in general, it enables a lot of things at a technical level, but at a usability level, you know, people should be thinking about UTXOs, maybe. This episode is brought to you by ShapeShift, the world's leading trustless digital asset exchange quickly swap between doesn't. dozens of leading cryptocurrencies including Bitcoin, Ether, Zcash, Gnosis, Monero, Golem, Auger, and so many more. When you go to Shapeshift.io, you simply select your currency pair, give them your receiving

address, send the coins, and boom. Shapeshift is not your traditional cryptocurrency exchange. You don't need to create an account. You don't need to give them your personal information and they don't hold your coins, so you are never at risk from a hacker or other malicious actor. ShapeShift has competitive rates and has even integrated in some of your favorite wallet apps like Jacks. So you can swap your digital assets directly within your wallet just as easily as putting on your slippers. Whenever you see that good-looking fox, you know that's where Shapeshift is.

So to get started, visit Shapeshift.io and start trading. And we'd like to thank Shapeshift for their supportive app center. Well, let's speak about this active contract set. Can you explain how that works? So the idea is you see this huge growth in state space in Ethereum. And that makes sense. It's not a criticism, like legitimate, but essentially the idea is to say, well, why do we need these contracts? I just sit around there.

And actually, maybe Ethereum, more this is the kind of thinking, like, let's have them commit suicide, right? We have two types of contracts. We have active contracts and inactive contracts. Now, an inactive contract can only receive funds. And the identifier of the inactive contract is the hash of its code. So it doesn't have, that contract doesn't have state directly. It just has code that stays fixed. You take a hash of that code, and that's your contract identifier.

And you can always send tokens to contract. However, releasing tokens from that contract, sending funds from a contract, or using a contract to issue new tokens, that's a step that requires activation. because, say for example, I lock up funds in a contract. Well, now we need the minor and then I say, okay, I want to unlock the funds. How does a minor know whether he should listen to me or not? The only way the minor knows is by storing that contract code. And essentially, the active contract set is the area,

it's the group of contracts, which right now people are paying the miners to store. So essentially, if a contract is active, you can spend funds locked it, And miners have to store active contracts. And they get rid of the contract once it runs out of the activation fee. Okay, so I think on a high level, right, that kind of makes sense, right? So I'm putting in this contract, right? Of course, it creates a burden on the miners and on the network, right? So I pay for the time that it lives there, right?

Not like an Ethereum where I put it in this contract, I pay once, it's there forever. So that I understand. But then let's say there's a bunch of assets in there and this runs out, right, out of money. And you said, okay, but somebody can reactivate it. But then how can you reactivate it if the minor kind of like throws away, it doesn't have it anymore? Like how does that work? Sure. So let's say, and maybe we'll use this example again.

Let's say we're talking about I'm writing a call option. So a call option essentially says, you're going to pay me money today for the event that, let's say, in a month from now, if the price goes above what we call a strike price. So if the price of the asset of the stock goes above a strike price, then I owe you the difference between the strike and the appreciation of that asset. People essentially use call options when they're bullish in the short term, when they think an asset is going to go up in the short term and they want to essentially, you know, capture their gains and they don't want to be exposed to any downside. It's also a hedging tool. So essentially, let's say I'm going to write you a call option on Apple. We're going to look at it again in 30 days. So I'm going to create that contract. I'm going to, step A is going to be writing the contract code, creating the contract, you know, identifier, which is done automatically. And, man, that's step one, right?

You read that contract and you make sure that it's a legitimate contract that's not trying to steal any funds from you. You know that, you know, if the price of Apple goes above, let's say, $200, dollars within the next 30 days, then you're going to be able to essentially take the funds back. So after I wrote the contract, I'm going to then activate it. Now, once I activate it, I essentially, what I'm going to do is I'm going to attach an activation fee. Let's just call it what we call the contract sacrifice. And let's say I'm going to provide a contract sacrifice for two blocks. And by the way, I should note that while we have different sorts of fees, so we have a different

sorts of fees. So we have computation fees, which is like for the cost of time. And we have the active contracts at fees, which are just like storage fees. So let's say I'm going to pay whatever, what it costs to activate for two blocks. Within that two blocks, you know, we're going to activate the contract. And then I'm sorry, and then I'm going to send collateral to it. And then that contract will issue me, like the, it'll issue me the writer's token. So I'm going to hold a token now of the person who just wrote a call option. then you're going to come in. You're going to pay the premium, right?

Let's say it's five bucks. You're going to pay that premium, and then that contract will issue you a token saying, you know, if Apple goes up and you have this token, then you can get the spread out. And after that operation has been done, after we each have the tokens that entitled us to our rights, that contract goes inactive.

Now, both of us have a vested interest to keep this contract in our local computer, in our local memory, right? In the event, you know, whoever like wins, they need to get their money out. Now, let's say for all intents and purposes for the next 29 days, nothing interesting has happened. The price of Apple hasn't risen above 200. That contract just sits there inactive. But in the meantime, me and you can trade these tokens, right? So we can trade these tokens irregardless of the contract and irregardless of the collateral that that contract holds. So we're just moving these tokens around at free will

and no one cares about what's going on in the contract. It's only at the end, like, at the end of the position in our example where all of a sudden Apple jumps above 200 then you say, okay, I'm going to activate this contract and remove my collateral. And then essentially what you're going to do is you're going to

retake the code, you're going to, you know, put it back in the active set. It'll activate for a couple blocks. You'll take out your money and that's going to be it. Yeah, this is amazing. Yeah, I understood that, but maybe we just maybe just walk through it again because I think this is

like a really key thing here but it's okay so we have the the call option first right which I guess the exact substance doesn't matter so much but it's basically like a contract that you know means that I pay

something for a right and then if the share price is at a certain point I can make money and if it isn't there then it's just worthless to me So you create this option, right? So creating this option means you basically create a bunch of smart contract code. You deploy it on a network and you pay for it to live there for some time, right?

This is a storage fee. Now, in this case, even though this option would only become its due date. Expirate. Yeah, it's expiry date. It's like a month later, you're actually only paying for. storage for like, I don't know, an hour or something like that, right? Because that is the window of time that then I can come in and say, I'm going to take the other side of this. I'm going to also, you know, put in some collateral. So we both have some collateral in there. You get a token. I also get a token, right? So we both have a token that basically represents the opposite side of this trade. Then this contract goes like, dormant. So the miners throw it away. But we keep it locally, right? We keep that contract code. Now, we can trade the token. I presume if you trade the token, right, you'd also, like, let's say

we sold it to a third party, you'd have to send them along with it, the contract code. But, you know, let's say we can trade this token, Apple shares change in price, so the tokens change in value. and then after a month, you know, let's say I was right, the Apple Chair went away. I fought, so my options now worth a whole bunch of money. So I can basically say, I'm going to pay or I'm going to send back this code on the chain. I'm going to pay this activation fee again, and I pay to execute it and to basically get my money. there. So the contract only really is there exactly when it needs to be there and is paid for exactly then. But at the same time, you can still trade that value the entire time.

Yeah. Yeah, that's exactly what's going on. And I guess, let me, I guess the implication of that too, I remember reading that somewhere, but I didn't fully understand it, but I think now I understand it. I guess this also means that now, let's say you, like my, my own, option is worth, you know, I'd get from you $100 at this point. So I can go on the chain, right, pay for that activation fee, pay for the computation fee, and then I get my money, but of course I pay those fees. Whereas could you also do it that basically you pay me out of band and now I don't, like maybe now it's not possible for me to claim anything anymore? Yeah. Does that work as well so that you don't actually have to.

execute it on chain? Yeah, that's that's great intuition. So that's exactly, that's exactly, something that I find to be very attractive, essentially saying, you know, we're going to, we're going to view these contracts as like an enforcement mechanism more than the actual payment. And maybe I have these like outstanding debts and I'm entering all these sort of deals. And the reason that, you know, maybe I'm doing 100 deals a day, but I'll only have like a contract with collateral for let's say 10 of those deals. And I can, be proving, you know, that I, you know, someone entered a position. I paid them when I needed to pay, and I can prove that, you know, I've made these transactions. Um, yeah, that I've essentially

made these transactions and pay you, like you said, out of band. So you bought the, you bought the option, right? And then, you know, you won. And you, you, you sent this request. You send this token to me. And then after you sent me the token back, I'm going to, you know, send you money. Um, now what, what you could do essentially is you could come to the contract and say, hey, you know, I can show that I sent added the token, but he didn't send me the money, right? Now I need to get my money plus a penalty, for example. Yeah, yeah. No, this is very interesting.

I think very just unusual. I really like how it's different from other blockchain architectures that I've kind of seen. And yeah, so I guess with this multi-token approach, there's no, assets just get basically, you know, treated the same way. It makes sense. So there is, of course, this native token, Zen. And now that doesn't get treated exactly the same way, right? Because that is what you use to pay for. Is it the storage fee is just paid in Zen? Was that right? you know in general right the way i view it is that why why have another token the token essentially does two things um obviously first is it's it acts as you know an economic subsidy both for development

today and you know mine is in the future um so so and or other people in the future um essentially so it acts as an economic subsidy and the second thing is it acts as a focal point so coming in and saying okay, we're all going to accept, you know, this one thing and agreed that, you know, this should be used for certain operations. So some operations could be, for example, voting saying, you know, we want to, you want to vote on what happens. And the other operation, for example, could be when you have a sensitive, when you have a sensitive scenario, like the contract sacrifice. So when I'm inserting a contract in the active contract set, any minor can decide to activate that contract. But that contract is going to be sitting there, you know, active maybe for another 100 blocks. and he's not the one bearing of that externality.

He's not the one bearing of that cost of storage. So when I make the contract sacrifice, that contract sacrifice is essentially split up among all the miners. And we need to make sure that they're paid the contract sacrifice and a invaluable token. Because, for example, compare this with a transaction fee. Well, in a transaction fee, if a miner wants to waste his time by, you know, mining a worthless transaction,

well, then that's, you know, whatever, his prerogative, right? He's found the proof of work and he can waste he can take transactions fees, which are essentially useless. But when he's creating essentially bloat on the system, we need to ensure that the thing that's being made a payment and will have some value. So that's the only difference between the other tokens. But there's no real difference, just to make my phone.

Sorry. Right, right. Because if a minor executes the computation, then it's just them and others don't have to actually execute it. So right. Everyone has to do validation, but essentially, yeah, people, people go ahead and they do validation, but they're not like, it's easier to, let's say, place a limit on validation, just like in Bitcoin. You have, you know, size limit, like one megabyte, but there's also like some sync hash, you know,

limits on certain operations. And the same thing going to happen here. We're going to say, okay, you know, there's limitations on the amount of computation of mine I can do, but the amount of time you can activate a contract for, you know, that's justifiably limitless. I mean, I guess maybe I would phrase it like that is that if you have a minor, right, so then they have an incentive to optimize what they actually execute, right, because they keep those fees, right? So they want to choose something valuable. They don't want to choose something useless.

But if it's the activation, right, where maybe it's for many, many periods going to be used and socialized, I guess, then it doesn't, it creates this kind of tragedy of the commons problem, maybe. Yeah, tragedy of the commons and also the ability to just easily attack the system. Because let's say we're counting, you know, just points.

And one point has, you know, the value of a thousand x and the other point has a value of one x um if we're just counting it on a on a purely like absolute mechanism without taking into account like um you know the rates that these things are going for then it would be very easy for someone to pay um in the cheap points and in the expensive ones right okay yeah well let's let's move to the next thing let's speak a little bit about uh bitcoin integration because you guys have some interesting and weird kind of connection to the Bitcoin system. Can you explain how that works?

Sure. So the idea here is, you know, the Sun was always wanting to come in as like sort of a side chain, not exactly a side chain, but essentially as providing help to Bitcoin in some manner. So saying we're, you know, we're essentially, we're not trying to compete with Bitcoin, we're providing complimentary, complimentary services to it. you know, having other tokens and that kind of stuff is actually something useful, sometimes. And the way that, you know, we're doing Bitcoin integration is essentially

the Zen miners, they're running a, they're mining, you know, Zen blocks, but they're running a Bitcoin node. And while they're running this Bitcoin node, what they're being forced to do is they're forced to take the state of the Bitcoin network, essentially, and commit it in the Zen block. So when a Zen miner finds a Zen block, not only is he ordering all the transactions in the block. He's also taking the data that he's like reporting to what he thinks happened in the Bitcoin network. And other Myers will reject his block if they think that, you know, he lied about what happened in Bitcoin. This property essentially allows you to, um, it allows other people to essentially use Bitcoin transactions as an argument for smart contracts. So I can,

for example, in our call option, like example, I can write a smart contract that says, um, you can pay me the premium to my Bitcoin address, for example. Yeah, so the Bitcoin integration, it essentially enables, you know, the interaction. For example, you could also even imagine back in the day, like you had Satoshi Dice. So you can imagine that people, you know, since it's a very quick transaction, you send, they send back, that Satoshi Dice would have like a small basket of collateral sitting there, making sure that, you know, everyone can trust them while all these transactions are going on. So let's just do this thing of, okay, so we have this call option on Zen and now we want to have, you know, we have this financial instrument on Zen, but now we want to have a Bitcoin payment on the Bitcoin chain that, let's say, you know, for payment that I owe or something like that.

And okay, I get that basically the headers of the Bitcoin chain are kind of written into the Zen chain. So I guess that means you can, so would it work like this? You send me some Bitcoins. Because the Bitcoin headers are in the Zen chain, you can basically kind of provide like an SPV proof on the Zen chain, the proof that you actually paid that Bitcoin and then the Zen protocol on the Zen chain. understands that? Is that how it works? Exactly. Yeah. Thank you. Okay. Okay. Amazing.

Pretty late, but let's briefly speak about oracles at least. Yeah, what's the role of oracles? So essentially the oracles, you know, are like not built into the protocol, but they're still a very necessary component to have. And, you know, we provided the first ones. But essentially the way that we're doing it is we're saying, listen, many of the assumptions made in previous Oracle mechanisms were saying maybe someone wants to ask any question. But essentially, it's like a pull mechanism in other Oracle. So essentially, you know, the Smart Contract and Ethereum Smart Contract would ask the Oracle for some data and then the Oracle would go and provide that data.

With us, it's more of a push mechanism. So kind of what happens here is the Oracle is taking the state of all the datasets and it believes that. someone may be interested in. So stock prices, you know, weather info, whatever, flight cancellations, all this kind of stuff. And he's sorting that into a merkle tree. And he's committing to this Merkel tree every block. Now, what that enables is then, right, it's very cheap to make the commitment. And he can also charge for payment. So when he's writing, when he's doing this marble tree, he's like salting these leaves. So he's creating the sort of secret that you need to have in order to be able to prove of what the price was.

And so then what the Oracle does is, you know, he just, he goes about his daily business. He doesn't, there's no like complexity really here. He's just, you know, gathering data from any APIs and doing this like continuous process, very methodological. And in the event that is needed, in the event that, let's say, I default on a contract, how do you prove what the price of Apple was, right? So what you're going to do is you're going to go, you're going to pay that Oracle, you're going to say, listen, please provide me with the path in the secret.

that essentially will enable me to prove to the smart contract what the price of Apple is at the time. So me and you are going to agree when you write the contract who the single oracle or a set of oracles will be. In the event one of them is down or one of them is malicious or whatever. But we're going to agree on, let's say, a set of five oracles, right? And essentially, you know, most of the time we're going to settle without the Oracle. But in the event that we need to settle, it's not even the contract talking to the Oracle. You'll just go, you'll ping the Oracle, you'll say, hey, man, I need to have this proof.

He'll provide you the proof, and then you can use that proof in the contract. And that's how the contract works. The oracles work, I mean. One of the things I found interesting about this, I think you mentioned that somewhere in the paper or something, is the regulatory aspect of that, right? Because an Oracle, of course, can be, like, let's say an Oracle writes to a contract on Ethereum,

and that contract is then some financial instrument. Well, that can be kind of tricky, right? because all of a sudden it's like a K-based, is regulated activity, et cetera. Whereas here, basically, it's almost like the Oracle is just a cryptographic data feed. It's kind of like writing that into the chain and then it has to be queried and it just provides his answer.

That can then be used to execute whatever contract on Zen without the Oracle actually being involved there. Exactly, exactly. So for example, let's say maybe, um, uh, One thing that may be totally legitimate in a country, maybe, you know, a normal stock, right? Or a normal C of D, let's say. But then that same country may have a ban on, you know, highly leveraged binary options. But the Oracle, as far as the Oracle's concerned, he doesn't know.

He's just reporting the price of Apple. Okay. Well, let's speak now about another complex topic. So the consensus algorithm, so you guys have this also, again, like unusual things. that I haven't seen anywhere else, which is basically that you have these hashing algorithms, like in Bitcoin, but except that there are several different ones, and then one uses the tokens to basically vote on the difficulty for the different algorithms. So basically saying, okay, I mean, so you have some, almost like a consensus process to manage,

match the proof of work algorithm. Like, why? It seems a very, like, strange... Why would you do that? Yeah, why would you do that? So the motivation, actually, this was first published to the Bitcoin mailing list. I think it was like in March

before the whole fork thing happened. And essentially, we recognize that there's this issue of contention here. You know, let's say maybe users aren't satisfied that, you know, miners are acting in certain ways, and not only in the ways that have been recently, you know, on social media all over, maybe, you know, it's not okay to SPV minor,

maybe even pools aren't okay with users. It doesn't matter what the case is, but essentially users have no credible threat against these miners so they can say, we don't like it, we don't like it, we don't like it, but there's not a very high chance that users are going to, let's say, hard for it and change a proof of work, because, you know, obviously those coin holders would be hurting themselves very much in the process of doing this. So this creates this kind of like Cold War dynamic where no one can make the first move.

Also, on kind of a separate side note, but it mixes into this, is the fact that, you know, when Bitcoin started, right, the idea was that Hashpower would be the votes, one CPU, one vote. And then I guess everyone kind of agrees that maybe Hashpower wasn't, isn't like dispersed, in a way that it's the optimal way to make decisions in Bitcoin. So we're not saying, okay, we'll just let HashPriber decide, but there is no good governance mechanism. If HashPraversen deciding what is people who yell the loudest on social media, that's not necessarily a good idea. And because it wasn't substantiated at the first point,

even when they hold coin votes, which I think they did, I don't want to get into the whole argument, but I think they did on, you know, Bitcoin.com's website. They had a coin voting, right? People didn't accept that because they said, well, you know, that's not the way the system was, It wasn't designed for coin voting. So this whole mechanism is both the way to essentially say, number one, like coin voting is going to be like the,

essentially the way to make decisions going forward. And number two, we're going to also use coin voting as a way to enforce and incentivize actions on behalf of the people who are servicing the network. So we view kind of like minors as people who need to service the network. And, you know, they need to be paid for it. And if they don't listen, essentially, they can lose the, it's, you know, they can lose the, it's not like a, it's not a God-given privilege to be a minor in Zen, right? That can be taken away from you if you don't behave correctly, or at least taken away from everyone who owns your sort of hardware.

And so this provides this sort of incentive to behave correctly because you know that it's a credible threat that the users may, may kind of, you know, provide you with less of the mining reward, with less of the blocks. And they'll do that by increasing the difficulty for you relative to all the other miners out there, the different hashing algorithms. Okay. I mean, I actually, I can sort of understand if one comes from the like proof of work,

like paradigm to say, okay, this is an improvement, right? It's like potentially, right, it potentially addresses some of the issues you've seen in Bitcoin. But it feels to me, I mean, you know, from sort of coming a little bit from the cosmos, tenderman, proof of stake, inspired thinking. It feels to me it's going like halfway or partially because, okay, sure, coin voting governance makes sense, but then Wynol also use basically the coin weight for validation and Rino have like security deposits

because there's so much, I mean, of course, a variety of benefits, right, like this speed, scalability, all of that works better. But maybe one of the biggest one, right, this with the tenement style thing, is that blocks a final. And that seems to be a huge issue here. If you have forks, you know, if you have forks and then you have to roll back these options or complex financial contracts, I mean, nobody's going to be able to deal with this. Yeah. I hear your point. I think it's kind of funny that we don't see many reorgs happening. in Bitcoin, like not, yeah, not, let's say normal, oh, it was in an accident kind of reorg.

That doesn't happen very often, not for more than like a block or two, right? It's very rare to have like, you know, a reorg after 10 blocks. So I think it's relatively safe to, I don't see this as a biggest problem. And I also agree that, you know, maybe a lot of people are asking, you know, why, why, like, why, why minors, right? And we, I kind of touched on this earlier, personally. So the way I see it is that there's been a huge divergence of what miners are supposed to be doing and maybe what they're currently doing. I don't think that they're just supposed to be saying they're maybe wasting hash power.

They should be, you know, being a node and essentially servicing the network, you know, taking transactions, propagating them out, etc., etc. The predominance of pools has essentially hurt that. And that's something that, you know, we may look at essentially fixing, saying that, you know, we're still considering it. I think we have a very good method of doing it, but essentially saying, you know, we're going to remove the ability to use a pool. We're still going to make it competitive, so we're going to provide the sort of smart contract that enables you to mine even if you're not like a huge miner. So it's still competitive for the little guy. But essentially, you know, remove the ability to use pools of thus forcing everyone to run a node. And I think that when you look at it this way, and you're saying, okay, I understand, you know, that hash,

power is a good proxy for essentially the computer existing. The guy's running a node. Okay, I want to compensate him for running that node. And when you look at it from that aspect, I view then the coin creation as a subsidy for being a network service provider rather than like, rather than, I don't know what coin holders at the networking level, at the hardware level, let's say, are really doing for the network topography, essentially. Does that make some sense?

well yeah but i mean the coin holders they could basically stake coins and then validate right and and and then let's say they get returned but also if they you know if they don't do things right to get punished it seems to be it seems uh i don't think it fully makes sense to me sure no i'm i'm happy to explain so so essentially um think of it i'm not sure of all the different ones no offense intended at all. I think that essentially, you know, I looked at one of them, like with the delegated proof of stake, so one of the big things that makes it scalable is that people know which which node is going to like find the next block, which person is going to find the next block. But because you know this, it means that there's not a very high incentive to

propagate things very quickly and be highly connected to the network. With proof of work, there's a big incentive because the lower your latehors, is the more bandwidth you have, the faster you validate, the quicker you process, the higher the probability of finding another block is. And I think that this is very important when you're looking at like what is the function you want miners to be doing beyond, you know, just securing the network with hash power. We also want them to be acting as nodes. And that's why I think proof of work is part of the reason.

Now if we're looking at like the economics of it, right, that's a different discussion. So we have two discussions going on. I think about put the stake. One is like the economic aspect and the other is the technical aspects. Now in the economic aspect, I think that, you know, it can be done that the more coins you have, the higher probability it is to find another block. The question is, you know, do we want to do that? Like, do people want to do that?

I think that we should let people decide. But essentially it may create a situation where people say, ah, this was a pre-mine and, you know, I'm going to go fork my own version. So, yeah, so I think that there's like that that's a different conversation. the economics of it, like, you know, should be mining or should be be chlorine holding, but from the technical perspective, I think that, you know, that essentially there's some benefit of proof of work, and I'm not sure about the case of proof of stake. I don't know, do you have any thoughts on that?

Yeah, that's exactly pretty much thought. Okay, great. Well, guys, thanks much. It was super fascinating. Now, of course, well, not of course, but so you guys also have a token sale now. We're kind of at the end. much time to speak about it but I'm sure some people will be interested and they want to like learn about it and read about it and economics of it in terms and when it's happening etc etc can you share like where should people go what are the dates when it's happening and how can people learn more about it sure so um yeah please go to www. zanportcol.com um all the information is there um yeah that's pretty much it go please try to use our software at alpha.

And so many much for your time, Brian. Yeah, no, thanks so much, guys. And just briefly, so when is the, when is this token sale starting and when is the ending so people know? Sure. It's starting on November 30th, ending December 30th and in the year. Okay, great. So people know that.

Okay, well, thanks so much. It was really, really fascinating. Of course, we'll have links in the show notes to write you for blog posts, light paper, and there's a nice, indeed, that kind of alpha demo that you guys have, it's very impressive. So I highly encourage people to check it out. And yeah, thanks so much guys for coming on. Thank you, man. And of course, thanks so much for a listener for once again, tuning in.

So if you want to support the show, you can do so by leaving us an iTunes review. Not a lot of people do it, but it helps new people find the show. So we do appreciate that. and yeah we look forward to being back next week so much