In this update, we bring news on our solidified token economy design, improved blockchain layer, and finalised technical core implementations for storage and streaming. Accordingly, we updated the technical whitepaper with details of our new approaches for market selection, fair streaming, incentivisation, and node on/off-boarding.

We have been working on a version 2 of the ProximaX Mobile Wallet. This wallet is completely re-coded from the previous version and has better security and improved user experience. We have also extended our portfolio of applications to now include an identity management solution, workflow engine, and microservices framework integration. File It!, Notes and Vault remain in beta testing, as they continue to be iterated with improvements and new features.

Core Platform Updates

Given that the actual technical components for our core services (storage, streaming) are complete, the team has spent more time on the token economy design. Full details of this will be included in the updated technical whitepaper that is due to be published soon.

In addition to the token economy design, there were a few changes made to the technical components of each layer, as outlined below.

Blockchain Layer

One of the key features that was built in April was the metadata plugin. This new plugin will allow metadata to be stored on the blockchain by a key-pair value. Existing blockchain plugins were updated to include this metadata feature so that custom data can be tagged to an account, mosaic, or namespace, which is extended by the owner of the account, mosaic, or namespace, via the key-pair value.

We have also designed and started building a software upgrade utility for the blockchain. As Catapult does not have a version compatibility support, newly built plugins would require extra effort when upgrading software nodes. A possible result of this is having to restart the blockchain and potentially risk losing all data. This outcome is not desirable for the launch of our public main network, which is why it became a necessity for us to design and build the software upgrade utility for the blockchain as we cannot wait for all plugins to be built to run our main network.

Instead of tying binary data releases to block heights currently, the plugin uses notification versions to be tied to each version of the binary data. In other words, when a new version of binary data is released, a new version of notification and validators/observers of that notification will be added. This way, all versions will be available and allowed at any time, which will enable smooth software updates. If required, switching back to previous software versions can also be done without affecting or stopping the blockchain. Blockchain clients may work with older versions of binary data if it is suitable for them (although they may need to consider aspects of synchronization of such data between nodes). The Catapult software update will be announced via the blockchain. A new transaction plugin will be added for this. At the moment only the genesis account can publish software update transactions. In future, software update releases may be driven by plugins and our Super Contracts. The transactions will set an update interval (in blocks) during which software updates should happen. During the update interval, all nodes can update the binary code but the changes will not apply until the end of the update interval. This will allow for the blockchain to function normally without being affected by the upgrade. When the update interval lapses, the older software will be replaced by the new version automatically.

The technical documentation for the blockchain is being put together and this will be published as soon as the blockchain SDKs are ready.

Storage Layer

Since our last update, we have also re-evaluated our storage technology components resulting in some changes to the code to complement our new approach. One of the key changes we have made was to partially decouple the storage layer from the blockchain. Previously, a blockchain plugin as a service was used to create digital contracts representing the contractual obligation of a storage node by continually reporting stats for its reputation. Although this is still the case for the new approach, it is now more independent as the reputation can be built with less frequent communication with the blockchain. This decoupling results in a more performant core storage service.

A few modifications to the Provable Data Possession (“PDP”) library were also made. In a nutshell, a PDP scheme allows a client who has data stored in an untrusted server, to verify that the server possesses the original data without needing to retrieve or store a copy of it separately. It accomplishes this by generating probabilistic proofs using an interactive protocol with the remote server. The platform supports three main PDP algorithms: A-PDP, CPOR, and MAC-SC. These will all be discussed in detail in a separate technical whitepaper.

We have started documenting the SDK for the storage layer. It is ongoing, and will be continually updated as we progress.

Lastly, we have started to build the demo server and client for the storage nodes. These are basically components that will demonstrate the storage onboarding, cross verification, and proof of replication scheme. The client demo on the other hand is used to demonstrate how an SDK or client library can interact with a remote demo server node.

Streaming Layer

PSP delivered their second milestone that includes the working streaming platform, documentation, and software development kits. Our next step will be to integrate these with the blockchain layer and build a token economy platform for it.

Raw demonstration of backchannel console: https://cl.ly/f44d36613c1a

One of the key milestones that was delivered was an actual working middleware and SDK that can be used to build live-streaming capable applications. We currently have full SDK support for iOS, Android, Linux and Mac. Documentation on this is well underway.

In addition, we also rebuilt some of the streaming technical components in an effort to unify all core services. One of these is to create a Proof algorithm (bandwidth) with a highly secure communications channel.

Bandwidth is always a crucial factor in any streaming application and the ProximaX streaming layer is no exception. In the streaming node network, the bandwidth and reputation are necessary to ensure that the consumer gets the best possible node workers that will deliver the data stream from one point to another. In ProximaX’s streaming layer, nodes are expected to provide bandwidth statistics via an indeterministic process that returns a set of data (time tags) that will be used to determine reputation with respect to their bandwidth. The stats collected will be weighted as part of the reputation score, which in turn will affect the probability of each node being selected to service a customer/client.

Details of this will be included in the updated technical whitepaper.

Node Test Network Environments and Software Development Kits

Earlier this year we opened our test network. In April, we started to finalise the blockchain SDKs and technical documentation. This will allow developers to build their proof of concepts on the test network. More will be announced.

Infrastructure and DevOps

The DevOps team has been looking at different platforms and toolsets with the objective of making it easier to continuously deliver our software.

Keeping up with updates and enhancements from all the development teams is not a trivial task. Hence, we have created a continuous integration environment with Jenkins as our main CI tool, and Slack as our notification channel. The teams will be notified of any successful or failed builds in Slack, thus increasing awareness and initiating open discussions on next steps.

Continuous deployment is another area we have greatly improved on over the past months. We have introduced Ansible AWX, an open source version of Ansible Tower. With a single click of a button, it can update the software version, reset the chain, propagate configuration changes across all nodes, and restart the application. This is now made more efficient as opposed to doing each task one by one, previously.

The DevOps team will continue to introduce new technologies across ProximaX’s development teams. One main focus will be to publish the Sirius platform on our cloud partners’ marketplace. Container orchestration using Kubernetes is being experimented as we prepare to scale up on the nodes for mainnet launch. More information will be released in future articles on how these platforms can be used and deployed.

Application Development

Much time has been spent on fine tuning and enhancing the core platform for performance as we gear towards the mainnet launch. At the same time, we have also been building an internal application development team, albeit it has not been as aggressive as the core development.

Notwithstanding that, we continued to build momentum on the ProximaX Identity solution. The project started as a POC to a potential customer, however, we are going to develop it into a complete system that can be marketed and sold as a solution separately. Identity management has a huge potential and ProximaX is well positioned as a platform for this vertical. It is an extremely powerful system solution for enterprises to secure their identity management, leveraging on the advanced encryption, and key infrastructure of the blockchain.

ProximaX NIS1 Wallet Version 2

The entire ProximaX Wallet was re-coded. This version 2 is much more intuitive and simple to use. We are currently running a bounty program to look for bugs in the wallet before the actual production version is launched.

Identity Management

One of the key tasks completed is to store biometric data in the storage layer. This is in addition to the system’s ability to create a hierarchy of users as well as capture geographical data. When a new user registers, part or all of the user’s data can be stored onto the NFC card. The information can be verified using an NFC reader that directly communicates with the ProximaX Sirius platform.

Microservices Platform Integration

The technology team is exploring the integrating of a microservices platform called Abixen. Abixen is an open source project that I contributed to, in 2016, and it has a powerful microservice architecture that allows development teams to quickly build enterprise and mission critical applications with pluggable services. We are extending this project by creating a Proximax Sirius plugin to allow developers to build apps that are directly integrated into the Sirius platform.

More updates on the applications we’re building

• File It!, Vault and Notes — These are continually being upgraded and enhanced. There is an open beta testing and everyone is free to join in and report bugs (bounties are given out where appropriate and applicable).
• Workflow Engine — the first live public test for the workflow engine will be released very soon. We’re now setting up the infrastructure for this so that we can open it to the public for beta testing.

Catapult (NIS2) Blockchain Explorer and Wallet Upgrades

We are rebuilding the NIS2 blockchain explorer and generic wallet.

• http://bctestnetexplorer.xpxsirius.io — NIS2 Blockchain Explorer
• http://bctestnetwallet.xpxsirius.io — NIS2 Web Wallet — still under development. A new web interface will be deployed soon.

Summary

• ProximaX Wallet Version 2 design and development
• Completed the storage tech platform
• Completed streaming tech platform
• Started updating the technical whitepaper and other research and design documentation
• Explored integration with Abixen Microservices platform and the ProximaX Sirius platform
• Worked on the identity platform
• Worked on the workflow Engine
• Automated infrastructure deployment
• Introduced metadata plugin for the Catapult blockchain
• Worked on improving the process for blockchain software upgrades