Ethereum Websites will Redefine Internet Security
2025 August 26
When you visit a website there's an unspoken agreement that the publisher establishes with you:
I’ll show you the right content — but I can change it whenever I want.
This is just how the web works today. Your browser resolves a domain through DNS, a centralized, but highly secure system with a fair amount of integrity (e.g. thepiratebay.org has not been ceased on the DNS protocol). The resulting IP-address is then used by your browser to make a request to a centralized server, and displays whatever content that server currently serves. The developer (or the hosting provider, or even a hacker) can alter that content at any time, with no public record of what changed or when. Individual server IP-addresses can also be censored by ISPs (potentially under government preasure, which is the case for pirate bay in many juristictions). Ethereum solves these trust issues by notarizing the fingerprints of websites on the blockchain. Each time the website changes content, this fingerprint also changes.
The Verifiable Agreement
The new agreement established by websites published with Ethereum would be something like this:
This is the exact content, provably so. If it changes, you’ll know because the hash and ENS record changed on-chain.
So how does this actually work? Ethereum websites uses ENS (Ethereum Naming System) as a replacement for DNS, but instead of pointing to an IP-address it points to a content-hash (fingerprint) of the websites content. This has a few important implications:
Explicit, verifiable trust: Content is linked to an immutable content-hash. What you see must match that hash, or it won’t resolve. This is similar to how HTTPS/TLS works on the web today where the DNS record contains a certificate (basically a public key) and the website server signs the content it serves to the user with the corresponding private key. The difference here being that with a content-hash anyone could send you the corresponding content, and you can verify that it's correct, where as a TLS enabled server could serve you whatever content it pleases.
Immutable by default: Any change to the website content results in a new content-hash. Nothing can be silently altered.
On-chain version history: In order to update a content-hash on ENS, an Ethereum transaction is needed — anyone can audit when a content-hash changed, by whom, and to what. For example, you can inspect the version history of this website (jthor.eth) here.
Shared/collective control possible: An ENS domain can be owned by an individual account, but more interestingly it can be a multi-signature wallet or other on-chain collective goverance structure. Website publishers can set up an arbitrarily sophisticated updating process for their website, such that it matches their security needs.
Distributed Distribution
So if an ENS domain resolves to a content-hash and not an IP-address (i.e. content location). How will the actual content be resolved if the user doesn't know where to look? This problem is solved IPFS (InterPlanetary File System), which is a peer-to-peer content distribution network. Given a specific content-hash the website content can be looked up and retrieved from any peer in the network that currently is seeding that website (similar to how the BitTorrent protocol works). Important implications include:
Anyone can be a seeder: websites will no longer be reliant on a single server to remain online. Anyone that cares about the content of a particular Ethereum website can start seeding it.
Resisting censorship: IPFS has demonstrated it's ability to give people access to importnat information, despite heavy censorship.
Accessing Ethereum Websites
Ethereum websites can be distinguished by the fact that they end with .eth
. Visiting them currently works a little differently from typing example.com
into your browser. Some browsers, like MetaMask mobile, Opera, or other wallet-based browsers, can resolve .eth
domains natively. They look up the ENS record on Ethereum, follow the content-hash, and fetch the site from IPFS. What about the average user who doesn't use a custom browser, here gateway mirrors provide the answer. Users can simply append .link
to the domain, e.g. jthor.eth.link. There are a few different mirror options:
- jthor.eth.limo
- jthor.eth.link - also operated by the eth.limo team
- jthor.eth.sucks
- jthor.eth.ac
- jthor-eth.ipns.inbrowser.link - experimental mirror that fetches and verifies IPFS content client side
The main drawback with these mirrors is that users now have to trust them to serve the correct content. However, since we still have the content-hash version history published on Ethereum it's possible for third party auditors to keep the mirrors in check and raise the alarm if they start doing something malicious.
Native browser support would still very much be ideal however. This was actually something that was being built in the early part of Ethereum's history, bring back Mist!
Challenges and Limitation
There are currently a few different things that website builders have come to expect that work a bit differently, or are current limitations with Ethereum websites. It's good to be aware of them:
Static-only: many modern webapplication rely on a technique called server-side rendering where parts of the website is dynamically rendered on the centralized website server. Since Ethereum websites doesn't have a signular server that is called to retrieve content this technique is not possible to use. Instead webapps served over Ethereum must be static, meaning that all content is retrieved and rendered client-side. This is a tradeoff with both upsides and downsides, experienced developers can interpret this as a challenge to build advanced webapps within this constraint.
Cost: current gas fees for one transaction to update an ENS record hovers somewhere around $1. For websites that are published infrequently this isn't that big of a deal, but for others it can definitely become a high cost. To mitigate this the ENS team is working on "namechain", which is an Ethereum L2 network which will make updating websites significanly cheaper.
Performance: IPFS content resolution can sometimes be slow or fail. However, this has been worse in the past and the IPFS team is actively working to improve this, shipping multipe improvements recently. Many times you won't notice much of a performance issue at all loading content through the eth.limo mirror.
Publishing your Ethereum Website
Launching an Ethereum website doesn’t require servers, hosting accounts, or DNS registrars. You only need an ENS name and access to an IPFS node (ideally running on an always online server).
- Register an ENS name
- Visit ens.eth and register a
.eth
name. - This name becomes your domain — you truly own and control it as an NFT on Ethereum.
- Visit ens.eth and register a
- Publish content on IPFS
- Add your website files (HTML, CSS, Markdown, images) to IPFS.
- You can run a local IPFS node or use a pinning service to keep content online.
- The result is a content hash (CID) that uniquely identifies your site.
- Link your ENS name to your content
- On the ENS website, navigate to your domain name and set the contenthash record of your
.eth
name to the CID from IPFS. - Now your ENS domain points to your decentralized website.
- On the ENS website, navigate to your domain name and set the contenthash record of your
- Access your site
- Anyone can open it via gateways like
yourname.eth.link
or in browsers that support.eth
resolution.
- Anyone can open it via gateways like
Simple Page - easily publish on Ethereum
If you don’t want to touch IPFS or ENS records directly, I've built a tool called Simple Page lets you publish to your .eth
name in minutes. I have another blog post that provides and overview of what it is and how it works.
Btw, this blog was created using Simple Page!
The Simple Page CLI can also be used to publish any static website directly to Ethereum.