Consensus
From PoW to PoS
Today, DeSo runs a hybrid Proof of Work consensus mechanism that allows it to use far less energy than Bitcoin or Ethereum while remaining secure against 51% attacks.
However, the core development team behind DeSo has invested significant resources into developing a groundbreaking proof of stake proposal that we expect to reveal in 2023.
Importantly, this proposal, like everything else with DeSo, will be especially well-suited to supporting the unique constraints of social applications.
Scaling Roadmap Overview
There are currently many different, and suitable, ways that the DeSo architecture can be scaled to support one billion users. Fundamentally, as long as the feature set is kept sufficiently narrow, with an intense focus on keeping everything as close to bare metal as possible, then most of the tools and lessons of scaling centralized social platforms like Instagram can be directly applied to scaling DeSo.
The above being said, we think it's valuable to provide a scaling roadmap with calculations so that blockchain enthusiasts can take comfort in the existence of a concrete path to one billion users.
Below, we detail a concrete scaling roadmap with four relatively straightforward phases:
- Phase 1: Proof of Stake
- Phase 2: Bigger Blocks
- Phase 3: Warp Sync
- Phase 4: Sharding
The math below walks through DeSo scalability at each stage:
1. Proof of Stake
- While PoS is not strictly required in order to scale DeSo, it is a top priority regardless, and so it will either precede or happen in parallel with the other scaling steps. It wil also drastically improve energy consumption, which we already estimate to be very low (~500 Kilowatts) in comparison to Bitcoin.
2. Bigger Blocks
The average DeSo blockchain post size is 218 bytes.
There are 10 other transaction types besides
POST, such asLIKEandFOLLOW. In a recent block, posts were about 1/3 of the total block size.The DeSo blockchain currently produces up to 2MB blocks every 5 minutes, as you can see from https://openprosper.com/deso-scan/blocks.
So it can scale to ~30 transactions per second, which is ~10 posts per second (= 2e6 bytes/block / (218 bytes/post * 60 seconds/minute * 5 minutes/block) * 1 post / 3 transactions).
If we increase the block size to 16MB blocks every five minutes, we can roughly extrapolate that it scales to ~240 transactions per second = ~80 posts per second.
For comparison, Twitter has approximately 6000 posts/second on average with 300M users.
So, at 80 posts per second, we should be able to roughly accommodate about 80/6000 = 1.33% of 300M users, or 4M users.
That’s where we can get with a basic block size increase alone. But we have a few other cards to play.
3. Warp Sync
With an Ethereum-like warp or snap sync, we loosen a key constraint, which is the need for all nodes to always validate the entire history of transactions. (You can still run an archival node, but this won’t be necessary for normal operations.)
As a concrete example, if all you're downloading is the current creator coin balances for each user, then all that user's trades are effectively compressed into a few integers because you don't care about the history (only the end state).
Instead, we move to a model where nodes by default first sync and validate a snapshot of the current blockchain state and then sync only a few week's worth of blocks on top of that.
Generally, the bottleneck to blockchain performance is validation speed. With DeSo, we've run tests that indicate a node running on an Intel Xeon E-2276M can validate transactions at the rate of ~12MB/s = 1.04TB/day = ~55,000 txns per second.
So, if we start by just downloading the state with minimal validation, how big can it be? To download 10TB at 10gbps = 10e12/10e9*8/60/60 takes about ~2.2h. To download 100TB at 10gbps = 10e12/10e9*8/60/60 is about ~22.2h to download the state.
With warp sync, the block size can be increased beyond 16MB because the number of blocks required to get a node up-to-date can be reduced to only one week's worth of blocks rather than the entire history of blocks from the beginning of time.
Let’s suppose then that using warp sync we increase the block size further to 120MB blocks. How many transactions per second (TPS) would 120MB blocks every 5 minutes facilitate? If we assume 218 bytes per transaction (which is what the value is per post), then (120e6 bytes / (5 minutes * 60 seconds/min)) / (218 bytes/txn) = ~1,800 transactions per second.
How much bandwidth would it take to synchronize one week of 120MB blocks appearing every 5 minutes, and how long would it take in wall clock time?
Bandwidth would be roughly (120e6 bytes/block * 1 block/5 minutes * 60 minutes/hour * 24 hours/day * 7 days/week) / 1e9 bytes/GB = 238GB/ week
- At the aforementioned validation speed of 12MB/s on an Intel Xeon E-2276M, it would take approximately 238e9 bytes/week / (12e6 validated bytes / second * 60 seconds/minute * 60 minutes/hour) = 5.5-6 hours to download and validate one week of 120MB blocks at a validation speed of 12MB/s on good hardware.
Under these assumptions, this means that the warp upgrade can allow us to sync a node in ~5.5h while maintaining 1,800 transactions per second (TPS) long-term.
1,811 tps vs Twitter with 6,000 posts per second and 300M users (assume only posts, no likes)
Users = 300M * 1,811 / 6000 / 3 txns per post = ~30M users.
4. Sharding
All transactions can then be write-sharded to make syncing a node parallelizable, thus providing multiple orders of magnitude in speedup. For example, we could do a very simple optimization, which is to shard all posts into their own sub-chain, and then shard other transactions across two of their own sub-chains.
This would result in a node being capable of syncing 3x faster, meaning that we could support ~90M users without an increase in sync time.
Ultimately, all transactions can be sharded into sub-chains by user ID, which would allow for virtually unlimited parallelization. For example, with thirty shards, we achieve another ~10x multiplier on the TPS without an increase in sync time, thus achieving ~1 billion users.
This number can be scaled further by increasing the number of shards.