How the good parts of centralized systems can help decentralized systems strive
The economic system has been run for decades by centralized technologies (emails, APIs, CRMs, e-commerce, ERPs, SQL databases, cloud computing). Then decentralized technologies arrived, enabling safe economic interactions with anyone, even strangers you don’t trust. You just need to trust the technology. It’s magic!
Sometimes we can be so in love with this new paradigm to only conceive a parallel brand new world where everything needs to be decentralized because “centralized” is evil and should be avoided at all costs.
We are focusing on solutions that are maximally decentralized, which is good because it pushes us to build solutions that remove any point of trust. However, this radical approach doesn’t always let us appreciate acceptable compromises that could make these systems easy to use, efficient and widely adopted.
What would be the best way to leverage the full potential of decentralized technologies? Designing an economic system based on a tight interaction between decentralized and centralized components where developers and companies judiciously decide how to mix them depending on which components need to be trustless or not.
We think that the “Centralized custodial technologies” vs “Decentralized/Blockchain” antithesis will be soon a thing of the past. A third category is already dawning.
Following Vitalik’s classic framework, think for a second about a category of technologies which are logically, architecturally and politically centralized as the traditional IT systems but:
- are not custodial. They are centralized, but can’t steal your funds!
- are replaceable at any time.
- can fail, because a) You’re using many of them at the same time, since they are replaceable, so if one fails is no big deal. What matters is that at least one works or, to put it more simply, b) A low fail rate is acceptable.
At the end of the day, these technologies — “gluers” — don’t need to be perfect, nor trusted, nor fault tolerant, they just need to work. The reliability of the system is based on the sum of the components (trustless components + many gluers + the centralized IT you trust), not on the single gluer.
Simplifying a bit, Gluers read and forward signed statements from decentralized to centralized technologies or vice versa. A few examples:
- Relayers. They are not custodial. They only relay your orders (= signed statements). For example: the single 0x Mesh or state channel txs relayer can fail and is replaceable. But it’s fine, because you rely on the network as a whole. Relayers are gluers.
- Oracles connectors. Decentralized smart contract oracles rely on many single centralized oracle connectors sending to the contract signed statements describing the state of the world outside the blockchain. Any of these oracles connectors can fail, is replaceable and not custodial… they are gluers!
- Watch towers. They read signed statements (the Ethereum state) and send transactions (rising disputes) to the chain to defend their clients. You can hire as many watch towers you want, so the single one can fail and is replaceable. They are gluers.
- Gas station networks. They forward your signed statements and pay the transaction gas for you. You don’t need to trust the single relayer. You can switch when you want or use many of them at the same time.
- ZKP transactions aggregators. In Layer-2 scaling settings based on Zero-Knowledge Proofs, any aggregator node who knows the previous state, aggregates signed statements (transactions), creates a ZKP Proof of the new state, and sends it on-chain to the Verifying smart contract… is replaceable and can fail. It’s a gluer!
- Order matchers. The more off-chain order matchers you send your order to, the better, because you have more chances to find an order which matches yours. Order matchers are not custodial and can fail. If at least one order matcher is in good faith, you’re ok. They can be seen as gluers.
- State connectors (this will be huge!). Basic version: If This Then That tools reading from the blockchain and forwarding data to traditional centralized systems — APIs, email, databases, ecommerces — if a specific trigger is matched (onchain -> traditional centralized). Advanced version: If This Then That tools supporting onchain -> onchain workflows or even any mix of offchain (relayers) <-> onchain <-> traditional centralized workflows. Gluers²!
Gluers are that magic that will enable us to create an economic system based on an intensive interaction between decentralized and centralized components where developers and companies will judiciously decide how to mix them depending on which components need to be trustless or not. We believe that (also) thanks to gluers this industry will reach mass adoption.
- Centralized isn’t evil, if it’s replaceable and not custodial
- Let’s focus on how decentralized can help — instead of “defeat” — centralized. And vice versa
- Let’s think of centralized and decentralized as a single tech landscape and soon as a single community of developers
- Old fashioned developers are our friends! Let’s spend more time building tools to help non-crypto devs to access the decentralized world without having to fully understand it first (99% of web developers don’t know how exactly HTTP works. To scale Ethereum we should get to a similar point)
- Let’s legitimate Gluers technologies. They are efficient, secure, replaceable… and there is a need for them!
- Done is better than perfect. Adopted is better than 100% decentralized. Let’s avoid decentralization maximalism
- Let’s build stuff!
February 10, 2020