Dapplets (part 1): introduce new Dapp architecture for better UX and security
Current web3 based architecture suffers from the “UX vs. Security” trade-off. Solved equally for all workflows, it leads either to poor UX or poor security. Another flaw: current architecture can’t reach existing legacy sites with millions of users.
The new proposed Dapp architecture solves both problems by splitting workflows into two groups: the “UX-focused” and the “Security-focused”. The former are usual Dapps running in the usual browser and the latter are Dapplets running in the Signer’s secure environment.
Find more discussions in the Ethereum Magicians Forum or on Telegram. Next: Dapplets (part 2): Implementation details and roadmap.
01. Identifying the problem
It is commonplace, that the current transaction signing workflow has major drawbacks. Let us review in detail what is broken.
By clicking the button “buy now”, the User has clearly expressed his decision to buy a Kitty. Nevertheless, the next step presented in the Signer is confusing: there is no Kitty to see at all, but the User’s confirmation is requested. What the User is missing here exactly is the set of data describing his Kitty fully. Later we will go into detail about what “describes” and “fully” means, but let us assume for the sake of simplicity, that our User expects to see Kitty’s image and its price to be able to confirm the transaction with confidence. Kitty’s image is missing in the Signer and it is unclear what the User is paying for.
Problem 1: WYSiWYS principle is currently broken: WhatYouSee is not WhatYouSign.
Another problem: We have no chance to buy a Kitty from some existing legacy site without web3 support. This is because now it is the Dapp’s responsibility to create a transaction. For the same reason, there is no way to start a transaction in Twitter — the site is unaware of Ethereum at all.
Problem 2: No Ethereum support for web2 sites like twitter.
This makes us re-invent the wheel and create a new social media like peepeth instead of twitter. This is bad because the idea of decentralization is not enough to make people move from Twitter to Peepeth.
02. Finding the root cause of problems we have
We had an idea of a Dapp as a website with web3 support from the very early days of Ethereum. The main argument for the architecture was the simplicity of development. Developers were supposed to develop the presentation layer for ethereum just as a usual website, while the web3 object was responsible for ethereum operations. It was a great idea, but with one major drawback…
… it did not work for any serious application, because
we have an immanent Trade-Off “UX vs. Security”
Even if we assume we can store our private keys securely in browser (which, as of today, is definitely not the case!), even if we assume the website is served from trusted cloud, like IPFS or SWARM (which is not the case for major Dapps currently!) any modern website with a focus on UX is far too complex and changing for a responsible audit. A website with dependencies to untrusted UI libraries and highly dynamic elements is quite risky to give any responsible assurance for the proper operation in the future. There is barely one auditor, who would put his money or his reputation on stake for it. While the smart contract audit became a must for any serious project, Dapps remain unaudited and untrusted and in consequence suspected to be vulnerable to various attacks.
Almost any project aiming for mass adoption sacrifices security for greater UX.
The mistrust against Dapps was the justification to use a Signer solving the trade-off with the focus on security (even at the expense of UX!). The Signer was considered stable, audited and secure enough to trust the presented transactions. It was a good decision, but it broke initial assumptions for Dapp architecture. Let see the picture for a detailed explanation:
A usual Dapp (like many web applications) has a View and a Model. A Dapp creates a raw Ethereum transaction from the Data stored in the Model stripping off all metadata and sends the transaction to the Signer. The Signer starts to recover missing information: it tries to guess a suitable Model for the Data and then guesses the View for the Model. It is obvious to see, that it is a mission impossible without external data sources because the necessary information is already lost.
We stripped off all metadata from the transaction in the Dapp and then trying to recover it in the Signer. It is crazy, isn’t it?
Currently, Signers try to utilize different registries and metadata stored in the deployed contract in order to recover Model and View but it is by far not sufficient.
03. Fixing the architecture. Introducing Dapplets
So the User would like to see the information about the transaction presented in the Signer fully and clearly. But what do we mean by “fully and clearly”? Well, it depends… It depends on both the User and Context.
Firstly it is worth mentioning, that parameters that the User would like to confirm are not always textual. The User may expect images or other media types too. If I would buy a Kitty, I would like to see it on my confirmation screen in the Signer, not just a hash of its image.
The view presented by the Signer to the User should be similar to Dapps because we compare it to the Dapp in the Browser. Let us give this special Dapp running in the Signer a name — Dapplet.
Dapplet is a trusted Dapp running in restricted environment of the Signer.
The second aspect worth mentioning is about the set of parameters presented by Dapplet in the Signer. We have assumed, our User would like to see a picture of the Kitty in the Signer because that is what he pays for. But other Users may prefer other parameters to confirm. For example, Kitty’s name “Moonrocket” may become popular and the User would like to see it in the Signer. It may be Kitty’s parents, it may be Kitty’s historical price: almost any parameter may become important for the User to verify the transaction.
The full set of User’s preferences is unknown at the time of contract deployment even to the author himself and may change in the future. It means, it should be possible to validate new Dapplets independently from the contract’s author and after contract deployment. A great example for such third party Dapp working on the top of existing contracts is the InstaDapp accessing CDPs and the MakerDAO system.
One thing becomes clear: if we supply the Signer with all the information, the Signer will be able to create the Ethereum transaction on its own. There is no point to let the Dapp create a transaction if we don’t trust the Dapp and prefer to use a Signer for transaction verification. We can just construct the transaction securely inside the Signer instead.
Don’t construct transaction outside of Signer. Supply the Signer with metadata and let it make the job.
Let us summarize: we should not give the Signer a transaction constructed by a Dapp any more. We should supply the Signer with all the information (metadata) necessary to create a raw transaction and present a meaningful View for verification and confirmation.
04. Dapplets and Dapps: what is the difference?
An attentive reader may ask what is the difference between a Dapp running in a usual Browser and a Dapplet running in a Signer? The answer is: the Trade-off “UX vs. Security” mentioned above is solved differently for both subsystems and it has consequences for all its components.
Usual Browser running usual Dapps is focused on greater UX at expenses of security. A Dapp may run on big size devices, which may be shared or used insecurely, the environment may be vulnerable to various attacks. Nevertheless, there are no critical workflows reside there, nothing can harm the User considerably. All those critical workflows are moved to Signer.
The Signer is security focused: Signer device should be compact, audited, personally trusted, with no unattended upgrades possible. A runtime environment is conservatively restricted. A Dapplet should be small and clearly, which allows sustainable trust by an audit. We can see Signer as the trusted browser (even very limited) for running audited and trusted Dapps (we just call them Dapplets in order to emphasize their specific nature).
In this new paradigm, a Dapp developer should separate critical workflows from not-so-critical ones. Critical workflows should run in Signer under all its limitations, but with maximum security, others remain in the usual Browser and may utilize the full power of modern hardware and technology.
I suppose many dapp developers will consider all workflows requiring transaction signing (write access) as critical and will move them to Signer. Read-only transactions (queries) may utilize TheGraph-like indexed services, which is anyway the better way to implement queries than pure web3 rpc calls.
05. Legacy sites
If we make the Dapp web3 agnostic, we could define Ethereum based operations and workflows on the top of legacy sites. All that we need is to collect and send to the Signer the context-dependent metadata required for transaction creation and representation. The website may operate as usual within usual security assumptions: all critical operations are fulfilled in the Signer.
A browser plugin is one of the possible ways to implement this approach. Let’s imagine a control button, injected into the twitter by that browser plugin and customized to collect metadata of particular tweet. Click on this button may utilize WalletConnect to send the collected metadata to the Wallet for further transaction creation and confirmation.
The example above (in simplified form) storing hashes of tweets in the chain, was implemented at the ETHParis Hackathon in March 2019.
If a Dapplet running in a Signer implements some standard workflow, it can be re-used by many websites without special Ethereum knowledge. This is another gain of the architecture. Only the logic collecting metadata, should be adjusted.
06. Other similar projects and researches
I know a few similar efforts trying to improve the current signing process. Here are some of them:
- (EIP-719) Trustless Signing UI Protocol
- (EIP-712) signTypedData
- EIP typed data translation
All of the proposals above are focused on the transaction. It means they are trying to recover the representation from the view attached to the transaction sent to the Signer. Some of the important challenges are:
- sometimes you need more metadata to represent the transaction clearly than the Signer is able to recover from transaction parameters. For example, an image of the Kitty is necessary to describe it, even if the image itself is not one of the transaction parameters.
- a contract is not only the source of trust for the View. Third party authors may create new representations at the later time for already existing contracts and the security infrastructure should support this approach. InstaDapp as the 3rd party Dapp for MakerDAO is a good example of this use case. Dapplets are flexible enough to support other sources of trust.
- a legacy site support creates a great business incentive for wallet developers to adopt the Dapplets standard. Adoption is the challenge, that other proposals are currently missing to solve.
A detailed comparison of assumptions made and approaches taken by other existing proposals for Secure Signing is a collective work and still to be finalized. You are welcome to be part of the work and I would greatly appreciate any links to other proposals missing here or if you point out any other challenges to be solved by the Secure Signing process.
The current signing workflow is in the best case either user-friendly or secure but not both. Introducing Dapplets we can have both great UX and great Security.
At the ETHParis Hackathon in March 2019, we have implemented a PoC adding custom ethereum workflow on the top of the twitter site. A browser plugin injects a custom control button into the twitter site. A click on this button initiates an ethereum transaction storing tweet hash in the rinkeby network. Browser and Signer are connected using WalletConnect.
We are looking for cooperation with wallet developers to implement dapplet support. Implementing Dapplet support will allow the user to interact with legacy sites that is quite unique and important feature currently.
We are also looking for cooperation with security aware designers to create a “sound and complete” visual DSL (domain specific language) to define secure signing UIs, where “soundness” is an impossibility to define a misleading UIs and “completeness” is an ability to define any meaningful one.