...
Permissionless BCs were the first generation of Distributed Ledger Technology (DLT) to provide decentralization decentralized ledgers as opposed to centralized databases. Bitcoin and Ethereum are the most known representatives of permissionless BCs. Their concept premise is that all transactions are transparent to every participant and are written on the ledger only after a consensus of the majority of peers is achieved. Each participant shares an identical copy of this data, called state, that is formed of blocks connected to each other through cryptographic hashes. This architecture makes it almost impossible to change or trick others about the data state or to take advantage of assets being exchanged or discarded without notice by other peers. A disadvantage of permissionless blockchains is they do not have support any control over who enters or leaves the network. This lack of control can be detrimental for security and may lead to energy-draining and time-consuming block generation techniques [11] to enforce security. The potential side effects of block generation include system scalability and speed.
Nevertheless, permissionless Permissionless BCs can be ideal for EG 3.0 applications when data must be public and transparent. Such use cases may include the education sector verified and shared certificates, degrees, and diplomas issued by governmental organizations and academic institutions [40][41]. Other use cases include publishing voting results and disseminating publicly available documents and copyrights.
...
Due to BC’s unique characteristics of immutability and decentralization, blockchain technology evolved beyond BC 1.0 to business priorities such as asset tracking and logging, consent and agreement enforcement and monitoring, and identity authentication and authorization. Permissionless blockchains achieve a great deal of decentralization; however, they can not guarantee the privacy and safety needed with sensitive citizen and government data. The lack of control over permissionless BCs and the exit and entry of network participants makes documents, records, historical data, and transactions containing citizens’ data visible.
Permissioned Blockchains blockchains such as Hyperledger (HL) Fabric answer the need for private, decentralized, secure, and verifiable transactions among governments, citizens, and businesses. Although all transactions are written through smart contracts to the ledger, as they are in BC 1.0, permission must be given to access any data. On permissioned BCs, participants are strictly controlled by a central authority. In an EG use case, this may be a ministry or an independent authority. Blockchain policies exist on the network to grant permission to stakeholders to perform specific actions. For example, a citizen must be informed that a public administration organization requests specified data and the citizen must consent for access to be granted. These requests and consent actions are written on the blockchain, providing transparency to participants. Permissioned BCs answer address the need for privacy, scalability, security, and speed, although compromises are made in decentralization. When a central authority is introduced to authorize the private network’s participants, decentralization is hindered and a BC controlling authority is introduced to accesses the network [12].
Permissioned BCs are ideal for governmental applications that require a level of security such as an internal exchange of documents among public organizations for inventories, registries, or other private records.
Smart Contracts
Smart Contracts (SC) [13] are computer programs immutably written on the blockchain and that can be called by the BC’s BC participants. SCs provide the automation and control flow logic to any system BCs support. Smart contracts must be treated as software functions in every aspect and smart contract BC engines must be deterministic. The determinism of SCs is the characteristic that maintains the ledger at a stable, consistent state, enforces transaction finality, and avoids soft and hard forks [14]. The determinism of SC’s actions is usually left to the developer. Thus, she must ensure automated actions are executed as planned and that the results of these actions leave the data in a consistent state, regardless of the node(s) they are executed on. SC’s actions must achieve the same result each time the SC is executed. In the writers’ opinions, derived from empiricism, smart contracts can be categorized in three major categories:
...