[go: up one dir, main page]

Next Issue
Volume 2, September
Previous Issue
Volume 2, March
 
 

Blockchains, Volume 2, Issue 2 (June 2024) – 5 articles

  • Issues are regarded as officially published after their release is announced to the table of contents alert mailing list.
  • You may sign up for e-mail alerts to receive table of contents of newly released issues.
  • PDF is the official format for papers published in both, html and pdf forms. To view the papers in pdf format, click on the "PDF Full-text" link, and use the free Adobe Reader to open them.
Order results
Result details
Select all
Export citation of selected articles as:
22 pages, 3155 KiB  
Article
Situ-Oracle: A Learning-Based Situation Analysis Framework for Blockchain-Based IoT Systems
by Hongyi Bian, Wensheng Zhang and Carl K. Chang
Blockchains 2024, 2(2), 173-194; https://doi.org/10.3390/blockchains2020009 - 22 May 2024
Cited by 1 | Viewed by 1256
Abstract
The decentralized nature of blockchain enables data traceability, transparency, and immutability as complementary security features to the existing Internet of Things (IoT) systems. These Blockchain-based IoT (BIoT) systems aim to mitigate security risks such as malicious control, data leakage, and dishonesty often found [...] Read more.
The decentralized nature of blockchain enables data traceability, transparency, and immutability as complementary security features to the existing Internet of Things (IoT) systems. These Blockchain-based IoT (BIoT) systems aim to mitigate security risks such as malicious control, data leakage, and dishonesty often found in traditional cloud-based, vendor-specific IoT networks. As we steadily advance into the era of situation-aware IoT, the use of machine learning (ML) techniques has become essential for synthesizing situations based on sensory contexts. However, the challenge to integrate learning-based situation awareness with BIoT systems restricts the full potential of such integration. This is primarily due to the conflicts between the deterministic nature of smart contracts and the non-deterministic nature of machine learning, as well as the high costs of conducting machine learning on blockchain. To address the challenge, we propose a framework named Situ-Oracle. With the framework, a computation oracle of the blockchain ecosystem is leveraged to provide situation analysis as a service, based on Recurrent Neural Network (RNN)-based learning models tailored for the Situ model, and specifically designed smart contracts are deployed as intermediary communication channels between the IoT devices and the computation oracle. We used smart homes as a case study to demonstrate the framework design. Subsequently, system-wide evaluations were conducted over a physically constructed BIoT system. The results indicate that the proposed framework achieves better situation analysis accuracy (above 95%) and improves gas consumption as well as network throughput and latency when compared to baseline systems (on-chain learning or off-chain model verification). Overall, the paper presents a promising approach for improving situation analysis for BIoT systems, with potential applications in various domains such as smart homes, healthcare, and industrial automation. Full article
(This article belongs to the Special Issue Feature Papers in Blockchains)
Show Figures

Figure 1

Figure 1
<p>Baseline Designs: (<b>a</b>) the design is based on an on-chain approach, wherein learning-based Situ-analysis is directly implemented using smart contracts for both training and prediction processes; (<b>b</b>) the design is based on an off-chain approach, where analysis models are trained and deployed at each authority node. In this setup, the consensus protocol mandates that authorities provide both model inference results and model hashes for validation purposes.</p>
Full article ">Figure 2
<p>An Overview of the Proposed Situ-Oracle Framework (Using Smart-Living Home as an Example).</p>
Full article ">Figure 3
<p>Recurrent Neural Network Learning Model for Situ-analysis. (<b>a</b>) depicts the overall neural network structure: <math display="inline"><semantics> <mrow> <mi>T</mi> <mo>×</mo> <mo>(</mo> <mo>|</mo> <mi>S</mi> <mo>|</mo> <mo>+</mo> <mn>1</mn> <mo>)</mo> </mrow> </semantics></math>, where <math display="inline"><semantics> <mrow> <mo>|</mo> <mi>S</mi> <mo>|</mo> <mo>+</mo> <mn>1</mn> </mrow> </semantics></math> denotes the total number of sensors in <span class="html-italic">S</span> alongside the previous user intention <span class="html-italic">M</span>. (<b>b</b>) illustrates the unfolded iterative learning process of the Vanilla RNN-based model. Note that the input vector will be padded with zeros for <span class="html-italic">M</span> at <math display="inline"><semantics> <mrow> <mi>i</mi> <mo>=</mo> <mi>t</mi> </mrow> </semantics></math> and for any missing sensory readings for the consistency of the input vector.</p>
Full article ">Figure 4
<p>Sequence Diagram of the System Workflow.</p>
Full article ">Figure 5
<p>Accuracy Comparisons in Situ-analysis: The seven sub-datasets from the SIMADL dataset, each representing one of the seven participants with a duration of 1 month and a 0-min time margin, were trained and tested with four learning models individually: Decision Tree (DT), Locality-Sensitive Hashing (LSH), Naive Bayes (NB), and RNNs (Vallina RNN, LSTM, GRU). <math display="inline"><semantics> <mrow> <mi>T</mi> <mo>=</mo> <mn>1</mn> </mrow> </semantics></math> and <math display="inline"><semantics> <mrow> <mi>T</mi> <mo>=</mo> <mn>15</mn> </mrow> </semantics></math> were tested for DT, LSH, and NB; only <math display="inline"><semantics> <mrow> <mi>T</mi> <mo>=</mo> <mn>15</mn> </mrow> </semantics></math> were tested for RNNs.</p>
Full article ">Figure 6
<p>Actual block sealing times, <math display="inline"><semantics> <mi>μ</mi> </semantics></math>, observed for three Situ-analysis servicing frameworks, with three different target block generation times, i.e., 5, 10, and 15 s, executed on RPiv3b and RPiv4b sealer nodes.</p>
Full article ">Figure 7
<p>Estimated network throughput, measured in transactions per second (TPS), for three Situ-analysis servicing frameworks, with three different target block generation times, i.e., 5, 10, and 15 s, executed on RPiv3b and RPiv4b sealer nodes. Note: Due to the substantial discrepancies observed in the measured results, we adjusted the y-axis display to a logarithmic scale for better clarity and comparison of relations.</p>
Full article ">Figure 8
<p>The probability distribution of Situ-analysis concealing latency for 100 sensory (context) updates, conducted on three Situ-analysis servicing frameworks, with three different target block generation times, i.e., 5, 10, and 15 s, executed on RPiv3b and RPiv4b sealer nodes. Note: due to the substantial discrepancies observed in the results, we adjusted the x-axis display to a logarithmic scale for better clarity and comparison of relations.</p>
Full article ">Figure 9
<p>The Situ-analysis latency for each of the 100 sensory (context) updates. The Situ-Oracle framework and the off-chain model prediction method (baseline-2) maintained consistent and stable network traffic throughout the experiment. However, the baseline-1 system initially showed a manageable latency but was rapidly trapped by network congestion due to the excessive computational demand on each sealer node.</p>
Full article ">
23 pages, 1877 KiB  
Review
Blockchain for Organ Transplantation: A Survey
by Elif Calik and Malika Bendechache
Blockchains 2024, 2(2), 150-172; https://doi.org/10.3390/blockchains2020008 - 9 May 2024
Viewed by 1166
Abstract
As blockchain becomes more widely used, a growing number of application fields are becoming interested in blockchain to benefit from its decentralised nature, invariability, security, transparency, quick transaction capabilities, and cost-effectiveness. Blockchain has a wide range of applications and uses in healthcare. Distributed [...] Read more.
As blockchain becomes more widely used, a growing number of application fields are becoming interested in blockchain to benefit from its decentralised nature, invariability, security, transparency, quick transaction capabilities, and cost-effectiveness. Blockchain has a wide range of applications and uses in healthcare. Distributed ledger technology facilitates the secure transfer of patient medical records, manages the medicine supply chain, and creates an efficient, transparent, safe, and effective way of communicating data across global healthcare. The organ transplantation process (OTP) is one of the healthcare areas that benefit from the use of such technology to make its process more secure and transparent. In this article, we put forward a systematic literature review analysis on the application of blockchain to the OTP. Additionally, we address and highlight the barriers and challenges that arise while using blockchain technology for the OTP. We also offer some suggestions for future developments that would enhance blockchain’s implementation in the OTP domain. Full article
(This article belongs to the Special Issue Feature Papers in Blockchains)
Show Figures

Figure 1

Figure 1
<p>Organ transplantation process based on blockchain.</p>
Full article ">Figure 2
<p>Basic blockchain architecture.</p>
Full article ">Figure 3
<p>Blockchain workflow diagram.</p>
Full article ">Figure 4
<p>Number of publication types per year.</p>
Full article ">Figure 5
<p>Level of maturity of solutions offered by the reviewed papers.</p>
Full article ">
16 pages, 1268 KiB  
Article
Performance of PBFT Consensus under Voting by Groups
by Vojislav B. Mišić, Jelena Mišić and Xiaolin Chang
Blockchains 2024, 2(2), 134-149; https://doi.org/10.3390/blockchains2020007 - 26 Apr 2024
Viewed by 695
Abstract
Practical Byzantine Fault Tolerance (PBFT) is the protocol of choice for many applications that require distributed consensus between a number of participant nodes. While PBFT assumes a single voting committee, many applications recognize different groups of participants that need to reach a consensus [...] Read more.
Practical Byzantine Fault Tolerance (PBFT) is the protocol of choice for many applications that require distributed consensus between a number of participant nodes. While PBFT assumes a single voting committee, many applications recognize different groups of participants that need to reach a consensus separately before accepting a proposal. To this end, we propose to count the votes by separate groups or committees of participating nodes, instead of all together as in the original PBFT. We then investigate the performance impact of this approach on the mean time to accept a data block and the number of nodes involved in making the final decision. Our results indicate that the proposed solutions impose a slight performance penalty which may be countermanded by reducing the quorum numbers needed in different subsets of the original committee. Full article
(This article belongs to the Special Issue Feature Papers in Blockchains)
Show Figures

Figure 1

Figure 1
<p>Operation of PBFT consensus (after [<a href="#B6-blockchains-02-00007" class="html-bibr">6</a>]).</p>
Full article ">Figure 2
<p>The impact of split voting on quorum delays. (<b>a</b>) The case of joint vote: node <span class="html-italic">i</span> receives the necessary votes to achieve quorum at time <math display="inline"><semantics> <msub> <mi>τ</mi> <mi>i</mi> </msub> </semantics></math>. (<b>b</b>) The case of split vote: node <span class="html-italic">i</span> receives votes at time <math display="inline"><semantics> <msub> <mi>τ</mi> <mi>i</mi> </msub> </semantics></math>.</p>
Full article ">Figure 3
<p>Baseline performance: MODE-1 voting with 25 orderers. (<b>a</b>) Mean queueing delay for a block (i.e., time from receiving a block to sending a PREPREPARE broadcast). (<b>b</b>) Mean time to accept a block. (<b>c</b>) Number of blocks sent in but not yet accepted.</p>
Full article ">Figure 4
<p>Performance of MODE-2 voting with 25 orderers in two voting committees. (<b>a</b>) Mean time to accept a block for MODE-2 with separate voting at both PREPARE and COMMIT stages vs. corresponding time for MODE-1. (<b>b</b>) Mean time to accept a block for MODE-2 with separate voting at COMMIT stage only vs. corresponding time for MODE-1. (<b>c</b>) Number of blocks not yet accepted under MODE-2 with separate voting at both PREPARE and COMMIT stages. (<b>d</b>) Number of blocks not yet accepted under MODE-2 with separate voting at COMMIT stage only. (<b>e</b>) Mean number of orderer nodes that confirmed a block at the time consensus is reached under MODE-2 with separate voting at both PREPARE and COMMIT stages. (<b>f</b>) Mean number of orderer nodes that confirmed a block at the time consensus is reached under MODE-2 with separate voting at COMMIT stage only.</p>
Full article ">Figure 5
<p>Performance of MODE-3 voting with 25 orderers in three voting committees. (<b>a</b>) Mean time to accept a block in MODE-3 voting at both PREPARE and COMMIT stages vs. corresponding time for MODE-1. (<b>b</b>) Mean time to accept a block in MODE-3 with voting by bloc at COMMIT stage only vs. corresponding time for MODE-1. (<b>c</b>) Number of blocks not yet accepted in MODE-3 voting at both PREPARE and COMMIT stages. (<b>d</b>) Number of blocks not yet accepted in MODE-3 with voting by bloc at COMMIT stage only. (<b>e</b>) Mean number of orderer nodes that confirmed a block at the time consensus is reached under MODE-3 with voting by bloc at both PREPARE and COMMIT stages vs. corresponding number for MODE-1. (<b>f</b>) Mean number of orderer nodes that confirmed a block at the time consensus is reached under MODE-3 with voting by bloc at COMMIT stage only vs. corresponding number for MODE-1.</p>
Full article ">Figure 6
<p>Performance of the system under variable number of orderers: delays and delay ratios. Symbols denote data points, lines are linear approximation of those points. (<b>a</b>) Delays in MODE-1. (<b>b</b>) Delay ratios vs. MODE-1, orderer area factor <math display="inline"><semantics> <mrow> <mi>δ</mi> <mo>=</mo> <mn>0.2</mn> </mrow> </semantics></math>, block arrival rate 25 bps. (<b>c</b>) Delay ratios vs. MODE-1, orderer area factor <math display="inline"><semantics> <mrow> <mi>δ</mi> <mo>=</mo> <mn>0.8</mn> </mrow> </semantics></math>, block arrival rate 25 bps. (<b>d</b>) Delay ratios vs. MODE-1, orderer area factor <math display="inline"><semantics> <mrow> <mi>δ</mi> <mo>=</mo> <mn>0.2</mn> </mrow> </semantics></math>, block arrival rate 85 bps. (<b>e</b>) Delay ratios vs. MODE-1, orderer area factor <math display="inline"><semantics> <mrow> <mi>δ</mi> <mo>=</mo> <mn>0.8</mn> </mrow> </semantics></math>, block arrival rate 85 bps.</p>
Full article ">Figure 7
<p>Performance of the system under variable number of orderers: mean number of orderer nodes that confirmed a block at the time consensus is reached. (<b>a</b>) Orderer area factor <math display="inline"><semantics> <mrow> <mi>δ</mi> <mo>=</mo> <mn>0.2</mn> </mrow> </semantics></math>, block arrival rate 25 bps. (<b>b</b>) Orderer area factor <math display="inline"><semantics> <mrow> <mi>δ</mi> <mo>=</mo> <mn>0.8</mn> </mrow> </semantics></math>, block arrival rate 25 bps. (<b>c</b>) Orderer area factor <math display="inline"><semantics> <mrow> <mi>δ</mi> <mo>=</mo> <mn>0.2</mn> </mrow> </semantics></math>, block arrival rate 85 bps. (<b>d</b>) Orderer area factor <math display="inline"><semantics> <mrow> <mi>δ</mi> <mo>=</mo> <mn>0.8</mn> </mrow> </semantics></math>, block arrival rate 85 bps.</p>
Full article ">
27 pages, 2820 KiB  
Article
Information Sharing in Land Registration Using Hyperledger Fabric Blockchain
by Reyan M. Zein and Hossana Twinomurinzi
Blockchains 2024, 2(2), 107-133; https://doi.org/10.3390/blockchains2020006 - 16 Apr 2024
Cited by 1 | Viewed by 1347
Abstract
Blockchain technology is increasingly being recognized for its pivotal role in enhancing security, immutability, and transparency across government sectors, notably in land registration (LR) processes. This research emphasizes the need for contextually adapted blockchain technology solutions, particularly in resource-constrained and culturally diverse settings. [...] Read more.
Blockchain technology is increasingly being recognized for its pivotal role in enhancing security, immutability, and transparency across government sectors, notably in land registration (LR) processes. This research emphasizes the need for contextually adapted blockchain technology solutions, particularly in resource-constrained and culturally diverse settings. Utilizing the elaborated action design research method, this study presents a Hyperledger-based blockchain technology system tailored for Sudan’s LR, addressing technical challenges, evaluation frameworks, privacy measures, and deployment strategies. This system not only facilitates secure and transparent land transactions from planning to certificate issuance, but also integrates the management of land sales, significantly reducing the need for intermediaries. By providing a detailed exploration of the system’s goals, technical hurdles, and practical deployment insights, this research contributes valuable knowledge to the implementation of blockchain technology in LR, with findings that are applicable to similar contexts globally. This study underscores the importance of customizing blockchain solutions to meet the unique requirements of different environments, thereby advancing digital government in resource-constrained settings. Full article
Show Figures

Figure 1

Figure 1
<p>Current land registration processes in Sudan.</p>
Full article ">Figure 2
<p>Hyperledger Fabric transaction flow sequence diagram.</p>
Full article ">Figure 3
<p>The proposed BLRS architecture.</p>
Full article ">Figure 4
<p>The proposed BLRS Hyperledger network.</p>
Full article ">Figure 5
<p>BLRS consensus mechanism.</p>
Full article ">Figure 6
<p>Land registration dataflow diagram.</p>
Full article ">Figure 7
<p>Land sale dataflow diagram.</p>
Full article ">
28 pages, 1647 KiB  
Article
Decision Model to Design Trust-Focused and Blockchain-Based Health Data Management Applications
by Christina Erler, Ann-Marit Bauer, Friedrich Gauger and Wilhelm Stork
Blockchains 2024, 2(2), 79-106; https://doi.org/10.3390/blockchains2020005 - 9 Apr 2024
Viewed by 905
Abstract
Many Blockchain-based approaches have been published in the field of health data management applications (HDMAs). However, no comprehensive guideline exists to guide the multiple and interdependent design decisions to develop such systems. This paper aims to support the HDMA system design processes by [...] Read more.
Many Blockchain-based approaches have been published in the field of health data management applications (HDMAs). However, no comprehensive guideline exists to guide the multiple and interdependent design decisions to develop such systems. This paper aims to support the HDMA system design processes by introducing a novel decision model. The model considers all relevant requirements, from regulatory context to user needs and trust considerations. To generate the decision model, we define a taxonomy that organizes previously published approaches by their technical design features and combines it with the trust assumptions of the participating actors according to the STRIDE method. The model aims to support a cohesive overall system design by addressing Blockchain type, off-chain storage, identity and access management, security decisions, and the specific use case of data donation. A group of experts evaluated the decision tree and its utility is demonstrated in three representative use cases. Special attention is paid to the use case of data donation via a data trustee, which is examined in detail. Full article
(This article belongs to the Special Issue Feature Papers in Blockchains)
Show Figures

Figure 1

Figure 1
<p>Steps in preparation of applying the proposed decision model, e.g. according to Wüst and Gervais 2028 [<a href="#B17-blockchains-02-00005" class="html-bibr">17</a>] and STRIDE method [<a href="#B13-blockchains-02-00005" class="html-bibr">13</a>,<a href="#B16-blockchains-02-00005" class="html-bibr">16</a>].</p>
Full article ">Figure 2
<p>The resulting decision model.</p>
Full article ">Figure 3
<p>The data storage types sub-decision model.</p>
Full article ">Figure 4
<p>The general data sharing sub-decision model.</p>
Full article ">Figure 5
<p>The research data sharing sub-decision model.</p>
Full article ">Figure 6
<p>The access control logic sub-decision model.</p>
Full article ">Figure 7
<p>The access granting security sub-decision model.</p>
Full article ">Figure 8
<p>The data storage security sub-decision model.</p>
Full article ">Figure 9
<p>Proposed system concept for the data trustee system to support data donation.</p>
Full article ">
Previous Issue
Next Issue
Back to TopTop