Introducing the Verifier Alliance (VerA)

Transcript

thank [Music] you so um hello everyone um my name is Khan and I'll be talking about the rify alliance today and as well as some info about sourcify the project I'm working on um sourcify if you haven't heard about it uh is a source code verification project uh it started at as a side project of the solidity team the smart contract language solidity and now we are on our own project inside the EF so we are a public good funded by EF let's say and not a not a company and so

on um right now we are yeah we are decentralized and open source smart contract verification service we are three people uh Manuel Marco and I working on it and as I as I said we are a decentralized and open- Source smart contract verification service um this kind of assumes there is another there is a counterparty to this that there is centralization and close sourness in in the ecosystem and it is because of yeah currently it's not descent it's because of this I guess everyone in our ecosystem so far knows ether scan and

these days I've I was I'm talking to some people and talking about source ofy and smart contract verification and a lot of people think ether scan is a public good and it is open source no it's not open source it's not a public good it's a insanely profitable business not that they don't provide any value I think it just can bring incredible value to the ecosystem and they they are just basically go to go to place to know what's going on on the Chain but still they company and they own all the data so our general thesis like what we think is this does not align with the ethos of the ecosystem before we go into what cifi

does and what the verifi alliance that I'm talking about exactly is let's recap what's smart contract verification so the problem the smart contract verification solved is that contracts on chain lives as a bite code so when you go on chain uh want to see what the code does this is all you get like the binaries the zeros and ones is all you get from a smart contract and this is obviously not human readable by looking at this you don't understand anything what your contract you are about to interact us and you are basically are

going to give money to this code so I guess you should know what it does or at least someone that knows what's going on should be able to look at it and I can say for example this contract is my source code like I can say okay that the the source code of this contract is this but then how do you know like how do you know this GitHub code like the code that I copy pasted and sent you is actually the code behind everything because it's in in reality it could be like stealing your money and or doing some other stuff at the end of today what we want to see is the human readable solidity wiper or other human language human natural

language written code and this check mark that is green and verified and this will make you happy so how does it work we first have the source code contracts contract source code in different files let's say we have these solid files here my contract Soul ownable ERC 20 in addition we have the compilation settings here it might be difficult to see but it's basically the compiler version the optimizer settings and other uh options you give to compiler that will affect your compilation and then we feed this into the compiler the solid

compiler and this gives us a bite code this gives us the bite code from these written cont contracts then we have a contract that is on chain that we want to verify so let's say we want to verify the contract at this address and the onchain contract itself also has a bite code so on the left side we have the one we compiled ourselves from our smart contract verification service and on the right side this is taken from the onchain data like this this what lives on chain and we compare it like do these bite codes match and if it's a match we say the

these files are the source code of this contract at this address so of course it's simplified but that's the main idea behind it and how does sourcify solve this problem how what is our approach as I said the current status of smart contract verification is closed source and the centralized so obviously the whole code of sourcify is open source and another thing that is possible is you can run your own sourcy for example this is Hash scan from the header chain it's the one of the most popular block explorers of haera chain and has can

haer itself run their own source ofy for example instead of instead of they writing everything from scratch they basically fork sourcify and and they are running sourcify themselves for smart contract verification so it's open source so you can both run your own sourcify and see what's going on and why it's not compiling why it's not verifying if there's a bug we can fix it together we can documented and it's publicly available secondly it's decentralized in the sense that it's served all the contracts we have are served on ipfs and ipfs also brings us a nice feature that we do something differently so besides the other verification

services sorcey does something we call a full or a perfect match which is the bite codes plus the metadata hash match what is what is the metadata what what I I talking about here so solidity compiler by default appends a special field at the end of the bite code so this this part is the functioning bite code and this one was added as a metadata at the end yeah and this this is a hash of metadata so the part here the black part is the functioning code so this is like what executes and the later Parts the last part is the part that does not

execute this is just metadata and this metadata contains something called solidity contract metadata so it's an ipfs hash and if you resolve it you get a Json file that contains basically two information one how do I interact with this contract the information like ABI user do Dev do and how do I reproduce this contract compilation so the compilation info and the source file info the file looks like this so you have the compiler version the language then in the output you have ABI user doc Dev do and below that you have the settings so the compilation Target the compiler settings part and below

here you have the source file info so you have the source names the source sometimes the source code itself can be embedded but also we have the ipfs hashes of the sources so the full verification then makes sure that what you see is 100% what was compiled so I'll go with an example how this work so let's say we have these contracts my contract all and I'm make a small difference in the contract I add a comment I change the variable name anything that does not affect the functioning code now we have this my contract. diff then the hash of this file will change

right because I as I said the source file also contains the ketcha cash of the contract the the source code and also like ipfs hashes so the hash of the file will change in turn turn the hash here will change inside the metadata file right and then in turn the whole metadata file has changed and the ipfs hash of this file will change so in this case the whole thing here will completely change so we say okay like this this part does not match so this this contract code you are seeing is different than exactly what it is um if you want to play around more about

what how it how it works and what it does we have a playground uh if you can't see this playground. sourcify Dev we have some example contracts and we break down everything that I have shown here in more detail so if you want to see contracts and how all this metadata hashes and everything works you can check it out there um yeah in short Source F now is supporting 152 evm chain CHS don't ask me what these chains are we just accept everyone if they want source code verification uh yeah you can see which chains we support on our docs page you can verify through our UI we have an API and you can also import contracts from

meter scan we have hardhead support So if you're using the official hardhead verify plugin you can verify your Source Code by enabling sourcify it's unfortunately disabled by default but we're we working on it um so you have to enable it if you want for example if you have a custom soury you can give the custom cfy URL and yeah on your local or somewhere else and you can easily verify your contract by heart at verify Network and the address uh there's Foundry support So if you're using Foundry you can pass the verifier sourcify flag and again if you have a custom URL on local for example

you can pass this info and this will send your contract to verification to certify and we also have a remix plugin but we are also now working on a new plug-in a unified verification plugin that will allow users to verify on all verifiers let's say you have a contract you want to verify it behind the scenes this will verify everything on ether scan on block Scout on sourcify because I believe like the contract verification should take place in one place only and it should just in parallel go to everywhere generally so we're working on a uh unified plug-in for all verifiers but we can't solve this by our

this is quite a big problem this we need ecosystem wide collaboration with this that's why we as sourcify and other projects started what we called the wfire alliance so with rout scan Sam is quite helped us quite a lot as well blog Scout sourcify tenderly Dora at the moment we have found this verifier Alliance to tackle the problem of smart contract verification and the openness of the data so in short verifier Alliance is an ecosystem Collective aiming for easy unified and open access to source code of evm smart contracts because as I've talked about the

problems currently it's closed Source the data is difficult to access and it's not standardized and what we want to do is actually a really simple thing we say like what if we took everything and put it in one place that's the basic idea is quite simple of course there's a lot of coll um coordination effort behind everything but yeah we just want to put everything somewhere and make it really easy to access and um open uh we have so the how it works is verifier aliance is not a verifier it's like a unified it's a place that your

verification goes so you have to go to a verifier you go to sortify you go to block Scout you go to um rout scan and you verify your contract there and your contract will end up in this shared database so everyone will like collect what what they have in one place and yeah this this data will be filled by these data providers and the database schema is also available at the our GitHub it's verifi Alliance database specs in short without going into too much detail it looks like this it's an SQL database which basically decouples the contract deployments from uh compilations so a a verified contract is

basically a association between a deployment a contract on chain and the compilation so we say this compilation matches this uh deployments so yeah as I said we decoupled the compilations from deployments there's a runtime code code match and there's a creation code match so runtime code is the code that is running on chain and the creation code is what's produced by the compiler so we can verify on those both and we normalize the bite code and add Transformations like what does this mean um the Transformations are what we call like are the edit on the on the bite

code before everything goes on chain so like things such as libraries immutables cber o data these are not the functioning bite code but other things added to the bite code let's let's let's give an example for example this is a uh creation bite code transformation because how do I know no this because it's a there's a Constructor transformation and this means a Constructor argument has been inserted like appended at the end of the bite code to the code so that means there's a compiled code and then on this compiled code we replaced the metadata and we added these Constructor arguments

at the end we have the code that we verify against so this is also a runtime code transformation here for example we have replaced a Library address a library contract that this contract uses or the immutable variable its value so we say for example for the for this case if this is the complation output of the runtime bite code you can see the Green Field is the Library address placeholder the what color is this like the the one in the middle is a im variable placeholder and this is the field I shown you on the met the metadata field

so the compiled output becomes this onchain Contra on the onchain contract so if we apply these Transformations the compiled output will become this and we say okay and this code will match the onchain code that that enables us to have a base contract and you can apply a bunch of Transformations on top of the base cont contract and verify different addresses with the same contract so if you if you deploy the same contract on a different chain with different values you can use the same contract let's say we have a Unis swap pool on different addresses so we can use the same base contract by applying different Transformations

everywhere yeah yeah and the normaliz of course I forgot the add display the normalization basically removes all these stuff so it creates a base base contract for applying the trans formations on top so yeah the the database right now has around 900,000 verifi contracts and it's growing um we um it's only it's not only a database it's also a shared knowledge place where all the verifiers can collaborate and um exchange information uh we want to have test cases we have to have certain edge cases tested and document the information the knowledge

generate basically and it's hopefully will be a place for tooling around the standard and the schema that we are creating and on top of the data like so many things can be done like this data is missing and both for data analysis purposes like you can do some security analysis when there's a vulnerability or for example what you can do is you can do a bite code similarity search for example if you have a contract on a on one address and it's not verified by looking at this database you can say say okay like this contract is 98% similar to this contract so it might actually be this one so you there's a lot of things that we can do on this data um yeah right now the datab base is growing we

really want to share this database publicly in parket format soon actually wanted to share it this week but unfortunately we have spoted a mistake inside the database so it's a bit delayed but really soon and maybe even in the future we can add an API or application access for people to just pull data but for now it's just a database and it will be just a databased dump because running an API a public API is a bit tricky it requires much more much more effort so yeah that's mostly it about the verify Alliance and the sourcify um you can check out the website and from the website you can reach uh the GitHub and the Twitter we also have a public chat Community chat

if you want to uh reach us out and yeah this is also how we can reach sourcify and yeah that's it from my side I'm happy to take questions a do we have any questions any questions well actually I do have a question sure I would like to know um because I can imagine there are cases where the verification can be super valuable so is there any incentive for the validators or to create a pool of validators specifically dedicated to the verifying contracts validators um

yeah the verifiers sorry so the verifiers are sourcify block scut and another block Explorer and what is yeah so um I guess I'm trying to ask like what was the in like how can we get more people to to be interested in this to maybe want to Fork you know what I mean other than just saying hey we need this but like what would be the incentive for for an ecosystem maybe Beyond just transparency I mean I think the basic incentive or let's say Force should be the community voice um basically the users the community members should be pushing these tooling and uh other people that have verified contracts to

contribute to this place and we also know who really you want to push this for I guess the our big guy and E can also would be nice to have but yeah basically just the community members should be pushing this and I don't I mean what I this this should be a natural thing to do because the source code verification is the basis of every single thing that we take for granted on blockchain like trustless open source um all of these things are based on the assumption that the source code is available and verifiable and I see it as an no-brainer that everyone should be opening up and sharing this data awesome

thank you hi so I wanted to ask about during an uh when you verify do you trace do you trace the construction transaction entirely and also compare since the Constructor doesn't end up on chain do you verify that it's identical to the one in the source code and metadata mhm yeah this is a good question so at sourcify we try to trace the RPC for the creation transaction if it's available at the RPC level like it's an archive node that we can look at the traces um but basically the problem here is the runtime code is onchain and it's

fetchable from an RPC but the creation code is not there and I see this as a centralizing force in the ecosystem because you basically need to index the chain for the creation bite code and that's quite difficult for doing for every single chain so what we do at least as sourcify is we check the transaction that created the contract and Tred to get the transaction do data like in the payload of the transaction if it matches the creation code but then also if we look if it's a factory contract if the traces are available and if not we just have to skip it and you know at least source and maybe I think BLX card does it probably

probably it scan does it as well but we personally as our project we don't index everything yeah I guess you would have since it could be a factory you would have to actually trace the transaction and see when the create or create to op code is being called you need to see what it is called with because otherwise you could have a a very similar but malicious Constructor let's say it sets something it back doors through the storage and then Returns the same code and then and the compiler would give you the same uh the compiler for the source code without the malicious version could could give you the same metadata like the correct metadata so I think the only way is really to trace to trace the op code the create up code H let's let's

discuss about discuss about this a bit more sure thank you awesome than you do we have a final question well if not thank you so much for joining us thank you [Music]