We describe an oracle for smart contracts for strengthening the functionality of their execution, thus making them amenable to any future changes that may be critical for sustained use. The oracle is supported by an ontology|speci cally, constraints for transactions can be represented by semantic rules, and as such, this ontology-based oracle can help resolve break glass in case of emergency type scenarios that require going beyond pre-de ned rules in the smart contracts that are already deployed in the distributed ledger platform. The issue of resolving an unexpected situation that was not explicitly considered in the code can be thought of as dynamic changes to attributes of assets and participants involved in a smart contract, which is equivalent to changing rules for a transaction. One way to implement such changes could be by having users vote on di erent proposals to change the rule. In our case, such a change can be invoked using the ontology and contextual information associated with the smart contract itself. The ontology also helps constrain the voting system itself, imposing a form of access control to allow only valid changes in rules.
A decentralized application (DApp) does not require an arbitrator due to the implicit trust properties guaranteed by the immutable nature of the distributed ledger framework. Typically, DApps employ smart contracts to execute a particular set of rules in a trusted way. However, smart contracts are usually immutable, and thus requires prior consideration for di erent unexpected situations that may require change in rules. For example, in a decentralized course selection system spanning multiple schools, there may be speci c rules for student enrollment in courses. A professor might employ a smart contract to reduce the class size for the Summer semester, but there could be a capacity of students Copyright c 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0). needing to nish the course during the Summer since they are to start a work placement in the Fall. Therefore, in the absence of a central authority, smarter contracts with exible structure are needed to manage unexpected situations.
Liu et al. [
We propose an ontology-based oracle, where transaction constraints are dened by semantic rules. Since all participant and asset classes have structured| and associated semantic de nitions, we can execute complex rules and also modify the rules when necessary. The main contribution of this work is a solution where unexpected situations of complex nature can still be resolved by voting. Aggregating user votes on a new set of proposed rules, we can select a new consistent rule that may resolve the situation. 2
There have been attempts to de ne a formal ontology for blockchain and smart
contracts [
An ontology contains de nitions of concepts, properties, and relationships among
them for a particular domain|or system; an ontology also provides a
common vocabulary among stakeholders, thus enabling data share and reuse. By
incorporating formal rules to such models (e.g., Semantic Web Rule Language
(SWRL) [
A smart contract executes completely deterministic transactions and then update the blockchain in an according way. Thus, communicating with an external system becomes problematic as it is not possible to verify all external data in a deterministic way. Oracles solve this problem by providing a trusted system for information transfer. While an oracle may seem like a centralized component, a mutable ontology-based oracle for holding transaction rules actually aids our solution for decentralized handling of unexpected situations. 4
Though smart contracts are useful in implementing decision rules in
decentralized applications, it might be desirable to some to keep intricate and complex
logic o -chain for ease of design[
As depicted by Figure 1, the main idea is as follows: the blockchain itself will act as a veri able data structure, but most of the logic for each transaction will be performed o -chain in this model. This is achieved by implementing an oracle with a domain-speci c ontology which holds all relations, and the rules of transactions with respect to the semantic concepts found in the said ontology. Each time a transaction is attempted by a user or a smart contract on the network, a query will be made to the oracle about present constraints for the particular transaction. The oracle will be provided with information about the participants and assets involved in a given transaction, and an instance will be created. The semantic rule de ned for that transaction will then verify whether this transaction will be completed or not. We demonstrate our model with the example case of a decentralized course selection system. A registrar's o ce usually acts as a governing body for the case of students' course selection. But in a decentralized system, there would be no such system. If we implement a smart contract for this, conditions like prerequisites for a student joining a course or capacity for a course may be de ned by semantic rules. Figure 2 shows a section of the ontology on a decentralized course selection (dcs) namespace. A basic transaction for the smart contract is AddCourse, which a student uses to enroll in a course, if they ful ll necessary prerequisites. Now, we can have a SWRL rule like the following to de ne this condition.
Student(?s)^hasGP A(?s; ?g)^hasY ear(?s; ?y)^Course(?c)^hasRequiredGP A(?c; ?rg)^ hasRequiredY ear(?c; ?ry)^hasM axCapacity(?c; ?mc)^hasCurrentSize(?c; ?curr)^ swrlb : greaterT hanOrEqual(?g; ?rg)^swrlb : greaterT hanOrEqual(?y; ?ry)^ swrlb : lesserT han(?curr; ?mc) ! canAddCourse(?s; ?c) When trying to execute an addCourse transaction, the smart contract would query to the oracle about whether the conditions meet. The oracle in turn queries the necessary data from the blockchain and receive data in triples. For the instance in Figure 3, the oracle would receive triples: student1 : hasGP A : 3:8, student1 : hasY ear : 1, course1 : hasRequiredGP A : 3:0 etc. With these triples, the query can be evaluated and a True/False value returned to the smart contract for the AddCourse transaction.
In a case when a student does not have su cient GPA, the professor may consider their grade point in some speci c course and modify the rules with an alternate prerequisite. This could have been unforeseen while writing the contract. In our solution, this can be resolved by updating the SWRL rule in the oracle. Since changing the condition for a transaction shall impact other participants than just the one professor and one student, any such change should be made in a fair manner. To ensure this, we implement a voting system to update the rules. 4.2
We give a sketch of the voting mechanism here, Figure 4 depicting the basic ow. The voting system itself would be explicitly guided by the ontology as it would not be tractable to allow all users to vote on all proposal or make all attributes changeable by voting. A form of access control is implemented on the voting system, again utilizing the semantic rules with respect to the ontology so that concerns like who could invoke a startVote transaction, how proposals are gathered or how proposals are aggregated to a single desirable outcome can be addressed properly. The voting mechanism may initiate transactions that request new proposals and votes from users. 5
We present speci c implementation considerations, drawing examples from the course selection scenario when necessary.
{ The ontology will help maintain the extent to which rules and attributes are changeable. For example, while attributes such as course.MaxCapacity may be changeable, student.GPA cannot be changed, overriding proper rules for updating student grades, by voting. { For privacy concerns, the oracle would receive data necessary for forming instances for each transaction and never store a complete knowledge graph. { The oracle consists of both an ontology and a reasoner that helps respond to queries. Updates on the rules should only occur from the smart contract, each transfer of data will also need to ensure that the oracle has not been externally tampered, using a mechanism like change signatures. Having some rules o -chain may pose a modicum of new security threats that we would like to investigate. Also, we understand that the implementation may also lead to growth in transaction completion time, so a complexity analysis is also due. Another point of interest would be di erent ways to aggregate propose rules based on di erent voting rules. Our proposal of an ontology-based oracle not only makes execution of complex logic in smart contracts easier, but coupled with the voting system, also allows for a way to update the contracts. Empowered with the ontology, we could make use of the data that from update requests for the rules. The voting data may be leveraged towards learning preferences of voters, and proper utilization of this may lead towards creating smarter contracts able to auto-generate proposals for voting or have intelligent proxies for voters to speed up the updating process.