Verifier Alliance: inside of the contract verification pipeline by Rim Rakhimov | Devcon SEA

[Music] well hello everyone my name is R I'm a software engineer at box Scout and uh which is an open source box Explorer and today I want to invite you to try to verify a couple of contracts along with me uh let's start with answering the question what the contract verification is when you deploy the contract uh onto the chain it is represented as a number of bytes which eum v machine can understand and execute and where is where are no solidity of wiper sources stored inside the blockchain so when indexers uh index the contract data all way can see are those two bite code values which are contract creation code and contract R time deployed codes uh but most of the people are not good in understanding what the in understanding the raw sequence of bites and what we usually want to see uh what is represented in the picture below so we ask our developers to send those sources to us and we recompile them and check that those actually correspond to the onchain code values and this is the contact verification and today I want to to verify a couple of contracts with you so let's start with the simple one uh represented by those two code values here what do we need from the user to verify the contract first of all we need the source files themselves of course and let's assume that this tricky storage contract uh is our potential candidate uh it is a tricky just because it add some magic number before storing it inside the storage that's it uh also we need the compiler version which the contract has been compiled with and the compilation settings uh with all that information our next first step is just to combine all of that into the standard Json input format uh which has all information just in one file uh we submit this Json to the compiler and what it returns us back is the standard Json output which is um uh quite big usually but what is important here for us is that it returns to bite code values compiled creation and compiled CL time code values so what we have to do here is to just take those two bite codes and compare them do they match yep they matches so that's it uh actually is it always that easy to verify the context well let's look at a little bit more complex example here which is uh where we used as external library for making the addition operation and external libraries as the contact codes which are deployed once at some address and then our contracts can link where addresses in inside themselves and uh reuse where functions by delegate call up code so we will do the same Transformations as before and we'll get two up COD two bite codes as well but do we match well we can see that there is a strange not even a hex part inside the compiled creation code which does not M correspond to the onchain value so why it happens actually this is the place where the Library address should be put at but as we haven't provided it to the compiler during the compilation it just don't know what to put inside and uh uh Place some place holder instead so and our question is how to verify such contracts luckily for us there is a special section inside the standard Json output which is named link references and which for each unlink Library contains [Music] the some information how to where where this Library address should be placed inside uh especially is the first BTE where it should be placed at and its length which is always 20 bytes so what we need to do is just to take the specified offset value uh when take the next 20 bytes from the on chain code and the substitute it inside the compiled code so do those two by code match now yes we do Lu for us so here we are just verify the second contract for today uh in general such uh Replacements we name them code Transformations and those are some actions which may be applied to the compiled code uh before or after during the deployment process and which changes its bite code a little bit but which Remains the functionality the same and there are currently five of social such Transformations we know about and support uh and we talk about the libraries but where are four more we don't have time to talk about today but if you are interested you might just follow the QR link and uh see some more information about so also I think the last slide my presentation title was verifier Alliance the first part of it and uh I don't I haven't talked about that a lot but if you are interested in that part as well you may be you you're welcome to the panel which will take place today at 5:30 p.m. where box cloud Source f Road scan the members of this verify Alliance initiative will describe you this a little bit more and talk about verification as well thank you I think that's it thank you R do we have questions for Rim oh okay is this a mic too this is this is pretty awesome actually um why is it so difficult to have decentralized contract verification right we we use service Bo Scout ether scan but why after all these years is the experience still so bad in general uh well I think uh it happens a lot because you have to store this contct somewhere first of all and we sofware which tries to decentralize the storage process itself and uh but actually what is more important here there are a lot of different formats uh and uh all like different explorers use their own formats to store this data inside uh Source uses its own data and one of the thisy lines initiative's idea was to develop the schema uh we in which uh all contracts should be sted that and uh with that actually we are going to have at just one database of all verified contracts shared between different verification providers uh and I hope that will help to increase the decentralization of this data so we're going to share some Market dams for that uh op access to the database maybe and hopefully that will work all right shoots okay uh in the verification part for contracts that use Library looks like we are using the reference by code from the deploy by is that safe uh yes that is safe uh because after the compilation we've seen that uh this 20 bytes the as that the Library address was assumed to be put inside those 20 bytes uh by the contract code itself and uh this address can be anything actually so we just take uh the actual value so we assume that the onchain code is Al should also contain the Library address at this place and take it uh as uh as an well our address so it it's it's actually safe just because this offset was in the standard Json output section all right thank you so much for this session please help me appreciate our amazing speaker rain