Kabuto + Hedera Consensus = real decentralized compute

LaunchBadge
Kabuto.sh
Published in
4 min readJan 23, 2020

Today we’re fortunate to see consensus as a service on a public network become a reality. I’m not sure this is getting enough attention because it’s a pretty huge deal, and I’ll explain why.

Fundamentally “compute” is taking inputs, processing those inputs, and rendering outputs. When you’re playing a video game, the game engine is taking a lot of inputs including your mouse and keyboard, in-game physics, network commands, and running those inputs through a process defined by some really smart programmers. That process renders outputs as images on a screen, audio in your headphones, and other outputs that will be used by the next process as inputs. This all happens really fast, but fundamentally, it’s input -> process -> output.

What happens when you have a bunch of people around the world who may not know each other and probably don’t trust each other but want to interact with each other? Enter “Distributed Ledger Technology”. Blockchain is included in this category. The goal of distributed ledger tech is to allow multiple parties to interact with each other in an environment where they trust the protocol and the code, but not necessarily each other. Up until now, most of this compute happens “on the ledger”. This means that inputs are signed by users and submitted to the ledger for execution. The ledger, which is a bunch of compute nodes with the goal of building consensus, is now responsible for validating those inputs, processing them, then rendering the outputs as data to the blockchain for retrieval. That’s a LOT for a blockchain to do. We see now that requiring every node in a distributed ledger to process the inputs and store the outputs is not scalable. Very quickly nodes run out of CPU cycles, memory, or storage, which can cause delays in processing and potentially a requirement to increase storage, which costs money. Some have tried to mitigate these scaling challenges by building side-chains, but then trust and security come into question. There seems to be a trade-off between performance and trust with blockchain.

This is not the case with Hedera. Hedera is releasing its consensus service, which approaches the problem of distributed compute differently. With Hedera your application implements one of the Hedera SDKs (Java, Go, JavaScript). The SDK formats and signs your “input message” and passes it to the Hedera Consensus Service (HCS). Hedera then comes to consensus about your message amongst all of the nodes then passes the finalized message to a mirror node like Kabuto.sh.

Applications interacting with Hedera Consensus Service via Kabuto Mirror Node
Consensus + Kabuto in an application stack

The SDK on your computer communicates with Kabuto.sh to retrieve the fairly ordered and finalized message. In this basic model, you can think of HCS as a decentralized trusted time-stamping service. This could be useful for auditable logging, regulatory compliance, or a variety of other use cases sensitive to public acknowledgement of some event.

But let’s think of this in a multi-party scenario. HCS accepts messages submitted to topics. A topic is a channel of sorts. You can think of it like a decentralized message queue. Multiple computers are submitting input messages to an HCS topic on Hedera. Hedera takes those messages and comes to consensus on the fair ordering and fair timestamp of each of those messages, then pumps those back to your computer through a mirror node. We now have a fair and trusted message queue as an input to our own applications.

Hedera Consensus Service takes unordered transactions from the public, orders them, and makes them available via mirror nodes
Ordered transactions from multiple parties

Let’s pause here and let that sink in. This is the important part I want to highlight.

If every computer runs the same deterministic processes with the same stream of inputs, the outputs will be the same.

Let’s follow the logic. We are all running our applications on our own computers. If we all agree to run the same processes and we all agree to run our inputs through HCS + Kabuto first to get a fair and consistent ordering of those inputs, then we locally process those inputs in that same fair order, we will all have the same outputs. The distributed ledger no longer needs to do the compute, our local computers take care of that. The ledger no longer needs to store historical data (inputs or outputs), our local computers (and likely mirror nodes) will handle that. We’ve just taken the burden of compute and storage off of the public ledger and let it do what it does best, calculate consensus (fair timestamp and fair order). Did I mention that this happens really fast? It happens in less than 10 seconds. And when it happens, it’s final. There is no chance of that message ever being pruned because of a blockchain fork or manipulated by faulty or nefarious leaders.

This is what decentralized compute looks like. The public ledger calculates consensus, but for it to be practical, the compute must happen off-ledger. Hedera achieves this in a unique and elegant way while preserving trust through a true consensus model.

LaunchBadge LLC and Kabuto are not affiliated with Hedera Hashgraph. They are independent from Hedera Hashgraph and self-funded. The views of LaunchBadge LLC or any official agent of LaunchBadge do not reflect the views or positions of Hedera Hashgraph.

Important links:

--

--

LaunchBadge
Kabuto.sh

California-based software development firm. Projects include: MyHbarWallet, Tagachi, and a Kabuto.sh