This post is a response to the well-worded, thorough, and unexpectedly polite blog post by Moxie Marlinspike:

Taken at face value, I can understand why someone who is newer to web3 and the goals of decentralization would walk away feeling like it’s not on a trajectory to save us from the centralized world of web2. But I also think that there’s a lot going on behind the scenes which gives us reason to be more optimistic.

Overall, I agree with several of the main points of Moxie’s post. I agree that people will never run their own servers. I also agree that if we’re going to be stuck in a client-server model, we need to be adding more cryptographic verification to the requests that clients make to servers. I disagree that the future of web3 is going to be all servers talking to servers — especially in the past 6 months, our team has discovered several breakthroughs with respect to browser based peer-to-peer protocols.

Moxie brings up what is in my mind the most significant challenge facing web3: if we want to escape the centralized world, we need to make sure that the decentralized world is easier for developers and users alike. If the easiest way to serve NFTs is to throw them on an AWS server, developers are going to throw them on an AWS server. If the easiest way to track your NFTs is by using a closed source wallet, users are going to use the closed source wallet.

I am confident that at maturity, decentralization will be cheaper, more convenient, and easier than the centralized world we live in today. And though technically the blockchain has been around for 13 years now, the vast majority of novel ideas are from just the past 3–5 years, with many of those ideas easily 5+ years away from being implemented. The future of blockchain is a lot stronger than the present, so long as we stay committed to moving forward.

Improving User and Developer Experience with Decentralization

Users and developers alike prefer convenience to security. If we want users to prefer decentralized technology to centralized technology, we need to make decentralization easier and more convenient than centralization. We need to focus on the number of onboarding steps, and we need to focus on the difficulty of remaining a user once onboarded.

And while this may seem like a tall task for those familiar with crypto onboarding, I believe that decentralization has fundamental advantages with respect to onboarding, especially once you introduce a decentralized data layer.

Users on Skynet only have to onboard one time. Once you’ve created an account, that account can follow you from your chatroom to your blogger to your banking. Once you’ve uploaded a profile picture, every single app in the Skynet ecosystem can reference and load your profile picture, and you can use the same username across the entire ecosystem.

This works because the data is decentralized and owned by the user instead of owned by some central corporation. User’s don’t have to worry about being deplatformed, and developers don’t have to worry that an API is going to suddenly change or be disabled.

Developers also enjoy benefits in the decentralized world. Applications don’t have any operational overhead, as the costs are shouldered by the users and the infrastructure is managed by the network. The is no need to create AWS accounts or spin up dedicated servers, and no need to plan for a contingency of hyperbolic growth. The network automatically handles many pain points, and allows the developers to largely focus on writing features and engaging users.

For these reasons, I expect that at maturity web3 will run circles around web2 in much the same way that open source software runs circles around closed source software.

The Client-Server Model on Skynet

The vast majority of interactions on Skynet can be fully verified by the client. This is because most interactions on Skynet are based on public keys and hashes, and the client only needs a couple of stateless cryptographic primitives to verify that everything is in order.

The standard flow for a user on Skynet is to type their seed into a client. From the seed, a series of public keys can be derived, and then the server can be queried to fetch the latest state associated with these public keys. All of this data is signed by associated public key, which prevents the server from providing any false data.

Additional measures are taken to ensure that the server is providing the latest version of the data, mainly a combination of incentives (later versions of the data receive higher pay) and redundancy (many network actors simultaneously provide signed assurances that this is the latest version of the data they know about).

The one big thing that a user can’t verify without a full blockchain node is data custody. When you store data on Skynet, hosts on the Sia network are updating file contracts, and while a user can verify the signatures on the contracts, they can’t know that the contracts are actually published on a blockchain unless they are running a full blockchain node. For the time being, users are trusting the API providers to handle the file contracts for them, but even this is something we believe can be made trustless in the future.

As we continue to extend the APIs and capabilities of Skynet, we are committed to maintaining this client-side verifiability.

Trustless Browser Applications

Unfortunately, the native web browser is incapable of providing a truly trustless experience for users. Even though every API from a server can be cryptographically verified, a client can only properly verify those endpoints if the server gave them the correct javascript in the first place.

We can fix this however with a browser extension, and we’re working on one that we’ve been calling ‘the Skynet Kernel’. The basic premise of the kernel is that it will verify the javascript being served by the portal and ensure that the code matches what the user is expecting, eliminating the source of trust and allowing the user to get fully decentralized access to Skynet directly from their web browser.

As we built out the extension though we realized that we could build something a lot stronger and longer lasting. The fundamental idea of decentralization is that we are supposed to put the user in control, which should mean that the user can choose what code is running for their core Skynet experience.

For the sake of convenience, we wanted the user to be able to run their preferred code on every device, regardless of what browser they are using or what version of the extension they have installed. So instead of using a model like MetaMask where most of the meat is in the extension itself, we created an extension that is actually more of a bootloader, a minimum viable set of cryptography that’s necessary to parse the user’s seed, and then fetch and verify the user’s preferred full set of code.

Full Blockchains from Skynet

Once you start using decentralized storage to store things like the user’s runtime code, you realize that you can actually use it for a lot more than that. Including running a full blockchain node from inside the web browser.

There’s a bit of a caveat here, which is that the blockchain needs to have a concise state. Most blockchains today require multiple gigabytes of state to be able to make progress while verifying blocks, which isn’t tenable. But a relatively new technique for constructing blockchains called Utreexo makes it feasible to place the entire blockchain on Skynet and then verify it from the browser.

The main idea behind Utreexo is that you take the entire state and build a Merkle tree. Then the verifier only needs to know the Merkle root. Transactions are required to supply a Merkle proof that identifies the pieces of the state that are being updated. This increases the bandwidth requirements of an individual transaction, but reduces the hardware requirements to make progress on a blockchain to roughly that of a Casio stopwatch. Meaning that any device which the user has open to any Skynet application can be actively verifying the blockchain in the background.

It also means that a user only ever needs to verify the blockchain a single time. Once the user has verified a particular block or set of blocks, they can sign that verification with their own pubkey, allowing them to blindly accept the Merkle root as honest in the future when they load the blockchain from another device.

We get another excellent UX advantage when we combine the above techniques with Skynet’s social network. If a user has several friends that they trust, all of whom are claiming to have independently verified the blockchain up to a certain height, the user can safely skip verification, or at least delay verification and begin using the blockchain immediately. These ‘friends’ could also be trusted institutions such as universities. This allows the user to begin using the blockchain immediately, directly from their web browser.

A Bright Future for Web3

This of course is only scratching the surface. A lot of the current winners in the web3 space are the ones that rushed ahead with incomplete technology to grab as much market share as possible. But there is real technology and innovation behind the gold rush that far exceeds what’s happening at the top. And we have reason to believe that when that technology is mature, it will be meaningfully competitive, forcing those at the top today to either integrate it or be surpassed.

And we should keep in mind: we aren’t pursing decentralization for decentralization’s sake. We are pursuing decentralization because it builds a healthier, more competitive, less stifled, and more fun ecosystem. We are pursing decentralization because we believe it is fundamentally stronger. And if we are right, decentralization will win naturally, without us ever having to convince mainstream users that it’s the right thing to do.

This article was originally published on the Sia Blog.