Verifiable institutions.

Decentralizing our institutions is the mission.

Decentralization is good. Quoting Hayek:

If we can agree that the economic problem of society is mainly one of rapid adaptation to changes in the particular circumstances of time and place, it would seem to follow that the ultimate decisions must be left to the people who are familiar with these circumstances, who know directly of the relevant changes and of the resources immediately available to meet them. We cannot expect that this problem will be solved by first communicating all this knowledge to a central board which, after integrating all knowledge, issues its orders. We must solve it by some form of decentralization.

Blockchains are perfect for decentralizing finance.

Smart contract blockchains are good for decentralizing financial markets - compared to legacy institutions, they are orders of magnitude faster, cheaper, and more programmable. There are now protocols for the entire spectrum of financial markets - lending, options, etc.

However, we can’t stop there. We need planet-scale governance infrastructure, which includes credibly-neutral forums, chat systems, and voting that can scale into the tens of millions at least.

Capture-resistant social infrastructure.

What does it take to build a capture-resistant social app? Let’s start by using a blockchain. Users pay for tx fees, tx fees are extremely volatile, due to gas markets. Developers need to write their own indexing software. Eventually, they need to write their own off-chain database solution to scale further because blockchains don’t fit (due to throughput, gas cost, etc).

So the next solution is building something off-chain. If the app is off-chain, now you’re now hosting nodes. If you’re hosting nodes, you’re now liable. If users are hosting nodes, performance suffers and things become way more complex (e.g. doesn’t work for mobile, updating software, etc.)

The problem is we want a scalable database that someone else runs - not users, and not us - a database network. And that has the properties of blockchain - it’s decentralized and credibly neutral infrastructure. The solution is a decentralized database network.

On Blockchains vs. Databases.

Blockchains (as of 2022) are overkill for these social data. Forums and voting content can be stored off-chain, and any computation such as “collecting a post” or “tallying a vote” can be computed on-chain from off-chain data (which is becoming more efficient by the day thanks to STARKs). Paying for blockspace is overkill for social data, longer-term - we don’t want to pay for a forum post to be gossipped 100 times around the world by Polygon’s Matic. New chain designs (Aptos, Polygon Miden) can horizontally shard, which could reduce this replication cost. So technologically they may become cheaper eventually, however the economics are still unsuitable. Nearly all blockchains (aside from xDAI) fundamentally tie themselves to a base asset (e.g. ETH), which competes against reserve assets. Reifying a reserve asset is very hard, and the requirement of paying fees in this currency transfers exchange risk to users. Gas fees are highly volatile, and even if data is priced cheaper (multidimensionally priced gas), blockspace is likely going to remain a scarce resource affected by supply-demand dynamics.

Blockchains are also poor database products. There is no query language - first, you must write an indexer. Indexers are notoriously slow to sync, aside from the time it takes to configure the contract instances, develop and test them. If you write a custom indexer, it is even more work. In web2 databases, you have schemas and migrations. In smart contracts, there is no such thing - schemas are literally the data types written in the native language of the VM - Solidity, Cairo, Rust, Move, etc - and must be written again in JS for use in dapp frontends. There are no possibilities to run schema migrations, and even if a system were written, it would be too expensive to run due to gas. Lastly, interacting with blockchain storage is usually too granular to be cost-efficient for social datasets - writing, reading, and deleting data all occur as operations on words of 32 bytes (TODO: does this apply to Aptos/Sui).

Databases and blockchains in 5 yrs.

The holy grail for developers is everything on-chain. It’s the least complex form of development - instead of having a database and a backend, they are one. A database in itself is not just a storage layer - query languages involve some lightweight forms of computation (e.g. SQL SUM(*)). Databases can also support generalized computations (stored procedures), just as blockchains do.

One notable difference is that currently, smart contract blockchains all have heavyweight memory semantics - state transitions can modify any part of state, with ACID semantics. (1) Social data is usually agnostic to ordering (e.g. we don’t care our “like” was processed before our “create post” action), so it’s cheaper to avoid systems with this constraint. (2) ACID is inherently more costly in the byzantine model, since we can’t rely on trusting an atomic clock for ordering. The best-in-class decentralized clock, aka a sequencer, is Narwhal/Tusk and Solana’s Proof-of-History. (3) Blockchains aren’t built for “deleting data”. Although you get gas refunds and Solana has state rent, all things being considered, it’s impractical to delete a large dataset after you’re done with it, and you pay the lifetime cost of hosting upfront.

Databases optimized for specific types of data (relational, graph, key-value, spatial) will likely be developed quicker than blockchains can integrate those featuresets. Why? Because with heaps of money, people get lazy. And monolithic systems are much more effort to change.

Eventually, I hope to see the entire dichotomy fall away, thanks to ZK proofs. The abstraction will become a single computer, which can run an instruction set (RISC-V), which will have a variety of different database types running on top.