It is my pleasure to announce that the newest version of the OriginTrail node code, the v0.6a release we have dubbed Kosmos, has been deployed on GitHub.
As explained on OriginTrail’s open-source protocol roadmap, the Kosmos release brings three vital improvements to the system. They are:
- Full GS1 standards validation: We have improved the GS1 import integration experience by adding full GS1 data validation. This helps speed up integrations.
- The first implementation of the market bidding mechanism.
- Fully implemented blockchain fingerprinting virtualization documentation, which explains how the blockchain layer of the protocol will become compatible with blockchains other than Ethereum.
Kosmos is the 4th out of 8 bi-weekly releases leading up to OriginTrail’s testnet launch in June. We are halfway there!
If you have any technology-related questions, please submit them via this form. Our tech team will organize an AMA session soon to get you the answers.
1. Easier Integration Via GS1 Standards
Since the Mechta release on March 26th, the OriginTrail Decentralized Network (ODN) nodes have had support for the GS1 EPCIS based XML structured file as input for the system. This presents one of the pillars of our solution to the data interoperability problem in supply chains, as many companies across industries are already in line with GS1 standardization.
GS1 operates in 110 countries and is governed by its members from 20+ industry sectors. GS1’s global management board includes industry giants such as P&G, J&J, Walmart, Deutsche Post DHL, AEON, Metro AG, Nestle, Mattel, Mondelez and e-commerce giants eBay, Amazon and Alibaba. Learn how our Supply Chain Integrity & Standards Advisor Mr. John G. Keogh explains the impact and potential of GS1 membership to our future technology development and adoption here.
Kosmos helps with data integration by providing developer-friendly validation of the GS1 compatible structured data, which is provided as input to the ODN. The latest importer version checks the validity of file structures and values of the provided data, including GTIN standardized code structure, their checksums, dates and blockchain address values.
The data importer is a vital step towards speeding up and easing the integration process of current systems with the OriginTrail protocol. The importer points out potential misconfigurations, data inconsistencies, and general errors, to service providers and developers setting up data exchange on the ODN.
From a business perspective, the importer is a significant step towards protocol scalability. With the Kosmos updates, companies will be able to adopt the system quickly and easily, with less overhead for data entry. This will ease the technical support workload of our business development team, allowing them to focus more on to developing business model structures for companies using ODN and identifying new use cases.
2. The First Iteration of the Bidding Mechanism
As outlined in the previous blog posts, one of the main building blocks of ODN is the bidding mechanism by which nodes in the network are able to form agreements and bid on providing services to each other.
This implementation of the bidding system is based on an Ethereum smart contract. In the bidding system, an Ethereum smart contract handles the creation of Offers by Data Creator (DC) nodes. DC nodes receive Bids from Data Holder (DH) nodes should an Offer become interesting to one or more DH node.
Bids are submitted in a sealed form, so, the content of the bids — the number of tokens and stake offered — are not visible to any of the participants during the bidding process. Once bids are revealed, new bids cannot be submitted. The DC node then initiates a choice mechanism, which runs a “roulette” function with associated probabilities of choice corresponding to the number of tokens and stake provided in the bid by each DH node. Once a choice is made, the tokens needed for the agreements are transferred to the Escrow smart contract facilitating the payment mechanism.
This initial implementation comes with certain simplifications and limitations, which will be improved in the following releases before we launch the testnet. Currently, the bidding mechanism disregards the node reputation scores. For now, the bidding system takes the amount of stake and tokens involved in the bid for a simple “roulette” choice, which allocates higher probabilities to the DH nodes that have applied with a higher stake and token price. The roulette then randomly selects the applied nodes based on these probabilities and checks if they have the tokens to pay for the contract. Furthermore, the replication size is currently limited by the smart contract gas running limits, so, it will not work for a large replication number (hundreds of nodes or more).
In future development, we plan to move several operations off-chain to the ODN network layer, leaving only the most important (trusted) operations to be performed by the contract itself. While Kosmos introduces the initial version of the bidding mechanism, the final mechanism is subject to a longer process of iterative research and development, as well as a thorough and lengthy testing in the upcoming period before we launch the testnet in June. The bidding mechanism will be gradually improved, based on real transaction data from multiple companies. There is other scheduled work to be done by the launch of testnet, with several iterations and more fine-tuning of code, logic and game theory behind the mechanism.
Keeping that in mind, the initial mechanism is an important step towards the testnet. We will be running extensive simulations within the alpha network to get as much insight into inefficiencies as possible so that we can base further decisions on empirical findings as well.
3. Beyond Ethereum: We Are Ready to Introduce Other Blockchains
The code rewrite performed as part of this release also involved blockchain-layer communication. Node holders can now choose a preferred blockchain for storing data fingerprints. This continues to be part of our research, as we analyze blockchains, other than Ethereum, with the ability to support the ODN.
At this moment, all the blockchain functionality is being tailored for Ethereum, but the code is structured in a way that abstracts (virtualizes) the blockchain implementation. This means that interfaces can be written to other blockchains without requiring changes to the rest of the system. This could provide a lot of value to the protocol. Becoming less dependent on a single chain could make the protocol attractive for markets that prefer non-Ethereum blockchains, and bring robustness and potential for lowering cost should one of the mainstream blockchains become highly volatile for some reason.
An Open-Source-Spirited Solution: Pitch in and Become a Part of the Decentralised Supply Chains Legacy
OriginTrail is an open-source project for data exchange with wide possibilities for applications and additional features. We have decided to adopt an agile way of development in bi-weekly sprint cycles so we can involve the developer community in the early stages of development.
Join the community of developers engaging with the code! Community proposals, based on insights into the code or experience from implementations and pilot projects, are crucial for the development of a versatile and efficient system. We are building a strong community of developers that are already working on top of the protocol on implementation projects with companies in the Trace Alliance. The Improvement Proposals repository provides a structured way to involve the community.
Our tech team will organize an AMA session for answering these questions. Stay tuned for the Zond Release — v0.7a of the OriginTrail node code — coming up on May 7th, which will introduce:
- The Initial version of the zero-knowledge privacy sub-layer
- Neo4j database compatibility allowing for further flexibility in the data layer for implementation
- Standardized and documented graph logic
Trace on & connect with devs on Github.