Assimilating Flowchain’s Algorithms — Part 2

Virtual Blocks Miner :

Algorithm 5

Flowchain can build a private blockchain that the IoT devices can self-organize as a p2p network. Every Flowchain IoT node in the private blockchain has a local blockchain that holds privacy-sensitive data. The above algorithm (Algorithm 5) clearly represents the concept of virtual blocks and the local blockchain. The local blockchain starts from the genesis block and is chained by virtual blocks mined by a local miner executing on the IoT node.

ALgorithm 6

1. The block time is determined by P, the Poisson distribution function

2. The value of P is resulted by stakes such as the battery level and WiFi signal strength

3. At the time t1, P predicts that if the termination time of the current block is exactly early than the end of t1, then block #1 is successfully mined

4. The local miner continues to step 2 and 3 to mine more virtual blocks

Flowchain comprised a mining-based proof-of-stake model for IoT devices where the block time, the time to discover a valid block is predictable and can be coordinated in a fixed number calculation per second. Moreover, Kraft and Daniel considered the predictable block times for different hash-rate scenarios as the Poisson process with time-dependent intensity. Therefore, Flowchain modeled the prediction of block times as a Poisson probability density function to ensure a cost-effective difficulty control system. The algorithm 6 represents the concept of this mining process. In algorithm 6, the local miner predicts that block #2 can be found at t2, and block #4 can be found at t9. The block time of block #4 is longer than expected because the WiFi signal is weak at time t4 to t8.

Virtual Blocks Consensus Algorithm :

The Byzantine agreement is a consensus algorithm used by Flowchain to avoid distort data across p2p nodes. In fact, the Byzantine agreement is a distributed decision-making process that a few sums of nodes are agreed on transactions and can replicate the information; such a mechanism is additionally known as fault-tolerance., and Byzantine agreement is known as Byzantine Fault-Tolerant (BFT). Hence, the private blockchain can also agree on the private transactions by fault-tolerance, which means that the p2p network within the private blockchain can imitate a certain of private transactions.

In common, in the event that a most extreme number of n nodes can distort information, a BFT algorithm can be accomplished with a total of 3n+1 nodes to tolerate the network. Be that as it may, on the off chance that if on the off chance that in the event that in case nodes can not distort application data submitted through them, at that point an amount of 2n+1 nodes is capable of tolerating the network. There are various BFT implementations such as Practical Byzantine Fault-Tolerant (PBFT), and Speculative Byzantine Fault Tolerant (Zyzzyva) can be employed in the private blockchains of Flowchain’s hybrid model. The implementation is a selection according to the difference in their business logic.

Flowchain represents a local miner by which virtual blocks are mined. Additionally, the genesis block is pre-defined by the private blockchain developers. As Algorithm 5 already figured that the genesis block, formally indicated as G, which is pre-defined by private blockchain developers, and there are given entities ε1, ε2, ε3, ε4, and ε5 in a private blockchain. As such, Algorithm 6 portrays the method of local mining, and the following example shows ε1.

1. The public blockchain has σ slices per second, which means that the puzzle miner uses a fixed time interval mining mechanism
2. The puzzle miners in the public blockchain are broadcasting λ1 at time t1
3. The Flowchain node ε1 has a sensory data, formally denoted by Μ, and ε1 generates a transaction T1 = Hash(Sign(M), H, pki)
4. The Flowchain node ε1 successfully mines Block #1 after Fpuz solving the puzzle bound with λ1, and stores t1 in virtual block Block #1 of ε1
5. ε1 repeats steps 2, 3, and 4, until the end of σ slices and resulting in a total number of 5 transactions, [Τ1,…, Τ5], which were stored in virtual block Block #1
6. ε1 subsequently continues to get λ2 at t1, as well as resulting in 10 transactions, [Τ6,…, Τ15], which were stored in virtual block Block #2
7. At the time t3, the IoT node ε1 submits [Τ1,…, Τ15] in the virtual blocks, Block #1 and Block # 2, to the private blockchain network
8. All authenticated nodes in the private blockchain can join the consensus activity to agree on [Τ1,…, Τ15], that all the transactions will become trusted
9. The BFT consensus can ensure that trusted transactions [Τ1,…, Τ15] were replicated in the private blockchain, which means that the private blockchain is capable of fault-tolerance of private trusted transactions.

Algorithm 7 shows such a local mining technique where the Flowchain node was pseudonymously authenticated to submit transactions at (ti, tj, tk). Moreover, the above process also gives the deferred submission concept. The Flowchain node can gather transactions in its virtual blocks and submit gathered transactions to the public blockchain in a future time.

Virtual Blocks Approval Sequence :

Flowchain uses a “mining-transaction-approval-verify” process which forwards the transactional data to the endpoint before verifying rather than the typical “transaction-mining-verify” process.

With respect to the method of Algorithm 8, N’ forwards the chunk information to the endpoint after recording the transaction within the distributed ledger. At this time, Flowchain will not label this transaction as a “verified transaction.” In this way, within the process, the endpoint demands “approval” by means of one node of the peer-to-peer network. The already said transaction will only become a verified transaction in the event that the peer-to-peer network effectively verifies it. In conclusion, Flowchain will recognize the transaction as a verified transaction when the endpoint demands to approve it. Thus, the Flowchain transaction process represents a “mining-transaction-approval-verify” model. This mechanism is the foremost imperative Flowchain design component.

Algorithm 8

Algorithm 8 shows the method that N’ marks txID as verified after completing the approval request of the endpoint. At that point, Flowchain grants one FlowchainCoin token to N’. Note that N’ can get more FlowchainCoin by completing more approvals. In this way, Flowchain comprises a resource-based proof-of-stake mining approach to mine new blocks. An IoT node can store “tokens” by joining and completing “approval” jobs. The miner guarantees the node’s minimum resource requirements, such as network bandwidth, battery level, Wi-Fi signal quality, and the “coins.” In this way, the Flowchain difficulty algorithm uses the number of tokens held by a node along with the resource requirements to calculate the reliability probability. In brief, IoT nodes got to hold some amount of FlowchinCoin tokens in order to join the consensus process and submit their data transactions.

15/10/2019