Towards Trust-Minimized Transactions and a Transparent Web3 / Franziska Heintel
EthPrague 2022 · June 2022 · 26:26
Franziska Heintel looks at why signing web3 transactions is risky, since wallets mostly show users opaque hex strings that hide what a transaction really does. At ETHPrague 2022 she argues that decentralized source verification and code commenting can make transactions more transparent and trust-minimized, and so help build a safer web3.
Speakers
Topics
From EthPrague 2022, hosted by ETHPrague.
Transcript
foreign I lined her up a few moments ago but now the time has come for Francisca heintel to come and talk to you about how we're going to move towards trust minimized transactions and a transparent web three please give it up for Francisca [Applause] okay hi everybody this is the time to come back inside I know you guys just went outside but like
yeah now is the time to come back inside to listen to my talk um yeah welcome everybody my name is Francisca and I'm with the ethereum foundation and today I'm going to talk to you about a trust minimized transactions and how we can create a web 3 experience that is hopefully more transparent and also a little bit more secure for the users yeah I sometimes when I do these talks I bring this very old cover from The Economist from 2015 where the economist called the blockchain the trust machine and I think we all have different ideas what what that can mean in terms of
trust listeners and cutting out the middleman on all these nice nice ideas about the blockchain but what I want to talk to you today about is is blockchain really trustless on all levels I think we also know the and out problems and all other things that can happen when we deal with blockchains and today I will be talking about the ux side of things and the the usability of of blockchain and if that really makes a trustless or not so yeah to dive right into the problem let's have a look at a typical web3 interaction how it could happen these days and find out whether that is trustless or not I hope these kind of screenshots are
familiar to you I took metamask but it doesn't really matter which which wallet you use and here we see in in several screenshots basically that usually when we are assigning a transaction we are presented with either a hex data so when I want to find out more about what am I going to sign so what kind of contract and interaction am I going to do I usually when I click on data or details I get presented with either hex data or nowadays some some wallets have integrated something that is called API decoding where you can see a little bit of information but it's not really I think in my opinion it's not relevant to an end user in that sense so for
example when I see something like function type Atomic match uh and yeah I mean you can read it for yourself I think this is not optimal when we really want to go mainstream full user adoption people that are not technically minded and probably don't even have an idea what any of this is about so yeah I think I've been giving these kind of talks now for over a year and web3 interactions nowadays are still a YOLO signing nightmare if you're not yet familiar with the concept of Euro signing it's basically you only live once signing which means you're basically signing transactions with a blindfold on you completely trust whoever is providing this infrastructure
to you that it will do the thing that you expected to do so yeah I want to ask you today what have we done and how do we fix this mess The Talk today is a little bit of a basic recap on how sourcify works and what the problem statement is and how we can as an ecosystem together approach it to solve it but then also I want to talk today a little bit about the big picture Vision how can we jointly push this to the next stage which is not only relevant for sourceify but basically all of the ecosystem partners that have to play together for this so yeah as we already saw in the other slide interacting with web 3 contracts currently requires kind of faith and
courage not sure if users would think the same because I think they just do it but there are tons of trust assumptions involved when we interact with web 3 at the moment just taking this as an example I see in the interface so on the in the web 2 space basically I see what I want to do so in this case I think I wanted to prolong yeah I wanted to prolong my ens registration for one more year this will cost 0.003 is and at the time that was five dollars and so basically then I would click in the web 2 interface I will click yes I want to be doing this and uh to this
point then in metamask pop-up or any other wallet pop-up opens up and I see this and now I think in an optimal scenario I could verify that what I had input into the UI in the web 2 space basically could verify that on the web3 front as well but at the moment that's not really so much the case um this is a little bit of an outdated screenshot so with this transaction insights feature that metamask has stripped it could be a little bit better but about these like slight differences I'm going to talk in a bit and so that is the point when this pop-up opens up this is the point where you should be asking questions
at the latest and these questions could be what contract am I even interacting with is this the right address are the function arguments correct is this thing doing what I wanted to do did anybody else who maybe has more technical experience than I do check the legitimacy of this and lastly can I consider this safe to use yeah I think this is something that we can fix as an ecosystem together and it's actually not even that hard but a lot of ecosystem players have to work on this together and currently it's kind of in this chicken and egg issue that yeah the ecosystem stakeholders don't really want to do the
first step so we are kind of in this blocked position but I think in the last year we've already made a huge Improvement on that front so if we now as the ecosystem together jointly continue to work on this I think it can really be fixed and it's not that hard yeah on that point I would like to introduce sourcify sourceify is a Community Driven project which is also inside the solidity team in the EF and uh yeah it's basically it's a lot of things on the one hand it's a little bit of infrastructure which I'm going to show you in a bit but it's also an educational initiative and we see ourselves as Bridge Builders who basically want to make aware uh or write raise awareness for the problem of
eulociting and all these things that are currently maybe not yet enabling a user powered web3 interaction and on the other hand we try to educate the the stakeholders and get everybody involved into solving the problem so what we do is enabling transparent and human readable smart contract interactions through automated solidity contract verification contract metadata and netspec Commons that's a lot and I will make it more easy to understand for you guys uh yeah so the overall goal I think can be described with this image we want to go from the left to the right or even a little bit further which I'm going to show you then in the vision ideas later but basically
what we want to do is really transacting translating this really cryptic content on the left side to something that is Meaningful to human on the right side without sacrificing too much on the security side of things and in order for this to work oh wow that is a big Emoji uh we need to uh a few components to to work together and that's why it's currently a little bit complicated so we need source code transparency and availability we need a source verification to happen we need metadata and netspec availability and then we need wallets and block explorers and front ends to basically leverage that and integrate with the data that is then available
[Music] and what do we do on the sourcify front to help enable the small transparent web3 future there's a couple of let's say a tech tools and infrastructure that we provide to make it easier on the one side it's a verification interface at certify.dev where you can do where you can verify your sources manually then we also have a contract repository of all verified contracts that is on ipfs we have a contract lookup interface for the contract repository which is also uncertified Dev slash lookup um yeah I think and then we have the monitoring and verifier service which is actually a quite cool thing so if you
are a developer and you ever try to verify your contracts on etherscan or other block explorers you know that it's usually quite the hassle you have to input a lot of things like the use solidity version and the compiler settings and all kinds of things but actually that's not really necessary so what we built here is an automated verification tool which really verifies newly deployed contracts on ethereum minute and test Nets automatically so there's no need for the developer to do anything in case they uploaded their source files to ipfs and that is because I'm not going to going to go into the technical details in this talk but
the idea is that the solidity bytecode has at this very end has a metadata hash which leads you which would lead you to an ipfs address if you would have uploaded the or it leads you to the address and then depending on whether you uploaded your source files or not they will be available on ipfs and in this metadata the solidity metadata is extremely powerful you already have all the information you need for example the compiler settings use the optimizer settings really everything you need in order to recompile the code and that's why automatic verifications aren't actually that hard and yeah for people that don't know what solidity contract metadata is about and
why it's extremely powerful we then also created the playground at playground.65.dev where you can basically learn about solidity metadata we have a couple of popular contracts there where you can just click on it and experience this power of metadata yourself and now I'm going to talk about a few of those different stakeholders or different aspects that we need to work together and explain them a little bit some of you may be thinking if you're not a smart contract developer a source verification or contract verification what the and why is it important and I think this is an educational aspect that we kind of either we have to do the extra mile to explain it to users
or we kind of have to abstract it away so that they just get a sign of a check mark or big X if it hasn't been done so contract verification is basically the process of checking whether the deployed bytecode of a smart contract equals the source code that a project has uploaded somewhere let's say I am uni Swap and I link to a GitHub repository and say here is my solidity smart contract code everybody can read it and then they also link to a Smart contract address and say here is the deployed code so in this sense in this case we couldn't yet see whether this code is actually the
deployed bytecode because the one is source code and the other one is compiled bytecode and so what you do with contract verification is you use the compiler settings that this developer has also used and you recompiled the source code that they claim is the bytecode and if it's a match that's wonderful because then you have basically the power to look into the contract yourself and check what is going on there there's of course not so relevant for the the non-technical end user but it is still super super important because transparent code is in my opinion friendly code yeah anybody can check the code and of course we have a couple of very brilliant developers out here so it would be quite the Bold move for
somebody to actively do an exploit or something super malicious in the open yeah so this already reduces uh the threat of something malicious happening quite drastically and the last thing is that we do things a little bit different than for example other means of verification like ether scan in the sourcify verification all metadata and comments are taking into account um you can also read that on in our documentation because I only have limited time today but basically this is very important when we now talk about the Second Step which is the code commenting in netspec but before that now taking all the
things into account that I just said imagine what developers could do without us having the slightest idea I mean it is already happening and I think we should really make it stop because there's really no reason why this is still the case I hope all of you now have this kind of epiphany moment and will help me spread the word about these issues so yeah what what is the Takeaway on this uh please never interact with my smart contracts that have not been published that have not verified their con contract code if you encounter a project that you like to use and they did not verify the contract please it's also up
to you to demand a verification to text them in their Community chat or GitHub or add them on Twitter I don't know what please ask them to do so and generally I think the the approach that we should take to this is really not open sourced smart contract code goes against the very idea of trust listeners then we can may as well go back to web 2 in my honest opinion so let's look at the second um part of this cluster metadata net spec availability I know that this is also kind of a mysterious thing for many people because we always use this name Nets back netspec is just a short form for ethereum natural language
specification format and in the end it's just code comments so it's comments that a developer can add to their source code which explains what this source code will do and there's different tags so you can add comments for developer specific documentation you can add comments for user facing documentation and that really you know makes the smart contract code a little bit more rich and this kind of comments we can then also use to in the best case display to the user at the point in time where they are going to interact with a smart contract and now we come to this kind of interconnectedness of all of these topics because Source verification is
great and code commenting is also great but really the only way how we can fully leverage it is if we combine the two of them because yeah if code is verified and open source but the end user does not understand it this is what usually sometimes happens at the moment it's not great there's not even an emoji for it but yeah that's that's not great uh because we don't know what's going on that's the YOLO signing scenario um in the second scenario end user understands it but the code isn't verified and descriptions could be inaccurate I mean that is even worse we don't want to trust any description of code that hasn't been open sourced and lastly when both come together the code is verified and open source and the end
users can understand it that's the perfect scenario that's what we try to achieve here this is just an example of how a netspec in code can look like this is the deposit contract and the developer of this contract I think it was uh no I'm not gonna to say who this was maybe the person wants to stay Anonymous but here basically we have the um the comments with all the different keywords so at def would for example be developer documentation and that yeah is done in the way how we would like to see it so what's the takeaway here developers please use netspec to comment your code and wallets uh please display the
NetSpend comments or verified contracts to the users please don't do that for unverified or not open source so where do we go from here uh that little picture you already saw this would be already a huge Improvement if we could go from here to there we would where we would really see uh what am I doing I am registering an ens domain for one year and basically the party in the description really shows it even for users that have no idea what they are doing and here we would even have a fully verified unsourcify or show Source option for developers or technically minded people that want to dig a little bit deeper
but since this is a solar Punk futuristic conference I also want to look even a little bit further into the future and want to present you with my personal wish list of how I think uh things could be even more helpful in terms of leveraging the data and I see there's like there's two layers and I would also be super interested in any ux research or any UI researchers that you know have ideas on how we could best abstract the information away or display it only for people that are interested in it but how I see it is basically on the first layer of information we should have the info on has the code been verified if yes please link to the open source verified code in a decentralized
storage let's not rely again on centralized Alternatives and then also the human readable meaningful code comments so that I actually know what am I interacting with here and then as a second layer of information now we can think a little bit more uh futuristic I think it would also be nice to just say something like how many times has this contract already been interacted with is this something that one million other users interacted with or am I the first one and then maybe also relevant when did this contract has been deployed so is it a super brand new contract or has it been there for years then decoding the ABI that's what I already touched upon a little bit that's basically what the transaction fee
insights feature of metamask currently does I think it's great but it's not solving the purpose for end users so this I would put in the second layer of abstraction and then lastly what we could also debate about is maybe including something like has this contract been audited and by whom but I have a to be discussed here because there's uh pros and cons about that but yeah imagine this if we had all this information at the point of signing we would not be blind signing or yellow signing anymore but we would actually take a informed decision about the contract interaction that we are about to do a couple of disclaimers and thoughts and I'm running short on time so I'm trying to run through them quite quickly uh yeah NetSpend cannot be formally
verified in that sense so any comment that you could you can put there could be malicious and that is why it is so important that the smart contract source code is open source so that other developers can look at it and also point out if there are any descriptions that are false or inaccurate the number of interactions with the contract can also add a layer of perceived security but on the other hand we know all of these things it's a crazy blockchain world are trickable as well if I have enough money I can just interact with a contract myself for one million times and make it feel more secure and lastly whether an audit has been done or not yeah it may add to perceived security but I think that is also something a little bit more futuristic
because we should also rely on some sort of reputation system for Auditors first or yeah there's definitely more more details to be fleshed out on on that point but uh yeah all of these are just ideas on how to make web3 less creepy for the normal end users to interact with and hopefully also contribute to a more transparent and overall more secure experience and we all know there's always ways to to trick the system but if we work together on this and if we just like Leverage the data that the blockchain and open source contracts are giving us I think we can already go a step further than where we are at the moment and lastly I think we really need this mindset shift still in web3 ux users are for the most part not
developers and they may not even be technically minded so please give them a chance to understand and verify what's going on without compromising on trustlessness and decentralization as our core pillars because otherwise we are no better than web 2. so yeah let's look at how this translates into actionable items if you are a developer and if you are hacking this weekend open source your code and make it available on ipfs comment your code using netspec use sourceify to verify your sources and metadata files and lastly if you're interested in that build Integrations or encourage other users or Builders to do so um how can you help I'm I will skip this
because I'm running short on time but follow us on sourcifies and yeah help us spread the word about the issues of YOLO signing and how we can fix it so thank you very much so sifi is here's all our contact details and we are also hiring we're looking for typescript developer so if that is you please reach out and scan the QR code or talk to me later and last but not least I'm going to hijack this session for a little announcement we are super excited that East Berlin will be back this year please all join us this is an invitation for all of you and now enjoy each product
[Music] just waiting okay thank you very much frenzy uh eth Berlin three that's going to be very very exciting okay do we have a few time for questions I think maybe some questions from the audience does anyone have any questions from the audience yes we've got a question oh two questions someone will come if you could stand up for the question that'll help us all be on the same level so just on hello yeah okay yeah so on a practical level uh how would retrieving that spec from contract when you're the user is interacting with the proxy yeah the proxy contracts are currently a
problem that we are working on so basically all the contacts need to be verified individually and uh yeah that that is an issue uh but it's on our radar thank you okay another question from over here uh do you somehow cooperate with the uh harder wallet producers in order to avoid the blind signing and to push them a little bit more to actually really show what the user is signing uh yeah I unfortunately didn't have time to mention all the cool things that are already happening so I now made it sound a little bit worse than it is there's a couple of Hardware wallets that are looking into various of these things and some are even already leveraging now the
specify repository and so um there's a keystone wallet which is already doing um great stuff into that direction we've also been touching in touch with ledger so it's totally on their radar and they are already doing quite uh nice experiments in that direction yeah okay and we've got another question from Makoto in the middle hi uh for that example you're using uh ens on metamask so for that to happen it's two players has to do that ens to verify on the sourceify plus metamask to do the integration is that what happened
okay yeah so metamask just has to ens has to verify the contracts on cersify and metamask just has to basically go the next step to also display Nets back and not only do their TX insights and we're in touch with them and I hope that eventually we will get there the second question so to verify the source code I'm actually from ens so I was just trying to verify that but does it have to be like in the website it says just upload a zip from the GitHub but it has to be the exact version of the time when it's deployed basically it has to it has to be the exact version there's two um ways or two verifications we say a
partial match if it's not the exact version that can happen when code comments have changed variable names have changed then it's a partial match and if you have the exact version it will be a full image so that is variable names are the same comments are the same everything is the same okay any more questions from the audience okay then perhaps I now this time say thank you very much for talking to us thank you and have fun foreign