Oracles Integration in Blockchain-Based Platform for Smart Crop Production Data Exchange

Abstract

Blockchain oracles are an intermediary designed to connect external non-deterministic information and real-world data to the blockchain digital infrastructure. The variety of proposed solutions and purposes are of great variety and suggest that it is necessary to take into account different features of the process and specifically define the required functionalities. The purpose of this paper is to present the integration of oracles into an EOSIO blockchain-based platform for smart crop production data exchange by smart contracts. The functions of two oracles are presented. Their integration is described at the design level and at the implementation of the smart contracts. The design level is illustrated by workflow diagrams of internal processes between oracle applications and the blockchain smart contract and by external processes in the oracles’ smart contracts. The implementation level is illustrated by oracle application configuration files and elements of C++ smart contracts, such as constant and variable declarations, multi-index tables, internal contract functions, and actions called by other contracts and external programs. As results of the oracles’ operation, a report on the detected emergency failures and an estimate of the cost of ram resource are presented.

1. Introduction

Blockchain oracles are an intermediary designed to connect external non-deterministic real-world information with the blockchain digital infrastructure through smart contracts. The definitions found in different sources are varied, but taken together, a trend is revealed in which oracles seem to cover a vast spectrum of characteristics and functions. Blockchain oracles are a service that requests and transfers data off-chain to smart contracts on the blockchain [1]; a device or entity that connects a deterministic blockchain with off-chain data [2]; an element for the blockchain ecosystem as they enable smart contracts to operate in a broader capacity [3]; a complex computerized systems that connect data from the outside world to the blockchain world; an Application Programming Interface (API) [4]; third-party information service providers that send external data to a blockchain protocol and are able to secure, verify, and validate the data that the blockchain network receives and uses; an application that retrieves, verifies, and transmits external information (i.e, information stored off-chain) to smart contracts; a mechanism to trigger smart contract functions using off-chain data [5]; a Web 3.0 ecosystem method of connecting to existing systems, data sources, and advanced computing [6].

Regardless of whether oracles are defined as a device, element, complex computerized systems, API, service provider, mechanism, or Web 3.0 method, their main purpose is related to blockchain ecosystems and, in their predominant implementation, is associated with use of smart contracts.

The concept of the smart contract is proposed by Nick Szabo [7]. Smart contracts are a self-executing, fully programmable, and automated agreement intended to implement trusted transactions when predetermined conditions are met, which usually works on a blockchain. The blockchain is a decentralized infrastructure software which supports a distributed digital ledger of cryptographically signed transactions that are grouped into blocks [8]. Analysing the current status of blockchain smart contract applications in [9], it is concluded that smart contract technology is promising but still in initial stages and has many drawbacks: the lack of strong data processing capacity, insufficiently effective management by the main blockchain systems, the insouciantly advanced contract language development, vulnerability scanning and processing techniques, low level of support, security vulnerabilities, etc.

The design, implementation, and integration of blockchain oracles is closely related to the blockchain platforms for which they are intended and their specific application. The blockchain platforms provide a digital infrastructure for development, deployment, and management of decentralized applications. Examples of such platforms are Ethereum, Quorum, Hyperledger Fabric, IBM Blockchain, R3 Corda, Tezos, Hyperledger Sawtooth, Stellar, and EOSIO.

The wide variety of solutions based on different blockchain platforms raises the question of their interoperability. In [10] these challenges are analysed, but it is found that in order to be trusted the oracles must either be managed by a trusted third party or have cryptographic attestation. The authors acknowledge that oracles can make blockchains compatible with non-blockchain systems.

In [11] the various approaches proposed for implementing blockchain oracles are explored. The authors conclude that oracles are key to the scalability and interoperability of blockchains. The solutions offered can be centralized or decentralized, and the main categories that oracles fall into are data feed oracles and computation oracles. The first category acts as an intermediary that submits external data to smart contracts on demand. The second category performs user-defined off-chain computational tasks for blockchains.

A blockchain oracle framework proposed in [12] covers key features such as origin of data, type of oracles, and type of blockchains, encryption method, oracle data source, data validation, and oracle integration method. Smart contracts are considered one of the most applied methods for integrating oracles into blockchain-based solutions. These guidelines of oracle’s framework are used in the current paper.

From a technical point of view blockchain oracles are software, therefore their integration is the process of combining separate software programs or elements into a single system. The operation of oracles is described in [13]. Generally, there is an oracle’s smart contract and a blockchain smart contract that need to use off-chain data. Then five steps are performed: first step—the blockchain smart contract sends an action to the oracle’s smart contract specifying the required off-chain data and the request’s id to the oracle’s smart contract (usually done by passing a URL that is an API endpoint); second step—the oracle scans the blockchain for incoming actions to its smart contract; third step—the incoming request is extracted from the blockchain transaction and executed; forth step—the server invokes a sanction on the blockchain smart contract with the response data and respective id, making the result available on the chain; and fifth step—the oracle’s smart contract matches the id to the blockchain’s smart contract request and calls a call-back function.

This paper is a continuation of research on the application and implementation of blockchain technologies in the National Research Program “Smart crop production” (https://rst-tto.com/rsttakt/index.php/newsroom/news-releases/50-nrp-scp (accessed on 4 May 2023) and “BG PLANTNET establishment of national information network genebank—plant genetic resources” (http://delc.space/genbank/ (accessed on 4 May 2023)). The framework of the projects are presented in [14]. Part of the tasks in the projects are dedicated to blockchain applications and implementations in smart crop production and more specifically to the identification of appropriate applications of the blockchains, to the building of pilot blockchains for selected areas, and to the analysis and development of models for efficient blockchains solutions for smart crop production.

Some of the results achieved so far involve different aspects of these problems. The main elements of the technology, the definitions, the focus areas in risk management, and the implications for internal audit and control procedures in companies that adopt blockchain in intelligent agriculture are discussed in [15].

The algorithms and solutions for multi-criteria selection of blockchain software и IoT platforms in agriculture are presented in [16]. In [17] the most widely used IoT platforms in agriculture are analysed and compered. A multi-criteria framework for selection of an IoT solution in a fuzzy environment is proposed. In this framework as a decision analysis method has been presented as a new modification of Multi-Attribute Border approximation Area Comparison (MABAC) method with a specific distance measure via intuitionistic fuzzy values.

A blockchain-enabled supply-chain model for a smart crop production framework and blockchain-based GenBank store system model are presented in [18,19,20]. In [21,22] the blockchain applications in cyber–physical–social space and experiments with supervised and unsupervised learning tools related to smart crop production and analyses with different classification, regression, and clustering algorithms are presented.

A framework of the blockchain-based platform for smart crop production data exchange is proposed is [23]. The prototype of the platform, its architecture design, topology, core functionalities, and tests are presented in [24]. The platform is based on private blockchain and distributed file system networks. It aims to support the integration of information exchange resulting from the use of various technologies in smart agriculture which generate a large amount of data, require processing, analysis, and have to be reliable in terms of quality and sources. A scheme of the building phases of the platform is presented in Figure 1.

The descriptions of business processes, workflows, the general concept of the framework, and the architecture of the platform are defined for the design phase. The installation phase includes the blockchain, the distributed file system networks, and the database deployment. The development phase includes the preparation of all software solutions, including blockchain oracles, frontend and backend, and the test application that will later run as a dApp (decentralized application). The prototyping and testing phase is designed to check the functionality of the platform and various experiments. The last phase is planned for the implementation of the platform in real operation. All elements in the diagram that are marked with dashed lines are under development or testing.

The purpose of this paper is to present the design framework and oracles’ integration by smart contracts in an EOSIO blockchain-based platform for smart crop production data exchange.

Further, this paper is organized as follows: In Section 2 the types of blockchain oracles are presented. The Section 3 describes the infrastructure of the blockchain-based platform, the framework, and functions of two oracles. The Section 4 describes the integration of oracles and workflow diagrams of the internal and external processes between blockchain’s and oracles’ smart contracts. In Section 5 examples of implementation of oracles’ functions using smart contracts are presented. The Section 6 is the discussion and future development.

2. Types of Blockchain Oracles

The diversity of types of oracles found in various sources [4,5,6,25,26], allows a preliminary orientation in their capabilities, methods of their integration, and implementation in the blockchain networks for which they are intended. Oracles can be classified according to origin data, data direction, the trust, data source, and trust models. They can also be distinguished based on whether they extract external data from on-chain contracts, send information from the blockchain to off-chain applications, or perform off-chain computational tasks.

Outbound oracles bring blockchain data to the outside world. They allow smart contracts to send commands to off-chain systems to prompt them to perform certain actions.

Inbound oracles bring off-chain—or real-world data—to the blockchain. The imported information can represent almost anything. Inbound oracles are the most widely recognized oracle that gathers off-chain data and delivers it onto the blockchain network for smart contract consumption. They reflect scenarios such as “if this happens, then do this” or “if the price of the asset reaches/falls to a certain value, then trigger a sale/purchase”.

Cross-Chain oracles exchange information between different blockchain networks. They enable interoperability between blockchains, such as using data from one blockchain to trigger an action on another, or linking assets between different blockchains so that they can be used outside of the one where they were issued.

Software oracles are one of the most common types. They interact with online sources of information and transmit it to the blockchain. Information can originate from online databases, servers, or websites—basically any data source on the web—and provide information to smart contracts in blockchain networks in real time.

Hardware oracles provide and transmit information through camera motion sensors, radio frequency identification (RFID) sensors, thermometers, and barcode scanners.

Human oracles are individuals with specialized knowledge in a particular field who serve as oracles. These specialists investigate and verify the authenticity of information and confirm their identity through cryptography. It is assumed that fraud, falsification of their identity, or provision of corrupted data is relatively unlikely.

Centralized oracles are controlled by a single entity and act as a single data provider for smart contracts. Therefore, the parties must have significant trust in this one entity, which is seen as a potential problem. Additionally, they represent a single point of failure that can potentially compromise the security of the smart contract, and a compromised oracle means a compromised smart contract. By presumption, oracles are supposed to enforce contracts between untrustworthy parties, but if they are over-centralized, they can become the intermediary they were meant to replace. This is known as the “oracle problem”.

Decentralized oracles (also called consensus oracles) have goals similar to those of public blockchains—avoiding counterparty risk. In these, to determine the validity and accuracy of the data, the smart contract queries multiple oracles. However, as yet, decentralized oracles do not completely remove trust but rather distribute it among many participants. Decentralized oracle networks (DONs) enable the deployment of hybrid smart contracts in which off-chain infrastructure and on-chain code are connected to provide decentralized applications (dApps) that respond to real-world events and interact with traditional systems.

Contract-specific oracles are designed to be used by a single smart contract. This means that if one wants to implement several smart contracts, a proportional number of contract-specific oracles must be developed. This type of oracle is considered very time consuming and expensive to maintain. On the other hand, oracles can be designed from scratch to serve a specific use case, and developers have a flexibility to tailor them to specific requirements.

Figure 2 illustrates one possible interpretation of the types of oracles in terms of the three areas—physical, digital, and blockchain ecosystems—that define their characteristics and purpose.

The origin of the data can be from the physical or digital area. In the first case, data could be generated by sensors or hardware (tangible objects). The so-called “human” oracles are also a source of data in the physical area, although their functions could be expanded to more specific applications. The origin of the data may also be from web content (intangible sources from the digital area), for example financial information, sports scores, weather updates, operational data, and user data, which are categorized under general http(s) data.

The direction of the information can be towards physical area (inbound oracles) or towards digital area (outbound oracles).

The digital area relates to the type of blockchain networks (permissionless, permissioned, or hybrid) and to the trust model (centralized or decentralized) for both—blockchain networks and oracles. Public blockchain networks are generally considered to be decentralized, while private blockchains are primarily centralized. For the most part oracles are developed as centralized, but there are a number of solutions with decentralized oracle networks that are actively gaining popularity.

Data validation, encryption methods, and integration methods refer entirely to blockchain ecosystem areas. Data validation (RFID signature, majority voting, weighted voting, hybrid PoW and PoS, or trusted third party) depends on whether the data provided by the external system is true, comes from the original source, and has not been altered. The most common approach is to rely on trusted data providers when oracles do not use any data validation method. Such a strategy is applicable if the data source is reliable.

Encryption methods refer to the confidentiality of data that is transferred from external data sources to the oracles and from the oracles to the blockchain. It is the cryptographic technology used to secure communication between two entities. A distinction must be made between encryption methods and techniques. The latter are the protocols themselves, cryptographic algorithms, and data transmission security schemes. The most commonly used encryption method is Public Key Infrastructure (PKI).

Oracle integration is the method of connecting an oracle to a blockchain in order to provide data. These can be smart contracts, software modules, custom solutions, and embedded solutions. The most common method is using a smart contract. A pair of smart contracts, one on-chain and one off-chain, can be used to integrate decentralized web applications (dApps). There is a variant of integration through software modules that are used to communicate between physical devices communicating and the blockchain, where the module is an intermediary agent that manipulates (according to certain rules) the incoming data before sending it to the oracle.

Oracle types discussed in this paper are illustrated in Figure 3. They could be classified as multi-source inbound centralized software oracles running on a permissioned blockchain with no encryption and data validation from a trusted third party. The applied integration method is a custom smart contract interface.

The data are retrieved from a sensor network. A server oracle application accesses the data through an API with a predefined username and password. A PKI is about to be introduced in future developments, most likely based on the ECC standard.

3. The Infrastructure of the Platform and Oracles’ Framework

The working name of the blockchain-based platform is SCPDx. It is based on an EOSIO blockchain (EOSIO 2.1.0) and distributed file system (IPFS 0.13.0 for MAC and IPFS 0.11.0 for Ubuntu). The infrastructure is presented in Figure 4. It is deployed on four virtual machines (vm_s) with the following configurations: vm₁—Intel Xeon configuration, 32 cores, 32 GB ram, 1TB hdd, 100 GB NET LAN, Ubuntu 20.04 OS (EOSIO node 1, EOSIO node 2, ipfs node 1, dApp, and an Oracle/Oracle API); vm₂—Intel i9, 16 cores, 16 GB ram, 1TB hdd, 100 GB NET LAN, Ubuntu 20.04 OS (Ipfs node 2); vm₃—Intel i9, 16 Cores, 16 GB ram, 1TB hdd, 100 GB NET LAN, Ubuntu 20.04 OS (Ipfs node 3); vm₄—Mac M1, 8 cores, 16 GB ram, 512 GB hdd, 100 MB NET Wi-Fi, OSX 13.4 (EOSIO node 3).

The blockchain and distributed file networks are set as private. Since private blockchains are always permissioned, it differs from the public blockchain in terms of infrastructure requirements. At this stage, to achieve transaction processing performance, the platform does not require significant computing power. The private blockchain is deployed on traditional servers that are part of the partners’ infrastructure. Blockchain nodes are located in different geographical locations, on different networks, and exchange data over the Internet. Currently, network delays and periodic outages have not significantly affected consistency of data.

The partners’ infrastructure is not a single and coherent one; however, any member who requested access can use the data exchange services through a test application (Test App) and public/private keys access. At a later stage, the functionality of the Test App will be transferred to a dApp. The users’ infrastructures are considered external for the platform.

Databases store transaction statistics, raw IoT (sensor) data, file catalogues, and more. In addition to various other purposes, raw IoT data are intended to be used by oracles in automated actions in smart contracts.

All partners/members are considered users. A user is a member in the role of a publisher or reader of data. A publisher is enabled broader rights of sharing and service access related to the copyright and tracking activity of provided data. A reader has more limited access to the specific contents on the platform. The user’s data and files could be uploaded to the platform either by API, if it is on a database, or directly through a Test App installed on a PC. Users are partners—scientific and educational institutes—participants in the National Scientific Program “Smart crop production”.

The oracles’ framework and interactions between sensors, blockchain networks, and oracles are presented in Figure 5. There is an existing IoT network that takes periodic measurements of various parameters. The measured parameters are recorded in a Postgres database on a server using API [27].

Oracle1 is intended to retrieve temperature and humidity readings from the sensor network every 60 min and to calculate and record daily min, max, mean, variance, and standard deviation of all readings every 24 h. It is also used to upload historical data to the blockchain. For 60 min readings and 24 h data, oracule1 connects to an API and writes the data to the blockchain.

Oracle2 performs two functions. The first function is system support, management, and maintenance of the blockchain. It queries the current status of each blockchain node every 60 min and receives the result as a Boolean flag. In the case where it cannot establish a connection with any of the nodes, this event is recorded in the blockchain, and a notification is sent to the system administrator by email. The second function is to retrieve the current market quote of the ram resource price for the public EOSIO blockchain and for the platform’s blockchain every 60 min. These data are collected as statistics, and if necessary, the price of the ram resource for the private blockchain can be as well.

This functionality is developed regarding the evaluation of resources consumed by the users of the platform. Due to the specifics of the EOSIO blockchain, ram is the only non-renewable resource and must be provided by purchase from the system account. Since the blockchain network is installed as private, the system account is owned by the developer. At this stage the operations are free for all users. When opening the platform to users external to the research project, it is necessary to provide the mechanism for sharing maintenance and operation costs among all participants. From the developer’s point of view, it is important to set a fair price for using the platform and to bind all transactions to system and/or custom tokens. How this is solved at the prototype stage is described in [24].

In summary, oracle1 is a server-based software oracle running on a private permissioned blockchain that extracts readings from multiple sensor sources. The data are not encrypted; validation is by a trusted third party; the integration method applied is a custom smart contract interface; the sensor data are accessed via an API with a predefined username and password; and its functions are as follows:

(1)

To retrieve and upload real-time temperature and humidity readings from two sensor networks;

(2)

To process and upload daily min, max, average, variance, and standard deviation for all retrieved data readings;

(3)

To upload historical data.

Oracle2 is also a server-based software oracle that extracts data from the private blockchain and the public EOSIO blockchain. The data are not encrypted; validation is by a trusted third party; the applied integration method is a custom smart contract interface; data from the private blockchain are accessed via an API with a predefined blockchain account and corresponding private key; data from the public EOSIO blockchain are publicly available and are retrieved via an API, which does not require the use of a user account or keys; and its functions are as follows:

(1)

The monitoring, management and system maintenance of the blockchain;

(2)

The registration and monitoring of the used ram resources.

4. Integration of Oracles

Each oracle consists of an oracle application (oracle app), an oracle account, and a smart contract. The oracle app is an application installed on a server and provides a connection to external data. The oracle account is a blockchain account with a smart contract installed to communicate with the outside environment and/or other smart contracts.

The access to on-chain data is possible by a user application as well. In this case it is necessary to develop this user application according to the oracle’s smart contracts technical specifications and to set respective permissions. Such an application is not yet available since SCPDx prototype is in the development stage.

The oracles’ workflow diagram is shown in Figure 6. The oracle app1 and the oracle app2 are respective applications for oracle1 and oracle2. Basically, those applications could be web-based or server-based. In this implementation, the installations are on external servers 1 and 2 with MAC OS. The oracle apps are written in Swift version 5.7 [28].

All communication and data exchange between oracle app1, oracle app2, the oracles’ smart contracts, and the user application are parallel and independent. The oracles’ smart contracts contain multi-index tables for storing the data and performing an external (for the blockchain) and internal (for the blockchain account) request.

Access to the data stored in the EOSIO multi-index tables is possible in several ways.

The first way is through a smart contract action executed by the same or another (call-back) smart contract in the blockchain.

The second is from an external application by executing a request to the blockchain API. This is possible if the address of the blockchain and the account to which the multi-index table belongs are known, as well as an appropriate software library.

The third way is by running the cleos command from the command line with the appropriate parameter format. In this case, if the blockchain address and the account of the multi-index table it belongs to are known, no blockchain account is even required. It is exactly what ensures the transparency and auditability of data in the blockchain, as it can be easily verified by an independent third party. This, of course, applies to public networks, but it is also valid for private ones, provided that no access restrictions are imposed (by IP address or otherwise). Additionally, depending on how the primary and secondary indexes of the multi-index table are defined, data can be filtered by a selected indicator (by dates, by sensor id, by indicators and their values, etc.).

The second and third ways are implemented here. For the first variant, a technical specification for the call-back procedure is provided below.

The oracles discussed here are identical in the way they work and implement their smart contracts, although the data they collect has a different purpose. The difference is in the formats of the multi-index tables and the syntax of the actions. For this reason, only one smart contract is described, since the second one has similar programming code.

4.1. Oracle1 Integration

The oracle app1 is developed to retrieve data from databases that contain sensor reading data. The main functions of the application are as follows:

(1)

To retrieve real-time data from sensor readings and upload it on a blockchain;

(2)

To process statistical data of sensor readings and upload it on a blockchain;

(3)

To statistically process historical data of sensor readings and upload it on a blockchain.

It is necessary to emphasize that the functions of the oracle are performed by its application and its corresponding smart contract. The oracle application is responsible for the interaction with the external data and the smart contract for the operations in the blockchain. This is the reason that the functions of the oracles described in the previous section are the same as those of their applications.

The oracle1 smart contract contains two multi-index tables for the sensor’s raw data readings and daily processed statistics. There are three types of operations used: add—allows the oracle app1 to add records; fetch 1 (getlastiorec)—allows external applications that have the appropriate permissions to fetch data (e.g., the most recent value, the arithmetic mean of data over a period); fetch 2 (getlastrec)—allows another smart contract action (from the same blockchain) that has the appropriate permissions to fetch data (call-back).

Within one blockchain, multiple accounts can exist to retrieve data recorded in the oracle1 smart contract multi-index table and to perform calculations and/or make decisions on this basis. This is realized by using the so-called call-back convention.

Figure 7 describes a communication scheme of a user’s blockchain account, a smart contract (blockchain smart contract), and an oracle account (oracle1); i.e., oracle1 smart contract internal interactions. The user account with a smart contract can be any account that contains a call-back action according to the oracle smart contract technical specifications and with the necessary permissions granted.

The internal processes for oracle2 coincide in structure with that of oracle1 (Figure 7).

The interactions between sensors, database, database API, oracle app1, oracle1 smart contract, and user application are presented in Figure 8. These are the communication processes between external components and the blockchain network. The internal component is only the oracle1 smart contract.

4.2. Oracle2 Integration

The oracle app2 main functions are as follows:

(1)

Monitoring the operation of blockchain nodes.

The addresses of all blockchain nodes, the checking interval of their status, and email addresses of the system administrators are set in the application’s configuration file. In this particular implementation, the nodes are checked every hour. The result as a true/false flag is recorded in a multi-index table of the application’s smart contract. In case a given node is not active, a problem email message is sent. Based on the results of the checks, statistics are extracted for the number of failures in the network as well as for the time to restore the working capacity of the nodes. This information can also be accessed by another smart contract in the private network using a call-back functionality.

(2)

Periodic creation of a snapshot file, which is used to restore the operation of a blockchain node after an emergency shutdown.

In our case, this is done every 24 h for each of the nodes, and this parameter is set in the configuration file. The size of these files is negligible (about 10 MB) and does not affect the disk space of the servers in the network. This is done by executing a POST request to the EOSIO nodeos API.

(3)

Retrieving current blockchain rammarket table of the EOSIO system account by executing the cleos command with the appropriate parameters [29].

The application retrieves the necessary data and calculates the current value every 60 min. This parameter is set in the configuration file. The data are recorded in the multi-index of the smart contract. The information is used to estimate the cost of the blockchain resources used for tests or particular blockchain accounts. The data can also be accessed from another smart contract in the private network using call-back functionality. The application retrieves similar data about the rammarket data from the public EOSIO blockchain as well and records it in a multi-index table of the smart contract. These data are used for comparison of the cost of resources on the private network versus the public EOSIO network and is available from another smart contract using call-back functionality.

The interactions between an oracle app2, oracle2 smart contract, private blockchain nodes, and EOSIO public blockchain are presented in Figure 9. These are the processes between external components and the blockchain networks.

5. Oracles’ Smart Contracts Implementation

Each smart contract contains the following basic components:

-

Declarations of the libraries used—they can be standard (built-in) in EOSIO or custom;

-

Data declarations—constants, variables, structures, or multi-index tables;

-

Declarations of functions that are used inside the contract;

-

Declarations of actions—the functions that are called by other contracts or external programs.

The used libraries in the smart contracts are the EOSIO build-in.

As examples of the oracles’ smart contracts implementation, this section demonstrates only some parts of the smart contracts’ program code, its syntax, declarations, and the configuration files of the server applications. As a result of oracles’ functions, a summary table of failures statistics, ram price estimations, and generated reports about status of the used resources are presented.

The oracles use specialized smart contracts, written on C++, custom interface, and a dedicated oracle blockchain account.

The complete source code of the smart contracts is available in the GitHub repository: https://github.com/scpdxtest/SCPDx.git (accessed on 13 April 2023).

For oracle app1 settings (parameters), a JSON (JavaScript Object Notation) configuration file is used with sensor’s id (included in API’s path), the type of measured data (for example, temperature), and the interval for data retrieval in seconds.

The oracle2 JSON configuration file contains a name of the blockchain network, addresses of the individual blockchain nodes, addresses of the system administrators, node status check interval in seconds, ram resource cost extraction interval in seconds, and interval of the snapshot file.

The snapshot file is used when restoring the operation of a blockchain node after an emergency stop.

5.1. Upload Real-Time Sensor Readings

For uploading real-time sensor readings, the following actions are used from the oracle1 smart contract and a corresponding multi-index table.

A structure that is passed as input parameters to the add action and syntax:

Oracle1 smart contract multi-index table (IoT registry) format:

The user application and oracle1 smart contract can retrieve the data recorded in the multi-index table by action getlastiorec input/output parameters format:

With the given example, the extraction of the last recorded value from a specific sensor is implemented. Depending on the required functionalities, other algorithms for data extraction, for example, the arithmetic mean value of measured parameters for a certain period of time, the last three measured values, or others, can be used.

In this particular implementation the used action in the oracle1 smart contract is:

In general, when a smart contract has to receive data from another smart contract, the so-called call-back convention is used. The oracle smart contract developer must provide a sample of the call-back action in order for it to be implemented in the user’s smart contracts to which data will be provided.

The call-back action sample in the user’s smart contract:

The oracle1 smart contract uses id to match the request coming from the user smart contract and then invokes a call-back action on it with the response. It suggests that the user’s smart contract has two actions.

In step 1, the user’s smart contract calls (executes) the action from the oracle1 smart contract and defines the request to receive data.

In step 2, the oracle1 smart contract calls (executes) the call-back action in the user’s smart contract that has a predefined interface (defined by the operator/owner of the oracle smart contract). The call-back action records the received data in a predefined multi-index table (Figure 6).

The other way to store data instead of in multi-indexes tables is a singleton. The difference is that singletons can only store a single data record and therefore don’t need a primary key which makes access easier. Singletons are usually used to store global configuration data for the smart contract or data for subsequent calculations.

The maximum execution time of a smart contract action is 140 ms. For input–output operations, the actions should be allocated, for example, 20% of the time. The remaining time is translated into processor cycles for a particular processor (clock speed, performance, etc.).

5.2. Registration and Monitoring of the RAM Resource

The resources in EOSIO blockchain are net, cpu, and ram. Net is average consumption in bytes over the last 3 days. Cpu is the processing power of an account measured in microseconds over the last 3 days as well. Ram is the information that is accessible from application logic. It limits the maximum space that can be occupied to store permanent data. Cpu price is measured in SYS Token/ms/Day, net price in SYS Token/KiB/Day, 1 KiB = 1024 bytes, and ram in SYS/1 byte.

An account can exchange net and cpu, but must buy ram, because it is not freed automatically. The only way to free up ram is to delete the data that is using the account (multi-index tables). Freed unused ram can be sold and purchased at the market price, which is determined by the Bancor algorithm [29,30]. The utility token in this private blockchain is SYS.

The data on the registration and monitoring of the ram resource is recorded in the blockchain. It can also be treated as raw data from a website source.

The ram price is extracted from the rammarket table of the EOSIO system account or by executing the cleos command with the corresponding parameters:

Based on the Bankor algorithm,

Table 1. SCPDx ram and EOS ram prices.

Description	Value	Units
RAM Market price SCPDx blockchain	1.463	SYS/MiB
Public EOS price	1.19	USD

presents the results for the price of a ram resource as of 4 April 2023.

It is possible to compare the ram resource price and the public EOSIO blockchain (EOS RAM Token quote in USD) at https://bloks.io/ (accessed on 4 April 2023).

5.3. Statistical Processing of Sensor Data

The data are statistically processed and uploaded on the blockchain. It can be historical or daily aggregated from the real-time sensor readings. Here, historical data from a sensor group installed in a greenhouse located in Maritsa Vegetable Crops Research Institute (MVCRI), Plovdiv (https://izk-maritsa.org/en/home/ (accessed on 12 May 2023)) was statistically processed and uploaded to the blockchain. The raw data are the temperature and humidity readings of five sensors over an eight-month period and comprised about 380,000 records or 10.9 Mb. The processed data uploaded on the blockchain constituted a volume of about 500 KB (0.5 MB). For the statistical calculations, a standard built-in array processing functions in Swift 5.7 is used.

A structure that is passed as input parameters in an oracle1 smart contract to the action addmar:

A multi-index table (sensors registry) format:

A reference to the memory used to upload the processed data is obtained from the command line: cleos -u http://<blockchain endpoint> get account iotoracle:

Resources status before uploading data to the oracle1 smart contract:

Resources status after data upload:

The comparison shows that about 500 KiB of ram is used to upload the historical data. Based on the data collected by oracle2, its value can be estimated for any date. In the current example, at 04/04/23 (Table 1), it is 500 KiB (=0.5 MiB) × 1.463 SYS/MiB = 0.7315 SYS. Assuming 1 SYS = 1 EOS, the price in USD is USD 1.19 × 0.7315 = USD 0.87. Therefore, a user must purchase a ram of this value, provided he wants to store such a volume of data in the blockchain.

Assuming that this is historical data for 8 months from five sensors that measure two parameters, it can be found that the monthly cost to upload statistically processed data is USD 0.108. These are operational costs that would have to be paid by the user. The presented calculation should be interpreted as an isolated example of the cost of the resource for using the blockchain and cannot serve as a criterion for the cost of maintenance of the platform.

5.4. Monitoring and Maintaining the Blockchain Network

The monitoring and maintenance of the blockchain network enables real-time monitoring of the state of nodes, immediate action in case of failure, and collection of statistics on the frequency of failures and recovery.

Table 2. Blockchain network failure statistics.

Parameters
Starting date	August 2022
Number of nodes:	3
OS	1 × OSX, 2 × UBUNTO 20.04
Total number of failures	29
Average node recovery time	up to 2 h
Maximum node recovery time	6 h
Minimum node recovery time	up to 1 h

is a summary of the data generated by oracle2.

The redistricted emergency failures are mainly due to the following:

-

Interruption and breakdowns of Internet providers;

-

Power failure;

-

Disk memory overflow—only once, due to a wrong configuration of the node.

Since all interruptions are due to failures of the nodes’ external infrastructure, it can be concluded that from a software perspective, the eos.io blockchain ecosystem is rather reliable. The statistics show that from the point of view of system administration, the chosen notification approach is efficient enough. The time it takes for the nodes to get back up and running varies and very much depends on how long the outage was.

6. Discussion and Future Development

This paper commented, analysed, and presented an integration of two server-based blockchain oracles into a blockchain-based platform for smart crop production data exchange by smart contracts.

Oracle1 is intended to retrieve and upload, on blockchain real-time data, readings from two sensor networks, to process and upload daily readings statistics, and to upload historical data as needed. Currently, the oracle work is stable, and no gaps have been reported when collecting the data. The resources used fully correspond to the expected parameters. However, a comprehensive assessment of its performance cannot be provided as new sensor networks are yet to be connected. In addition, the need to store historical data is currently incidental and it is difficult to determine the load on the blockchain network and its performance at higher transaction intensity.

Oracle2 is developed for system functions. The monitoring of the operation of blockchain nodes facilitates the work of the system administrator. With the inevitable scaling of the blockchain network, it is assumed that the system functions will evolve, and the analysis of the collected statistics will optimize the operation of the entire platform. For about eight months of operation, the oracle has detected all emergency interruptions of the blockchain nodes. On this basis the maximum, average, and minimum nodes’ recovery time and the main reasons for those failures are identified. From this data, it can be concluded that the interruptions in the work of the blockchain nodes are mainly due to external factors such as interruptions in Internet connections, power outages, and unplanned server software updates. The notification that the oracle sends to the system administrator significantly reduces the recovery time of the nodes.

The oracle2 also allows assessment of the ram resource cost for uploading processed historical data. Since these results are obtained on the basis of very little data and low-intensity transactions, this functionality remains to be further tested under more active exchange, volume, and type of data. At the current load of the platform, the cost of the ram resource used is relatively low. A possible increase of the ram price may occur when increasing the frequency of measurements from the sensor network or a rise in the number of sensors. The fact that the blockchain network is private has no effect on the cost of ram resources, only on who covers this cost.

Both oracles’ integration is described at the design level and through particular implementation of smart contracts. The oracles’ functions are performed by an oracle application and a corresponding oracle smart contract. The first is responsible for the interaction with the external data, and the second is responsible for the operations in the blockchain. The concrete solution is illustrated by oracles’ workflows, the internal processes between the oracle applications and the blockchain smart contract, and the external processes of the oracle smart contracts. The main functions are illustrated by examples of the configuration files of the server applications (oracle applications), elements of the C++ smart contracts representing constants and variables declarations, multi-index tables, internal functions in the contracts, and actions called by other contracts and external programs.

There are a number of potential fallacies in developing and setting software blockchain oracles. They mainly refer to the implementation and used protocols. Regardless of the fact that authors and developers propose their own solutions, the implementation and integration approaches can be different and should be tailored to the particular tasks and specifics of the information systems and infrastructure used.

The main criterion of whether an oracle is properly designed is whether it achieves its predefined functionality. This process is measurable and testable. After almost 10 months of operation, the current implementation of blockchain oracles meets the set goals and is sufficiently stable from an operational point of view.

The presence of a single point of failure is always a threat for any information system, regardless of whether it is based on blockchain technology or not. The mitigation of this risk could be achieved by duplicating the infrastructure components—IoT networks, by adding a group or groups of sensors measuring the same parameters (but this leads to an increase in the cost/investment when building the IoT component of the platforms), or by duplicating the software component; for example, by installing a group of oracles on different servers to retrieve data from the same IoT sensors. A mixed approach is also applicable. The second option is probably more cost-effective, while the first increases the reliability of the obtained data from the physical world. In this particular implementation, the second option is more appropriate. It is planned to add one or more software oracles installed on independent servers. This is a subject for future development.

Verification of external data sources is of particular importance for the reliability of the information received. It is customary to work with verified information providers (fixed IP addresses, data encryption, etc.). In the case presented in this paper, the data comes from sensor IoT networks of a partner’s organization. The entire information infrastructure is under the management of the project members, and the data are assumed to be from a reliable and verified source. In the next stages of development of the platform, encryption of the data received from the IoT sensor networks is envisaged by using public/private key technology—the same principle that is used for the authentication of users in the EOSIO blockchain network (ECC keys).

From a cybersecurity perspective, which is beyond the scope of this paper, oracles introduce a degree of risk, but it is a manageable process. At this stage of implementation standard means and security measures are provided, such as access to the server and blockchain infrastructure through encrypted connections, using digital certificates, limiting access to networks only through a list of user IP addresses, and installing all software components on their own information resources. The management is centralized and is entirely under the control of the project’s members. Complementing and expanding the functionality of the platform, or in the case of opening it to public access, more significant cybersecurity measures must be taken.

The oracles are particularly valuable in terms of transferring data from the physical world to information systems. The safe and reliable transfer of digitized information intended for process management and/or decision making is extremely important in the development and operation of information systems/platforms. Basing such platforms on blockchain technologies increases their reliability in terms of immutability, auditability, and transparency of stored information and performed transactions. From a software point of view, blockchain oracles are not very different from any other application (server or WEB based). For this reason, the risks when integrating them into software platforms, including blockchain-based ones, are of a general nature. With an appropriate risk management plan, which includes access control, use of complex hardware and software approaches for cyber security protection of information and network resources and infrastructure, centralized management, and continuous control of activities, the risks are manageable.

The future development of oracles’ integration could go in several directions. First, given that the main public blockchain networks based on EOSIO technology have made a hard fork, a private blockchain network operating under the management of the Antelope.io software is going to be installed [31], and upcoming tests for compatibility, data portability and performance, etc. are going to be performed. This hard fork added a number of new functionalities. For example, Ethereum VM (EVM) support, which allows existing applications running on Ethereum blockchain to be migrated onto the new version of Antelope.io, better management of resources and access to on-chain data (permissioned access to multi-index tables, extracting information about transactions), extended options for authentication, integration with most available wallets (hardware, web, and software), which makes it suitable for the implementation of dApps and web3 applications, and the possibility of using Solidity for smart contracts and transactions migration features.

A second direction is expanding the scope of access to various external data sources and the integration of oracles with other smart contracts that have decision-making functions.

A third direction is experiments to integrate the functions of intelligent personal assistants into the oracles’ smart contracts. The characteristics of an intelligent agent, such as autonomy, reactivity, and proactivity in communication with an external environment and virtual infrastructures, whether it is a virtual educational space [32,33] or other domain, in principle do not differ significantly from the purpose of a smart contract. Implemented in decentralized applications, such oracles would enable significant customization of data exchange services and decision support in smart crop production.

Another future development is oracles’ integrations in risk assessment and management framework [34,35] of the platform. This is a sufficiently specific topic that implies expanding and detailing the functions of the system oracle in the direction of identifying, registering, processing, and signalling about external environment risk events to security systems or platform administrators to take appropriate actions.