Introducing the Verifier Alliance – Marco Castignoli

in case you don't have connection maybe you can just wave at me and I'll I'll give you the mic to ask a question Tom Marco at the end Marco the floor is yours okay thanks hello everyone so I'm here to present the verifier Alliance and reintroduce sourcify uh how many of you have ever heard about sourcify okay at least someone so sourcify is a project from the ethereum foundation um because I know I don't know if you know it but what the ethereum foundation does is to host all of the um projects that right now uh cannot survive by themselves so in being open source like we and in this moment in time uh contract verification is uh mainly owned by uh ether skan then we're going to take a look about those problems so we are an alternative to the closed closed source and private owned company-owned uh ether scan and so let's begin presenting our project it's just three people uh yeah my colleagues and what our main objetive itive let's say are first first of all um let's say spread the good word about the solidity metadata Json again I don't know if if you have ever seen it in your life then I'm going to show you what's that about then what we want to do is to create tools so that other developers can Implement human friendly contract interaction that it's something else that right now I mean it's one of the biggest lack I think of the ethereum ecosystem and then we are working on ipfs so there is like a strong decentralized presence in our project that's why what we really do at the end is decentralized and open source smart contract verification as I was saying before uh most people today are verifying using not not decentralized and not open source Services basically ether scan okay and just imagine like every time you interact with an application what you do is you trust some information that is inside a centralized database that is completely closed so we have all of this beautiful thing about blockchain and decentralization but then at the end when you have to really interact with all of those contracts what you do is you trust Ean you go on like the page write contract or the project that you're using they use ether scan API to fetch the contract information so at the end there is this uh this elephant in the room okay that that is ether scan in the ethereum ecosystem but let's go let's dig a bit deeper into what is actually what does it mean to verify a smart contract so on the blockchain what you have is I don't know if you can see it it's if the resolution is enough but B basically this is just bite code so it's just hexadecimal code or bytes okay it's machine code that human cannot read and that's all you have on on on blockchain but then what you really need is source code solidity code or Viper code whatever because that's what human can understand human cannot understand by code itself so we need a way to correlate the sources and the bite code and that's exactly what ether scan does when you have the green ticks so when you go on a on a verified code on E scan instead of showing you just the bite code it shows you the the whole sources of the contract yeah it means you can it it means that in theory you can trust it so how do you actually verify it you start from the sources of course you need to have the sources in order to verify asart contract and you give your sources to the solidity compiler or the Viper compiler depending on what's the language of your smart contract and and also you have to give him give the compiler the right settings and after that you get the bite code that you recompiled okay so the next step is going onchain we are just using an RPC call and we get the bite code directly from uh onchain what we do we simply compare the the the two bite codes if they match if they're the same it means that the onchain code was generated using the sources that that we used at the beginning and how do we solve this problem so first of all as I said we are open source so what happens is we are for the community for example hash hashan is uh has forked us and now they have their own uh herera sourcify okay this is a way for for us of course to get a lot of feedback and for them to have a complete verification system for free but then also what we do is we publish every everything on ipfs so people can get all of these information of smart contracts directly from ipfs without having to call a centralized service such as Ean here I don't know if I have enough time I think so let's try to take a look at this okay okay so this is a small playground that we created to demonstrate how to fetch uh data in a decentralized way so this is the deposit contract on the ethereum main net and you can see how this contract at the end of the bite code that I was telling you before the the weird things that no one can understand uh there is actually an object encoded at the end and inside this object there's there is an ipfs link and the important thing to notice is that this is by default on all all smart contract after version 0.7 if they are based on solidity okay so all all smart contracts they have this ipfs Ash and if you go on apfs and you fetch that file what you get is the metadata file that I was talking about before and if you if you expand it you have everything you need you have the ABI you have the sources you have the compilation settings so there is no need at all to go on ether scan or some other centralized company to get for example the AI and that's crazy from my point of view because I think most of the companies that have an application that supports multiple contracts and you can just like give your contract and they're going to uh you can interact with the with the application on the contract that you pass the AI that they're fetching that that's what need to interact with your smart contract they're not fetching it in a decentralized way they're just trusting it scan they're just trusting a database okay let's go back sorry yeah yeah I'm coming there sorry um wait a second because I lost part of my [Music] presentation let's let's just do like this okay okay so uh some features of sourcify we support 170 evm chains and every day there are new chains that are adding their support to sourcify so basically if the chain is an evm chain then it's compatible with the sourcify and we are actually supporting like all verification method that you can imagine we have all uh we have plugins for all of the tools hard that Forge remix we are actually since we are in the ethereum foundation and remix is also in the ethereum foundation we are actually working for example on a on a new plugin that it will be the default plugin for remix in which once once you verify on ether scan you verify on every verifier including sourcify on AR that again in the default plugin you just have to pass the option uh s enable sourcify and it will be verified also on Source IFI without the need of having um an a an API token but we cannot solve this big problem just by ourself we're just three guys at the at the end so what we are doing we are forming a verification very fire Alliance and we have some pretty big names uh coming in there is block Scout there is Sam chisun we have tenderly Dora Routan and basically what we are doing is unifying all of the verification processes and all of the verified contracts inside a single database so we are working together to create standards to better verify and to fix ether scans problems because it's full of problems in the verification ecosystem and then of course we are also providing a database accessible by everyone that will contain all of our data coming from every verifier yeah so that's just what if we took all of our contracts and we put them in the same place that's exactly what's happening so um basically it works like this you can use your preferred uh verification system sourcify block Scout because for example on block Scout you have the block Explorer for a specific chain you can verify your contract directly using block Scout but then at the end the contract information is going to be sent into this shared database from which we all uh we all store verified contract information inside this database you have the schema here then I'm going to share a QR code so you can take a look if you're interested and also I don't know how te technical I should be with that but you have basically starting from the right you have all of the sources inside a table and you have all of the bite codes in another table and basically what it does is we have all of these other table that are basically compil contracts and deployed contracts that at the end they correlate the information of a source with the information of a bite of the bite code so you always have this correlation bite code Source basically this bite code is coming from this specific source and the while working on it we realized that it's not just important for smart contract verification but it's also a great uh knowledge base for everything regarding Every Chain because it's not chain specific so you can find all of the information from Every Chain into a single database and you can just run queries on it um we are actually uh publishing everything now on using U um Google services and so you you have also big query that you can use to to do Advanced queries on this database but we also because we are open source at the end we are also sharing a we are also sharing a regular parket dumps so you can just take the whole database and download it on your computer and you can do whatever and probably soon depending depending on our users what they will do with it we will probably have also some API or access directly to the database to simplify you the user experience and I think that's it I think I think I skipped your question I it was in the slides now oh no okay it's here so tooling around the standard sorry I didn't talk about that so one of the biggest problem of smart contract verification as you said is that at the end you always have to trust the person who created the the the the verification the verification itself so what we are doing is we are actually working on tools so that for developers it will be super easy to to do what we call um verif Edge verification so basically you fetch the sources from ipfs and then you recompile directly on your on your device and you get you discover by yourself if it works or not yeah so actually we did that with this other tool and uh I can have a museum of uh versions of Sals you have to support 51 version of Sals and you need to have 21 GB of disk space to install all this uh different version of salts and every version of salts is broken in its own different way so verification on the client side is uh I mean this is where we introduced a back end uh because it just impossible uh task because of this whole chronology so I don't know how long ago you tried to do that but now there are a couple of new projects that are very interesting in this way so of course the problem of having the compiler yourself it's kind of like a I don't know if it's a real problem like the final user doesn't want to verify every contract the final user probably will interact with some contracts and so they can simply download on the Fly the compiler from from what they need and the compiler is not that big and and once you have it when the single the single compiler not every version so once you have it then you can also throw it away after you compile uh the recompile the sources and this is the problem of the storage let's say and about the problem of the compilers themselves uh we we have also an open source library that that has a lot of these cases handled for each each of the bugs that you have in each solidity in each solid for each solidity version and these library is open source so you can also take a look at it it's on our repository and this is another um important standard that we have to um yeah that the verifier Alliance will will will create like how do you handle these bug cases for for each compiler like for example one year ago so if I was doing it in a way block Scout in another way but now we are all joining together to handle these uh special cases let's say in the same way and then I forgot if I did you say anything else or did I really okay okay okay okay okay so I I think that's it I don't know if you have another questions here yeah a question is about the Consortium the consor is is it open to accept new members or it is closed I mean the ver and I have also a second question is why why ipfs and not swarm we are also in uh so let's start from the first question uh in this moment we are actually accepting new members if we think that they can bring a lot of uh or like a lot of data let's say or new ideas and stuff like this but yeah we we are not closed so we are open to accept new members and the second questions reg uh regarding swarm we it's actually in our um in our road map to support swarm soon soonish let's say and the the the uh playground that I showed before uh in which you have the links embedded in the bite code those uh those structure uh Support also swarm so potentially you can also tell the solidity compiler to uh generate the uh hash for swarm instead of ipfs or to generate both so it's supported by solidity but right now in this moment we are not publishing every anything on on Swarm just for technical reason maybe we have time for one last question anybody has another question no then I guess we can all clap for you and Applause you for the speech you gave thank you thank you thank you thank you stano oh thank you Marco sorry