Hyperlane 🛠 Permissionless Interoperability

I'm going to talk about Hyperlane today . I am York. I am member of the founding team of Hyperlane. Hyperlane is an interoperability protocol. We are building a system called permissionless interoperability .

The main purpose of this is to connect your chain without having to enter into agreements with Hyperlane in a service- service- oriented manner . This is possible through any interoperability protocol that does not compromise on security . You can implement our protocol yourself and decide your own security preferences . We have put a lot of effort into modularizing our protocol , making it extensible to new VMs and new chain architectures extensible to new VMs and new chain architectures . Let me explain the motivation behind this.

First, let me start with some definitions . That is. Many people talk about permissionless talk about permissionless , but in my view, permissionless means that a protocol is available to everyone . There will be no censorship there . Neither those within the protocol nor any operator is likely to discriminate against any developer, any individual, or any user.

By interoperability , I mean composability between apps on different infrastructure layers . This word is also used in many places. That is . This can have many meanings in software interoperability , but in the context of blockchain, this is what it means in my view . So why should we care about permissionless interoperability ?

If you look at how this ecosystem has been developing over the past decade . You will understand that as DApp developers we are using a more diverse infrastructure. We started with payment applications . It was in Bitcoin. It had a very simple blockchain architecture.

Then came Ethereum, which generalized any computation that could be executed by a VM on a block . The likes of Near and Solana also quickly followed suit . Some other smart contract chains also fall into this category. Then many people wanted to take it further. They wanted to create a generalized chain SDK or framework that not only provides an Ethereum-like developer experience, but also makes optimizations at the consensus layer or monetary policy layer level, giving the application more autonomy.

That's why things like Cosmos and Polkadot came about, where application developers wanted the flexibility to make changes as they pleased, so that they would n't have to rely on the EIPs of Ethereum validators. Over the past few years, at least the Ethereum ecosystem has been making very rapid strides towards this rollup- rollup- centric roadmap . Vitalik talked a lot about this . This approach has many scaling benefits , and many teams here are working towards this goal . The Optimism team, in particular, tried to create an experience like the Cosmos SDK to enable its own rollup .

Same OP stock. More and more teams are recognizing the importance of this and are transforming their applications to take advantage of rollups , especially without having to set aside a separate security budget. You can get it from L1. Many people are also thinking about plasma and sharding are also thinking about plasma and sharding . Depending on who you're talking to , you might include different chains in this category, but this poses a problem .

The problem is, we need to quickly highlight the applications that are adopting these new architectures or DApps , right? We have Zora; They recently launched L2 . Coinbase has launched, and everyone is very excited about Coinbase L2 . Over time, applications and users are also changing, and more activity is happening in these new infrastructure layers than in L1 . This is not just a theoretical matter that researchers talk about.

This is actually happening right now. People are migrating . The problem that arises from this is that fragmentation is occurring; If you look at networks other than Ethereum L1, there are Arbitrum One, OP Mainnet, Polygon, etc. Avalanche, each has different interfaces for interoperability. This means that, as an application developer, you need to re-integrate each network in order to be composable across all networks .

When the market growth rate is not as expected, it is important to reach all users in the ecosystem. Many users have their own opinions on which network to keep their funds on or which smaller networks the wallets they use support. So even if you want to adopt new infrastructure layers , you have to go where the users are . This is a major issue with interoperability, especially as new roll-ups emerge in the Ethereum ecosystem . In fact, these three actions I described above have different interfaces .

I think it would be very difficult to find a developer at this hackathon or anywhere in the world who knows how all these interfaces work . No one really knows what security guarantees these have, what their semantics and capabilities are. What happens if your message fails between chains, failure modes, payments, etc. are all very complex. The complex matrix of different networks you need to understand is constantly growing .

So at Hyperlane we are thinking hard about this problem . We are trying to bring the right abstraction so that DApp developers don't have to think about these things . Arbitrum has its own bridge interface , as do ZKSync, Ronin, and Polygon, which all have different ones . They all have their own interfaces. Actually, you need a consistent application interface, right?

I think it would be nice to have a simple function that we could all use think it would be nice to have a simple function that we could all use . But the problem is, how to preserve the security guarantees of these underlying bridges, while still having a stable interface? This is what the Hyperlane protocol does. So Hyperlane is implementing this approach to interoperability. We are embracing modularity and separating the transport layer and application layer .

So at the application layer, you can have a very simple consistent interface . It's basically an onchain smart contract API that allows you to send arbitrary bytes to a destination chain, the recipient address there . It is available from and to every chain where our smart contracts are implemented . This is not limited to just Ethereum. We have recently expanded to several other VMs as well.

We We are in the Solana VM. We are going to release the Cosm WASM implementation soon . We encourage many people to implement this protocol in their own VMs . Move is coming soon. We want this interface to be everywhere .

So, developers will have a kind of consistent experience . And inside, our protocol chooses the most efficient transport layer. Additionally, it allows the recipient of the message to decide the security preferences they want . Many people talk about the 7- day withdrawal window from roll-ups and how inconvenient it is for users . Sorry for my language .

Um, and yes, I think a lot of users have started to opt out of that 7-day withdrawal period and instead go through other means . Maybe it theoretically has good censorship guarantees . They use things like Stargate, Hop, Across, and Connect . These have different security challenges . So, users are already making such choices regardless of applications .

Applications should support the ways users want them . And, ideally, applications should be designed in such a way that, in order to use my application , you have to go through all this trouble , go through the Canonical Bridge, make these strange API calls , and this approach should be encouraged encouraged . So yes . So yes , basically the recipient of the message in the hyperlink can specify their own security. We call these interchain security modules .

We have a few ready-made options , some of which include native bridges to the rollups I mentioned earlier. So we have this for all the major rollup transport layers. Um, but what's special about this is that when someone is sending from Ethereum to Optimism , we want to allow them to use the Optimism bridge security . But when sending from Optimism to Orbitum, users can choose alternative routes, rather than forcing them to send via L1 and face a 7-day delay. Of course, there are liquidity solutions, but these involve some security challenges that developers are not aware of .

Yes, this is the main purpose of our protocol. Yes, in short , the security preferences that an application developer can express actually depend on the content of the message . What I'm personally excited about is the use of this L2 to L2 interop, without forcing users to go through L1, as a way to be faster, cheaper, and not have to bother with the L1 settlement period. So, we have a lot of great designs that leverage financial security instead of going through a fraud-proof system . As long as there is a stake pool at risk in L1, it is basically like providing advance MPs.

All rollups participating in this system can achieve fast, cheap interop, within our financial security. And, people ask what happens when you go beyond that financial security . The purpose of this interface is so that application developers can say, "Okay say, "Okay , if there's more than this financial value associated with my message , I know that when this message hits my protocol , it's worth 10 million dollars ." That is a very scary thing. I can't blindly trust some validator that gives a fast pre-MP attestation on it .

I want to force it to go the slower, safer route . This is similar to traditional financial wire limits . You can express it as a function of the message content can express it as a function of the message content . So, if a message exceeds this value, a manual review process or veto can be performed, or optimistic security modes can be selected and used used . Mm.

And another thing I want to highlight is that we actually want people here to expand our protocol . We don't want to be the only ones operating this . The protocol itself is implemented in smart contracts. There are some off-chain actors out there who are completely permissionless permissionless . This is all configurable, and we've been working for the past year to make this experience available to developers .

So, whether you're launching your own rollup this weekend , or experimenting with some new chain architecture or VM (maybe even a move), you can deploy our protocol on those new chains without talking to us or going through any sales cycle with our organization , as well as reap the benefits of all the other networks already connected to our protocol . So there's a nice network effect here, whereby you now only need to do one Hyperlane integration . As I mentioned earlier mentioned earlier , every application developer does n't need to make more than ten integrations. So it's entirely about the developer experience. I would like to briefly talk about some of the applications we have built on top of this primitive talk about some of the applications we have built on top of this primitive .

To put it simply, token bridging is where people exchange tokens back and forth . Um, we have a template application and UI, which is a complete solution. This is useful for everything from interacting with our contracts across multiple VMs . It already supports Solana, and there is a template repository that you can fork from . This UI and multi-VM wallet experience can be connected to any chain of your choice and token can be launched launched .

There are a few types of token bridge options for you to choose from . If you already have some tokens, you can use the classic lock and unlock bridge . If you want to create a new token , you can use a native mint and burn method like Circle's CCTP protocol . You can bridge a chain's native asset into the Ethereum network as a token. We did the same thing recently.

We helped launch the first SVM rollup. SVM Rollup's native asset is represented as ERC20 on Ethereum , with the same onboarding mechanism and they use Hyperlane internally . If you want to see it, its name is the Nautilus Chain. Um, we also have some other nice primitives for the developers here . I only have two minutes left, so I'll wrap up quickly .

You can have interchain accounts and interchain queries . The basic idea is that you can have a smart contract that holds assets on another chain , which is called an interchain account. That smart contract has a proxy located on another chain . We designed it as a simple smart contract API. Similarly for queries, if you want to call a view over a remote network, we have a simple API for that.

And I repeat , all this is to solve this fragmentation problem . We want to simplify the developer experience across these disparate infrastructure layers . We hope you will try these APIs . That's it, almost. I don't know if you're asking questions , probably not.

But I'd be happy to talk to you later and discuss weekend projects. Yes. Shall we take a question ? Sorry. Corsica.

Cortege. I don't know exactly. I do n't think so. That...which VM is that?

So, that's what it says . That's okay. We do n't have that right now, but... Generally speaking, anything that compiles to that instruction set , we have a Cosmos implementation, something like Rust, so we can build a compilation tool chain and deploy Cosmos contracts to that VM . Good.

Thank you very much.