Building Something Real on Blockchain

A lot of attention has been given to interacting with “things” using Distributed Ledger Technology (DLT). The use cases draw a lot of attention from media and from enterprise customers. Many of us were drawn to developing applications on DLT platforms because of the promise of a global trust layer. It turned out, for many of us, that building production-grade applications is nearly an impossibility with the existing tech.

Real-world application development requires three pillars: scalability, privacy, and simplicity. Without any individual pillar, application development becomes much harder and therefore pushes people down paths which do provide all three pillars (such as traditional compute or private DLT systems). All three pillars do form a spectrum however and each individual application will have different needs along those gradients.

First, let’s define those terms.

Scalability

Scalability is a vague term. Generally, your app has to serve the needs of your users within a timeframe they find acceptable. For most real-world apps, this means you can’t have users waiting 5-to-60 minutes for actions to complete.

Privacy

Privacy, in this case, I define as information only available to those that are intended to have it. Most real-world apps require some sort of privacy. For instance, you wouldn’t want to broadcast your entire supply chain purchases to all your competitors. That being said, some form of public data is also generally desired in real-world applications. For instance, being able to prove to a purchaser that your entire supply chain is sustainable.

Simplicity

This is probably the vaguest term in the list. However, I’m going to focus on developer simplicity here. Conceptually, it’s easy to frame a supply chain simply, but getting down into the details is where implementation becomes complex. I’m going to focus on the actual development here and talk about how builders can actually build something.

I’m going to pick supply chain as an example because it’s one of the most talked about applications of DLT systems. The conceptual is already getting pretty well defined in this space and many enterprises are already building PoCs or even entering limited production modes.

The Strawmen

I’m going to look at hyperledger and ethereum and talk through implementing a supply chain app.

The supply chain tracks ice cream from dairy farms -> factory -> wholesalers -> retailers -> customer.

This, highly simplified, supply chain can be a good illustration of the complexity of building up real-world tracking.

At any place in that supply chain, each actor (eg the retailer, the wholesaler) cares about the history leading up to its part of the chain. For instance, the factory cares about the provenance of the dairy and whether it was kept below a certain temperature on its way to the factory. The wholesaler cares about the factory and the handling of the ice cream *and* also the origin of the dairy used.

All the way out at the edge, the customer cares about a summary view of all of that data to indicate whether her ice cream was kept at the appropriate temperatures, whether or not the dairy was ethically sourced, etc.

Ethereum

Generally, real-world apps have focused on one of two directions for ethereum. Either the transactions take place off-chain (sidechains, stamping service, etc) or they use the emerging ERC721 standard to represent non-fungible tokens (NFTs).

Conceptually, the simplest way to represent our supply chain is to use distinct non-fungible tokens for each item in the chain. That’s to say that each dairy company would create a token for each “lot” of dairy they are handing to the truck and the trucking company would take possession of those ERC721 tokens and then either aggregate them into a new token (how?) or simply hand off all those tokens to the factory.

Or, perhaps, we could start the token at the truck and have a single ERC721 token for a truckload of dairy with information regarding which farms contributed to the milk in the tanker.

On Ethereum, a token comes from a smart contract. Either each trucking company has to deploy its own smart contract or has to rely on a 3rd party to deploy a smart contract. This smart contract needs to represent a bunch of data about milk so it would use the `tokenMetadata` field of ERC721 and link out to information. ERC721 itself doesn’t expose any way to update that metadata. You would need to add that into your own smart contract.

Confirmation times are over 6 minutes and each individual ERC721 token costs at a minimum $0.20 to deploy at today’s bargain basement cost of $100/ETH (these are generous numbers for ethereum). Any updates to the contract would take an additional 6 minutes and cost somewhere between $0.01 and $1 (most likely, on a normal day). Additionally, in order to produce or confirm transactions, ownership, etc, any producing or consuming client needs to be online and, ideally, there is a trusted full node for each individual party.

This isn’t an article about fully deploying an Ethereum solution, so I’m going to stop the description there. Hopefully, that was eye-opening enough to illustrate the process, costs, and complexity. In this situation, it is possible to keep some data private because the metadata is linked from the ERC721 token and can be kept in private storage. Long wait times and high price make the system prohibitive for the real-world and the complexity of deploying smart contracts makes it difficult to find agreement between all relevant parties.

Hyperledger

Hyperledger is more akin to a shared database with custom code than a general DLT system. Here is a good overview of the moving parts: https://hyperledger-fabric.readthedocs.io/en/release-1.4/network/network.html . In the most high-level sense, hyperledger is a system where parties enter into agreement that they will be part of a network. The network then keeps track of general “business objects” using custom code which can keep history and changes. Every part of the system needs to be defined by the participants as hyperledger doesn’t have any opinion on how data is stored or how transactions take place.

Jagrut Kosti, Porsche Digital Lab, once said: “If you can get all the relevant parties into the room to agree upon Hyperledger, you probably don’t need a blockchain.” Part of the reason for that might not be obvious on its surface: supply chains aren’t a single path from source to destination. Today’s companies interact in a variety of supply chains and so would have to participate in a number of different consortium chains, or develop an overarching system where almost everyone participates (much like a public blockchain). In our ice cream example, the dairy farms would interact with a number of different factories, etc and so would have differing requirements to interact with these systems. You end up losing a lot of the benefit of a common system if it is not actually common.

Just for completeness a very quick walkthrough would be: get everyone in the supply chain together to agree on data formats and code for interaction, a trusted subset (or everyone) runs nodes in the system to verify transactions and keep the ledger, some party writes custom code for interacting with the defined data structure and outputs are private so the end consumer has to trust the consortium didn’t mess with any records.

Tupelo

Tupelo is a public DLT system built for individual objects. Tupelo introduces the concept of a ChainTree which is an individual object that has ownership, ownership history, and arbitrary data associated with the object. Tupelo is built from the ground up to handle this kind of scenario. It features a simpler, and therefore cheaper, consensus algorithm with low transaction costs (currently modeled at $0.0008 per transaction). It’s also faster and supports offline capabilities.

ChainTrees are conceptually similar to NFTs on ethereum, but the way data is associated and updated with objects is defined. Additionally, ChainTrees are built into Tupelo and do not require smart contracts to deploy.

In the ice cream scenario, each individual party would take control of ChainTrees as they moved through a supply chain and build up a history culminating in a description for the customer that can be summed up as needed. The only thing the parties need to agree on is a way to transfer the private parts of the ChainTrees amongst themselves. Quorum Control is building one such service for private data interchange, and we hope that there will be many others.

So the dairy companies would produce a ChainTree for an amount of milk. The dairy company would transfer ownership of the ChainTree to the trucking company. Each truck delivery would have its own ChainTree which would embed the ChainTrees of each dairy lot, producing a single ChainTree with all of the dairy information. As the dairy enters the factory the truck transfers ownership of its ChainTree to the factory. The factory produces a ChainTree per tub of ice cream and transfers ownership to the truck delivering to the wholesaler, which could add information on the cold chain (the temperature of the trucks) as they are delivered to the retailer. Once at the retailer, each tub’s ChainTree has its ownership changed to the retailer which can then sell to the customer. The customer has a complete history in each tub all the way back to the individual dairy farm.

Those with access to a ChainTree can decide which information to make public (or not) but they cannot modify or add additional data unless they are the owner. Even the owner of a ChainTree can not remove history from an object (though they can decide how much to make available). In that way, the supply chain can present a public side for use by consumers, auditors, etc and at the same time keep a private side that they can use to transact with each other (for, say, customs documents, legal contracts, invoices, etc). The information is tamper-proof but does not have to be available to the consumer at the end. At any step of the way, it is provable that information is not available. In this simple manner, it’s possible to create complex rules around visibility, acceptance, etc.

Graphically:

Tupelo clients are straightforward and using tupelo feels a lot more like using an API than interacting with smart contracts. You simply run a transaction on a ChainTree. The list of transactions is quite small. Additionally, while the method of interacting with metadata is defined, the data is arbitrary and does not require agreement between parties in order to get started with a very real, production, application.

Conclusion

We’ve done extensive user research and we constantly find that nearly all projects involving “things” from CryptoKitties (digital assets) to real estate investment trust (REIT) management follow a similar paradigm to a supply chain. At any time there are owners and data about an object. Objects move from owner to owner and accumulate data throughout their life cycle. At times objects want to be completely public (CryptoKitties) and at times they will remain mostly private (my house and closing documents), but being able to trust that information hasn’t been tampered with, was added by the appropriate person, and cannot be modified creates a powerful framework for a new breed of applications. The kind of applications that the hype has been promising.