The Ethereum DAPP “Cross-Pollination” Fallacy

While it’s cool to have so many apps running on some sort of “World Computer”, that’s kind of besides the point.
I started writing this post after Simon de la Rouviere, a developer for ConsenSys, and overall cool guy, posted this on Twitter:
---

A sidechain per dapp is a dumb idea. You don't get the synergy of cross-dapp pollination at all. No combinatorial explosion of utility.
— @simondlr
---

Simon’s tweet hit a nerve with me. I very much disagree with this idea that all “DAPPs” should run on the same Blockchain (which is just a state machine).

Blockchains, are just cryptographically linked and verifiable data packets. These data packets have the additional ability to tell anybody how to run them, as well as who has the ability to add new packets (new state) to this chain. The fact that they are today both distributed/decentralized from a computational as well as political perspective is rather a fascinating historical coincidence.

The fundamental added value of Blockchains vs traditional databases is that you can do Content Centric Networking (CCN) with them. They are super secure, networked, databases that can (but don’t have to) reference secondary logic which explains how stuff works (e.g. who adds the next block, who is an oracle, etc).

Here’s the kicker: the value of any particular blockchain derives from its referenced logic (who decides what gets included in a block), not the data stored on it. Blockchains are not useful for data storage and event communication (e.g. an oracle deciding what the exchange rate of some currency is, or who won the FIFA World Cup). Blockchains are useful because now, these oracles (which exist today in API form), can communicate new event/state to anyone via CCN. They communicate an endogenously created state.

Screenshot from the linked Ethereum DAPP list

Almost every useful DAPP on this list depends, mostly, on external oracles giving them data about external events/states. The one’s that don’t depend on oracles try to generate the necessary data through direct user interaction, which makes the blockchain events endogenous.

Mu (You’re asking the wrong question)

Instead of asking whether or not a “World Computer” makes more or less sense than a lot of “sidechains” per application, lets approach the question differently.

Mu (Japanese and Korean Seal Script)

The two points below are crucial to understand what I mean:

• Blockchains are really just networked databases that both communicate and store secondary logic and state;
• The vast majority of required input states for any DAPP are created and decided upon by external entities (which is currently done via oracles, i.e. “state deciders”).

Each oracle already is its own Blockchain. In Ethereum’s case they just happen to write to the same Blockchain, though they might as well keep track of their own Blockchains. The beauty of CCN is that fundamentally, everything is addressable in the same manner.
This leads to a very interesting conclusion. Since oracles are almost always politically centralized anyway, no mechanism to “secure” the blockchain is needed. The oracle is in charge of publishing new events forward-looking, the network overall can then assure backward immutability of these events through cross merkelization. As you can see, no tokens, mining, or fancy consensus is needed at all as long as all nodes use this protocol (which we call internally Pactum). This is a true protocol approach to blockchains, rather than a state machine approach as it is done today with Bitcoin or Ethereum.
Now, one might say that “Public” Blockchains still have the advantage of doing common computation across oracle chains, but in that case we’re just talking about a Dynamic Multi Member Signature (DMMS) oracle.

Examples

Let’s say 40 banks want to want to complete the settling process with each other faster.
Each of these banks would have their own centralized Blockchain, very similar to how they handle databases today. Now that they have these networked databases at their disposal they can securely reference each other’s databases cryptographically. They keep track of their own issued assets and contracts, and merkelize all Blockchains they interact with. That way they get immutability of data. All data is addressable via a CCN layer such as IPFS. The blockchain is really just a chain of merkle roots referencing the IPFS layer. So the

Blockchain is for event ordering and immutability, while IPFS is for actual state storage and communication. This order of events is in turn itself addressable as an object in IPFS and communicable.

Many-to-Many relationship

Because there are 40 banks involved, a many-to-many settlement layer would lead to a combinatorial explosion. At 40 banks that would be 780 connections!

One-to-Many

Instead, you would want a “consortium chain” which is really not much more than an oracle with a blockchain whose Members are all 40 participating banks. This would be 40 connections to the consortium chain. The oracle chain references each bank’s blockchain for their assets at each interval.

The role of this oracle is:

1. Do many-to-many settlement.
2. Merkelize the state of all member banks.
3. Assure state-finality by having all banks, sign all blocks at the same time. Banks don’t need probabilisticfinality.

Blockchain Interoperability

How are siloed blockchains aware of the state logic in each other? What if I want to implement prediction markets (using the prediction market blockchain) on DAPPs in other blockchains? And they need access to the other’s state logic, not just the information? — Simon De La Rouviere

Everything is CCN addressable: the state of each transaction, the code running the blockchain and the smart contracts, even the merkelized order of events (the actual Merkle DAG). The only thing needed to spawn, run, and inter-operate blockchains this way are:

1. A CCN system such as IPFS.
2. A contained environment to run arbitrary logic from these CCN packets (or a subscription to a certificate registry listing secure code CCN packets) — Very similar to how web applications run.
3. A standardized cross-merkelization method.

In-Depth Example

Let’s say you want to do the above example of a prediction market. There would not be a single prediction market blockchain. Any number of prediction market blockchains could exist. They could be anywhere on a scale from centrally validated, to consortium chains, to DMMS chains with PoW or PoS, etc. Somebody comes up with a prediction market smart contract, which people in turn fork and add other consensus/validation logic.

You publish the Genesis block of your blockchain which includes all arbitrary starting parameters (tokens, money to be used, registries, white/blacklists, ID verification if needed, etc), the prediction market smart contract, as well as the logic of the consensus/validation. You then send that Genesis block UID to as many nodes as possible to merkelize. You could potentially even reference the list of merkelization services in the Genesis block itself.
If your blockchain is centrally validated, then you can start adding transactions/blocks with new oracle events to your blockchain. If you need PoW, then you start doing PoW, it’s that simple.

Anybody can now access your blockchain state, all logic (run and verify it), as well as cross-check your order of events with other nodes which cross-merkelize your blocks.

Let’s say you have an insurance blockchain which used the prediction market as an input parameter. You would reference its external logic and state as an example with:

1. If [Blockchain Genesis Block UID] at height previous +1
   Check new state
2. If different from previous
3. Use in your own logic as updated parameter

In effect, due to CCN, all state is addressable as if it was on your own database. Combined with a VM or certificate registry you can cross-check any arbitrary state logic. You can chose to blindly believe the execution of any validator, or re-check everything yourself, or even delegate that task to a trusted third party. The sky’s the limit.

Conclusion

Public chains are an interesting idea, but have not been thought through yet. The future is most likely all about CCN addressability and mutually assured immutability. In a few years we’re certainly going to think about “Blockchains” very differently.