...
Permissionless BCs were the first generation of Distributed Ledger Technology (DLT) to provide decentralized ledgers as opposed to centralized databases. Bitcoin and Ethereum are the most known representatives of permissionless BCs. Their 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 take advantage of assets being exchanged or discarded without notice by other peers. A disadvantage of permissionless blockchains is they do not 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.
...
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 for sensitive citizen and government data. The lack of control over permissionless BCs and the exit and entry of network participants makes make documents, records, historical data, and transactions containing citizens’ data visible.
Permissioned 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 to provide transparency to for participants. Permissioned BCs 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 accesses the network [12].
...
Smart Contracts (SC) [13] are computer programs immutably written on the blockchain that can be and called by 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 into three major categories:
- Static,
- Dynamic,
- Oracle driven
Depending on the specific use case to be implemented, the developer designs either dynamic, static, or oracle driven smart contracts. A definition of each, below, explores their different characteristics to assist researchers, architects, and developers to as they determine which is appropriate for their per use case.
Static standard output
Static SCs do not call other smart contracts, do not reside on human interaction, take place in one-step, and never change their predefined number of actions. Static SCs perform primitive math operations such as addition, subtraction, multiplication, and division. Other SCs can call, retrieve, and consume the results of their operation. All SCs receive parameters to perform actions and are somehow dynamic. However, there are no additional conditions embedded in static SCs to change their path of action. Math operations consistently reach the same result and operators follow the same precedence rules every time. SCs can return a ‘yes"yes/no” no" response to a specific question or return a standard image when an action is triggered. An EG 3.0 application example is a function that accepts a verification request for an academic diploma, looks to the ledger for the diploma holder, issues the institution name and date of issuance, and returns the result to the requester.
Dynamic non-standard output
Dynamic SCs embed various rules that allow them to perform different actions. Examples of dynamic SCs include functions that monitor certain conditions and trigger intended actions. For example, when a dynamic SC monitors electricity consumption and temperatures logged on the BC of an energy-smart building. The dynamic SC includes thresholds for heating and consumption measurements to adjust temperatures in an eco-friendly way designed to avoid excessive electricity consumption and cost. The following pseudocode offers the logic behind monitoring and execution:
if room_temperature < 18 Celcius {
...