LTO, Part II: Modularity vs. Analogy, or ‘Why not use HyperLedger?’

Part I: Intro:

For my second piece on LTO, I’ll be comparing their protocol and network to one of the more popular presences in the enterprise blockchain space — Hyperledger. I’ll first be providing brief descriptions of the technologies that LTO and Hyperledger (specifically Fabric) provide, then spending the final part on an analysis of when both technologies are useful and when one would be preferable to another. While I would normally go more in depth on the analysis, my personal life has been relatively hectic these past few weeks, so I felt it better to get out an accurate though short article sooner rather than waiting for a longer one to be feasible.

Anyway, without further delay, here’s a short summary of what I’ll be covering in somewhat more detail below: LTO’s network is built to allow for construction of near-arbitrary enterprise workflows, rather than specifying specific patterns of behavior — however, it is intended specifically for the domain of workflow reification and processing. In contrast, Hyperledger is intended to provide a tooling ecosystem for a far wider range of enterprise uses (including, e.g., payment processing and larger-scale supply chain formalization and protection) but not to allow much customization within that sphere — if you want to build something allowed by their ecosystem, then use it. If, however, you want to use blockchains to enforce a specialized workflow, then use LTO.

Conflicts of interest: This article was commissioned by LTO, who may be aiding in some of the LTO-specific use cases. Any contributions from the LTO team will be explicitly marked as such.

Part II: A general explanation of HyperLedger — Ease by Modularity:

So, as always, before getting into the differences between the two systems, I will describe each system in general, intending to provide an intuitive picture of the relevant pieces of information rather than perfect formal accuracy. Those who want more information are invited to check the hyperledger website, hyperledger.org.

Unlike many other projects in the space, Hyperledger cannot be succinctly described as a protocol — instead, it is intended to be a developer ecosystem/tooling ecosystem which is organized around a generalized ethos of ‘building projects for enterprise use’. Therefore, it’s not really possible to give an intuitive explanation of their ‘project’ without looking into the main projects listed on their site — so I’ll proceed to do that. The below are intended only to be short summaries of each project (as you’ll see, reader) to give an idea of their general MO for development. While the relevant comparison here is to Hyperledger’s Fabric project, most of their major projects have the same development ethos.

Sawtooth: One of the first projects in the ecosystem, Sawtooth focuses on building the infrastructure for companies to easily deploy their own distributed ledgers, focusing on making that deployment and implementation a matter of fitting different modular pieces together.

Fabric: This project focuses on building interfaces between lots of separate segments of the blockchain space (e.g. consensus) to make those libraries ‘plug and play’ for the people who want to use them without significant developer windup time.

Iroha: I’m not actually sure what this project is doing differently — it seems to be a blockchain platform intended to deploy in concert with an SQL database?

Burrow: This is a smart contract interpreter (think the EVM) intended to be modular so that any business can spin it up relatively easy.

I could go on, but I suspect the pattern is already relatively apparent — looking over the previous 4, the approach of Hyperledger is simple: they want businesses to be able to expand into the blockchain/DL space, but those businesses find it too overwhelming/difficult to expand into that space without risking the security and usability of their currently existing platforms. Hyperledger, therefore, is reducing that implementation difficulty through modularity — i.e. rather than having to choose among the massive array of possible implementations for blockchains to build your project, you can instead select from a smaller, known menu of potential options that are all built to work with one another, making it drastically easier to spin up your private or permissioned chain.

Now, for many cases, this is an excellent approach — however, it does fail in one case. What happens when the tools you need aren’t part of the modular menu? Of course, you can build them into the ecosystem eventually, but mandatory square-one blockchain development was exactly what Hyperledger’s consortium is trying to avoid! This is a general flaw in modular development — you sacrifice the ability to solve arbitrary problems for the ability to better solve some subset of those problems.

Part III: A general explanation of LTO — Ease by Analogy:

Now that we’ve explored Hyperledger Fabric’s model in general, we can move on to exploring LTO’s model. Rather than going in depth on their product, I’ll instead copy over the relevant text from my prior article on the project before getting into specifically the relevant parts of their system for this comparison (those who want more information should take a look at the prior article and LTO’s website).

“ LTO represents [enterprise] workflows as extended Finite State Machines [FSMs], with additional pieces to cover multi-party communications, and uses hamiltonian zero knowledge proofs (as explained in a prior post of mine) to verify to parties that the correct actions within a workflow have been taken without revealing sensitive data.”

Now, how does this model for development compare with Fabric’s model? It clearly isn’t based on modularity and on combined tooling — but, nonetheless, it seems to be doing something to ease development relative to typical Ethereum development. Take a careful look at that system design — as explained more in my prior article, LTO uses FSMs to represent workflows because, in several ways, FSMs are based on the invariants and properties that are typical of enterprise workflows (the constant number of known states, the constant number of parties involved, having a different workflow for each task, etc). Or, to put it in other words, FSMs are analogous to enterprise workflows.

Now, why is it useful to establish this kind of analogous system? Well, two reasons. First, because it makes it easier to spot illegal states of the system (illegal used here in the computational sense, not in the legal sense). However, that idea of making illegal states obvious/unrepresentable is something I’ve already covered. For this article, I’m going to focus on a design point — systems that are analogous to their purposes work well because the system model — the way the code works, matches the user model — the way we, as humans, expect the code to work. This sort of analogy and correspondence means that you don’t need to feed the user with lots of instructions about how to get subtle bits of your system working, or warn them about lots of unintuitive pitfalls. Their intuitions take care of that for you. (For more on the subject of user-system model correspondence, including UI focused examples, see Joel Spolsky’s excellent UI book).

So, intuitive correspondence and ease of design is the benefit of system design by analogy. What’s the cost? It’s actually quite simple — I imagine many of you can figure it out. When the analogy breaks down, you’re sacrificing power for no benefit. In LTO’s case, once you move outside the space of enterprise workflows that look like FSMs, you lose much of the intuitive design aids granted by the system design. (In other words, you’re now just stuck with a non-turing complete scripting language, with no benefits).

Part IV: When should you use modularity, and when should you use analogy?

So, we’ve now established the two development paradigms of this article’s subjects as two potential ways to ease businesses into blockchain development. On the one side, you have Fabric and development by modularity — making development simple by turning it into a plug-and-play like system, where building a chain is a matter of selecting the right options and tuning the right parameters. On the other hand, you have LTO, and development by analogy — making development simple by ensuring the properties of the system exploit that system’s invariants and that the process matches our intuitive models of workflow. So, I imagine you have one burning question: which should I, as an enterprise blockchain developer, be using? I regret to inform you, reader, that there is no simple answer. I can, however, offer a couple of heuristics for which to use when.

Heuristic I: Normal vs. abnormal tasks:

This first heuristic is the simplest — if you’re performing some well-known task like supply chain verification, where all the pieces have been studied and implemented before by others, Hyperledger is likely a better option since some module will likely fit into whatever you need done. In contrast, if you’re building for a specialized workflow (e.g. one-off contract approval, etc) you’re likely to have more success building with a specialized system like LTO’s.

Heuristic II: Speed vs Precision:

This next heuristic is less about the task itself, and more about the constraints on which you have to build. If it’s more important for you to get some sort of system out ASAP, and you care less whether the system matches your problem scenario as long as it gets most of the work done, you’re likely better off finding the closest hyperledger module or set of modules for your scenario. If, on the other hand, you can afford to spend a little bit longer on a purpose-built system, you’re better off building out a precise analogue under LTO’s tooling.

While I could give more heuristics, they all fall under the same lines — Modularity is good for ‘close enough’ builds that care more about ease of use, Analogy is better for builds where precision and ideal/close enough solutions are worth the slightly larger development run-up time. While, of course, this is an incomplete answer, it gives a good enough set of intuitions to be useful.

Happy developing!