Submitted Successfully!
To reward your contribution, here is a gift for you: A free trial for our video production service.
Thank you for your contribution! You can also upload a video entry or images related to this topic.
Version Summary Created by Modification Content Size Created at Operation
1 -- 2384 2023-10-19 09:42:43 |
2 format correct Meta information modification 2384 2023-10-19 10:04:29 |

Video Upload Options

Do you have a full video?

Confirm

Are you sure to Delete?
Cite
If you have any further questions, please contact Encyclopedia Editorial Office.
Ghaffari, F.; Aryal, N.; Bertin, E.; Crespi, N.; Garcia-Alfaro, J. Blockchain Technology for Service Provisioning in Cellular Networks. Encyclopedia. Available online: https://encyclopedia.pub/entry/50507 (accessed on 08 July 2024).
Ghaffari F, Aryal N, Bertin E, Crespi N, Garcia-Alfaro J. Blockchain Technology for Service Provisioning in Cellular Networks. Encyclopedia. Available at: https://encyclopedia.pub/entry/50507. Accessed July 08, 2024.
Ghaffari, Fariba, Nischal Aryal, Emmanuel Bertin, Noel Crespi, Joaquin Garcia-Alfaro. "Blockchain Technology for Service Provisioning in Cellular Networks" Encyclopedia, https://encyclopedia.pub/entry/50507 (accessed July 08, 2024).
Ghaffari, F., Aryal, N., Bertin, E., Crespi, N., & Garcia-Alfaro, J. (2023, October 19). Blockchain Technology for Service Provisioning in Cellular Networks. In Encyclopedia. https://encyclopedia.pub/entry/50507
Ghaffari, Fariba, et al. "Blockchain Technology for Service Provisioning in Cellular Networks." Encyclopedia. Web. 19 October, 2023.
Blockchain Technology for Service Provisioning in Cellular Networks
Edit

The attention on blockchain technology (BCT) to create new forms of relational reliance has seen an explosion of new applications and initiatives, to assure decentralized security and trust. Its potential as a game-changing technology relates to how data gets distributed and replicated over several organizations and countries. 

blockchain technology distributed ledger smart contract access control

1. Introduction

Blockchain technology (BCT), as the foundational design of distributed ledger technology (DLT), has revolutionized many aspects of business models and operations. Based on the traditional idea of hash chains to assure the integrity of data over distributed computing scenarios, BCT is believed to bring innovative new solutions, due to its key characteristics, such as decentralization, transparency, and immutability. Decentralization relies on the distribution of nodes over a global network, whose records are stored in registers (e.g., blocks) containing every transaction initiated in the system. All transactions are verified by multiple entities and securely recorded several times, through the use of encryption keys and electronic signatures. Records cannot be reversed, modified, or repudiated, thus creating an irrevocable and verifiable history of transactions. Registry management is decentralized and operates without a control body or centralized storage.
The use of BCT has received increasing attention, with Bitcoin [1] being the most famous application in the realm of cryptocurrencies, as well as Ethereum [2] and the extension of the concept of smart contracts [3], to autonomously execute agreements reached between distributed nodes. Together, these methods offer new possibilities to validate data transactions while offering traceability in a wide range of complex scenarios, far beyond the original usage of cryptocurrencies [4]. Examples include copyright management, sharing healthcare information, supply data, and real state control [5][6][7]. The intrinsic advantages of BCT are expected to change many aspects of business models, management, and operations in a range of fields. The list of major actors who reportedly explore BCT grows almost weekly [8]. Their expectations may vary and include potential cost savings, maintenance of technology leadership, and securing future business models.

2. Blockchain and Distributed Ledger Technologies

Blockchain technology’s (BCT) proposal dates from 2009 [1], and it is tied to the Bitcoin cryptocurrency, where a practical implementation of the traditional concept of hash chains to ensure data integrity was revisited. A hash chain is the successive application of a cryptographic hash function to continuous flows of data transactions. In BCT, the authenticity of such transactions is also assured by digitally signing them by a sender, before broadcasting the result to a peer-to-peer network [9]. Special BCT users in that peer-to-peer network, known as miners. The term miner is commonly used in consensus models derived from the Bitcoin cryptocurrency. For the other consensus models, terminologies such as block validator or leader can replace the term miner). In the realm of cryptocurrencies, miners perform two main validations on the transactions. First, miners validate the correctness of the digital signature associated with the transaction. Second, miners validate that the the transaction is logically valid based on the policies in the network (e.g., in the case of a cryptocurrency, miners validate that the traded asset belongs to the sender and does not involve any double spending). If both validations succeed, the miners include the transaction in the next block of the chain, hence validating the consensus protocol underlying the network governance.
The workflow of processing the transactions and block generation in the BCT is depicted in Figure 1, in a simple example of trading between two entities. First, a transaction is initiated and broadcast to other nodes in the network. Then, the nodes which receive the transaction use the digital signature to verify the authenticity of the transaction. Once a transaction is validated, it is included in the list of valid transactions in the nodes. In the third step, the miners need to record the transaction into a new block and add it to the chain. To record the verified transactions, miners work to publish the new block (e.g., in the consensus model associated with the Bitcoin cryptocurrency, miners conduct this procedure by finding a potential Nonce to reach an agreement) and store a block of transactions in the ledger. Finally, other miners can then verify all the transactions stored in the block via the Merkle root. If all other verification steps hold correct information (e.g., authentication, integrity, lack of double spending, etc.) the new block is also added to their local replicas of the ledger. Indeed, two main concerns in this simple example (as well as other Blockchain-based distributed systems) are the lack of centralized authority to manage the synchronization of the transactions, as well as their ordering, and the integrity of data.
Figure 1. Use of a BCT system for trading assets between two nodes A and B. The ‘?’ symbol in Steps 2 and 4 refer to the execution of a given procedure by network nodes (e.g., transaction validation process in Step 2, and block replication in Step 4).
Addressing the challenges of data transaction ordering, synchronization, and integrity of data in BCT is done by the difficulty of rolling back in the chain of blocks. This provides strong immutability in BCT that makes the partial chain rendering unfeasible. In other words, by hashing the preceding block and inserting this amount as a header in the current block, any simple modification of a transaction included in previous blocks would require solving a consensus problem for all of the subsequent blocks. To assure that the whole chain of blocks becomes immutable, the inclusion of a new block in the BCT system must entail a given degree of difficulty. This is conducted by requesting the miners to perform some particular tasks defined in the consensus algorithm that may differ from every specific BCT implementation.
In addition to immutability, many other opportunities are provided by BCT designs. First of all, BCT allows for the creation of a new distributed paradigm, in which not only there is no centralized authority to control the network, but network failures are handled in a distributed manner. As a result, BCT-based systems can provide a high level of availability and fault tolerance. The idea to achieve this is the following. All nodes in a BCT system rely on consensus theory (i.e., a well-established sets of rules and algorithms to ensure that everyone behaves as expected). This assures the integrity-by-design feature. Additional properties associated with BCT systems include traceability, transparency, non-repudiation and permanence. Traceability and transparency mean that all data transactions are available to be seen and tracked by any nodes with access to the system. In other words, data must always be available and traceable at any time. Non-repudiation in BCT means that nobody can deny their actions in the system. The use of cryptography in BCT ensures that all parties must digitally sign their actions, hence avoiding the possibility of action denial by BCT entities. Finally, permanence means that all data in a BCT can be available at any time (nothing may be removed from the network).
In terms of data structures associated with BCT, blocks are composed of a body and a header (cf. Figure 2). The body stores the transaction data. The header contains metadata, such as the hash of the previous block, a timestamp, a cryptographic Nonce (i.e., a number used only once, for security purposes), and a Merkle root. The hash value is calculated by passing the header of the previous block to a hash function. The timestamp is used to keep track of the specific creation time of the block. The Merkle tree is a binary data structure, in which each leaf node is labeled with the hash of one transaction stored in the block body, and the non-leaf nodes are labeled with the concatenation of the hash of its child nodes. The Merkle root represents the root hash of the Merkle tree. It is used for performance purposes, such as optimizing the search time during the verification of transactions contained in the Blockchain. Any modification affecting a transaction (i.e., even a bit-flip) will render to a different Merkle root; hence verification and comparisons can be conducted by simply looking at the Merkle root of the block, without the need to go through all the transactions stored in a block.
Figure 2. Structure of a BCT design and its use of Merkle trees.
The more general concept of distributed ledger technology (DLT) includes aforementioned designs around the concept of blocks and Merkle trees, as well as alternative designs, including different data structures, consensus algorithms, and governance solutions. Blocks can be replaced by other non-linear data families, including with the use of directed acyclic graph (DAG) or any other hybrid data structures. Different designs can be classified depending on the rule that regulates as to which nodes can access, verify and validate the transactions in the system [10]. DLT platforms associated with Bitcoin and Ethereum represent the idea of permissionless (public) ledgers, i.e., DLT designs whose ledgers are accessible to the public. In other words, these are designs in which any participant can broadcast new transactions, participate in the consensus procedures, write into the ledger, etc. While Bitcoin and Ethereum mainly represent existing DLT examples underlying contractual decentralized transaction models, some other existing frameworks extend them to address applications in different domains, such as https://ripple.com/ (accessed on 21 February 2023), for banking applications, https://www.energyweb.org/ (accessed on 21 February 2023), for energy, https://www.hyperledger.org/ (accessed on 22 April 2023), for supply chain, logistics, and much more, etc. In all those previous cases, and by granting the authority of maintaining a ledger to all the nodes, public ledgers may also become fully distributed and even allow scenarios with anonymity requirements. However, these systems suffer from the low speed of transaction validation and require a certain level of computation to secure them regarding the intrinsic vulnerabilities of DLT.
Permissioned designs can be used to construct either private or consortium DLT-platforms. The former is related to the solutions that are usually maintained by a single organization, i.e., the ledger is developed in specific organizations based on their needs. The rights to access the ledger and to verify the transactions are granted through a central controller to the permissioned nodes. A permissioned network is thus established, in which only the authorized nodes can access certain transactions of the ledger or participate in working to publish new blocks. Due to having a minimum level of trust among the nodes in the permissioned network, the computation-intensive consensus algorithm can be either omitted or replaced by a simpler algorithm. Hence, the secrecy of the transactions is highly improved and the decentralization of authority of transaction validation is under the control of the organization. A second subcategory of permissioned designs leads to consortium ledgers, which are similar to the private ones, in the sense that they are maintained in a permissioned network, but differ from private ledgers, since they involve multiple organizations to share the right to access and validate the transactions. Although these organizations might not fully trust each other, they can work together by altering the consensus algorithm, based on the level of trust among them. Consortium platforms can also be used as a distributed and reliable database for predefined enterprises for business-to-business purposes. However, only the eligible nodes, defined by participating organizations, can join in the consensus process. The anonymity of users can be violated. Moreover, the use of tokens or fees is not mandatory for the process or for validation of transactions.

3. Smart Contracts Enabled by BCT

Originally defined in the mid-1990s [3], the concept of smart contracts refers to automated agreements among mutually distrusting parties [11], without the need for a trusted intermediary. Users can request the execution of a smart contract via peer-to-peer network transactions of a distributed ledger, i.e., each execution request gets logged into a public, append-only Blockchain. Potential conflicts in the execution of each execution requests are also handled through the distributed ledger, i.e., using its associated consensus protocol.
The operation of a smart contract is briefly described next, with a representative example [12], in which an entity A agrees to remunerate a second entity B for setting up a new service. The remuneration is expected to be conducted in two steps. First, 70% of the total remuneration is assumed upon completion of an initial configuration step. Then, 30% of the total remuneration occurs two months after the full completion of the service, thus making it possible to validate the service of B. The contractual establishment is conducted in two main stages. During the first stage, entities A and B establish a smart contract between them. A and B have assumed valid accounts related to a given Blockchain. The smart contract between A and B is also stored over the Blockchain, as a special entity that conceptually resembles the instantiation of an object and which defines various operational rules in the form of publicly exposed methods. 
Notice that the previously formalized agreement between A and B is executed upon the ledger in an automated manner. Each change of state of the program is a recorded transaction. Neither of the two parties (nor anyone else) can perturb the execution of the contract. The stages of the service associated with B are checked automatically, and if these are carried out, the planned contributions are rewarded to B in the form of transactions associated with B within the ledger itself. In the end, whenever all the conditions (i.e., agreements) are met, the transaction is completed and B becomes the owner of the assets. Otherwise, if the conditions are not properly satisfied, A remains the owner (i.e., A recovers the amount due). The deployment of smart contracts on top of a DLT platform, such as Ethereum, can generally be done by the development of decentralized application (DApp), which are digital applications or programs that exist and run on a distributed network of computers instead of a single computer. In terms of data structures, platforms such as Ethereum also generalize the approach depicted in Figure 2, with some more elaborated data structures. Each block header (w.r.t. the approach depicted in Figure 2) can now be tied to several trees; one tree is used to store the transactions, another is used to store the state, and a third tree is used to store the results. The combination of Merkle trees together with Patricia trees [13] is the fundamental data structure on which Ethereum is built.

References

  1. Nakamoto, S. Bitcoin: A Peer-to-Peer Electronic Cash System. Decentralized Business Review 2008. p. 21260. Available online: https://assets.pubpub.org/d8wct41f/31611263538139.pdf (accessed on 12 April 2023).
  2. Wood, G. Ethereum: A secure decentralised generalised transaction ledger. Ethereum Proj. Yellow Pap. 2014, 151, 1–32.
  3. Szabo, N. Formalizing and securing relationships on public networks. First Monday 1997, 2.
  4. Ali, M.S.; Vecchio, M.; Pincheira, M.; Dolui, K.; Antonelli, F.; Rehmani, M.H. Applications of blockchains in the Internet of Things: A comprehensive survey. IEEE Commun. Surv. Tutor. 2018, 21, 1676–1717.
  5. Jing, N.; Liu, Q.; Sugumaran, V. A blockchain-based code copyright management system. Inf. Process. Manag. 2021, 58, 102518.
  6. Saari, A.; Vimpari, J.; Junnila, S. Blockchain in real estate: Recent developments and empirical applications. Land Use Policy 2022, 121, 106334.
  7. Xi, P.; Zhang, X.; Wang, L.; Liu, W.; Peng, S. A review of Blockchain-based secure sharing of healthcare data. Appl. Sci. 2022, 12, 7912.
  8. García-Corral, F.J.; Cordero-García, J.A.; de Pablo-Valenciano, J.; Uribe-Toril, J. A bibliometric review of cryptocurrencies: How have they grown? Financ. Innov. 2022, 8, 2.
  9. Donet, J.A.; Pérez-Sola, C.; Herrera-Joancomartí, J. The bitcoin P2P network. In Financial Cryptography and Data Security: FC 2014 Workshops, BITCOIN and WAHC 2014, Christ Church, Barbados, 7 March 2014, Revised Selected Papers; Springer: Berlin, Germany, 2014; pp. 87–102.
  10. Zheng, Z.; Xie, S.; Dai, H.N.; Chen, X.; Wang, H. Blockchain challenges and opportunities: A survey. Int. J. Web Grid Serv. 2018, 14, 352–375.
  11. Lande, S.; Zunino, R. SoK: Unraveling Bitcoin smart contracts. In Proceedings of the 7th International Conference on Principles of Security and Trust, Thessaloniki, Greece, 14–20 April 2018; pp. 217–242.
  12. Dumas, J.G.; Lafourcade, P.; Tichit, A.; Varrette, S. Les Blockchains en 50 Questions-2éd.: Comprendre le Fonctionnement de Cette Technologie; Dunod: Malakoff, France, 2022.
  13. Morrison, D. PATRICIA—Practical algorithm to retrieve information coded in alphanumeric. J. ACM 1968, 15, 514–534.
More
Information
Subjects: Telecommunications
Contributors MDPI registered users' name will be linked to their SciProfiles pages. To register with us, please refer to https://encyclopedia.pub/register : , , , ,
View Times: 114
Revisions: 2 times (View History)
Update Date: 19 Oct 2023
1000/1000
Video Production Service