Docs

Evolution


The project that eventually became Open Horizon began in Egan Ford's innovation team at IBM with the code name MTN (pronounced, "mountain") in 2015, and was shown to the public for the first time at the Internet of Things World Forum (IoTWF) conference in Dubai, UAE, in December 2015.

dubai

At the time of that initial unveiling, Horizon was a completely decentralized Internet of Things (IoT) platform, leveraging Peer-to-Peer (P2P) technologies to completely eliminate the need for (and risks inherent in) centralized services. Horizon sought to enable untrusting participants to safely exchange data for compensation.  Individual data producing IoT edge computers would advertise the services they wished to offer on a (decentralized) Blockchain (using an instance of the Ethereum Blockchain) with a Solidity Smart Contract. Potential data consuming edge computers could monitor the Blockchain looking for advertisements of interest. Then a consumer could use the Smart Contract to propose an offer to the producer (containing details of the software they want to run, services they wish to consume, and compensation arrangements). Producer machines would also monitor the Blockchain to watch for proposals on their Smart Contract. If an acceptable offer was received (e.g., if sufficient compensation was offered) the producer would record their agreement in the Smart Contract accepting the offer and the two parties would be "in contract".  This approach eliminated the need for a centralized broker service.

This technique was also patented: https://patents.google.com/patent/US20170279774A1/en

Once in contract, the producer would use a (decentralized) BitTorrent system to "torrent" (fast download from many peers) the code "seeded" by the consumer. Then the producer would verify the content hash and cryptographic signature of both the code and the configuration with information provided by the consumer. Once verified, the code would be run in a constrained sandbox, giving access only to the services explicitly identified in the agreed contract. Those services could enable access to local sensors, and/or local actuators, on the producer machine in addition to enabling constrained access to compute and network facilities on that machine. Producer machines could then be used to collect data, compute analytics locally using consumer code, send data to remote locations, and to receive commands from remote locations to take action locally.

Horizon is also multi-tenant in this early version, enabling multiple consumers to provide software to a single producer edge machine. Of course a single consumer edge machine could also contract with many producer machines, and any machine could act as both consumer and producer.

This version of Horizon completely eliminated the possibility of a central service being hacked or corrupted and compromising the entire set of participating machines. It also enabled the protection of all (untrusted) parties' privacy throughout the discovery process. Only when *both parties* formally expressed their desire to engage would the fully autonomous contract creation and validation occur. Then only when in-contract were the parties able to share specified information and access. Trust between these untrusting parties was established through the use of a Smart Contract and a mutually trusted third party *escrow service* for the exchange of compensation.

About this time, Horizon also began to be open-sourced as the Open Horizon project in GitHub.

Assessment and Reinvention

We discovered several significant limitations in the original Horizon implementation. Probably the most significant of these was identified by automated testing. We discovered that traditional Blockchain technology has severe throughput limitations. We had to rethink our usage of this component as an immutable public ledger. We also were unable to find any P2P messaging technology that sufficiently safeguarded participant privacy (e.g., with Future and Forward Secrecy). Another issue was that the Smart Contract details were publicly exposed on the Blockchain by our approach. In order to address these issues, several significant design changes were made and version 1.5 was released.

Version 1.5 of Horizon introduced a centralized messaging Switchboard service. Participants were required to provide their public keys, but otherwise register anonymously. Producers registered offering services on their edge machines. Consumers registered then searched the Exchange for services they wanted to consume. When a suitable producer was found in a search, the potential consumer would message the producer using a derived shared symmetric key. How did they derive this key? Each party used their own private key with the other party's *public* key to derive the same shared symmetric key (e.g., using a Diffie-Hellman key derivation). By doing this they were able to encrypt their messages such that the Switchboard is not able to eavesdrop on their messages. To be more secure the parties can use their shared symmetric keys to generate the same *series* of message keys so that no two of their messages are ever sent using the same key.

Using the central Exchange and Switchboard services enabled much faster transactional throughput for Horizon.

Also in Version 1.5 of Horizon only a cryptographic hash of the contract, and corresponding payment transfer transactions, are ever written to the public Blockchain.  This better obfuscates the contract details. Both participants compute a hash of the contract contents, then sign it using their shared symmetric key. Then when the consumer writes that signed hash to the Blockchain, the producer can verify it matches their own computation. Both parties will then privately prove the veracity of their agreed contract on the public ledger (Blockchain). Note that this approach greatly improved participant privacy. No parties other than the producer and the consumer were able to see any of the contract details with this new approach because the contract itself never appeared on the public Blockchain..

The links below have additional information about these earlier versions of Horizon: 

Version 2.0

Even though the Blockchain in Horizon 1.5 was only used to store contract hashes and payments, the requirement to use a Blockchain and specifically only the Ethereum Blockchain was considered restrictive.  At this time IBM expressed an interest in using Horizon with their HyperLedger Blockchain.  So Horizon was redesigned to enable other non-Ethereum Blockchains to be used, and also to make Blockchains entirely optional (i.e., participants could use other forms of ledger to record the results of their fully automated contracting).  About this time, work was also begun to deploy an instance of Horizon that worked together with the IBM Watson IoT Platform.

Version 2.0 also contained major improvements in tooling.  It introduced the "hzn" command line tool with built-in help and many other features.  Hzn can be used to interrogate the state of the local Horizon Agent (anax) or the Horizon Exchange.  It also can be used to simplify (or automate) the machine registration process.  Hzn works primarily by invoking the already existing REST APIs of Horizon components, but greatly simplifies using them.  By passing the "-v" (verbose) flag to hzn, the REST API endpoints (and actual "curl" commands used to invoke them) are shown.  In addition to the hzn command, many simplifications and feature enhancements were made to the metadata structures (JSON) used to communicate between the components.  For example, in 2.0 "deployment patterns" could specify a full range of services to be deployed on  the edge nodes, including container references, access credentials, verification credentials, etc. making it very simple to securely deploy large numbers of edge nodes with a particular software load.

The hzn command also supports development testing.  The "hzn dev" subcommand enables the developer to generate the required metadata structures, and to simulate automated deployment (closely replicating the production environment for pre-deployment testing).

Also for version 2.0, detailed developer documentation was provided, together with "quickstart" guides, a technical FAQ, and a lengthy troubleshooting guide.  New simplified example code was also provided.  Developers can now simply copy the example, quickly insert their own code, and rapidly deploy a prototype.

Beginning a New Chapter

The resulting deployment of version 2.0 along with the release of the IBM Watson IoT Platform Edge solution as a technology preview occurred in early 2018.  Work on this Blue Horizon project was suspended at the end of 2017 so the team could focus on open-horizon and the Edge technology preview going forward.