DevTooling in a multichain world panel hosted by Mathieu Chanson

Great to see so many people excited about uh multi-chain dev tools. So me personally, I think I'm I'm I'm really happy to chat about that because you know multi-chain has really changed from a thesis like four years ago to reality now. So we have all these optimistic rollups having launched. We have many L1 which are EVM compatible and have really traction by now. And soon we'll also have uh the CK rollups launching.

And I'm I'm really excited to see how developers who build dev tools but also who build deps um change their thinking with you know these these changed environments. And personally as a as a PM at Salo which is an EVM compatible L1 I've had hands-on experience with um you know transferring deps from different ecosystems within EVM worlds. And it's actually not that easy and uh the dev tooling world has still way to go. So um with that I'm super happy to have all these experts on on on stage with me and yeah BTON you're you're building uh tenderly and you're also deploying on many on many chains. maybe you can give us a quick overview how you know your product helps people uh deploy and maintain their smart contracts um on on different layer ones and tools L2 side like all of the things.

So, hi everyone. My name is Bogdan. I'm one of the co-founders of of Tender. Ah, okay. Sorry.

Can you hear me now? So, my name is Bogdan. I'm one of the co-founders of Tenderly. So, we're a blockchain developer platform, which means literally nothing at this point because everyone says the same thing. But what this actually means is that we have a bunch of tools and services that help developers be more productive.

So, debugging, profiling, alerting, infrastructure, simulations, nodes, like a bunch of different things. But um when we started working on tenderly our thought in this four years ago was a very unpopular opinion was that uh there's going to be multiple chains and everybody was in Ethereum mainet maxi at that point but we thought that the EVM is going to be a win and we were lucky enough that we were correct. So how we help developers actually deploy and deploy and maintain things on chain is trying to make all the tools that we build work across all of the chains in the same way which is actually very hard to do as you mentioned because EVM compatibility isn't EVM equivalency. I really like that new term. So actually even and I guess everyone else is going to have a better opinion than me on this but when you deploy from one EVM chain to another your smart contracts behave differently your clients behave differently and it's very important to streamline that.

Yeah. So maybe your um can you give us a quick overview of how you are actually trying to make it easier to deploy on these different chains with uh with hyperlane? Yeah definitely. So hey guys I'm York. Uh I work on Hyperlane which is an interoperability protocol and what that means is there's basically smart contract systems deployed on various chains which allow developers to pass messages arbitrary messages uh between contracts that exist on other chains.

And so uh when they're uh deploying their applications they're basically uh hooking up their deployments across each one of these chains to the hyperlane protocol. And so, you know, we've we've had to deal with deploying these smart contract systems across a bunch of these chains ourselves. And in doing so, we've built out uh basically a bunch of uh our own kind of custom SDK and and deployment tooling uh to facilitate this. Mostly because uh a lot of the off-the-shelf tool chains like uh Foundry or Hardhat really don't have uh super native solutions. uh they don't really have uh native solutions for these sorts of like uh multi-chain deployments, especially when you have to keep track of uh addresses that like need to be configured on different chains.

So you kind of like are parallelizing your deployment. Um and so yeah, we we have basically built out like a a TypeScript uh SDK which provides like item potency. Uh Boggen noted that kind of there's a lot of idiosyncrasies across uh what people describe as like EVM compatible networks uh that maybe don't actually share all the same op codes or pre-ompiles. Um and so like a lot of the time you encounter uh you know failure modes that are inconsistent uh across different chains and like what we've done is created this like item potent deployment tooling that allows you to resume from failures which like saves you a lot of work when you're deploying across like 20 different networks. Um so that's just one feature I guess.

Cool. Thanks. So um Rashid Rashid sorry maybe um can you tell us why you chose to go omni chain first like directly and how this makes your product really way better than other borrow lending protocols um and then we can jump into like what was hard about deploying that actually. Oh for sure for sure. Uh so hi everyone my name is Rachin and I'm founder of Sedro Finance.

We are uh an omni chain lending and borrowing protocol. And yeah, for us it made perfect sense to deploy on multiple chains first and go omni chain right from the start because uh like if you see lending and borrowing protocols right now uh what you can do is like say uh a or some other lending and borrowing protocol is deployed on ethereum right and you can lend ETH there and with that as collateral you can only borrow within Ethereum with within Ethereum chain right so what that does is it limits your borrowing power now if you're suddenly able to lend in Ethereum and then borrow in any other chains that we support it suddenly increases your borrowing purchasing power and at the same time when we do that uh like if you see in a right now they have the utilization rate of about 25% last time I checked uh and that is because you're limiting the number of users that can use your protocol uh by the number of users in the chain that you support right uh so if you open the utilization of a liquidity pool across all the users across all the chains then you're you're increasing the probability of your liquidity pool being utilized in a in a much more efficient manner and hence like a better functioning of a lending protocol and yeah that is exactly why we chose to go omni chain first cool and like um you're already live right on a on a bunch of EVM compatible chains and you'll also be adding nonem compatible chain soon is that uh correct right so we are currently on testnet uh going on mainet very soon and uh Yeah, currently we support we can support any EVM chains and uh right now as we speak we're integrating Aptos to open up our way for non EVM in uh nonVM chains as well. So what was the most hard thing? uh like how easy was it to just deploy on these EVM compatible chains and then if that was easy I don't know um how much harder is it to go into these other worlds like you know the appto or Cosmos or so ecosystem right so uh like honestly speaking uh the the deploying part for EVM chains that it wasn't that hard because uh layers thanks to layers we're using layer to pass messages across chain so they make it very easy to deploy and like just plug plug they have like a very good plugandplay system. So very easy to deploy on uh AVM chains and we didn't have to think about a lot for like things like wallet uh wallet integrations or anything uh for EVM chains because like like users they they usually have like same address for for like EVM chains right but the problem the the problem goes in a much different level when you're trying to integrate non EVM chains with EVM chains as well right uh now you have to think about how do you uh how do you like uh connect these two different wallet addresses for a single user and uh and like a lot of different uh uh a lot of differences at infrastructure level.

So yeah, it is I would say much harder to integrate EVM and nonvm chains uh than like just EVM to EVM chains. So uh Booked on is that this the same experience that you that you make like um where where is the world vision for you like what what chains do you want to be active on and is it possible to be really an omni chain dev tool which is present and working well on every chain or do you have to limit yourself and you know deliver a great experience on a certain subset yeah I think um it takes a lot of effort and I think you're very much aware of that to actually have this experience be completely streamlined everywhere. So what we actually did is we have our own custom EVM that we need to basically backport all of the differences between the op codes between the gas information and a bunch of different things. So we internally can have these abstractions which are the same across all of the chains that we support. Now when we look at it like an omni omni chain developer tool and this is especially for like hosted services like like tenderly um it gets harder and harder to onboard new chains as everybody's trying to do their own own thing kind of everybody says again evatible but oh suddenly there's this thing called the sequencer and it's very important suddenly on arbitum you have this invisible transaction on transaction index zero on a block that nobody actually talks about but it's like very important when you're building the tool and etc.

So yeah, I guess um it's hard, but I I think we should we shouldn't use that as an excuse to build toys. We should make products that make people's lives easier. So yeah, got it. How do you think about that at uh at Hyperlane? Yeah.

So, uh, one of the features that we're the most excited about is this concept of permissionless deployment and permissionless interoperability, which is this idea that, uh, you know, applications are going to want to be on infrastructure networks that we can't necessarily always support deploying on. Uh, but we're providing the tools for our developers and our customers to actually expand the Hyperlane protocol themselves. Um and obviously that uh implies kind of a whole host of cha of security challenges. Um but the the general idea is uh you know we can like if if we really believe in this multi-chain future, we're going to have you know thousands of these chains that all have like um you know minute differences at the infrastructure layer. And uh we want to kind of create these abstractions that generalize that allow developers to have consistent interfaces.

um across chains. Um so like he alluded to even the like uh kind of identifiers of accounts across some of these newer VMs uh look very different than they do on the EVM. And so like what we've done is like tried to create these like forwards compatible abstractions uh for how how you can address contracts and accounts on these new VMs that uh maybe have like uh are using different elliptic curve cryptography or or those sorts of things. Uh but in general it's like really hard to create an abstraction that captures you know all of the different VM designs. Got it.

So Rajin um I'd be really interested to hear uh from you as you know DEP developer how do you prioritize between all these different chains that are around right I mean um usage is mostly centered still on Ethereum. So if you just look at that it's kind of hard to make a move in any one specific direction. Do you mostly think about just going the path of least resistance and where you can you know deploy the easiest way or do you try to think ahead of um where do you think the users will go or like what what is your prioritization uh system essentially? Um so yeah uh for now like especially for our launch we're thinking of launching in only like few three four chains uh including like all the like you know as you said high volume chains like Ethereum, BS, BNB and like uh Polygon, Avalanche. So probably these four and yeah there are a couple of reasons for choosing those.

uh first is like of course the uh because all of them are EVM compatible meaning like we don't have to make a lot of changes to deploy on on all of these chains and uh and at the same time all of these are high volume chains and uh like we would want users to use our platform like it doesn't make sense for us to launch on a chain that doesn't have high volume instantly to uh and then just be the just the protocol sitting there doing nothing right um so we'd want to initially start out with like all these high volume chains uh gain user user attraction there and then after that slowly expanding to all the chains that we can support. Our our goal is to be able to be everywhere uh everywhere so that like users don't have to think about what chain they are on uh whenever they're performing any uh DeFi transactions. Uh so we're trying to create this layer of abstraction uh as you said uh the uh everyone here is like creating layer of abstraction for developers. We're trying we're trying to create a layer of abstraction for developers and users for liquidity uh liquidity part right like users don't have to think about like uh if there if there liquidity in one chain they don't have to worry about how to perform transaction in other chains so that is how we're thinking about it yeah got it and I mean going a bit more into the technicalities um how is your text like looking like at the moment I mean what are you specifically using to deploy contracts to surveil them to connecting your front end, etc. Because I mean afterwards, I'd be interested to to hear from you two guys which part of that stack, you know, your app or or tooling could replace or or work more efficiently in.

Um, yeah, Rashin. Sure. Sure. Uh, so for us it was uh pretty simple. We didn't have to use any uh any like different uh stack at all.

like we just use this like standard solidity for EVM and then hard for deploying and uh just uh web3js for like connecting the front end. So pretty much the standard uh standard like uh tech stack for web3 applications and uh yeah know like uh the problem I think would arise when we are like trying to integrate front end of our uh appto smart contracts. So yeah would love to hear you guys' thoughts on that. Yeah. Uh I personally have a lot of thoughts here.

Uh spent a lot of time thinking about this. Um tell us, tell us. But yeah, if we do want to achieve this user experience of like a user not knowing which chain they're on but benefiting from the network effects of an application across a bunch of these different chains um where there's kind of like this sharded liquidity uh then we need to have uh applications which are architected in a different way. So like the front end uh is going to basically require this like global view of the application state across a bunch of these networks. Um and as a user when you want to interact with that application you're you know you're producing some signature.

Um if we don't want the user to know which uh network they're on they at least have to you know have to have some specified preference for like which chain they want to be on. Maybe it's like a fee preference um or a finality preference uh you know or a latency or these sorts of uh underlying properties that like differentiate the infrastructure layers. Uh but we still need to have you know some uh interface that allows users to understand the entire uh application state that's relevant to them if it is sharded across all these different chains. Um so yeah we we've been working on some again like some SDK tooling. I mean it's fairly like uh immature I would say just because uh you know we don't actually have a lot of people who are actually building applications in this sort of like uh forward thinking architecture but um yeah I do think we need to start to to think about um how how the the user interfaces need to adapt to the like multi-chain landscape.

So um Ratchin I mean is your app still one front end for one chain basically is it like whatever uh unis swap and all these others where you need to select which chain you want to transact on and then that changes what RPC is being used in the background and what the wallet says and so on or do you have that vision of having one united front end for you know the whole app? Um so yeah right now we have like unis swap kind of thing like where you where you can choose what network to be on. Uh but yeah eventually that is the goal. I think that that comes down to uh like other friends here like building those kind of infrastructure. Uh about like users uh don't have to like select the networks they want to be on like like right now for example in the web to world we don't we don't care about what server like Instagram is hosted on right like we as a user like we we don't care like what blockchain we're on.

We just want the best user experience and then the best uh best best like best uh I don't know best best profit out of it I would say. Uh so yeah uh like uh right now we are like the unis swap kind of model but eventually we'd hope to uh go to go to that direction with like total abstraction from the underlying blockchains. Can I hijack for a second your your role in this conversation? I just want the crowd to be aware how actually complexity this is. Rashin kind of made it sound extremely simple.

So, can I ask you a couple of questions if you're okay with it? So, while you mentioned that you plan on launching on I I think you mentioned Polygon, Avalanche, Ethereum mainet and a couple of others. How were you testing for these chains? Sorry, could you repeat that? So, how were you doing testing?

So, were you doing local forks? Were you deploying to test nets? How did you approach this issue? Um so yeah so we were uh doing like local forks first and then we deployed on their uh test net and then um and then yeah so first we did our internal testing and then to cuz because we built our architecture from the ground up right like it was not as easy as just working our way and then like adding multi-chain feature to it. So uh we had to build it from the ground up.

So uh we had to test if this architecture would stand up and uh so that's why we opened our testing to the public like 3 months ago and uh we processed like uh more than 200,000 transactions so far on test net and uh it hasn't broken so far. So I'd say the the testing has been good so far and yeah and how did you figure out it didn't break with 2,000 200,000 transactions like do you monitor the the application in some way? How how do you know it's actually working? Um so we we check our like uh like yeah it's a manual process right now. We check the transactions time and again and uh also like the community feedback helps uh like if if someone from the uh if someone uh from our community tells us like hey this is uh not working we go to them but unfortunately that hasn't happened yet.

So okay so we talked about only two things here which was like local testing and the second one was monitoring basically which was manual here. So take that for example, you have to do that across for example three, four or five chains. So these two things suddenly become 10 things actually that you need to figure out and this is why the multi-chain strategy is very important with what hyperlane is doing layer zero what we are doing everything else because you like imagine Rene waking up each morning and then refreshing each ether scan instance by hand to figure out if everything is working correctly and then hardhead locally forking every network every time they want to do tests. So it's very important for us to invest as much as possible because comparing it to web 2 like people now mostly deploy to AWS GC GCP for some up reason Asia and that's about it and then you have Terraform which figures it out but we're going to be in this like future where like you're deploying to thousands of things as you mentioned and it's going to be very important to streamline this whole thing. So yeah sorry for hijacking I just wanted the crowd to be aware of like the complexity is exponential.

It doesn't scale linearly with every chain that you onboard. It actually scales exponentially. Totally agreed there. Yeah, 100%. And also like I mean how do you create these 200k transactions, right?

I mean do you how do you chaos test essentially, right? I mean do you do you have do you have users that you incentivize to be on test net and you know hint hint maybe at some point there's an airdrop or something? uh because right tenderly is is being used to automate all of that and to to really go not only into the let's say normal state uh where maybe 95% of the time you are in right the two sigas but into the extreme state. So maybe could you could you tell us a little bit how you can use tenderly to really like stress test and go into the limits of deps to see uh you know whe whether they also work there. Sure.

At this point, I'm joking both on Twitter and in person here at the event that our goal is for girly ETH not to have any value because I think it's completely it's extremely dumb that people are not that people are paying but that we ended up in a situation where you need to pay to test things. Anyway, sorry this is a pet peeve of mine and I get triggered. So anyway, how people actually use Tendul for these things is we have something called cloud forks. So just as Rene when he's working he can use hard locally to fork a network. You can basically just pick any network which that we support which is I think most of the EVM chains except Cello.

Hint hint we can have a conversation later but yeah anyway so basically they pick any network that we support. They get an RPC link which is completely malleable. So you can impersonate anyone. You can even change the source code of a smart contract to see how it would behave. You can even fork your own fork which to be honest not as many people use as we thought.

It felt very cool to code the thing but it's it is like I guess too advanced. But um then you can basically do fuss testing, integration testing. You can pop it into your UI and and test it out like a staging area. So people basically use this together with Foundry or Heart or whatever, connect it to a Tenderly fork and then do a bunch of transactions to actually figure out if it's behaving like it should. And again, you don't have to even leak your code to a test net because I I mean, you don't verify it on ether scan, but you still end up in this situation where the bite code is there.

So yeah, that's that's basically how people use it. Yeah, again, this is like super exciting for me because uh this is like what I'm thinking about all the time, but uh yeah, Hyperlane's vision uh for like the long-term future of this like developer experience is being the Kubernetes for web 3. So basically having like this horizontal scaling abstraction for developers to say okay I actually want to spin up my application on this new chain because it's providing some liquidity benefits or it's providing some new uh property that's been unlocked by like you know the R&D happening at the L1 or rollup layer. Um but I have this existing network effect in my application that I want to kind of migrate to this new uh you know environment cloud environment. Um and so you want to like yeah create those tools for people to scale up and down their application you know do you know load testing um on these like test net environments.

Um and I think like we're really far away from that being the reality but I think like if we do want to realize these sorts of like super heterogeneous uh infrastructure like trade-offs uh then we do need to come up with these sorts of abstractions for developers. So um going back to this stack and you know the stack question and where is the omni chain part in the stack being built. So you know if you think about hey the front end it's all there's only one front end for for for for everything for every chain then what about the wallet is there only one wallet for every chain and then you know is there like only one um JS SDK for every chain and can can can you like have everything in like a single chain uh you know development environment and only have hyperlane which connects at the very lowest level of the stack into all these different L1s and L2s. Is that like the final state that you envision or or you know does the whole stack basically or a a large part of it have to become crosschain? You made me anxious.

You made me anxious by the amount of work you just explained in the amount of human years that are going to be invested. So yeah, I I guess it's a question mark for you. Yeah. Yeah. So fantastic question.

And I think what we want is for the developer experience, the wallet experience, we want all these interfaces to be kind of like as backwards compatible as possible to minimize the churn required on all these like layers of abstraction that sit above something like hyperlane. Um and so uh for example like we've come up with basically some tooling where you can actually use the hyperlane messaging system to uh basically describe intent to deploy these contracts across a bunch of different chains. So yeah, you start to get to this uh architecture where you maybe have like a single uh interface for the developer uh on one chain and maybe a single interface for users on like maybe on your app chain. Uh but then hyperlane is actually this connective tissue across all of the different uh like L2s or uh you know L1's that are providing basically like the interoperability to these other applications that you need to like uh you know maybe bootstrap your your your growth as an application. Um I think like it's very hard to get wallets to adopt any sort of like uh new standard.

uh Wallet Connect is doing some great work on like uh pushing forward kind of some of this multi-chain tooling but I think in general like we haven't really as a ecosystem and community like come to consensus on like what the right abstractions are so it's definitely like fast evolving okay great great answer and now we only have like two and a half minutes left so what I want to do is like look a bit into the future and ask you guys you know what is your most contra arian view of how this multi-chain uh ecosystem will evolve, right? We've been talking for years about it and for years everybody was just saying multi-chain is happening. That was like the the thing everybody was very aligned on. Um yeah, what is you you as experts in the space where are you diverging from like mainstream uh thought? So it has to be contrarian, correct?

Yeah, ideally I mean if you're just mainstream that's cool too. No, no, no, no. Cool. So February 3rd, 2025 when we sit together again here, I I fear that we're going to have the literally same conversation that we're having right now. This was the thing that happened with wallet UX.

This is the thing with that like the there are these topics that we are constantly revisiting and we just feel nice about ourselves talking about them. I was I'm actually very happy that multi-chain is happening now. But if we think about it, we always think about unis swap or whichever we we talk about 20 different projects like all the others the the most multi-chain they get is deploying to a test net and then the mainet of that network and ah we're using two chains you're not anyway. So my contrarian thoughts are that the abstractions that are going to be there but it's still a long way for people to actually adopt them and sorry for this pessimistic outlook. It was pessimistic, not contrarian, but yeah.

Should I go? Okay. Uh, yeah, I can I can go real quick. Um, so I think one of the biggest interesting trade-offs between like multi-chain future is like this idea of like async versus atomic composability. Um, and actually I think there's like uh a lot of complexity imposed on the application developer to like think about this like async composability system.

Um, obviously like I have my own opinions about like, you know, I I believe in like kind of this multi-chain thesis and like interoperability between app chains. Um, but I do think that uh well, I don't know if it's contrarian. I guess I believe in async composability. I think like a lot of people who are like Ethereum maxis maybe don't believe in that. Um, and there's like some cool research that of people who are working on like atomic composability between roll-ups, but uh I don't really believe in that.

So uh yeah that's my contrarian take. Got it. Rene. Yep. Totally agreeing with what other fellows said.

Um yeah like there it will be hard to achieve like async uh sorry sync uh like uh it's hard it will be hard to achieve the synchronized comp composibility across chains because you know it's fundamentally two different uh systems and uh it's going to be hard to do that and my my I don't know if it's contrarian but my view is that uh once we have a lot of these infrastructural side figured out uh I I think that a lot of these like legacy protocols like you know uh unis swap a lot of these protocols that deny to go uh crosschain, omni chain, multi-chain, whatever you call it, it's going to be hard to uh it's going to be hard for them to survive. Uh especially with the new protocols coming up because uh they have access to all the users across all the chains uh without having to know about the blockchains they're residing on. Uh it is just like a new generation of protocol and it's going to be hard for them to uh move to that because it's like uh they're too big to like make drastic changes and they have to be very cautious about it. So I'm I'm very interested to see that happen. Okay.

Thanks a lot. Uh Rajin York Bdon, thanks a lot for coming and having this discussion and I'm already reserving the same spot 5 years in the future and so we can have the same discussion again. Huh. Cool. And a big round of applause for Matthew.

He was an amazing MC. So a huge round of applause to him. Thank you. Thank you. Thank you.

[Applause]