Perspectives on Blockchains and Cryptocurrencies

Many are looking to the blockchain to solve many decentralization and consensus problems. I believe the infrastructure people are seeking is possible to build, but not in the way blockchain and cryptocurrencies have been approaching it so far. There are fundamental flaws to the current popular approach that will keep it from ever reaching the scale on which we need collective intelligence, currencies, sense-making and distributed computing infrastructure to operate.

Of course, this is why we’ve been building Ceptr - to provide the necessary infrastructure for these kinds of distributed systems. It solves all the same problems, but has been built from fundamentally different initial assumptions, so the more you know about cryptocurrencies, the harder it can be to understand why we’re doing what we’re doing.

I’ll start with a summary of highlights and then drill into greater detail in the next posts - providing some examples of ways to make these kinds of distributed applications and cryptocurrencies work on a large scale.

Cl says to H: How do I know you’re not double-spending that electron?

Stop the Nonsensus! (Nonsense Consensus): Systems will never scale if you require global consensus for local actions by independent agents. For example, I should not have to know where every dollar in the economy is when I want to buy something from you. That adds an overhead of ridiculous complexity to something which needs to follow the principle of pushing intelligence and agency to the edges rather than center. Likewise, an atom should be able to bond with another atom (see cartoon below) without accounting for the status of every electron in the universe. However, Bitcoin and blockchains are built around authorized tokens embedded in every transaction/record, which embeds unnecessary complexity and limitations for scalability into every interaction. Tokens are not what makes a decentralized system work, cryptographic signatures and self-validating data structures are.

**Intrinsic Data Integrity: **For a long time, data integrity has been conflated with the hosting, control, and access to the device on which the data is stored. So banks, for example, have used big firewalls to keep you from hacking in and changing your account balance. However, today we have self-validating data structures, like hash-chains and Merkle-trees, which leave evidence of tampering by breaking structural integrity, cryptographic hash, or counterparty signatures when the data is altered. This makes it possible to distribute the storage and management of data and ensure that the people holding it can’t tamper with it. In other words, you could be an authority to show your own account balance, yet not be able to tamper with your account history. When implemented properly, this is the key to enabling massive scales of storage and throughput by enabling auditable data to be stored anywhere/everywhere instead of requiring agreement on a single shared ledger.

Distributed Process not Consensus: Let’s learn a bit from tracking how scalable systems in nature and the real world get things done. For example, cells each carry a copy of their instruction set (DNA), rather than a record of the state of every cell. Similarly, speakers of a language each carry the means to generate sentences as needed, we don’t store every sentence ever spoken in some gargantuan global ledger. To build collective intelligence, what you need to distribute is reliable processing according to rules that have been reached by consensus – not try to establish consensus on every element of data. The data output from the process can be used to validate the integrity of the processing, rather than be the medium upon which processing is executed. When you start with a validated copy of a process, then you can proceed authoritatively, trusting your code to enforce the rules and produce valid output, without having to wait for the rest of the network to validate, verify and update itself with your state.

Agents not Coins: Instead of starting with cryptographic coins or tokens as the fundamental things that exist, start by having the agents/people/organizations (or their keys and account IDs) be the primary things that exist. When each person has a copy of the process needed to participate, and their records are stored with tamper-proof, intrinsic data integrity, then two people can perform a transaction without requiring the approval or consensus of anyone else. My process audits your transaction chain to make sure you’re in a valid state to proceed. Yours audits my chain. Either rejects the transaction if it puts someone in an invalid state according to the coded agreements. (I know, you probably have a lot of questions about how to make sure this happens reliably, but I’ll have to drill into that in a future post.)

Fractal not Global: You would think that the existence of the web would have taught us already that we can have shared access to pretty reliable, referenceable information without us all needing to have identical copies of it. Starting by creating a global ledger where each copy has to be in the same state is a totally different problem than having a fractal process for creating and organizing data which can be referenced by anyone, wherever that data lives. It can still provide globally accessible agreement about data, but that agreement is constructed from fractally assembled reliable parts instead of requiring each part to reach global (or majority) agreement to commit each element of data. One of the beautiful outcomes from this is such a massive reduction in the processing and storage requirements that it becomes feasible to run a full node on a mobile phone instead of requiring specialized mining hardware.

These cover some of the basic differences in the assumptions of how we’re approaching cryptocurrencies. I’m sure for some they create more questions than answers, so I intend to follow up quickly with a few more posts:

1. What does it take to implement a minimum viable cryptocurrency in this approach?
2. Some currency design basics: Crypto-geeks aren’t typically learning about advances in the field of currency design so they’re just implementing crypto versions of outdated currency designs.
3. How existing cryptocurrencies may not be as different from national currencies as we’d want them to be.
4. Beyond minimal viable, what does the full range of options look like for this alternate approach to crypto apps? (Varying levels of transaction enforcement, availability of data, redundancy, verification and validation, multi-state vs. single-state, etc.)