Securing Smart Cities through Blockchain Technology: Architecture, Requirements, and Challenges
Bibliographic record
Abstract
In recent years, unprecedented work has been done in the area of smart cities. The purpose of developing smart cities is to enhance quality of life factors for people dwelling within them. To achieve that purpose, technologies such as IoT and cloud computing have been utilized. Blockchain technology is also among the promising technologies that can offer countless valuable services to its end users. It is a immutable programmable digital register for the purpose of recording virtual assets having some value and was primarily developed for digital currencies like Bitcoin. To fully utilize the services of blockchain technology within smart cities, characteristics of blockchain technology, and its key requirements and research challenges need to be identified. Hence, in this article, an attempt has been made to identify the characteristics of blockchain technology. Furthermore, indispensable requirements for incorporating blockchain technology within smart cities are enumerated. A conceptual architecture for securing smart city using blockchain technology is proposed and explained using a possible use case study. An overview of a real-world three-blockchain- based smart city case study is also presented. Finally, several imperative research challenges are identified and discussed.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.002 | 0.003 |
| Meta-epidemiology (narrow) | 0.000 | 0.000 |
| Meta-epidemiology (broad) | 0.000 | 0.000 |
| Bibliometrics | 0.001 | 0.001 |
| Science and technology studies | 0.001 | 0.002 |
| Scholarly communication | 0.005 | 0.008 |
| Open science | 0.001 | 0.002 |
| Research integrity | 0.002 | 0.001 |
| Insufficient payload (model declined to judge) | 0.002 | 0.001 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".