OriginTrail Testnet Progress Update
It has been two months since our team released the first beta version of the OriginTrail node (Apollo), kicking off the beta program during which we have seen solid progress on our way towards launching the OriginTrail Decentralized Network (ODN) mainnet.
On June 29th, the launch of the testnet initiated the beta program, which has resulted in great engagement from the OriginTrail community. Through our Discord group, members of the beta program submitted very valuable findings and observations regarding node operation and communication within the network, as well as their take on and ideas about the user experience of running a node. We are very grateful to all beta participants! We have focused on making the process of joining the beta program as streamlined as possible by providing automatic installs and updates (via Docker), as well as automatic generation of ETH wallets and providing them with test tokens and Rinkeby ether as soon as a node goes up.
In the meantime, all of the network nodes have been sending the OriginTrail development team highly valuable information on their operations, which we have been analyzing and utilizing in our development efforts. It has been extremely valuable to observe the nodes in operation in so many different environments and conditions. It has helped us further secure smooth operation within targeted systems. Furthermore, the UI application Houston has seen several visual and UX improvements resulting from feedback of node holders and customers alike.
The test network is being constantly under load with imported data coming from both companies and our sources (periodically) uploading and testing their integrations with ODN. The current success rate of data creator (DC) offers on the network is above 80%. Node escrow initiation has also improved, (above 80%) while confirmation is constantly above 92% (97.6% on average), which can be considered quite high, especially considering breaking changes we introduced as part of the six releases after Apollo (currently, we are on version v1.3.10b).
Using data observed from the network operations so far, we have identified two main inefficiencies that need to be resolved in order to proceed with the launch of the mainnet. The first issue is the unsustainable cost of the current bidding mechanism operations in terms of ETH. The second challenge is the ability of the node to recover from the widest possible range of issues that it might encounter, in order to minimize the possibility of becoming inoperational for a critical period of time, resulting in potential loss of stake.
Optimizing the Bidding Mechanism
The current high cost of the bidding process is the result of the nodes’ internal mechanism, which tries to predict offers from DC nodes for which it is most likely to be picked when bidding. The bidding smart contract awards the nodes jobs based on their bid (required price in tokens, offered stake), reputation, as well as the hash distance in address space relative to the data import being replicated by the offering DC node.
As every bid sent to the bidding smart contract requires ether, these costs can pile up, and with no guaranteed return, can present a sizable amount in case of high network usage. This is why the OriginTrail team is developing an optimized version of the bidding mechanism by making sure that the nodes get to spend ether only if they are sure that they will receive compensation (i.e. they are chosen for the offer they bid for via smart contract). We are also focusing on lowering the amount of transactions the bidding mechanism requires with the blockchain, optimizing the smart contracts to require less gas usage and, finally, crafting a mechanism that would allow for delaying operations during periods of high congestion on the Ethereum main network.
Furthermore, we are looking closely at emerging solutions in the domains of state channels, Plasma and L2 protocols, which might further lower the costs of operation for ODN interactions with the Ethereum blockchain. We believe the Ethereum community is doing great work and are happy to be able to contribute to the efforts.
Increasing Resilience and Failover Mechanisms
When it comes to the ability of the ODN node to recover, a major improvement was introduced through a state, machine-like module that utilizes the command sourcing pattern in its core. This way, it is much easier to modify and fine-tune the internal mechanisms of the node, write code and command tests, as well as recover and remodel any node operation.
Because of this improvement, a node can save state (much like players can save their progress in computer games) and continue with operation where it left off after a potential restart occurs. Furthermore, the team is working on a way to create a high-availability scheme for nodes (with a load balancer) to enable operators to provide very high-availability ratings by utilizing several servers in different environments to increase robustness and quality of service.
Apart from these two main protocol-related challenges, we are working on several smaller improvements, including key management, smart contract tunings, user experience improvements and API extensions. All this will be further elaborated on in the coming releases and covered with tutorials and documentation.
Overall, we have seen great progress during the last couple of months and, with the inefficiencies outlined above, have managed to successfully test out many scenarios with different data sets, environments and network conditions. As the number of companies interested in joining the decentralized network is growing, we are looking forward to seeing more engagement on the network. We will keep the community posted on our progress in the coming weeks and publish an updated roadmap next week.