The Blockchain Debate Podcast

Motion: The future of blockchain will be an oligopoly of public blockchains (Illia Polosukhin vs. Zaki Manian)

April 14, 2020 Richard Yan, Illia Polosukhin, Zaki Manian Episode 7
The Blockchain Debate Podcast
Motion: The future of blockchain will be an oligopoly of public blockchains (Illia Polosukhin vs. Zaki Manian)
Chapters
The Blockchain Debate Podcast
Motion: The future of blockchain will be an oligopoly of public blockchains (Illia Polosukhin vs. Zaki Manian)
Apr 14, 2020 Episode 7
Richard Yan, Illia Polosukhin, Zaki Manian

Guests:

Illia Polosukhin (@ilblackdragon) - debating FOR the motion
Zaki Manian (@zmanian) - debating AGAINST the motion

Host:

Richard Yan (@gentso09)

In a world where decentralized applications proliferate, will these applications be built on top of a few or many public blockchains? Exploration of this topic would help us understand the merits of the coexistence of many protocols. On the extreme, each dapp can have its own chain, so that the developers/community for each app can have maximal control over the full stack of their product.

The guests we have for this episode have essentially voted on their position with their feet. The oligopoly advocate is cofounder of a layer-1 protocol, and the multiplicity supporter is a major contributor to one of the earliest, if not the earliest, blockchains designed with interoperability in mind.

Be sure to also check out our previous episodes too, on Bitcoin’s store of value status, tokenization and smart contracts, DeFi, bitcoin halvening, China’s future in blockchain, and POW vs POS.

If you would like to debate or want to nominate someone, please DM me at @blockdebate on Twitter.

Please note that nothing in our podcast should be construed as financial advice.

Source of select items discussed in the debate:

Show Notes Transcript

Guests:

Illia Polosukhin (@ilblackdragon) - debating FOR the motion
Zaki Manian (@zmanian) - debating AGAINST the motion

Host:

Richard Yan (@gentso09)

In a world where decentralized applications proliferate, will these applications be built on top of a few or many public blockchains? Exploration of this topic would help us understand the merits of the coexistence of many protocols. On the extreme, each dapp can have its own chain, so that the developers/community for each app can have maximal control over the full stack of their product.

The guests we have for this episode have essentially voted on their position with their feet. The oligopoly advocate is cofounder of a layer-1 protocol, and the multiplicity supporter is a major contributor to one of the earliest, if not the earliest, blockchains designed with interoperability in mind.

Be sure to also check out our previous episodes too, on Bitcoin’s store of value status, tokenization and smart contracts, DeFi, bitcoin halvening, China’s future in blockchain, and POW vs POS.

If you would like to debate or want to nominate someone, please DM me at @blockdebate on Twitter.

Please note that nothing in our podcast should be construed as financial advice.

Source of select items discussed in the debate:

Richard:

Welcome to another episode of the Blockchain Debate Podcast, where consensus is optional, but proof of thought is required. I'm your host, Richard Yan. Today's motion is: The future of blockchain will be an oligopoly of public blockchains. To further clarify, in the world where decentralized applications proliferate, will these applications be built on top of a few or many public blockchains? Exploration of this topic would help us understand the merits of the coexistence of many protocols. On the extreme side, each dApp can have its own chain so that the developers/ community for each app can have maximum control over the full stack of their product. The guests we have for this episode have essentially voted on their position with their feet. The oligopoly advocate is cofounder of a layer-1 protocol, and the multiplicity supporter is a major contributor to one of the earliest, if not the earliest, blockchains designed with interoperability in mind. Be sure to also check out our previous episodes on Bitcoin's store of value status, tokenization and smart contracts, DeFi, Bitcoin halvening, China's future in blockchain, and POW vs. POS. If you would like to debate or want to nominate someone, please DM me @blockdebate on Twitter. Please note that nothing in our podcast should be construed as financial advice. I hope you'll enjoy listening to this debate. Here we go! Welcome to the debate. Consensus optional, proof of thought required. I'm your host, Richard Yan . Today's motion: the future of blockchain will be an oligopoly of public blockchains. Here, the concept of oligopoly refers to the blockchain landscape being dominated by very few public blockchains that power DApps. The opposite of oligopoly is multiplicity where many public blockchains find use cases. One scenario of this is application specific blockchains, or app chains. So, to my metaphorical left is Illia Polosukhin, arguing for the motion. His position is that the future of blockchain is best characterized by oligopoly. Let's hope Near is included in that elite group of blockchains. To my metaphorical right, is Zaki Manian, arguing against the motion. His position is that the future of blockchain is not best characterized by oligopoly. Indeed, a world with many chains gives use to the utility of an inter-chain protocol such as Cosmos. Gentlemen. I'm very excited to have you join the show. Welcome.

Zaki:

Happy to be here.

Illia:

Yeah. It's exciting.

Richard:

Great. So here's a bio for the two debaters. Illia is the cofounder of Near, a sharded, developer friendly, and proof of stake public blockchain. He was previously at Google where he was a major TensorFlow contributor and a manager of the team of deep learning and natural language understanding researchers. Zaki Manian is a cofounder of Iqlusion, where he operates secure and high-availability validators for Cosmos and Terra. He is former head of research at All in Bits, in which role he helped build the first Cosmos validator dashboard and launched the first Cosmos public Testnet . He is also an advisor to the electric coin company among many other companies. As usual, the debate has three parts: an opening statement from both sides starting with Illia. The second round is the body of the debate, with me directing questions to the debaters. Both sides are highly encouraged to follow up with their opponent after hearing answers on the other side and of course they're also free to respond to each other's points raised during the opening statement. The last round is audience questions selected from Twitter and we will end with concluding remarks from both debaters. Currently our Twitter post shows roughly 50/50 for the two positions. We will have a post-debate poll and whoever tips the ratio more to their side wins the debate. Okay. Let's get started with the opening statement. Illia, please go ahead.

Illia:

Yeah , so high level, my position is that blockchains are based on network effects. That is kind of the goal in general, is to attract more and more people to the network, and on a high level the network that gets most of the network effects captured, and at the same time provides a required set of features, instead of like expectations for people will pretty much dominate the market. And obviously there'll be like some segregation because probably not all features will be in one of the network and it will require some probably like one major which takes off like 60 to 70% of the market. And then a few smaller ones. I look at it as very similar to cloud, which actually has even less network effects than blockchain, right? Like in cloud actually transitioning from one cloud to another does not require you to, you know, also transition your users owning a lot of stake in the network. But even there, right, Amazon kind of completely took cover pretty much most of the startup land. Microsoft managed to take over all of the enterprise and Google tried to fight, but like in general this three actually dominated the market, with Amazon being like in the lead. And this is like developer platforms, right? Again, this is like blockchain is developer platform on steroids, where you have stake, you have kind of incentives, you have lots of other tribalism involved as well, however, like, not great It is.

Richard:

Okay. Sounds good. Zaki, please go ahead.

Zaki:

So first thing I want to say as it's probably start out with the thesis that there is a cost to having many blockchains. And from a developer network effects, or why there are powerful network effects that exist around any successful blockchain. Those powerful network effects are like, you know, trust in the core dev community, confidence in like, your ability to run your software there, maturity of the developer tooling, all of those and like many more, you know, just like a rich universe of assets, and off ramps and on ramps into the system. And so those network effects without a doubt exists and are really compelling. And so the argument for Cosmos is that there is a force that sort of fights those network effects. Ultimately a blockchain is a shared, like a shared environment between human beings and those human beings are naturally going to have differences of opinion. There are always going to be trade offs in the evolution of these systems and that is naturally going to be a reason why the stakeholders and the state machine will frequently want essentially root access on their state machine. And root access means this is like we have our own blockchain. And so what the goal of Cosmos has always been is to create an environment where we preserve as many of the network effects across the entire ecosystem, while acknowledging that reality, which is that people that, like different tribes, different groups of humans, different groups of stakeholders will, will naturally want to kind of branch off, and in an environment where there is a sort of more direct relationship between the shared state machine and the community.

Richard:

Thank you from both sides. Let's proceed to the next round. So this is the time when I'll be asking questions to you both. Feel free to respond to each other's answers as well as your respective opening statements. Before we get started. Actually I think it's necessary to quantify the oligopoly. What in your mind is the number of chains, public chains that will be dominating the scene? How do we quantify the oligopoly, Illia?

Illia:

Sure. I think high level, there's like major distinction between quote unquote features that networks provide, but it's not actually about features per se. It's more of a function of kind of either underlying token or platform itself. And we kind of sees this right now. Like in reality, even though there's , you know, I don't actually even know how many, like hundreds, probably like 200, 300 public chains running right now. There's actually only two. It , it's Bitcoin and Ethereum. And like realistically and for most of the world outside of, you know, our community, which is very small, there's really just only one. There's Bitcoin. And Bitcoin is like pretty much -- it's market share, it's mindshare, it's completely kind of surpassed everything else together. Right? And then Ethereum kind of, it provides a completely different feature set, right ? It's like Bitcoin and it provides us , like first it was the first blockchain, but the second it was kind of the way to store values at, you know, we thought it's anti-correlated to the market -- now yesterday showed us it's not true. But like it's , it's kind of became like a store of values that people want to, you know , buy in and not really like transact into. And then you have on the other side Ethereum, which became obviously also through time more of a like, how do you build more rich financial instruments, how do you actually transact with people in a way where you can move between different tokens and move between different instruments? Right, so this is like at the end, two different use cases that are solving by like the token itself as well as like tooling around it and ecosystem around it over time. The way I see this evolving right is that there will be few networks that capture kind of solidly, some aspects of this, or like some subsets of use cases. And then they still have interoperability, like I do believe in a lot of kind of same ideas around IBC, where you're connecting the existing blockchains and be able to leverage value from one to another. I just think it will be like within, you know, three to five major networks that kind of mostly dominate the market.

Zaki:

Okay. Let me construct a little bit of a framework for thinking about how these different worlds sort of evolve over time. Like and kind of how you define what direction are we actually going in. The first thing is, we need a world of like sort of robust economic primitives, and those economic primitives are both, some of those economic primitives are just code. So it's like here is the code for writing a multisig. Here is a code for, here's the code for writing an automated market maker. Here's the code for writing a two party state channel. All of this stuff exists. And the network effects that are that around are like around like API is like the way the security of the, of these different systems compose, you know, what the developer experience is, what programming languages you need to use, etcetera. There's also these pieces that happen in these things that happen in blockchains that are stateful. So there is the state, you know, that is locked up in a DAO. There is the liquidity that is in the liquidity pools of an automatic market maker like Uniswap. There is that state. So when we talk about kind of the question of like what are we actually talking about when we're talking, when we're like really focusing like on a fine grain level about the oligopoly vision in my mind and the, the multiplicity vision is a world in which the most important stateful things, stateful pieces of software that are shared among the largest number of users, all of their state relies on one or two or three like sort of root blockchain systems. And what we look at within the Cosmos' vision of the world is we tend to imagine a world, where that state is spread out over a number of different blockchains.

Illia:

My question here is when, when you talk about multiple blockchains versus few, right? You've probably noticed this yourself run running validators for multiple blockchains. Like reality is kind of security and governance still roots into somewhat similar subset of people for multiple blockchains. So I mean that's, that's kind of like going, going to governance and like security of this blockchain.

Zaki:

Can we maybe like, stick to like, could we start with like financial incentives before we do that?

Illia:

Sure.

Richard:

Sure, sure. Go ahead.

Zaki:

I don't want to put words in your mouth, but the vision of the largest and most liquid, you know staking pool in the entire world, or like automated market maker in the world is going to be on Near. That's the vision and the largest and most collateral management system for like whatever stable coin that you want to have that'll be on Near. And there'll be community is that like operate and like own the systems but they won't be running the validators et cetera. Is that a way of kind of trying to make this like very concrete for people?

Illia:

So I think like between, yes, on the part of like let's say largest (inaudible) stable coin and largest automated market maker. That's a goal. I think like which community run them? It's actually a very interesting question, because right now in Ethereum, yeah, we expect that a set of miners that mine Ethereum is completed disjoint from people who are operating Maker one way or another, and not going in...I mean I know we want to discuss more on like governance side, but like the question of like sounds, the fundamental components like Maker is that if this is, these people really define most of the DeFi, in Ethereum like I totally agree with that. It's unclear that those people should not be the same people as validators of the network itself. Right? Because then, like, if the network itself is defined by Maker, like and all of the components built on top of it, like it seems like the point there is not that, hey, we should be splitting and having hundred now, like you know we'd have a hundred DeFi applications, and should have a hundred governances that govern each part of this like applications, but they still compose together. It's actually that should figure out a model where you can kind of govern all of this at the same time, because when something fails; when Maker fails, all of this application start to fail as well. And like it's this ripple effect, kind of spread spreads out across the whole network, independent of, it's just one blockchain in multiple blockchains.

Zaki:

So I have a theory that essentially buying Maker tokens is like a leveraged buyout of the Ethereum blockchain, because Maker is sort of the, like the roots of the core use case for Ethereum across DeFi. It's the, it's the root of the whole DeFi ecosystem and one of two things will happen -- either there's a contentious, there's contention in some larger Ethereum debate, at which point whatever the Maker token holders and Maker oracle choose to back, will ultimately be the only side that survives -- barring, you know, forking the network, replacing the Maker token holders and the entire Maker system. It's like you've already, like the maker system and Ethereum have become so strongly coupled together, that forking Ethereum without forking Maker becomes almost impossible. And that is, I think then the real question if Maker was its own chain. And Maker was its own chain, and Uniswap was also its own chain, the governance decision by Maker would obviously have a really big impact on the functioning of the Uniswap chain, and whether or not it was economically viable. Would it be desirable for the people who were running, you know completely another system, to kind of just cede sovereignty to the Maker folks? In which case hopefully the large stable coin on Near is run by Near governance? And then it like all natural composers together? Or will there be like these different, these different tribes of DeFi users and components? But I think you already kind of see this a little bit or some evidence for this, how Compound and Maker are kind of actually the two pillars of Ethereum DeFi. Compound and Maker or do seem to be somewhat decoupled both from a governance point of view, and from like a tribe point of view. And you might eventually run into a world where like sort of Ethereum government is a , is a ...

Illia:

Federal government and then you have, Oh yeah, I think it's , well like at the end we can try to model it after like let's say U.S. government, right, where you have federal government, which is you know, doesn't really need to meddle into state government's problems, but when there is like a clear kind of issue between two States, it will come in and kind of rule it, rule it over. ut if you don't have federal government and do you really just have a bunch of States trying to independently operate, and like one of the States , you know, in complete disarray because of let's say economic crisis. And also the other states, it's kind of depend on its experts, now are completely, like starting to collapse. There's this dependency, right? Where is this like kind of governing function comes in and kind of rules it over? And I think like we actually had this in another Telegram group, right, where you mentioned that Cosmos hub would be this Schelling point for the governance. But that's kind of sounds like, at the end, then that Cosmos hub does define governance .. . Like it does define that from external observer, right? From a user or from even another chain, which is not part of the kind of Cosmos ecosystem directly. Cosmos hub is like what makes a final decision on which change to include, which chain just was completely overtaken by malicious actors, or kind of any other of like this high level points are like... If , if makers completely went down, went dark, you know the, all the DAI pretty much is now insolvent, like somebody needs to pay back money in a way, right? If we're trying to build an economical system that actually works, right? Not, not just kind of idealistic system, you know, we need, you know, insurances, we need ability to repay things. We need to, you know, in cases of kind of emergency, being able to resolve the issues and I do, I do think that the governance of the chain itself needs to be more proactive in a way about these issues. Like versus like Ethereum, they're like deciding on ProgPow or not, and you're right -- Maker comes in and says like Hey guys don't do this, otherwise you're going to completely a nnihilate DeFi. And that's kind of c lose the question really quickly, like just a year in of discussions. The question here is like, there needs to be governance that actually is able to make t he decision looking at the whole ecosystem, right, and everything that is connected and like relies on each other either like l oosely or not l oosely. There n eeds to be somebody who will evaluate this risk. And I like, I'm not sure that like current v alidators is that set. Maybe we need to expand t hat. The governance we are kind of thinking which we're not going to be launching with is like really trying to bring combination of different parties together and like developers, as well as validators, token holders, ambassadors, ecosystem leaders and developers. Both like core devs and developers of application. So if you bring all of them together and like when you discuss these questions, you kind of now represented at least all these different opinions, versus just like right now, what is Ethereum governance is just core devs having a call. But there's also miners who kind of not represented there, but actually making a final decision. And there's the actual like Makers of Ethereum, who are deciding which chain, or which change they actually will support are not independent of that.

Zaki:

So one of the things I think that I like most about talking with Illia, and we agree on, like the core, is there are a couple of things. One is we do not disagree about whether or not you can technically build a single blockchain that can accommodate the entire universe of transactions that people want to do. We both like deeply agree that this is just like a tractable problem, and something that you know we are continuously making progress towards solving. So this is not that problem. The problem is, once you have these blockchains, governance does matter. The governance of the systems that we see at scale with blockchains, so far have mostly worked on the basis of there are people with power who choose not to publicly express an opinion. There are people who publicly express an opinion and sometimes don't have power. And it's very implicit how any decision gets made. And it sort of is a black box until there is some significant crisis or controversy and then you actually get to see who has the power. And I think that is a thing that we are going to have to learn in all of these systems. It takes multiple years of their existence and many crises to eventually learn how their governance systems actually work and what the actual disposition of power is. And so I think that this is kind of like why I am glad Near exists and why I'm glad Cosmos exists. I am glad that like there is a vision of governance where there's kind of this massive system that there is going to be some sort of eventual explicit root governance for. I'm glad that Cosmos is trying to figure out if the world we have to build for is a world where we try to make it as low cost as possible to fork, while staying inside the ecosystem. Or build your own community if you aren't satisfied with another community. I think this is the space that we're trying to make sure there's room for in the blockchain future.

Richard:

So, Zaki, let me just interject there. Are you able to maybe talk a little bit more specifically about certain chains that have actually forked Cosmos, and have had relative success in terms of adoption? The key question here being why did they decide to build on something like Cosmos? Is it because of the inter-chain nature that they're taking advantage of? And why did they decide not to build on something you know like Near? Well Near didn't have their Mainnet back then, but you know, maybe something equivalent. Just something more high performant than Ethereum. So examples would be like Binance or Terra.

Zaki:

I think there's like really an interesting question that we're not going to be able to really know the answer until you know the near main net is live and some of these other next-gen Mainnets are live. 'cause largely if you wanted to build something that was very high performance today, your options so far have just been Cosmos or you know, taking the Cosmos code base, building your own chain. And if you wanted to build something that was connected to DeFi ecosystem, your only option was built on Ethereum. So IBC is Cosmos's initiative to change the, you can only build DeFi on Ethereum limitation. And Near is now going to be offering like a performant alternative environment, which is great. So it's great that we're moving forward. The experience that we've had with Cosmos is, teams like Terra and Binance and Aragon. Those three teams have been the most like we see the benefit in sovereignty, you know. To a certain extent, even though Celo isn't the Cosmos code at all. I also view Celo a s kind of, embrace in the vision of sovereignty chain, where Binance was like we want to control the validator set, we want to control the state machine, we want to control the source code, we want to control the protocol. Yes we want to decentralize over time. It seems like over the course of several years. And the, the capacity of Cosmos to sort of support that use case was really valuable to them. Terra is like, you know, we're building a stablecoin i n a payment gateway. Terra is a fully integrated stack where like everything from the oracle layer to the consensus to the end user experience is so tightly integrated, even though they are actually quite decentralized relative to something like Binance. Iqlusion runs validator there and it's actually, you know, we've been putting a lot of work into making our oracle better and you know there's others like there is actually a distributed system there. And then Aragon, you know really felt their status as a stakeholder in Ethereum, in the latest Etherium upgrade where a sort of unexploited DOS vulnerability was closed but broke a lot of Aragon's user experience, and that sort of got them to recognize for themselves potentially the value of sovereignty and interoperability. And so that they have put a lot more resources into sort of exploring that world. So you know these are all data points that indicate that, there is somewhat some demand for sovereignty. But it'll be interesting to see how that trades off against the kinds of network effects that a platform like Near could provide.

Illia:

My position on this, I'll say like, and I think I mentioned them before, like if you have a lot of resources like sovereignty, like something that also reasonably top on your priority, and you can kind of roll out your own chain. And like Binance is an amazing example of that. They have a ton of resources and integrating into ecosystem for them is very easy, because they are a big part of the ecosystem in the first place. Terra has, as far as I know, also like a backing of a huge company behind them, to also like introduce it everywhere. And Aragon, it's I think like, given they already have like a really good community, like it's not starting from scratch. Right. And starting as like already a big application, a big ecosystem ...

Zaki:

It is interesting to me just, sorry to interrupt, but I did want to like just hit home on one point, which is we have seen with both Binance and Terra, a lot of taking advantage, and actually with Aragon too, of developer side network effects. Binance has pulled in lots of stuff that has come up for the other Cosmos teams and core team have built, pulled it into their stack, got an advantage that there's been sort of cross pollination the other way, especially on the client library side. Terra is like, we're going to introduce staking derivatives, which is pulling in WASM work that someone from Near just contributed to, that a Cosmos developer team built and then pulled that on, and is exploring pulling that into their chain. You know, the Aragon chain is , is leveraging technologies from both Peggy , which is the Ethereum to Cosmos bridge and Ethermint, which is the, run the EVM on top of Cosmos technology and Near has comparable technologies for both of them. So that's also cool. But validation of "there can be some sort of developer network effect without everybody being on one chain" does seem to be happening. But I could see a world in which those network effects are on steroids if everyone is on one chain.

Illia:

Yeah, I've tried Tendermint myself, and it is a very nice piece of software to work with, which provides a lot of kind of, bootstraps you into building your chain. I think my main problem there is not in writing code part is actually launching a network. As you know, both me and you know, is a lot of effort outside of writing code. And , that, that part is where like a lot and a lot of resources needs to be applied to actually like push it through versus, you know, there's a reason why a bunch of projects in Ethereum coming out from hackathons, because it's actually enough, it's reasonably enough to have like two days of work and get something running like on a shared platform, right.

Zaki:

But there's a, there's a scenario where sort of that works out to Cosmos, to like the Cosmos vision's advantage, which is Near becomes like the, where new projects incubate, but then when they get to like critical mass, they like, oh, we eventually want sovereignty over our own system.

Illia:

Yeah . If , if this is where we're going, that's probably not the worst world. Where it's like where we have, yeah, we have thousands and thousands of applications and then like some of them mature into like their own chains, you know, the requirement there is, we have thousands of thousands of developers in this ecosystem, which sadly right now, we're still, we're still very far from.

Zaki:

I mean honestly, like to me this is like, and this is why I've always been like I've never viewed really any of these things as any next generation platform is truly competitive, really with Cosmos or with Atoms at its heart. There're so many pieces. So we have this idea that Billy came up with, Billy Rennecamp, who's at the interchain foundation now, came up with what he calls burner chains. Because right now one of the downsides that I feel like I did with the Cosmos hub was, you know we did this like beautiful decentralized launch of the Cosmos hub, and it was like the sort of Testament to like what the future of Proof of Stake. But also told everybody that like in order to launch a Cosmos chain you need like 60 validators and you know, you need to put like a year plus of work in building your validator community, et cetera . And we have this idea that we call burner chains. Once we have IBC, it will potentially create an ecosystem where like you and three of your friends or you and you know , four servers on Google cloud can launch a chain that's connected to IBC, and potentially just exist for a temporary amount of time. So hopefully the existence of IBC will bring launching your own chain into the realm of hackathons. I agree that the current state of the world is, you need massive, massive resources to launch your own chain and that sucks.

Illia:

But I guess the question there is if you bring up a burner chain, how does, as a consumer of this, whatever token or use case of that chain, on the other side, how do I kind of identify as a security of that, right? If I want to compose on top of it, right, and then like tomorrow three of those servers go down and the fourth one, you know, the runner of it decides to like modify our code a little bit.

Zaki:

Yeah, I think it's going to be really exciting to see. These are questions that I've had for a long time and I'm not, I'm not going to suggest that I know the answers to them. I can see a world in which there's an ecosystem of, I don't know like Nexus Mutual, but for the inter-chain. I imagined that stuff like that may occur and make it tractable or stuff like that may not exist. And the idea of just being in, like, one sort of giant unified state machine like Near is, maybe compelling, cause you don't have to build all that stuff. And it's not under my control, or your or your control to kind of see exactly which one comes up. It's up to like whether or not anyone sort of steps up and does a really good job of like starting to manage some of these inter-chain security questions and the whole thing becomes tractable and developers flock to it, or it's a nightmare and a massive complexity and nobody can make any sense of it, and everybody will rather run on Near because you just don't have to think about all this stuff that's complicated.

Richard:

Yeah. Illia to actually build on top of something you said earlier, perhaps regarding burner chain mentioned by Zaki. I think back to a tweet storm that you made in February, where you discuss how a multi chain setup does not ensure atomicity of transactions, and the multi chain setup does not make sure all the state is secured by the same consensus and financial security. Can you talk about this point in more detail?

Illia:

Yeah, I mean I think it's kind of around the same topic we've been discussing. I think, like, the example again going into splitting all of the DeFi into a bunch of chains, and like imagining how that will operate, where you know a Uniswap or some other DEX that, you know, needs to transfer some of the tokens from kind of one chain to another, and from one account to another. But at least executed on this as a chain. So it needs to like do an ABC call and then wait for response pretty much to accept it. Like we actually have like, like our model to build a sharded blockchain for smart contracts. There's not actually, like, it cannot be the same as in Ethereum, where everything is synchronized. All the kind of transaction is like fully atomic , right. We actually cross contract, doing asynchronous calls. And we are thinking about exactly the same problems but like it's way easier for us to solve it, because underneath, we can kind of ensure delivery of the messages and we can ensure that, you know, something cannot be reverted for no reason. Like it's either a state is fully transitioned, or reversed , like, like fully. Versus in kind of, when you have multiple chains and they're all governed by different security, especially if they started governing by like different (inaudible) rule, which you know, like we also have Polkadot coming in. It has a different (inaudible) rule , we have substrate like as a framework which allows you to plug in whatever functions you want. So in the world of like, we have like, you know, 50 Cosmos chains and then they, through IBC connected to some (inaudible) chains and to some maybe like Aurora chain, and to some PBFT chains. And then as you're transferring some of the assets here and there or just calling a function, like you may get the result but then that chain actually reverted for whatever reason, and then like you're already dealing with this result, which like again if it's a DEX, you pretty much said you transfer tokens and, you know, you gave money to somebody, else but you actually didn't. So like I mean that's kind of like whole slew of problems and I guess like I said like somebody either need to step in, and actually like figure out how this works. Or like, from my perspective that that sounds extremely complex and kind of having just like backstop of, like single security provides you like a very simple way. Like, part of what we've been trying to do is like hide sharding and and all of this kind of complexities from developers as much as possible, because like even when I know exactly how all this works, I still don't want to deal with it, right? Like that, that's my point. In Ethereum, like, I know exactly how Ethereum works. Like, I know how transactions are signed and everything. I don't want to use that because it's like too complicated. Like, when I'm, you know, not in a developer mode but actually just wanting to like, you know, play a game or something. So same, same as like when you have all this like chains which are on their own, has their own, like (inaudible) rule, has their own kind of state security, right? And like to be specific, in proof of stake -- And this is very different from proof of work. If you do have to sort of stake, you can do whatever you want with the chain. You can literally, I mean, and that's how governance is. You can rewrite the state. You have (inaudible) to the state, right? So if it has this kind of smaller cap chains that have , you know, that own assets from other chains or, or they operate with other chains, like the validators there can in theory rewrite completely one day . (Inaudible) Change status.

Richard:

Okay. So a followup question for Zaki on that point. In terms of the reasons why Binance, Terra and Aragon DAO decided to go with Cosmos. Was it more of a choice of taking advantage of the performant protocol Tendermint, or is it a matter of them hoping to have some kind of interoperability with each other or with future chains that fork Cosmos?

Zaki:

I would say that like outside of the core IBC contributors, I don't really think that there's still much real understanding of what IBC will look like or feel like. And even we who've been working on this for years have a lot of open questions and so I wouldn't overkill on, "Oh like the promise of IBC is what brought everybody to Cosmos." What had brought people to Cosmos so far is, one, is the performance options. Two is the ability to have an ecosystem, but an ecosystem that somewhat exists on their terms, which means yes, there is still a developer ecosystem. We really, you know, so far sort of after Ethereum, the largest developer ecosystem has definitely been Cosmos. So there is a true developer ecosystem around the software. And so that the teams can build on it, can get help, et cetera. Having sovereignty plus having developer ecosystem, is really like the first time that vision has been captured, was by the Cosmos software stack. And that was why I think we've seen the adoption that we've seen.

Richard:

Okay. And by the way, so someone chose Cosmos over EOS presumably because of the decentralization concerns?

Zaki:

So I don't have very much development experience with EOS at all. And my sense of the development ecosystem is frankly that EOS is less flexible than Cosmos. The way the Cosmos hub got built is we built a general purpose consensus engine, which could be used for all kinds of things. And then we've implemented one specific vision of proof of stake , but we implemented that one specific vision of proof of stake in a framework for building any possible vision of proof of stake that you might want to have, that runs on a BFT consensus engine. So what that made it easy, for teams that have taken that software and built their own systems is they can play with these parameters however they want. They can, they can make the system run however they want. You know, Binance runs it in a proof of authority mode. Terra runs it in something that's closer to the Cosmos hub proof of stake, but the economics are very different. You know, that level of flexibility. I'm not aware of any other software system that is live that has that level of flexibility. Ava team just open source their code and that's probably the thing that I look at as like probably the most flexibility in the Cosmos sort of sense of any other code, any of the code bases I've seen. I think a lot of teams, like especially the EOS team, they're like, we want a blockchain, it was going to work this way, we're going to make a monolith that does that. You know, the Cosmos team was the first team that didn't do that.

Richard:

Okay, understood. So next question is for Illia. With many well-funded public blockchains launching their that last year, this year, and in the near future. Could you paint a picture for us in terms of the pathway towards a future dominated by just a few chains?

Illia:

Yeah. In the near future , that will be one dominating. (Laughing) Yeah, I think like overall there is kind of few things that happening and I mean I like, I know probably most of the major public blockchain teams, because they did whiteboard series with all of them. So like, no disrespect as a technical and like kind of them delivering product, but realistically like it's , it's up to developers to decide which network they actually want to build on. And actually given like current market, it's probably be like very competitive market where developers will kind of like, congregating on one of the networks which provides them like something that they can build businesses on. At least that's our position, right? That's why we like recently launched, to kind of support for businesses, sort of like a kind of startup program because at the end like people actually need to make money. And people need to, like people want to build products, people want to build something for users, people want to build some cool tech, and people need to make money. And it will be up to like.. this network is not, it's not about like their , you know, consensus. It's not about their state machine, it's not about their like even flexibility. Doesn't matter. It would be about like can we get developers to actually like accept like whatever new parameters there are, like open up set of use cases as possible and then attract them to actually build their businesses, and their kind of applications on top of it. And, and like from what I've seen at least networks that launched last year, outside of Cosmos, actually like none of the other ones I've seen any traction on actual developer adoption. Cosmos indeed has, you know, a bunch of teams building on top of it. Polkadot has a bunch of teams building on top of it. We have some, at least I personally haven't heard of many others kind of getting, getting traction. I mean some do and like there's a lot of teams actually like going around and trying to attract developers. But like overall like it's, it's a very like small set of developers who are right now in an ecosystem . So like attracting jam is pretty hard. And then that was a part of it is like how do you market to developers outside and that's where like real problem is real questions. And again, like if we were talking like two months ago, my attracting developers from outside would probably be half of my pitch. But given what happened in the last few weeks , I think like we actually will need to rethink how attractable developers from web 2 will be in the next few months . Just like realistically as people are becoming more conservative with what they're doing.

Zaki:

Yeah, the whole market dynamics have definitely changed in the last, you know , day or two in a variety of different ways, that will be interesting to play out. I also think though that a world of developers who are kind of stuck at home, you know, and looking for cool stuff to play with is actually not a bad world to be launching a new Layer-1.

Richard:

Silver lining. By the way, is there any kind of collaboration possible between Near and the work IBC is doing, or are the two fundamentally incompatible?

Illia:

For sure. I mean we've been talking about, like light clients and few other things for a while now. We're actually building a bridge to Ethereum, which like in spirit actually follows IBC, just missing the product, like the transport level, which probably can be adopted, as IBC matures. But I'm sure Zaki has more ideas.

Zaki:

Yeah, I've been, I mean I've been watching what's going on with Near for a long time and with the hope of Near being a protocol that can run on top of IBC. So I think a couple of really promising things are happening. One is the team over at Informal, which is Ethan Buchman's new company. And the, basically the former spinoff of the inter- chain foundation research team , um, is building an IBC implementation in rust. The only thing that we'll need, we'll need to add to that is the other side of that, which is we'll probably need to figure out some way of implementing a web assembly, or go implementation of the Near light client . Working on light clients is a really good way of kind of really stress testing your consensus system. And making sure that that really works well. So if you are running a consensus protocol like EOS or Algorand, you might have a really hard time building light clients for it. Good consensus teams will usually figure out their light clients' story pretty quickly. I think Near has theirs pretty much unlocked. Celo is doing some really cool things with zero knowledge light clients. But so we actually have this very nice abstraction in the IBC spec called ICS2, which defines what a light client is supposed to provide. And that it actually just defines an interface between the light client and the rest of the protocol. And as long as you develop , provide a piece of software that implements that interface, we can connect to your chain.

Richard:

Okay, great. So I want to go back to a previous point Illia mentioned, and I think Zaki provided an answer to it, but I'd love to hear a little bit more elaboration. And that is this concept of governance of governance, right? Because if you have a multi chain universe and you expect lots of interactions between these chains, maybe from a DeFi transaction, it really is important for one chain to trust that the other chain is doing the right thing, quote unquote. Right. And I think governance of another chain is a piece that's not necessarily easily from another chain. So would IBC be implementing some kind of mechanism to ensure that kind of credibility, In terms of governance?

Zaki:

The entire design of IBC is to have a system that has operates in a fairly, in like a sane , predictable manner. Even if governance on one side of the connection does something unexpected or strange or weird, now it's not going to prevent you from potentially losing money. And there are designs of protocols . So Agoric has something that called Zoe. And has this property that it calls, "offer safety," which it is possible to construct, to have like transaction protocols. And similar to that, Jay Kwon and I designed a decentralized exchange protocol for the interchain . That sort of allows you to always settle on a chain whose governance you sort of believe in. And so there are , there are designs like this, there is some capital inefficiency that always comes up and you have to sort of hedge against these risks. Going to be interesting to see whether or not that capital inefficiency is so large that something like ne near that can offer one unified state machine. The only thing I'll kind of push back a little bit on is that virtually every device smart contract that it isn't Uniswap right now has some form of governance built into it and everywhere in the DeFi ecosystem is currently trusting that governance to some extent or another as we have seen with like crisis that maker's going through right now.

Richard:

That's a good point. Yeah. Although I guess then the question is whether this new governance of governance system is going to be so complex that it will be difficult to get adopted by the developers. Like Illia pointed out.

Illia:

I actually think we need to move towards something like governance as a service, where you actually like when you start your , so one of the issues that I see is that like let's say I'm a developer, which I am, and everyone will launch application on any of these platforms. As a developer myself, I am actually not very, like, prepared to you know, build up a political system out of my application. Not at least like not when you're just starting. And then you starting to kind of , pushing your product, and obviously you want to start building a community. You want to start getting like kind of initial users who are empowered to make decisions on how this thing will evolve. That's like part of the value of what we're building. But like it's unclear that you actually have an ability when to do it for most cases, right. So I actually, like, I've been thinking a lot about how do you kind of go to a place where you have people who are professionally kind of working on kind of governance issues on security issues, on like this interplay of different applications, and how you can kind of pretty much rent some of their capacity in a way to bootstrap your own application. And then over time either you will kind of, fork off some of that into your own governance system or you just stay with this kind of more shared service. And this like it's kind of independent of if it's a kind of Cosmos approach or, or like a shared approach. It's more of a question of like as we going into this like more and more interplay of applications as well as like we kind of require applications to be able to like be community-operated from day one when they're totally not ready for that. Is there like a way to kind of ramp this up?

Zaki:

I mean we , we tried , we , we did this like very sort of insane experiment, which is, you know, we launched the system without transfers being enabled, and we told the community you have to decide when transfers are going to be enabled and that did work out. And so it's interesting like, I was talking to with the open Libra people earlier today about like, you know, when is it that you can put governance in charge, and I'm like you put it in charge in day one, day zero, you know, it governance is in charge, you know that that did work. It has worked out so far for Cosmos. And I think has really improved the , the sense of resiliency among the contributors of the project. Especially as like we've gone through all these recent changes on how this project is organized. Everybody's like, well we do know governance works and it's done and we can use that as our , that's our break glass option for , for how do we reorganize.

Richard:

All right , let's move on to round three questions from Twitter audience. So this is from someone named crypto 401k and his question comes in two parts. First is why would dev choose Near protocol versus Cosmos? Talk along the lines of dev incentives, ease of deployment, amount of on chain assets, if DeFi is the target app, etc. And then the second question is for Zaki. With the recent shuffles at Tendermint, what's the next step for developing the Cosmos project?

Illia:

I think like there's few reasons why to go for Near. And actually the first and primary reason has nothing to do with scalability. It didn't , doesn't have to do much with developer experience. Like one thing we focused a lot on is making sure you can build an application that a normal person can use. Again , we did a lot of work from both, like how accounts are structured, how like we have a web wallet that does need to be installed. We completely redesigned how like keys are managed to allow for kind of per device key, per use case key, per like kind of, multisigs embedded in everything. And what this allows us to do is kind of have a very smooth onboarding which is very similar to (inaudible). It allows us to plug in various kind of key management systems like either right away or over time, where you know you may be starting what we call progressive security. When you are starting, it is not very secure wallet, which doesn't actually have anything in it anyway. And then other times as you're getting more value into it, you may be like gonna rotate your keys and you know, start using key from a ledger or from chrome extension, or from a desktop or whatever. Like that is actually being one of the major drivers for like applications. We are working on it right now because everybody right now wants users like most of applications on blockchain have like low hundreds users, right? And given crypto kitties, which at some point been like super used, have huge drop off rates on signup . People are like, cannot understand how to do, how to use, how do you use this . So that's really like kind of top, topline thing. The underlying after it is like we've been focusing on developer tooling that makes sense, right? Like we've been trying to make sure that it's actually kind of easy and straightforward to build applications. It's easy, straightforward to deploy them. Like we modeled it very closely to kind of, how would you build with React itself? I could have a create Near app, which creates your front end and a back end. You write your code in ( inaudible) Rust, (inaudible) is like a TypeScript and you know, compiles and deployers with one command. You don't need to actually like really know what's going underneath. You don't need to go and like spend two months learning how consensus works, what is reorg, how it will affect your front end, build a caching layer, all of this stuff. That's kind of like a huge benefit there. And then really we, like we've been trying to figure out where we can add incentives for developers. A big incentive actually what ends up being is just helping interfering ours to be more successful, right. So we've been helping a lot of folks who are interested in building a business around this. Both with like everything from just a kind of developer help, we've been having this market kind of a validation. There's general like advising on how to approach like questions, token economics, etc . And then connecting them to mentors. Or connecting them to investors and helping them with fundraise. And so we launched this Open Web collective, which we actually really wanted to be more generic than just Near. And I really liked grow this ecosystem of like entrepreneurs building in the space, where really it's like bringing people together, helping them, making sure as the answer right questions before and then going through acceleration phase, getting them to be funded and build actual businesses.

Richard:

Oh fantastic. That's a great pitch. You started out by saying scalability or even developer UX are not your top priority. It's more about building a viable business. So much more holistic approach.

Illia:

Thank you.

Zaki:

So I think when you zoom out from the details of what's been going on in terms of Cosmos, you have to tick a bunch of boxes. First one, some people have to care about your , your software. Like there has to be some community around it. There has to be users and Cosmos has ticked that box. You've essentially achieved like a , some meaningful level of decentralization of the project, of the stakeholders of the community. And then you run into this like very actually quite thorny problem, which is, you know, when you're, when you're building up towards a launch, it sort of does, you sort of see this...It's sort of, there's, there's comprehensible reason why ... why there's a tendency for most of the people who are contributing to sort of work at the same company. You know, it's the only way to like meaningfully contribute to the project is to is to uh, you know, we've always had a like an open source contributor community but there was this core that all worked at All in Bits , where Jay was the CEO and has become very clear to me in the year after launch. You sort of see this in other projects and ecosystem. Is it like the question of why do we all work for this company when we are working on a decentralized open source project? There are many ways to contribute to this project. Why is working for this company? And it became harder and harder to give any sort of concrete answer to myself to the core engineering team as the project got more mature and more decentralized. And so the, the biggest question was always ended up being like it would be very painful if we had to reorganize ourselves into many, into multiple entities and sort of figure out all our business relationships and sort of collaboration relationships. It's all based right now on this like system that we invented before prelaunch . About how the github repo's are managed, you know, how we interact with each other in Slack. So that was all the reality and essentially this painful process that we've had with, you know , dealing with the situation where Jay's priorities and sort of direction changed from. I think most of what the team wanted to do is we had to go through all of this painful process of dividing up the work among multiple entities. It's still work in progress to figure out how all these pieces fit together, but we've made an enormous amount of progress. Ethan just threw up a blog post today . Today is the actual anniversary of the Cosmos hub launch. Just sort of about the progress that we've made and sort of the work that he has played an instrumental role in, you know, getting the engineers into this new inter-chain Berlin entity. Most of the engineering team is there, you know, empowering the work that I've been doing with Iqlusion, getting other teams to step up. I think in many ways this re-org, is a blessing in disguise because we are actually trying to actually figure out what is a longterm sustainable incentive-aligned ecosystem for development of Cosmos before what we had was a thing that was very successful in the sense that it was able to do a number of things that sort of changed the entire direction. You know, set the path for the entire industry, but in a lot of ways also the incentives never really made any sense. It was just a question of inertia. That was in many ways keeping , uh, keeping things the way they were. And now that we've had to overcome that inertia, we're sort of exploring this new space.

Richard:

Well, thank you guys. We've now come to the concluding remarks stage. We'll start with Zaki. Hoping to hear from you synthesization of your thoughts from the debate, anything you've picked up from your debate partner, please go ahead, Zaki.

Zaki:

We're at a very interesting point in the evolution of these systems, where IBC is sort of imminently going to be available. You know, we're banging away at the, at the demo as we speak, trying to manage coronavirus concerns and all these things that are slowing us down, but it'll be ready sometime next week. The weekend after. And that demo I think is like the first thing that like really unlocks developer ecosystem around it. And now we have these open questions about whether or not all of the problems that we've, or the challenges or the opportunities that we've sort of scoped out for, what might happen after IBC launch after IBC exists about whether or not they'll get solved or they won't. At the same time, the Near sharded blockchain is about to launch its Mainnet, and we're actually going to start seeing all these new developer experiences come about. Cosmos is going through its first governance crisis and we're starting to see how that plays out in this, in this world. All of these things are kind of very exciting and we're learning a lot. I'm very excited to see sort of the beginning of the IBC dream realized.

Richard:

Okay, fantastic. Illia your turn.

Illia:

I always appreciate Zaki's perspective, both because I mean he's been in the ecosystem and through kind of getting the network to launch and launching and post launch, and now so like a lot of kind of maybe somewhat traumatic but at the same time like ( inaudible) experiences. So always interested to learn from him. The way I look at it is like I'm looking, you know, one one year in advance of where we might be. So it's always good to kind of has this foreshadow, similar to how it is with Corona . Like you know, you can look at China, what's happened over the last two months and kind of see what's going to happen here. But anyway, yeah I mean I think like governance will become very important. I think actually Ethereum has been brewing governance crisis for like I think like last two years it's been like very slowly doing that. And did it actually culminate? I think from my perspective it's been mostly like kind of popping up and it's like people are just like, oh whatever, and kind of moving on. I think if they actually planning to do something about ETH 2, in kind of approaching the future, they'll need to like really figure this out. But yeah, I think like the way he kind of, we think about it is how can we actually pass down those governance ideas and give ability for developers and community to participate in more fully, while managing sounds as like clear issues that we see in existing networks.

Richard:

Okay. Great. And finally, can you, Illia say a few words about developing a light client for Near on IBC ?

Illia:

Sure. Yeah, so we have a spec, it's in a github in NEPS repo, for light client. But also just join our telegram, discord, Twitter and reach out to us. We'll , we'll help out. But yeah, in general, we also, I think we'll have a version, somebody soon in near-bridge, might be a good version to look at. And I think we have somewhere Python version, as well in near-core. So yeah, just reach out to us . We'll point you to the right places to look.

Richard:

Okay, great. Well. It's been a pleasure to have you both on the show. How can our listeners get in touch with you?

Illia:

Twitter, Telegram.

Zaki:

Yeah, I'm at zmanian on Twitter and that's usually the best place to find me.

Richard:

It's been an absolute delight to have you come on the show and debate. It will be interesting to see how things unfold from here. I definitely learned a significant amount from this. So listeners, we would love to hear from you and to have you join the debate via Twitter. Definitely vote in the post debate poll and also feel free to leave your comments there as well. We look forward to seeing you in future episodes of the Blockchain Debate Podcast. Consensus optional, proof of thoughts required. Cool guys. Thank you guys very much.

Zaki:

Bye.

Illia:

Thank you!

Richard:

Thanks again to Illia and Zaki for joining the show. It seems reasonable to conclude, that in the world with lots of dApps, the underlying public chains will follow a power law distribution. This is not only due to the more obvious network effects. It was pointed out in the debate that, creating a new public chain is expensive, partially because of the time-consuming efforts going into growing a validated community. Also, there's an inter-chain trust issue where a dApp-specific chain that is quote unquote unvetted, needs to somehow demonstrate appropriate level of security afforded by its various components such as governance, consensus algo, and validators set. It's great to hear about the progress being made by IBC, or inter blockchain communication. After all, regardless of a future characterized by oligopoly or multiplicity, some kind of interoperability is always helpful. What was your takeaway from the debate? Don't forget to vote in our post debate Twitter poll. This will be live for a few days after the release of this episode. And feel free to say hi or post feedback for our show on Twitter. If you liked the show, don't hesitate to give us five stars on iTunes or wherever you listen to this. And be sure to check out our other episodes with a variety of debate topics: Bitcoin store value status, tokenization and smart contracts, Defi, Bitcoin havening, China's future in blockchain and POW vs POS. Thanks for joining us on the debate today. I'm your host, Richard Yan, and my Twitter is @gentso09. Our show's Twitter is @blockdebate. See you at our next debate!