Building Decentralized Blockchain Applications with JavaScript – Rowland Graus, Agoric

This is texturing TV. Hey guys. Thanks for the throw.

We're here with rolling Grouse who is head of product for a gorg and we're going to be talking about blockchain, but not just the platforms and the theory that goes with it, but also How the applications and maybe what the implications are for devops teams. Hey Roland, welcome to shop. Hey Michael, thanks for having me on we hear a lot about blockchain and people are building all kinds of interesting applications.

And it's only a matter of time before those applications get added to devops workflows and become part of the larger scrum as they say and the question that I would put to you is so what are those applications going to be built in what tools are people going to use and and what are the platforms look like? Because yeah, it's not rocket science at the end of the day. It sounds like magic but hey, it's a platform.

You got to build applications for it much like any other right? Yeah, yeah, that's right. I you know, I think that as the industry has evolved the tooling around how to actually build and deploy contracts has evolved with it and you know a lot of that started with ethereum, I think as we as you think about what it means to to build and simulate contracts before they go live to production blockchain has a bunch of additional challenges that may be a little bit unusual to to developers coming from other places.

So, you know, you have to simulate a chain running, you know at times you may need to simulate other chains or Bridges or external economic activity that affects the things that you are deploying and so that does bring a bunch of challenges and I think the industry is still sort of catching up with some of the tooling around that that said, you know from the igoric standpoint. We are focused on JavaScript developers and that means that at least from you know, as your coding you're able to build in your normal tools, you know vs code with all the functions that you typically use and you know auto complete on your functions and things like that, which I think Ends up being a huge Force multiplier for developers early on. How much do I need to know about the underlying platform versus just JavaScript itself?

And how much can you abstract away the complexity of that platform? So the developer just writes their code like any other app? Yeah, that's a great question.

And I think inorg we do a good job of abstracting away the platform. So the what you have to learn to build in a goric is the specific Frameworks that we put out there. So we call that Zoe or our smart contract framework and our electronic rights transfer protocol.

And once you understand how to work with those Frameworks, then you mostly are abstracted away from anything around consensus or or things like that. And and so, you know the way it typically works is you know, this industry is moving so quickly when you when you're building stuff that's on the bleeding edge around new functions that are coming out at the blockchain level. You may need to be aware of those but for smart contract use cases which covers probably 95% of what people want to build you really can ignore anything that's going on in consensus.

So happy to dive in a little more deeply or contrast that with Syrian but I think from from our side that's been really important for us because you know as you've seen It becomes very difficult to build in blockchain. Even for season developers because they need to be aware of so many different parts of the stack in other systems. Are the things that developers need to know about building a smart contract in particular using JavaScript?

That's slightly different. I mean what makes a smart contract smart? Yeah, so it's a great question.

Um, I think In maybe this isn't specific to JavaScript but more about how our system is architected. And the way we think that smart Contracting is moving in in our system things are asynchronous. And so when when developers in who are accustomed to and if you're in more similar kind of environment think about how their transactions would get executed everything sort of happens in sequence, but the whole world stops for a given users transaction and so that allows you to think about things a certain way when you come over to our system.

You do need to be aware that there's sort of promises resolving and things like that that it changes your mindset about potentially how you're how your system works. So it's sort of a broad answer but I think that's one one difference coming into our system. I think the other piece for us is you know, we use an object capability model which ends up being a major major difference and sort of mindset Shift versus an account kind of model that you would see in other systems.

We do that intentionally to make sure that as people build they can reason more carefully about the security properties of their system and so a whole lot that we could go into there but that ends up being a mindset shift that you would need to to have coming into a work. We hear a lot of course about web 3 is the great new buzzword of the moment. But my question to you is, you know, we really just talking about a centralized approach versus a decentralized approach and eventually we're just going to consider.

This is an extension of the it Fabric or his web 3 something that is fundamentally so different that we need a buzzword for That's a good question. You know, I I sort of leaned towards your former description where it really is a Continuum and you know, I I think there's a lot of people in the space which who are decentralization maximalists and to me that's just not a useful position to take it all like there's there depending on the use case certain things should be centralized or or decentralized. You may choose to trust a third party versus not and so the way we like to think about it is it should be seamless to move between the same kinds of environments that people are used to working in in web too to a more web 3 kind of kind of architecture without without really having to think that hard about it.

The analogy that some of our Founders tend to use is you you link out from a corporate control kind of Internet to the broader internet without thinking about it at all, right? You don't think about oh, I'm I mean this system that sort of enclosed only to my Corporation versus I'm going to the broader internet you just kind of like go between things depending what you need to do and that's likely how this evolves to I do think that in web 3, it's the part that ends up being very different is you actually do need to think about the characteristics of what's backing what you're doing or the or the trust assumptions that you're making and arguably you should be doing that more in web to also right, you know people use Facebook without thinking about the trust assumptions they're making there but here it becomes much much more visceral and so that will be that is something that is a little bit different. But again, it really is just a continuing.

And today a lot of folks rely on devops platforms of a variety of kinds to build both monolithic and microservices-based applications. Will that all be the same model they use for building our web 3 AppSec or is there going to be a different motion or how do these things all come together? Yeah, I'm I'm I think it's early enough that.

It's not totally clear how it will fully come together, but I you know. There will certainly be large and I would say it's an opportunity if you're somebody that's very devops minded to help improve where the space is at. There will be a large number of different.

Ways to sort of simulate like create a workflow for for managing running smart contracts for deploying to production. There's all sorts of stuff around governance that needs to get built. Yeah.

I I think I think frankly we're still very early in all of that. And I don't have a great view on how it's going to Emer, you know evolve or emerge and I would definitely encourage you that if if this is something that you are talented in there is a great opportunity in this space. Are there different use cases for different types of blockchain platforms?

So will I ultimately need to master multiple blockchain platforms or is there going to be one blockchain platform to kind of rule them all in all use cases? And you know, it's going to be kind of this. single standard Yeah, I think certainly not the latter.

There will be multiple chains and there will be multiple Frameworks and the question. I think the question for me is Does it do we sort of land on three or four or do we land on 50 and I I think I'm not sure exactly where where it will evolve. Igoric lives in the cosmos subnesia the ecosystem and the way Cosmos is architected is we sort of share a consensus layer, but then the execution environment above that can change depending on what you need to do.

And the whole idea is that you end up with a large number of chains that operate independently, but can speak the same language when they sort of transfer assets or other things between them that you know that aligns with my own vision of how this evolves with the rest of the Gore's Vision certainly people in the industry. May disagree about that. But it does mean that blockchains can get tailored to specific use cases, which I think is sort of the first part of your question.

Like are there reasons to have different ones? They're certainly are you know, if you look at Solana which is outside of Cosmos their whole their whole idea is let's have the chain process as many transactions as possible and that starts to open up use cases that are just impossible in inferiorate you can have order books that run on chain and actually feel like, you know, a real centralized service would feel that sort of thing obviously is differentiated and I think we're starting to get to a point, you know with with Cosmos with a app change launching around specific use cases and communication between them where hopefully from a developer standpoint you end up only needing to use a few Frameworks, even though there are hundreds or thousands of actual blockchains. What do you think are going to be some of the killer applications for blockchains that people should be thinking about or taking advantage of or or any impacting Us in ways we don't see and appreciate.

Yeah, he really what a blockchain does though. I tend to look at applications where? Trust assumptions are important and and I think that money was the first clear application there where you know, you can have you know, you can have Bitcoin that exists outside of it a nation state guarantee or a bank guarantee it or something along those lines and that's clearly something where you sort of pull a trusted third party out of a out of a system and have it still operate correctly and that has sort of expanded to broader Finance where you can have a lending platform where the code executes the rules around borrowing and lending and you don't need an intermediary there.

And so I would continue to look to those kinds of Those kinds of use cases and I I tend to think of governance as being in an important thing as well where you can have code execute the outcome of a vote without needing to sort of trust anything else outside of the technical apparatus that conducts the voting and that's sort of thing ends up having a whole lot of application. So, you know, if you're trying to build agreement amongst a bunch of different parties that don't necessarily trust each other or want any particular one of them to lead blockchain starts to be the right answer. And so I think that's where we'll see it evolve and then beyond that really just It enforcing scarcity in digital worlds, right?

So, you know, we saw that with nfts in sort of largely trivial examples over the last couple years, but I think that the momentum there is real so enforcing property rights online that sort of thing becomes, you know, a blockchain native thing very quickly. What do you wish customers knew early on versus learning the hard way when they get started and you know, what's kind of your best advice that folks to get prepared for doing this stuff. Well that necessarily, you know having to pay as high in India taxes.

They might otherwise pay. Yeah, so I would say that that tax in in blockchain in smart contract development is really around security it is If you're looking at ethereum or or similar places to build it is really hard, you know, this has been proven out. It is really really hard to build smart contracts that end up being robust over the span of time because they they're open to the environment.

They're under attack at all times this week on Monday. We had a hack of The Nomad Bridge which was holding something like 200 million dollars worth of assets and it was it was on the ethereum side. And this vulnerability was sort of repeatable people figured out that it was repeatable.

We had I think several thousand people go in and exploit this thing, right? So you have these programs that are holding money that are exposed to the outside world and And the know my bridge the team there is extremely solid. We know the engineers like this is not a novice group of developers.

It is hard and so look for you know, a lot of what Agora has done and the hard work that we've done is around trying to build our Frameworks such that you you can't make certain kinds of Errors anymore. And I need to look deeper into the Nomad for attack. I'm not saying we would have necessarily avoided that specific kind of error but there are a lot of those, you know, re-entricity of bugs things like that which are very easy to make in existing blockchain infrastructure, which don't exist anymore.

And again to use a Founder analogy. We tend to view it as sort of similar to the introduction of memory safe language. It's where there were just suddenly a certain kind of class of Errors.

You just couldn't make as a developer anymore. And that's what we're look really looking to enable is making it easy for someone that isn't a security expert to build a secure smart contract. All right.

Hey Roland. Thanks for sharing your insights on what's gonna be a whole Brave New World of opportunity for building applications and extending devops workflows. I'm sure we wish you best of luck and talk to you again soon.

All right. Thanks for having me on Michael. All right back to you guys in the studio.