[music]
Uh thank you for introducing me, uh but I'm still going to tell you all uh who am I and why am I speaking to you today. Uh so, for the last 6 or so years, I've spent my time working with a little company called Chainlink Labs uh that has a number of products that solve the exact problem that I'm going to talk to you uh about today. I've held a number of roles across uh product, go-to-market, technical uh for the better part of it, I guess I was owning one of our mm most successful products, Chainlink VRF, which was randomness on chain. But lately, I have been dealing with integrations, blockchain integration specifically. Uh uh across all of all Chainlink products, uh which means that I have seen a lot of things that can go wrong.
Uh every blockchain is slightly different. There's some issues that can happen. And I will try to explain to all of you uh or or to at least give you some nuances about uh what could go wrong, how you can think about uh how you can make better decisions when when you're thinking about moving assets cross-chain. At the surface, it's it's it looks really simple. It's uh you have something on one chain, and then you want to you move it to another chain, and it ends up there.
It's it does work simple. You know, uh blockchains are uh part of what makes them so great is that they're closed ecosystems, and that means that they cannot see anything that happens outside of them. This enables a number of things, a number of use cases. It makes them deterministic deterministic. It makes them able to do to do a lot of stuff that you cannot easily do outside of a blockchain, but it also means they're blind to the outside space.
And cross-chain means that something someone or some service or some some sort of product needs to be able to tell that blockchain that something happened on on the other blockchain. And and that's it. That looks really simple, right? Uh but someone or something needs to make that decision. And and that is the the actual product.
And and here is where things get complicated. And that's what I'm going to talk about. Uh now security security is a very boring concept in general for for for most people or for most companies. It's always like number two or four on the list after better features, better UX, and then it comes security unless something wrong happens. Then it becomes the number one on the list.
Lately, unfortunately, we've seen a lot of a lot of incidents in our space, and probably it has become number one for for too many people or too many companies. Or at least it has been in the news uh quite a bit. But fundamentally, security is uh an economic concept. The cost of implementing that security needs to be justifiable by the value that is at risk. And and if you think about cross-chain about moving some something, let's say you have 100 USDC.
You want to move them from Ethereum to Arbitrum. If you think, "Okay, it's a hundred dollars at risk. It's not that much. Why should I spend a lot of on security?" But this is one of the nuances.
Uh The The problem is that there's this whole cross-chain protocol or bridge or system that needs to transfer your your uh your funds from from chain A to chain B. And if it fails, it's not only your $100 at risk. The whole chain the target that has been compromised can go down or the whole asset can go down can go to zero. So, the the grade of that security needs to match what is at stake. That that is just a fundamental concept about security.
And now, how do we how do we make sure that all of this uh happens is true to the point and uh whoever we trust to make that decision for us that something happened on the source chain and and then we can unlock value on the on the target chain. How How can we uh make that decision? Well, there there are a number of ways uh that this is done today. Uh but still the most
[snorts]
viable way is uh through a committee. Essentially, same way many blockchains operate. You have a number of independent parties that come to a consensus that something happened. And they give their stamp of approval usually by just combining their signatures. Uh and those signatures get verified.
And that's how uh the committee verifier works. There's other um other developments, technological developments, light clients, DK clients. Uh they work on some chains. Uh but to date, none of them have seen enough adoption. There's uh There's reasons for that.
For example, the is very computationally expensive. It's uh very difficult to scale. Uh light clients also it's very they're very difficult to to do on Ethereum uh for example and on some chains uh they're very easy. For example, on on Cosmos you have IBC which utilizes light clients. Uh it's very easy to do that there but uh for the chains where we have most of the value, still the the committee way is is the right the only viable way or or the most scalable way.
Uh so the the the committee needs to independently attest that someone is trying to send their 100 USDC uh from this chain to that chain. Which means that they need to have uh each each of the members of that committee they they need to have independent observation. And this is this is where a lot of the uh bridging or cross-chain protocols lack transparency because you cannot you cannot see uh you you can there there's no reason to think that if there's a committee of let's say seven operators, all of them have an independent view. In in in some cases, they they may share the same view. They may be looking at the same RPC endpoint.
RPC is um basically the way to interact uh with a with with a blockchain. Uh if you want to see what is happening on a blockchain, you ask an RPC about that. Now, especially some of the newer blockchains, it's very difficult uh to have for some for some operators at least it's very difficult to to run their own RPC. Uh so sometimes they share. So if they do that, uh like if all of those seven operators, they look at the same RPC, it doesn't mean that it doesn't matter that they're seven.
Like, they're all attesting to the same thing. There's a single point of failure or a point of attack where if there's an attacker who can compromise that specific RPC, uh they they can they can execute a a successful attack. Even even though you have multiple people agreeing that something happened. So So that is that is something that um that can that can make things go wrong. Uh or if if you're if you care about your reliability, usually as an operator, you care you have some sort of failover.
If your failover goes to the same uh the same other RPC where uh the other operators also go to if they failover, that is also an attack vector. And and attacks like this have been executed in the in the very recent past. Uh where uh the the attackers have uh executed a a DOS attack on the on some of the primary RPC end points and uh made made the operators to look at the same view. And uh that that resulted in a successful attack. So failover is also you need you also need to be careful.
If you have failover, you you must ensure that this also results in independent observations. Now, even if everything is okay, the blockchain itself might be a problem. Uh we have we have had sort of an explosion of blockchains uh that have launched in the past several years. It has somewhat subsided nowadays, but still there's many and some of them are not very secure. Some of them have been exploited.
So, if you have a cross-chain system where the cross-chain protocol has essentially mint and burn permissions for an asset across many different blockchains, all that needs to happen is one of those blockchains to be compromised. Then the committee sees that something happened on that blockchain and it attests to it there's nothing wrong with what the committee is doing. It it's attesting to what they're seeing, but the blockchain itself is compromised and this can cause contagion. Because if if the protocol has mint and burn permissions on all the all those blockchains, now it can create infinite supply and this can also go cause the asset to go to zero. Uh so, that is a problem.
How do we solve it? Now, the reason many of those protocols have mint and burn permissions on all of the chains that support is is convenience so that users can um can move assets between any of those chains. So, any to any. Uh instead of going through uh through let's say a central hub. But the actual solution to this particular problem, contagion, uh is uh hub and spoke model.
Uh because that's how you can contain one bad blockchain. If if one blockchain goes bad, it the damage is only contained to itself uh through a salad approach. Now, you can still have convenience for users to and go from any chain to any other chain through intents. Uh intents is a sort of a uh higher level uh protocol that runs on top of uh uh the cross-chain protocol that that lets mm these parties called solvers uh execute orders without actually needing uh uh this direct route from between between both chains. So, also at at the cost of uh one to BP's or some some fee, uh they give users convenience.
So, you so you so you can have security and convenience, but at a cost, of Of as usual. Uh now because many many things can go wrong, uh there's it's always a good idea to be able to to to to plan for the uh unpredictable. Something can happen that you didn't plan for. That that's that's always the case uh in software in general, but in blockchain even more so. Uh so unfortunately, uh in blockchain what what happens in blockchain stays in blockchain.
So, once it happens, there's no way to revert it. Uh uh so, there's there's fewer things that you can do, and the the the main and the most uh effective thing that you can do is transfer limits. So, if if your protocol supports uh the ability to to limit the the amount that can be transferred between two specific chains, [clears throat] uh that is uh that is a way to contain the damage. So, the damage can be uh bound to whatever the transfer limit, let's say, per 24-hour is. And that is a very good way uh to also, going back to to my to to what I previously said, that security is an economics concept, there's a very good way to assess uh how much you can spend on security because you know how much the damage can be as as as a protocol developer.
Uh now security in general uh has been a very very hot topic recently. And previously, all the exploits happened uh through smart contracts, uh smart contract bugs. Uh nowadays, it's not so much so. Uh I think partly because uh in the HFA I, there have been uh a lot of uh successful attacks, but it also uh works works for the for So, all of these uh are being patched. Uh there's audits that are that are or other techniques that are successful at containing those bugs but but lately most of the exploits that we've seen are through compromised infrastructure, compromised private keys.
Uh and and that that's how most most of the money uh is lost to hacks nowadays. And I think after me we have some people that are probably going to expand on on that topic quite a bit about AI and security. Now, what what I tried to do uh with with all of this was uh to describe the whole threat surface uh and to to show that this thing that looks simple on the surface, it's actually uh quite nuanced and you have to think about quite quite a few things before you make a decision. So, um creating a cross-chain protocol might be easy. Uh operating one, very hard.
Hopefully, all all of this uh helps you make better decisions in the future. Thank you.
[applause] [applause]
And I if if there are any questions, happy to answer.
Yes, we do have a few questions for you. Uh so, what do you do to help operators get remote procedure calls from multiple different providers or would you prefer for operators to to primarily run their own?
We definitely prefer operators to to run their own RPCs because like I like I said, uh this is uh the the key is independent observation. If the operator is trusting someone else, a provider, they don't know who who else uh that provider is is is giving their service to. So, they might be unknowingly sharing uh with with another operator. And um independent observation is the key thing here. Failover might be okay uh to go to a third-party provider uh just to uh keep costs contained, but we also try to ensure that uh any failover configs are uh bound to different operators.
Sometimes we prefer there's no failover because uh worse reliability is better than failed security. That That was No more questions, okay? Thank you. I I ended up quite earlier. Thank you.
[applause] [music]
Automatic transcript — names and jargon may be misspelled.