Comparing Distributed Ledgers by Game of Thrones Use Case — Holochain
This is the second part of our series “Comparing Distributed Ledgers by Game of Thrones Use Case”. To find out more about the series and the other articles of it, check out our intro article!
Holochain is a protocol to enable peer to peer applications. Other than in blockchain, holochain doesn’t provide a global consensus, but more a shared consensus between parties that interact with each other. Because of that, holochain doesn’t face the problems that blockchains face, like scalability or transaction speed. Each application powered by holochain, is itself its own network. So there is not one chain like in ethereum for example, but a separate isolated chain for every dApp.
To see the source code of our implementation, head over to our GitHub.
Technical overview
Each user is a node. Instead of sharing consensus about data, all the nodes share consensus about the validation rules of transactions. So the dApp is
basically a set of rules, on what kind of transactions are valid and what are not.
Each node stores a hashchain of its own transaction on his own device.
All transactions are signed by the nodes public key. To share the transaction headers and the transactions itself with the network, the network is organized as a distributed hashtable (DHT). The data (transactions or headers) is sent to other nodes, which public keys are similar to the hash of the data.
That way it’s possible to find and follow any stored data and to detect fraud, as well as not losing the transaction if a single node goes offline.
In the event that a node issues a new transaction, first the transaction gets added to the nodes own hashchain. Then, the header of this transaction is sent to several other nodes.
If the transaction is needed for interacting with the network, the two interacting parties also have to send the transaction itself to the network. As we can see, it’s not mandatory to share the content of the transaction if it doesn’t concern other nodes, only its header.
With this, it’s possible to store personal data with holochain without violating any data protection law, because transactions only have to be stored locally on the users device.
Example of double spending:
Let’s take the classical problem of double spending (a user issues two
transactions spending all his funds, though he could only spend it once):
Eve sends a signed transaction spending all her money to Alice to receive goods from Alice in return. Some time later, Eve sends another signed transaction to Bob, where she tries to spend the money she already sent to Alice.
Because in each transaction header the hash of the previous transaction is noted, Bob can look up the previous transaction on the DHT. In this previous transaction, the hash of the transaction before this previous transaction can be found, and so on. Once Bob finds the transaction of Eve to Alice, he knows that Eve in reality doesn’t have money anymore, and rejects Eve’s payment. In addition, he will show the rest of the network this malicious transaction signed by Eve, and every node will stop communicating with Eve because of this incident. This way, the network kicks out dishonest users.
One final thing to note: when a node goes offline, i.e. other nodes do not receive messages from this node anymore, they will mark it as offline. Transactions have to be stored redundantly on more nodes than a specific threshold of nodes, for example on 5 nodes. If a node goes offline, the network checks on how many nodes a transaction that was formerly stored on that offline node is accessible. If it is only stored on 4 other nodes, the network automatically copies this transaction to a new node, so that there are 5 copies again in the network.
Implementation
The implementation of our game of thrones use case, was done with the
help of holochains development kit (hdk) for rust. We followed the installation steps from the quickstart tutorial and developed our dApp with the help of the guidebook. If you never programmed with rust before, it is recommended to do a rust crash course beforehand, so you can differentiate between rust specific syntax and holochain specific syntax.
Holochain apps are made of one or more so called “zomes”, they are something like modules in javascript. Each zome provides logic. Every zome is compiled to WebAssembly, therefore one can write collaborating zomes in many different programming languages, and not only rust.
The zomes get compiled into a *.dna.json file, which contains the zomes code as WebAssembly.
To test this dna file, we used the node testing framework Tape.js.
Pros and Cons
Pros:
- Cool technology
- Scaleable
- Cheap
- Fast
- Not all data has to be stored on all nodes
- Privacy
Cons:
- New syntax to code zomes
- For some dApps one consistent state across all nodes might be needed (requires additional layer on top of Holochain)
Special thanks for answering our question in the holochain mattermost chat to @bierlingm and @pauldaoust!
Useful links to understand holochain:
block42 is a blockchain solution provider developing applications on top of most recognized distributed ledger frameworks like Ethereum, Hyperledger, Holochain and many more.
