We covered Holochain back in 2019, but since then the development team has completely rebuilt the platform, which they are now calling Holochain RSM (refactored state model).
Note that the underlying purpose of Holochain hasn’t changed, it’s just improved. Holochain still offers an alternative to the current landscape of bloated blockchains and imperfect solutions.
What is Holochain?
Holochain is being positioned as an alternative to the blockchain, giving developers a framework for creating decentralized applications (dApps).
One huge change to enable this is a switch from the data dependent blockchain to an agent-centric system. Holochain’s method avoids keeping a global consensus, using an agent system in which each agent keeping a private fork, and that is stored and managed in a limited manner on the blockchain with a distributed hash table.
This avoids scalability problems that have plagued blockchain solutions. It also allows any dApps hosted on Holochain to do far more with less resource than required for blockchains. In this Holochain review, we will take an in-depth look at the project, technology and token prospects.
Holochain is a framework for creating and powering distributed applications, incorporating peer-to-peer content distribution protocol, cryptography, and hash tables. It avoids scalability issues, and is extremely environmentally friendly.
We recommend going back to read the original piece before going on with this piece. It will give you the necessary background to understand the changes that have been made to the protocol, and how they make it even better. You can also have a look at the official Holochain explanation here.
Holochain Refactored State Model (RSM)
The new version of Holochain is a revision of several of the key architectural choices initially made for Holochain, with the older version now called Holochain Redux. In short, the codebase of Holochain RSM is simplified and it gives the network a huge leap in performance.
Here are some of the benefits realized by Holochain RSM:
- Holochain RSM with Wasmer runs orders of magnitude faster
- Holochain RSM uses less memory
- Holochain RSM compiles 1/3 faster
- Holochain RSM has much more maintainable code
- Holochain RSM is nearly ready now for the switch to full P2P networking
- Holochain RSM has improvements that simplify the work for app developers
- Holochain RSM integrates the capabilities model and is more secure
- Holochain RSM is more feature complete
The new features that have been added to Holochain RSM include random number generation, remote function calls between nodes using the unified capabilities security model, apps able to access system time, and user proofs when joining to prevent Sybil nodes from joining the network.
The changes were implemented back in September 2020, and any issues that were created for developers have been ironed out by now. Below is a deep-dive into the specifics of Holochain RSM that elaborate on how if differs from Holochain Redux.
Four Key Points about Holochain RSM
- The developers kept the RUST programming language for Holochain RSM, but they made it better. That means optimizations to improve performance which allow Holochain RSM to be the proper infrastructure for the P2P infrastructure needed for IOT. The majority of improvements are the result of a significant redesign of workflows Holochain RSM has its own ‘local first’ approach to state modeling and workflows.
- The back-end application code used for the Holochain RSM DNAs still compile down to WASM, but now it uses Wasmer to recompile to machine code for faster execution. This performance improvement now passes down so that developers can see it functioning in Holochain RSM.
- The networking used in Holochain RSM is now based on QUIC protocols. These use a single layer end-to-end TLS encrypted connection between nodes to deliver further improvements in performance.
- Developers will find Holochain apps are now easier to build. Besides simplifying the HDK, the Holochain team has also created a new API that can be used to bypass limitations in the HDK. Reports from developers indicate they are now able to create apps with roughly one-third the amount of code.
Now that you have the basics let’s move on to the details.
In order to guarantee the data integrity for distributed apps Holochain RSM needs to be airtight in terms of security. To reassure the developers building on Holochain the creators of Holochain RSM have taken solid measures to define all of the formalized elements used in Holochain RSM.
One of the primary goals in simplifying the codebase of Holochain RSM was to make it easier to understand. That’s not to say the original Holochain whitepaper and prototype wasn’t sound in principle. It was very sound and many of those same principles are used in Holochain RSM. The issue the developers found was that the principles may not have been defined clearly enough in Holochain Redux. So they determined to remove complexity and abstraction wherever possible.
That began with a rewrite of the whitepaper that paid particular attention to any places where confusion was present. That included such areas as transforming local chain data to sharded global DHT data. The formal whitepaper isn’t for everyone, but if you have the academic and research background necessary you will find clarity in the reworked document.
Concurrent Workflows with Atomic Transactions
The new design of Holochain RSM uses workflows to change data in particular stages of work such as integrating data, validation, gossiping, publishing, and authoring. Each of these workflows is limited to making changes only in specific stages of work where it holds responsibility. Using this design allowed the team to optimize Holochain RSM for concurrent processing without worrying about overlap in the way workflows change the cryptographic state of the chain.
This concurrency also gets a boost by forcing the workflows to use a scratch space when creating changes, and granting them read-only access to Holochain RSM while they are doing this. Then once the processing is complete there is a brief atomic write transaction to the data sources and a flush of the scratch spaces to get them prepared for the next change. Also, when multiple processes attempt to write to the source chain only the first one to finish is successful, while any others will then need to reattempt validation on top of the new local state of the chain.
One other benefit to clearly defining the workflow is to ensure that the chain functions on a local first basis. This allows Holochain RSM to change its local state and then queue the additional state changes for synchronizxation with the DHT when the network once again gains access to the local state. This all means that distributed apps can even function when offline or with limited internet connectivity. While offline operation remains out of bounds for now, it would be a natural fit for the agent-centric state of Holochain RSM.
A Tighter Tech Stack
Holochain is still written in Rust and it still compiles to Web Assembly (WASM). However there a lot of underlying components that were standardized to decrease dependencies and to align with the coding conventions of the wider Rust community. Many of these also make execution more efficient, and speed up the execution of code.
Tokio Futures: The unified tokio futures executor has allowed for the reduction in the number of required threads while still allowing for concurrency. However, because some actions cannot safely await a return from a future as they would tie up tokio’s threads for too long, Holochain uses tokio’s safe blocking for calling into WASM, I/O, and networking.
Ghost Actor: Ghost Actor is a small, lightweight, and simple to use actor library. It’s used in several places to make clean and efficient execution boundaries.
Lightning Memory-mapped Database (LMDB): The LMDB gives Holochain RSM a lightweight, super-fast key-value database that allows for unlimited connections, providing simultaneous read-access for the Holochain Content-Addressable Store.
Cascading State Engine for Content Addressable Storage (CAS): CAS provides consistent methods for workflows to interact with Holochain’s cryptographic state.
Strong Typing: While LMDB is able to store any value in its database Holochain RSM has taken the time to segment data into several different databases to have strongly types entries. This helps with consistent interaction with LMDB’s key-value stores through the Rust compiler.
Flushing Scratch Spaces: The use of a consistent process to perform atomic commits from workflow scratch spaces into the final cryptographic state gives Holochain RSM a consistent finishing process, while also constraining the scope of workflow changes.
Cascading Queries: With cascading queries workflows are able to reuse the data that may have been loaded or cached by another workflow. This helps to improve performance and increase responsiveness, while also protecting the workflows from the complexity of interacting with those layers.
Wasmer vs. Wasmi: One of the big changes made was to shift from the web assembly interpreter wasmi to the recompiler wasmer. This makes for much faster execution as wasmer recompiles to native machine code. Overall this shift provides many benefits, including faster calls, better memory management, and much higher memory safety/security.
WASM Caching: To reduce the load time for hApps running in WASM Holochain RSM added a WASM cache. This has lowered load times by 1,000x to under a tenth of a millisecond. It also allows for the sharing of cached WASM across multiple locally installed instances of an app’s DNA. This is especially great for Holo hosts who may be running many copies of an app.
Serialized Bytes vs. JSON: Holochain Redux used JSON for crossing boundaries between Holochain and other subsystems. But serializing, deserializing, and parsing JSON is notoriously inefficient, and it can lead to issues with double serialization and hellishly confusing payloads characterized by many layers of backslashed quotation marks. By switching to serialized bytes Holochain RSM now has a standardized interchange across boundaries with a format that is much faster, more consistent, and is type-safe.
Performance & Security Enhancements
As you can see from the above section, most of the performance enhancements in Holochain RSM have come from unblocked concurrent processing, or from optimizations related to WASM and networking. Below are the improvements made to improve the performance and security of Holochain:
Reducing WASM Calls: Executing code in Web Assembly remains fairly expensive for Holochain RSM in terms of cpu usage, memory usage, and time even with all the optimizations that have been made. In order to improve on this further the team has reduced the number of times Holochain RSM needs to spin up WASM by allowing Holochain RSM to access some of the application code definitions outside WASM. This allows Holochain to make the determination of whether it actually needs to spin up WASM or if it can simply make a call back into WASM.
Native-compiled WASM Performance: By using wasmer to recompile code and run it as native binary code Holochain is improving on execution by roughly 1,000x compared with running interpreted bytecode. It also manages a memory cache for the compiled code for ultra-fast execution. To ensure the compiled code hasn’t been tampered with Holochain can recompile from the hashed WASM code at random intervals. By using wasmer calls to app functions now execute in under 0.1 milliseconds, compared with execution speeds of up to 200 milliseconds when using wasmi in Holochain Redux.
QUIC Protocol: The QUIC protocol was developed by Google to speed page load times in the Chrome browser. It uses UDP rather than TCP/IP web socket connections, and this allows for multiple simultaneous bidirectional exchanges. It also prevents the type of blocking where smaller messages get stuck in line, waiting for the larger messages ahead of them to finish. And, after the initial TLS handshake between peers there is no additional setup time required for future encypted transactions. All of which leads to faster transaction times, particularly on congested or unreliable connections. This makes QUIC better for wireless usage, which is the vast majority of end-user connections these days.
Proven Crypto: TLS is considered the standard for end-to-end encrypted communications, and because Google is ensuring widespread adoption of QUIC Holochain RSM is able to leverage the growing code libraries for both TLS and QUIC. This allows the Holochain RSM developers to remain focused on improving their own project, and it also provides reassurance to users that there are no vulnerabilities being introduced by the team building their own crypto communications protocols.
Reduced Network Calls: The addition of the caching function in Holochain RSM reduces the need for the network to make queries on recently seen data. The implementation used delivers a user experience that can be as responsive as that of a local database making the Holochain app experience not only much faster than lethargic blockchain consensus systems but actually faster than centralized web servers. Also, since the cache layer only holds data shared publicly on the DHT, it is safe for multiple instances of an app to share the cache; this will result in massive speed-ups for Holo hosts who may be running many instances of an app for different users.
Hyper-Efficient Network Representation: DHTs are notoriously complex and chaotic, and when self-healing and gossiping are added to the system it can become very challenging to determine the state of the system and who is responsible for what. Holochain RSM massively simplifies data representation such that a node represents the range of addresses it is responsible for with a single 32-bit integer. This simplifies the codebase and architecture significantly, while providing performance characteristics on par with complex, binary-tree representations of the DHT space.
Integrated Keystore: The improved keystore stores the public/private keypair for Holochain apps, and also for the TLS keys used in network connections. This allows for protocols that ensure peer communications in Holochain RSM are immune to man-in-the-middle attacks.
Prepared to Go Full P2P: It can be nearly impossible to truly test fully decentralized systems. Holochain RSM uses a peer routing table to contact each peer directly. Nodes that don’t expose a public IP and port (behind firewalls or NAT) are able to use a relay that’s published in the peer routing table. For easy troubleshooting every node publishes their address via a single relay proxy; the end-to-end TLS encryption ensures the relay can’t read any of the traffic. Then when it comes time to go fully peer-to-peer, all the nodes need to do is publish their own public IP or, if they don’t have one, choose a relay proxy they trust.
The Holochain Team
The developers behind Holochain have a vast amount of experience. The co-founders both have 34 years of programming experience. Arthur Brock, who is the Chief Architect behind Holochain has been a contract coder since 1984, working with AI systems and as an online alternative currency system designer since 2001.
Eric Harris-Braun is the Executive Engineer behind Holochain. He has also been a contract coder since 1984, a full time programmer since 1988, a designer of peer-to-peer communication applications (glassbead.com) for many years, a full-stack web developer, as well as having experience in system design, framework design, etc.
Rounding out the team are 25 additional developers, UX/UI experts, software engineers, marketing professionals, and other contributing members. The core developer is David Meister, an Australian software architect with over a decade of experience. Nicolas Luck, a German software architect who also has over a decade of experience developing elegant software solutions was previously a core developer as well and remains on the team as a special contributor providing advisory services.
HOLO Cloud Hosting Platform
There are a number of practical applications brought to life by Holochain RSM. These are all enabled by the HOLO hosting platform; a peer-to-peer hosting platform for hApps meant to provide the foundation for the new internet.
Holo does to web hosting what Airbnb did to hotels—anyone can become a host by turning their computer into a source of revenue, getting paid in HoloFuel for hosting distributed applications. The Holo software runs in the background, allocating spare storage and processing power to serve hApps to the legacy web. Hosts choose what hApps to serve, set their own hosting prices, and manage their own priorities.
The HoloPort is an easy and direct way to support the distributed Internet, designed to host peer-to-peer Holochain applications.
As easy-to-use dedicated Holo hosting devices, HoloPorts serve as a bridge between the community running distributed Holochain applications and visitors from the web. Owners of HoloPorts can charge fees for their hosting service and earn HoloFuel. HoloPorts come in three sizes—the HoloPort Nano, the HoloPort, and the HoloPort+.
Holochain has two currencies, HoloFuel and HOT.
HoloFuel, the native , asset backed, mutual –credit currency. HoloFuel is a Holochain-based currency that is a contractual service obligation, redeemable for hosting. HoloFuel is a mutual-credit accounting system capable of performing billions of daily micro-transactions. Its primary use is for Holochain application (hApp) providers to pay Holo hosts for their services. Holofuel is not currently openly traded on exchanges
- A completely peer-to-peer cryptocurrency.
- Optimized for high speed and minimal fees.
- Currency you earn for hosting on Holo, and redeem to pay your bills.
- Completely accountable and transparent crypto-accounting, operating by known and shared rules running on every host machine.
Being asset-backed and having a dynamic supply means that HoloFuel can be value-stable without being static or requiring a peg. HoloFuel can optimize the market value of its units in relation to the cost of hosting, creating a steady and stable trajectory.
The agent-centric design allows for the transactions per second (TPS) to increase the more people use it, mirroring how the English language’s “words per second” increases as more people speak it. Therefore, HoloFuel is scalable for mass adoption.
There is no mining or staking involved in earning HoloFuel—only the useful work of web hosting. Anyone can become a host and be compensated by application providers who want their hApp served to the web.
- Spend it through a variety of apps and online marketplaces.
- Redeem fuel earned by hosting for other currencies to pay your bills.
- Borrow it, based on your proven hosting track record, to pay for things.
- HoloFuel is designed for micro-transactions—millions of transactions at fractional values. HoloFuel is divisible in fractional units.
The HOT Token
HOT is an ERC-20 token that was created for the Holochain ICO in March/April 2018. It is intended to be a temporary token that can be exchanged on a 1:1 basis for HoloFuel once Holochain is finally released in its alpha/beta versions. This is expected to happen sometime in 2021, although Holochain has been notoriously slow in its development and release of features.
Holochain completed a month long ICO on April 28, 2018 during which they raised a bit over 30,000 ETH worth roughly $20 million at the time. There were 133,214,575,156 HOT tokens minted for the ICO. Immediately following the ICO the token had traded as high as $0.002 for a more than 1,000% gain in a week. The price quickly deflated over the following two months, and by July 2018 was trading below $0.0005.
HOT tokens remained in a range of $0.0006 to $0.001 from 2018 through the beginning of 2021 when they got a boost from the broad based rally in cryptocurrency markets. After reaching an all-time high of $0.03157 on April 5, 2021 the value of the tokens began declining and as of May 19, 2021 HOT tokens are trading at $0.007755.
Rather than burning the HOT tokens after swapping they will be held in a reserve account to help maintain stability in the network. There are no plans yet for when HOT will be completely removed. There are also no set plans for listing Holofuel on exchanges, although the team understands this conversation will need to happen.
As mentioned, Holochain is known to be slow in the development and release of features, and the team readily admits that Holochain RSM remains a work in progress. As of May 2021 it is focused more on use cases for app developers rather than end-users. The next steps are the release of the beta version of the mainnet, which is anticipated to occur before the end of 2021.
At the time of writing many features are in alpha testing, and it is expected that end-users will soon have the ability to run hApps.
The Holochain team took a long time to refactor the platform, and now feel they have the Holochain that was initially envisioned by the founders. Now all that remains is for testing to be completed so that the production version of Holochain can be released to users. Will it actually occur in 2021? That remains to be seen.
Holochain’s development team feels that this is a paradigm-shifting ecosystem of peer-to-peer applications, but it remains to be seen if they will be able to also reach mainstream adoption of their technology, given the large headstart that many other dApp platforms have. One feature that’s certainly in their favor in 2021 is the push towards more environmentally friendly DLT solutions. That alone could make a world of difference for Holochain.
Disclaimer: These are the writer’s opinions and should not be considered investment advice. Readers should do their own research.