Comparative study of permissioned blockchain solutions for enterprises

Performance analysis of lightweight Internet of things devices on blockchain networks

“…Quorum is an open-source enterprise blockchain infrastructure based on Ethereum [10,33]. Quorum provides Raft and IBFT as its consensus protocols.…”

“…Raft achieves very fast results compared to other known consensus algorithms. Unlike PoW, it works on permissioned and private blockchain networks where the goal is to get a faster consensus [10].…”

“…Depending on the reliability of the network's participants, either slow consensus algorithms that require more power or more efficient and fast consensus algorithms can be preferred. Quorum (github.com/ConsenSys/quorum) is a permissioned blockchain framework, which was introduced by JP Morgan [10]. Quorum is open-source and based on Ethereum, but Quorum uses different consensus algorithms (Raft and IBFT) and provides private transactions and contracts.…”

A Study on the Adoption of Blockchain for IoT Devices in Supply Chain

“…Nadir [ 18 ] contributed towards contrasting the permissioned blockchain leading houses Fabric, Corda, and Quorum blockchain based on comparison filters of modularity, language support, privacy, transactions per second, currency support, and adaptability. The comparison filters are scaled between 1 and 3 and computing the final score, representing the overall adaptability of the framework.…”

“…After that, the LogRequestMsg message is packed with a whole bunch of information related to log characteristics as well as the new entries and is sent to the follower node that the follower node will use to update its log. In Algorithm 5, when the LogRequestMsg message to update log is received at the follower node from the Rep-licateLogMsg function; it first compares the argument variable term with its presentTerm if the argument passed value is greater, then it updates its term to the latest term, (1) on initialization do (2) presentTerm � 0; votedForNode � null; log � < > ; committedLength � 0 (3) presentRole � follower; presentLeader � null (4) votesReceived � { }; sentEntriesLength � < > ; ackedEntriesLength � < > (5) end (6) on recovery from crash do (7) presentRole � follower; presentLeader � null (8) votesReceived � { }; sentEntriesLength � < > ; ackedEntriesLength � < > (9) end (10) on node nodeId suspects leader has failed, or on selection timeout do (11) if logOk ∧ termOk then (7) presentTerm � candidateTerm; presentRole � follower; votedForNode � candidateId (8) msg � (VoteRequestMsg, candidateId, candidateTerm, candidateLogLength, candidateLogTerm) (9) kNodes � kRandomNodes ⊂ nodes (10) for each node ∈ kNodes send (11) msg to node (12) end (13) send (VoteResponseMsg, nodeId, presentTerm, true) to node candidateId ( 14) else (15) send (VoteResponseMsg, nodeId, presentTerm, false) to node candidateId ( 16) end (17) end (18) end ALGORITHM 2: Voting on a new leader, at FOLLOWER side. 16 Computational Intelligence and Neuroscience resets its votedForNode variable to null, converges to "follower" state, and updates its presentLeader variable with the new leader.…”