Abstract
Decentralised ledgers are gaining momentum following the interest of industries and people in smart contracts. Major attention is paid to blockchain applications intended for trading assets that exploit digital cryptographic certificates called tokens. Particularly relevant tokens are the non-fungible tokens (NFTs), namely, unique and non-replicable tokens used to represent the cryptographic counterpart of assets ranging from pieces of art through to licenses and certifications. A relevant consequence of the hard-coded nature of blockchains is the hardness of probing, in particular when advanced searchers involving the capabilities of the smart contracts or the assets digitised by NFTs are required. For this purpose, a formal representation for the operational semantics of smart contracts and of tokens has become particularly urgent, especially in economy and finance, where blockchains become increasingly relevant. Hence, we feel the need to tailor Semantic Web technologies to achieve that semantic representation at least for NFTS.
This article reports on an ontology that leverages the Ontology for Agents, Systems, and Integration of Services (“
Introduction
The last decade report huge interest from various realms such as economic, social, business, and academic ones in blockchain technology and related applications (Xu et al., 2017). The interest in blockchain technologies is mainly motivated by the fact that they implement decentralised and publicly shared ledgers, where third-party intermediaries demanding the client’s total and unquestioned trust are not required. One of the most popular applications of blockchains such as Ethereum (Szabo, 1997) is the smart contract. Smart contracts are executable specifications of agreements in blockchain transactions that implement decentralised and autonomously running programs called dApps.
Applications of blockchain technologies are innumerable, ranging from the Internet of Things (IoT) and robotics (Christidis and Devetsikiotis, 2016), to commerce, healthcare, insurance, energy, laws, and communications. In particular, in the commerce and financial realms, some types of blockchains are used to deliver cryptographic versions of the digital twins of assets within a public decentralised environment. Properties of digital twins are commonly represented by means of non-fungible tokens (NFTs). An NFT is a digital certificate stored on the blockchain representing predetermined rights on certain unique assets. Therefore, NFTs are mainly used as digital proofs of assets’ ownership, even though they do not provide inherent legal meaning, do not grant copyright, intellectual or any other legal rights over them, and unauthorized copies cannot be avoided. NFTs are routinely exchanged mainly to transfer the ownership of assets whose uniqueness is hard to demonstrate (for example, digital data such as images and sounds), mainly for monetary profit.1
The NFT market is projected to reach 2,378.0 millions of dollars in 2024 (Statista, 2024).
This article targets the well-known problem of the user-friendliness and usability of blockchain-based trading. A paradigmatic use case sees a beginner approach such a technology and come across a number of identifiers (notably, the hashes of previous transactions and the token identifiers) that were transferred with each transaction. Not only are such identifiers as cryptic as hexadecimal representations, but it remains unclear what goods correspond to each token and what tokens are for sale. The only plausible means to retrieve such information at present are a) the inspection of the source code of the smart contract that handles specific tokens, b) the fetching of some metadata that may be available about each token, for example off-chain by means of an HTTP link to a dedicated page (maintained either by the token owner or by intermediaries), and c) the appeal to off-chain services that operate as intermediaries promoting specific types of tokens. While code inspection is clearly not for the layman, metadata is not always available. Part of this problem is how to structure such a metadata to enable automated processing, and searching in particular. Additionally, it is currently hard for newcomers to search through a blockchain, for example, to find smart contracts trading the specific tokens that satisfy the user requirements on quality or quantity. Moreover, users perceive tokens and related smart-contracts as a black-box and remain vastly unaware of (the details of the essential processes of) deploying, transferring, and destroying tokens – thereby also increasing the likelihood of scam attempts (Tom’s Hardware, 2022).
Arguably, all facets of the problem outlined above could be addressed by developing ontologies about the logic of the full, blockchain-based trading, coherently with the Semantic Blockchain paradigm (Aswini and Padmapriya, 2021). Therefore, this article aims at a formal, semantic representation capturing not only metadata but the entire trading process, namely blockchain smart contracts and all related activities, so as to facilitate the understanding of blockchain concepts, the interlinking with off-chain information, and also formal reasoning. Moreover, a semantic conception of blockchains could support the automatic discovery of smart contracts, the interconnection of services running on different blockchains (i.e., cross-chain integration) and the integration between smart contract and off-chain services. These features turn out to be yet more relevant when smart contracts are implemented as mechanisms for generating and exchanging tokens: one of the most desirable features of token exchange systems is a precise and intelligent query mechanism capable of determining what, when, and how certain assets were generated, exchanged or destroyed. Token marketplaces may be aware of the activation of smart contracts for generating tokens with specific features, of the type of exchanged asset or of their exchange conditions, or more in general of all the related activities over the blockchain. Final users would also benefit from a clear representation of the blockchain, since they gain means to understand the underlying mechanics and the decisions taken in trading tokens.
Hence, this article contributes to the realization of the Semantic Blockchain by interpreting smart contracts as reactive agents operating on a common environment, with a fully specified semantics of available operations, committed actions, and stored data. The representation of blockchain actors requires ontological capabilities for fully representing agents and their interactions in a detailed way.
The behaviouristic approach, inspired to the Tropos methodology (Bresciani et al., 2004), focuses on the agents’ mental components, notably on goals and tasks to achieve a result. Tasks are, in turn, oriented at changing the environment through some actions, namely, the direct consequences of bringing the behaviours into effect. Therefore, this comes as a natural approach at formalising the operational capabilities of agents. The Ontology for Agents, Systems, and Integration of Services (“
In this work,
The present manuscript extends a previous conference paper (Bella et al., 2022) by fully describing the Ethereum blockchain together with the ERC-721 compliant smart contracts and related non-fungible tokens, including how minting and transferring operations are semantically represented. Part of this work is integrated within ONTOCHAIN (NGI-ONTOCHAIN, 2020; Bella et al., 2021), a family of solutions to deliver a secure and transparent blockchain-based knowledge management system. This is meant as an interoperability service for the Internet in several domains such as health, economy, mobility, public services, energy and sustainability, news, media, entertainment, Industry 4.0, and tourism.
The paper is organised as follows. Section 2 presents related works. Section 3 outlines
Combining Semantic Web technologies and blockchains is the goal of recent research (English et al., 2016; Cano-Benito et al., 2019). One of the most investigated aspects is the specification of blockchain concepts and technologies by means of ontologies to provide semantic reasoning capabilities. An ontological albeit theoretical approach at blockchain representation already exists (de Kruijff and Weigand, 2017). The authors of (Ruta et al., 2018) propose a blockchain framework for Semantic Web of Things (SWoT) contexts settled as a Service-Oriented Architecture (SOA), where nodes can exploit smart contracts for registering, discovering, and selecting annotated services and resources. Blockchain technologies are also exploited as a secure and public storage system for small data, including linked data, and to realise a more resilient architecture for the Semantic Web (English et al., 2016).
Other works aim at representing ontologies within a blockchain context. In (Kim and Laskowski, 2018), ontologies are used as common data format for blockchain-based applications such as the proposed provenance traceability ontology, but are limited to implementation aspects of the blockchain. The author of (Fill, 2019) discusses the application of blockchains for tracking the provenance of knowledge, establishing delegation schemes, and ensuring the existence of patterns in formal conceptualizations. This is achieved using the zero-knowledge proof of knowledge method, which consists in proving a given statement without revealing how it was proved or any additional knowledge.
Semantic interpretations of smart contracts as services such as the Ethon ontology (Pfeffer et al., 2016; Baqa et al., 2019) or analogous approaches (Cano-Benito et al., 2021) exist: their main limitation is the poor semantic description of the represented smart contracts, which hinders the discovery of unknown smart contracts and of the related operations fulfilled during their life-span. This is due to the fact that these ontologies limit the representation of smart contracts to the one of services, or only to hard-coded functions. Moreover, the semantics of smart contract interactions is extremely limited and no specification about the type of operation and of the entities involved in the commitment is provided.
The Blockchain Ontology with Dynamic Extensibility (BLONDiE) project (Ugarte Rojas, 2017) provides a comprehensive vocabulary that covers the structure of various components (wallets, transactions, blocks, accounts, etc.) of blockchain platforms (both Bitcoin and Ethereum), which could be easily extended to other ledgers. However, BLONDiE does not cover the type of operations carried on by smart-contracts, how and what type of tokens and related assets they manage. This is the fundamental limitation of BLONDiE that this article overcomes.
Worthy to be mentioned, Ethereum recently introduced the TokenURI2
Finally, we summarise the works that led to
In this section we present the Ontology for Agents, Systems and Integration of Services (in short,
The
In
modelling general abstract behaviours (called templates), from which concrete agent behaviours are drawn;
modelling concrete agent behaviours drawn by agent templates;
modelling actions performed by agents by associating them with the behaviours from which actions are drawn.
The first step is not mandatory and consists in defining the agent’s behaviour template, namely a high-level description of behaviours of abstract agents that can be implemented to define more specific and concrete behaviours of real agents. For example, a template may be designed to describe specific commercial actors such as sellers and publishers. Moreover, templates are useful to guide developers to define the most suitable behaviours for their own agents. To describe abstract agent’s capabilities to perform actions, an agent template comprises three main elements, namely behaviours, goals and tasks. Behaviours represent the mental state of the agent associated with its capability of activating, modifying the environment or doing something; goals are conceived as mental attitudes representing preferred progressions of a particular system that the agent has chosen to put effort into bringing about (van Riemsdijk et al., 2008), while tasks depict how such progressions are carried on. Agent tasks, in their turn, describe atomic operations that agents may perform including, possibly, input and output parameters required to accomplish the actions. Indeed, the core of
The second step consists in representing the concrete agent behaviours either by specifying a shared template or by defining it from scratch: in both cases, concrete behaviors have the same shape of templates, where ideal features are replaced with actual characteristics. Behaviours drawn by shared templates are clearly associated with them in order to depict the behaviour inheritance relationship.
Finally, in the third step, actions performed by agents are described as direct consequences of some behaviours and associated with the behaviours of the agent that generates them. To describe such an association,
We now illustrate how those three steps are implemented in
Agent templates in
an instance of the class TaskOperator, characterizing the action to be performed. Instances of TaskOperator are connected either by means of the object-property refersExactlyTo or refersAsNewTo to instances of the class Action. The latter class describes physical actions that are introduced by means of entity names in the form of infinite verbs representing the actions (e.g., produce, sell, …). The object-property refersExactlyTo is used to connect the task operator with a precise action having a specific IRI, whereas refersAsNewTo is used to connect a task operator with an action for which a general abstract description is provided. In the latter case, the action is also defined as instance of the class ReferenceTemplate: instances of the class ReferenceTemplate are used to introduce entities that represent templates for the referred element describing the characteristics that it should satisfy. By exploiting the object-property refersAsNewTo, the entity provides only a general description of the features needed to accomplish the task, for example, that it must be of a specific type; on the contrary, the object-property refersExactlyTo specifies the actual and exact entity that is involved in the task.
Possibly, an instance of the class TaskOperatorArgument, connected by means of the object-property hasTaskOperatorArgument and representing additional specifications for the task operator action (e.g., on, off, left, right, …). Instances of TaskOperatorArgument are referred to the operator argument by specifying either the object-property refersAsNewTo or refersExactlyTo.
An instance of the class TaskObjectTemplate, connected by means of the object-property hasTaskObjectTemplate and representing the template of the object recipient of the action performed by the agent (e.g., apple, …). Instances of TaskObjectTemplate are referred to the action recipient by specifying either the object-property refersAsNewTo or refersExactlyTo.
Input parameters and output parameters, introduced in
UML diagram of agent templates in
Summarizing, the main classes characterizing an agent template in
AgentBehaviorTemplate. This class comprises all the individuals representing templates of agents. Instances of such a class are connected with one or more instances of the class Behavior by means of the OWL object-property hasBehavior.
Behavior. Behaviours of agent templates represent containers embedding all the goals that the agent can achieve. Instances of Behavior are connected with one or more instances of the class GoalDescription by means of the object-property consistsOfGoalDescription.
GoalDescription. Goals represent containers embedding all the tasks that the agent can achieve. Instances of GoalDescription comprised by a behaviour may also satisfy dependency relationships introduced by the object-property dependsOn. Goals are connected with the tasks that form them and are represented by instances of the class TaskDescription through the object-property consistsOfTaskDescription.
TaskDescription. This class describes atomic operations that agents are able to perform. Atomic operations are the most simple actions that agents are able to execute and, hence, they represent what agents can do within the environment. Atomic operations may depend on other atomic operations when the object-property dependsOn is specified. Atomic operations whose dependencies are not explicitly expressed are intended as to be performed in any order. Finally, tasks are linked to the individuals that describe the features of the atomic operations, i.e., the instances of the classes TaskOperator, TaskOperatorArgument, TaskObjectTemplate TaskInputParameterTemplate, and TaskOutputParameterTemplate, as described above.
TaskOperator. This class characterises the type of operation to perform. Instances of TaskOperator are connected with instances of the class Action by means of either the object-properties refersExactlyTo or refersAsNewTo. Tasks are connected with task operators by means of the object-property hasTaskOperator.
Action. This class describes actions that can be performed by agents. Entity names of the class Action’s instances are introduced as infinite verbs such as buy, sell, compute, and so on, drawn from a common, shared and extendable vocabulary defined by the OASIS-Abox ontology (Cantone et al., 2021b).
TaskOperatorArgument. This class defines operator arguments representing subordinate characteristics of task operators. Tasks are connected with operator arguments by means of the object-property hasTaskOperatorArgument.
TaskObjectTemplate. Instances of this class represent the recipient of the behaviours of agent templates. Tasks are connected with object templates by means of the object-property hasTaskObjectTemplate.
TaskInputParameterTemplate. This class represents the input parameters required to accomplish the referred operation, as for instance the wallet to which a token is transferred. Tasks are possibly connected with the input parameters by means of the object-property hasTaskInputParameterTemplate.
TaskOutputParameterTemplate. This class represents the output parameters obtained as a result of the referred operation. Tasks are possibly connected with the output parameters by means of the object-property hasTaskOutputParameterTemplate.
Concrete behaviours of agents are represented in similar way as to behaviour templates (see Appendix A, Fig. 14), which reflects the modelling pattern adopted for the representation of agent behaviour templates described above. The main difference between concrete behaviours and behaviours template can be summarised as follows:
The instance of the class AgentBehaviorTemplate gives way to an instance of the class Agent, representing a concrete agent in the knowledge domain.
The instance of the class TaskObjectTemplate gives way to an instance of the class TaskObject, representing a real recipient of the concrete agent action.
The instance of the class TaskInputParameterTemplate gives way to an instance of the class TaskFormalInputParameter, representing the formal input parameter of the concrete agent action.
The instance of the class TaskOutputParameterTemplate gives way to an instance of the class TaskFormalOutputParameter, representing the formal output parameter of the concrete agent action.
Concrete agents are possibly connected with the agent template that they are drawn from. In order to describe the fact that concrete agents inherit their behaviours from a common and shared agent template, the object-property overloads associates a) the instance of the class TaskDescription of the concrete agent with the instance of the class TaskDescription of the agent template, b) the instance of the class TaskObject of the concrete agent with the instance of the class TaskObjectTemplate of the agent template, c) the instance of the class TaskFormalInputParameter of the concrete agent with the instance of the class TaskInputParameterTemplate of the agent template, d) the instance of the class TaskFormalOutputParameter of the concrete agent with the instance of the class TaskOutputParameterTemplate of the agent template.
Agent actions that are executed autonomously are associated to the description of the concrete behaviour of the agent from which they are drawn: an agent action is primarily introduced by an instance of the class PlanExecution, representing the agent commitment (see Appendix A, Fig. 15). In their turn, plan executions comprise goal executions, represented by instances of the class GoalExecution, whereas goal executions provide task executions (instances of the class TaskExecution) embedding at least the following three elements:
TaskObject. As in the case of agent behaviours, this class comprises elements used as recipients of performed actions.
TaskOperator. As in the case of agent behaviours, this class comprises the operations performed by the agent.
TaskOperatorArgument. As in the case of agent behaviours, this class comprises a specification of the operations performed by the agent. Operator arguments are introduced in agent actions only if the corresponding behaviour that generates the actions also provides operation arguments.
Unlike the tasks of agent behaviours, task executions comprise instances of the following classes, which take the place of the instances of the classes TaskFormalInputParameter and TaskFormalOutputParameter:
TaskActualInputParameter. This class represents the actual input parameters exploited to accomplish the agent action. Task executions are possibly connected with the actual input parameters by means of the object-property hasTaskActualInputParameter.
TaskActualOutputParameter. This class represents the actual output parameters obtained as result of an agent’s action. Task executions are possibly connected with the output parameters by means of the object-property hasTaskActualOutputParameter.
Agent actions are related with the behaviour from which they are drawn by. These relationships are introduced by a) connecting the instance of PlanExecution of the agent action to the instance of the class Behavior of the agent behaviour by means of the object-property planExecutionDrawnBy; b) connecting the instance of GoalExecution of the agent action to the instance of the class GoalDescription of the agent behaviour by means of the object-property goalExecutionDrawnBy; c) connecting the instance of TaskExecution of the agent action to the instance of the class TaskDescription of the agent behaviour by means of the object-property taskExecutionDrawnBy; d) connecting the instance of TaskObject of the agent action to the instance of the class TaskObject of the agent behaviour by means of the object-property taskObjectDrawnBy; e) connecting each instance of TaskActualInputParameter of the agent action to the related instance of the class TaskDescription of the agent behaviour by means of the object-property taskActualInputParameterDrawnBy; f) connecting each instance of TaskActualOutputParameter of the agent action to the related instance of the class TaskDescription of the agent behaviour by means of the object-property taskActualOutputParameterDrawnBy; g) connecting the instance of TaskOperator of the agent action to the related instance of the class TaskOperator of the agent behaviour by means of the object-property taskOperatorDrawnBy;
We now recall
Figure 2 depicts the schema of
Conditional atoms are introduced by means of the following classes:
ConditionalAtom: represents a conditional atom;
ConditionalHeadAtom: represents atoms of conditional consequents and is defined as a subclass of the class ConditionalAtom;
ConditionalBodyAtom: represents atoms of conditional antecedents and is defined as a subclass of the class ConditionalAtom;
ConditionalSubject: represents subjects of atoms of conditional consequents or of conditional antecedents;
ConditionalObject: represents objects of atoms of conditional consequents or of conditional antecedents;
ConditionalOperator: represents actions of atoms of conditional consequents or of conditional antecedents;
ConditionalParameter: represents parameters of actions considered by conditional consequents or conditional antecedents (the class ConditionalParameter includes the classes ConditionalInputParameter and ConditionalOutputParameter, representing the input and output parameter, respectively);
ConditionalOperatorArgument: defines operator arguments that represent a subordinate characteristic of the conditional operator (for example, “quality check” may be represented by the operator check with argument quality);
ConditionalEntryTemplate: represents templates of the features that the entities involved in the conditional, which are introduced by means of the object-property refersAsNewTo, must satisfy.
Conditionals are introduced in
Conditional: defines conditionals, comprising a consequent (head) and an antecedent (body), both consisting in a conjunctive set of atoms;
ConditionalHead: represents consequents (heads) of conditionals. Conditionals comprise at least by one instance of ConditionalHead;
ConditionalBody: represents antecedents (bodies) of conditionals. Conditionals comprise zero or more instances of ConditionalBody, while instances of ConditionalBody are constituted by one or more instances of ConditionalBodyAtom;
ConditionalSet: represents conjunctive sets of conditionals.
UML diagram of conditionals in
Conditional atoms are related with a subject (instance of the class ConditionalSubject), an object (instance of the class ConditionalObject), and an operator (instance of the class ConditionalOperator) by means of the object-properties hasConditionalSubject, hasConditionalObject, and hasConditionalOperator, respectively. Moreover, conditional atoms are possibly related with parameters (instances of the class ConditionalParamenter) and with operator arguments (instances of the class ConditionalOperatorArgument) by means of the object-properties hasConditionalParameter and hasConditionalOperatorArgument, respectively. Specifically, input and output parameters are introduced through the object-properties hasConditionalInputParameter and hasConditionalOutputParameter, respectively.
In
The first way consists in directly indicating the individual involved in the conditional by means of the object-property refersExactlyTo, e.g., the address of a digital wallet of a specific person. In the second approach, the entry is unknown but there is a set of desirable features that the entry must own in order to make the conditional satisfied when it is checked. For example, if a digital asset is sold to anyone who sends the correct amount of money to the designated wallet, the seller (i.e., the conditional entry) will not be known until the transaction is completed: completing the transaction is the necessary requirement for a specific entity to be identified as the “buyer” of the transaction. In such situations, the object-property refersAsNewTo is used to indicate an instance of the class ConditionalEntryTemplate, which endows the set of features that must be satisfied by the conditional entry.
Instances of the classes ConditionalHead and ConditionalBody are related to instances of the classes ConditionalHeadAtom and ConditionalBodyAtom, representing conditional atoms through the object-properties hasConditionalHeadAtom and hasConditionalBodyAtom, respectively. The object-properties hasConditionalHeadAtom and hasConditionalBodyAtom are defined as subproperties of the object-property hasConditionalAtom.
Finally, conditionals are introduced in
In this section, we describe how the Ethereum blockchain is modelled in
The ontology is reachable at (Bella et al., 2021).
Overview of
With respect to similar ontologies such as Ethon (Pfeffer et al., 2016) and BLONDiE (Ugarte Rojas, 2017),
UML diagram of the Ethereum blockchain in
Ethereum is represented in
For the rest of this article, we use the namespace prefix oasis for
Miners nodes are conceived as
In
The transactions (represented by instances of the class EthereumTransaction) induced by interaction requests submitted to smart contracts are related with instances of the class EthereumContractInteraction (subclass of SmartContractInteraction, representing interactions of smart contracts through the blockchain) by means of the object-property describes. Instances of the class EthereumContractInteraction introduce plan descriptions as in the
Figure 5 shows an Ethereum transaction storing the smart contract for emitting NFTs of the Sicilian Wheat Bank (SWB) S.p.A.6
UML diagram of an example of an Ethereum transaction in
Next, we show how
As described above, the smart contracts defined for the ERC-721 token management are introduced by way of instances of the class EthereumERC721SmartContractAgent (subclass of Agent). In
Figure 6 illustrates the behaviour template provided by
The second element of the ERC-721 token minting task is the operator argument introducing the individual blockchain_digital_token by means of the object-property refersExactlyTo. Operators and operator arguments identify unambiguously that the referred operation consists in generating (digital) tokens on the blockchain. The third and the fourth elements represent the recipient and the outcome of the operation, respectively. The recipient is described by the template of the task object, while the outcome is introduced by the template of the output parameter of the task. The object template and the output parameter are both connected through the object-property refersAsNewTo to the entity mint_ERC721_token, which describes the features that the recipient of the action must have, namely, being an instance of the class EthereumTokenERC721.
UML diagram of behaviour template for the ERC-721 minting function.
The behaviour for the ERC-721 function for transferring tokens is depicted in Fig. 7. The behaviour provides three input parameters, one for the token to be transferred and one for each externally owned account involved in the transferring of the token, namely the source wallet and the destination wallet. The source and destination wallets are introduced by exploiting the object-property refersAsNewTo by means of two individuals that are instances of the class EOA-EthereumAccount, namely, transfer-2_ERC721_EOA-account (the source) and transfer-3_ERC721_EOA-account (the destination). To ensure that the token is transferred from the wallet identified as source to the wallet identified as destination, the conditional illustrated in Fig. 8 is provided.
UML diagram of behaviour template for the ERC-721 transfer function.
The conditional ensures that a transfer activity for each token to be transferred exists. The conditional has a fresh transfer activity as conditional object, and the individual exist as operator. In its turn, the transfer activity indicates as transfer source the wallet used as first parameter in the token transferring, as transfer destination the wallet used as second parameter, and as transferred object the token passed as input parameter.
UML diagram of the conditional for the ERC-721 transfer function.
The behaviour for the burning function of the ERC-721 standard is depicted in Appendix B, Fig. 18. In this case, the individual ethereum_ERC721_smart_contract_behavior_template (representing the ERC-721 behaviour template) is also connected to the behaviour describing the burning function, whose structure is analogous to the minting function but with a different action and with an input parameter template instead of an output parameter template. The action introduced in the burning function is the individual burn, while the input parameter template is connected with an individual representing the token to be burnt that is passed as input to the burning function.
The standard ERC-721 also allows the owner of tokens to delegate wallets to manage tokens on his/her behalf. Authorizations may be carried out either on a single token or on any token stored in his/her wallet. The ERC-721 function approve and setApprovalForAll are introduced for the former and the latter case, respectively.
In case that an externally owned account is authorised to manage a single token, the behaviour in Appendix B, Fig. 19 is adopted.
Specifically, the behaviour introduces: (a) the account to be authorised and the granted token, as input parameter; (b) the instance delegate, as operator; and (c) the instance ownership, as task operator argument.
The conditional in Appendix B, Fig. 20 ensures that only the operation of burning and transferring may be performed when the wallet is authorised to operate on behalf of his owner. Such a condition is guaranteed by the existence of a delegation activity (instance of DelegationActivity) having as delegation property the instances burn and transfer. The subject and the object of the delegation activity are the authorised wallet and the granted token, respectively.
The Ethereum ERC-721 standard allows token owners to authorise an account to manage all the tokens owned. The corresponding behaviour is illustrated in Appendix B, Fig. 21. The behaviour is similar to the behaviour template introduced for granting a single token, with the only difference that there is no input parameter concerning the granted token. In this case, the conditional in Appendix B, Fig. 22, ensures that authorization is extended to each token owned. Indeed, the delegation object expresses the object-property hasSpecificity with value the individual any.
The Ethereum ERC-721 standard allows users to discover the wallet currently owning a certain token. The corresponding behaviour is illustrated in Appendix B, Fig. 23. The behaviour is related with a task description providing both as recipient and as input parameter the selected token whose owner has to be retrieved. The conditional in Appendix B, Fig. 24, ensures that the wallet retrieved is the effective owner of the token considered.
UML diagram of the Ethereum token representation in
One of the most important features of
non-fungible tokens, represented by instances of the class EthereumSemiFungibleToken, the latter containing the class EthereumTokenERC721 that represents non-fungible tokens compliant with the ERC-721 standard protocol. In its turn, EthereumSemiFungibleToken is a subclass of the
Fungible tokens, represented by instances of the class EthereumFungibleToken, the latter containing the class EthereumTokenERC20 that represents fungible tokens compliant with the ERC20 standard protocol. EthereumFungibleToken is a subclass of FungibleToken.
Semi-fungible tokens, represented by instance of the class EthereumSemiFungibleToken, the latter containing the class EthereumTokenERC1155 that represents semi-fungible tokens compliant with the ERC1155 standard protocol. EthereumSemiFungibleToken is a subclass of SemiFungibleToken.
Custom user-defined tokens not compliant with the ERC standard protocols, represented by instances of the class EthereumCustomToken, subclass of CustomToken.
Additionally, the four mentioned classes are defined as subclasses of the class EthereumToken.
Inspired from the definitions in (Gangemi et al., 2002), tokens carry two types of features, namely a) endurant features such as the token ID that never change and are embedded with the entity representing the token, and b) perdurant features that change during the life-span of the token and are associated with an instance of the class EthereumTokenPerdurantFeatures (subclass of PerdurantFeature) by means of the object-property hasEthereumTokenPerdurantFeature.
The most notable subclass of PerdurantFeature is the class EthereumWalletOwnerPerdurantFeature, which associates tokens with the related owner (by means of the object-property isInTheWalletOf). When the perdurant features of a token are modified by the smart contract managing it, they became deprecated and replaced with a new set of features by means of a suitable modification activity. Those new features are introduced by a fresh instance of the class PerdurantFeature. Modifications of tokens are allowed only when they involve perdurant features and hence endurant features cannot change. Perdurant features may be replaced with other perdurant features by introducing an instance of the class EthereumTokenFeatureModificationActivity, which is connected with (i) the changed perdurant feature, which is also an instance of the class EthereumTokenDeprecatedPerdurantFeature by means of the object-property hasEthereumTokenFeatureModificationSource, and with (ii) the new perdurant feature, by means of the object-property hasEthereumTokenFeatureModificationResult.
Moreover, the modified perdurant feature is connected with the perdurant feature that replaces it by means of the object-property isEthereumTokenFeatureModifiedIn, while the token embedding the features is connected with the new perdurant feature by means of the object-property hasEthereumTokenPerdurantFeature, as described above.
Analogously, the state of a token can be changed from active to burned. An instance of the class TokenActivationStatusModificationActivity is introduced to represent the burning of the token due to a call to the burning function of the smart contract. Such instance connects the old active status, which is now deprecated, by means of the object-property hasTokenActivationStatusModificationSource, and a new status (representing the deactivation status) by means of the object-property hasTokenActivationStatusModificationResult.7
This approach based on deprecating the old activation status is motivated by the fact that, unlike perdurant features, activation status of tokens can be restored, depending on how the burning function is implemented.
In this section we illustrate a concrete application of
The OWL of the example can be found in
An NFT of wheat is an instance of both the class EthereumTokenERC721, representing the Ethereum non-fungible tokens, and of the class SWBWheatToken, representing the token of wheat emitted by the SWB smart contract.
An NFT of wheat is related with an integer through the data-property hasEthereumTokenID, representing the unique and progressive identification code (ID) of the NFT. As foreseen by Ethereum, the ID is unique within the smart contract, and IDs of burned tokens are not reassigned.
An NFT of wheat satisfies at least one perdurant feature. The mandatory perdurant feature describes the ownership of the token.
Moreover, NFTs generated from the SWB smart contract satisfy the following features too:
An NFT of wheat is related with an instance of the class QualityClass (through the object-property hasQualityClass). Specifically, QualityClass contains the instances PlatinumQuality, GoldQuality, SilverQuality, and BronzeQuality, representing the quality level of wheat from the higher to the lower.
An NFT of wheat is related with a double through the data-property hasQuantity, representing the quantity of wheat digitised.
An NFT of wheat is related with an instance of type EthereumAccount through the object-property hasProducer, representing the wallet of the farmer that requested the digitization of the batch.
In this example we consider the minting and transferring of the token number 217 illustrated in Fig. 10. The token with ID 217 digitised a batch of 98 tons, classified as “gold” and currently owned by the wallet number “0x41db48574b0a6e59f30ad59fee63f023eb7b9745”.
Example of an SWB token numbered 217.
Minting behaviour of an SWB smart contract.
As a concrete agent, the smart contract implements all the behaviour templates in Section 4.2. In particular, the concrete behaviours for minting and transferring tokens are introduced by extending the corresponding template in Section 4.2, Fig. 6 and Fig. 7, respectively. For instance, the minting behaviour of the smart contract is depicted in Fig. 11. The concrete behaviour follows the same lines of the corresponding template. Each mental state of the behaviour is linked with the corresponding state of the template by means of the object-property overloads. As in the template, the recipient of the action represents an ERC-721 compliant token, which is additionally an SWB compliant token.
In order to generate the token 217, an agent commitment derived from the concrete behaviour in Fig. 11 is required. For this purpose, the fragment illustrated in Fig. 12 is introduced. The figure shows a fragment of the action associated with the minting behaviour of the SWB smart contract. The action carries all the mental states required to perform the minting of an SWB token, which are also connected by means of the object-property drawnBy with their corresponding states of the concrete behaviour of the smart contract. The task recipient is a specific entity that refers to token 217, which is different from the general SWB token described in the template recipient. The task recipient is linked to the token 217 by means of the object-property ‘refersAsNewTo’.
The agent commitment for minting the SWB token 217.
From now on, the token is available and ready to be traded. To complete the example, the token 217 is transferred from the wallet of the farmer to a chosen wallet (called cp132-trader). In a similar way as the minting of the token, an agent commitment derived from the concrete behaviour devoted to the transferring of SWB tokens is required. As a consequence of that action, the ownership of the token is changed through the introduction of a modification activity involving the perdurant features of the Ethereum token. Specifically, the modification activity is introduced to mark as deprecated the perdurant feature that associates the ownership of the token with the producer, and to introduce a new perdurant feature that associates the token with the new owner. The result is shown in Fig. 13. The figure shows (on the left) the transfer activity involving the two perdurant features concerning the ownership of the token 217, the old perdurant feature that becomes deprecated (on the right), and the new perdurant feature (in the bottom-center). Now the token is in the wallet of the new owner cp132-trader and can continue its life cycle.
The transfer activity involving the SWB token 217.
The
In addition, a suitable set of competency questions were defined for the modeling of
In what follows, we report the results of the evaluation methodology, including the competency questions defined, together with a discussion of the results obtained.
Consistency check has been carried out by the reasoners Pellet (Sirin et al., 2007), HermiT (Glimm et al., 2014), and FaCT
The last GitHub commit (
Structural metrics on
We recall that BLONDiE provides the description of three blockchains, namely Ethereum, Hyperledger Fabric, and Bitcoin, while
Moreover,
The ontological metrics computed by OntoQA on the
Ontological metrics of
The relationship richness metric reflects the diversity of the relations and the placement of the relations occurring in the ontology. With respect to BLONDiE, the difference of relationship richness in
We are now ready to discuss the competency questions for the Who mined a specific block? What is the height of a specific block? How many transactions are written in a block? Is a transaction confirmed? How many total coins were transferred on a block?
C1: Which are the tokens minted and not burned, the associated asset, minter, and current owner?
Competency question C1 is intended to retrieve the tokens available on the Ethereum blockchain and their type, providing an overview of the current arrangement of the token market. In addition, the competency question also shows the asset digitised by the token, thus enabling users to discover and possibly acquire the desired product through a decentralised infrastructure: by knowing quantity and type of assets traded by means of their corresponding tokens, it is possible to realise new instruments for analyzing the market and potentially generate new business opportunities.
C2: Which are the block and the transaction hash that mint a given token?
Competency question C2 allows users to verify that the given token has been effectively minted on the blockchain, and hence a proof for the related asset is available. In addition to the other competency questions, this constitutes a countermeasure against NFTs scams.
C3: Which are the smart contracts that emit tokens related with a specific type of asset?
Competency question C3 allows users to access the smart contracts that generate the tokens associated with the desired type of digital or physical asset: the functionalities of the smart contracts are clearly expressed, thus users have an effective instrument to evaluate the affordability of the related NFT exchange system.
C4: Which is the number of tokens and the type of the related assets owned by wallets?
Competency question C4 allows users to verify how many tokens associated with the desired asset are owned by wallets, thus permitting to check whether whale wallets own the desired tokens. The term ‘whale wallet’ refers to individuals or entities that hold large amounts of specific cryptocurrencies or tokens and therefore have the potential to manipulate their valuations on the market.
This paper presented the
In conclusion, the present work supports the claim that the potential of the semantic representation of blockchains is vast, contributing substantially to the more flexible yet usable blockchain technology expected in the very next version of the Web.
Footnotes
Acknowledgements
This work is an extended version of the paper “Blockchains through ontologies: the case study of the Ethereum ERC721 standard in OASIS”. In D. Camacho et al. (eds.), Intelligent Distributed Computing XIV, Studies in Computational Intelligence 1026, Chapter 23, pp. 249–259.
This work was supported by the project “FuSeCar” funded by the MUR Progetti di Ricerca di Rilevante Interesse Nazionale (PRIN) Bando 2022 – grant 2022W3EPEP – CUP: E53D23008210006
The work of POC4Commerce has been supported by the ONTOCHAIN NGI European project grant agreement no. 957338. We are thankful to the ONTOCHAIN Consortium who mentored and assisted the research.