Improving Wallet UX and Security through Decentralized Metadata
ETHCC 3 · March 2020 · 27:32
Christian Reitwiessner examines how decentralized metadata can improve wallet user experience and security.
Speakers
Topics
From ETHCC 3, hosted by Ethereum France.
Transcript
okay hello everyone Oh everyone workout that's great my name is Christina right Wiesner I have been working on solidity with the etherium foundation since 2014 but this time I will be talking about a yeah different but related topic and this is a project I started maybe half an hour half a year ago about a decentralized metadata and source code repository but before we start with that let's actually do talk about solidity and especially the solidity summit we're organizing at the end of April in Berlin this is a gathering of people interested in the
solidity language and we will brainstorm and discuss language change proposals and things related to solidity like the lovely intermediate language fuel or debugger tooling and all things related to solidity I've heard from many people that they intend to come but they have not registered so please if you want to come go to the website and register so we have can have a better a better impression of how many people are coming okay now to the main topic of the talk yeah yes exactly
huh that's yeah I these screen shots are half a year old maybe so please excuse me I and it's just an example I've very much like ENS I think that's the best app on aetherium but I want to take this an example to walk you through yeah just standard interaction with a decentralized application on aetherium so usually you go to a website then you Forks yeah we want to register this domain on ENS so we get to this page where it explains us what we need to do and what the next steps are then we
click on request register then Mehta mask pops up or any other wallet you have and it tells us please confirm this transaction it will send zero ether but it will send a bunch of data and in this case we are notified that the function is probably called commit that we're calling and there is a bunch of hex bytes here this might be related to the name we want to register but it might not okay let's confirm that then we wait a minute and then we need to reconfirm the name this time again zero ether but a little bit more data and it's all in hex
we don't even know which function is called here maybe we can read some addresses here and some numbers there but it's very much unclear but still we confirm right because we're on the official website that should be the right transaction okay what what did just happen here we got this confirmation dialog and the first thing is we do not really know which contract we're actually interacting with so there's just a bunch of hex bytes and perhaps one thing to to clarify here this is neither the fault of the in s step nor the fault of meta mask this is a kind of systemic thing
that we're trying to solve once and for all here and so I think meta masks often resolves this address YNS and my guess is that this doesn't work didn't work in this example because it wasn't a test net and the second question is do I call the the right function does it actually correspond to the button I clicked on the website and what are the function arguments and I mean behind this smart contract there is a source code and it is kind of public but why is it not linked from this transaction here how do what do I need to know what what do I need to do to get to the source code
yeah and there is a solution to this problem and we added it to the solidity compiler in December 2016 that was quite a while ago the problem is nobody uses it we did that in the hope that the community would pick it up and implement the rest of the needed things but that unfortunate didn't happen and because of that we're doing it now so what is bytecode metadata if you look at the deployed bytecode of a smart contract it always has a bunch of hex data at the very end and if you take a closer look then you will see that
this is Seymour encoding of this structure here and it contains the the version of the compiler encoded in hex bytes or yeah byte encoded which is really useful even if even without this whole thing whenever you want to verify byte code I drop down box to enter the the compiler version is completely not needed because the compiler version is in the byte code and it's rather easy to retrieve and then the second thing is a swarm hash of another larger structure and current compiler versions use an IP
FS hash but yeah the type of hash use is actually not relevant and if you follow that hash we get to this structure which is the actual metadata or the actual thing we call the metadata it contains the full compiler version it contains the complete ABI of the deployed contract it contains the complete developer documentation also the user documentation which is sometimes called net spec and so for every function it has a string that should be displayed to the user when they want to call the function so in this example it's a function called Reynolds ownership and
the text says we're announcing ownership will leave the contract without and get continues with owner so this is actually what you want to see before you confirm the transaction that does this but this is not all it it gives on the next part are all the settings that are required to recompile the byte code from the source code so all the compiler settings optimize the settings EVM version and so on and it also contains hash links to all the sources so in this case it's both it's warm and ipfs and because all the settings and all the
sources are linked from this file and which is it again hash linked from the deployed byte code you can do something like the following this is a small tool we wrote half a year ago I think it's yeah the whole project we currently call sauce verify was looking for a better firm more catchy name and when you run this tool and you give it an address of a deployed contract and a transaction Paylor so this goes on here a little bit it starts by retrieving the byte code at that address then it already sees which compiler was used next it downloads the metadata from swarm so this structure I just showed you and in this structure
the sources are again linked why are high PFS or swarm so next it downloads these sources and then it recompiles these sources or it downloads the exact compile that was used to compile that contract and it recompiles the the sources and it does this to recheck that the bytecode and the source code belong together we already know that from the byte code from the metadata hash but the deployer could have changed the metadata hash before deploying and if we recompile then we know that it matches
both ways and [Music] and next it searches for the function identify their first four bytes in the in the transaction payload and checks which function is to be called and looks for this Nats back description I showed you earlier so what it could also do is decode the the integer argument here but we didn't implement it that far so and yeah to to say it again basically this this part in the middle where you recompile everything this is just an additional safety set but it's not strictly necessary you can just download
the metadata and look at the IBI directly okay nice isn't it so this is so this was basically a workflow how to show improved transaction confirmation dialogues but what you can also do with this is for example you have a transaction deployed on maintenance or transaction that has been running on main it at some point and you want to look at what actually happened there and if you have metadata and sources then a debugging tool can automatically download the sources of the contract the transaction goes to and it can recompile it and request more debugging information from the caller than just
the bytecode so it can use this debugging information to show you more data about the transaction and this is yeah without any user this should work without any user interaction if all the sources are available then people can also build yeah annotated sources auditing services on top of this basically a database of smart contract source codes with annotations and may be signed or this something like that and people are already building things like that yeah there's only one big problem it doesn't work and why does it not work because the data is not available so metadata is metadata and sources are
linked by a swarm and ipfs but if you take a look at IP FS and swarm at these addresses you will not get the data you cannot download it because neither swarm nor ipfs have a working mekin to keep the data available so and yeah keeping the data available is one of the problems and the other problem is that people just don't upload it in the first place so this metadata file is generated by the compiler and truffle also stores it as one of the artifacts but people still need to upload this metadata and if you only upload the source and not the metadata then this this link chain is broken so yeah how do we solve the first problem we have to convince all
the deployment tools to at least encourage people to upload the metadata and the sources or even to make it the default and we solve the second problem by the following idea so this is the kind of the project I'm presenting here ok this is a maybe a little bit complicated layout let's start with the thing called monitor service or let's start with the deployer let's start at the top the deployer compiles the contract and deploys it on chain and then there's the monitor service that continuously takes a look at the
blockchain and looks for newly deployed contracts and never whenever a contract is newly deployed it tries to download the metadata and the sources from swarm and here the deployer again is important because the employee needs to upload metadata and sources at the point of deployment it doesn't have to be exactly at that time but yeah I don't know + - 15 minutes as long as forum can keep it available if metadata and sources are available around the time of deployment then the monitor service will be able to pick it up and then this service pushes it to a recompilation service which does what i just explained so tree compiled from the sources and check that it
matches and if it matches it is permanently stored in some repository and this repository again pushes it to swarm an IP FS to make it available and yeah there's another thing called a pinning helper which synchronizes the database from the the painting service and also helps keeping it available and if you if you are too late if you didn't upload metadata and sources at the right time or if you want to get an older contract into this system there's also the manual input where you can just upload metadata and sources and then we will do the same thing we will recompile
and check that it matches and if it matches we permanently stored and here's a yeah first version of this repository or of the manual input interface of this repository you can find it at verification not computing dork with the written with the K computing with the K and so when you want a contract to be verified you only upload metadata and sources here the names of files are completely irrelevant the only thing that so it has to be exactly the same metadata Jason that was used when the contract was deployed and all the sources need to be there if there are too many sources it doesn't matter and
on at least four main it will also have a nice feature implemented where you do not even have to specify the contract address because when it can recompile the contract it will get the bytecode and it will just look for the bytecode will just look where the bytecode is on maintenance so yeah we just updated this I think three days ago we're really looking forward to your feedback if this is working or not yeah and you can also click on this link to browse the repository and then you get something that looks like that where you have yeah
all addresses and all sources and all metadata files this is of course not meant to target end users the idea of this repository is really just to have a repository where the data can be retrieved from potentially by other tools that build on top of this system yeah and my hope is that soon we will get from a transaction confirmation dialog like is it like it is shown on the left side to one as it is shown on the right side where it says you are calling a function called register with string name and you interation the name is meter - bouillon dot e if the
duration is one year and it shows your text description that says register the domain and then here the actual function argument is inserted meter - bill endured it for and again one year so the the smart contract source code will have a documentation that string that says something like registered the domain dollar name for dollar duration and of course we have the link show source here I am fully aware that people will not be able to understand the source but I think it is very important to at least give them the opportunity to look at the code if they want and people will also not be able to fully understand a smart
contract so they have to rely on the developer but I think they should have the ability to take a look if they want and this is this is a screenshot of an actual prototype of a Ethier iam wallet called wallet developed by Leakey maybe you know it and so this is a transaction that calls a function mint on on your C 20 token and it says it shows you the actual text description mints - token
for and then an address of course it would be nice to have an NS resolution for the address or something else or look at it in your address book so that you don't just see the address as a hex string here so I presented to you the system we're building but to solve the problems I mentioned the beginning we all have to work together on this developers have to use net specs so these documentation strings that are shown to be uses in the end and publish their metadata and the sources for the contracts deployment tools need to encourage users to publish metadata and sources or even make it
make it to default wallets have to use the API to decode call it a parameters and show the net spec strings and then also big organizations I would be glad if we get some help with ya hosting the data making it available on ipfs and swarm do I still have time to talk about future work yeah so what are the plans for the next months we're talking to the FBM team to unify the specification of the solidity compiler metadata yeah we want to extract something like the
verify data I showed you so that it is usable as a standard on npm module to just recompile smart contracts we currently use IP NS - yeah provide the entry point into the repository of all source codes and metadata and within your moving to e NS the downside of moving to any ns would be that it's more expensive to update the the pointer but the upside would be that it's much fun to look up is much faster so because IP nslookup it's really a pain we also want to provide our help to implement this for for bullets and then of course there's still a lot of
work to do on net spec itself yeah one example is that the or one thing is that the template language the the JavaScript string replacement language is not fully specified and yeah everything is currently in English I do not have a proper solution on how to make that available to people who do not speak English and yeah so when I said we this is Christopher a d-league II and Mark so big thanks to those for actually implementing it I just did the prototype in the beginning and if you have any questions or suggestions talk to us on kids I am /t theorems their sauce very fine yeah thanks a lot for your attention
[Applause] so are you keeping your own repository and where where can we see that so on verification or computing a dork yeah no we've metadata repository it's there it's there okay so I'm not made an estimation of how much storage we need but currently it's still working so can you put the link on the screen again okay
yeah we will have to find a better name for the project and maybe also better URL so I I guess for me Thomas for example to your system they basically trust that your repository is having the correct data so do you plan to have is taking mechanism where you can get punished if someone prove that actually the one you're publishing is wrong so Trust is not required here so you can have different levels of trust but because you can always take a look at the bytecode and recompile it from the source code you can always check whether
it's correct or not okay so metamath is going you you think they are going to do it either is it not too slow like I mean for every pop-up that come for a new contract or I don't know okay compilation yeah it depends on how which compiler use but it can be quite fast and so this is this is not a centralized source of information because everyone can just copy the service and do it on their own if you people discover that there there are incorrect entries okay just a quick suggestion or idea if you talked to either scan and seen if they could just give you all their verified source and
then just do all their contracts the problem is that ether scan does not store the metadata but you have the source code you just compile it and get the metadata current you if you can guess all the file names and the compiler settings and the remapping then you can get the metadata but usually doesn't work and also the so that the problem with ISA scan is they they say I hope there's nobody from it is gonna I really like it's a great service but and I also know that it's hard to do it right they say it's 100% 100% match but actually they ignore the metadata hash they ignore any non match in the metadata hash part which has as a
consequence means that you can get source code verified but it has completely different internal variable names and completely different comments than the original source and you also the the verify feature on ether scan it accepts the first match so when someone is faster than you they can just get incorrect source code verified I guess they change it later on but yeah that that's how the interface works so the question is is there a reason why they don't set up saw the metadata I think at the beginning it was easier to just ask people to upload the source
code and not also the metadata and then this just yeah kept they kept it like that and so the thing is we added this metadata feature to make it easier to do source verification because it contains all the settings required you you just use the metadata file and then you can forget about all the dropdowns and optimize the settings and compiler version and whatever but somehow it made it harder to fully verify it so that's the situation we are in now and I hope we can change this type I as I said asking deployment tools to yeah make people aware of what metadata is and where it should be published yeah would you like to replace not spec or it's
okay for you we have to fully specify it so I think the initial version just said oh yeah any JavaScript is fine inside that's back but I think that should be restricted and I mean there's also this read spec proposal but yeah I think this is a process that has to be done in parallel we have to make the net spec available and we also have to come up with a good specification of it at some time yeah okay thanks okay
[Applause]