Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Serverless architecture [6, 16] has been gaining popularity in the last three years. Function as a Service (FaaS) [10, 12] is a concrete realization of the Serverless architecture and has several advantages and features. This paper proposes a new service model which is based on FaaS model, named FBaaS – Functional Blockchain as a Service. Compared with conventional Blockchain as a Service (BaaS) [8, 9, 11, 13], FBaaS has a lighter implementation of top-level business logic, which brings a number of straightforward advantages. Firstly, it could improve the operating speed of a blockchain. Secondly, the advances in high robustness, high availability of the underlying FaaS network can be naturally adapted to the FBaaS because of its hierarchical architecture. Thirdly, FaaS implements higher level of abstraction of the logics that is much succinct [12]. This paper proposes an abstraction method in the realization of business logic of consortium blockchain that could further improve the overall performance. In this paper, we also unfold the details of a concrete example network, which is the conference blockchain network for Services Conference Federation (SCF) 2018 [14]. In the future, the proposed technologies could be partially applied to public chains, such as the [13].

This paper is organized as follows: Sect. 2 introduces the concept of serverless architecture. Section 3 briefly introduces the BaaS. Section 4 illustrates the proposed ideas of FBaaS. Section 5 concludes the paper and outlines some future research directions.

2 Serverless

DevOps (Development and Operations) and Serverless architecture have been gaining popularity in the last three years [6, 10, 12]. In particular, microservices architecture significantly boosts the development of DevOps. Microservices architecture helps to split a monolithic application into several smaller services, which are self-governed and can be easily developed and maintained by smaller development team. Serverless architecture [6, 12] produces a more granular division of services than microservices architecture that gives four-fold advantages to applications (Fig. 1):

Fig. 1.
figure 1

Monolithic application, microservice application and serverless application

Full size image

  • It reduces costs. Serverless produces smaller functional blocks than monolithic application and microservices, which reduces overhead in larger functional blocks in a way that serverless only requires on-demand resources and gets thereby allocated.

  • It accelerates the execution. Because of service is divided into smaller functions, only the needed functions are called at the run time. Those unnecessary functions can be fully stopped instead of standbying that indeed occupies resources.

  • It allows better resilience. Smaller blocks somewhat mean shorter start time that gives faster response to the callers. In addition, because less overhead exists, resource allocation can be much more flexible and efficient.

  • It enables event-driven applications. Serverless is actually an IPO (Input-Processing-Output) model, which suits the event-driven applications, for instance IoT (Internet of Things) applications. A functional block of serverless architecture is only triggered when it is really required. It would be destroyed immediately once the caller does not ask for its capability. In other words, the life cycle of the function is shorter than the ones of the monolithic and microservices architectures. As a result, event-driven application can leverage lighter framework, such as the serverless, for much more agile execution.

3 Blockchain as a Service

Block Chain as a Service (BaaS) [8, 9, 11, 13] offers the services for blockchain manipulations and building, shipping and running the business logics over blockchain networks. The well-known solutions include but not limited to IBM blockchain [8], Ethereum Blockchain over Azure [13], Microsoft Azure Blockchain [11] and R3 Corda [9]. Although many vendors provides different BaaS, the existing solutions are mainly using the traditional 3-layer cloud architecture: IaaS, PaaS and SaaS. This paper proposes the FBaaS that has significant difference when compared with the conventional BaaS offerings.

4 Functional Blockchain as a Service

This section proposes the FBaaS – Functional Blockchain as a Service in details, by unfolding its architecture, realization process, and a concrete example network. Figure 2 shows the detailed FBaaS architecture.

Fig. 2.
figure 2

The architecture of Functional Blockchain as a Service

Full size image

4.1 Architecture

The underlying architecture of FBaaS partially follows the ideas of CCOA [17], but without the ESB [15]. More concretely, the system is implemented in accordance with the Big Data Open Architecture (BDOA) [7]. The layers of BDOA that have been developed and deployed in the realization of FBaaS are:

  • Layer one: Infrastructure layer, realized FBaaS layers 1 and 2. The system is built onto AWS [1], without using any Amazon Lambda functions, but only the normal components such EC2 are used. In other words, we do not use the serverless framework nor the function as a service given by AWS.

  • Layer two: Components layer, realized as FBaaS layers 3. The basic functions are implemented inside this layer. For example, authentication functions and authorization functions are developed here to be frequently reused in the upper layer.

  • Layer three: Services layer, realized as FBaaS layers 4 and 5. This layer implements the majority of functions of BaaS. We will unfold the details later.

  • Layer four: Business logic layer, realized as APPs and Large-scale Services in Fig. 2. By grouping the functions of layer three, we are able to easily establish a blockchain and the complicated large-scale services.

4.2 Functions in the Services Layer

Function 1: Object Storage. Object storage is with strong atomic, which means the entire object storage process is either successful or failed and there is no intermediate/uncertain status during the storage process. At the same time, object uploaded is complete and no breakpoint point resuming uploading is allowed. The strong consistency of such an object storage scheme brings much convenience to the users. Users are no need to worry about the problems of eventual consistency existed in the distributed blockchain networks (Fig. 3).

Fig. 3.
figure 3

The workflow of object storage and encryption

Full size image

Function: New Transaction. This function adds the content of a transaction into a new block, which is then to be encrypted and mined. There is no limitation for the content of a transaction, however, for the sake of storage, it is good to have a limit. Moreover, it is better to make abstractions for the content that we will unfold the details in the remainder of this paper.

Function: Mine. Mining a block is actually a process of simple enumeration and hashing. To accelerate the mining process, one can apply CUDA [2] of NVidia GPUs. In the context of FaaS, it is somewhat difficult to directly apply. Instead of the traditional approach, we introduced the messaging system Kafka [3] for distributing the hashing requirement in an extremely speedy way. Normally, the performance reaches as high as 40x compared with the CPU hashing approach.

Function: Chain Info. Blockchain information can be fetched by this function. Typical data include the number of blocks and the length of the blockchain. It is important to emphasize that here the length represents the only certified chain among many chains that has not yet been mined.

Function: Resolve. Resolving function tries to resolve conflicts by running consistency algorithms, aiming to ensure that all of the nodes have the unique correct chain.

Function: Add Node. Adding a node is complicated with the conventional solutions. However, with the help of FaaS, we are able to easily add nodes to an existing network. First, we retain the current state into the persistent storage. Then, we replicate one node by Container as a Service (CaaS) replication functions. Afterward, the configuration of the new node is the established by adjusting the configuration files of the replica node. Finally, we restore the state from persistent storage and continue executing the network. The performance of adding the node depends on the size of the existing network. Network manipulation, such as replicating a node, does not take too much and is sometimes trivial. Most of the time is consumed in the sub procedure of storing and restoring the states of the system.

4.3 Realization

Function Server. The system is implemented in Python and Golang. Python is used for the top layer framework and those logics inside functions, which are then to be called frequently and simultaneously. The layers Function Server and Container as a Service are implemented in Golang. We developed system over the OpenFaaS [12]’s modulars API Gateway and Function Watchdog, shown as Fig. 4, where the RBAC (Role-Based Access Control) server is used for authentication and authorization of functions. Implementing the RBAC inside the layer Function Server increases the complexity of the system and decreases the performance since every function call procedure has to be checked. However, this scheme allows system administrators to limit the abnormal violate calls from inner systems. A typical scenario is the short message service. If the RBAC is only existed in the API gateway, once the function is hacked, the message delivery cannot be controlled. In contrast, RBAC implemented in the Function Server can stop only the user whose application server has those hacked functions, and will allow the functions with the same functionalities but different authorization to continue working.

Fig. 4.
figure 4

The inner components of Function Server

Full size image

Finer FaaS. A microservice provides less functionality than a monolithic system. In other ways, it provides the higher level of abstraction for the service they provide. Decomposing a microservice into several functions can be similar, where FaaS is commonly seen as the one with ultimate level abstraction. On top of FaaS, can we implement a new layer with finer granularity? The certain answer is to freeze some components of FaaS into constant. Formally, we can define the function \(\lambda \) as the abstraction of part of microservice \(\mu \):

$$\begin{aligned} \lambda = abs(\mu (\alpha , \delta )) \end{aligned}$$
(1)

\(\alpha \) denotes the variable part where \(\delta \) denotes the constant part. When we freeze the \(\delta \), the function becomes simpler and its abstraction degree can be further increased. In the realization process, we can introduce some pre-defined function to imitate these constant parts. In Fig. 5, FaaS is in gray and it is further decomposed by introducing the IFTTT [4] and Zapier [5]. This way of decomposing produces finer granularity and increases abstract degree of FaaS.

Fig. 5.
figure 5

The finer FaaS by introducing the IFTTT and Zapier

Full size image

Improving the Performance by Logic Abstraction. In the case of simple rules, if complex transactions are submitted to a node, and in the case of high concurrency, the speed of the consortium blockchain (such as Hyperledger Fabric) will be very poor, which will affect the transaction recording speed and block generation speed. If we reduce the transaction submission frequency by assigning complex rules, we can effectively increase the transaction speed to some extent. For example, we can change the time slot of generating the block and the size of the content of a block. Formally, we abstract the complex things (transactions) in the business system into simple logic through a logical abstraction method, thereby improving the system performance. Such an increase is essentially achieved by reducing the amount of recorded content, where the content is now logic abstraction of actual content. It is important to note that the real state space and abstract state space first satisfy Galois connected:

$$\begin{aligned} \begin{aligned} \eta (\theta (abs)) = abs\\ \theta (\eta (real)) \supset real \end{aligned} \end{aligned}$$
(2)

This means that if we extract an element from the abstract space, materialize it, and abstract the concrete version, the result is equal to the original. On the other hand, if you select an element from the real space and abstract out a specific abstract version, the final result is the original superset. The specific abstract process is shown in Fig. 6. The original logic, if not abstracted, runs according to the original logic (dashed line) flow. The solid line shows the new process. First of all, a formal review of the logic of the input ensures that the formality of the thing is correct, in line with the characteristics that a transaction should possess. Then, abstract rule matching is performed. The abstract rules mainly include the following types:

Fig. 6.
figure 6

The abstraction flow

Full size image

  • Only to record the last operation object of the thing;

  • Only to record the first object of operation;

  • Only to record odd-numbered (or even) atomic-level operation objects;

  • Record only Create and Delete operations;

  • Only to record the update operation of key data objects;

  • Only the fan-in data objects and/or paths affected by the exposed interfaces of the overall system service interface API is recorded;

  • Only the key data object changed in the service interface API are recorded, that is, changes are recorded by memorizing the state.

4.4 An Example Network

Figure 7 shows an example network for conference blockchain. The blockchain network consists of five nodes, each of which records the process from ‘Call For Paper’ (‘CFP’) to ‘Online’. Once a record of a stage, for instance a presentation of a paper in ‘Present’ process, is bookmarked, such the record will be published to all of the nodes. Throughout the network, all the records will arrive eventual consistency. We applied the proposed ideas to the network, benchmarked the network, and found the performance satisfies the requirement of a conference blockchain, where the original required TPS is often smaller than 10.

Fig. 7.
figure 7

An example network for conference blockchain

Full size image

FaaS architecture reduces the overheads and allows developers to focus on the business logic. For example in the conference blockchain, by using FaaS, we are able to concentrate on the 6 business logical stages, namely ‘CFP’, ‘review’, ‘accept’, ‘final copy’, ‘present’ and ‘online’, without taking care of the underlying complex components. Normally in the conventional BaaS solutions, the actual bottleneck always hides in the network transmission, and we had to consider the network itself. With leveraging the FBaas, the performance could be naturally improved with the advanced in the underlying FBaaS dependent components.

5 Conclusion

This paper proposed the first blockchain service model FBaaS over the serverless architecture. We also proposed abstraction method for reducing the complexity of developing business logic over blockchain networks and improving its performance. Not only the consortium blockchain that the proposed FBaas could apply to, but also the partially the public blockchain could. The issue raised when applied to public blockchain might be from the storage oversize that might be further improved by abstraction techniques. As a result, future research directions include developing FBaaS for public blockchain and further improvement of abstraction techniques.