The Future of Ethereum’s Mist Browser: Layered Nodes and Beyond
The Mist team is proud to announce the long-awaited “layered nodes” release, which includes exciting new features in both Mist and the Ethereum Wallet. This post highlights those updates and explores what’s next for Mist.
TL;DR — Updates
- Layered nodes: connect immediately to Mist/Ethereum Wallet. Use a remote node while your local node syncs.
- Mist and Ethereum Wallet are updated to web3.js 1.0.0.
- Mist now serves the wallet locally.
- Ethereum Wallet introduces an auto-scan for tokens feature.
- Under the hood optimizations, including partial migration from Meteor to a React/Redux tech stack.
- UI updates throughout.
Where We’ve Been
Mist is sponsored by the Ethereum Foundation and has been around for a few years now. It was an important early piece of infrastructure for helping users visualize and interact with the Ethereum network. More recently however, many of the developers and users I’ve spoken to haven’t checked out Mist in “a while.”
The last thing they remember about using Mist is the painfully long time it took to sync a node before the application became usable. That, of course, is the design decision made within Mist. If you want to connect to the network, you do so through your own node. In a simpler time, that was a relatively easy task. These days, syncing the whole blockchain is a commitment, thanks to Ethereum’s explosion in popularity.
This trade-off is an important one to understand. When you run your own local node (e.g. geth, parity, etc.), that software is your gateway to the Ethereum network. In the case of Mist, a geth instance is first started in the background. Mist waits for your geth node to sync, then starts the application.
The benefit of using something like MetaMask (with default settings) is that you’re able to access the network immediately. The cost is that you’re connecting to a remote node. Using a remote node introduces new security concerns: an opportunity for MITM attacks and a single point of failure. If the remote node provider goes down or is compromised, you’re gonna have a bad time.
Many users I’ve interviewed would prefer to run their own node, but deem it impractical and settle for centralized infrastructure (i.e. remote nodes).
Where We Are Now
Over the last several months, our top focus has been an architecture overhaul which allows you to connect to the network immediately. We’ve tried to find the best of both worlds when it comes to the trade-offs discussed above: you may immediately connect to a remote node, but will switch over to using your local node as soon as it’s synced. If your local node ever falls behind, the remote node will take over again. We refer to this architecture pattern as “layered nodes.”
Since we’ve started this work, the geth team has released some massive improvements to their client. All sync modes are now quicker and less resource-intensive, but light sync is screaming fast. In most cases, we expect Mist users to rely on remote nodes for just a few minutes.
Great — the most pressing usability concerns are being addressed.
What’s next?
What the Future Holds
As an exercise, let’s extend the timeline and consider the Ethereum ecosystem a few years in the future. Could the best-case scenario for Mist be a graceful retirement in three years?
After a pause for dramatic effect, let’s take a step back:
Our goal is the success of Ethereum, not necessarily the success of Mist.
Mist is a tool that allows users to interact with dapps. It links wallets to websites. If/when Ethereum scales well enough to be adopted by a mainstream audience, major web browsers will have a huge incentive to integrate the same technology to help them compete for users.
Simply put, the Ethereum community will be better off if major browsers do replicate Mist’s functionality. The reasons are twofold:
- Building a browser is perilous, requiring significant peoplepower and security know-how. Mist is built with Electron, which leverages Chromium under the hood. Chromium benefits from Google’s security expertise, but there is always a lag between the time Electron updates to a new version of Chromium and Mist updates to the latest version of Electron.
- Major browsers already have massive audiences. Rather than require downloading a new program, meet the users where they are.
So, if we accept this potential outcome and eagerly work toward it, where is the Mist team’s energy best spent? We can work backwards and connect some dots. In the short to medium-term, Mist aspires to:
Introduce more users to web3.
Mist and Ethereum Wallet have over four million downloads across all versions and the wallet is downloadable from the ethereum.org homepage. We would be doing the ecosystem a big favor by delivering a stable application that provides a gentle introduction to this brave new world.
Following this release, user education will move up the priority list. As more non-technical users discover Ethereum, there’s a growing need to clarify Ethereum fundamentals as well as Mist’s role, features and how to use them. Greater focus on education and onboarding is an encouraging trend we’re starting to see industry-wide. One project to keep an eye on is Play, an upcoming version of Remix tailored to beginners.
Major browsers likely won’t adopt web3 technologies until they really blend in with the surroundings. The focus on user education will push us to try introducing and explaining the concepts in various ways, iterating based on user feedback.
Support the network.
A healthy and secure network is one with many nodes. Simply using Mist can be valuable to the network, given that you’re running your own node. We’ve recently updated the default sync mode to light, because it offers the best user experience, but we will need more nodes serving these light clients.
We would be wise to build UIs that encourage healthy network contribution. This may include nudging users to serve light clients if they have the resources. There will be opportunities to get creative here, as discussions evolve around incentivizing running full nodes.
Support developers.
Lessons we learn while building should be shared. This may be architecture patterns we can write about or npm packages we can publish. The easier we make it to contribute to or replicate our work, the quicker the technology can be adopted and iterated on — whether by browser vendors or other community projects. Worth repeating: our goal is the success of Ethereum, not necessarily the success of Mist.
Experiment.
This overlaps with previous points, but going further: interesting ideas are regularly introduced through the EIP process. Occasionally, Mist or the Ethereum Wallet are good candidates to prototype these new ideas within. I’d love to see Mist gain a reputation for being a place to try out the latest and greatest features.
Application security is one such area worthy of research effort. We see the potential to improve upon Electron’s security model; significant developer hours have been invested in prototyping a framework that reduces the attack surface of a dapp browser. Stay tuned for an update on that project within the next few releases.
The More Distant Future
So, is Mist going anywhere? No. [Update 3/22/19: Actually, yes. 😅] The point I’ve tried to make is that Mist is valuable to the extent that it propels Ethereum forward.
Mist needn’t compete with the Chromes and Firefoxes of the world. One opportunity our team is excited about is creating a pure web3 browser. Instead of serving http/https, a future iteration may restrict content to that hosted on IPFS and Swarm. While major browsers could also serve this content, having the pure web3 option is attractive for practical and ideological reasons (think: privacy, security). Elaborating on this vision is a good topic for a future post.
Bringing It Home
I believe the best way to make sure your work is meaningful in a rapidly evolving landscape is to stay laser-focused on your users. If you’re making their experience more intuitive and useful, you’re likely headed in the right direction.
Note that this requires knowing and understanding who your users are. In our case, we acknowledge that our user base has evolved from mostly developers to a more non-technical audience. In turn, our focus has evolved to think more critically about user education, verbiage, location of features, and so on.
There’s always more work to be done. Besides the backlog full of tickets, users will let you know what they’re unhappy with and every developer has their own list of items they’d like to get around to. Finding the bigger picture and working back from there has provided our team with a framework for prioritization.
Re: listening to our users — now you have the floor. Give the new release a try and let us know your thoughts. Mind you, we won’t have gotten it perfect on the first go; if you find a bug, file an issue. What would you most like to see in upcoming releases? What do you think the Mist team should prioritize? Do you have an altogether different “big picture” than I’ve painted?
