Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Arthur Breitman: Tezos – A Self-Amending Crypto-Ledger

Episode Date: June 20, 2016

The lack of an explicit governance mechanism has created deep problems for Bitcoin. Ethereum, with the DAO-related soft/hard-fork discussions, may face similar challenges ahead. Yet, already in 2014 Arthur Breitman quietly started working on cryptocurrency network Tezos that has an explicit mechanism to let coinholders vote on protocol upgrades. Our discussion with Breitman centered around how explicit governance could lead to a more secure and evolutionary protocol. We also discussed Tezos’ approach to smart contract that tries to prevent bug-riddled and insecure smart contracts such as the DAO which has thrown Ethereum into a deep crisis. Topics covered in this episode: Why stakeholders voting on forks can prevent consensus attacks The mechanics of Tezos’ governance How an upgrade mechanism could allow Tezos to rapidly and radically evolve Why the programming language in which smart contracts are written is crucial for security Why a functional language that allows formal proofs such as OCaml is more suited for smart contracts than Ethereum’s solidity The road ahead for Tezos Episode links: Tezos website Tezos position paper [PDF] Tezos whitepaper [PDF] This episode is hosted by Brian Fabian Crain and Meher Roy. Show notes and listening options: epicenter.tv/136

This is Epicenter Bitcoin, episode 136 with guest Arthur Brightman. This episode of Epicenter Bitcoin is brought to by Jax. Jax is the user-friendly wallet that works across all your devices and handles both Bitcoin and Ether. Go to J-A-A-W-X.I-O and embrace the future of cryptocurrency wallets. Welcome to Epicenter Bitcoin, the show which talks about startups, technologies, and projects driving decentralization and the global blockchain revolution. My name is Brian Fabian Crane. And I'm my head Roy. Today we are going to talk to Arthur Brightman, who is the lead of the Tezos project.

Tezos is aiming to launch a cryptocurrency with a very unique governance mechanism and smart contract system. We'll talk to Arthur about what's special about Tezos, but before we begin, let's have a short intro from Arthur. Arthur, your intro. Hi, my name is Arthur Breitman. I grew up in France, which is why I have a bit of a French accent. I've been working in fine. over the past 10 years. And I've also been involved into cryptocurrencies. And in particular, I was involved with Tesos, which is a cryptocurrency that aims to solve a weird problem, which many people don't see as a technological

problem, but which I think is, is a governance problem. And the governance problem is the idea of saying, who really controls a currency. And if you're thinking of something like Bitcoin, you might say, okay, what controls the limits on Bitcoin. Why is there 21 million Bitcoin? And a naive answer is to say, well, it's a code. The code of Bitcoin is a rule. The code is what determines how many bitcoins you have. And then the question says, well, yes, but what is there's a fork? And this is a fork who you say, well, you know, I can always use the original version

of Bitcoin. I'll only use a version which has 21 million coins. Okay, but if you do that, then what about what are other people going to do? You know, Are they going to use the same version as you, or are they going to use the new version, which maybe has 30 million coins? And what really matters is what other people are going to do, what other people are going to value. And what they're going to value is going to depend on what they perceive other people are going to value. It's a sort of a beauty contest. And that is completely a social phenomenon.

Essentially, if there's a perception that a certain fork is valid, that a certain fork has authority, then people are going to be following that. that is essentially what's going to control the governance. You might think that you're escaping it by having these inflexible rules, but you're not. So the closest thing that you have is basically a cultural, very strong cultural bias towards saying, no, this should be the rules, and any departure from those rules is seen as illegitimate. It's sort of a taboo. But that taboo can be broken, and many people have been talking about actually breaking

it for Bitcoin. So instead of trying to have this weird system where, We try to keep forks to a minimum. I want to have a system where we can have forks, but whenever they happen, they're not going to happen through this informal process where it's whoever can shout the loudest or have the most natural authority. I want the process to be formal. And so the way the Tesla offers to do that is basically to put all the stakeholders of the currency in control.

I want all the updates to the protocol to happen within the protocol. And when I started thinking about that when someone said, it was a conference and someone said, hey, you know, if you're not mining in Bitcoin, you're not in control, because miners control Bitcoin. And I was like, well, you know, that's not completely true. Because if everyone changes their clients, then, you know, there's nothing the miners can do about it. If everyone decides, you know what, tomorrow, we want to switch to a different mining algorithm, all the miners would be screwed and there's nothing. thing they could do about it. But also, I don't want the miners were in charge, I don't want the minors to be in charge.

Their incentives are not aligned to the holders of the currency. So who's really in charge? And I wanted to put the stakeholders of the currency in charge of all the changes that could happen. And at the time when the Tezos paper came out in 2014, basically the paper made the point of like, look, you know, I'm going to sound crazy paranoid right now because obviously the core devs are these great and nice people,

but, you know, core devs could use their influence to try to push for forks. And then we had this huge battle about block size. And I was like, oh my God, it's actually, you know, it's actually happening. We have this governance problem. Now this, you know, and yeah, and the funniest thing is like, okay, you know, we're trying to solve a problem, which is essentially a problem of consensus on what the protocol should be. And we have this consensus forming technology, which is a blockchain to begin with, so why not use it to form the consensus on what we actually want to do? And so it starts sounding

very loopy because you're thinking, okay, we're going to use a blockchain to change what the blockchain is doing. And yes, so this is actually exactly what we do. We have rules on Tezos that allow people to vote on a change to what the rules are going to. to be, including the rules for voting. And so that idea was developed by a philosopher named Peter Suber. Peter Suber came up with a game called NOMIC. And the idea of NOMIC is that you start with a set of small rules, but the small rules allow for changes to the rules themselves. And then you can grow a game like this. Now, some of you might have played NOMIC, and if you've ever played NOMIC, you know that the games can be pretty crazy. And that's because the rules are

are designed to be very open-ended. In Tezos, we have open-ended rules, but we also start with a seed protocol. And that seed protocol is going to define what you can... Sorry, it's going to define the first rules by which you're going to be able to make changes. And those rules are conservative. In general, you don't want to have too many changes.

You only want to have a change if there is a clear majority in favor of that change. And the idea is to progressively become attracted to a better and better governance system. So depending on when you start on this governance landscape, you can either diverge and get something that's going to be completely crazy and useless, or you can converge towards good governance. And that's where I'm hoping I'm placing the original protocol in.

Okay, that's very interesting. And yeah, a very thorough introduction that I think already addressed a lot of the questions that we were going to have. I think what's particularly interesting is that you, with Tesla's note, because you're starting this in 2014, you're working on a lot of the things that now have become kind of pressing issues, right? So the one thing is the question of incentives, right? So between miners and the token holders, then there's the question of how does one upgrade

the protocol? And I think you're certainly right that now that is widely perceived to be a, massive issue, certainly in Bitcoin, Ethereum, well, we'll see. And that you started working on this explicitly so early on. Why do you think you saw that as problems back then, but others didn't? I think that people really wanted to believe that, you know, code was going to replace all of these social problems. They really want, you know, there was this very, very popular meme at the time, and it's kind of died off a little bit, which is, you know, Bitcoin is based on mass. And nothing, you know, Bitcoin is completely mathematical. There's nothing you can do to break it and so on so forth.

Mass is this platonic thing, which is pure and incorruptible. And therefore, nothing bad can happen to Bitcoin because mass. And the idea is like, yes, well, you know, there is some mass, but it's still embedded into society. And, you know, bad things can happen. And people were very reluctant to even admit the possibility that this type of thing would happen. They would say, well, you know, you can always use a real version of Bitcoin. That is so true. And it's just such a patently ridiculous statement to say like, you know, Bitcoin security is like math, right?

Because it just very clearly is not, right? It's economic security models. And if the miners want to do something else, then math is not going to help you one little bit. So I think that's a great point. I mean, there is, to be sure, there is some mass that does give you strong guarantees. So for example, the mass behind a hashing function, even though it's not proven, there are very, very strong conjectures that would tell us that, you know, the mass, you know, indeed, you will need astronomical amounts of power if you wanted to reverse a hashing function of computing power. And I'm not just talking about, or a lot, you know, billions of competing power. we're talking about, you know, orders of magnitude which are similar to, like, the energy in the universe, or like a star, this type of, this type of guarantees.

So these are very, very strong guarantees. And then you have the consensus itself, which is based on the idea, like, well, you know, we're hoping that the miners are not going to get compromised, you know, they're not going to get kidnapped and forced to, the mining pool operators are not going to get kidnapped and forced to do a fork. We suppose that they actually care about making money and they don't want to destroy the network. They're all this type of itself. assumptions and these have nothing to do with mathematics. You can have the best, you know, you can have all the proofs you want about reaching consensus. In the end, it depends on minors deciding to do the right thing. And that's going to be an economic and social problem and not a mathematical one. Yeah, very interesting. Like I, I've been, I read your paper a year back and over the past year, I've increasingly kind of realized that like, like, like the visionary aspect of your paper because you know you're working on governance when none of these problems

seemed obvious and then i finally decided okay let's have you on the show i mean thanks for having me yeah like thanks for coming on because like this is really the kind of conversation we've we've been wanting to have for a long time especially brian i see now uh let's get into the mechanics of this protocol upgrades right like let's go down down and dirty so the base is like Let's assume Tezos is starts off as a proof of stake system, right? We'll not not get into details of proof of stake. So, so there's a blockchain, which means there's like a network. There's a set of transaction rules, right?

So how, how, what considers a value transaction, etc. And then there's a set of consensus rules. That's how any blockchain protocol, that's how the seed starts. How can, let's say we call this seed, S1 or something. How can you go from S1 to S2, which is, say, an upgraded version of S1 in Tesos? Okay.

So the way you go from S1 to S2 depends on rules which are embedded in S1. You know, I'm still working on those rules, but the general outline for the rules in S1 is that you have a two-phase vote. The first part is people are going to make propositions. So what does the proposition look like? So in Tesos, we try to have many layers of encapsulation in order to give us some guarantee about the safety of the system. And at the top layer, you have something called the Economic Protocol, and it doesn't know anything about the network.

It doesn't know anything about your file system or hardwress or anything like that. It's a very, very, it's as small as possible piece of code that describes all the rules that you're using for making transaction and for deciding which branch is a valid branch inside the blockchain. Now, in this piece of code basically can be swapped. You can repress this piece of code with another one. So right now this piece of code is S1, as you call it, you could replace it with S2. So the first thing you're going to do is that people are going to take S1, maybe fix some bugs, make some changes, call it S2.

Then they're going to hash S2. And they're going to publish the hash on a blockchain and say, hey, here's a proposal. I want to do this. And of course, if you just see the hash, you don't know what the proposal is, but while they'll do probably, you know, they'll post on GitHub their proposal, and then they'll say like, hey, everyone, you know, this is my proposal. Look at it. And because the hash is on the blockchain, people can check that the hash corresponds to the proposition. Now, the first round is called approval voting. And approval voting is a very robust voting procedure. It was using the Republic of Venice. It has very good properties. And the idea, is that, let's say there are a hundred proposals.

Everyone looks at every proposal and say, I like this one, or I don't like this one, I like this one, I like this one. Then you sum all the yes and the nays for each proposal, and you take the one which was most popular. Now, that one is going to be subject to a vote itself. And for that vote, we're going to require a majority of 60% of people. So once you've decided what we're going to voting on, then we're going to decide, okay, do we want this or not? Just briefly interrupting here. Yes. So you said, you know, there would be a variety of proposals.

People would vote on it and then the one with the highest would get through. But what time period are we talking about here? I mean, if our votes happening, like is there a set period? I don't know, once a month where one can submit proposals and then through the next weeks the votes? So how does that work? How would that work? So I think right now, initially the CID Protocol has allowance for quarterly votes and it's basically on the order of months between each steps, you know, for propositions,

votes, acceptance and so and so forth. So let's say there was a bug found, or so that that wouldn't be a way to upgrade the protocol, you know, if there's an emergency or some flaw is found. Yes, it's not, it's not a good emergency procedure. The idea is that if we find some bugs, And of course, you're going to tend to find bugs early on. If you find some bug, you can issue a patch. And why wouldn't you want to use the governance procedure to do that? Well, because of governance procedure, you wanted to be slow and you want it to be careful and conservative.

But bugs are not very controversial. You know, if you find a bug like, you know, in 2010, Bitcoin had this overflow bug where, you know, you could create a transaction, which had billions of Bitcoin on each side starting from zero because of an integer overflow. And, of course, it was a reverted that, there was a patch, because there was no question that this was invalid.

It was very obvious. So if you have this kind of very, very obvious bug, you can have a patch because there is so widespread consensus that you're not doing anything wrong when you're pushing this patch. It's for the stuff that is more controversial. And the stuff that is more controversial generally does not, require an immediate fix. So I it's not it's not a good mechanism for that. It's think of it more of like okay we have this new mechanism for scaling but it has

some trade-offs. What do we want to do? That's not something you need to push in an emergency. Let's take a short break to talk about Jacks. Jacks is a cryptocurrency wallet created by the people at the Central. Now there are two cryptocurrencies that matter at their moment. One is Bitcoin and one one is ether. But using them can be tricky, what wallet you use. How do you secure them? Where did I leave my umbrella? It's all a big mess. And that's where Jacks comes in. Jacks is a unified wallet. It works across all your devices. It works for their Android phone, Apple, iPhone. It works for your desktop computer. And they have browser extensions for Chrome and Firefox. And it works for both currencies

at the same time. It works for Bitcoin and it works for Ether. One of the things that makes Jax as delightful as walking through the 5th, that Hongji Small of Paris on a Sunday morning and getting a whiff of fresh pastries is how they leverage HD wallets. So they use a 12-word single backup seed for all three currencies and make it super easy to sync your wallets across all your devices. So if you're using the Chrome extension or the desktop app, you just can whip out your phone, scan the QR code, and boom, your wallets are synced.

And plus, the people at Jax take your security very seriously. It's open source so anybody can look at the code, and plus they never hold any customer funds. All the keys are stored locally on the client side. So go to jacks.io, that's j-a-a-d-x.io, download the jack's wallet right now and understand what it's like to use the next generation wallet. We'd like to thank jacks for those supportive epicenter. Let's try to make this brilliant concept a bit tangible. So let's go back to the story where with what happened with Bitcoin

when Gavin came up with the idea of increasing the block size, right? So initially, initially there was a lot of debate, like Gavin said, 20 mb blocks, lots of debate. At some point, Gavin and Mike Hearn, they realized that

typing into Bitcoin Talk Forum isn't going to help anymore. So they said, okay, we are going to go for a hard fork. And we are going to try to convince all of these miners to, to also potentially accept that hard fork, signal their intent to accept that hard fork, and then if 75% or whatever percent signal their intent,

then we are going to go ahead with it, right? Now, let's imagine that same scenario happening with something like Tezos. In this case, what would happen, as I imagine it would, yeah, maybe the charismatic Gavin Anderson of Teizos comes and says, okay, we should do this. And then he tries to convince the miners or stakeholders of Tezos to do this. But the stakeholders can always say, hey, if you have such a cool idea,

why don't you go through the governance process that is built in our blockchain itself rather than try to convince us to do a hard fork? Yeah, that's exactly right. So I think it ties into a question that people sometimes ask in politics. You know, what, if you look at the U.S. Constitution,

what makes it self-enforcing? Because people say, well, the constitution is not self-enforcing. It's just a set of rules, so why would it have any weight on what people actually do? And the reason is that most political power is held through shelling points. They're held through game theoretical focal points. And the idea is the following. If you break a set of established rules, then you become suspicious. and then there is implicitly coordination against you.

So, of course, someone could propose a hard fork. Someone could propose into this, you know what, let's move in this different direction. But like you're saying, if you start doing that, people are going to say, wait a second, you know, we have a mechanism for doing this. Why are you bypassing the mechanism? If you're bypassing the mechanism, then you must be doing something wrong, and by default, we're going to be against you. So that's how you essentially protect yourself against outside forks.

because they're seen as illegitimate by default because you have these allowance for forks. If you never needed any fork, if you never needed any upgrade anything, then we wouldn't need this whole governance procedure. We would have just something that never changes. But if you need to have changes, you can't have, you can't just say like, oh, well, we'll have the changes come from the outside because if you do that, then how do you sort between, the good ones and the bad ones? So this is essentially why I'm not just pushing the problem further. By integrating it inside the blockchain, I'm creating the expectation that all changes have to come through this procedure, have to come to this approval.

This is essentially how institutions work. Institutions work because people form expectation around them and they form expectation about what other people's expectations are going to be. This is great because as you know, Mayor pointed out before that I'd been sort of asking people like every, every time somebody came with like some new protocol, whether it's, you know, talking with Ethereum or Bitcoin or Zcash or all these other things. So what's the mechanism going to be by which you'd sort of decide on the evolution of the protocol? And nobody ever had a particularly, you know, coherent answer. I mean, there could have been various degrees of coherent answers, but nobody really built

the system that takes this into account from the outset and designs a mechanism of this upgrading in. So I'm really exciting, excited that you've done that here. Thank you. I'm excited too. Let's have like a small, naughty problem out of the way. Now, now you're saying that any, any potential upgrades to the protocol have to go through a two-phased voting process where we first try to sort through all of the proposal out out there and at a certain time point and say okay which one are we going to really consider and then in the next phase stakeholders are going to vote on it and you need 60% of the coin holders to vote yes to a proposal to finally upgrade the blockchain what happens when stakeholders don't end up voting and

you don't have quorum like this even though the Dow just lived a month we saw this that a lot of very important proposals to the Dow ended up getting just 506% of very low water turnout. So what happens then? Yeah, it's a big problem. So I have three mitigations to that. The first one is that in every contract that you have on Tesos, you can set a key for a delegate.

And there are two reasons for doing that. One is that in general, you don't want to be making voting decisions with a key that hold your funds. because you could be putting that key at risk. Maybe you want to have this key in a cold wallet. So you want to have a different key for just voting, which is less sensitive than actually spending your money.

But you could also put the key of someone else. So you can have a system like liquid democracy where you're saying, okay, you know what? I don't trust myself to evaluate propositions on this network. But I do trust these people. You know, I think they're good people. They're making good decisions. So I'm going to give them my voting power,

by choosing my key. And if they start doing things I don't like, then I can change it. I can, you know, in one transaction, I can say, okay, you know what? Now I'm going to give my voting power to someone else. So the fact that many, I think the reason many people didn't vote in a Dow is that many people were just buying these tokens for speculation. They were saying like, oh, maybe I'll go up, you know, I'll buy some. They're not really interested in participating.

And people are always going to be doing that. And if people do that, at least I want them to be able to say, okay, and I'll just delegate my voting power to someone else. So that gives you a way to really increase your quorum. But even if you do that, people are going to lose coins. Delegates are going to lose their keys and people are not going to upgrade the delegates. So the current way this works in Tezos, which would be the second level of protection, is that at every election, you sense what the quorum is,

and your required quorum goes down at every election based on the participation in the previous one. I'm not super happy with this mechanism because if you, you have low participation for a lot of elections, you could weaken your system to the point where few people could change the balance of things. So I don't really like this very much. Fortunately, it's something that can be changed in S2 or S3. So the type of things that I have in mind for changing this are essentially requiring proofs of activities maybe yearly or so for coins to be able to participate in votes so that you can sense the quorum not based on whether or not people are voting, but whether or not people are making transactions

or possibly charging people for not participating or for not having valid delegates. There are many solutions that can be implemented. I think for the first few elections, we should be okay, but it's something that we'll need to address in the future. So is this built already, or is this a concept? Like right now with tasers, does they exist already the mechanism, for example, having a separate key that there's a voting and delegation and all these things? Yes, so absolutely. So the project has been in development for two years.

We have an alpha. So most of it work. I can tell you the thing that doesn't quite yet work, to give you an idea, because that's a much shorter list. So the things that do not work quite yet, we have the mechanism for changing the process. and a fly, and for voting, we don't have yet, at the network layer, the rule for downloading the protocol from your peers. You can download block transactions. We're not yet downloading new protocols.

You mentioned it was a two-phase for the vote. It's actually three-phase, because at the end of the second phase, basically, you replace your test net. So the test net of S-1 become S2. Then you keep that for a month, and then at the end of that, you have another voice. have another vote saying, okay, we tested that for a month. Do we really, really want this? And then if you say yes again, then S2 becomes S1.

So the test nets right now has a couple bugs, and we are still working as well on the forging clients, which is the clients that people run to actually create blocks and send them to the network. The rest, which is the consensus algorithm, works, changing the protocol works, transaction, smart contracts, all of that is implemented. So now in your position paper, you mentioned that Futarki can also be used to decide on protocol upgrades, right? And across the whole Ethereum ecosystem, like Futarki is this busword.

It's supposed to be the end of the governance problem. but I haven't actually seen it working ever. So are you going to try to implement Futaki in Seed 1, or do you expect further iterations of the protocol to get Futaki like governance system also in? Definitely further. Futurki has not been tested. I have somewhat conservative rules for changing the protocol.

I'm very excited about the prospects for it, especially since you have a natural target for the Futurkey, which is the value of the token itself. So, you know, just to explain quickly in Futurkey, the idea is to say we are going to, the slogan that Robin Hansen has is vote on values and bets on beliefs. And the idea is that we should decide what we want first and that may be a collective decision,

but that how to implement it, how to get there, we can have prediction markets. And those prediction markets are going, to tell us conditionally which proposal is the most likely to succeed. So here we have a natural value, which might be the value of the tokens themselves. And we have also a blockchain, which is a really good medium for organizing this prediction markets to begin with. So it is an interesting idea.

Some of the limitations, possibly of that idea, is that you have a moral hazard sometimes. So, you know, if you make the prediction that if a certain policy is taken, then, you know, a good thing will happen. You could bet against that. And then out of bend, you could try to make sure that the policy will not happen. Or if you don't have very liquid markets, you could have, you could possibly have some people influence the decision, maybe by pouring money into it. Now, Robin Hansen thinks that's not a case. that if you start having that, people will just arbitrage it and make even more money by correcting the markets.

I'm willing to accept it's possible for very liquid markets. I don't know for sure that it does happen with less liquid markets. What I do know, and I think that's very important, is something that people don't talk about when they talk about Futurkey. In Robin Hansen's proposal of prediction markets, there is a market maker in these markets, and that market maker is subsidized. And the idea is that you are taking money and you're giving it to someone and that someone is going to lose money to more informed traders.

And this is a very important aspect because you cannot do all this research of finding out which policy is the best without actually investing money and investing time in it. And so this is why there's a subsidy. And oftentimes people think that, oh, you can just have a prediction market and people will bet. Well, there's a thing called the no trade serum, which means that if you're not trying to hedge a risk, if you're not trying to invest in a business, you shouldn't. not be betting on a market. Because if you're betting and someone else takes your bet, then they probably know more than you do. So people are overconfidence, and since they're overconfidence, they're going to bet anyway. But you cannot just use people's overconfidence in order to subsidize your research. You need to have another source. What's really nice with

a governance system like Tesos is that in Tezos, we can say, hey, you know what? We'll issue coins, and those coins will be used to subsidize the market making. So you can actually get a liquid market out of this. So that's one possibility. However, to go back to your original question, do we want to have that in S1? No, certainly not. And not even in S2.

What we would want is probably to have two systems in parallel. One where we have, okay, we'll have future key, but then we'll have another round of voting on top of that to act as a fail-safe. And the way I look at voting, I'm not, so I'm not, I don't think that voting leads to very good decisions in general, but I do think that voting is a good mechanism for avoiding really bad decisions.

It's more of the veto tool than it is a decision tool. So possibly something like that, possibly, you know, future key to decide something and then a veto power. There's an interesting in Liechtenstein, you know, a small European country, it's a monarchy, but they have a constitution and the constitution says that the people, can actually vote out the monarch. And I think that's an interesting system because you're saying, no, you know what? We're not going to actually ask you to pick someone,

but if things get really bad, you can get someone out. And, you know, I think democracy has many, many flaws, but one of the things that it gets right, I think, is this ability to take people out of office. Cool, very interesting. So one of the things that you wrote about in the TASIS paper, which I didn't fully understand

or didn't understand really at all, so I would love to dive into. So I said that TAS can instantiate any blockchain-based ledger, so it can instantiate something like Bitcoin, something like Ethereum. Can you explain what that means? Yes. So when I was thinking about trying to replace the protocol with something else, trying to change, what should be the change?

And one way to do this would be to say, well, you know, the protocol is just some executable that you run on your machine. so we'll just change that. We'll just send you a patch to the binary. And that's not a very good model because people have many different platforms and you might want to have different implementation. So you needed to change something more parametric,

something smaller that would describe the protocol in an ambiguous way. And so in order to do that, I said, okay, so what constitutes a blockchain algorithm? What are all the parameters? that come into it. And if you think about it, they all pretty much look at the following thing. You have a state that you want shared between many people, and you want this state to be changeable. So I'll take the example of Bitcoin. In Bitcoin, this state is the state of unspent transaction

outputs. If you want a snapshot of Bitcoin at a given time, that's basically what it is. It tells you, okay, these are all of the available addresses and the scripts that are associated with them, and this is what you can spend. Anything that happened before is only used for validation. And then you have operations. So an operations on Bitcoin is a transaction. You take an unspent outputs

and then you transform it into another, you take a bunch of unspent outputs and then you transform them into another bunch of unspent outputs. So you have operations, you have blocks which are sets of operations, and you have a state.

So your Brackling Protocol is basically a business, following. You have a function which you call apply, which takes a state, takes a block, applies the operations of the blocks to the state, and gives you a new state, or possibly tells you this is invalid. Okay, so now let's say you do that. Well, the problem is that if you have many people editing the state at the same time, you're not going to end up with a nice linked list like a blockchain, you're going to end up like a tree. It's going to be a huge tree with many, many forks. So you want to say, okay, well, I don't want a tree, I just want

one version of reality. I just want one leaf of that tree. And so you have a second function which is going to tell you how real is that branch. How valuable is that branch? And you're going to just pick the branch which is the most canonical, the most valuable.

And in Bitcoin, there would be the branch with the most total hashing power. Or in a proof of stake system, it might be the branch with the most signature. In a centralized system, it might be the branch that has been signed by the trusted centralized parties. And so as long as you have a protocol that implements these two functions, apply,

and a fitness function that tells you which leaf to peak, you can implement any blockchain protocol. Almost any, I think that, so if you have things like ghost where you're rewarding uncle blocks, it's not going to be, it's not going to be expressible in that framework. So I don't think you can express a serum exactly, but you can get things which are very close to that. And all of the other protocols can be expressed in that framework. So if I understand it correctly, what you're saying is that because tasers can evolve,

because you can change a variety of rules, and looking at it in this general way of having a block, some transformation in the new block, because of that, taseless could evolve, to do what Ethereum does, to do what Bitcoin does, or to do some variety of other things. So it could essentially evolve into pretty much any cryptocurrency protocol. That's right.

Yeah. So basically it's like this seed that has this evolution mechanism inbuilt. And it can evolve probably in, probably it has many different directions it can evolve towards. And the stakeholders pick which direction to go. And if you think that your own units of this currency and you think the other guys that are owning units of this currency are smart and you will evolve in a great direction,

then you might just end up building a really valuable system. That's a hope. And it's very important. So there's this concept in mathematics called basins of attraction. You have, in optimization, when you're trying sometimes to optimize a function, you will start with a point, follow a gradient and you'll try to get a better point. So you'll start with the value and then you say, okay, I'll move it a little in this direction and make it better, a little in the direction you'll make it

better, and you end up at the bottom of a valley. And it matters greatly where you start, because if you start near a poor equilibrium, then you might go in that direction instead. So it's important that the seed protocol, it doesn't have to be perfect, it just has to be in the right basin of attraction. It just had to be in a place such that starting from this position and following the rules, we're going to end up with a better set of rules and a virtual circle. Oh, that's an awesome analogy, right? You're talking about greedy optimization, right? Is that correct? Yes. So most numerical optimization, local optimization is going to be greedy. If you look, for example, at neural nests now are popular again. What they're doing when they're learning is

that they look at an example, they see, you know, they see the mistakes they make when they're trying to classify it, and then they move a little bit in the direction that would have made them better at classifying it. So they're very myopic, they just try to greedily improve the system. And we can be a little less greedy with this because it's not, you know, you have a lot of people who think about the protocol and they're going to try to go in the right direction. The reason I'm mentioning this is that people who have played no mix, they say like, oh, well, you know, this is crazy because people are just going to, vote for all these crazy roles, and then you're going to just devolve into something really bad.

And it's possible if you start from, you know, if you're way too willing to accept any type of changes at the beginning, then yes, you could go into this crazy spiral when it just becomes kind of a joke. But if you're close enough to a solid state where, you know, where you have these various circles, then you can get something really good out of it. so your role as if I understand what you're saying correctly it's like your role as a founder of tezos is you conceive the governance mechanism you conceive the process yes that's a big contribution but your other big contribution has to be that the seed protocol has to start off with a set of functionality core functionality that is such that it leads the community to go

in a virtuous direction rather than in a chaotic direction where the community doesn't know what's the final destination where it wants to go. Right? That's kind of your kind of rest. It's like you have this responsibility on your shoulder to come up with a good seat protocol

because the further evolution is going to depend on the starting state, on the initial state. Yes, yes. I mean, and it's almost every institution you can think of has crazy pass dependency. I mean, you know, like people in the U.S. today are talking about Constitution and they're talking about decisions that were more hundreds of years ago. So if you think of, like, the weights that, I don't know if, you know, the framers of the Constitution had this idea

of like the weights of their words, but it's, but it's huge. And so you, yes, you can, you can have tremendous repercussions way, way, way, way down the line. Today's magic word is evolution. That's E-B-O-L-U-T-I-O-N. Head over to Let's TalkBitPidPo.com to sign in, enter the magic word and claim you're part of the listener reward. So, like, I could go on and on about this topic for a long time, but there are other interesting aspects of TASOs that we need to touch upon, and there are other interesting topics we want to talk about with you.

One of them is smart contracts, and the seed protocol of Tados, as I understand it, is also innovating on how smart contracts should work, right? So tell us a bit about all of the innovations you're doing on the smart contract side. Yes. So, yeah, I believe smart contracts are very important to have, and they solve a lot of problems that are interesting in the decentralized ledger space. So one of the reasons not to get smart contracts is to say, well, you know, all you need is to have this mechanism for transferring tokens,

and then you can just rely on third parties in order to execute those contracts. And the problem with that is, well, there's one of trust, because you need to be able to trust a third party. But there's also one of automation. It is very nice when you know that the network is just going to work on itself. You know that you don't have to worry about the uptime of the third party. You know that you don't have to pay them. You know you don't have to give them keys.

is just going to be automatically executed by the network. There's a lot of value to that. There's also value in the IT that smart contracts can act as escrow. So right now you see things like Oger, for example, in Assyria, in their prediction markets. And one of the beauty of it is that they are able to build that. And as a company, they're not holding anyone's fund, which legally helps them because they're saying,

well, you know, it's a smart contract. So who is a custodian? The custodian is the network itself. So that's why I have smart contracts. Why am I doing it differently than Ethereum? So there's a kind of dichotomy in how Ethereum sees its own smart contract. On the one hand, they are saying, like, well, the world's computer, you know, you can buy all these computations and so on so forth. But on the other, and that's also why, you know, they're trying to optimize the Assyram virtual machine.

They're trying to make it fast and so on so forth. But on the other hand, if you look at what people actually want to use this for, most of the logic you want to turn in smart contracts is not, you don't want to be running computation. You want to be running very, very simple business logic. It's basically if and then. It's it doesn't, you know, you're not going to be running protein folding distributed on the Assyrium network. It would be crazy because all the computation is done many, many times. That's not why it's for it. It's not the world's computer. It's a bunch of very simple business roles that you're implementing. So a lot of the features such as saying like, okay, you know, we're going to have a limited execution time and you pay for this execution. First of all, that doesn't work. And that doesn't work because if you go out and say, okay, I'm going to create a contract. And that contract, basically you create an infinite loop. And then you put a huge transaction fee. And you say, okay, this is a gigantic transaction fee because these contracts, it actually runs for hours.

You put this, you put this transaction out. And you say, okay. now I mine it and I pay myself the fee so you haven't lost anything. Now the other miners, they have two choice. Either they just trust you. They say like, well, you know what? I'm just going to say like, yeah, sure, that's fine. Or they waste all their time verifying this.

And so you're going to have a problem, which is you're only rewarding the person who mines a block and whereas you should be rewarding everyone for the computation. So instead of doing that, and in practice in this area, they have a cap limit, which is going to be the block gas limit. So instead of doing that, we say, okay, you know what, we're just going to rate limits that. We're going to make people pay for every resources that they use. So there's going to be a limit on the competition time so that we are sure that everyone can, all the participants can verify it. And there's no way to game the system by having these very long computations.

We're going to make you pay for storage, how much you're storing, and so on so forth. Can I interrupt briefly here? Yes. So that was a very interesting point, right? So let's say I'm a big Ethereum. I can put some gigantic, pointless thing into the block I mine myself, pay myself the big fee. So it actually doesn't cost me anything. And then it kind of creates a big cost for the network.

So I think that's an very interesting flaw, quite obvious one. But so how is that different here? So here we have a cap, which is basically saying, okay, we're going to allow you to run a certain amount of computation. and it's not going to be a crazy amount. And the amount that we let you basically think of it as you would think about the block size. It's a threshold that as long as it's underneath this, it's reasonable to be doing that.

But then I could still put in loads and loads of pointless computations, no? Yes, and so it's optimized so that the amount of computation that you could have total in a block is always going to be reasonable. And you have that, you know, you have that as well in Ethereum with the gas limits. What I'm saying here is not that Ethereum has this very, very large flow.

What I'm saying is that the idea is that, oh, you're just paying for competition time is not really sound because you're not really trying to do this very complicated calculation. You're just trying to run simple business logic. However, it's very important to get that logic right. And in order to get it right, what we have is a smart contract language which has a full formal specification and which is very strongly typed. And the idea behind this is that we don't want to say, oh, we're going to have this low level assembly and we're going to optimize it because no, we're not we're not trying to run this numerical computations. We're trying to do something precise and know exactly very well what we're doing. And so this language allows you to get very strong guarantees about the behavior of your contract. So there's a field called formal verification, which has been, you know, has been existing for a while.

It's, it has existed pretty much as long as computer science has existed. It was really pushed by computer scientists, for example, like Erwin Dijkstra, was explaining, hey, it's very important that we produce mathematics proofs, mathematical proofs, that the programs that we write are correct. And in fact, what he was suggesting was saying, you know, instead of writing a program and then writing the proofs that it's correct,

we're going to try to write the program and grow the proof with it. The program can be a proof in itself. Now, one way you can do some of that is by having very strong typing guarantees. So strongly typed languages like Haskell and O'Camel, for example, have these properties where you have very strong guarantees at compiled time that you're not going to have two objects of widely different types be confused.

And it's not going to remove any bug, but it does remove a lot of bug. One of the experience that many people who work with these languages have is that when they write some code, very often it will not compile. And getting it to compile very often, is a very similar process as what other people might experience debugging. But the very difference is that once you've compiled it, you're going to have much less bugs than you would have otherwise. The idea of formal verification is to bridge that even further.

Instead of just checking types, we're going to check every property. So you write a smart contract and you're going to say, okay, I want to have the property that money is never going to leave the contract, at a greater rate than, you know, a certain amount per day. And this is a mathematical property, and you're going to be able to produce a proof of this property by looking at the code of the contract. Now, in principle, you could do this with any language.

You know, I could give you any programming language, and sure, you could make a mathematical proof. But for that to happen, that language needs to be very ambiguous and needs to have a full formal specification. And also, if your language is just some basic assembly that shifts some values in RAM is going to be much harder to come up with these proofs

than if your language has a certain structure. Now, the language of the smart contract for Stizos has been designed to begin with to facilitate those proofs. And the people have been working with are actually people who have a lot of expertise in the field of formal verification.

I don't think it's perfect. First of all, because people are not necessarily going to write these proofs, though I want to encourage them to, and the system definitely does that. But also because it can be difficult. It can be difficult to produce this proof. I try to make it as easy as possible.

What I want to envision for the future is to have a description language. So imagine instead of encoding what your contract will do at every step, you encode it instead properties of the contract. You said, okay, this contract will, you know, this contract has to pay this much when certain properties are true. This contract can never spend more than X.

You just write a bunch of constraints that you want on your program. And as humans, it's very much easier for us to express what we want in terms of constraints rather than in terms of behavior. So you should be able to write all these constraints and then have a compiler automatically take those constraints and produce code that is going to validate those constraints, produce the minimal smart contracts that can actually satisfy those. So that is not S1, just to be very clear. S1 has a very nice formally specified language that will make it easy to write proofs. But this is where we

want to be headed. A few weeks ago, we told you about the GTECH blockchain contest. We ask you to submit your blockchain startup ideas for your chance to win 50,000 euros in grant money from RWE, GTE, GTE, and glubumbus. Well, over 100 startups submitted their ideas, including 16 of you are listeners. Well, the results are in, and the winner of the Grand Prize is Arcade City, a project with a radical idea to cut the middleman out of ride-sharing. And the runner-ups are cargo chain, a blockchain distance to improve international trade, especially in the shipping industry, and Clippers,

a decentralized permanent document storage solution intended to guarantee intellectual property without a middleman. Congratulations to the winners, and we wish you lots of success with your projects. If you have a blockchain startup idea and think Berlin could be the home where you are going to grow your company into a billion dollar behemoth, then make sure you check out GTECH or the GTECH Entrepreneurship Center. GTECH has a lot of programs, workshops, startup academies, provide office space to help companies grow quickly, work on really innovative concepts. So make sure you check out their website, check out GTECH dot Berlin, that's GTE, d'E-C-D-E-R-L-I-N, and we hope to see some of you in Berlin soon.

We would like to thank G-TEC, R-E, and Clubumbus for their support of Epicenter Bitcoin. So if we can kind of contrast here, the sort of Ethereum approach, right? So solidity being quite similar to JavaScript and being kind of made in a way that's hopefully reasonably easy for people to, you know, code some smart contracts, but then issuing being here that, well, lots of errors, right, different types and stuff like that. And then also when it gets compiled down, that stuff is hard to analyze and hard to do proofs on, whereas the TASO's approach is sort of enforcing as much as possible using a language that is veryifiable. And that kind of prevents a lot of box being created.

Is that the kind of accurate description of the two approaches? Yeah, absolutely. And in fact, so I saw recently that the solidity compiler is not deterministic. So you don't always necessarily produce the same assembly code per serum, which is crazy dangerous because you want to be able to analyze what the contract does. you don't want to be just given a bunch of assembly code and say, okay, you know, this is what you're putting money into. This is very dangerous. And we've seen that with a Dow, which basically had this huge bug, you know, yesterday, $50 million of words were stolen from the contract.

You want to have contracts which can be verified, which can be inspected. Assyram has this philosophy of trying to make the language as minimalistic as possible, and I think that works well if you're designing a CPU, something very general purpose. But for smart contracts, I think you want to have a rich language at the basis of it. With the formal specification so that you know exactly what you're doing, but you want to have these high-level primitives that allow you to express meaningfully what you're doing and not just say like, okay, we're just going to be shifting a lot of bits. people need to be able to inspect the contracts and understand what's happening.

Okay, so I think like your answer is brilliant. And I'm going to try to kind of boil it down into some examples, right? And maybe I'll be all wrong. So the first thing you say is the language should be strongly typed. So by that, I mean, so. So typing meaning like any variable could have, you know, it could be Uint, Uint, 32, string, etc. You're saying like the language should have a lot of different types. Yeah.

It should be while compiling, the language should guarantee that there's never a step in the code where you are adding like a string to a U-int, right? By default, whenever you wrote a code and maybe it has some error where you're adding a string like Meher to an integer like one, two, three, and this kind of error is there, and that's going to, you know, halt the code during execution. So this kind of code would never compile down, and it would be very hard to get the code to compile

because it's verifying whether in all of these conditions there are errors like these or not, right? Yes. That's one aspect of it. The second aspect you say is that you should be able to have proofs. So the example that comes in my head when you say this is, so let's let's see, let's take what happened to the DAO. So for like I've said kind of the contract of the DAO and roughly what happened is in the DAO, whenever you make a withdrawal, let's say there's like one variable that tracks how much withdrawal was made. And then there are actual transactions which are doing the withdrawals.

Now in the Dow code, there was a possibility to have this variable stay the same while there were output transactions happening. So normally the way the DAW authors intended is whenever there's a withdrawal, this variable should record that. But there was a possibility that was the hack basically where instead of changing this value, you could still do a withdrawal. Or instead of changing this value only once, you could withdraw 10 times. So when you say a formal proof should be allowed, what that means is once I wrote the smart contract, I can prove that whenever there is a withdrawal, this variable will definitely be changed or incremented or decremented, whichever way I like it. So I can prove to anybody that something like the Dow hack could never happen inside my code. right? So yeah, so that's something you could prove absolutely.

You would want to prove a more general thing. And I'll just say a word about proof after this, but what C you would want to prove, for example, is say, okay, I want to prove that it's never possible for people to use a split procedure to get more token than they actually control to begin with. That's a property you would want to prove. You don't even want to prove something about that variable

because maybe there would be another way to do it. You want to prove these high-level properties. So with proofs, it's always possible that you will forget to prove something. You will prove a lot of properties in the system, and there's one property you care about that you will forget to prove. However, the alternative to proves, which is most commonly done today is unit test. So with a unit test, you have a piece of code, and then you think of many, many different cases,

and you make sure that your program has a correct behavior for each of these tests. And that's a really good thing. And people don't always do it, but it's very important to test your programs. Proofs is like a super version of test. Instead of testing specific problems, you can test very large classes of problem.

Instead of saying, I want to make sure that I get the right output in this instance, you say, I want to make sure that my output always has certain properties for this very large classes of instance. So you can get much stronger guarantees.

You would want to make many, proofs, not just one proof. You won't want to prove that people cannot, you know, get away with, steal money from the fund, you will, you will want to prove that the fund cannot disappear, do all this sort of proof. That's a type of thing you would expect. To go back about, the first thing about types, so I use strongly typed and I use the word loosely, many people, sometimes mean different things. What I really am talking about is static type checking, where you're making sure that at compile time, You're looking at all the types, and you know that the logic of your program is going to be correct,

regardless of what your input is going to be. So you give the example of adding a string in an int, and yes, that's something you would catch. But you might say, okay, well, what's a big deal? I don't see myself adding a string to an end. How is that a real problem? So the idea is that you can use a type system to get a little more out of it. So, for example, you will give a different type to a token than you would give to an integer. So, for example, you might be counting the number of people who participate in the contract,

and then you might be counting how many tokens you have. Well, you never want to actually sum those two numbers, because they're both integers, but they mean completely differencing. And with the type system, you can make sure that all the types that represent money, for example, or that represents token or that represent votes, are always, are not going to mix. They're always going to be the one type. And that's the type of bugs that you might have and that you would catch.

That's super interesting. So I've also kind of read in some of your writings that you've said that formal verification is, as a discipline, has had a long history. But never found a lot of practical application. And you said, the technology is now mature and we should use this technology in smart contract. So I would like to ask, like, why hasn't it found a lot of applications still? So formal verification is difficult. It's really hard to come up with this proofs. What has happened recently in recent years is that we've come up with better and better

proof assistance. So one of the proof assistants that I'm trying to work with is a proof assistant called Koch. It's a French word COQ, it means a rooster. And, you know, the entire Tizos codebase is written in OCamel. Cock is written in OCamill. You can take programs in this language and export them to OCamel. So there's a lot of symbiosis between the two languages. So this proof assistance have become much better. So now we're able to make more proofs.

But it's still expensive to make a proof. So the right circumstance under which you might want to use formal verification is when you have a small code base. Because it's easier to make a proof about a small piece of code than about a very large piece of code. and when you have a lot of value at stake. So right now, the place where it's happening is aerospace engineering. So in aerospace engineering, they have some programs, and they're sometimes small programs, but if they get it wrong, it's very, very expensive to fix. Maybe your rocket blows up.

So they're using formal verification because it's a good use case. Smart contracts is a perfect use case for formal verification, because there's a lot of value at stake, and there's a small piece of code. So this is exactly in the sweet spot where we should be devoid. it's you know we're not going to be doing formal verification on verifying something like an entire operating system anytime soon but we can do it for smart contracts and which absolutely should okay so I think I think this is like an awesome section and perhaps perhaps we should have you on later to kind of

drill down into this a bit but if you if you're kind of listening to this section and and maybe maybe this section went up went very technical so I'll just give you enough an analogy for it so So imagine like when we invented like, I don't know, steam engines. And we had boilers and steam engines. So these were devices where we were burning coal, putting steam into it. The risk was you put too much steam into it, it bursts. And if you look at the history of steam engine technology for the first hundred years,

a lot of people died because steam engines and boilers burst. Then we invented something which was a safety valve, right? Once you put too much steam inside it, there's going to be a wall that will open and let this team out. And that has resulted in so many lives saved over time, right? So you can think of smart contract technology today, what we have with solidity to be like something like the steam engine with no safety walls. So in the hands of an inept programmer, you could have conditions where things happen and a lot of money is lost. But there is this particular technology where you could institute, something like safety valves, which are like formal proofs that say a certain type of

thing can never happen inside this particular code. So it's like the safety valve of smart contract technology that Arthur here is talking about, right? Would that be a good analogy, Arthur? Yeah, I think so. And I was, you know, I was sad to see after the Dow, you had a lot of people online saying like, oh, well, this shows why smart contracts can never work. And this, you know, this shows why we need to have all this institution instead and deal with the problem socially. A lot of people were saying the idea of like, oh, replacing contracts with code can never work because people will always make mistake. And I'm like, okay, hang on, hang on. I don't want smart contracts to die because of a mistake like this because I think they're a very, very promising technology.

And there's been a lot of research. Andrew Miller has done tremendous work showing how easy it is for people to get them wrong, to make small mistakes. they will have large consequences. And people have been ignoring that research, and they really should not, because it's super important to get it right, but it's possible. We actually have a technology

to make sure that the smart contracts don't blow up in our face like a steam engine. So we talked before a little bit about where TAS is at, and it sounds like you're very far, and the law has been built, and you've been working on this for two years. So what's next for TAS? And when is the thing actually going to launch?

So hopefully we're trying to target launch end of the summer, early fall. That would be ideal. Maybe midfall if we get a little delayed. One of the things that is a blocker right now is making sure that the network is resilient to us because I think that a lot of new networks tend to be dust by people who don't want to see new networks. And so we want

to make sure that we have enough resilience at least to sustain to sustain a launch and that requires a lot of testing. So mostly there's some, you know, there's some bug fixes, a few features which are not implemented, some rough patches,

but mostly we're mostly we have a working prototype we've had for a while. It's really a lot of a lot of polishing work happening right now. And also, you know, I was not really promoting Tizzo's for a long time.

And right now, I went back to promoting it. I want to get people interested in a project and I want people to hear about it before we launch. I don't want to launch it and no one knows about it. And I mean, launch with a proof of stake system, right, that's not going to be mining. So how is the currency or the tokens, is there going to be a crowd?

or is there going to be some other way of distributing those? So we're looking at several options at the moment. One of the options that we are definitely going to have, it might not be the only thing. You mentioned crowdsale. There might be some form of crowd sale. One of the option we're looking at is doing something like a Bitcoin drop. And the idea is the following.

The idea is that we take a snapshot of the Bitcoin blockchain. And then we take the snapshot and we put it, we put it into a miracle tree, and then we embed the root of that tree inside the genesis block of Tezos. And what it gives you is a possibility of saying, let's say I own some Bitcoins, I can form a proof that I own an unspent output at this stage of Bitcoin. I can insert that proof as a special transaction inside the Tezos blockchain and receive tokens. So that's one way we can use to distribute some tokens. Okay, very interesting, yeah. And so you mentioned also that Tesos is a company,

and you've kind of been bootstrapping that. Do you see a longer-term business model here for the company or what's the relationship going to be between the entity and the protocol itself? Right. Oh, I'll just add something to the previous question, which is that even though there's no mining, there is block forging and there is a reward for actually participating into the proof of stake activity, which is very, it has, I think it's very, very slightly inflationary at the beginning,

but it's not, it's nominal inflation, which means that it doesn't really deval the currency because you basically receive it in proportion to the tokens that you already hold. So it only changed the nominal of the currency. It doesn't mean that it doesn't dilute anyone. But the other thing also is that if you don't want to be participating in proof of stake, you can delegate it to someone else, and that person is going to collect rewards. So people who actually contribute resources to the network who run nodes actually can receive tokens out of doing this.

So regarding, yes, so the TESA product has been bootstrapping for a while. going forward I think in practice who's going to propose you know S2 S3 S4 and so on so forth I think for the for the time being

most of the you know most of the protocol updates are going to are going to come from us for the time being the idea of having the governance model is not so much that

we're so bad at making propositions that we really need even want to be doing it it's is a safety valve it's the idea of saying, okay, you know, we don't want, I don't want, we don't want, we don't want to turn evil and just start saying like, okay, you know, now we have to take our, our, we have to, like, you have to take our change. If you look at it, you know, you might say, okay, what's the serum governance model? Where does they have the Assyrian foundation? Okay. But then yesterday, we already had, uh, this big question's like, well, you know, should they do a fork? Should you not do a fork? To say the doubt. And then they were like, well, we let the miners decide. And like, wait a second, you know, what does the miners decide? And like, you know, what does the miners decide? have to do, what do the miners have to do with this? They're not the one holding the ESAs. They're not the stakeholders.

So, yeah, for the time being, we're going to be basically proposing upgrades to the protocol and try to make it as good as we can. Cool. Fantastic, Arthur. Thanks so much. It was a really great discussion and super interesting. Now, you mentioned that you're sort of gearing up to the launch and you would like to get people more involved.

Where can they go? and what can they do to get involved in the project? So right now, okay, so this is an important question. Sometimes people say like, oh, well, you know, where's your Git repository? Or sometimes they say, where's your GitHub? Because Git can only exist on GitHub. But we have not released a source course of Tezos. So Tezos is going to be released open source.

You know, there's no way you can do a decentralized ledger without having an open source code base. The reason we have not released the source code is that, that when Icerium launched, it had a source code out, but he also had a very long roadshow. You know, there were Assyria meetups all across the world, people were talking about it and so on so forth. So they had this perceived legitimacy. We're a very, very small project. If I release, you know, if we release the source code immediately, there are some people who are going to,

there's some people who are immediately going to try to fork it and who are going to try to, and who are going to try to launch it. And people did this with Assyria. And the reason they didn't really succeed is because people were still following the main project. So we want to build this legitimacy first to be seen as, yes, this is the official TESO's development before we actually release anything. We will release the code, of course, prior to the launch, because we want as many people looking at it as possible before we launch anything. But that's probably not going to happen until September. I am giving a talk at a strange group

conference in September, and so yes, the code will be available by then. but so what can people do right now for contributing I would like to get people to start discussing about the projects seeing what their IDs are for governance saying what they would like to see in Tezos we have a smart contract language which tries to have as many high-level primitive as possible it would be great to start seeing tools

to build around this language compilers all this type of all this type of stuff but for now I would like to get some I would like to get some awareness I would like to get people starting talking about it and and giving feedback on the project okay well thanks so much and of course we'll we'll put links to the website white paper and and the other stuff you've written on there and there's a way to sign up for the mailing list as well so maybe people want to do that if they want to yeah keep the rest of the latest developments here also thanks so much for coming on

It was a great pleasure. Likewise. Thank you very much. So with that, we're at our end. So Episand and Bitcoin is part of the LTV network. You can get this show and many others at Let's TalkBitcoin.com. We're also still doing this t-shirt contest. So if you leave us an iTunes review,

just send us an email at Show at EpisandumBitcon.com and we'll email you one of those. So thanks so much and we look forward to being back next week. I don't know.