Weekly Sync Friction — the Most Important Blockchain Security Metric
In this post I will propose very clear metric how to define a security of blockchain, in minutes you wait per week to get synced.
There are 3 major ways to hurt a blockchain:
- Destroy it with 51% double spend (the easiest). Explained here: https://medium.com/@homakov/how-to-destroy-bitcoin-with-51-pocked-guide-for-governments-83d9bdf2ef6b
- Try to block it on transport layer with deep packet inspection and pattern analysis. It can be prevented by using encryption, noise, Tor and proxies. Even the Internet isn’t required — a satellite like one from Blockstream can distribute blocks to the whole planet.
- Attack infrastructure to hurt user experience. Let’s talk about this one now.
Blockchains must be able to function as a peer to peer network, with zero dependency to the cloud servers. Think laptop-2-laptop mesh. Once a peer doesn’t have a full node in their physical possession your blockchain becomes insecure. You will not immediately notice it, but then it will be too late.
Centralized nodes-as-a-service are no go — they are easily censorable. A cloud node that you “own” on your VPS provider doesn’t count either, albeit slightly better. Everything in cloud is highly centralized — that’s actually why the cloud is so popular and profitable, because it’s effective to centralize things.
Even light clients (relying on proof of work) are insecure by definition. We don’t see much bashing of light clients for one simple reason: no one figured out how to move payments off-chain and a compromised security is still better than nothing.
Btw when someone says light clients are fine it’s a useful sign the person is clueless so you don’t need to spend time talking to them.
Things like Coinbase or MyEtherWallet are direct opposite of what blockchains are about.
The only right way to use blockchain is to be a full node. That’s not negotiable. Everything else is a compromise on security and centralization. There’s no middle-ground for security here, it’s fairly binary. You are either censorship resistant or you’re an obscured Paypal with public transactions
Why are people not using desktop wallets?
Because UX friction. Namely, 3 kinds of them.
1. Initial sync friction
Can you imagine a bank or paypal asking you to wait for THREE DAYS in front of your screen to download BLOCKS?
So that’s why you go to a lightclient / web wallet instead. Because those are usable.
Good news are: initial sync can be fixed, if someone will ever explain to Bitcoin Core that it’s just fine to download latest UTXO snapshot because no matter what the bitcoin.org is the root of trust, and there’s no point to waste bandwidth to “verify” a chain with software that could be just as easily backdoored as the UTXO itself.
Also, I fixed this in my stealth blockchain using neat trustless install scripts that go with latest snapshot out of box — you never download more than 1GB (size of a DVDRip movie). Decentralized networks need decentralized install.
2. Key management friction
Blockchains are not inherently unusable. It’s their wallet developers who made them this way. 12-words-backup trick almost costed a guy $30k https://www.wired.com/story/i-forgot-my-pin-an-epic-tale-of-losing-dollar30000-in-bitcoin/ and tons of money lost due to poor UX of key management.
That can also be fixed by using a WarpWallet for key generation. People are remotely aware how to deal with username+password, yet they have no clue about 12 words, pieces of paper, or file.key they need to backup. Do not impose your own key management rules and use something they already understand.
3. Weekly Sync Friction
Finally — this is the subject of the post. Previous 2 frictions can be fixed without changing the consensus, but would involve a lot of explaining to Core people (which I have no interest in).
Blockchain is like an online game. Your goal is to have as many users as possible playing to get to the moon.
It’s easy to think that blockchains are about Bandwidth, CPU and Storage.
Wrong. There’s only one bottle neck — Bandwidth. Any kind of CPU is enough to process a bunch of DB manipulations and quick elliptic curve verifications.
Most modern laptops have enough storage to be a full node. And I’m talking about storing the last state (another anti-pattern is to store a full chain locally). 3GB for BTC state or even 20GB of ETH are OK-ish and don’t add much friction to my 256GB Macbook. (But Ethereum is certainly more bloated one)
You can buy better CPU/Storage and always have it where you go. However, you can’t buy Bandwidth so easily:
This is the Internet in a pretty good hotel in Berlin. Actually it’s like that in all hotels around Europe.
The Internet on this planet is shit, on average.
Blockchain users are often nomads or just well-traveled people. They need connection on the go, so “just buy a better plan with your ISP” won’t work.
So here’s a very simple metric how to measure sync friction (which directly impacts security of the entire network).
An average user opens their wallet once a week (to pay employers or do some transfers). While the blockchain is quite useless IRL you can’t request people to have the wallet daemon running all the time — you need to be as gentle as possible. Only later, when the blockchain has real world value, you can start requiring more resources and working in background 24/7. Not now.
The user is average, so they have an average connection. Which is according to Akamai as low as 7.2 Mbps https://www.akamai.com/us/en/about/news/press/2017-press/akamai-releases-first-quarter-2017-state-of-the-internet-connectivity-report.jsp — let’s round it up to 60 megabytes per minute.
Your job now is to engineer the network in a way that an average user with average Internet connection opens your wallet once a week and doesn’t freak out from a multi-hour sync window, deletes it and moves to insecure light/web client.
So, Weekly Sync Friction is defined as number of minutes it takes to sync with a week you just missed.
WSF of Bitcoin = 6(blocks)*24(hours)*7(days) / 60 = 17 minutes
Not so bad…
WSF of Bitcoin Cash (8 times bigger blocks) = 134 minutes
WSF of Ethereum = 1300 MB (per day) * 7 / 60 =150 minutes (yes, TWO AND A HALF HOUR. I bet even Core devs gave up syncing at this point)
And you can get these theoretical perfect-scenario numbers only if you’re lucky — normally there’s no incentive for anyone to spend bandwidth on sharing blocks with you (just like with torrents, very few people seed) so feel free to double or triple those numbers.
We proposed a very clear number that defines security of a blockchain for average user on an average world connection.
That metric is much easier to understand than things like “gas block limit” or “block size” or “total blockchain size” which all are somewhat vogue and irrelevant.
WSF is how many minutes you wait in front of your screen to use it once a week. That’s it. Decide for yourself what’s acceptable. For me personally— anything above 30 minutes are no-go. For most users — 10 minutes is a max. (That’s why in the project I’m working on blocks are capped at 600Kb + full nodes are paid and incentivized to seed at max speed)
Currently all blockchains fail this metric miserably — having a full node in physical possession has stopped being feasible few years ago. The entire thing is held together by a duct tape and security-through-obscurity.
While initial sync can be fixed with state snapshots, and key management can be fixed with WarpWallet derivation, the Weekly Sync Friction metric purely depends on the data you have to download to stay on the same page with others.
Only Bitcoin can be (if proper measures are taken by bitcoin.org) somewhat remotely usable with 17–40 minutes WSF.
Segwit2x is doubling WSF to over an hour, when we should actually 0.5x it to decrease it. So obviously I’m strongly against this move.