Security
How EarthFast enables secure decentralized frontends
Last updated
How EarthFast enables secure decentralized frontends
Last updated
EarthFast is designed to be the most secure protocol for decentralized frontends, offering more security guarantees than IPFS and other existing solutions. Through it’s , it provides tamper resistance, transparent versioning, and protects against network attacks, and single points-of-failure.
When an EarthFast asset bundle is built, a hash is computed for each file in the project and all files are recorded in a manifest. The manifest along with the bundle are hashed once more to get a final hash where the bundle url and hash are committed onchain. You can see the code for this or try out the bundle creation using .
When a site’s assets are loaded, each piece of content is validated against the hash committed onchain. This means if a file does not match its cryptographic hash, the file will be rejected. You can see the hash verification logic in the service worker code .
Attack vectors mitigated:
Man-in-the-middle — Attackers intercept and modify content before it reaches users
Compromised node — If a node is serving malicious files that don’t match the bundle and hash onchain
EarthFast takes decentralization a step further than IPFS and other solutions with onchain versioning. Every update is committed to chain making it fully transparent and creating an audit log of updates. Ownership and updates can be controlled by:
An Ethereum address or smart contract
A multisig
A DAO (decentralized autonomous organization)
Or any other onchain entity
Attack vectors mitigated:
Unauthorized updates — If a malicious actor gained access to the team’s Github repository, they might be able to publish to Vercel, S3 or even IPFS. Without transparent version logs, this becomes very difficult for end-users to detect.
EarthFast can distribute content across multiple nodes, each independently addressable and registered onchain. EarthFast aims to be Byzantine Fault Tolerant and Sybil resistant, reserved nodes get compromised, the project as a whole remains secure and functional.
There’s also redundancies built in to prevent single points of failure. These can be especially problematic for decentralized systems where nodes might be unresponsive or at worst intentionally hostile.
Projects can use multiple domain and content nodes, which can provide higher throughput as well as protection against some of the network attacks as mentioned above.
In addition, this distributed architecture can mitigate DDoS attacks well. Each node in our network is provisioned upfront and dedicated, meaning you wont pay for traffic spikes. In addition, our optimized code + caching can serve thousands of requests concurrently.
Attack vectors mitigated:
DDoS — Nodes are dedicated to a project and are not charged by throughput or traffic served, so traffic spikes will not spike cost. In addition, each node can serve thousands of requests concurrently and not all nodes are required for every request so performance can scale as more nodes are added
Sybil attacks — Nodes and operators are registered onchain and must deposit a stake, so setting up fake nodes and operators is disincentivized
Malicious Node(s) — If one or a minority of the nodes for a project are malicious, the combination of content verification and required consensus amongst nodes will protect users.
While we’re making significant progress trying to secure this network, there’s a few challenges that exist in the web2 world that are still challenges, although we’re working on them.
DNS - If an attacker manages to gain access to DNS settings they can point to a malicious version of the frontend. To prevent this, we recommend something like 3DNS to bring DNS records onchain.
TLS/SSL - To make sites accessible by the every day user, having a domain that can be resolved by browsers is essential and that requires SSL termination. We’re exploring ways to secure this process for example with TEEs for decentralized certificate management and signing.