SEBF: A Single-Chain based Extension Model of Blockchain for Fintech

1 Introduction

Since Satoshi Nakamoto published the Bitcoin white paper [Nakamoto, 2008], a brand-new technology called blockchain came into the spotlight. It can solve many challenges, such as data tamper resistance, traceability, and decentralization in untrusted networks [Dai et al., 2020]. At present, Bitcoin that only allows financial transactions has been replaced by Ethereum [Buterin, 2014], which can program the blockchain using smart contracts, enabling users to write more sophisticated and intelligent protocols.

* Corresponding authors

The applications and the commercial value of blockchain have attracted widespread attention in artificial intelligence (AI) and financial communities. Blockchain can help guarantee the credibility of data in AI applications [Sarpatwar et al., 2019]. Blockchain also has broad applicability in financial systems and applications, such as cheque clearance [Kabra et al., 2020], auction system [An et al., 2019], and sharing economy [Abdur Rahman et al., 2019]. Blockchain systems have three characteristics: decentralization, nontamperability, and traceability. These characteristics allow users to carry out secure transactions along with historical transaction verification or search in a mutually distrusted network. This destines that blockchain will overturn traditional security models. However, there exists a severe problem concerning the scalability of data types for blockchain: the block bodies of most blockchains use one or a few limited types of data for storage. For the blockchains represented by Bitcoin that concerns the maintenance of unspent transaction output (UTXO), the transactions stored within their blocks only support the transaction data of Bitcoin (coinbase transaction is also essentially the data transaction with bitcoin). In Ethereum, full nodes are responsible for maintaining the transaction tree, the state tree, and the receipt tree, which constitute the Merkle tree [Merkle, 1987]. These three trees in Ethereum store three different types of data, however, with the rapid development of blockchain, they may not meet the needs of various specific scenarios in the future. Therefore, there still exists the problem of poor scalability of data types

1. Two smart contracts, i.e., extended function embedding and multi-type data processing smart contracts, are designed to facilitate cooperation between the blockchain layer and the oracle group regulator layer.
2. We build a fintech alliance chain and deploy the oracle group along with the corresponding smart contract on the FISCO-BCOS platform 1 . Experimental results indicate that our SEBF model can improve the efficiency of Simplified Payment Verification (SPV) [Lin and Liao, 2017].

2 Related Works

The poor scalability of blockchain may restrict its rapid development [Liu et al., 2019]. A traditional blockchain can only store one or just a few types of data [Dai et al., 2019]. In order to overcome the scalability issues of blockchain, two types of approaches are adopted in the current mainstream research, including the cross-chain methods [Back et al., 2014] and the main chain extension methods [Lombrozo et al., 2015]. Both kinds of approaches mainly focus on the extension of storage capacity [Jiang and Wu, 2019] or transaction throughput [Sompolinsky and Zohar, 2013].

In terms of the cross-chain technology, Deng et al. [Deng et al., 2018] studied cross-chain technology based on sidechains and hash locks, and proposed a new cross-chain technology to realize communication between different blockchains. Due to the complexity of the cross-chain mechanism, there exist restrictions with regards to asset transfers and data exchange between different blockchains,

1 https://github.com/FISCO-BCOS/FISCO-BCOS

supported by the underlying blockchain.

1.1 Motivation and Contribution

At present, there exist two kinds of methods that focus on the data scalability of blockchain, including the cross-chain methods [Back et al., 2014; Singh et al., 2020] and the main chain extension methods [Liu et al., 2018]. These methods try to extend the block storage capacity and throughput of blockchain by adopting sidechains, changing block production processes, or optimizing the consensus protocol. However, the problem of how to make blockchain be able to deal with various data types has not been well studied.

Enabling an intelligent system to deal with various data types is an important research topic of AI [Chen et al., 2019]. In this paper, in order to alleviate the above-mentioned shortcomings of blockchain, we propose a single-chain based extension model of blockchain for fintech (SEBF). The contributions of our study can be summarized as follows:

1. We design a four-layer architecture for our SEBF model, which contains the user layer, financial terminal layer, blockchain layer, and the oracle group regulator layer. To our knowledge, we are among the first to study the problem of single-chain based extension of data type in fintech blockchain.
2. An external trusted oracle group and a financial regulator agency, e.g., the authorities like a bank, insurance company, etc., are introduced to verify the data type submitted by the blockchain, which makes the successfully verified data be recorded into the sub-tree collection in blockchain, and thus generating the corresponding Merkle tree. In this way, the data type in the blockchain is extended.

which reduce usability and comfort for users. Focusing on this problem, Borkowski et al. [Borkowski et al., 2019] proposed the DeXTT cross-blockchain transfer protocol, which can realize cross-blockchain asset transfer without relying on any single blockchain. Atomic cross-chain exchange [Herlihy, 2018] tries to ensure the security of data transfer between the main chain and sidechain. This kind of works mainly studies the security and robustness of the cooperation between the sidechain and main chain, supporting the data extension indirectly with the help of sidechain.

Against the shortcomings of the cross-chain technology, the main chain extension is another feasible solution. In terms of the scalability on the main chain, bitcoincash 2 adjusts block production time and block size. The increase in block size will deteriorate the efficiency of SPV verification on light nodes. Enterprise Operation System (EOS) [Lee et al., 2017] increases blockchain throughput by using the Byzantine Fault Tolerance-Deligated Proof of Stake (BFT-DPOS) mechanism [Du et al., 2017], and Bitcoin-NG [Eyal et al., 2016] redefines the block production process.

2 https://www.bitcoincash.org/

This kind of methods changes the block production process or optimizes the consensus protocol of the main chain to make effects similar to an extension.

There exist obvious differences between these two kinds of methods and our SEBF model. (1) These two kinds of methods mainly focus on the extension of block storage capacity and throughput. Contrary to them, we for the first time to study the data type extension problem and provide an effective extension solution. (2) The cross-chain methods promote extension based on the sidechains. Our single-chain based data type extension model is intrinsically different from these cross-chain works. The main differences are summarized in Table 1.

3 Systematic Model Design of SEBF

In this section, we first describe the system architecture. Then we introduce the detailed implementation of SEBF model.

3.1 System Architecture

As shown in Fig. 1, our SEBF model contains four layers: the user layer, financial terminal layer, blockchain layer, and the oracle group regulator layer. The first three layers correspond to the roles of user, financial terminal, and blockchain node, respectively. And the last layer corresponds to the roles of financial regulator agency, i.e., the authorities like a bank, insurance company, etc., and oracle group. The users are the participants who intend to purchase or use financial services. The financial terminals refer to the devices, e.g., the light nodes like a personal computer (PC) or mobile phone, that can query, submit, or handle certain financial services. The blockchain refers to an alliance chain established for the financial service, which only allows the authorized nodes to be added into the blockchain. Blockchain is responsible for storing the related template data that the financial institution allows. The financial institution refers to authoritative institutions like bank, insurance company, and securities and exchange commission. Here, we introduce the concept of template data. We use T TYPE  -  to represent the template data, which is a data structure that is filled according to a certain transaction data format. For example, in the Bitcoin system, when a transaction is initiated, the address of the sender, the recipient's address, and the transfer amount need to be filled in, and the data structure containing this three data information is called template data. In our model, the oracle group consisting of several trusted devices called oracle machines serves as a unique bridge between the financial alliance chain and the external data. And it verifies the template data that needs to be verified in the alliance chain.

3.2 Detailed Implementation

The overall operation process of our model can be summarized as follows. As shown in Fig. 2, firstly, the user selects the financial services that he wants to query/process on the financial terminal. In the same time, the user needs to submit his signed authentication. The financial terminal preliminarily verifies the identity of the user and returns the verification result to the user. If the identity of the user is successfully verified, the terminal will then send the signed T TYPE  -  template data message to the blockchain node. When the message is received, the node will verify the signature of the user and check whether the type of the data is Token   . Here, Token   is the token circulated on the financial blockchain, which can be regarded as a kind of simple template data during transfer transaction. The built-in Token   template type is solidified in blockchain, and the data with this type can be directly run by blockchain node. If the type of the data is Token   , the data is stored in local Token   sub-tree collection. Here, Token   sub-tree is a Merkle tree that specially records the data of Token   . The node will broadcast this message to other nodes. If the type of the data is not Token   , the node will send the data to oracle machine in the oracle group. When the oracle machine receives the message, it will conduct a smart contract and judge whether the type of message has been authenticated by the financial regulator agency, i.e., the authoritative institutions like bank, the insurance company, and securities and exchange commission. If the message is successfully verified, the oracle machine will sign the message, and return the message to the blockchain node. The node will store the data into the corresponding sub-tree collection, and broadcast the message in the blockchain network. After an epoch, the nodes will mine a new block. The financial terminal will calculate the hash value according to the submitted data, perform simplified payment verification (SPV), and return the SPV result to the user. In this way, a single chain is able to deal with multiple data types. In the following, we introduce more details about the implementation process.

The Public-private Key Generation by User

A user first generates a private key u P locally ( u P can be considered as a point on the curve secp256k1 [Johnson et al., 2001]), and also randomly selects a point u G on the curve secp256k1, which satisfies u u z G O = . Here, O is an infinity point, the prime number u z that meets safety requirements is the order of u G . Then = u u u K P G  can be calculated, and the public key ( , ) u u z K corresponds to u P can be achieved. Here, " " denotes the multiplication defined on the elliptic curve. In this way, a public-private key can be generated by the user.

Template Data Processing on Financial Terminal

(1) Digest Calculation with the SHA256 Algorithm

The user submits the template data D and the public-private key to the financial terminal. The SHA256 algorithm [Courtois et al., 2014] is used for digest calculation, which is a well-known security hash algorithm that can generate a 256-bit digest. By employing the SHA256 algorithm, we can get the digest u dig of the template data D .

(2) Digest Signature by the User

When the user applies for a certain service, the financial terminal signs the provided service according to the private key u P provided by the user. Specifically, it selects a random number u a within the elliptic curve, and calculates the point on the elliptic curve, i.e., ( , ) u u x y , with u a and u G

Then, the signed message ( , ) u u r s by u P can be calculated as

Here, "mod" denotes the modulus operation. This process of digest signature by the user is defined in the function digestSign(public key, digest).

The financial terminal extracts the template type T (the abbreviation of T TYPE  -  ) in template data D . At the same time, in order to prevent the distributed denial of service attack (DDoS) [Essaid et al., 2019], the user is required to pay deposit Bond , and the deposit amount is set by financial regulator agency. Then the financial terminal can obtain the integration package u Package for transfer by

This package will be sent to the blockchain node. In this way, the process of interop signature between the user and financial terminal is finished.

Message Processing by Blockchain Node

When the blockchain node receives the data package u Package sent by the financial terminal, the smart contract locks the Bond of the user, and verifies the user signature. The blockchain node then calculates the digest ' u dig with the SHA256 algorithm. After that, the signed message can be calculated with Eqs. (5) and (6)

If ' u u r r = , the signature verification can be regarded to be successful. Afterward, the template type T is checked that whether it is built-in Token   template type or not. Here, Token   is the token circulated on the financial blockchain, which can be regarded as a kind of simple template data during transfer transactions. The built-in Token   template type is solidified in blockchain, and blockchain can directly run this type of data. If T is Token   template type, then ( , , ) Token D Bond   will be stored in local Token   sub-tree collection. And the blockchain node will use Flooding routing protocol [Rahman et al., 2004] to broadcast u Package to other nodes. If T is not the Token   template type, the node uses its own private key b P to sign the integration package and obtains the package data b Package

where ( , ) b b z K is the public key corresponding to b P , ( , ) b b r s is the signed message by the blockchain node on template data D with b P . The signature process is the same as the process digestSign(public key, digest). Financial blockchain is an alliance chain, and thus nodes need to be authorized by the financial regulator agency before they can be added. In this secure scenario, it is hardly for nodes to act maliciously. Even in case if the nodes act maliciously, they will be eliminated once they are found out by the financial regulator agency. Thus, in order to save the communication resource, there is no need to attach Bond to data package. The blockchain node will send data package b Package to oracle machine, and temporarily save the template data ( , , ) T TYPE D Bond  -  locally. If the oracle machine does not make response or replies that the template data does not Algorithm 1. Smart contract of extended function embedding

1. Input: FRA signature, integrity hash, and FRA template package
2. ecrecoverDecode(FRA signature)
3. require(SHA256(FRA template package)==integrity hash)
4. require(FRA template package==SHA256(FRA template package))
5. split FRA template package
6. if (checkTemplateTable(template table) && checkTemplateScript(run-validation script)) then
7. create T TYPE  -  table in oracle group database
8. store run-validation script in oracle group
9. else

10. throw

11. end

exist, the blockchain node deletes the data ( , , ) T TYPE D Bond  -  and deducts user's deposit.

Template Message Processing by the Oracle Group

The oracle system consists of an oracle group and the financial regulator agency. Oracle group runs a smart contract that communicates with the financial regulator agency. When a new service is added to financial terminals, the corresponding T TYPE  -  template data will be added to the oracle group through a smart contract. The oracle machines then deploy corresponding smart contract on themselves.

Algorithm 1 summarizes the smart contract of extended function embedding that is deployed in the oracle machines, which deals with the process that the financial regulator agency adds the function corresponding to T TYPE  -  into the oracle group. The smart contract will verify the signature of the financial regulator agency (FRA), template integrity hash, and the integrity of the FRA template package, including template table and run-validation script, using the functions checkTemplateTable() and checkTemplateScript().

Algorithm 2 summarizes the smart contract of multi-type data processing that is deployed in the oracle machines, which deals with the T TYPE  -  template data to be verified that is sent by the blockchain node. When the smart contract receives the b Package sent by blockchain node, it first verifies the signature of blockchain node. If the signature verification is successful, T in b Package will then be compared with T TYPE  -  that is stored in a local oracle group database. If the type of T TYPE  -  corresponding to T is found, it is then considered to meet the condition that the T TYPE  -  data requires to be processed by the smart contract. Afterwards, the smart contract uses the oracle machine's private key o P to sign D and obtain o Package by

Algorithm 2. Smart contract of multi-type data processing

1. Input:

b Package

1. split b Package
2. require(digestSign( ( , ) b b z K ,

1. if (search( T TYPE  -  )) then
2. conduct run-validation script
3. oracle machine signs D
4. return o Package
5. else
6. throw

10. end

where ( , ) o o z K is public key corresponding to o P , ( , ) o o r s is the signed message by the oracle machine on D with o P .

Processing of Data Returned by the Oracle Group with the Blockchain Node

After receiving o Package , the blockchain node first verifies the signature of the oracle machine. After successfully verifying that the oracle machine's signature is true, o Package is then parsed into the ( , , ) T TYPE D Bond  -  template data for storage, and this data will be compared with temporary template data stored locally in the blockchain node to check whether they are consistent or not. If they are consistent, this template data will be stored in the T TYPE  -  sub-tree collection, and this blockchain node will broadcast it to other nodes through the Flooding protocol.

After a certain period of time, the blockchain node will sort the template data stored locally in all sub-tree collections in the order of timestamps. Taking Token   as an example, the node will calculate the corresponding hash value , {1, , } i HToken_DATA i I  of the sorted data _ i Token DATA in the sub-tree collection as follows

where I is the number of Token   template data. Taking i HToken_DATA and i+1 HToken_DATA as the input of SHA256 algorithm, their parent node's hash value i,i+1 HToken_DATA can be calculated as

In this way, the hash value of each two sibling nodes is used to calculate the hash value of their parent node, and after several iterations, the corresponding Token   sub-tree Merkle root HToken_Root is finally produced. The calculation of other sub-tree roots , {1, , } j H <T TYPE> _Root j J -  corresponding to T TYPE  -  remains the same as that corresponding to Token   , where J is the number of categories of T TYPE  -  . Then, the hash values of the sub-tree roots are stored in the block header.

After the block is produced, the conditions, i.e., the block is mined and template data sent by user is inside the block body, will be met for the smart contract to return bonds, and the corresponding amount of bonds will then be added to the user's account balance.

SPV of the Financial Terminal

After waiting for a period of time, the user can utilize the financial terminal to send a SPV request to the blockchain node. The financial terminal will then calculate the hash value of the triple ( , , ) T D Bond by

and search the corresponding hash value u HPackage in the sub-tree corresponding to T . After the hash value is found, the financial terminal performs SPV. If verification is successful, the transaction will be successfully recorded in the block, which marks the completion of a template data transaction.

4 Simulation Experiment

In this section, we describe the experimental environment, and provide the results and the corresponding analysis.

4.1 Experimental Environment

In the experiment, the blockchain is deployed locally. Ten personal computers are used to simulate the nodes of the blockchain, a Raspberry Pi (light node) is used to simulate the multi-functional financial terminal, and the multi-group alliance chain that is built on the FISCO-BCOS platform is used as the oracle group. The detailed configurations are shown in Table 2. The main code of our model and the corresponding application demo is released on the webpage https://github.com/sebf2020/ijcai20.

4.2 Experimental Results and Analysis

In the experiment, we define two kinds of data types. The first type is the built-in Token   template data type, which records the basic transfer transactions in the blockchain, including the public key of the transfer sender, the public key of the transfer receiver, and the amount of transfer. The other type is T TYPE  -  template data type that is extended by the oracle machine. Three T TYPE  -  template data types are defined, including Insurance, CrossborderPayment, and ElectronicIdentity. The Insurance template data type is responsible for recording healthy financial insurance data,

<Token> built-in data type

T-Type Token ,

Sender transfer sender s public key, Receiver transfer receiver s public key, Amount transfer amount

<T-TYPE>Extended data type

T-Type CrossborderPayment , User user s public key, LocalBank local bank account, TargetBank target bank account, Amount :transfer amount

T-Type Insurance , User user s public key, Type type of insurance, InsuredAmount insurance amount T-Type ElectronicIdentity User user s public key, Name user s name, Birth user s birth, Address user s Address, IdentityNo. user s ID number

Figure 3. Template data types.

which includes the public key of the user (policy holder), the type of insurance, and the insurance amount, making it easy for the insurance company to call the data quickly. The CrossborderPayment template data type is responsible for recording cross-border transfer transaction data, which includes the public key of the cross-border transfer user, the public key of the local bank account, the public key of the target bank account, and the transfer amount, making it easy for cross-border banks to quickly process user's transfer. The ElectronicIdentity template data type is responsible for recording the user's electronic ID information data, including the public key of user's account, user's real name, birth date, the user's address, and electronic ID number, which enables regulators to make quick calls to this type of data. The above Token   template data type and three T TYPE  -  template data types are shown in Fig. 3.

In order to verify the effectiveness of our SEBF model, we compare our model with the traditional financial single-chain without extension function. Specifically, in the experiment, we utilize four kinds of blockchains with different settings, including: (1) a single-chain without extension function, only having the built-in Token   template data type, which is named B-T; (2) a single-chain with extension function containing the oracle machine and financial regulator agency, having the built-in Token   and the Insurance template data types, which is named B-TI; (3) a single-chain with extension function containing the oracle machine and financial regulator agency, having the built-in Token   , the Insurance, and the CrossborderPayment template data types, which is called B-TIC; (4) a single-chain with extension function containing the oracle machine and financial regulator agency, having the built-in Token   , the Insurance, the CrossborderPayment, and ElectronicIdentity template data types, which is called B-TICE.

For a given fixed number of template data, our SEBF model can make single-chain be able to deal with multiple types of data. By using the index established with the data type information, the efficiency of data search is improved by rapidly searching data of a specific type. The simplified payment verification (SPV) time is an intuitive reflection of data search efficiency, and it is also a suitable indicator of the financial blockchain processing delay that directly affects the users' experience. Thus, we use SPV verification time as an evaluation measure. The time complexity of the SPV process is ( ) 2 2 log N N , where N is the total number of template data. When there are multiple types of data, the time complexity of the SPV process of our model is ( ) 2 1 2 log J j j j N N =  , where , 1, , j N j J = denotes the number of data of the j th data type, and 1 J j j N N = =  . It is obvious that ( ) ( ) 2 2 1 2 log 2 log J j j j N N N N =   . Thus, theoretically, our SEBF model can improve the verification efficiency of SPV.

We randomly generate template data and input the data to the above four kinds of blockchains. In practice, Token   is an important template type in the financial blockchain, and Token   template data should account for a large proportion of data in the financial blockchain. Therefore, we generate more Token   template data than that of other types in the second to the fourth kind of blockchains. For example, the Token   template data accounts for 70 percent of the total input data set, and the other types of data constitutes the remaining 30 percent of the input data set equivalently. For the blockchain B-T, we randomly select a Token   template data in the input data set to perform SPV and record the verification time. For the second to the fourth kind of blockchains, we randomly select a Token   template data and a single data for each of the other types in the input data set to perform SPV and record the verification time corresponding to each data type. And then, we compute the average verification time across multiple data types for each kind of blockchain. Specifically, in the experiment, the size of the input data set is investigated in the range of [500,3000] with the step of 500. For each case of data set size, we record the optimal and the worst verification time and report the mean value for each kind of blockchain. In order to make it easy to input data, the mining epoch is set as 10 minutes.

Fig. 4 shows the comparison of SPV verification time of four kinds of blockchains when the Token   data accounts for 70 percent of the input data set. With the increase of the data set size, the verification time of four kinds of blockchains shows the increasing trend. It is also obvious that the verification time of the second to the fourth kind of blockchains is shorter than that of B-T, i.e., the traditional financial blockchain only containing the Token   template data type, for a specific data set size. Furthermore, for a specific data set size, B-TIC needs less verification time than B-TI, and B-TICE needs the least verification time.

Table 3 tabulates the average SPV verification time across different data set sizes of four kinds of blockchains under different percentages of Token   data in the input data set. We can see that with the increase of the percentage of Token   data in the input data set, the verification time of four blockchains experiences a slight increase. And in all cases of percentages, B-TI, B-TIC, and B-TICE cost less verification time than that of B-T, and B-TICE costs the least verification time.

As a summary, our model is an effective single-chain based extension solution, and it can obviously reduce the SPV verification time as compared with the traditional financial blockchain. With the increase of type of template data, the SPV verification time of our model will be further reduced.

5 Conclusion

In this paper, we design a single-chain based extension model of blockchain for fintech (SEBF). We specially design a four-layer system model architecture. Based on the oracle group and financial regulator agency, we provide a novel data structure extension mechanism and design the corresponding smart contracts, such that the single-chain is able to store multiple types of template data, e.g., Insurance, CrossborderPayment, and ElectronicIdentity. Experimental results indicate that the SEBF model improves the verification efficiency of SPV as compared with traditional financial blockchain, and with the increase of the type of template data, the verification efficiency can be further improved.

For the future work, we will apply our SEBF model in a real bank scenario with Tonghe Chain 3 , where a built-in token type of data is owned and new business is developed aperiodically that generates new data types, for further validating the effectiveness and efficiency of the proposed model.

Acknowledgments

This work was supported by the National Key R&D Program of China (Nos. 2017YFB1401300, 2017YFB1401302), National Natural Science Foundation of China (Nos. 61702280, 61902194), Outstanding Youth of Jiangsu Natural Science Foundation (No. BK20170100) , Key R&D Program of Jiangsu (No. BE2017166), Natural Science Foundation of Jiangsu Province (No. BK20170900), Natural Science Foundation of the Jiangsu Higher Education Institutions of China (No.19KJB520046), National Postdoctoral Program for Innovative Talents (No. BX20180146), China Postdoctoral Science Foundation (No. 2019M661901), Jiangsu Planned Projects for Postdoctoral Research Funds (No. 2019K024), Six Talent Peak Projects in Jiangsu Province, CCF-Tencent Open Fund WeBank Special Funding (No. CCF-WebankRAGR20190104), NUPT DingShan Sholar Project, the Innovation and Entrepreneurship Projects of Jiangsu Province and NUPTSF (No. NY219132).