Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Added Smart Contracts Code

...

This kind of blockchain technology for financial payments automation without intermediaries is known as Blockchain 1.0. The technology acknowledged as Blockchain 2.0 followed with the Ethereum project [8], which differed from BC 1.0 because of its support to smart contracts (SC) usage. Other BC 2.0 technology projects followed, such as Hyperledger’s HL Fabric, Sawtooth, Iroha [9] and R3’s Corda [10] to name a few. Smart Contracts (SC) are computer programs written and run on the blockchain to provide security and automation to the system, making it possible for participating parties to agree upon certain conditions and according actions to be performed when these conditions are met. These features of SCs reshaped even more the supply chain processes by enabling additional on-chain actions as assets tracking, and in parallel, equipped BCs with the necessary characteristics to be used in other business cases, apart from the supply chain. Actually, BC is now used in many industries such as healthcare [1][2], education [3], government [4], charities [5], real estate [6], insurance [16] and banking [15]. This expanded field of applications supported by BC is actually called Blockchain 3.0, because solutions are no longer restricted to finance actions and assets transfer, but include the above-mentioned sectors and according expanded actions to support the logic behind them [18] [19].   So, with the rise of Blockchain 3.0 technology (2019) based on DAG data structures such as Byteball and IOTA, Blockchain systems are more efficient, scalable, highly interoperable, and have a better user experience than before. Among these sectors, government use cases are of special interest, because of the implications they introduce when adopting BC infrastructure to support them.With the rise of Blockchain 3.0 technology based on Directed Acyclic Graph DAG data structures [39], BC systems are more efficient, scalable, highly interoperable, and have a better user experience than before. Among the abovementioned sectors, government use cases are of special interest, because of the implications they introduce when adopting BC infrastructure to support them. These implications are coming from internal ones related to governmental issues such as politicians’ inaction and opposition, as well as external ones such as the unready for digital transformation laws and sensitive citizens’ and civil servants’ personal data [17]. The BC’s characteristics of decentralization providing zero down-time, immutability ensuring tamper-proof data, non-repudiation and security implemented with cryptography establishing trust between participating parties, consensus algorithms for data integrity, verification and satisfying scalability on private and permissioned blockchains [20] can be both accelerators and obstacles when applied to e-government EG applications.

...

A SC is used for gathering energy consumption and production measurements form the citizen’s IoT devices in order to log them on the blockchain. The citizen has to provide the BC identity that has been issued to her in order to login. This identity can be self-sovereign in order to be secure and remain at user’s control [44]. A SC is used for dispatching of the extra energy from a citizen’s residence to the main energy system or to the citizen-sourced smart grid she participates. If, for example, daily consumption needs are 14kWh and the SC detects that the power produced from renewable sources exceeds 15kWh, it can automatically trigger an action in order to dispatch this available power to the local energy system. In addition, there must be a dynamic smart contract to deposit the predefined amount of money for the energy dispatched by the citizen. Oracle based SCs can inform citizens when the energy dispatching can be more profitable, to provide incentives for participating to the energy network. Smart grids can be formed by local policies taking under consideration geographic factors, energy needs, and building production capabilities. AI agents will run at the citizens residences forming a collective decision making mechanism to apply Swarm Intelligence SI and achieve a swarm goal [34], programmed to decide how much energy can be dispatched to the city’s central energy system and how much energy can be traded among the participants on a smart grid. AI EG applications can read the data written on the BC and make forecasting of city’s energy needs for the next hours, days or even months. AI can also analyze the data and recognize trends and peak hours. The results and metadata from AI analyses can be grouped per district to help governments and policy makers create more efficient energy management strategies and achieve local and national goals.

B.    Health data - Scenario 2

National Healthcare systems is another sector where e-health strategies must be adopted for governments to control excessive healthcare costs [35]. Healthcare systems include huge amount of data that are mostly confidential, thus, problems arise when trying to process and analyze those big data and AI is a perfect match to provide solutions to these problems. As research shows it is hard for older adults to use the e-health systems [36] [37]. By using AI chatbots, older people can use speech recognition to make questions and inquiries and the chatbots can provide guidance and responses. Another use for AI agents will be to get citizens’ filled forms and forward them to the appropriate government department [38]. As for the confidentiality and authenticity problems of the private e-health data, a permissioned BC 3.0 as it has been already described can provide the means to confront them. This way EG 3.0 can provide solutions to the e-health necessities by utilizing ICT and Web 3.0 to transform the legacy systems, in order to increase the efficiency and effectiveness of these systems, decrease costs and provide more citizen-centric health care services [36].

Following is the pseudocode of two BC 3.0 SCs. The first one is for gathering energy consumption and production measurements form the citizen’s IoT devices in order to log them on the blockchain. The second is for energy dispatching of the excessive energy from a citizen’s residence to the main energy system, after checking the total consumption and total production which have previously been written on the blockchain. Both SCs are implemented on a private blockchain framework and take action every five seconds.

define SC_measurements():

  while True:{

           CurrentConsumption = IoT.get_measurements

           sign transaction(client_addr, CurrentConsumption )

           write to BC(client_addr, CurrentConsumption )

           CurrentProduction = IoT.get_production

           sign transaction(client_addr, CurrentProduction )

           write to BC(client_addr, CurrentProduction )

            }


define SC_energy_dispatch(client_addr):

   while True:{

          energyConsumption = read BC.CurrentCons(client_addr)

          energyProd = read BC.CurrentProd(client_addr)

          if energyProduction > 10watt then

            if energyConsumption < energyProduction then

                dispatch = energyProduction – energyConsumption

                sign transaction{client_addr, dispatch}

                write to BC{client_addr, dispatch}

                }

B.    Health data - Scenario 2

National Healthcare systems is another sector where e-health strategies must be adopted for governments to control excessive healthcare costs [35]. Healthcare systems include huge amount of data that are mostly confidential, thus, problems arise when trying to process and analyze those big data and AI is a perfect match to provide solutions to these problems. As research shows it is hard for older adults to use the e-health systems [36] [37]. By using AI chatbots, older people can use speech recognition to make questions and inquiries and the chatbots can provide guidance and responses. Another use for AI agents will be to get citizens’ filled forms and forward them to the appropriate government department [38]. As for the confidentiality and authenticity problems of the private e-health data, a permissioned BC 3.0 as it has been already described can provide the means to confront them. This way EG 3.0 can provide solutions to the e-health necessities by utilizing ICT and Web 3.0 to transform the legacy systems, in order to increase the efficiency and effectiveness of these systems, decrease costs and provide more citizen-centric health care services [36].

The EG scenario includes IoT wearables that send patient data, i.e. heart beats or blood pressure, to a private permissioned BC. This ensures the data’s security, authenticity and confidentiality. When a doctor wants to access the patients’ BC data she makes a request, which triggers a SC and this request is logged on the BC. The SC sends an information message to the patient and if the patient agrees to give access to the doctor the doctor gains access to the patient’s data. The SC writes on the BC the patients answer either it was positive or negative. This way a complete tracking system for requests and consent responses is formed. We can consider how useful and secure this can be when e-health records must be exchanged between countries at a national or international level with end-to-end security.

We can see an outline of three of BC 3.0 SC's pseudocode below:


define SC_health_data():

while True:{

      H_Data = IoT.get_heart_rates

      sign transaction(client_addr, H_Data)

      write to BC(client_addr, H_Data)

          }


define SC_doctor_access():

  request read BC.H_Data(client_addr)

  sign transaction(doctor_addr, request, client_addr)

  write to BC(doctor_addr, request, client_addr)

  send inform_consent(client_addr, request, doctor_addr)}


define SC_patient_consent(doctor_addr, request):

   read BC.doctor_request(doctor_addr, request)

   inquire response_from_patient

   if response == ‘YES’ then grant_access(doctor_addr for request)

   sign transaction(client_addr, response)

   write to BC(client_addr, response)}The EG scenario includes IoT wearables that send patient data, i.e. heart beats or blood pressure, to a private permissioned BC. This ensures the data’s security, authenticity and confidentiality. When a doctor wants to access the patients’ BC data she makes a request, which triggers a SC and this request is logged on the BC. The SC sends an information message to the patient and if the patient agrees to give access to the doctor the doctor gains access to the patient’s data. The SC writes on the BC the patients answer either it was positive or negative. This way a complete tracking system for requests and consent responses is formed. We can consider how useful and secure this can be when e-health records must be exchanged between countries at a national or international level with end-to-end security.

  V.        Further Research

...