How Bitsapphire approaches Blockchains and Shared Ledgers

This post is intended for blockchain entrepreneurs, investors, and developers.

Don’t believe Blockchain / “Shared Ledger” hype. “Shared ledgers” are only edge use cases. Independently verifiable data is where the money is at.

At Bitsapphire, we probably talk to two to five founders in the Blockchain space every week. Since most of them are pre-seed or seed stage companies, we have to evaluate a lot ideas that are way-out-there. Based on our experience we’ve come to the conclusion that the vast majority of blockchain based solutions are simply ways of keeping track of changes to contracts.

The Bitsapphire model

At Bitsapphire this is our framework of looking at the Blockchain and Shared Ledger space:

• Blockchain state-networking (e.g. mostly consensus, but not exclusively)
• Blockchain data structure or Merkle DAG.
• Smart contracts, meaning, code whose state and execution is independently verifiable.
• Independently verifiable time keeping / state ordering

All of the above points are heavily interdependent. I believe this is partly why most people make the mistake of looking at “blockchains” as a magic black-box. Depending on the use-case, these features have to be combined differently. There is no one-fit solution for all use-cases.

Blockchain rules of thumb

Some of the rules of thumb aren’t obvious, but they can save millions of dollars. That is some serious cash for most startups and even corporations.

• Separate the above four features into distinct layers of your software stack.
• Keep the networking layer state-less.
• All states should be stored in a Content Centric Networking system such as IPFS or CCNx.
• The state transition should be performed by the ultimate “decider” of the state transition. Where the state stored is of little to no interest under CCN systems. It makes no sense for state transition to be performed out of context (e.g. Ripple gateway token settlement on the shared ledger; Ethereum oracle data, etc).
• Don’t hardcode the UUID generating hashing algorithm. Make that part modular and possible to use any hashing algorithm.
• “Shared ledgers” are just a shared, timestamped, and mutually agreed upon order of state. Almost always you should not share the actual state, only the order of the state of each participating “decider” (e.g. private blockchain). Only the “consortium” does the ordering of the state.
• Executable state (your actual smart contract) should be contained on a per-thread model. Keep the “blockchain business logic” as a smart contract itself. Turtles all the way down.
• Shy away from implementing the system in OOP, try building the system with a Static Functional Language.

Last but not least, we believe that the distinction between public and private chains will blur. Most private chains will cross-Merkelize neighboring chains, creating indirectly an absolute order of global state transitions. We are currently in the “AOL phase” of public blockchains, we believe the future will be closer to the Internet in that it will be a set of interoperable protocols.