[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