Smart Contract Invocation Protocol (SCIP)

Hello, I am Ghareeb Falazi from the institute of Architecture of Application Systems and in this video I would like to present to you the Smart Contract Invocation Protocol or SCIP. This is a protocol for the uniform integration of heterogeneous blockchain smart contracts. This work is a joint effort of the University of Stuttgart and Politecnico di Milano. Firstly, we dedicate this work to the memory of Dr. Florian Daniel who sadly passed away on the 27th of April 2020.

00:31 - He was an outstanding person who co-authored hundreds of academic publications, including this one. Florian was really looking forward to participating in CAiSE and meeting all of you. May his soul rest in peace. OK, so now let me introduce the agenda of this presentation. At the beginning, I will explain the main motivation behind SCIP. Afterwards, I will go into the protocol specification itself at an abstract level. Things get more concrete when introducing the JSON-RPC binding for SCIP as well as the SCIP gateways. Finally, I present a case-study which serves to prove the validity of the approach, and then I conclude. So: the main motivation for SCIP is multi-blockchain integration scenarios. These are scenarios in which a client application needs to interact with multiple blockchain systems at the same time. To show you why this could happen, let’s consider the following scenario from the domain of smart grids.

01:34 - In this scenario, the energy management system is operated by a privacy preserving permissioned blockchain, which governs the relationships between the various stakeholders of the system, such as power plants, electricity providers, and consumer households. And now, let’s focus on one specific electricity provider and see how it could interact with the system. Here, we show one simplified business process in which the electricity provider can be involved. It is based on the fact that in smart grids, certain power plants, like wind and solar power plants, frequently change the price of energy they sell to electricity providers because of their nature of their energy sources. The process starts with the electricity provider monitoring interesting price changes announced by power plants.

02:28 - Now, when an interesting price drop is detected, the electricity provider buys in-bulk from the corresponding power plant, say it buys a thousand megawatt hours from it. Afterwards, the electricity provider decreases the retail price of energy it is selling to consumer households so that it becomes a more desirable option to them. And from time to time, auditing authorities would like to perform audits on such processes. However, the problem here is that a permissioned blockchain like this one, does not guarantee the immutability of its records to external parties (like the auditing authority). The reason is that, if all participants of such a system agree, they can alter the recorded history the way they want, which is not acceptable in this case.

03:15 - Therefore, the electricity provider stores a digest of the previous operations in a public blockchain, such as Ethereum, which provides better immutability guarantees. The auditing authorities can then observe this digest and compare it with the data stored in the permissioned blockchain. This allows to ensure its authenticity. Now, all of a sudden, the the electricity provider needs to communicate with two blockchains at the same time. Specifically, it needs to monitor and invoke smart contracts within these systems. So what are smart contracts? Smart contracts are small applications hosted directly on blockchains, and they usually encode the business logic of collaborative interactions such as the ones we find in this scenario.

04:05 - And now the question is, what is the best way for the electricity provider to impelement this integration scenario? Is using the native APIs and protocols of individual blockchains a good option? In the following, we will see why this might not be the best approach. In this figure, we see how a typical invocation of a state-changing smart contract function can take place. First, an external consumer, such as our electricity provider, formulates a technology-specific request message, or a blockchain transaction, that specifies the designated smart contract function to be invoked as well as the data used as arguments for the invocation, and then sends it to one of the nodes of the blockchain system via its API. Then the node verifies the transaction, and broadcasts it to other nodes to be included in the next round of the consensus mechanism (which is usually referred to as mining). The result of mining is a new block that includes our transaction Tx.

05:07 - The block is added to the local blockchain of all nodes. Now, the execution of the new block reaches Tx, the corresponding smart contract function is run using the passed arguments, and the local state is changed. The problem with this, is that if the external consumer application wants to invoke a smart contract function of a different blockchain system, it will be faced with multi-level heterogeneity. Specifically, it will need to address API heterogeneity, message format heterogeneity, protocol heterogeneity, and even transactional semantics heterogeneity, which refers to the fact that certain blockchains do not guarantee the durability of committed transactions due to forking, whereas others do. To this end, we introduce the smart contract invocation protocol, or SCIP, which is a high-level protocol that hides the heterogeneity of blockchains by providing a set of uniform methods that allow external consumers to: First, invoke smart contract functions.

06:14 - Second, monitor smart contract events and function invocations, and third, query past occurrences of smart contract functions and events. Of course, SCIP is intended for blockchain-external consumers, such as client applications not blockchain-internal consumers, which are other smart contracts. Before we dive into the methods provided by this protocol, let’s have a general overview of how a client application can use it to interact with blockchain smart contracts: The client application now does communicate directly with the nodes of the underlying blockchain systems, but rather with a new entity called the SCIP gateway. The SCIP gateway implements SCIP methods. The client application sends SCIP request messages to the endpoint of the gateway, and receives SCIP responses, both synchronous and asynchronous. The gateway then communicates with the underlying blockchain nodes using blockchain-specific API calls.

07:14 - It is worth mentioning here that the client application addresses its SCIP requests to a Smart Contract Locator (or an SCL). An SCL is a URL with a predefined format. It allows us to identify the designated gateway, the type of the blockchain, the specific blockchain instance, as well as the address of the designated smart contract. So let’s start with the first SCIP method, or the invoke method. As its name suggests, this method allows to invoke smart contract functions both state-changing, and non-state-changing. In this figure we show how the more-complicated state-changing case proceeds: First, a client application creates a signed SCIP invocation request message, or a signed request message for short (SRM), and sends it to a SCIP gatewaty.

08:07 - The gateway then identifies the designated blockchain system, and formulates a suitable transaction out of the data provided in the SRM. The problem here is that blockchains expect transactions to be signed by their initiator, which is, in this case, the gateway. However, one can claim that the gateway made up the data items inside the transaction and did not base it on a client input. Therefore, the gateway takes the additional step of storing the pair constructed by the transaction and the SRM so that it can prove the originality of the transaction. When a blockchain node receives the transaction, it starts the mechanism that we saw earlier.

08:51 - This also includes sending back a unique transaction identifier of the submitted transaction to the gateway. The gateway, then, sends a synchronous response to the client application indicating that the request message reached the blockchain. At the same time, the gateway starts to repeatedly query the status of the submitted transaction, using its identifier, until a desired Degree-of-Confidence, or a timeout is reached. Degree-of-Confidence, or DoC, is a measurement, introduced in an earlier publication, which tells us how likely it is that a submitted blockchain transaction is durably committed. It increases over time, and is intended to hide the heterogeneity of transactional processing semantics of different blockchains.

09:34 - Assuming the desired value for the DoC is reached, a result is pulled by the gateway, and an asynchronous SCIP response message is formulated and sent back to the client application. Finally, we notice that the orange arrows correspond to SCIP interactions and operations, whereas, the green part on the right-side here shows some blockchain- specific interactions, which can differ from one system to another. However, notice how the client application is shielded from this heterogeneity through the uniform SCIP interactions. Now, let’s take a look at the meta-model of the messages that support the Invoke method. First, we see the Invocation request message, which has fields to uniquely identify the designated function, and pass arguments to it.

10:24 - We also have the Callback-URL field to let the gateway know where to send the response to, and the correlation identifier field, which is also present in the callback message so that the client application can correlate them together. Other fields were explained in the previous slide. The callback is an asynchronous response message that includes the invocation outputs if they exist. We now move to the next method, which is the Subscribe method. This method allows the live monitoring of smart contract events and function invocations. Smart contract events are events that are emitted during the execution of a smart contract function. The smart contract code specifies when an event is emitted and what data is announced with it. But this means that certain functions may not throw events at all. Therefore, besides monitoring events, the Subscribe method allows monitoring state-changing smart contract function invocations. In this case, it reports the values of the input parameters used in the invocation.

11:31 - Here, we see the Subscription request message and the Callback asynchronous response message. We know most of these fields from the previous method. A notable addition is the Filter filed, which is a Boolean expression based on the occurrence parameters, and it allows us to select interesting occurrences only. The next method is fairly simple. It allows a client application to unsubscribe from previous subscriptions. It has a set of fields, which can be used to unsubscribe from a set of subscriptions at once.

12:06 - The final SCIP method is the Query method. It is very similar to the Subscribe method, the difference is that it queries past occurrences of events and function invocations. Since the method can be served back immediately, the response message is synchronous in this case. The methods and messages we just described are at an abstract level. However, when we want to implement such a protocol, a so-called binding to a concrete technology is needed.

12:36 - SCIP does not prescribe a specific binding for its methods. Nonetheless, we propose to use JSON-RPC for this purpose. JSON-RPC is a stateless transport-agnostic RPC protocol that uses JSON as its serialization format, and it is widely used in blockchain APIs, such as Ethereum. Here, we see a Subscription SCIP message using the proposed JSON-RPC binding. The complete binding description is available at the link below. Next, we address the topic of SCIP gateways. As we saw before, SCIP gateways implement SCIP methods and provide an endpoint for clients. The way these gateways are deployed plays a major role in determining the properties and guarantees of the system as a whole. Here, we mention two of the possible deployment options: First, we have the case representing Blockchain-as-a-Service providers, in which a third-party service provider hosts one or more SCIP gateways in order to allow client applications belonging, perhaps, to multiple organization to access heterogeneous blockchain systems. In this case, the gateways might need to be replicated to tolerate certain failure classes.

13:51 - A different option is to have the gateway deployed on a trusted infrastructure, such as on premise. A major drawback of the second option is the configuration and maintenance burden on the enterprise. However, it achieves better trust and privacy guarantees since no intermediaries are involved. For more details, please refer to the paper. As a proof of concept, we implemented a prototypical SCIP gateway as depicted in this figure. The prototype exposes the methods of SCIP at the top. These methods are powered by a JSON-RPC server and a JSON-RPC client. Below it, we have the core layer containing high-level blockchain- independent functionality, such as callback and subscription management. And at the bottom we have the adapters layer, in which we have one adapter per supported blockchain. At the moment, we have adapters for both Ethereum and Hyperledger Fabric.

14:52 - Adapters implement blockchain-specific tasks such as invoking smart contract functions and calculating the degree of confidence. To prove the feasibility of the approach as a whole, we implemented the aforementioned electricity management system scenario using the prototypical SCIP gateway. The scenario, which is shown here at the top, is now implemented as follows: the business process is now a java client application, which acts as a SCIP client. This SCIP client uses JSON-RPC binding, and it accesses the underlying blockchains, using two instances of the SCIP gateway (another option would have been using just a single instance of the SCIP gateway with two adapters). Furthermore, we implemented the energy management system as a basic setup of the Hyperledger Fabric permissioned blockchain, and we simulated Ethereum using Ganache-CLI.

15:44 - Now, the four steps of the business process are turned into SCIP method invocations exactly as shown here. These invocations target the underlying smart contracts stored within the two blockchains. To summarize, in this work, we presented the smart contract invocation protocol or SCIP. SCIP is mainly motivated by multi-blockchain integration scenarios, and it provides a uniform set of methods to invoke, query, and monitor heterogeneous blockchain smart contracts. We also presented a JSON-RPC binding for SCIP.

16:22 - Furthermore, we presented the topic of SCIP gateways, and showed that they can be deployed in multiple ways with different trade-offs. Finally, we implemented a prototypical SCIP gateway, and proven the whole feasibility of the approach using a case-study. I hope you enjoyed this video, and thank you for your attention. .