Marco Castignoli - Decentralization Ends at Ethereum’s Edge

Okay. Okay. Yes. Okay. Uh, so I just heard your question before and I mean it's not my product but it's made in Italy.

Uh it's built by the by a group of uh hackers in uh Rome and they actually built this AI called uh Brian and in which you can ask actually ask questions related to web 3 for example here he's he's asking what is unis swap and then next question is please swap 10 USDC for ETH on base and the AI can actually do all the work and exchange for you and like guide you step by step in doing web three stuff. I don't know if these answer your question before but then let's go let's go back to the focus of this talk. So um first of all I'm Marco and I'm a former Ethereum Foundation uh developer and I'm now working for Argo that is a spin out of the Ethereum foundation and our team is uh developing B basically is the main c the core developer behind solidity. I don't know if anyone of you here is a technician or not, but so this this could be a technical talk. Um, and it starts from this concept of the Ethereum's infinite garden.

I don't know if anyone of you have ever heard about it. So basically, Ethereum can be thought as a as an infinite garden in which there are a lot of gardeners taking care of uh all of the plants going on in this garden. And the cool thing is that no gardener is uh uh against each other like in in typical in a typical capitalistic environment because everyone wants the ETH the basic value to to go up. So if we start fighting against each other and we we start fires in the garden then everyone is losing money and so now let's see the map of this garden and at the end we have the core so researchers and developer working directly on the core of Ethereum developing I don't know the people that developed the merge so when Ethereum went from proof of work to proof of stake people working on crypto cryptography people working on very like uh consensus yes like core stuff of Ethereum. Then if we move a bit outside we start looking at the tools.

So we have frameworks for languages. We have some specific user interface maybe not not completely user interface stuff but maybe the libraries that then developer use to to work on user interfaces. That's also where where I'm working on. and and then at the end we have the user interface. So all the applications that are working on Ethereum block explorers so that you can check your transaction going on.

Okay. So here we can see there are researchers working on layer 2 EVM. Then we go again EVM tooling. So we have languages and framework and then we have user interfaces. We have block explorers.

We have verifiers and then we have etherscan. And I and I I put this uh this image about scan because in this talk is specifically about the problems of this decentralization at the end at the edge of Ethereum. Okay. Uh the edge of Ethereum I mean the edge of this garden. Okay.

So in the middle we have a strong decentralized core but the more we go outside and the less there is decentralization. Let's start from the first problem block explorers. So, Etherscan that everyone uses is actually a closed source software as a service as a how do you call it uh software as a service and most of the ecosystem actually relies on etherscan itself. So many libraries they actually fetch all of the information from the contracts and also not libraries but also libraries used by wallets they are actually fetching all of these data directly from Etherscan. We don't know any anything about Ether Scan's code.

So for example, we just had a a very bad um hack that relied on a vulnerability on ether scan that no one no one knew because their open their code is closed closed source. So uh security researchers cannot work on any of of their code and also all of their uh data. So the database itself that contains all of the information of of all the contracts is completely closed. And if you ask them to get to to like the possibility to get some data, then they say, "Oh yeah, we have an export of the last 5,000 contracts that is just chain and address." And then we have this API.

But of course you have to pay for calling the API to extract all of the contracts information that again are one of the foundations of uh calling and interacting with a smart contract. But we'll we'll see this later. Yeah. Some nice thing that I saw is that user users think that Ethereum itself is down just because Ether Scan is down. And this is like mind-blowing from my point of view starting to like my point of view is the point of view of an aer and a promoter of privacy and like decentralization.

And this is like the opposite of like exactly the opposite of what I'm fighting for. So what are some solutions? So um like a user friendly solution is uh just right now you can do it now. You can start using block scout that is simply an open-source software as a service. you can deploy it yourself and it supports a lot of blockchains and it's already deployed for most blockchains.

So you just go there instead of ethercan.io you type block scout and and you start brow browsing uh blockchains and then if you're a bit if you're a bit more of an hacker like me I also put the QR code there is actually optan and I like it a lot I like it a lot because it runs on your own device so that's the centralization okay of course you need to provide an an RPC the RPC is basically the uh interface that a block explorer uses to comm communicate with the blockchain to extract information but then we'll see later some information about our PCs. The cool thing is uh it's never down so because you run it so there is no problem and there are no vulnerabilities from outside. Then the second problem source code verification and this is exactly what I'm working on every day. So just to understand what's source code verification on Ethereum and all the EVM blockchains uh when you interact with a smart contract you are calling a program like any other program in in in the in software engineering is like this.

Okay. So it's just a series of uh of code for machines. Okay. So you don't know what's actually going on. So it's a black box.

It's a completely black box and you have to trust it. Okay. What source code verification does, we take the code that the developer uploads to um source code verifier. we recompile it and the process of uh compilation it means to transform a human readable uh code to a machine readable code. Okay.

And that's what we do as a source code verifier. We take sources we recompile them. We we check and then we check if the output of this compilation is exactly the same as the one as the code that is onchain. I don't know if it's clear. It's a bit technical I know.

So basically I'll just repeat it once on the blockchain we have data uh in binaries okay like the one above but as human we understand only code like this. So my work is to create a connection between the human readable code and the machine readable code. Okay. And then I publish this database online so everyone can check I mean not not not like end users but security researchers can actually read the code of a smart contract instead of its bite code but here still relies there is still a problem of course etherscan then we're going to check again about etherscan uh but then even if you decide to uh trust one of us you are still trusting a single service. Okay, because we are the verifiers.

Sourceify, block, rout, we are the verifiers and you are asking us is this contract verified? What are the sources of this contract? Okay, but of course it's better to trust four uh services rather than only one closed source uh service. Again, Etherscan closed source closed course database and also lock in for chains. Uh this is from from my point of view this is completely madness that that's a short story and we have again an Italian guy working on um avalanche and avalanche used to um have uh etherscan as their main block explorers.

So all of their users ver developers verified all of the contracts on Etherscan. But a certain point they realized oh like Etherscan is closed source. It's it's like the opposite of decentralization itself. So we want to extract our data from Etherscan and Etherscan just said no these are our data. Okay.

So chains are chains themselves are locked in like when you use Apple devices like me. It's like they are forcing you to use their own products. That's madness. What are the solutions for this? So, first of all, we created a verifier alliance to fight this.

Um we have uh we we basically created a database that is completely open and each of the verifiers when once uh a user submit a new verification a new contract uh source code we store it both in our private database private meaning of our of our service not private itself but then we also push this data to a shared database between all of us so we can all learn from each other. We create standards. We are working together on uh source code verification libraries such li sourcify but I'm going to show it later. And also we publish everything on IPFS. So all the sources can also be accessed by IPFS itself.

Um I don't know if there if anyone here knows about IPFS and knows about smart um bite codes. Do you you do? Okay. So I'm going to actually demo something since I have a lot of time. Something nice about IPFS and and Ethereum.

Sorry, not Ethereum, EVM. If you're using solidity to develop your contract and then you you compile your contract with solidity, something magic happens at the end of the bite code. So, Solidity automatically appends a file uh a mesh that we called we call Seabore AUX data and inside this uh AUX data actually relies an IPFS link link and this IPFS link contains the metadata file and this metadata file actually is a collection of contracts information. So for example, you need the AI. Oh yeah, I'm a software developer.

I need the AI. I will use just a library that fetches data from Etercan. That's while at the same point you have you you have the AI right inside the bite code itself. I loved IPFS when it was new and I'm a developer myself and tried to incorporate it into my product but it failed so often and it was so slow. So is it really on the edge of usable?

Yeah. So as any other decentralized technologies right now I think in the last couple years it improved a lot and also notice that we are not only uh like solidity is not only only storing links to APFS but also to swarm that is another technology probably less stable than APFS but still if like we we make sure to pin all data on APFS so it's mostly available we we experimented and in the last years it's going pretty well. You can try if if you find a verified contract and you can actually try from our point of view it's quite stable. So yeah basically I just wanted to sh to show you this file and also notice that at the end you also have the sources with the full the full source here it's either the full source on another link to IPFS to the source. Okay, let's go back on track.

That's that's why publishing on IPFS is very comfortable because it is accessible directly from the bite code. Of course, sorry I didn't say that you still need to verify the bite code itself because someone can put anything on in in that curox at the end. So you still make sure that the contract is verified. Okay. And then uh we were discussing about trusting services.

Okay. So we are still not completely decentralized. We still we are still federated. So we have to trust a specific um service. But then there are some researches going on that I'm actually following.

And actually this slide is a bit is a bit old because this part on the left was actually uh completed uh in the last month. So in the last month we actually successfully had the the first edge verification. So what I mean by edge verification is executing ver verification directly in the user's device and we decided to um focus on the most the most uh used device that is the browser. So now verification can be executed directly in the browser and on the right it's like a bit of a more difficult topic. I'm not a zero knowledge zero knowledge uh researcher so I don't have the I cannot work directly on that and but now I actually wanted to show you an example of edge verification that it's just a click away so here I'm running Ottercan on my machine and it's I'm actually not using an RPC on my device but I'm using a I don't know quick node RPC So I set it up in a minute, five minute.

Okay. And here you notice on sorry let's go because this is the I'll show it show it to you like this. If I click contract over here normally I I get all of the AI. I get the sources where okay I get the sources like ether scam. Okay.

But then here this is an experiment that we have uh going on with uh Ottercan with the Otteran team and this is this this has actually called lib sourceify directly in the browser it downloaded the sources from our database not from uh IBFS because it's faster and more reliable and actually the quest maybe the answer to to your question is you don't even care where you get the the sources as long as you get the sources and you use the sources to reverify your contract. And so here we actually executed the same code that is running in sourceifi server but on the browser. And here the user can before interacting with a smart contract can reverify on the fly. Uh it does it mean that that is a JavaScript library running inside does it mean that it's a JavaScript library running inside the browser or which language or

no no there is u solidity they deploy also a version of soul C that is built with uh web assembly

web assembly so we are calling the real sol the real Okay.

And actually there are some experiments uh I mean that there are already a full virtual machine running on the browser and so we could potentially also uh execute Viper contracts because we don't support only solid contracts but also other languages. Okay, that's the demo. It was fast but it was good that it was fast. That's the whole point. Okay, then let's focus on the last problem.

RPCs are centralized. So RPCs basically are every time you interact with the blockchain, you're not interacting directly with the blockchain. You are passing through uh node post posted by someone else. Okay. Uh, of course the the blockchain is built uh to create uh an intrinsic and like technological trust between you and the node and and the person that is running this node.

But what can happen and has already happened is that governments for example can censor specific calls to specific contracts. For example, uh the tornado cache uh contract that was used to be hidden on chain. Now a lot of RPC based in the states they simply censor you. Okay. So uh I I think it's opposite to the to the ethos of of Ethereum itself.

So everyone is the same, everyone can do whatever. Okay. And then there is also a big a big problem of single point of failure. So if one of these RPC is down then a lot of application they go down instantaneously even if we even if Ethereum is is alive because like there are not many chances of Ethereum being down since it's decentralized. So what are the solutions?

Again we have um local RPC that is called alos. It's written in Rust and it's super cool because it syncs. It doesn't have to sync. It's not an it's not a full node. It's not even a partial node.

It's just like it uses an existing RPC. It's it it synchronizes the state with the RPC and then from that point on you can use it as a as a fully local RPC. So from that point on all the transactions that you do are are totally independent from uh from a centralized RPC. So if you combine if you combine if you combine alias and and authors scan you know that you are really using blockchain how it how is it how it was supposed to to be used. And here just uh another small consideration uh now web 3 uh grew a lot and thrived a lot and in the last years with account abstraction it became very easy for users to use the blockchain.

Okay. But here the problem with the with account abstraction is that you successfully abstracted away all of the decentralization uh weird usering uh user experience from the user. but you hidden it in the background and now the user doesn't even know what's going on. So all of the trust that you had like that forced you to sign a transaction via your ledger, your cold wallet, whatever now it's completely lost because everything runs in the background. What are the solution?

There are no solution I think because if we want the blockchain to be used by everyone, we cannot force the user to sign everything with the wallet. We cannot force the user to use a private RPC. We cannot force the user to use a local explorer and we cannot force the user to verify sources locally. Okay. So the only solution would be to and here I I come just to to my idea but it's just an idea just a so my proposal is a completely specialized browser with limited actions and it has a very friendly user interface but everything is like runs locally and it cannot interact at random with any um web web two or web three service.

No web three service. Yes, web to service. Now, so it builds the UI automatically using contract information because we can get it via local verification from lip source. then it can communicate with an integrated local RPC using Helios and and so every time a contract for some reason wants to do an HTTP interaction it warns you and it says oh this contract needs maybe an image from this website. So do you want to download it or or not?

Maybe you you can say yes trust all so you you trust this contract and it can do whatever and then at the end uh smart contract owners can integrate some custom UI to give specific uh like I don't know like a uh custom UI to the contract itself but again you are forced to use verified modules to to build it and MetaMask kind of did this uh with snaps But it's a project that slowly like no one was using it. So I I see that sometimes that there were experiment to build something like this. But probably people don't care enough about these problems. So why building something like this is if people don't care and that's my talk.