The Omnitude Ecosystem
Omnitude… if it didn’t exist you would have to invent it.
A middleware hybrid blockchain platform that works for every enterprise business and their customers.
Big enterprise businesses have complex WMS, CMS and ERP systems that have been put in place by differing providers at different times in their growth. This means that getting them to speak to each other is a long, expensive and painful process whilst being a resource and cash drain. We offer a fast, cost effective and secure blockchain middleware platform that helps push,pull and merge data.
Small businesses cannot afford to invest in these complex systems so will never truly be able to compete with the big boys in terms of managing their data to deliver business information. Our platform enables small businesses to adopt blockchain technology, cost efficiently and at speed enabling users to create bespoke applications, tailored to their own business needs.
Omnitude is a toolkit for businesses to integrate the benefits of blockchain technology into the commercial fabric of their organisations easily and cost efficiently.
Omnitude is open
Any entity participating in eCommerce (e.g. merchant, customer, supplier, courier, affiliate/ referrer, or Omnitude specialist) will be able to join the Omnitude ecosystem. They will be granted an OID by the Omnitude Foundation and will run a full or partial node. Depending on their role, the Omnitude Foundation will assign the appropriate level of access required to transact in the ecosystem.
Each new full node will improve the security and reliability of the Omnitude ecosystem. ECOM tokens will provide an economic incentive to secure ecosystem infrastructure, and serve as the method of settlement between participants to access ecosystem resources. Omnitude will be a permissioned network where nodes are run by known whitelisted organisations or individuals. Depending on the role of the participant, the Omnitude Foundation will assign to that OID the appropriate level of access required to transact in the ecosystem.
Omnitude is secure
Additionally, Omnitude will prevent unauthorised parties from ascertaining the identity and patterns of behaviour of any other participant by inspecting the ledger. Omnitude will allow ecosystem participants to make certain details of a transaction confidential, so that they cannot be accessed by anyone other than the stakeholders in the transaction.
Periodically, the Omnitude blockchain will also anchor to transactions on the Bitcoin and Ethereum blockchains. This will allow Omnitude’s blockchain to benefit from the added security provided by Bitcoin’s and Ethereum’s consensus algorithms and blockchains.
Omnitude is transparent
Omnitude will provide deep searchability, backwards in time through many transaction layers, to fulfil the requirements of retrieving data stored on its blockchain.
Omnitude will use ‘anchoring’, i.e. creation of a proof linking off-ledger data to a Omnitude blockchain transaction. Through anchoring, this proof can be used to verify data integrity and timestamp without relying on a trusted authority.
How it works
The DPBFT consensus protocol receives transactions, and determines how to organize and when to execute them. Successful execution of transactions results in ledger changes.
DPBFT consensus, anchored in Bitcoin
Omnitude will use the DBPFT (Delegated Practical Byzantine Fault Tolerance) consensus algorithm. DPBFT is an Omnitude-specific algorithm derived from Practical Byzantine Fault Tolerance.
For each block, N ‘validators’ will be selected randomly from the known membership of full nodes. One of these ‘validators’ will be selected randomly as ‘leader’ and then order transactions to include in the block. The node will then broadcast this list to all other ‘validators’. Each ‘validator’ will execute this list of transactions, calculate the hash code for the newly created block, and then broadcast this hash code to the network. The node will also take note of the hash codes broadcast by all other validating nodes. If it sees that 2/3 of all validation nodes have the same hash code, it will commit the new block to its local copy of the ledger.
The reward for participating in a round of DPBFT will be the transaction fees in the block, split equally between N ‘validators’. There will be no mining of ECOM, all of which will exist from day one.
DPBFT will offer immediate transaction finality, a high transaction rate, and high scalability.
2. Smart Contracts
Smart Contracts will be self-executing agreements between parties where all relevant covenants will have been spelled out in code, will be settled automatically, and which can be made dependent upon future signatures or trigger events. Smart Contract applications will encode logic invoked by specific transaction types on the channel.
A smart contract will be a decentralized transactional program, running on validating nodes.
Omnitude will provide smart contract applications to embed and execute common eCommerce business logic.
The world state will represent the state of every smart contract. Each smart contract will be assigned its own state to be used to store data in a key-value format (keys and values will be arbitrary byte arrays). The world state will also contain the block number to which it corresponds.
During deployment, smart contract transactions will be time bounded and configured.
If a transaction times out, it will be considered an error and will not cause state changes on the ledger.
One smart contract function will be able to call another smart contract function whenever the first smart contract has the same restrictive confidentiality scope as the second; that is, a confidential smart contract will be able to call another confidential smart contract if they share the same group of validators.
As transactions are run in a new block, a delta from the world state in the last block on the blockchain will be maintained. If consensus is reached for the current block, the changes will be committed to the database, and the world state block number will be incremented by 1. If peers do not reach consensus, the delta will be discarded and the database will not be modified.
Smart Contract Services
Smart Contracts Services will provide a secured, lightweight way to sandbox smart contracts executing on validating nodes.
Smart Contract Services will use Docker to host the smart contract without relying on any virtual machine or computer language. The environment will be a “locked down” and secured container.
Secure Registry will enable Secured Docker Registry of base Omnitude images and custom images containing smart contracts.
3. Trust, Identity & Registration
Omnitude’s hybrid blockchain will be anchored in the Bitcoin and Ethereum blockchains. Periodically Omnitude will take every piece of meaningful data in its system and compute a single hash that can be used to verify the system’s state, given the original data.
This hash will then be stored economically in Bitcoin’s and Ethereum’s blockchains at periodic intervals. The hash will be generated by building a Merkle tree of all the data and then storing the Merkle root as the anchor. Easy-to-use tools will be provided for users to verify anchors against the state of the system.
Registration will offer the control and management of authorizations for Omnitude participation, to restrict access to the network.
Identity Management will provide management of assurance, and authorized disclosure of association of identities and roles to Omnitude participants. The identities of transacting parties can be concealed.
Auditability will offer the capability to provide authorized entities the means to link transactions of individual users, or groups of users, and to access a given user’s activity, or the operation of the system itself.
Performance and scalability
Omnitude will leverage Hyperledger’s design for performance over the long term. Omnitude ledgers must be able to operate continuously for very many years, and allow discoverability, search, identity resolution and other key functions in user-acceptable timeframes. Omnitude must also be able to handle substantial expansion of the user base without performance degradation.
Omnitude will assign network roles by node type. To provide concurrency and parallelism to the network, transaction execution will be separated from transaction ordering and commitment. Executing transactions prior to ordering them will enable each peer to process multiple transactions simultaneously.
This concurrent execution will increase processing efficiency on each peer and accelerate delivery of transactions to the ordering service.
In addition to enabling parallel processing, the above division of labour will unburden ordering nodes from the demands of transaction execution and ledger maintenance, while peer nodes will be freed from ordering (consensus) workloads. This bifurcation of roles will also limit the processing required for authorization and authentication; it will not be required that all peer nodes trust all ordering nodes, and vice versa, so processes on one will be able to run independently of verification by the other.
Participants in the Omnitude ecosystem will need to register with membership services to obtain an OID with access and transaction authority on the network. Omnitude will operate as a permissive permissioned-blockchain, to allow both ease of access and support for rapid and high adoption.
Membership Services will manage identity, privacy and confidentiality on Omnitude. Participants will register to obtain OIDs. This will enable the Omnitude Foundation to issue security keys for transacting. Auditability will allow auditors to view transactions relating to a participant, if each auditor has been granted proper access authority by the participants.
6. Network & API
Omnitude will run as a cloud hosted, multiple network environment, with peer nodes hosted by any cloud provider and able to connect to one another over HTTPs. Users will run peer nodes, and may also run validating nodes if they chose to.
Application programming interface
Omnitude will include the REST and JSON RPC APIs, events, and an SDK for applications to communicate with the network.
Typically, applications will interact with a peer node, which will require some form of authentication to ensure that the entity has proper privilege; messages from a client will be signed by the client identity and verified by the peer node. Applications will also be able to interact directly with the Omnitude core.
As with Hyperledger, P2P Protocol will use Google Remote Procedure Call implemented over HTTP/2 standards. This will provide the network protocol (“gossip network”) with many capabilities including bidirectional streaming, flow control and multiplexing requests over a single connection. It will also work with existing Internet infrastructure, including firewalls, proxies and security.
Blockchain will manage the distributed Omnitude ledger through a p2p protocol built on HTTP/2. The data structures will be optimized to provide efficient schemas for maintaining the world state replicated at many participants. The DPBFT algorithm will guarantee strong consistency.
Blockchain services will comprises four key components: DPBFT, P2P Protocol, Distributed Ledger, and Ledger Storage.
Distributed Ledger will manage the blockchain and the world state by implementing three key attributes:
- Efficient calculation of a cryptographic hash of the entire dataset after each block.
- Efficient transmission of a minimal ‘delta’ of changes to the dataset, whenever a peer node is out of sync and needs to ‘catch up’.
- Minimize the amount of stored data required for each peer to operate.
Distributed Ledger will use RocksDB to persist the dataset, and build an internal data structure to represent the state satisfying the above three attributes.
Omnitude will support two transaction types: code-deploying, and code-invoking.
A code-deploying transaction will be able to submit, update or terminate a piece of smart contract, and the validating node will then need to protect the authenticity and integrity of the code and its execution environment.
By contrast, a code-invoking transaction will be an API call to a smart contract function. Each smart contract will maintain its own state, and a function call will be a common method for triggering state changes. It will be possible to prevent transaction patterns from being observed and interpreted, so that shared ledgers do not give away details about business relationships that should not be revealed to competitors.