Parallel Consensus Cloud v2.0 Wallet leverages a triple consensus system. The first two allow consumers the everyday benefits of a fast, frictionless, fully-distributed crypto wallet with its useful and user-friendly integrated services.
Every Cloud v2.0 Wallet is a node. A user, whether an individual, organisation, or government retains only as much of the global ledger as pertains to them. At the individual level, a transaction is:
For organizations with multiple points of sale (POS) dApps operating within the same fully distributed peer-to-peer dApp network as individuals’ dApps, a single transaction record on one POS dApp is insufficient. All the transactions undertaken by the organization’s POS dApps will need to be consolidated for analysis, accounting, and for all sorts of internal reasons — bonuses, training, decision support, et cetera — as well as legal or regulatory reasons. Thus, after a confirmed sale in the peer-to-peer network, Cloud v2.0 Wallet provides for a second consensus protocol to be initiated on the organization’s own hybrid network.
The organization’s internal hybrid network includes OrgNodes, each of which, unlike a mobile dApp, has the capacity to maintain the full ledger of transactions by all its point of sale dApps.
At the organisational level, a transaction is:
This internal parallel process is of no concern to the buyer or customer. The deal has already been done, and the value has already been transferred to the organization’s POS dApp (near-instantly). Therefore, the parallel process is not as time-sensitive as the transaction itself.
The organization can build in as much decentralization or centralization as it wishes to secure the full ledger for its own internal or regulatory requirements.
For organizations that want to leverage the value of decentralization fully and to reduce their reliance on expensive servers, Cloud v2.0 Wallet is engineered at the system level to delegate compute, network, and storage functions to SWARMs of devices. Cloud v2.0 Wallet provides FOG computing architecture for organization-level transaction processing, which offers significant savings. “Fogging” is an architecture that uses edge devices to carry out a substantial amount of computation, storage, communication locally and routed over the internet backbone.
Edge devices that organizations can leverage include the branded Cloud v2.0 Wallet-powered dApps used by its 16Cloud v2.0 Wallet stakeholders, its own POS dApps, OrgNodes, even routers. Flexibility and adaptability for real-world applications is the name of the game. The organization could feed its OrgNode data directly into its legacy accounting and inventory systems. It could even build real-time performance dashboards to keep track of activity using transactional data drawn directly from its POS dApps. For example, a company might set up dashboards to track the performance of regional offices or sales representatives in real-time.
FSDLT supports multi-transactional processing by utilizing file-based blocks that can support variable file sizes to cater for business content. Unlike traditional time-based blocks, such as used on the Bitcoin and Ethereum blockchains, transactions on file-based blocks can be processed immediately and in parallel.
Each FSDLT block is structured as a file that contains all the necessary components of a transaction such as its timestamp and other attributes. Each file and its contents have a unique fingerprint called the cryptographic hash, which ensures immutability and no possibility of duplication across the network.
The file or block is stored using IPFS (Internet Protocol File System) on network nodes. Through parallel chaining, FSDLT allows multiple transactions to be processed from a single node. Add multiple network nodes, and there is the capacity to process multiple transactions simultaneously. A FSDLT, therefore, is infinitely scalable in theory.
Each node only stores the transactions in which it has participated. The SHOUT protocol distributes the transaction information through the mDHT network and helps nodes locate the necessary information required to complete transactions. Each transaction needs to pass through a customizable business logic layer similar to an Ethereum smart contract.
Moreover, every transaction can be found by human-readable file names based on IPNS (InterPlanetary Name Service), part of the IPFS framework.
MAINLINE DISTRIBUTED HASH TABLE (MDHT)
The Distributed Hash Table (DHT) is a peer-to-peer (P2P) network composed of distributed nodes. A mainline DHT (mDHT) is used in the system. mDHT data has the form of an index-value pair. Lookup, get, and store operations are performed in the process of requesting and storing data between nodes. To retrieve a value with a specific index, the node performs a lookup operation on the node with a get operation.
There is no hierarchical structure in the network. Every node can join or leave the network at any time. All are dispensable. These characteristics enable nodes to share data by communicating directly within a widely dispersed network.
In a DHT-based P2P system, data is associated with a critical value (a result of hashing the data), and each node in the system handles a portion of the hash space and is responsible for storing a certain range of critical values. When a specific key is searched, the system returns the identifier (IP address) of the node storing the data with that key.
MDHTsystem consists of four modules:
- User Interaction Module for receiving data and accessing time information from the user;
- Cryptography Module for performing encryption of data;
- Key Management Module for managing the keys required for encryption; and
- Secret Sharing Module for dividing the encryption key into several pieces using two further modules:
o A Threshold Estimation Module for setting the optimal parameters based on the similarity measurement between reinforcement learning and the data availability graph, and
o a DHT Network Module for distributing the generated key shares to the DHT network.
SHOUT — SIMPLE HEURISTIC OBJECT UDP TRANSFER
Shout is an innovative and efficient protocol for communications between nodes in the platform. Older blockchains use a slow gossip-like protocol whereby the first witness whispers to another node which in turn whispers to another node until there is a consensus in the network.
SHOUT broadcasts the transaction request across the network and implements a POR (proof-of-reputation) consensus algorithm to determine the first witness. Unlike the energy-intensive POW (proof-of-work) in which the amount of “gas” becomes a decision the sender must make to ensure timely delivery, POR processes transactions in chronological order using an algorithmic mixture of response time, influence (number of connections), and stake (number of transactions).
A lightweight mass connectivity protocol, SHOUT is an open UDP-based variant of the Micro Transport Protocol intended to mitigate latency and other congestion control issues found in conventional BitTorrent over TCP. SHOUT uses multicasting to deliver data to all nodes within the network thereby significantly decreasing overhead.
Swarm Network nodes work together like a swarm of worker bees to form a storage system like a honeycomb. The SWARM Storage layer effectively manages a process whereby participating nodes share disk space with every other node in the network. Each transaction between sender and recipient is processed by a reputation-backed node which is called a witness, and each transaction is a separate chain in the SWARM.
SWARM Storage leverages the FSDLT to store transactional information in the filename so eliminating the need to store data in the actual file itself. Other BLOB/STRUCTURE-based data is stored in the file.