Join Delphi Research today and immediately get access to our full Member Portal!
Join Delphi Research today and immediately get access to our full Member Portal!
Back

Hop Protocol: A Trustless Protocol to Quickly Transfer Tokens From One Rollup / Sidechain to Another

Sep 22, 2021 · 54 min media

By Can Gurel

Guest host Can Gurel from Delphi Research sits down with Chris Whinfrey, co-founder of Hop Protocol, a prominent token bridge for Ethereum’s layer-2 ecosystem that allows users to quickly send tokens from one rollup or sidechain to another. The two discuss the utility of Hop Bridge in a rollup centric Ethereum world, diving into its design properties, security model and much more!

Resources:

More

 Music Attribution:

  • Cosmos by From The Dust | https://soundcloud.com/ftdmusic
  • Music promoted by https://www.free-stock-music.com
  • Creative Commons Attribution 3.0 Unported License
  • https://creativecommons.org/licenses/by/3.0/deed.en_US 

Show Notes:

(00:00:00) – Introduction.

(00:00:40) – Chris’ background / Why he started Hop Protocol. 

(00:05:15) – How optimism and ZK rollups work. 

(00:12:28) – How Hop Protocol works.

(00:18:28) – How hTokens are converted into aTokens.  

(00:21:03) – Why an intermediate token is needed. 

(00:25:02) – Hop Protocol from a capital efficiency perspective.   

(00:28:46) – How Hop Protocol defends against fraudulent transactions. 

(00:30:54) – Users’ exposure to the weak links in scaling solution security. 

(00:35:33) – Chris’ thoughts on concerns about rollups. 

(00:39:26) – Hop Protocol’s role if rollups become efficient.

(00:40:53) – Challenges with cross-chain messaging.

(00:47:48) – Other layer-1s versus layer-2 solutions.

(00:51:53) – Hop Protocol token.

Interview Transcript:

Can Gurel (00:05):

Hello, everyone, this is Can from Delphi research together with me today I have Chris from Hop Protocol. Hop is a generic token bridge across different scaling solutions revolving around Ethereum. And it’s a very exciting project and I can’t get to dive into it. But yeah, actually, it’s a pleasure to have you here with me today, Chris. Welcome.

Chris Whinfrey (00:36):

Thanks for having me on today Can.

Can Gurel (00:40):

So before we dive in, actually, I know Hop is not the first project you been working on. And you’ve been in the space since many years now. So can you talk a little bit about what you’ve been doing? What it made you to arrive to Hop Protocol today?

Chris Whinfrey (00:58):

Sure. So I think I first got introduced to crypto around 2014. But it wasn’t until kind of late 2016, 2017, that I started to work full time. So I was living in Boston, doing iOS development. And there wasn’t a lot of opportunities to work in crypto. And so I was working for an agency and I ended up quitting the agency. And I started the Boston Ethereum developer meetup to kind of meet other people that were into Ethereum at the time. And then, with a few friends started dev shop called Level K. And we were building smart contracts for people that were looking for that as a service and using that to kind of bootstrap ourselves and start building projects. And so with Level K, we ended up starting in auditing practice, and that was something that I led up within the company. And we worked with a lot of great projects, like we audited the OpenZeppelin framework, dYdX, Trust Token, Decentraland and a handful of others. And so that was kind of my first full time job within the crypto space.

Chris Whinfrey (02:16):

And so I met my current co founders, Shane and Miguel when I moved out to Los Angeles, maybe three, three and a half years ago. So we were all working together at Level K. And then we ended up spinning the auditing business out to go after this new opportunity that we’re really excited about. And that opportunity was contract based accounts. And so we launched Authereum which is a contract based account wallet built for casual users. And so the idea behind Authereum was you could just kind of sign up with the username and password. And just made the onboarding process and starting to use Ethereum applications really easy for first time users. And then pretty quickly DeFi took off and so did the gas market along with it. And when it costs us maybe 15 cents to deploy this contract base account for new users when we started it we quickly push that cost over to the user. And at one point, it would cost you over $250, just to deploy this contract based account.

Chris Whinfrey (03:21):

I think it would cost even more than that some days today. So we really saw layer two as kind of the only future for Authereum. And for casual users in general, like Ethereum itself was just too expensive, the cost of deploying Authereum account was roughly two uniswap [inaudible 00:03:40]. So even if you could get the account deployed, there wasn’t much you could do unless you’re dealing with large amounts of money, and you could justify that cost. So we had our backs against the wall, and we’re looking for ways that we could allow users to move directly from one layer to the next, so that they didn’t have to come back to layer one. So with Authereum we started integrating with our two solutions, such as, like, diversify, looping, and we saw that users would bridge over to the solution, they make a few transactions, and then they bridge back, but the cost just to get onto and off of layer two, was more than they were saving, if they just used the layer one applications directly. And so we knew that users kind of had to be layer two native and that they had to be able to get on to layer two and then stay on layer two.

Chris Whinfrey (04:35):

And so we came up with Hop Protocol, we put out a paper about it earlier this year. And just to get some feedback and along with a demo for how it could work and the response is really overwhelmingly positive. So we decided to focus on this completely and realized that this could be true with Ethereum core infrastructure and could be bigger opportunity than what we were looking at with Authereum. So that’s kind of how we got started on Hop and and to where we are today.

Can Gurel (05:12):

Yeah, I appreciate that information. So the future of Ethereum is, as stated by Vitalik is a roll up centric one. I mean, he laid out this vision years back, and only now we’re seeing a glimpse of it with the launch of Optimism, Arbitrum, there are also ZK roll ups, like [inaudible 00:05:39] and ZK [inaudible 00:05:40]. So I noticed that many people are still not very familiar with how roll ups work in general. And given that you’re very accustomed to them, could you maybe explain how’s a roll up working in general sense? And what is it that makes them so special?

Chris Whinfrey (06:04):

Sure. So yeah, with Ethereum scaling, we’ve always heard that scaling is right around the corner for years and years years now. And it feels like roll ups are kind of the first one that really addresses everything that we’ve dreamed up with layer 2, where it feels like layer 1, we can deploy applications, we can deploy smart contracts. And so a roll up is kind of this partial scaling solution. And so what I mean is that it scales in terms of execution. A scaling solution has execution, and then data availability. And so those are the two pieces, are the two main costs of using Ethereum. And so any scaling solution needs to scale both of those, or in the case of a roll up, it’s a partial scaling solution, because it just scales execution and not data availability. But this trade off allows us to basically use layer 1 Ethereum, to as this data availability layer, and allows us to kind of order all of our transactions. So what I mean by that is each roll up has what’s known as a state route. And Ethereum itself has a state route. And this basically represents all of the state on the solution or on Ethereum.

Chris Whinfrey (07:21):

And so a roll up state route is routed into a smart contract on Ethereum. And as the roll up progresses, we basically say here are the transactions, these are kind of updates to state, and we’ll get from the current state route to some new state route. And then have some validation around whether or not these updates or these transactions that went from state route A to state route B it is a valid transition. And the way that those updates are validated that that’s kind of where the difference between an optimistic roll up and ZK a roll up start to diverge. And so when users are making transactions, they basically submit them to the roll up, and then those will actually get posted on chain. So all the transactions that you’re making on, say, Optimism or Arbitrum, they’re actually going and being posted on layer 1 Ethereum. And that’s why you’ll see that that roll ups have this kind of non negligible cost, like you might see with these non roll up scaling solutions like polygon and [inaudible 00:08:37].

Chris Whinfrey (08:38):

And so once these transactions get posted onto Ethereum, they’re not executed, it’s just hosted for data availability. But it does kind of lock in the order. So if anyone’s kind of looking at these transactions, they can say, “Okay, here’s the last update that we have on Ethereum. And then here is the data of all these transactions. But no one’s actually run the execution of these transactions on chain.” But if I’m an off chain participant, I can look at the ordering of these transactions, and I can look at the state route that we had last and I can actually figure out the current state of the chain by just executing them myself off chain. And that’s where you get the scalability, where the execution has been pushed off chain for the most part. And so then the harder part is getting to that next update. And so with an Optimistic roll up, someone will just post the update. And then it’s actually a week before that’s finalized. And that week long period basically gives people enough time to challenge that these transactions that were posted between this state route and this state route actually were all valid state transitions. And if there’s a challenge the challenge can play out and then the state can be updated within that week.

Chris Whinfrey (10:00):

And then a ZK roll up uses some really cool cryptography to basically prove that all of these transactions that were posted led from state route A to state route B and then it could just be proved on the spot, it’s final on the spot. And there’s no challenge game, there’s no week long wait period. And that’s why you’ll see the exit times on ZK roll ups are way faster than than they are on Optimistic roll ups.

Can Gurel (10:31):

Yeah, thank you for that, really good. Really good intro. So with that actually, you touched on the point between the ZK and Optimistic roll ups. And especially with regards to the Optimistic roll ups, I also find that a lot of people miss confuse the seven day challenge period, seven day withdrawal period, actually. So just want to clarify that when Optimism writes the posts, Optimism is called sequencer, there’s an entity that posts transactions to layer 1. But when they post that in order actually, and a full verifier node would actually be able to as soon as it’s minted on on layer 1, a full verifier L2 node would execute them, and you would know 100% the state of the optimistic roll up. So there will be no risk for them. The seven day withdrawal period is for users who not necessarily have the resources to compute these themselves. So I think that’s the fundamental piece that most people miss. And this also is also a crucial part of how Hop Protocol functions, right?

Chris Whinfrey (11:57):

Yeah, that’s exactly right. We think of it as kind of on chain finality and off chain finality. If you’re an off chain participant, you can pretty easily compute these updates and get to finality pretty much after that batch has been submitted or your transaction has been submitted. And then if you’re on chain the execution can’t play out on chain, otherwise, we wouldn’t be scaling. And therefore, you have to wait for this week long challenge period.

Can Gurel (12:28):

Got it. So with that let’s walk through how Hop Protocol comes into play here. So I’m a user on roll up A and I want to transfer my tokens to roll up B, let’s say up from Optimism to Arbitrum. So what is it that Hop Protocol helps me to do and what guarantees do I get as a user, what security guarantees I have?

Chris Whinfrey (12:58):

Sure. Yeah, so Hop basically allows you to transfer tokens directly from one roll up to the next or one scaling solution to the next. And this happens almost immediately, we basically wait for the source chain to reach off chain finality. So that takes roughly five minutes for the most part. And then your transfer is completed. And Hop doesn’t introduce any[inaudible 00:13:26] trust assumptions. There’s obviously smart contract risks with any kind of DeFi application that you’re using. But it doesn’t introduce, like a new validator set, it doesn’t introduce a new consensus algorithm, it’s actually just using and leveraging the scaling solutions themselves. The message bridges between the scaling solutions and Ethereum. And it does the rest completely [inaudible 00:13:53]. So to get an idea of how Hop works, I think it’s important to understand how the [inaudible 00:14:02] bridges for roll ups themselves work. And so, each roll up will have a cross domain messenger and so that this basically allows contracts on the roll up to talk to contracts on layer 1 Ethereum and then layer 1 Ethereum to talk to contracts on the roll up.

Chris Whinfrey (14:22):

And so the communication from Ethereum to the roll up, that happens almost immediately. It happens in the time it takes for layer 1 to reach finality. So also five to 10 minutes and then communication from layer 2 to layer 1 that is only as fast as the exit time of the roll up. So if we’re talking about an Optimistic roll up, then messages from the roll up to layer 1 Ethereum are going to take that full week before they can be executed. And so the reason that all roll ups have this messaging bridge is because it’s needed for the native bridge. And the idea with roll ups is you don’t want to just have this siloed environment where you have tokens on that roll up, you want to actually use the tokens that are on Ethereum on that roll up. And so in order to make this native token bridge for the roll up, the roll ups will have this lockbox on layer 1 Ethereum, users deposit tokens into it. And then they’re minted a representation of that token on layer 2. And that native token bridge is all built around their cross domain messenger which allows the messages to be shared.

Chris Whinfrey (15:33):

And so that’s why the exit time is also a week, because the user actually will decide to exit, they’ll burn their token on layer 2, that will trigger a message from layer 2 to Ethereum. And the exit won’t be able to be executed for a full week. So that’s kind of the the native cross domain messenger and the native bridge for each roll up. And so what Hop essentially is at the core is this cross roll up messaging protocol. And so the core of the problem is actually the messaging itself and then on top of that, we’ve built token transfers. And so you could imagine the naive way to if we’re trying to talk, say, from Arbitrum to Optimism, then naive way to send a message would be to propagate your message down to layer 1 Ethereum, and then backup to the destination. And so that’s not very scalable, because for each individual message, we’re going to need to transaction on layer 1 Ethereum. And then we had this big bottleneck because we can’t scalably send messages between Optimism and Arbitrum. And so we came up with Hop is we actually aggregate many messages at the source. So we won’t actually trigger them to be sent, we’ll just store them in state on the wallet itself. And then at some point, we will move the whole batch of aggregated messages from the source to the destination.

Chris Whinfrey (17:11):

So we compressed this whole batch of transactions into what’s known as a Merkel route. And then so we just had the single hash, and then we can propagate the single hash that could represent 1000s of messages down to layer 1 Ethereum to the destination, and then at the destination, it can be unpacked. And that alleviates this layer 1 bottleneck for cross roll up communication. And so just like the roll ups on top of their cross domain messengers, the first thing they built, this is their native bridge, on top of our cross scaling solution, messaging protocol, the first thing that we built on top of that is cross scaling solution token transfers. And so the way that the token transfers work is we introduce our own asset. And so this asset we call an H token. And so just like with the native bridge, you deposit into a lockbox and you get some representation of that token on layer 2. For the native bridge, we call it the canonical token, those are the ones that users actually want, like USCC [inaudible 00:18:20] etc. And then for Hop, you deposit, and then you get H token like, HUSDC, HE, etc.

Can Gurel (18:28):

All right. So, just to expand on that point, you mentioned about the message contracts. So correct me if I’m wrong, but any application I mean, once it’s fully deployed, in open [inaudible 00:18:45] at these roll ups are not white listed, etc, any application can actually interact with that messenger and then create a representation of L1 token inside the roll up. So you would for instance, see a bunch of [inaudible 00:19:02] there, right? Different versions of that, but eventually there’s a native roll up bridge and that’s the one that you’re referring to as canonical token. So there will be forces in the case of say… Arbitrum there, we can call it maybe A di an Arbitrum [inaudible 00:19:22] and that will be the canonical one. But the Hop bridge would be a different token, right? Would be like H di so. And you mentioned that eventually users want to get Arbitrum . So how does this work after that point, so we [crosstalk 00:19:45].

Chris Whinfrey (19:46):

Yeah, that’s exactly right. And so users ultimately want this [inaudible 00:19:52] or canonical di. And we introduced this H because we need to kind of program in this special bridging functionality directly into the asset. So when a user kind of transfers an H token from one roll up to the next, the H token is burned at the source. And then we have this liquidity provider role that mints it at the destination. But ultimately users don’t want H di they don’t really care about H they want real [inaudible 00:20:21] the A di. So we have stable swap AMMs between the H tokens and their true or canonical assets. So that would be say H di to A di. And so that way, when the liquidity provider, we call this role, the bonder mints, H di, for the user, because they’ve made a transfer, then immediately gets swapped through the AMM into the canonical di. And then that’s the one that the user can go on. And then deposit it into [inaudible 00:20:56] using uniswap. That’s the one that’s going to be kind of widely adopted in that roll ups ecosystem.

Can Gurel (21:02):

Right, right. And also, just to make sure this point doesn’t get missed. You also touched on the point that in a roll up a lot of transaction, you batch them together into a compact size, and then this gets propagated through layer 1 to another roll up. So here actually, the question then becomes why there’s a need for an intermediate token. And then you’re also talking about the bonders minting tokens. So what is the motivation behind this to have a Hop representation of tokens to cross assets actually, can we expand on that?

Chris Whinfrey (21:46):

Yeah, so for Hop to function as it is functioning, we need to be able to basically burn this token at the source and then mint it at the destination. And so with kind of the canonical tokens or basically the tokens that are the representations produced by the roll ups native bridge, we aren’t able to program that functionality into them directly. And so-

Can Gurel (22:14):

What do you mean, when you say we cannot program the functionality?

Chris Whinfrey (22:20):

So with the H tokens, they basically when an H token is burned, that’s when it kind of adds a message to the list of pending transfers, that will eventually get aggregated into the batch that gets transported from the source to the destination. And so with the native bridge tokens, when they’re burned, you basically just get to claim it on layer 1. And we want to actually claim it at the destination. So we need this different model that if we don’t have that level of control with the native assets.

Can Gurel (23:12):

Understood. And then let’s continue from that point on the user burns the the H token, let’s say he [crosstalk 00:23:21] yeah, and then what’s the following chain of events from there on?

Chris Whinfrey (23:27):

So the user burns the H token, and then the this role called the bonder one of the bonders will kind of see this transfer has been initiated, and then they will come in and complete the transfer. They basically have collateral locked up. And that allows them to make each token per the same amount that the user transferred minus a small fee at the destination, and then that immediately gets swapped into the canonical token. So from the user’s perspective, they’re just going from di on Optimism to di on Arbitrum they don’t really have to think about this intermediary H token at all. It’s completely abstracted away from them, but then they get tokens at the destination.

Can Gurel (24:14):

Got it. So, user has again the canonical di on Optimism, he basically wants to transfer it to Arbitrum he creates a Hop transaction and the Hop transaction is his first converting that to a H version, the hop version of di on the origin roll up. And then this one gets burned, and then in Arbitrum again, a Hop version of di gets minted, and then it gets converted to the canonical di on Arbitrum. Is that correct?

Chris Whinfrey (24:58):

Yeah. That’s exactly correct.

Can Gurel (25:02):

So the bonders here are actually playing a crucial role, right? Because once they see the intention of the user they [inaudible 00:25:13] front liquidity and in order to do that they’re putting up a collateral during the time it takes for the transaction to settle out on layer 1. So in terms of capital efficiency how do you see Hop Protocol?

Chris Whinfrey (25:34):

Yeah, so in terms of capital efficiency, to take a step back, Hop basically has two types of liquidity, we kind of have passive liquidity and these are people that are providing liquidity to the AMMs. And then we have this what we call active liquidity, because the bonder needs to run this off chain process, they’re the ones that are fully verifying the source chain, making sure that they’re not being defrauded or something like that. As so it’s this active role where there are liquidities is they’re consistently making transactions with their liquidity. And so ultimately with bridging, there needs to be some reserves of the canonical token that can be accessed by folks that are bridging, because there needs to be basically some pool that they can tap into and pull tokens from when they arrive at destination. And so that’s how we think of AMM liquidity. And so that I think, is optimal. I don’t think there’s a way to better use that liquidity, because there ultimately has to be some reserve pool.

Chris Whinfrey (26:51):

And then the collateral that the binder locks up, this is where we see an inefficiency in the current implementation of Hop. And so the bonder uses this collateral to front liquidity or mint, these H tokens. And right now they’re using the same asset, but they’re bridging, so if it’s di that they’re bridging, they’re locking up di. [inaudible 00:27:15] that they’re bridging, they’re locking up [inaudible 00:27:17]. In the future, we’re going to decouple the bonders collateral from the asset they’re bridging, and so this is going to allow the bonder to hold productive assets this could be [inaudible 00:27:32] positions, it could be tokens. They could have a basket of assets, and Ave and only borrow, as they need to collateralize these transfers, and this is ultimately going to remove all capital inefficiencies around the bond [inaudible 00:27:51]. They’ll basically be able to hold the same basket of assets that they would otherwise and just earn some extra yields by performing this active service with their basket of collateral.

Chris Whinfrey (28:03):

So that’s how we think of capital efficiency with Hop today and hop in the future.

Can Gurel (28:09):

Right yeah, it’s important to separate these these liquidity providers, because the the AMM liquidity providers, which we’re accustomed to as users, it’s just that you’re providing liquidity and in the case of Hop, that would be one side would be the canonical token. And the other side would be the Hop version of the token so that it can be swapped one another at destination or the origin. So from here actually, I want to dig into we mentioned that bonders, they lock up collateral. And so let’s play the worst case here. So a bonder, he just mints a bunch of H tokens, and sends them to himself fraudulently. Such transaction doesn’t exist. And how do we protect it from this?

Chris Whinfrey (29:17):

Yeah, so when the bonder mints a bunch of H tokens in the current model, since we haven’t decoupled the collateral from the asset that’s being bridged, they’ll actually have an equal amount of that H token. [inaudible 00:29:33] so they mint a bunch of H die, they’ll have an equal amount of H di that is locked up in collateralizing that mint or the completion of that transfer. And so if that was actually a fraudulent transfer, when it’s not a fraudulent transfer, their collateral is basically unlocked until they can prove that that H di was burned at the source chain. And so that proof that’s what actually gets propagated through layer 1 as part of the batch. And so if they bond something fraudulently and there never will be proof that does reach the destination, then their their H di collateral will be permanently locked up, and the bonder just ends up in a complete wash. Because they basically locked up H di, they’ve minted an equal amount of H di, and now that locked up H di is permanently locked. So they ended up exactly where they would be and the system stays fully collateralized.

Can Gurel (30:36):

And, yeah, that’s great to know, actually. So in terms of trust assumptions, this is pretty much as close as you can get to Ethereum layer 1 trust assumptions, right?

Chris Whinfrey (30:50):

Exactly.

Can Gurel (30:53):

So when Hop protocol it integrates with many roll ups. And roll ups don’t miss based on the implementation of the specific roll up, it can differ in terms of security, right? And also, there’s side chains that Hop protocol also supports. So in terms of the risk here, as a user am I exposed to the weakest link here of the scaling solutions?

Chris Whinfrey (31:26):

That’s a really good question. And so the answer is no, from a user perspective. The bonders tend to be more at risk just because they touch more of the networks. But as a user, you’re only exposed to the risk of the networks that you’re using and Ethereum. And so what that means is say you’re on X di, and you’re bridging to Polygon, then you’re subject to the risk of X di, you’re subject to the risk of polygon and Ethereum but not the risk of Optimism, or Arbitrum. And so the way that we do this is, we track the H tokens. So a user deposits, say di into the layer 1 Hop contract, and then their [inaudible 00:32:15] H tokens on the layer 2. And so we track how many H tokens are minted for each layer 2, and make sure that the H tokens that are exiting that layer 2 can’t exceed the amount that went in. And so that limits the liability any single scaling solution presents to the rest of the system, because say, if this scaling solution were to go rogue and say try to exit way more liquidity than actually existed on that scaling solution, then this mechanism would just kind of stop it at the point where they can only compromise the H tokens that are on that scaling solution.

Chris Whinfrey (33:00):

And then the bonder role they are kind of facilitating transfers across these different scaling solutions. Bonders can choose to only support just a subset of scaling solutions, and they can limit their liability that way. But ultimately they’re going to be touching more scaling solutions. And if they bond a transfer from a scaling solution that’s gone rogue, there’s a chance that that scaling solution doesn’t propagate the proof over to the destination and they don’t get to unlock their collateral. So that’s how you can think about the liability that you’ll face when using Hop. And so another important note is that users don’t end up with this [inaudible 00:33:51] token that they end up with the canonical token. What we saw with for example, Poly network is users who are bridging assets to another chain, I forget what the chain was. But these were kind of wrapped tokens. What was it?

Can Gurel (34:10):

I said, no one knows.

Chris Whinfrey (34:12):

Yeah. So users had this wrapped token that was produced by Poly network. And this is dangerous, because users were using these wrapped tokens on that network and not realizing they still had exposure, risk exposure to the bridge. And ultimately, a lot of those users lost their funds when they didn’t realize that. With Hop, you’re going from one canonical class to the next. You’re only very briefly exposed to this intermediary asset, which means that you only have risk exposure, when you’re making the transfer from point A to point B and then the second you have funds on point B, you no longer have risk exposure. So if you’re using it, the chances of you losing funds through Hop are very, very low. Because you only have a very, very short window of risk exposure.

Can Gurel (35:04):

Yeah, this is like a great property to have for cross domain messaging protocol. So just to break down your sum up, users only get to have exposure during the time of swap, and bonders only get exposure in the scaling solution for which they provide liquidity. So yeah, that’s a that’s great actually. So moving on from here. I want to also have your… maybe drifting a bit from Hop Protocol, but talking about roll ups specifically. I wonder your take about the roll ups? How do you see the space to evolve? Like many giga brains are obviously working to onboard people into scaling solutions, roll ups, but do you see any potential resistance from users to onboard to those scaling solutions? If any, what could be a concern there?

Chris Whinfrey (36:20):

That’s a good question. So I’m very excited about Optimistic roll ups. I think that’s one of the better trade offs in terms of security and costs that we have right now. But ultimately the cost of [inaudible 00:36:38] is still pretty high it’s like roughly 10% of what we see on Mainnet Ethereum, and even 10%, of what we see on Mainnet Ethereum can still be pretty ridiculous. So I’m still so bullish on change, like Polygon and X di, where they don’t necessarily share the same security level of Ethereum. But they do kind of allow these kind of use cases that even Optimistic roll ups today are pricing out. And so these could be like very small time users or traders, this could be people that are playing games, where just like, if they’re playing with $10 of value, it doesn’t make sense for them to be paying one or $2 per transaction, which is what those Optimistic roll ups look like. That being said, if the user is using DeFi they have a large part of their net worth or even a portion of their net worth on a scaling solution, it probably makes sense for that to be Optimism, or Arbitrum where we know that the security is matched by at the same level of Ethereum.

Chris Whinfrey (37:49):

And so I think that there’s going to be room for both, there’s going to be use cases that they kind of shake out for both. And then in the long term, I think, ZK roll ups are really, really interesting. I think looking back and the history of scaling solutions, we’ve seen how important it is to be [inaudible 00:38:12] compatible. So like we saw Plasma people trying to build application specific plasma implementations, we saw state channels and generalized state channels and like games just start playing out there. But the second, we kind of saw EVM compatible, scaling solutions, where we can just use the same tools, the same development tools that we can just point block explorers at them, and they just work. That’s where we’ve kind of really seen this explosion of activity on scaling solutions as far as kind of non Ethereum EVM chains. And so I really think that’s where ZK’s roll ups need to ultimately get.

Chris Whinfrey (38:52):

But it’s a really, really difficult challenge. There’s people that are much much smarter than I am that are working on this challenge. So excited to see where those develop because I think ultimately that is the holy grail, is the EVM compatible ZK roll up where the exits are instant, the level of scalability is higher than what we can achieve with Optimistic roll ups. And that’s kind of the ultimate scaling solution, I think.

Can Gurel (39:26):

Yeah, thank you for sharing your thoughts. And in that world, the imaginary world where ZK proofs are so efficient, and then we checkpoint like, frequently, then would Hop evolve into something different. Because now like providing say, fast [inaudible 00:39:45] or is kind of loses its benefit, right?

Chris Whinfrey (39:53):

Yeah, that’s right. And actually I don’t think Hop would kind of evolve into something different. So we see [inaudible 00:40:00] as our big market today, but ultimately, we see the real value of Hop is enabling these layer 2 native users where they can just move directly from one layer to the next. And they don’t have to touch layer 1 at all. And so while yes, Hop does solve this [inaudible 00:40:19] problem, and that’s very needed today that is one of the main benefits of Hop today. Even in a world where there is no long exit time [inaudible 00:40:31] and you can access ZK roll up immediately exiting a ZK roll up to move to the next roll up is still going to cost $100 today, or hundreds of dollars today. Could cost thousands of dollars in the future. And so we still see huge benefit for users to be able to move directly from one ZK roll up to the next using something like that.

Can Gurel (40:51):

I see. I see. And also there’s the area of just cross chain messaging, right. It’s not only a value transfer, ultimately, they have to talk to each other ideally. But I also wonder your take there. So when one roll ups communicates to another if there is no bonder to front liquidity immediately as it is right now, then the communication would still be delayed with the L 1 [inaudible 00:41:28] the right. So in Ethereum you need to wait so many blocks, depending on the amount let’s say involved. So it’s not like we have this full composability that Ethereum L1 has today. Do you think that could be a potential problem? How could that be mitigated?

Chris Whinfrey (41:53):

Yeah, it would definitely be a challenge. So in terms of cross chain messaging and composability, we see this move from a synchronous paradigm, where each contract can just talk to other contracts, each transaction is completely atomic, where if the transaction reverts anywhere along the way, the entire thing is unwound. And then we’re moving towards this asynchronous paradigm where now we have the transaction starts and then there’s different times where we wait. And then the transaction is completed at a later time, and you also lose that [inaudible 00:42:42] of the transaction where say the transaction reverts during the second part. You can’t necessarily unwind the first part, because they’re happening at different times. And so this presents a challenge, I wouldn’t say that it’s necessarily a very bad thing. But you have to deal with the problems that come with this asynchronous communication. And so the way we think about the trust bottle, on layer 1 Ethereum today is you have this message from one contract to the next, it happens immediately. And that it’s it’s like an owned message, where you can actually see who sent it and verify that in absolute terms.

Chris Whinfrey (43:35):

And so with cross chain communication, it breaks up into two two trust models. And so one of them is where you can communicate from one contract on one roll up to the next roll up, immediately. But that’s not an owned message, you can’t actually verify who sent it. It’s more or less just triggering a meta transaction at the destination. But this can still be very useful, especially if you can attach tokens to that message. So, for example, someone could send USCC through Hop to the destination, and trigger some functionality that deposits it into a vault contract with a specific owner address. And that we don’t need to verify who sent the funds, we just need to verify that the funds showed up. And so that type of communication is fine, it can happen pretty much immediately. And then there’s this kind of second type of communication, where we actually need to verify the sender.

Can Gurel (44:36):

To clarify, that is the case where the transaction involves some token transfers, right? It has the token, so you don’t bother with any further information is that why [crosstalk 00:44:49].

Chris Whinfrey (44:49):

Yeah, exactly. Yeah. And for most use cases, for this type of communication, there would need to be some token attached. Unless you just want to kick off some process or something. There’s easier ways to do that than cross chain call unless there’s tokens attached. And so this other type of communication is that’s where things that are really delayed. So this is where we actually need to verify who sent the transaction at the source. And so for that to fully verify who sent it, we actually need to wait for the exit time of the source to roll up. And then once it reaches the destination then we can know in absolute terms that it was sent from this address, on this roll up, and then either that could be used for something like withdrawing from the vault that is owned by a cross chain owner, or on a different scaling solution.

Chris Whinfrey (45:57):

So that’s how we think about the two different models. And so Vitalik actually released a really interesting paper on doing cross chain NFTs and he has a very interesting twist on the second model. Hop has a similar twist for ERC 20 transfers, where basically, you complete it immediately, it can be verified off chain, and then it isn’t until it can be verified on chain that you can completely-

Can Gurel (46:35):

Release the collateral-

Chris Whinfrey (46:36):

Like settle. Yeah, exactly. So with the his proposal you basically can transfer an NFT from one source chain, mint a claim to that [inaudible 00:46:49] destination, everyone can verify that off chain. And then it’s not till it’s verified on chain that it’s completely settled up. So it shows how you can get around the constraints of this asynchronous communication and these long exit times without significantly damaging the user experience.

Can Gurel (47:11):

Okay, that’s very interesting, because in almost all cases, NFTs cannot be ported over bridges, due to their uniqueness. Yeah, this talk was super insightful in my opinion. And when you think about it, if a bunch of roll ups exists, eventually there will be a cross roll up communication across the side chain as well communication in the Ethereum world. But moving on from Ethereum world, what’s your take on L1s versus L2s? We see a bunch of L1 projects also running EVM chains, like [inaudible 00:48:06] and others as well. I mean [inaudible 00:48:09] is doing great stuff as well. So how do you see this competition to move on and can Hop eventually support other chains as well?

Chris Whinfrey (48:24):

Yeah, that’s a great question. So yeah, I think it’s undeniable that we’re headed to this multi chain world. We’re both seeing Ethereum scale on its own layer 2, and then we’re also seeing competing layer 1s pop up, like you mentioned. And those also are cheaper environments, because they either make different trade offs, or they’re also just less congested than what Ethereum is today, and that unlocks use cases that just aren’t possible on Ethereum today, or allows smaller users to interact. And so, yeah, I think it’s undeniable that that’s where things are headed. We’re seeing chains like [inaudible 00:49:10] get get serious traction. And so we definitely want to support bridging across not just Ethereum’s scaly ecosystem but also to these disjointed layer 1s eventually. And there’s a few ways we could do it. So like we talked about Hop very much relies on the cross domain messaging between Ethereum and whatever scaling [inaudible 00:49:37] we’re supporting.

Chris Whinfrey (49:40):

And so when we think about risk of a user on a scaling solution they’re subject to the risk of that scaling solution and then also its bridge. And so with roll ups, those are one and the same and and then also with chains like Polygon they’re pretty much one and the same as well. But some of these more disjointed layer 1s have introduced messaging bridges with Ethereum. And those might have different trust models that they introduced. And so we could support these disjointed layer 1s. And they would basically be subject to whatever the trust model of the messaging bridge is, as well as the security of that chain itself. So this is one option that we see. And that option’s really available in the near term.

Chris Whinfrey (50:38):

And then another option that that’s available, or that we will likely head towards, in the future is for chains that don’t even have a messaging bridge with Ethereum, today, we could actually create one and possibly create our own messaging bridge. This would likely involve introducing a new validator set that approves these messages. And that would allow us to bridge two completely disjointed layer 1s.

Can Gurel (51:14):

Yeah, got it. Yeah the bridges is quite complex. And so it’s a very open design space. And it seems like we’re using them more now. And it’s going to keep increasing. So I think this was a great conversation. And we covered I think, almost all important properties of Hop Protocol. And I’m super excited about Hop, before we close out, I have to ask this question. And it will be a short one, when talking-

Chris Whinfrey (52:03):

Yeah I can’t say much. But we would like to further decentralize the protocol. And so we are exploring ways that we can do that.

Can Gurel (52:15):

Okay, so the details around the token is I assume are not let’s say publicly disclosed at this point, is that correct?

Chris Whinfrey (52:27):

Yeah. We’re still figuring out which direction we’ll take. Yeah.

Can Gurel (52:32):

Got it. Got it. Got it. Okay, Chris, thank you very much for joining. It was a great pleasure.

Chris Whinfrey (52:39):

Thanks for having me on Can, it was a great conversation and yeah, really appreciate it.