EP4695931A1

EP4695931A1 - Double checking a blockchain transaction request

Info

Publication number: EP4695931A1
Application number: EP24722717.6A
Authority: EP
Inventors: Tahir Mahmood
Original assignee: Krnl Labs
Current assignee: Krnl Labs
Priority date: 2023-04-25
Filing date: 2024-04-22
Publication date: 2026-02-18
Also published as: WO2024224051A1

Abstract

A computer-implemented method of processing a blockchain transaction request comprises receiving (2014; 3014; 4012) a blockchain transaction request and directing (2020; 3020; 4020) the blockchain transaction request to a specific node of a blockchain. The specific node interrupts (2030) execution of the blockchain transaction request, and directly or indirectly performs (2046) at least one service in relation to the blockchain transaction request.

Description

DOUBLE CHECKING A BLOCKCHAIN TRANSACTION REQUEST

The present invention relates to processing blockchain transaction requests.

A blockchain is a well-known type of distributed ledger where data records are organized into blocks that are securely linked together via cryptographic hashes. Nodes of a blockchain network comprise independent peer-to-peer computers that are configured to save, share and synchronize transactions in their respective blockchain records.

Transactions are instructions that blockchain accounts issue to the blockchain network. An example of a simple transaction is transferring a token from one account to another. Some blockchain networks also support smart contracts, which are self-executing programs deployed on the blockchain network and designed to enforce the rules and conditions of an agreement between two or more parties.

An account can initiate a transaction request to the blockchain network from a node. The transaction request may typically be generated by a user using a decentralized application or a wallet. A node may verify the transaction request before it is propagated to other nodes in the blockchain network. The nodes communicate with each other to validate the transaction, e.g. by confirming that it exists, is legitimate and meets any criteria required to add it to the blockchain.

Although existing blockchains provide a degree of certainty regarding transactions, it can be desirable to perform additional services in relation to blockchain transaction requests that are not presently provided by blockchains. Such additional services can improve the security of transactions, e.g. by performing additional checks as to whether they comply with specific regulations and/or do not invoke any security-compromising smart contracts/code, etc. Additional services may also allow an additional level of flexibility over and above those offered by existing smart contracts. For example, a user may want to have one particular transaction signed off by one or more other person/entity before it is executed, or have additional rules applied to it.

Embodiments of the present invention aim to address at least one of the above problems. Embodiments can allow a transaction request in flight within a blockchain node to be interrupted/paused before it is propagated to the blockchain so that at least one additional service relating to the transaction request can be performed. The service will typically comprise one that is not normally performed as part of the transaction execution process by the blockchain. The service can take various forms, such as transaction/request analysis; interaction with one or more parties; charging (e.g. using the blockchain’s native currency/gas fees) for the services that are provided, and/or real-time monitoring. Thus, the service(s) can improve security of transaction execution. The result(s) of the service(s) can be seen by a user, a client application and/or dApp installed on a user’s device. The user may be given an additional opportunity to approve execution of the transaction request based on the result(s) of the analysisZservice(s), or may stop it from being fully executed. In some cases the system can be considered a “gateway” that effectively allows permissioned blockchain solutions to be implemented on a public blockchain. Embodiments may structure the gateway as a marketplace where users/enterprises can install specific services/applications to suit their particular requirements.

According to a first aspect of the present invention there is provided a computer- implemented method of processing a blockchain transaction request, the method comprising: receiving a blockchain transaction request; directing the blockchain transaction request to a specific node of a blockchain, and at the specific node, interrupting execution of the blockchain transaction request, and (directly or indirectly) performing at least one service in relation to the blockchain transaction request.

The specific node may be configured to communicate with a remote computing system. The specific node may be configured to (after interrupting the executing of the blockchain transaction request) indirectly perform the at least one service by instructing the remote computing system to perform the at least one service in relation to the blockchain transaction request. In alternative embodiments the specific node may be configured to directly perform the at least one service by means of/using instructions executed on a processor in the specific node.

The specific node may interrupt the (normal) execution of the blockchain transaction request (typically directly/immediately) after verification of the blockchain transaction request (by the specific node) and before propagation of the blockchain transaction request to other nodes of the blockchain. The propagation can take place after the at least one service has been performed.

The at least one service may comprise performing at least one check relating to the blockchain transaction request. The method may further comprise continuing the execution of the blockchain transaction request on the blockchain if a result or results of the at least one check is positive, or not continuing the execution of the blockchain transaction request on the blockchain if the result or results of the at least one check is negative. The at least one check may relate to regulatory compliance, security vulnerability, etc, of the blockchain transaction request, e.g. a party identified in the blockchain transaction request, and/or a smart contract identified by the blockchain transaction request. The at least one check may comprise detecting whether the blockchain transaction request involves a blacklisted account/address. The at least one check may comprise detecting whether the blockchain transaction request involves a smart contract that includes code (e.g. bytecode) known to have security issues, e.g. by comparing at least part of the code with existing code stored in a data store, e.g. accessed by the remote computing system.

The at least one service may comprise obtaining at least one digital signature from an entity other than a user who initiated the blockchain transaction request.

The at least one service may comprise applying at least one rule (of a workflow) to the blockchain transaction request.

The method may further comprise: transmitting a result of the at least one service to a user who initiated the blockchain transaction request, and (then) requesting confirmation from the user whether the execution of the blockchain transaction request should continue.

The method may further comprise, prior to performing the at least one service, determining whether a user/user account who initiated the blockchain transaction request has at least a specified/predetermined amount of currency (e.g. gas) required to perform the at least one service. The currency can typically comprise a native currency of the blockchain network.

The method may further comprise: registering a user associated with an account on the blockchain as a registered user of a service system, and configuring a wallet and/or a digital asset custodian associated with the registered user to direct all blockchain transaction requests to an address of the specific node. A distributed application may be configured to set the wallet and/or the digital asset custodian to direct the blockchain transaction requests to the address of the specific node. The method may further comprise installing a client application on a device associated with the registered user, wherein the client application is configured to set the distributed application, the wallet and/or the digital asset custodian to direct the blockchain transaction requests to the specific node. The distributed application may be configured to direct the blockchain transaction request to the specific node by pointing, e.g. via network configuration, a wallet/custodian associated with a user account to send all transaction requests to an address of the specific node. The wallet or the custodian may be configured to direct all transaction requests to an address of the specific node. In alternative embodiments the steps of receiving the blockchain transaction request and directing the blockchain transaction request to the specific node may be performed by a client application installed on a user device.

The method may comprise providing the specific node on the blockchain by preconfiguring a node of the blockchain to interrupt execution of a said blockchain transaction request that is received from a wallet of an account (or user) registered with an external service system. The method may comprise determining whether a wallet and/or a sender/account from which the transaction request was transmitted is one present/identified in a data store of the external service system.

In some embodiments the method may comprise the remote computing system communicating with a specific node on another blockchain in order to perform at least one further service. This communication may take place after the at least one service in relation to the blockchain transaction request has been completed, for example.

The method may comprise installing a client application on a device associated with the user. The client application may configure a distributed application or a wallet or custodian to direct the blockchain transaction request to the specific node. The client application may communicate with the remote computing system, e.g. it may transmit data associated with the user to the remote computing system for use in confirming an identity of the user for performing the at least one service.

The blockchain transaction request may be initiated by a user registered with a serviceproviding system that is implemented using the remote computing system. The received blockchain transaction request may comprise a signed blockchain transaction request, which may be received from a wallet or a custodian associated with the user.

The remote computing system will typically be external to the blockchain, e.g. the remote computing system will typically not be (configured as) a node of the blockchain.

The method may further comprise: before directing the blockchain transaction request to the specific node, obtaining an estimated cost of performing the at least one service in relation to the blockchain transaction request; presenting the estimated cost to a user; obtaining user input to cancel or continue the executing the transaction request in view of the estimated cost, and directing the blockchain transaction request to the specific node if the user input is to continue or cancelling or continuing the executing the transaction request based on the user input.

In some embodiments each of a plurality of remote computing systems may be configured to provide a type of service in relation to the blockchain transaction request. The method may further comprise: obtaining performance information comprising at least one performance factor associated with each of the plurality of remote computing systems for performing the type of service, and selecting one of the plurality of remote computing systems to provide the type of service in relation to the blockchain transaction request based on the performance information.

According to another aspect of the present invention there is provided a system configured to process blockchain transaction requests, the system comprising: a first computing device, and a further computing device configured to function as a specific node of a blockchain , wherein the first computing device is configured to receive a blockchain transaction request and direct the blockchain transaction request to the specific node of the blockchain, and wherein the specific node is configured to interrupt execution of the blockchain transaction request and to (directly or indirectly) perform at least one service in relation to the blockchain transaction request.

The system may further comprise a remote computing system and the further computing device may be configured to communicate with the remote computing system. The specific node may indirectly perform the at least one service by instructing the remote computing system to perform the at least one service. According to yet another aspect of the present invention there is provided a computing device configured to function as a specific node of a blockchain, wherein the computing device is further configured to: interrupt execution of a received blockchain transaction request and directly or indirectly perform at least one service in relation to the blockchain transaction request.

According to a further aspect of the present invention there is provided a method of operating a computing device configured to function as a specific node of a blockchain, the method comprising: interrupting execution of a received blockchain transaction request, and performing at least one service in relation to the received blockchain transaction request.

According to yet another aspect of the present invention there is provided a computing system configured to: communicate with a specific node of a blockchain, and perform at least one service in relation to a blockchain transaction request based on instructions received from the specific node.

According to a further aspect of the present invention there is provided a method of operating a computing system, the method comprising: receiving an instruction from a specific node of a blockchain, and performing at least one service in relation to a blockchain transaction request based on the instruction received from the specific node.

According to further aspects of the invention there is provided a client device configured substantially as described herein and a method of operating a client device substantially as described herein.

According to further aspects of the invention there is provided a method of preconfiguring a distributed application substantially as described herein and a method of preconfiguring a blockchain node substantially as described herein. According to yet another aspect of the present invention there is provided a computing device configured to perform any of the methods described herein.

According to another aspect of the present invention there is provided a computer readable medium storing a computer program to operate any of the methods described herein.

According to the present invention, there is provided a method and apparatus as set forth in the appended claims. Other features of the invention will be apparent form the dependent claims, and the description which follows.

For a better understanding of the invention, and to show how embodiments of the same may be carried into effect, reference will now be made, by way of example, to the accompanying diagrammatic drawings in which:

Figure 1 is a block diagram of a system configurable to execute embodiments of the invention;

Figure 2 is a sequence diagram illustrating steps related to an embodiment of the invention where a user initiates a blockchain transaction request using a distributed application;

Figure 3 is a sequence diagram illustrating steps related to an embodiment where a user initiates a transaction request using a client application;

Figure 4 is a sequence diagram illustrating steps related to an embodiment where a user initiates a transaction request using a cryptocurrency wallet;

Figure 5 is a sequence diagram illustrating steps related to an embodiment that involves multiple digital signatures, and

Figure 6 is a sequence diagram illustrating steps related to an embodiment that applies rules in relation to the transaction request.

Figure 1 is a block diagram, specifically a modified C4 context diagram, of an example system 100 configurable to execute embodiments of the invention. The system comprises at least a client device 102, a service provider computing system 104 and one or more blockchain network 106. Each of these can be implemented by means of one or more computing device, with each computing device normally including, or being associated with, at least one processor, memory and communications interface. The components and features of the computing devices will be well-known to the skilled person and need not be described herein in detail. Suitable examples of the client device 102 include a desktop personal computer, a laptop computer, or a mobile computing device, such as a smartphone or tablet computer. The service provider computing system 104 may comprise one or more server class computer, for example, which may be configured to provide a cloud service in some cases. The blockchain network 106 will comprise a decentralized network of computers, each of which is configured to function as a node of the blockchain. Although the embodiments detailed herein are based on the Ethereum™ blockchain it will be understood that alternative embodiments can operate with other blockchain networks that may or may not support smart contracts. Examples include Binance Smart Chain (BSC), Polygon (MATIC) or Optimism (OPT).

In the Ethereum™ network transactions are instructions signed with cryptographic security that are sent from accounts to update the state of the network. In some cases the transactions may use smart contracts, which can store any type of state and perform any kind of computation. A smart contract is composed of both code and data stored at a specific address on the blockchain. Smart contracts cannot be removed by default and any interaction with them is considered irreversible. To interact with a smart contract, users create transactions. To deploy a smart contract on a blockchain, a transaction may be sent from a user’s blockchain wallet that includes the compiled code for the smart contract and a receiver address. Smart contract transactions can invoke other smart contracts and alter the state of the network, e.g. by sending coins/gas from one contract or account to another. Once the transaction is included in a block that is added to the blockchain, the smart contract's code will execute and establish the initial state of the contract.

As smart contracts are considered a type of Ethereum™ account, they possess a balance and can be the recipient of transactions. Although Ethereum™ supports several programming languages and compilers, the most common language for Ethereum™ contracts is currently Solidity. Solidity is a high-level programming language and when an Ethereum™ client like geth is installed, it comes with a lightweight operating system called Ethereum™ Virtual Machine (EVM) that is specially created to run smart contracts. EVM is a virtual machine that is a collection of individual, networked machines called nodes that act as a single machine. In EVM, each node runs a client software that implements Ethereum™ specifications and they form a network. This network of nodes synchronizes its state so that they together form a giant database that is always synchronized. The agreement on the state of the data is achieved through a consensus algorithm and must be achieved across the network of nodes.

When the Solidity code is compiled it will be converted to low-level bytecode that only EVM can understand. Each instruction step in bytecode is an operation that is referred to as opcode. Opcodes are 1-byte long. Every line of code in the smart contract gets converted to opcode so that the computer knows what to do when running the code. The bytecode of contracts (generated by the Solidity compiler sole) is distributed via dedicated contract creation transactions and gets executed by the EVM on each local node. Once the contract creation transaction is committed to the ledger, all nodes compute the contract address - which is required to invoke contracts - and initialize the contract code and data. Transactions that alter the state of the EVM must be shared with the entire network. Any node can request a transaction to be executed on the EVM, and once it is, a validator will execute the transaction and share the resulting state change with the rest of the network.

The client device 102 may be owned/ope rated by a user 108. The user may be an individual or an enterprise/organization, for example. The user will typically have an account, e.g. an Ethereum™ account, on the blockchain network 106. The user will have at least one associated cryptocurrency wallet 110 and may also use a digital asset custodian/centralized exchange software system 112. Each externally owned account (EOA) on the blockchain network has a private key, which must be used to sign a transaction request before it is sent to the blockchain network for execution.

The user 108 may use one or more decentralized application (dApp) 114, which will typically be built and deployed on the blockchain network 106, to create or modify transaction requests and to arrange for them to be executed on the blockchain. The dApp may relate to decentralized finance (DeFi). Examples of suitable applications that can be used in conjunction with embodiments include Uniswap, OpenSea, Compound, MakerDAO, Aave and dYdX. Other examples can be found at https://dappradar.com/rankings/category/defi. dApps have their backend code (e.g. smart contracts) running on the decentralized network rather than a centralized server. Developers of a dApp can use a software development kit (SDK) 116 for incorporating libraries into their project to create a seamless experience for the user.

The user device 102 can also be configured to execute a client application 118 according to embodiments. The client application can provide a “gateway” or interface that allows the user 108 to interact with an external service system that is implemented using the service provider computing system 104. A user can interact with the client application 1 18 and/or the dApp 114 in order to specify one or more additional service, implemented via the service provider computing system 104 (or in some cases by a specially configured blockchain node 154), that should be performed in connection with a blockchain transaction request that they can initiate in one of various ways, such as described below. For example, if the user is an IT Department of a financial institution such as a bank then they may configure the client application or the dApp to specify that a service in the form of at least one additional compliance check (e.g. GDPR and/or AML/KYC) is to be performed in relation to all transaction requests that are generated. In other cases, the client application or the dApp may provide a user interface, e.g. menus, that allow a user to manually select one or more particular services to be applied at the time when the transaction request is generated.

The service provider computing system 104 will normally be owned/operated by a service provider entity that offers the external service system to users. The illustrated embodiment comprises a set of software components/containers as described herein, but it will be understood that these are merely exemplary and in other cases one or more may be omitted and/or at least one additional component/container may be included. Any or all of these may be used to provide a service to the user 108, particularly in relation to the user’s blockchain transaction requests.

The service provider computing system 104 may comprise an analytics, reporting and data mining tools software component 120. These tools can provide one or more service in the form of statistical analysis, generate reports and visualisation, and/or discover hidden patterns and relationships in data, for example. All data about the blockchain transactions processed using the computing system 104, including logs, data that is passed in/out of the services such as 126, 130, 124 and external systems 146, 148 can be recorded in databases 138, 140 accessible by the computing system. This data can be used as source data by the software component 120 for providing reports in a known manner. The computing system may comprise a dashboard software component 122. This can provide one or more service in the form of realtime telemetry, metrics and/or state of health statistics of the external service system’s infrastructure, for example. All the logs generated by the various software components within the system 104 can be processed with other data, such as some or all of the examples given below:

System-level data: This includes data such as CPU usage, memory usage, disk I/O, network I/O, and other resource utilization metrics that help to monitor the performance of the system as a whole.

Application-level data: This includes data such as request/response times, error rates, throughput, and other metrics that help to monitor the performance of specific applications running on the system.

User-level data: This includes data such as user sessions, user behaviour, and other metrics that help to monitor the user experience and engagement with the system.

Security-related data: This includes data such as login attempts, failed authentication attempts, and other security-related metrics that help to monitor the security posture of the system.

The service provider computing system 104 may comprise a workflow/multi-signature engine software component 124. This can provide one or more service in the form of requiring multiple parties to sign off on a transaction request or ensuring one or more rules have been applied to the transaction request before it can be executed, for example. Specific examples are disclosed further below.

The service provider computing system 104 may comprise an oracle software component 126. This can provide an oracle service that is used for communication and event listening, for example. For blockchains to securely interact with off-chain resources, they need the help of an oracle, which is middleware that connects smart contracts to external systems, including enterprise resource planning (ERP) systems. Oracles can connect loT devices to blockchain environments for enterprises to take advantage of the benefits of smart contracts. The computing system may comprise a security vulnerability tool software component 128. This can provide one or more service in the form of detecting security vulnerabilities in transactions. In embodiments the security vulnerability detection may comprise detecting whether the transaction request involves a blacklisted account/address. It may comprise checking whether a smart contract invoked by the transaction request includes code (e.g. bytecode) that is known to have security issues, e.g. by comparing at least part of the code with existing code stored in a data store. In some embodiments the detection may be based on artificial intelligence/machine learning that can apply a trained machine learning structure to the bytecode, such as a deep learning-based vulnerability detection method that uses a common feature extractor to learn generic bytecode semantics of smart contracts and separate branches to learn the features of each vulnerability type that can detect multiple vulnerabilities of the contract at once. An example of a vulnerability detection system having functionality that can be used in connection with embodiments is described at the following link (the contents of which are hereby incorporated by reference): https://www.ndss-symposium.org/ndss-paper/smarter-contracts-detecting- vulnerabilities-in-smart-contracts-with-deep-transfer-learning/

The service provider computing system 104 may comprise a RegTech software component 130 that can help banking and financial companies comply with government regulations. This can provide one or more service in the form of helping monitor transactions, detecting and preventing fraud, managing risks and ensuring compliance with regulations, for example. The integration of services such as GDPR, KYC, AML and/or Blockchain technology can enable accountability and provenance tracking of operations carried out on user data that is included in blockchain transactions processed via the computing system 104. In some embodiments the service may comprise comparing data in the transaction request with stored data, e.g. whether an account specified in the request is associated with a user for which the stored data indicates a GDPR and/KYC check has been completed. The computing system may comprise an on-chain monitoring software component 132. This can provide services in the form of monitoring on-chain events, such as all or some of the following examples: Subscribe to transaction notifications: Most blockchain networks have a mechanism for subscribing to notifications about new transactions. For example, Bitcoin has a "raw transaction" notification system that can be used to detect new transactions.

Monitor the mempool: The mempool is the pool of unconfirmed transactions on a blockchain network. By monitoring the mempool, it is possible to detect new transactions as they are broadcast to the network. Full nodes maintain a copy of the mempool and can be used to query the node for updates on new transactions.

Parse new blocks: As new blocks are added to the blockchain, they contain new transaction data. By parsing the new blocks, it is possible to detect new transactions that have been confirmed and added to the blockchain.

The service provider computing system 104 may comprise a marketplace software component 134. This can, for example, offer users a marketplace forthe services, allowing them to select and activate specific services in relation to specific blockchain transaction requests. The services may be built by the entity that owns/operates the service provider computing system 104/external service system and/or by third parties via the marketplace in a similar manner to known app stores/marketplaces, such as Apple App Store™ or Google Play™. The computing system may comprise a billing software component 136. This can provide services in the form of billing-related functions that will be handled by the external service system, for example. The computing system may further comprise an operational data container 138 and/or at least one data warehouse container 140, 141 , which can store on-chain and operational data. The data warehouse(s) may comprise centralised storage and/or decentralised storage (e.g. using IPDF/Swarm).

As mentioned above, one or more of the services provided via the service provider computing system 104 may be built by third parties. Examples include smart contract/web3 developers 142. As well as the user 108, companies/institutions 144 can also use the services. These entities may subscribe to the external service system to use its tools/services. One or more external software system may also interface with the service provider computing system 104. Examples include third party systems 146, e.g. Internet of Things (loT), that can subscribe to receive system events and integrate with the services, as well as digital asset custodian(s) 148, which can provide storage and security services fordigital assets, such as cryptocurrencies, digital securities or others. Another example comprises notification systems 150, e.g. SMS, emails, etc. The skilled person will be able to implement notification system capability, e.g. using techniques described at the following link (the contents of which are hereby incorporated by reference): https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification _server/sending_notification_requests_to_apns The blockchain network 106 comprises a plurality of conventional interconnected nodes 152. The blockchain network will also contain at least one specific/special/preconfigured node 154 that, in addition to functioning as a conventional node of the blockchain network, is configured to cooperate with the service provider computing system 104 in ways such as those disclosed herein. Some embodiments may operate with more than one blockchain network 106. Each of these multiple blockchain networks may include one or more preconfigured node 154 that can cooperate with the computing system 104 (or another computer system that is in communication with it).

The blockchain network may further comprise an oracle 156, which may store smart contracts and/or off-blockchain data that can be used by the preconfigured node(s) 154. Example implementation details for a suitable oracle are available at the following link (the contents of which are hereby incorporated by reference): https://medium.com/iex-ec/how-to- build-a-decentralized-oracle-on-ethereum-a-step-by-step-guide-d8c14719b69f

In general, at least the preconfigured node 154 of the blockchain network(s) 106 will be in communication with the dApp 1 14, the wallet 110 and the digital asset custodian/centralized exchange software system 112, as well as the service provider computing system 104.

Figure 2 is a sequence diagram illustrating steps performed by an embodiment of the invention. It will be appreciated that at least one of the steps of any embodiment disclosed herein may be re-positioned/re-ordered with respect to other steps, or may be omitted. One or more additional steps may be performed in some cases. Some of steps shown as being performed in sequence may be performed concurrently in alternative embodiments. Further, a step shown as being performed by a particular entity/device in a detailed embodiment may be performed by a different entity/device in an alternative embodiment. For instance, one or more of the steps described as being performed by the service provider computing system 104 may be performed on the preconfigured node 154 (or vice versa) in a different embodiment. As another example, one or more of the steps described as being performed by the client application 118 may be performed by the dApp 114 (or vice versa). It will also be understood that embodiments can be implemented using any suitable software, programming language (e.g. C++, Python™, Go™, Rust™, Scala™ or Java™), data editors, etc, and may be represented/stored/processed using any suitable data structures and formats.

At step 2002 a distributed application, e.g. dApp 1 14, may be configured to cooperate with the external service system. This will be done, for example, when a user 108 registers with the external service system or when a developer creates or modifies a dApp 114 to cooperate with the external service system. The user can install the client application 118 on their device 102 and register it with the external service system. A developer of the dApp 114 can include a suitable Software Development Kit 116 for the external service system in the dApp.

During a user registration process of the client application 118 with the external service system, for example, the application can integrate with (request access to) the user’s crypto wallet(s) 110 so that it can retrieve information such as the user’s sender address(s) on the blockchain 106 and point the user’s wallet(s), e.g. by network configuration, to send all transaction requests from the wallet to the preconfigured node 154 that has been configured to cooperate with the external service system implemented by the service provider computing system 104. The skilled person will appreciate that this can be achieved in various ways. For example, the user may be using the known Metamask software, which allows users to access their Ethereum™ wallet through a browser extension or mobile app that can then be used to interact with dApps. To obtain the user’s sender's account address from Metamask using an API, it is possible to use the Web3.js library which provides a way to interact with the Ethereum™ blockchain and Metamask. Below is an example code snippet in JavaScript™ that demonstrates how to get the current selected account address in Metamask: javascript

Copy code

//Import the Web3 library const Web3 = require('web3);

// Create a new Web3 instance with Metamask as the provider const web3 = new Web3(window.ethereum);

//Request access to the user's Metamask account window, ethereum. enable();

// Get the current selected account address in Metamask web3.eth.getAccounts().then((accounts) => { const selectedAddress = accountsjO]; console. Iog(selected Address); // Log the selected account address

});

This example code assumes that the user 108 has already connected Metamask to their browser and has granted access to the dApp 114. Additionally, this code snippet is merely exemplary and can be adapted for alternative specific applications. The client application 118 may send information such as the user’s sender address(s) to the computing system 104, where it can be stored and used, for example, to identify/confirm incoming transaction requests on the preconfigured node 154.

The dApp 1 14 can be made to use a specific blockchain node, such as the preconfigured node 154, by means of the following example steps. First, the blockchain network and specific node that is to be used are identified. This may depend on factors such as network speed, cost of transactions, and security. The dApp can be configured to connect to the specific node using its node address or API endpoint. This can typically be done using a web3.js library or a similar technology. During development the dApp can be tested to ensure that it is connecting to the correct node and interacting with the blockchain as intended. The dApp can be deployed to a server or hosting platform that has access to the specific node. This may require additional configuration or setup, such as setting up a local node or using a cloud-based provider. The dApp and its interactions with the blockchain may be monitored by a developer to ensure that it is functioning as expected. Different blockchain networks and nodes may have different APIs and interfaces and the skilled person can use relevant documentation or community resources for a specific network or node in order to configure a dApp in an appropriate manner.

The user 108 (or a developer) can also configure the dApp 114 to send transaction requests to the preconfigured node 154 (the dApp contract address/function call may also be sent to the computing system 104) and be given an opportunity to set up features, such as Multi Factor Authentication (MFA) so the client application and any dApps can be protected from security breaches.

In general, the dApp 1 14 can use the user’s wallet 110 to communicate with a node of the blockchain 106 by the following steps. First, the dApp can request access to the user's crypto wallet, usually through a web3.js library or a similar technology. Then, the user can grant permission forthe dApp to access theirwallet and sign transaction requests. Next, the dApp can construct a transaction request and sign it using the user's private key stored in the wallet. The signed transaction request can then be broadcast to the blockchain network, where it is validated and added to the blockchain ledger. The blockchain node can receive the transaction request and update its state accordingly. Overall, the crypto wallet acts as a bridge between the dApp and the blockchain network. It allows the dApp to interact with the blockchain by providing access to the user's private key, which is needed to sign and broadcast transaction requests. The blockchain node can then receive and process these transaction requests, updating the state of the network accordingly.

The user 108 may be able to use the client application 118 to set several preferences, including, for example, which of a plurality of dApps 1 14 are to be monitored and/or to which services (or “marketplace transactions”) 120 - 136 they want to be performed in connection with a transaction request or subscribe to (e.g. checking for compliance, security vulnerability score, etc); define multi-signature rules that should be followed, or workflows/rules that should be applied before a transaction request is approved using the preconfigured node 154. The client application 118 can provide the user with information on the system 104 (e.g. status/health of the nodes that operate with the system), notifications, visualisations (e.g. graphs of smart contracts, history of transactions, etc.), multi-signature actions that need to be taken, gas fees that will be charged by the system, configure the types of checks to perform (control costs) and also control (specifically from pause to unpausing/rejecting) of the transaction requests that pass through the specific node 154. Once the client application 118 has been set up and the external service system 104 has been activated (in a similar manner to an antivirus program, for example), any dApps 114 that the user uses can have theirtransaction requests directed through the preconfigured node 154 and managed by the node and the system 104 in a real-time manner.

At step 2004 the user 108 interacts with the dApp 1 14 to initiate a transaction request, which, which may be a smart contract or non-smart contract transaction request. This can generate a transaction object/submission. A simple example of a transaction is “Make payment of 10 ETH to <user account>”. Other examples of blockchain transaction requests that can be generated using dApps are given below:

Decentralized Finance (DeFi) T ransactions: DeFi dApps enable users to perform financial transactions such as trading, lending, borrowing, and more on the blockchain. For example, a user may use a dApp like Uniswap to exchange Ethereum™ for a different cryptocurrency. The transaction would involve sending Ether to the dApp's smart contract and receiving the other cryptocurrency in return.

Non-Fungible Token (NFT) Transactions: NFT dApps allow users to buy, sell, and trade unique digital assets such as artwork, collectibles, and more. For example, a user could use a dApp like OpenSea to purchase a unique piece of digital art. The transaction can involve sending cryptocurrency to the smart contract representing the NFT, and receiving ownership of the NFT in return.

Decentralized Social Media Transactions: Decentralized social media dApps allow users to interact with each other in a peer-to-peer manner. For example, a user may use a dApp like Peepeth to post a message on the blockchain. The transaction may involve sending a small amount of cryptocurrency to the Peepeth smart contract to cover gas fees.

At step 2006 the dApp 114 communicates with the user’s wallet 110 to request signing of the transaction request. At step 2007 the wallet can operate to determine whether the transaction request is approved or rejected in a known manner. When a user signs a blockchain transaction using a crypto wallet, the wallet typically performs several validation checks to ensure the transaction is legitimate and secure. Examples of the validation checks that a wallet may perform include: Address Validation: The wallet checks that the sending and receiving addresses in the transaction request are valid and comply with the expected format for that particular blockchain network.

Balance Validation: The wallet checks that the user has sufficient funds in their account to cover the requested transaction's cost and any associated fees.

Fee Validation: The wallet checks that the user has set an appropriate transaction fee, based on the current network congestion and transaction priority.

Nonce Validation: The wallet checks that the transaction request nonce is correct, which helps prevent double-spending and other security issues.

Gas Limit Validation: The wallet checks that the user has set an appropriate gas limit for the transaction, which determines the maximum amount of gas that can be used to execute the transaction.

Signature Validation: The wallet checks that the transaction request is being signed with a valid private key and that the signature is correctly formatted.

These checks help ensure that the transaction request is valid and secure before it is signed and propagated to the blockchain network 106. If any of the validation checks fail then the wallet 110 will typically generate an error message indicating the reason for the failure. At step 2008 the wallet transmits a transaction approved/rejected message to the dApp 114. This can result in an appropriate message being displayed by the dApp to the user and gives the user an opportunity to decide whether the transaction request should still be submitted/approved. If it is accepted then, at step 2010 the user provides input to the wallet indicating approval and then, at step 2012, the wallet uses the user’s private key to sign the transaction request. At step 2014 the wallet sends the signed transaction request to the dApp.

At step 2016 the dApp 114 may add metadata to the signed transaction request. The metadata may comprise, for example, information regarding the service(s) that is to be performed in relation to the transaction request, an identifier/address of the preconfigured node 154 as a further safeguard, etc. Once a transaction request is signed and submitted to the blockchain network 106, the dApp can also still add metadata to the transaction by including it in the transaction's data field. Below are further examples of metadata that the dApp can add to a blockchain transaction/request:

Function Calls: A dApp can include function calls as part of a transaction's data field. This can be used to perform specific actions on the smart contract or invoke other dApps.

Comments or Messages: A dApp can add comments or messages to a transaction's data field. This can be useful for providing additional information or context for a particular transaction.

IPFS Hashes: A dApp can include IPFS (Interplanetary File System) hashes as part of a transaction's data field. This can be used to store larger amounts of data off-chain, while still referencing it in the blockchain transaction. Metadata for NFTs: In the case of NFTs, a dApp can add metadata such as the title, description, and image URL of the NFT as part of a transaction's data field.

Custom Data: A dApp can include any custom data as part of a transaction's data field. This can be used for various purposes, such as tracking the status of a particular transaction or adding extra information to a transaction. In some embodiments the metadata can include information related to one or more services that is to performed by the computing system 104 in relation to the transaction request.

At step 2020 the dApp 114 transmits the signed transaction request (along with any added metadata) to the preconfigured node 154.

If the user 108 does not approve the transaction request after receiving the message sent at step 2007 then at step 2022 they provide input to the wallet 110 indicating rejection of the transaction. Then, at step 2023 the wallet generates a transaction not signed error and at step 2024 sends a transaction not signed error message to the dApp 114. At step 2025 the dApp sends a message to the user confirming the reject transaction error and the transaction request is not transmitted or executed.

After step 2020 the signed transaction request is received by the preconfigured node 154 and at step 2026 the node verifies the validity of the transaction request in the conventional manner specified by the blockchain 106 to ensure that it is well-formed and that it meets the requirements for execution. If the verification fails then at step 2028 the node transmits a message to the dApp 114 indicating that this is the case. The dApp can then take appropriate action, e.g. send a message to the user 108 at step 2029 informing that the transaction request will not be executed. The message may contain information regarding why the verification failed.

If the verification does not fail then at step 2030 (normal) processing of the blockchain transaction request is effectively paused/interrupted. That is, the normal next step(s), e.g. propagating the transaction request to other nodes of the blockchain 106, that an unmodified/conventional blockchain node would perform at this stage is/are not taken, at least not immediately following the verification. Instead, the node 154 arranges for at least one service (i.e. an additional service that is not part of the normal blockchain transaction request execution process) relating to the transaction request to be performed, either indirectly by instructing the computing system 104 to perform the service, or directly by means of code being executed by a processor in the node 154 itself. To enable the preconfigured node 154 to interrupt/pause/un- pause the transaction request and make an API call to the off-chain computing system 104, if needed, the code executed by the node is written/modified so that after the transaction request verification step is completed, normal transaction request execution is not performed/paused until it is intentionally un-paused/restarted (the code/steps executed by the node 154 is otherwise substantially identical to that executed by a conventional node of the blockchain 106). Conventionally, when a client sends a transaction request, it sends it to a single node on the blockchain network. The node that receives the transaction request will then validate it and broadcast it to other nodes on the blockchain. This process is known as transaction propagation and helps ensure that all nodes on the network have a consistent view of the state of the blockchain.

Conventionally, when a blockchain node receives a transaction request, it validates the transaction request to ensure that it is well-formed and that it meets the requirements for execution. If the transaction request is valid then the node will add it to its local transaction pool and broadcast it to other nodes on the blockchain. The other nodes on the blockchain will receive the transaction request and validate it in the same way. If the transaction request is valid, the nodes will add it to their local transaction pools and broadcast it to their own set of peers. This process continues until the transaction is included in a block through the mining process. Therefore, while the client only sends the transaction request to a single node, the transaction request is eventually broadcast to all nodes on the blockchain as part of the transaction propagation process. This ensures that all nodes have an up-to-date view of the state of the blockchain and can participate in the mining process to achieve consensus.

In some embodiments the transaction propagation process effectively allows the preconfigured node 154 to interrupt/pause execution of the transaction (and thus also delaying execution of any related smart contract), and then only after approval is given (e.g. from the user 108 that is using the client application 118, the dApp 1 14 that is using the SDK 116 and/or preconfigured settings in the computing system 104) does it allow the transaction to continue execution (be played/un-paused), or it may be terminated in real-time.

Alternative embodiments may be configured to operate in conjunction with ERC-4337 Account Abstraction (see https://eips.ethereum.org/EIPS/eip-4337). This is an account abstraction arrangement which avoids the need for consensus-layer protocol changes and uses a higher-layer pseudo-transaction object called a UserOperation (UO). Users send UserOperation objects into a separate mempool. In ERC-4337 a new eth_sendUserOperation (“Signed UO”) message is sent to a UO mempool instead of a conventional eth_sendSignedTransaction message being sent to the conventional Ethereum™ mempool. In embodiments the node 154 may be configured to effectively pause a transaction request (step 2030) after the “Signed UO” message has been sent and before the transaction request is included in the UO Mempool. Embodiments can then continue substantially as described herein (e.g. by making the API call to the computing system 104 at step 2032 as described below). The skilled person will be able to make any other changes required for the embodiments to operate with ERC-4337. Once execution of a transaction request is effectively paused by the preconfigured node 154, the node can make an API call including details of the transaction request to the computing system 104 at step 2032. At step 2034 the computing system checks to see if the sender’s account is registered with the external service system. During the user registration process, information such as the URL/sender wallet address of the user is provided, e.g. by the client application 118, to the service provider computing system 104 and this may be checked. This provides an additional security safeguard that the transaction request has been received from an expected source.

If the result of step 2034 indicates that the sender is not registered (which typically means that the transaction should be processed as normal by the blockchain without additional services performed using the computing system 104) then at step 2036 the computing system 104 sends a message to the node 154 indicating that this is the case. In response to this the node effectively “un-pauses” (allows continued) execution of the transaction request at step 2038. That is, the node will continue with the normal next step(s), e.g. propagating the transaction request to other nodes, that an unmodified/conventional blockchain node would perform in order to execute the transaction request.

If the result of step 2034 indicates that the sender is registered with the external service system then at step 2040 the computing system 104 checks whether the sender has sufficient funds to activate the relevant service(s) that they have configured to be performed in relation to the service request, e.g. by means of having access to their wallet 110 and/or another payment system, such as one operated by a bank, payment/credit card or Paypal™. This is an additional check related to funds required to perform the additional service in addition to the gas normally charged by the blockchain network for executing the transaction itself. The amount required to activate the service may be set by the entity that created/operates the relevant service and will typically be provided to and stored by the computing system when the service is deployed on the system. The funds can typically comprise gas fees in the native currency of the blockchain 106, e.g. ETH, and will be deducted from the account of the user 108 who initiated the transaction request. An extra gas fee can be charged to the user for each service(s) provided. Alternatively or additionally, some embodiments may receive payments (and/or provide refunds) based on bank/credit accounts/cards and/or tokens. The ability to charge an extra fee in the native currency of the blockchain for a service that is performed off-chain by the computing system 104 via the preconfigured node 154 is a feature that allows the operator(s) of the external service system to make revenue. This can also give the operator(s) the ability to decentralise its infrastructure. If it is determined at step 2040 that the funds are insufficient then at step 2042 the remote computer transmits a message to the node 154 that this is the case. In response, at step 2044, the node transmits a service rejection message to the dApp 1 14. The dApp can then take appropriate action. For example, an exception can be thrown and the service/transaction request is reverted with an appropriate error message to the user 108.

If it is determined at step 2040 that the funds are sufficient then at step 2046 the computing system 104 can activate/perform the relevant service(s) and obtain a result(s). This may involve passing result data from one service to another service in some cases and/or communicating with/instructing a remote computing system to perform one or more operation. For example, the service may comprise checking if a receiver account and/or a smart contract associated with the user’s transaction request has been flagged as one that should be terminated, e.g. due to a known security problem, in which case execution of the transaction request will be halted immediately, an exception will be thrown and the transaction request may be reverted to the user with an appropriate error message. Other examples of the services are described above with regards to components 120 -136. In some embodiments data may be passed to the computing system 104 via the secure oracle 156. In some alternative embodiments the at least one service may be performed by code executing by a processor in the computing device that functions as the preconfigured node 154 itself, rather than by the computing system 104, which can result in reduced communication between the node and the computing system. For instance, Edge Al computing may be provided within the preconfigured node (not in the EVM) where a pretrained model is utilised to perform security vulnerability checks. Although relatively costly, this can increase responsiveness/performance and may also provide a degree of resilience, e.g. if the computing system 104 is not available.

In parallel with (or after/before) step 2046, at step 2048 the computing system 104 transmits a message to the preconfigured node 154 that the relevant gas fees should be deducted. In response to this at step 2050 the node charges (we should include the ability to do refunds) the sender for the service(s) using the node’s own wallet or a service system wallet (wallet scheme). When the node charges the sender for the service(s) they use, the fees for each service may be received into different accounts (wallets) by the node so that it’s easier to manage what fee was taken and for which service. This can allow other people/entities to set up one or more preconfigured nodes and take revenue, whilst also allowing the operator(s) of the external service system to charge for the infrastructure/processing performed on the platform. In some embodiments the system may provide a refund facility, e.g. in the event of a service not being completed for technical reasons. Thus, in some cases all the money from the preconfigured nodes can be collected and the payments disseminated (typically less system operator costs) to the people/entities that run/operate the preconfigured nodes. This billing service can allow the keeping of all the details and either hold the funds and send them out on a periodic frequency or even immediately in real-time. As mentioned above, instead of (or in addition to) using gas, embodiments may process payments using bank/credit accounts/cards and/or tokens. At step 2052 the computing system 104 can transmit the results of the performed service(s), and typically also a breakdown of the cost(s), to the client application 118.

At step 2054 the client application 118 can provide a message to the user 108 indicating that the service(s) has/have been performed and asking the user whether they still want to reject or approve execution of the blockchain transaction request. Thus, the user may be given an opportunity to confirm that they still want the blockchain transaction of their request to be executed in view of the results(s) of the performed service(s). For instance, if a service provides a score related to a security assessment of the transaction then the user may decide that they are prepared to accept some level of security risk. If the user still accepts the transaction then at step 2056 they provide input to the client application indicating that the transaction request is still to be executed. In response to this at step 2058 the client application transmits a message indicating approval of the transaction to the computing system 104. In response at step 2060 the computing system sends a message to the preconfigured node 154 signalling that execution of the blockchain transaction request should be un-paused/continued. The node then un-pauses (ceases interruption of) the transaction request at step 2062. That is, the node will continue with the normal next step(s) that an unmodified blockchain node would perform in order to execute the transaction request. Therefore, at step 2064 the node 154 propagates the transaction request to other nodes in the blockchain a conventional manner. At step 2065 the node 154 can activate the EVM and execute the smart contract(s) of the transaction request, if applicable.

At step 2066 the preconfigured node 154 may transmit a message relating to the status of the transaction/request to the computing system 104. The message may indicate that the transaction request has been propagated to other nodes, for example. In response at step 2068 the computing system 104 may initiate any specified subsequent service(s)/action(s), workflows and/or alerts. For example, the computing system may monitor the blockchain network 106 to confirm when the transaction based on the transaction request has been completed and after completion it may store data, e.g. time/date, in its own data store regarding the completed transaction. This can serve as an additional safeguard, e.g. that a particular (e.g. vulnerability/compliance check) was performed in relation to the transaction request and that the resulting transaction was also successfully completed/mined. Other examples of services that may be performed at this stage include providing instructions for another user to perform a certain task, e.g. send an electronic or hard copy of proof of completion of the transaction to another entity.

As mentioned above, after the step 2054 the user 108 may be given an opportunity to confirm that they still want the blockchain transaction request to be executed. If the user does not want the transaction request to be executed then at step 2070 the user provides input to the client application 118 indicating that the transaction request is not to be executed. In response to this at step 2072 the client application transmits a message indicating rejection of the transaction request by the user to the node 154. In response to that at step 2074 the node may send a message to the dApp 118 that the transaction request is rejected. The dApp can then take appropriate action, e.g. display a message to the user confirming that the transaction request will not be executed, etc.

Figure 3 is a sequence diagram for another embodiment where a user initiates a blockchain transaction request using the client application 118 (as opposed to the dApp 114 in the use case of Figure 2). In orderto minimize repetition, steps/entities/devices that have similar reference numerals/labels to Figure 2 can be considered to be substantially identical.

At step 3002, the user wallet 110 may be configured to cooperate with the external service system. This will typically be done when the user 108 registers with the external service system. The user can install the client application 118 on their device 102 and may use it to register the wallet with the external service system.

At step 3004 the user 108 interacts with the client application 1 18 to initiate a blockchain transaction request. At step 3006 the client application 118 communicates with the user’s wallet 110 to request signing of the transaction request. At step 3007 the wallet can operate to determine whether the transaction request is approved or rejected in a known manner. If any of the validation checks fail then the wallet will typically generate an error message indicating the reason for the failure. At step 3008 the wallet may provide a transaction request approved/rejected message to the user 108. This can give the user an opportunity to decide whether the transaction request and/or the associated service(s) should still be submitted/approved. If it is accepted then, at step 3010 the user provides input to the wallet indicating approval and then, at step 3012, the wallet uses the user’s private key to sign the transaction request. At step 3014 the wallet sends the signed transaction request to the client application.

At step 3016 the client application 1 18 may add metadata to the signed transaction request. In some embodiments the metadata can include information related to one or more of the services that is to be performed by the computing system 104 in relation to the transaction request. At step 3020 the client application can transmit the signed transaction request (along with any added metadata) to the preconfigured node 154.

If the user 108 does not approve the transaction request after receiving the message sent at step 3008 then at step 3022 they provide input to the wallet indicating rejection of the transaction request. Then, at step 3023 the wallet generates a transaction not signed error and at step 2024 sends a transaction not signed error message to the client application 118. At step 3025 the client application provides a message to the user confirming the reject transaction error.

After step 3020 the signed transaction request is received by the preconfigured node 154 and processing may continue in a similar manner to that described with regards to steps 2026 onwards of Figure 2 (but involving the client application 118 instead of the dApp 114 at some points as shown in Figure 3).

Figure 4 is a sequence diagram for another embodiment where a user initiates a blockchain transaction request using the user wallet 110 (as opposed to the dApp 114 in the use case of Figure 2). In order to minimize repetition, steps/entities/devices that have similar reference numerals/labels to Figure 2 can be considered to be substantially identical.

At step 4002, the user wallet 110 may be configured to cooperate with the external service system. For example, the user may manually configure settings of the wallet (e.g. via software such as Metamask) so that it sends transaction requests to the preconfigured node 154. This may be done at the same time as when the user 108 registers with the external service system. The user may also install the client application 118 on their device 102.

At step 4004 the user 108 interacts with the wallet 110 to initiate a blockchain transaction request. At step 4007 the wallet can operate to determine whether the transaction request is approved or rejected in a known manner. If any of the validation checks fail then the wallet will typically generate an error message indicating the reason for the failure. At step 4008 the wallet may provide a transaction approved/rejected message to the user. This can give the user an opportunity to decide whether the transaction request should still be submitted/approved. If it is accepted then, at step 4010 the user provides input to the wallet indicating approval and then, at step 4012, the wallet uses the user’s private key to sign the transaction request. At step 4020 the wallet sends the signed transaction request to the preconfigured node 154.

If the user 108 does not approve the transaction request after receiving the message sent at step 4008 then at step 4022 they provide input to the wallet 110 indicating rejection of the transaction request. Then, at step 4023 the wallet generates a transaction not signed error and at step 4025 provides a message to the user confirming the reject transaction error.

After step 4020 the signed transaction request is received by the preconfigured node 154 and the process may continue in a similar manner to that described with regards to steps 2026 onwards of Figure 2 (but involving the wallet 110 rather than the dApp 144 at some points as shown in Figure 4).

In alternative embodiments, instead of the user 108 initiating the transaction request by interacting with the wallet 110, the user may do so by interacting with the custodian 148 instead. The custodian generally holds private keys for the user and can take care of signing the transaction request. If the transaction request is successfully signed then the custodian may transmit the signed transaction request to the preconfigured node 154 in a similar mannerto that done by the wallet at step 2020 and processing can continue as described herein.

Figure 5 is a sequence diagram for another embodiment where a service selected by a user to be performed in connection with a blockchain transaction request involves obtaining multiple digital signatures. In orderto minimize repetition, steps/entities/devices that have similar reference numerals/labels to Figure 2 can be considered to be substantially identical.

As described above, at step 2058 the client application 118 transmits a message indicating user approval of the (paused) blockchain transaction request to the service provider computing system 104. In this case the transaction request is one that has been configured, e.g. by the user 108 via the client application 118 or the dApp 114, as needing to be digitally signed by one or more additional party in order to be executed. For example, the dApp may offer this as an option for each transaction request before it is sent to the wallet 1 10, or it may allow a user to designate that certain types of transactions (e.g. ones that transfer over a certain threshold of ETH, ones involving particular recipient(s), etc) will automatically require multiple signatures.

At step 5050 the computing system 104 detects that the transaction request requires multiple signatures. For instance, the message sent at step 2058 may include a multi-signature flag and/or data such as information identifying the entityZperson(s) who is/are to sign, which can include account/contact details, etc. At step 5052 the computing system initiates a multisignature service that is to be performed in relation the transaction by transmitting a message to its workflow/multi-signature engine software component 124.

At step 5054 a multi-signature engine of the software component 124 is activated. At step 5056 the engine sends a message to person 508 who is identified in the message as one who needs to provide a signature in order for the transaction request to be executed. Typically, person 508 will be registered with the external service system and have a client application 118 (and/or dApp 114) installed on their own device, with the client application or dApp 114 being configured to process these messages. At step 5058 the person 308 signals acceptance of the transaction by sending an appropriate message back to the engine, thereby effectively providing their signature. For example, the client application or dApp may require the person to enter a password, provide biometric information and/or obtain a private key from a wallet, etc, in order to transmit the approval message.

If one or more external system entity in addition to the person 508 needs to provide a signature then the relevant steps may be performed in relation to each of these. For example, at step 5060 the engine sends a message to an external system 510 that is identified as needing to provide a signature. The external system entity is a system with which the external service system can integrate using an API. For example, Airtable™ is a modern database and workflow automation platform that offers APIs to integrate with various applications, including Slack™, Trello™ and Salesforce™. The external system entity will also be registered with the external service system and includes code that allows it to interact with it in the manner disclosed herein. At step 5062 the external system entity signals acceptance of the transaction request by sending an appropriate message back to the engine, thereby effectively providing the signature.

Following the step 5062, e.g. after receiving confirmation that all applicable signatures have been provided, processing continues at step 2060 where the computing system 104 sends a message to the preconfigured node 154 signalling that execution of the blockchain transaction request should be un-paused/ continues. Thus, processing may continue in a similar manner to that described with regards to steps 2060 onwards of Figure 2.

Figure 6 is a sequence diagram for yet another embodiment where a service selected by a user to be performed in connection with a blockchain transaction request involves applying one or more rules in relation to the transaction request. Again, in order to minimize repetition, steps/entities/devices that have similar reference numerals/labels to Figure 2 can be considered to be substantially identical.

As described above, at step 2058 the client application 118 transmits a message indicating user approval of the (paused) blockchain transaction request to the service provider computing system 104. In this case the transaction is one that has been configured, e.g. by the user 108 via the client application 118 or the dApp 114, as one that has at least one associated workflow rule. The workflow rule may be based on If/Then conditions, a decision table or the like, and can use data in the transaction request as an input variable. For example, if the request relates to a certain type of financial transaction then a rule may specify that a hardcopy relating to completion of the transaction should be stored or provided to a particular party or execution of a further software step may be triggered. An example of a workflow engine that can be used to provide rules in embodiments is disclosed at https://camunda.com/platform-7/workflow- engine/ In some embodiments the dApp may offer applying one or more rules as an option for each transaction request before it is sent, or it may allow a user to designate that certain types of transaction requests will automatically require at least one specific workflow rule to be performed before the transaction request is executed.

At step 6050 the computing system 104 detects that the transaction request is one having at least one associated workflow rule. For instance, the message sent at step 2058 may include a workflow rule flag and/ordata such as information identifying or defining the rule(s) that need(s) to be applied, etc. At step 6052 the computing system activates a workflow service that is to be performed in relation the transaction by transmitting a message to its workflow/multi-signature engine software component 124.

At step 6054 a workflow rule engine of the software component 124 is activated. At step 6056 the engine sends a message to at least one external system entity 610 identified in the message as one that applies a rule that needs to be met in order for the transaction request to be executed. The rules engine can be built by a third party that provides features similar to those offered by https://camunda.com/platform-7/workflow-engine/ At step 6058 the external system entity transmits a workflow response back to the engine that signals whether or not the rule has been met in relation to the transaction. For example, a user of the system 610 may provide input confirming that a hardcopy relating to the transaction has been printed and stored.

If one or more person or entity in addition to the external system entity 610 needs to apply a rule in relation to the transaction then the relevant steps may be performed in relation to that entity. For example, at step 6060 the engine sends a message to the dApp 1 14. At step 6062 the dApp 1 14 transmits a workflow response back the engine that signals whether or not the rule has been met in relation to the transaction.

After receiving confirmation that all applicable rules have been followed, control passes to step 2060 where the computing system 104 sends a message to the preconfigured node 154 signalling that execution of the blockchain transaction request should be un-paused/continued. Thus, processing may continue as described with regards to steps 2060 onwards of Figure 2, for example.

It will be understood that the embodiments of Figures 5 and 6 can be modified, e.g. to operate after the transaction request has been initiated using the client application 118 or the wallet 110 as shown in Figures 3 and 4, respectively, instead of by the dApp 114.

In some cases before a transaction request is signed and transmitted by a dApp 114 or a wallet 110, embodiments may communicate (e.g. before step 2006/3006) with the preconfigured node 154 to obtain an estimated cost of the service(s) that is to be performed in connection with the transaction being requested. The obtained estimated cost may be displayed to the user, e.g. via the dApp, wallet or client application 118, and the user may be given an opportunity to approve or cancel the transaction request in view of the estimate. If they approve it then embodiments can continue signing and transmitting the transaction request as disclosed herein (e.g. continue from step 2007/3007).

In more detail, as there may be a fee (which may fluctuate due to network congestion, etc) associated with performing the service on the blockchain embodiments can estimate the fee at that time plus add any additional cost that the remote computing system(s) 104 is/are to charge for the service (aggregated cost). The preconfigured node 154 may do this by referring to prestored data containing service charges and/or by requesting service charge data from the relevant remote computing/external service system(s). Additionally, the preconfigured node may obtain an estimate of the number of units of gas, for example, that will be required to perform the service. In some cases it may do this by using a block explorer, such as etherscan.io, to navigate to the contract(s) to be invoked and examine transactions made with the contract(s) to compute the estimated gas cost. In embodiments that use an Ethereum™ blockchain, gas fees can have two components in accordance with EIP-1559: a base fee and a tip/priority fee. The fee a user making a transaction request will pay can calculated as: ((base fee + priority fee) x units of gas used). As previously mentioned, an extra gas fee may also be charged to the user for each service(s) provided, which can be determined by the service provider entity that offers the external service system and/or the third party entity that offers the additional service(s). The preconfigured node may calculate the estimate using this information.

In some cases, if a requested service(s) fails then embodiments may refund the user for any unspent gas. In some cases this may be done by the preconfigured node 154 interacting with the dApp 144, the wallet 110 and/or the client application 118 to not charge the relevant service charge(s) to the user and/or not charge any gas included in the estimate that was not actually used. For example, if the requested service involved three smart contracts and the first one failed then the user may not be charged for the gas that was estimated to be charged for executing the second and third smart contracts and, optionally, may not charge some or all of the extra gas fee that was to be charged to the user for the service(s) requested. Refund information may be presented to the user.

In some embodiments one or more of the services provided by a remote computing system 104 (or the service provider entity that offers the external service system) may be monitored by, for example, the preconfigured node 154 for Quality of Service (QoS), Service Level Agreement (SLA) and/or other metrics. This can be done so that a process being executed by the preconfigured node may make decisions about whether it should execute the remote service using that particular computing system/external service system, or switch to another that is considered better in some regard. For example, a plurality of the remote computing systems may be able to provide a specific type of service that can be performed in connection with a blockchain transaction request. The preconfigured node 154, for example, may store/access data regarding the type of service offered by each remote computing device/external service system, as well as associated performance factor information. The performance factors can include one or more factors, such as processing speed, availability, etc, of the computing system for providing the service, as well as the associated cost/charge. This performance information may be created/updated at an appropriate juncture, e.g. periodically, when a service is introduced/changed, orthe factors such as cost may be set dynamically by an operator entity of the external service system. A process executed by the preconfigured node may access the performance information and use it to select one of the plurality of remote computing systems to provide the type of requested service in relation to the blockchain transaction request. For example, it may compare the speeds, etc, and choose the computing system that will perform the service at the fastest speed, etc. Thus, embodiments can provide a dynamic system to help the preconfigured node provide the best quality of service and/or higher availability.

Alternative embodiments may operate in a “multi-blockchain” manner where at least one further node 154 is deployed across/on at least one further (different) blockchain network(s) 106. In this case the computing system 104 is able to provide the ability to synchronize transactions requests and instigate services based on blockchain transactions on multiple blockchains to achieve a common outcome. The nodes may operate in real-time across/on multiple chains and so can also mean that the data that is able to be monitored (on-chain monitoring) and processed is not just historical transaction data that has already been mined, but may be true real-time data. The nodes can enable the monitoring of all new incoming transactions, their processing through the computing system 104, and their status in the mempool and when they are finally confirmed/mined. Thus, the nodes may receive the initial transactions, make API calls to the computing system 104 and finally put the transactions in the mempool for mining.

For example, such embodiments may comprise the remote computing system 104 communicating with a specific preconfigured node on another blockchain in order to perform at least one further service. The communication may comprise providing a further transaction request to that further preconfigured node. The further preconfigured node may instruct a further remote computing system to perform a service, e.g. a service related to the further transaction request, which may be similar to any of the additional services described herein. This communication may take place after the at least one service in relation to the (initial) blockchain transaction request has been completed, for example. In a blockchain network, the mempool (short for "memory pool") is a component of a node that temporarily stores pending transactions that have not yet been confirmed by the network. When a user creates a transaction request and broadcasts it to the network, it is first received by nodes in the network, including the mempool of each node. The mempool stores these pending transactions in a data structure, which is typically a first-in, first-out (FIFO) queue. Transactions are added to the mempool when they are received and removed when they are confirmed by a miner and included in a block. Nodes in the network have their own mempools, which may differ slightly in terms of the transactions they contain. This may be due to differences in network connectivity, as well as differences in the transaction fees attached to each transaction. Miners typically prioritize transactions in their mempool based on the fees attached to each transaction. Higher fee transactions are generally given priority over lower fee transactions. This means that if there is a backlog of transactions in the mempool, transactions with higher fees are more likely to be included in the next block. Transactions that are not confirmed within a certain time period are typically removed from the mempool and must be rebroadcast to the network if the user wants them to be included in a future block. In summary, the mempool on a blockchain node temporarily stores pending transactions that have not yet been confirmed by the network, and transactions are prioritized based on the fees attached to them.

Attention is directed to any papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive.

Each feature disclosed in this specification (including any accompanying claims, abstract and drawings) may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example only of a generic series of equivalent or similar features.

The invention is not restricted to the details of the foregoing embodiment(s). The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed.

Claims

1 . A computer-implemented method of processing a blockchain transaction request, the method comprising: receiving (2014; 3014; 4012) a blockchain transaction request; directing (2020; 3020; 4020) the blockchain transaction request to a specific node of a blockchain, and at the specific node, interrupting (2030) execution of the blockchain transaction request, and directly or indirectly performing (2046) at least one service in relation to the blockchain transaction request.

2. A method according to claim 1 , wherein the specific node is configured to communicate with a remote computing system, and wherein the specific node is configured to, after interrupting the executing of the blockchain transaction request, indirectly perform the at least one service by instructing (2046) the remote computing system to perform the at least one service in relation to the blockchain transaction request.

3. A method according to claim 1 , wherein the specific node is configured to, after interrupting the executing of the blockchain transaction request, directly perform the at least one service using instructions executed on a processor in the specific node.

4. A method according to claim 1 , wherein the specific node interrupts the executing of the blockchain transaction request after verification (2026) of the blockchain transaction request by the specific node and before propagation (2064) of the blockchain transaction request to other nodes of the blockchain.

5. A method according to claim 1 , wherein the at least one service comprises: performing at least one check (2034, 2040, 2054) relating to the blockchain transaction request, and the method further comprises: continuing (2062) the executing of the blockchain transaction request on the blockchain if a result or results of the at least one check is positive, or not continuing the executing of the blockchain transaction request on the blockchain if the result or results of the at least one check is negative.

6. A method according to claim 5, wherein the at least one check comprises detecting whether the blockchain transaction request involves a blacklisted account/address.

7. A method according to claim 5, wherein the at least one check comprises detecting whether the blockchain transaction request involves a smart contract that includes code known to have security issues by comparing at least part of the code with existing code stored in a data store.

8. A method according to claim 1 , wherein the at least one service comprises obtaining at least one digital signature from an entity other than a user who initiated the blockchain transaction request.

9. A method according to claim 1 , wherein the at least one service comprises applying at least one rule of a workflow to the blockchain transaction request.

10. A method according to claim 1 , further comprising: transmitting (2052) a result of the at least one service to a user who initiated the blockchain transaction request, and then requesting (2054, 2056) confirmation from the user whether the execution of the blockchain transaction request should continue.

11. A method according to claim 1 , further comprising: determining (2040) whether a user/user account who initiated the blockchain transaction request has at least a specified amount of currency required to perform the at least one service.

12. A method according to claim 1 , further comprising: registering a user associated with an account on the blockchain as a registered user of a service system, and configuring a wallet and/or a digital asset custodian associated with the registered user to direct all blockchain transaction requests to an address of the specific node.

13. A method according to claim 12, wherein a distributed application is configured to set the wallet and/or the digital asset custodian to direct the blockchain transaction requests to the address of the specific node.

14. A method according to claim 13, further comprising installing a client application on a device associated with the registered user, wherein the client application is configured to set the distributed application, the wallet and/or the digital asset custodian to direct the blockchain transaction requests to the address of the specific node.

15. A method according to claim 12, further comprising: determining (2034) whether a wallet and/or a sender/account from which the blockchain transaction request was transmitted is a registered user of the service system.

16. A method according to claim 2, further comprising the remote computing system communicating with a specific node on another blockchain in order to perform at least one further service.

17. A method according to claim 2, wherein the remote computing system is external to the blockchain, and wherein the remote computing system is not configured as a node of the blockchain.

18. A method according to claim 1 , further comprising: before the directing (2020; 3020; 4020) the blockchain transaction request to the specific node, obtaining an estimated cost of performing the at least one service in relation to the blockchain transaction request; presenting the estimated cost to a user; obtaining user input to cancel or continue the executing the transaction request in view of the estimated cost, and continuing the directing the blockchain transaction request to the specific node if the user input is continue.

19. A method according to claim 1 , wherein each of a plurality of remote computing systems is configured to provide a type of service in relation to the blockchain transaction request, and the method further comprises: obtaining performance information comprising at least one performance factor associated with each of the plurality of remote computing systems for performing the type of service, and selecting one of the plurality of remote computing systems to provide the type of service in relation to the blockchain transaction request based on the performance information.

20. A system configured to process blockchain transaction requests, the system comprising: a first computing device (102), and a further computing device configured to function as a specific node (154) of a blockchain (106), wherein the first computing device is configured to receive a blockchain transaction request and direct the blockchain transaction request to the specific node of the blockchain, and wherein the specific node is configured to interrupt execution of the blockchain transaction request and to directly or indirectly perform at least one service in relation to the blockchain transaction request.

21 . A system according to claim 20, further comprising a remote computing system (104), and wherein the further computing device is configured to communicate with the remote computing system.

22. A computing device configured to function as a specific node (154) of a blockchain, wherein the computing device is further configured to: interrupt execution of a received blockchain transaction request and directly or indirectly perform at least one service in relation to the blockchain transaction request.

23. A method of operating a computing device configured to function as a specific node of a blockchain, the method comprising: interrupting execution of a received blockchain transaction request, and performing at least one service in relation to the received blockchain transaction request.

24. A computing system (104) configured to: communicate with a specific node of a blockchain, and perform at least one service in relation to a blockchain transaction request based on an instruction received from the specific node.

25. A method of operating a computing system, the method comprising: receiving an instruction from a specific node of a blockchain, and performing at least one service in relation to a blockchain transaction request based on the instruction received from the specific node.

26. A computer readable medium storing a computer program to operate a method according to any of claims 1 , 23 or 25.