On The Brink with Castle Island - Jon Kol and Asa Oines (Abacus) on the Third Era of Interoperability (EP.319)

Episode Date: May 16, 2022

Jon Kol and Asa Oines, cofounders of Abacus join the show to talk about the state of the art in cross chain interoperability. In this episode:  Career trajectories and why Jon and Asa decided to start Abacus  The three eras of interoperability  Asset interoperability vs app based interoperability  Why asset interoperability might just be a transitional phase  Why asset interoperability is more about the creation of derivatives than true portability  Application parallelization or duplication versus native cross chain applications  Why duplicating applications across chain is inefficient  The advantages of building natively cross chain for developers How blockchains can be made to communicate with each other Key assumptions you need to rely on to trust that Abacus will work  How Abacus is distinguished from other interoperability protocols  Why speed matters in cross chain  How Abacus differs from Layer0 and Axelar  Which blockchains Abacus is linking together  Learn more about Abacus 

Hello and welcome back to On the Brink. I'm Nick Carter. Today we sit down with John Cole and Asa Oynes of the Abacus Network, a project devoted to cross-chain interoperability with a focus on applications. We talk about their career trajectories to date and why they decided to leave Galaxy and CELO respectively to start Abacus. The three errors of interoperability, the move from asset-based interoperability to app-based, and what the advantages of app-based interrobability might be the problems with creating derivative asset on chains and the challenges that we've seen in terms of blockchain applications, fragmenting liquidity across chains as they try and duplicate themselves across chains. We go into much more detail in the episode. Let's dive right into it. Hello, gentlemen, sitting here with John Cole and Asa Oynus of

Avicus. Asa, it's your first podcast I've been told. Thank you for joining us. You've been told correctly. It's very exciting to be here. Thanks for having us. Good to see you, Nick. There's actually, thank you, John. There's actually a number of guests. We've done like 300 episodes of this podcast, which is crazy. There's a whole bunch of people who chose us for their first podcast, so we're honored that you selected us. Let's jump into it. Let's take an intern. We start with you, John. Tell us a little bit about your career. A lot of our listeners will know you, of course. And what led you to Abacus? Thanks, Nick. So I spent the last five years investing in crypto in various capacities. Before that, and actually during those initial periods, I was a bond trader with Morgan Stanley, which is a funny, you know, vocation for someone who has a strong distaste for banks of all kinds. I've had terrible experiences with banks since I was a teenager.

growing up in Israel where the banks are notoriously unpleasant and you really don't want to deal with them if you don't have to. Then had the luck or misfortune, you could say, of being one of those Wells Fargo clients who got ripped off in the big account scandal. But leaving school, Morgan Stanley was one of the few places where I could make the living that I needed to support my family. So it was a good choice. And a trading desk is a really fun place to be. it's a high energy environment and it's an intense workspace which is kind of what I was looking for and I found crypto right around the same time when I started there in 2016 and very quickly became the laughing stock of the desk for being the crazy guy who's into this weird coins thing and has

computers that mine stuff which mind you a bunch of fixed income traders could not wrap their head around no matter how many times I tried to explain it and at some point became obsessed with the idea of just working and helping support this industry. And so my time in Morgan Stanley became numbered and told my boss, hey, I'm going to take the first opportunity I can't to get into crypto full time. That happened in late 2017. Join a firm called Passport Capital, became one of the venture investors there, had a good run there.

And before you know it, time passed and I had the opportunity to join Galaxy Digital. where me and my partner at the time, Michael Jordan, built the investment team. You ran it for the next three years until meeting Asa and the bunch and very quickly became convinced that I want to move on to working on advocates. And you asked, like, what made me want to work on it? So in five years of investing in crypto, I'd spent a ton of time thinking of

interoperability because the moment you rock the idea of like these internet computers, these decentralized clouds that blockchain is going to be, you're like, wait, why don't they talk to each other? Why, if I'm on one of them, why can't I just move over to another one? It seems really, it's very unintuitive that this would be the case. But once you get, you know, that's kind of like there's this Dunning Kruger peak where like you don't know what you don't know and you don't understand enough about how these systems work. And you're like, interoperably, it's going to happen any day now. And you don't understand why it is the case that the systems can't natively communicate

with each other. And you don't appreciate the difficulty in that. And with time, I learned, like, wait, this is a non-trivial task. I used to liken it to the crypto equivalent of going to the moon from the difficulty of the engineering task. And meeting AESA, meeting the rest of the team here was the first time that I felt like, you know what? we should choose to go to the moon.

Because like in this case, we have the design, we have the capability to actually do it. And, you know, it took a little bit of thinking on mine and some persuasion, but it didn't take that long. And very quickly, I was like, shit, I have to do this. And dove head first. All right. A-so would about yourself? Yeah. I grew up in, you know, you asked for a career, but I'm going to take you all the way back.

I grew up in Watertown, Massachusetts. Nobody knows it, but it happens to be neighbor, the far more famous Cambridge, Massachusetts. And as a junior in high school, had the good fortune to find myself interning at the MIT Media Lab on a PhD thesis project for Ara Knaian, in case he's gotten into crypto in the last. I don't know how many years, working on a reconfigurable robot using electropermanent stepper motors. And we didn't have a computer science program at my high school. And so this was really my first exposure to this world. And I absolutely fell in love. Spend as much time there as I could.

Quit all of my sports. I wasn't very good at them anyways. the subways and public transportation, I believe, stops running on weekends at 2 a.m. And I found myself missing that pretty frequently and walking, you know, the three or four miles home back to my house just in order to spend like a little bit more time at the lab. And so from that point on, I was pretty convinced that this industry, you know, computers generally is. is kind of what I wanted to devote my life to. So I spent the next five years at MIT as an undergrad and then doing my master's, the latter of which

I studied under Seth Canbar, would later go on to Found Cello, spent three years after school at Google doing machine learning research, specifically acoustic modeling for speech recognition. And then SEP, with whom I had stayed in touch, kind of been a mentor to me since I first started studying under him. He had always been pushing me to do something more entrepreneurial than join a, I think at the time, at least 100,000 person company, maybe 200,000 people. Probably the least entrepreneurial thing you can do coming out of MIT.

And in 2017, during that full market, right, when everybody was, I guess, a lot of the world was getting into crypto for the first time, Cep started reaching out to me and saying, hey, you know, I think there's something really interesting here. You should start learning about it. And in particular, he pointed me to some of the, work on natural capital-backed currencies and how crypto was maybe the first opportunity to actually try this out in the real world, right? It was an idea that had been around for a while, but the technology to make it possible just didn't really exist and crypto and in particular Ethereum was the first technology that

would maybe allow for something like this to be possible. So I thought that was a really inspiring idea. It's kind of the first thing that I've had ever heard of that seemed like a solution to the root cause of some of our kind of climate and pollution issues rather than, I guess, treating the symptoms, right, more kind of bandits. And so when Seth and Merrick and Renee, we're starting Selo later that year, it's kind of a natural. kind of decision for me to join that project and I spent about four years there leading protocol engineering where I designed and helped build things like the stable coin protocol consensus proof of stake kind of a broad array of things and then kind of towards the end of that started I guess I really really throtties

off of greenfield work and obviously four years in kind of start to lose that aspect of things. And so kind of looking at the optics protocol, which was developed at Sea Labs, saw an opportunity for the opportunity to do more greenfield work and thought there was an interesting direction that we could take it in focusing on kind of app first and app centric interoperability. as opposed to kind of ecosystem-wide or like ecosystem-first interoperability or asset-first interoperability, which I think to date has been the focus of a lot of interoperability projects. Yeah, great segue there. So, you know, I think you guys define it as there being three eras of inter-op first sort of, you know, kind of walled garden-ish, almost, where, you know, it's interesting. interop, but within this sort of defined rule set. And you have to kind of play by the rules of the one protocol.

So, you know, I don't know how much introp that, you know, truly gives you. But, you know, it's interesting because I think Pocod is kind of emblematic of that. But, you know, they're just still just now sort of getting up and running. So it's almost like we're still learning about that era. Yeah. Yeah. And, you know, I mean, are we still in the first era of interoperability, sort of Cosmos and Poca We might be in parallel in all three of those eras.

So to give the audience some context, so we think of there being three errors of interoperability. The first one looks like more of these, as Nick said, right, these defined rule sets. You could think of Cosmos being a Cosmos and IBC, really. being a beautiful example of that, Pocodot in substrate, a similar one, where the system gives you a set, like gives you a toolkit, and it's as long as you're within these bounds. You know, in IBC, it's if you have fast finality and a light client,

if you're a parochene in the Pocodod world, you can have great interoperability within the confines of the system. Then, you know, as you said, Nick, that area is still kind of playing out today as these things take a long, long time to build, and they take a longer time to scale. So what started as designs from probably six or so years ago are now starting to come into fruition. But from then on, we moved into another era, and it's fair to say these are all parallel

processed. But starting kind of in 2019, you started to see this asset-focused interoperability, which is, a lot of the bridges that we see today that lots of people use and the idea is like hey I want to get this asset from this chain to that chain I have some Ethereum I'd love to take it to salon hour I have some USDC but I have it on Ethan I'm really I'm dying to take it to Polygon and that was guided mostly by the needs of the power users of the last couple of years, which have been trading firms, right? If your jump, if you're Alameda, they needed, they were active on all these chains and they needed to move those assets there,

and they needed to move their fast, and they needed to move it securely. Of course, this met the needs of many users, and that's why these bridges are very, very popular. But we think it's time to move into this third era, which is app-focused interoperability. And really why that paradigm is much more interesting to us is if you think of what the bridge allowed you to do, it allowed you the user to go to the app, but we want to help the app come to you the user. And so how can we make it where your application can really share state between a bunch of blockchains and where your, you know, your total applicable, you know, market, you know, your TAM now gets to expand beyond the chain that you happen to choose on. And how did you just return?

briefly to the asset interop era. I mean, how do you judge the success of that era? I mean, obviously there's high-profile hacks there. Was that sort of a functional model or was that just a transitional phase? So obviously we're biased. We're inclined to think it is a transitional phase because it's all of this immediate need. The bridges as they're constructed very much fit that mold of being a painkiller because someone desperately needed to move assets from chain to chain and they couldn't think of a better way to do it that didn't involve swapping through a centralized exchange. And it works really well until it doesn't, as we've seen from some of these breach events. But really the main issue that we see with the bridge is it's not so much the security incidents

of although those obviously are very important. Like the two largest recent security incidents are not necessarily the result of like the bad security of the Bridges 1 in Ronan was an operational security on the bridge operators, unfortunate. And the other in Wormhole, again, was it was kind of a code error and the fact that the pull request was submitted but not merged for some amount of time that probably allowed the hacker or the attacker, let's call them, to figure out that there is some attack service that can be made. But the network actually operated as intended. It's just that bit of code was the issue. And so really the problem that we see with bridges is not that, not just the

security. It's the fact that they create this very unpleasant fragmentation because each bridge is going to output a different asset. And so that's how we end up. now with say 15 forms of tether on you know on a chain like Salana because there each bridge like each bridge now tells you oh my representation will win and now we have this token representation war which is really to the benefit of no one it's hard to think who really benefits from this and so with abacus we think we're actually allowing a single issuer to create their uh their token in a multi chain fashion kind of natively. So that's our opinion about that.

But certainly if you spoke to someone else, I'm sure they would be more supportive of that bridge model. And maybe to expand on that just a little bit, for some color for the audience in case they're kind of not familiar with how these things work under the hood. Token bridges typically do not actually, I guess, move the token from chain A to chain B. What they really do is you as the user, give them your token, and they will issue a derivative for you on a different chain.

And so all of these bridges are issuing slightly different derivatives. And so again, you're not really moving the token. It's just who's, you're asking yourself kind of when you decide to use one bridge or another. It's like, whose derivative would I prefer to have on this destination chain? And it's not actually kind of the underlying asset. So in terms of application first interoperability, I mean, there are applications that are parallelized on different blockchains. You know, they're not exactly, I wouldn't consider that shared state,

but you'll have the same application being sort of mirrored or duplicated across chains. what's it going to look and feel like to have an application that's sort of natively cross-trained? Yeah, no, that's a great point, Nick. So the model that we've seen for taking applications cross-chain thus far has been exactly, as you said, a model of duplication, where you take the same code, let's say you start by launching your app on Ethereum, for example, and you want to launch on Polygon. You take the exact same code that you've deployed on Ethereum, and you deploy it again on Polygon. And now you have two entirely separate instances of your app running on two entirely separate networks.

And the thing that really connects them is in their functionality. So they're doing the same things, even though they're not touching each other in any way. They do the same things. And in their brand. So, you know, assuming it's kind of the same. like entity that's kind of associated with both of these deployments, you might get the same, you know, you might be able to visit the same website and click a drop down and get to choose kind of which of these two parallel deployments you're interacting with.

There's a big drawback to this approach, which is that when you have two entirely separate instances of this app, they don't benefit from the existence of another. So imagine you kind of had initially launched on Ethereum and say your lending app, for example, you launch on Ethereum, you do all this work to kind of build up, say, you know, a billion dollars in TVL. Right. And each additional dollar that you're getting in TVL makes the application more usable, right? the kind of cost to borrow goes down, the available assets for people to borrow goes down.

You know, most of these networks are most of these protocols have very strong network effects. When you launch your app on a new chain, an entirely separate instance, you don't benefit at all from all of the work that has gone in to building these network effects on you know, in this example on Ethereum. In a world where you have truly app-centric interoperability, because those applications are able to share states, either through Abacus or some other kind of cross-chain messaging protocol, you can kind of think of those two applications as one. You're just now reaching, it's not two applications as one,

you're just reaching a new set of users, a new set of assets and becoming interoperable with a new set of protocols. And so rather than starting from square zero with respect to your network effects, in many cases that's TVL, you bring all of those network effects with you as you go out and reach new users, new assets, and new protocols. So from the perspective of the user, you can envision a model where they interact the application sort of irrelevant to them which blockchain or protocol, you know, the settlement occurs on? Exactly. I think in this model, at least in kind of the near to medium term, the only

thing that the user would really need to know about with respect to kind of the underlying blockchain comes from when they need to sign a transaction, right? Their interaction, they're interacting, with that application, you know, they're interacting with a concrete instantiation of that application on a particular chain, but that doesn't limit them from accessing the utility that that application has on any other chain. So they just need to kind of select the right network in Metamask or what have you. And that's kind of the extent to which, again, this underlying infrastructure would need to be exposed to them. And for the developers, aside from the, you know, network effect benefit of having liquidity, you know, cross-blockchains, what are other reasons why I be prudent to build, you know, natively cross-chain?

That's a good question, right? So the first and foremost one is you're a developer in crypto. Now you have to ask to yourself, before you get started, really, is which chain am I going to build on? which is also saying which chain am I going to hitch my wagon to and tie my fate to. And if you think about it, why does this question matter? Because as we said before, there are massive implications to the platform that you choose. And beyond just things like uptime, availability, resource costs, you're also limited to the usorship that exists on that chain. And so you can imagine one reason why someone might

find it prudent to build in this manner is that now they increase their potential usership because it's no longer limited to that first chain they started with but also if they happen to make so to speak the wrong choice in their initial blockchain they did not doom their business and so in a way they're removing a measure of risk that was kind of extrinsic to their operation to begin with right what if you happen to build on a certain blockchain, let's say the XYZ blockchain, but turns out that no one cares about it, that a community never galvanized around it,

and there's just no one there. And so you may have built the world's most interesting product, but there's no one there to see it. And so that's a big reason we think why developers will be interested in a platform like Abacus. And if you've already had a certain app, especially if one you've deployed in a cross-chain, fashion, but again, in this instance, the apps all share the same name, same brand, but don't

share state, you might know, you might want to do it simply because you're now reinforcing a lost network effect. Like you, uh, your original reason to deploy on other chains clearly was you wanted to access more users. Now you actually get to, uh, connect them in a way that benefits each one of them, uh, where you didn't have that before. And so those are some of the things that we think will be attractive to any developer looking at advocates or something like it. So the history of cross-chain is kind of fraught, I would say. There haven't been too many. Yeah, I mean, I remember back in the days when, you know, people are excited about

atomic swaps between, you know, Bitcoin and the micro. SPV swaps and things like that. But it hasn't necessarily been a space that's covered itself in glory. historically. So curious to just get into the sort of nuts and bolts of how Abacus works, and how specifically you actually make blockchains communicate with each other. For sure. One thing before we even get really into the nitty gritty of the architecture, like this is fraught was risk, you know. Blockchains don't know anything about data from the outside world. That includes other blockchains.

And that has been one of the hardest problems. This is why earlier I likened it to the crypto equivalent of going to the moon. It's a very non-trivial task. And so when we're sitting here in 2022 and someone's like, why doesn't this stuff exist? Like why, you know, why when it does exist, it has all these issues and why doesn't exist in this and the way that they're talking about it? It's because it is incredibly, incredibly hard. you need to be able to ensure that one blockchain can know something about the outside world. In this case, it happens to be something that happened on another chain.

And you need to do that securely, but to have a strong developer product, you also need to do that in a way that is sufficiently fast and easy enough for them to work with. They can't all be rocket scientists. And so with that, you know, I'll let Aisa do the on earth. telling everyone a little bit more about how Abacus actually works. Yeah, that would be my pleasure. So the way Abacus works is that there are two contracts on every chain. There is an outbox contract that is responsible for ferrying messages from that chain

to all the other Abacus-supported chains. And there is an inbox contract that is responsible. for delivering inbound messages that are coming from the other chains to their intended recipient on this chain. Most of the magic, I guess, or most of the complexity is in how messages make it from the outbox to an inbox. And I'm going to get to that, but I'm going to first start with just talking about the kind of interface that you would interact with as a developer with these kind of inbox and outbox. contracts. So if you want to send a message to a remote chain, you call a function on the outbox contract on your chain with the data that you would like to send, so an arbitrary byte string, as well as the destination chain ID, and the address of the recipient on that remote

chain. These three values, along with the sender address of the message, and the source chain ID that the message is coming from are hashed and inserted into an incremental Merkel tree, which is stored in the Outbox Smart Contract. So that's the same data structure that the ETH2 deposit contract uses. It's an append-only Merkle tree that allows for very efficient insertions into the tree. After that data is inserted, a new Merkel route for that Merkel tree is calculated and the abacus validator set is responsible for signing the Merkel route so that the signature on the Merkel route can be verified by an inbox on a remote chain and like I said before I'll come back to exactly how the validator set works.

After the inbox has verified that a quorum of validators has signed the Merkel route, that message that was inserted into the tree in kind of step one can be proved against that route and dispatched to the intended recipient. And so as a developer, to integrate with Abacus, all you need to do is you need to define a function that will call a function on the outbox contract with, again, the data that you want to send and who you want to send it to. and then you need to define a function that will accept function calls from the inbox contract on your chain when there is a new message being sent from a remote chain to you and that's it so abacus is not a blockchain in its own right how would how would you describe it yeah that's exactly right abacus is not a blockchain it's a network between blockchains and maybe this is a good opportunity to talk about the abacus validator set and what's really going on behind the scenes.

Because again, I guess anybody can create an API and claim that it kind of can be used to ferry messages from one chain to another, but obviously how that is actually achieved is the most important part. So, Abacus implements a proof-of-stake protocol entirely in smart contracts that is deployed to every blockchain that Abacus supports.

That proof of stake protocol functions a lot like proof of stake protocols you might be familiar with from your kind of favorite proof of stake L1s. The ABC token is used to stake is used as a staking token in order to elect a validator set. And again, it's these validators that are responsible for observing the outbox contract and signing new Merkel roots as they are created when applications send new messages to the outbox. The nice thing about this is that by having the stake that is used to secure the validator set live on the same chain as the messages that are being sent, abacus is actually able to permissionlessly allow for slashing when validators behave fraudulently.

So you can kind of think of abacus and the abacus validators as an Oracle network responsible for moving Merkel roots from chain A to chain B. But unlike Oracle networks that you may be used to thinking about, that are responsible for reporting kind of fully exogenous information to a chain, like what is the temperature? in, you know, Miami today. Yeah, I'm sure it's hot. I don't want to know the answer. You know, that information, there's nothing intrinsic to any chain that can, you know,

reason about the answer it's being told, right? All it can, all the chain can do or all a smart contract can do is look at, like, who is telling me this information. The nice thing about oricalizing data that lives on a chain is that chain knows what the answer is. And so by homing the stake in the same place as the source chain, or the, sorry, by homing the stake on the same chain as the, where messages are sent, if validators try to sign a route that does not correspond to the true history of messages, the outbox contract is

able to very easily, you know, check that signature, see that it was a signature on a route that it has never seen before, and slash the validators. And so unlike kind of many other Oracle networks, you're able to offer a level of economic security and make the statement that if there is fraud, it can be detected by anybody, and anybody can present that fraud in order to punish the validators. So what are the sort of key assumptions? What do you have to believe in order to trust that the network will function the way it's intended to? In order to believe that the network will function as it's intended to,

it's helpful to think about the properties of proof of stake and what kind of economic security means for a proof of stake protocol. So in a proof of stake protocol, the economic security is the difference in size between, I guess, the stick and the carrot. So the stick in this case is, what can the protocol dole out as punishment to a Byzantine actor, so a fraudulent validator?

And the carrot is, what can that fraudulent validator, get away with if their kind of attack on the network is successful. And to have positive economic security, you want the stick to be greater than the carrot. Now, if you look at this kind of framework, if you kind of look at layer ones through the lens of this framework, I think kind of anecdotally we've seen that the stick does tend to be larger than the carrot, right? the stick is just the total value at stake, whereas the carrot is, I guess, the reward that you could

potentially get away with if you were to either fork the network or sensor or, you know, otherwise reorder transactions. I think the important thing here to note is that Byzantine validators, even a Byzantine quorum of validators, do not have full control. over the state of the network. They can only apply valid transactions that they are aware of or that they have the ability to create by signing with their own private keys.

But if I control a Byzantine quorum of validators say on Cosmos, I have no control over your atoms. Now, if you look at proof of stake being used to secure an Oracle network like Abacus, you actually, you know,

it actually looks a little bit different. You know, the stick looks the same, right? Which is, you know, there is a staking token and kind of the amount that can, you know, the size of the punishment is just relative to the size or the market cap of the staking token. But the carrot,

which is, again, what a Byzantine quorum of, validators can, I guess, steal through misbehavior looks very different because on the destination chain, there is no way to intrinsically verify what the validators are telling you. In other words, the validators have much more control over the state in an Oracle network than validators doing a layer one. Because in a layer one, you have this state. state transition function that verifies that transactions are well formed, whereas in an Oracle network, you are somewhat beholden to kind of whatever the validators are telling you.

And so this is why we believe that proof of stake for something like Abacus is a good start, but it's not actually the whole story. And so we look at kind of proof of stake as addressing economic security first and reputational security second, right? So economic security, I hope, is kind of straightforward at this point. You know, it's just, again, the difference between the stick and the carrot. Reputational security is a little bit more nuanced in that, you know, a lot of the actors that participate in these systems have something to lose more than the tokens they stake, right? They've built a business on being known as kind of trustworthy, high uptime, reliable actors.

And that's actually very valuable to them. I think a lot more than maybe a lot of people give credit to. Obviously, it's difficult to put a concrete number to. But if you look at something like Wormhole, right? Wormhole, I believe, is it 17 or 19 guardians? 19 guardians kind of, I think, carefully vetted by the folks that kind of run that network. there are no protocol level incentives for good behavior, and similarly, there are no protocol level disincentives for bad behavior.

And I think last I checked, there's around $3 billion in kind of TVL, locked up in the wormhole token bridge, and from a technical perspective, there's nothing stopping those 19 validators from colluding to kind of, I guess, rug all $3 billion in TVL. And so I would say that when you analyze that system from an economic security perspective, there's negative $3 billion of economic security. What's harder to put a number on

is the reputational security. But I think probably everybody here and most folks listening wouldn't feel that uncomfortable moving, you know, tokens over wormhole, at least from the perspective of, you know, am I worried that these 19 folks are going to collude together and rug me? Right? Probably not.

And why is that? Because collectively, the value of their kind of reputation and their brand to them kind of clearly exceeds, I guess, what they could get away with by, you know, again, trying to subvert the system. And so while you can't put a number on reputationalist, I just want to underscore that it is very valuable. All of that said, I know I've been talking for a while here, again, proof of stake is just one, and the economic security that it provides

and the reputational security that provides in having known actors participating in that proof of state protocol is just one component of the security model for abacus. As we've talked about kind of during this podcast, Abacus is very much focused on application-centric interoperability. And so I guess in keeping with that vision, we have a protocol that we call sovereign consensus that complements proof of stake that is very much in the kind of application-specific lens of security. The way sovereign consensus works is it is essentially a before hook into message processing

that applications that integrate with abacus can optionally specify arbitrary rules around what sorts of messages they want to receive and what sorts of messages they want to reject and the conditions in which they will accept and reject messages. obviously you could just build that, you know, you might think, I guess, obviously you could just build that into my application smart contract. But there is some, I guess, difference between putting these rules directly in the smart contract versus sovereign consensus, which is that abacus will both present you with the metadata around, I guess, how was this message moved from chain A to chain B, right? who signed it, what roots, or rather, what root is it being proved against? And it will allow whoever is proving that message against the root to include arbitrary data that the application's sovereign consensus module can consume. And this allows for kind of a really, I guess, flexible, sorry, this allows for a

applications to specify kind of really flexible rules around kind of what messages they want to accept or reject. So for example, one thing you could build, and we will provide a reference implementation for, as well as a reference deployment for, is this concept of sovereign guardians where in addition to a quorum of validators, advocates validators, being required to sign off on a route before messages, can be proved against it. You also require some entities, presumably incentive aligned entities, nominated by the governance system of your application, be it a Dow, a multi-sig, some guy with a ledger.

You require that those parties also sign off on that route. And that does two things. First, it brings quite a bit of reputational security from the application into the advocacy system because now if there's going to be a safety failure that affects that application, not only would the abacus validator set need to be compromised, but you would also need the guardians that that application is running to be compromised as well. And I think, you know, again, kind of coming back to reputational security, I think a lot of us would feel, coming back to reputational security, I think most folks would expect that the application that they're interacting with it is not trying to rug them. Secondly, it isolates failures.

So, you know, God forbid there is some kind of quorum-sized compromise of the abacus validator set. so long as those sovereign guardians aren't compromised as well, all the applications that integrate with Abacus will remain safe. I think the last thing to note here is that this is actually not much of a change from the existing trust assumptions you make when you interact with an application. If I go and I use uniswap, for example. You know, realistically, like, maybe I've read the smart contracts, maybe I've checked that they're verified. But even if they're verified, even if I'm checking that they're verified, I'm trusting that the Block Explorer attesting to their verification is telling me the truth. Maybe I compile them myself and compare the bytecode on chain.

Even if I do all of that, as soon as I start to use the UI, I am trusting that the folks, that implemented the UI, in other words, the kind of stewards of the application, have implemented the UI in a way that is signing a transaction that I'm actually intending to make. So no matter how you, like which way you kind of slice it, at some point you're placing, when you use a decentralized application, at some point you're placing a good amount of trust

in the application itself. And I think this kind of this concept of sovereign consensus and specifically in sovereign guardians really leans into that. You know, we talk about this a lot, but it, to continue like what I was saying, it takes what is an implicit ask for you to trust the app. You know, if like it's it's not even just the UI, right? If the contracts are upgradable, you're trusting that they're not going to flip the rules on you after you started engaging.

And they make it we, you know, sovereign consensus can make that ask explicit. You could say, basically tell your users as the app developer, hey, this time around because we run the sovereign consensus on our own app, if you're getting rugged here, we're in on it. Of course, we're not going to do that because that basically makes us a criminal enterprise. And so now you get that added measure of confidence, where if you really think, especially in financial applications, they're all built on trust.

almost every fintech out there, its brand, all of its defensibility is built on trust. And so we think for a lot of developers, this idea of making the trust ask explicit if they want to is going to be a huge point of appeal. So in terms of the other, you know, this new generation of cross-chain focused application first interoperability protocols, how do you distinguish yourselves from these other? number of ways that we do that and you know we could get into the technical differences but beyond the technical differences which are certainly meaningful and we believe will be valued by developers for us you know with abacus the key things we're focused on are both the simplicity

and the speed uh of the system and the simplicity will touch on just what is it like to integrate it Is it limited to folks who are on the far right edge of the talent distribution, or can it be accessed by some moron like myself? And the goal is certainly to make it much more accessible to think of it like a developer of any talent level. So it's not just that, as we call them in crypto, the gigabrains are the only ones who can leverage it. And then again, when you think of speed, speed to us means two things. speed is not just the how fast can these messages be transmitted securely which is very very important but it's also the speed from you going from barely knowing about what abacus is to being able to

launch your abacus app and we're hell-bent on making abacus a very short we have an internal metric like the time to success right we're very adamant about that being no longer than the time frame of a weekend. Abakus should be something that you can very quickly go from zero to a hundred on. And of course, then there are the technical differences, which depending on whatever you're comping it to, whether it's Axelar, whether it's layer zero, whether it's Nomad, those are going to be different each time. But so I guess in architecture, we're probably the most similar to nomad. So maybe we start with them. Key difference is that in our security model, which they use an optimistic system,

which can be incredible for a number of things. And we just don't believe that it's the best way to achieve this shared state. That was what the experience we desire to give our developers. Isam I missing anything in so far as the... There is kind of, I guess, a nuance. in the efficiency in which roots or you know talk a lot about

roots but what really when I'm saying roots in the end you know the effect of what I'm saying is messages there's a nuance in how kind of messages are transmitted from one chain to another that allows abacus to I guess move messages

more efficiently than than in Nomad in Nomad I believe kind of with the update model every update this may go over the head of anybody who's not kind of familiar with how it works but basically

I guess every time you want to move messages from say chain A to chain B you're also creating an operation that needs to be done on saying chain C that's in the nomad model whereas in Abacus if you want to move messages

from chain A to chain B you only need to do operations on chain A and chain B. And then maybe worth getting into layer zero and XLR. Yeah. Yeah, let's cover those two, especially layer zero. It's the one that people are very excited about these days. Yeah, yeah, and for a good reason, right? I think kind of all the excitement around layer zero really speaks to the

the excitement around kind of app-centric interoperability. And so we, you know, we're very encouraged to see, I guess, all of the buzz that they're launch and their product has created. When you think about kind of, I guess, abacus as it relates to layer zero, I mean, I think high level, the biggest difference is in security model. There are more kind of nuanced technical differences

in exactly kind of what is being communicated. I think layer zero is focused on moving block headers, whereas abacus is focused on focus on moving these Merkel routes, which are kind of internal to smart contracts. And that results in kind of, I guess, different trade-offs in terms of how quickly these protocols can be expanded to other chains, the cost of proving state kind of against either in Abacus, the outbox Merkel route in layer zero, the kind of block header, state Merkel route. But I think again the biggest difference is in security model. As I

described before, Abacus is a, uses a proof of stake security model, which allows or basically ensures that if validators misbehave and act fraudulently, they are certain to be slashed. because again, the stake lives in the same place as the knowledge of the source of truth. Layer zero, as I understand it, really provides a framework for security, which is, I believe they have two roles, the Oracle and the Relayer. The Oracle is a permissioned entity that signs blockheaders, and the relayer is a permissioned entity that proves state against the relayer. the Merkel root in that block header.

And I think they make the argument that so long as these entities don't collude, you can never wind up, you know, I guess relaying state to a destination that wasn't actually valid on the source chain. But, you know, of course, the onus is on the developer to integrating layer zero, to decide, you know, who is going to be my oracle?

Who is going to be my relayer? And we think that, well, okay, that's a really important question, right? Because as we've kind of talked about in the beginning of the podcast, cross-chain communication is fraught with, I guess, examples of things going horrendously wrong, right? and the Oracle and the relayer together have the power to make things go very smoothly or as wrong as you can possibly imagine. And so I think the big difference there is that Abacus kind of gives you a decentralized network of validators that will help you move messages from A to B out of the box. If you want to layer on sovereign consensus on top of that, obviously that is kind of up to the application.

It can provide an additional layer of security that we think will be appreciated by more mature applications, but maybe not interesting to applications that are just getting started that maybe don't need anything more than the economic security of what the abacus validators that can provide. In either case, I think again, the main difference is that we see layer zero somewhat as a framework for how to do cross-chain communication. Whereas we see Abacus as, I guess, a kind of prescriptive, a little bit more prescriptive in what the security model that you're signing up for looks like. And we see that as a good thing, not a bad thing, because cross-chairs. chain security is really the heart and soul of this entire space. That's like the most important problem I think that you could possibly be solving when you're building a cross chain communication protocol.

Yeah. As As I said, right, this is that really the hardest thing about this because these chains don't know anything about the outside world and they take whatever the Oracle is going to give them. They take that as given. We talk a lot about interoperability, but at its core, it's a lot. It's just a different manifestation of the Oracle problem, which a lot of people are much more familiar with, but tend to not think of in this context. And really, the protocol that enables Abacus, what Axelar is trying to do with their network, these are all attempts to solve the Oracle problem for this specific use case.

So you can think of with Abacus having two parts, right, the developer-facing part, which is all the tooling we're building, the example apps, and then you could think of another part being the protocol, right, the stuff that makes the magic happen. That is just a narrowly scoped Oracle network that is solely built for this purpose of relaying messages between chains. And we really think it's important. And if you think of like, what are we trying to do?

We're trying to create a network that delivers a very nice experience to a developer. And this experience is about delivering share shared state between the different manifestations of their app. And if we were to not, if the network didn't own this part, we wouldn't be able to define a key set of parameters. Your latency, the security, all these things are going to basically be defined by this plugin. And in our case, the plugin is part of the network.

And in this other case, it doesn't have to be. And so we think that's a key difference, one that really matters to us, because we don't want our developers to think about anything more than their app. They're good at doing what they're doing. They don't need to be good at understanding how to communicate between two chains. And so that goes back to that core principle of keeping it simple. And we think this allows us to keep the system very simple for them. And very pragmatically, which blockchains will Abacus support?

Or which ones won't it support? I guess maybe that's a simpler question. Oh, good question. So there's, well, many more that it won't support than will support, unfortunately. But that's just a function of just how many chains there are these days. To start, we are going to have support for the more popular EVM chains. So by the time this pot will be released, we'll probably already be live on most EVM test nets. That includes the Afro-Lanch C-chain, that includes a polygon.

It also includes arbitrarum and optimism. Probably will include Aurora, about a list of about eight of them. And we've started that deployment a number of days ago. And so, again, I expect that by the time the audience gets this, it'll already be live. and we'll have those same EVM maintenance up by, let's call it conservatively early July. And so those are what we're going to start with. Now, we think of the universe in forms of different virtual machines, right? Like, where does activity happen by VM?

So clearly, the EVM is leading the pack right now. So from a pragmatic perspective, it just makes sense to focus on the EVM. What's runner up? well, it seems like the Cosmos Universe. Of course, we include Terra and that. That's a pretty clear second, and they have Solana right on their heels. Now, what seems to be happening is that as others recognize the inertia and strength of the EVM, and look, we all know it's not perfect.

We all know it's probably not the best from a technological perspective, but to the extent that there are network effects, in some of these things. It's pretty clear the EVM has a pretty strong one. And what we're seeing is a motion by most layer ones, especially ones that are not EVM native. To add, we sometimes think of them as docking stations or like these ports with EVM support.

So you're seeing what Neon Labs is doing on Solana, Evmos on Cosmos, Aurora on Near, moonbeam on Pocod and in the substrate world. So if those all happen and they're stable, then great. We don't have to do much. And that allows us to keep up this consistent, simple developer experience because we'll put our mailboxes, right? If you remember from the architecture, Abacus just needs to deploy its mailboxes

on each chain it wants to support. And you can imagine mailboxes on whatever neon ends up building, mailboxes on Evmost, mailboxes on Aurora, mailboxes on Moonbeam, and every other EVM port city that we get to. see that's in the amazing case if that happens you should see us live on all of those no more than a few months after we're live on that first set of maintenance so what are the prospects for getting yield Bitcoin or would that have to be through through sort of a wrap Bitcoin that is so the rap Bitcoin part that'll certainly be enabled very easily because you know once

Once we exist anywhere where WBTC or any form of rap, Bitcoin already exists, no problem. But getting what you'd consider native support, that might be we're going to need some way for the mailboxes to be deployed on Bitcoin, which won't be a trivial task. Right. Yeah. In the absence of kind of curing complete scripting language on Bitcoin, that would require. require architectural changes. Yeah, we're comfortable with this because again, we're focused on application-centric interoperability.

And so from that perspective, the thing that's most important to connect are platforms for building applications. In terms of BTC the asset and moving that from place to place, there are already a number of purpose-built Bitcoin bridges. And we think they're great. Well, that's a very broad statement. Some of them are great.

I think it's great that there is so much effort and investment into developing kind of Bitcoin-specific bridging technology. And for the most part, that's not a game that we're interested in getting involved with ourselves. Yeah. So what you could see, Nick, is down the line maybe deploying mail-border. boxes on RSK, maybe deploying mailboxes on on stacks, right? As soon as it seems like there's actual demand for them, we're going to be there, right? But hopefully it's become evident by now that we operate with a big sense of pragmatism and we just want to serve like we are not focused on our user's user beyond what our developers will want.

So it's first and foremost a developer product. And if they tell us, hey, we need you on RSC. We need you on stacks. We'll make every effort to be there. Maybe the listeners are feeling inspired right now. Where do you direct them? What's their next task after listening to this episode? So next task is definitely go to our docs, get smart about Abacus.

Then you should go to the repo. And then you should like test out with some of the example apps, whether it's, you know, if you want to do something real simple, try, maybe try ping pong, or if you're slightly more ambitious, it's just as simple. But you can try and create a natively multi-chain token. So give it a go. And then, yeah, come to our Discord and let us know what are your questions. But that's what you'll be able to do.

And you'll be able to actually, like, touch this thing and experimented and send messages across you'll be able to create a I mean you on test net you'll be able to make an app that shares state between these you know seven or eight chains we think that's pretty cool like you know at its core abacus about doing stuff you couldn't and you're going to be able to do stuff you couldn't do before if you do this very concretely our website is use abacus dot network and you can find the doc a link to the documentation there or you can go to dox.usabacus.network and and and And both of those will have links to our GitHub and to our Discord. It's funny, we've actually done, you know, we're in talks with a number of projects,

but we've actually done very little in the way of, I guess, anything that might be considered publicity. So not only is this, you know, my first podcast personally, but this is actually the first outreach beyond kind of anything one-to-one within our personal networks that we've done. Yeah, this is the abacus coming out, Bernie. All not to say, SEO might not be there yet. So you may have to plug in the URL. Oh, that's okay.

We'll put the links in the show notes. Well, it's an honor. Honor to host you too. Thank you for joining us today. So, John. Appreciate it. Thank you so much. Thanks for having us.

Thanks, fellas.