Keywords

1 Introduction

Blockchain technology has played an important role to overcome challenges in numerous areas. Especially, it has brought efficient solutions for transactional systems since third-parties and central instances are expelled. Unfortunately, the decentralization has several challenges which cannot be adopted by our current political, economic and social systems. These problems were analyzed clearly in [1]. Herein, the fundamental technical problem of current blockchain algorithm is that ‘performance inefficiency’ could not be solved, in comparison with the central server system. In addition, notwithstanding each case of the client software maintains a copy of the blockchain and updates it based on these consensuses, the client software itself does not construct consensuses for making decisions about the future direction of the cryptocurrency, such as whether individuals or firms should be rewarded for taking actions supporting the cryptocurrency [2,3,4,5,6]. Furthermore, users’ completed anonymity and the absence of a responsible person are also open problems of decentralization [3, 4]. To date, there is a great deal of blockchain projects have launched. However, almost current blockchain projects have concentrated on finance by using existing platforms to generate tokens without the development of the technological features [6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21] while the intrinsic values should be the technological cores.

To this end, a whole new platform dubbed RCANE was proposed in [1] to solve above challenges of current blockchain. In that paper, the structure of RCANE platform was introduced as a semi-centralized network which combines the advantages of both centralized and decentralized networks. By dint of semi-centralized network, RCANE platform adapt to our preconceived perspectives of the current political, social, and economic systems to build up an ecosystem for economy, society and politics. Besides, the components of RCANE platform are parallel blockchain and APoS which are also presented to described its work mechanism. Moreover, an important feature of RCANE is to reward coins to individuals who have promoted the cryptocurrency by adopting the currency on the Internet, providing liquidity, coding. In addition, RCANE Project aims to pioneer the ‘content market’, where the cryptographic currency has an intrinsic value and can cover the blind spots of existing currencies, create new profitability by organizing system to give value to contents without monetary value, and establish cryptocurrency ecosystem to create a sustainable business model based on social and economic value to lead the future huge content market. However, the network security and the performance of RCANE network are still issues which must be developed to show its advantages in comparison with previous platforms, and also its executability in reality.

As an inheritance of our previous work in [1], this paper presents an alternative development of the network security and performance of RCANE platform. Herein, the transaction confirmation time, the number of transaction per second (TpS) and latency are emphasized to verify the RCANE performance. Besides, the transaction process is also adjusted to eliminate some meaningless steps. The algorithms and the transaction sequence are presented more clearly. In this paper, the brief review of previous platforms is also conducted to give the comparison with RCANE network to prove the necessary of the semi-centralized RCANE for our current economy, society and politics.

The rest of this paper is organized as follows. In Sect. 2, existing platforms such as Ethereum, EOS and Ripple are introduced. In the next section, RCANE network is presented, including the structure of the proposed parallel blockchain, the semi-centralized network of parallel blockchain and APoS. Then, the network security and the transaction sequence of RCANE network are also presented. In Sect. 4, an experimental set-up is conducted and the obtained results are shown. The last section presents the conclusions of the research work.

2 Existing Platforms

2.1 Ethereum

Ethereum was launched in 2015, which is referred to as Blockchain 2.0, and it has many similar ways in comparison with Bitcoin blockchain. However, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. This project is a great milestone in blockchain technology, improved the mechanism of ‘Smart Contract’ that has opened the unforeseen possibilities of Decentralized Applications (DAPPs) [22]. The Smart Contract is mostly applied for financial derivatives in which the main challenge is that the reference to an external price ticker is required. An Ethereum transaction takes about 17 s [23]. And 15 transactions per second is the maximum number that Ethereum may conduct. Besides, ETH takes several or more seconds to propagate the blocks themselves. The GAS value is also one feature of Ethereum, which is like a bridge used to jump to the front of the line. You can pay Miners more to do your work first. If you set your price to 0, you will be stuck forever. To date, many issues still require the discussion among the Ethereum developers, especially Proof-of-Stake consensus [24, 25].

2.2 EOS

EOS utilizes the decentralized consensus algorithm called Delegated Proof of Stake (DPoS) which is proven capable of meeting the performance requirements of applications on the blockchain [16]. By dint of DPoS consensus algorithm, an EOS transaction time is much faster in comparison with Ethereum, take on average 1.5 s. Theoretically, EOS may implement approximate 13,190 transactions per second. As mentioned in [16], who hold tokens on a blockchain adopting the EOS software may select block producers through a continuous approval voting system. Anyone may choose to participate in block production and will be given an opportunity to produce blocks, provided they can persuade token holders to vote for them. Typically, a transaction can be considered confirmed on average 0.25 s from time of broadcast if DPoS blockchains have one hundred percent block producer participation. In addition, EOS also adds asynchronous Byzantine Fault Tolerance for faster achievement of irreversibility, which can make transaction settlement and propagation times under a second.

2.3 Ripple

Ripple is a decentralized ledger that uses a completely different protocol to manage consensus in which there are not ‘blocks’, so Ripple is not blockchain. The peer-to-peer Ripple Ledger network consists of many distributed servers, called nodes, that accept and process transactions. Client applications sign and send transactions to nodes, which relay these candidate transactions throughout the network for processing. The nodes that receive, relay and process transactions may be either tracking nodes or validating nodes [26]. The Ripple transaction confirmation take about 3.5 s, and it can processed about 1500 transactions per second. Ripple consensus process takes roughly 3–5 s to complete. This might seem like an eternity for traders accustomed to measuring transaction latency in milliseconds or microseconds, however, once you remove the speed advantage that others might use to engage in predatory trading strategies, a lot of the latency aversion that people harbor disappears.

3 RCANE Network

3.1 Background of RCANE Network

In [1], a whole new platform dubbed RCANE was introduced which is a semi-centralized network as shown in Fig. 1, including stations and nodes. This network selects the advantages of decentralization and centralization to build up an efficient network for blockchains, in which the fast processing speed of centralization and the distributed system of decentralization are combined.

Fig. 1
figure 1

Semi-centralized network, including stations and normal nodes

Full size image

Besides, the work mechanism of RCANE network and the structure of parallel blockchain were presented clearly in [1]. Here, parallel blockchain consists of node blocks and history blocks as illustrated in Fig. 2. Node block contains the information of permitted user and the public key. And, history block contains the information of confirmed transactions.

Fig. 2
figure 2

The structure of the parallel Blockchain, including node blocks and history blocks

Full size image

Only the information of the desired node can be read in the parallel blockchain. By doing this, the efficiency of blockchain is improved considerably since the load of information is reduced during the transaction process. In parallel blockchain, it should be recorded as ‘real name’ in the node block so that only permitted users can access.

The vote is unique way to establish conventions for making decisions about the future direction of the RCANE, or to reward coins to individuals who have promoted the cryptocurrency. However, decisions, including transactions, are only possible with a Station node having power in the semi-centralized system. Stations have stakes, and their influence based on their amount of stake. This verification is named Authorized Proof of Stakes (APoS). Only stations can broadcast and generate blocks via broadcast. The super broadcasts are exchanged continuously among stations, so the blockchain is synchronized. Unlike previous platforms, in RCANE network, Blockchain is managed by Stations, and therefore, a personal node cannot issue block or broadcast to others, so hash connection is not essential.

As presented in [1], for example, a transaction needs to be confirmed, the vote will be happened as in Fig. 3 in which node “Toan” wants to send an amount of RCANE coin to node “Nung”. To start, “Toan” sends a request message to Station, then Station issues a new history block which contains transaction information (what = transaction), and broadcasts them. The transaction history is then newly issued, and other stations should vote for this history block to make it available. If the total of vote (TV) is equal or bigger than required vote (RV), that history block is available. The weight of vote of each Station (‘How’ in Fig. 3) depends on their stakes. If there are n Stations vote for the history block, the TV can be calculated by:

Fig. 3
figure 3

The procedure of vote for transactions

Full size image
$${\text{TV}} = {\text{How}}_{1} + \cdots + {\text{How}}_{\text{n}}$$
(1)

The RV of history block can be calculated by:

$${\text{RV}} = {\text{k}}.{\text{S}}$$
(2)

herein:

RV:

required vote

\({\text{k}} \in \left[ {\begin{array}{*{20}c} 0 & 1 \\ \end{array} } \right]\) :

muiredultiplier, is decided by voting

S:

the sum of stake.

If stations voted for transactions, they are responsible for those transactions in case of hacking transactions. In the case of hacking, the stations can cancel the hacking transaction by voting, and if someone spoils the network, the node may be deactivated. In other words, the wallet will be locked to prevent hacking. The cancelled vote weight can be calculated by this formula:

$${\text{CV}}_{\text{i}} = \left\{ {1 - \frac{{\text{RV}}}{{\text{S}}}} \right\}.{\text{OS}}_{\text{i}}$$
(3)

where:

CVi:

cancelled vote weight of Station ith

OSi:

own stake of Station ith.

If there are k Stations voting for cancelation, the total of cancelled vote weight can be calculated:

$${\text{TC}} = {\text{CV}}_{1} + \cdots + {\text{CV}}_{\text{k}}$$
(4)

If the TV − TC < RV, then the history block is cancelled. In other words, that history block becomes unavailable. By virtue of (4), only stations that have amount of voted stake can cancel requests to derive sufficient weights for block invalidation. By doing this, it prevents the dictatorship of stations who occupy a great deal of stakes, or the malicious cancellation of transactions.

3.2 Transaction Sequence

The transaction sequence in RCANE network includes five main steps:

  • Step 1: Query

The query is that the node sends a request to a station. The query packet is encrypted with a hash, session key, and private key as shown in Fig. 4. This packet cannot be read or created by anyone. After a station has received the query packet, which is decrypted along the reserved process of encryption as shown in Fig. 5.

Fig. 4
figure 4

Encryption of a query packet

Full size image
Fig. 5
figure 5

Decryption of a query packet

Full size image

The station ignores a packet if it has the similar value to previous ones, or if the time recorded in the packet is too long ago, or in the future.

  • Step 2: Transaction request

A node sends this query to the station when it sends a coin or token to another node. The station checks whether the amount of coins or tokens currently held by the node is valid or not, and checks whether it is a negative value or not. If the content of the request is correct, history block records the transaction details is created on the corresponding two nodes and broadcasted. It sends the unexpected train packet for verification to other stations shown as Fig. 6.

Fig. 6
figure 6

The method of request for a transaction

Full size image

  • Step 3: Acknowledgement request

The node informs other stations when a transaction request is made, as shown in Fig. 7. Each station stores an encrypted acknowledgment packet in its cache. As shown in Fig. 6, when the station broadcasts the transaction block that requests verification via an unexpected train packet, the other stations compare it with the acknowledgement request packet stored in the cache. It checks whether the amount of expected coin or token will be changed due to the blocks currently held by the transaction node and currently waiting for acknowledgment is valid or not. If the contents of the request is correct, creating a voting block in the previously created transaction block and notify it by broadcast.

Fig. 7
figure 7

The method of a approval for a transaction

Full size image

  • Step 4: Broadcast and receive

A broadcast is the propagating messages to all nodes from stations. Before sending a broadcast, stations encrypt packets as shown in Fig. 8. Then, the nodes receive the packets and decrypt them using the station’s address repeatedly and randomly, as shown in Fig. 9. After the transaction blocks and transaction voting blocks have been broadcasted, stations insert them into pending history block manager.

Fig. 8
figure 8

Encryption of a broadcast packet

Full size image
Fig. 9
figure 9

Decryption of a broadcast packet

Full size image

  • Step 5: Pending history block managing

Pending history block manager synchronizes history blocks received from broadcasts. The history block is inserted into the blockchain after 30 s. The number of pending history block queues is similar to the number of node blocks. Therefore, in the RCANE network, even if the block creation request is excessive, the bottleneck rarely occurs. By dint of the pending history queue, the scalability is solved.

3.3 Network Security

Packets in the RCANE network are encrypted by three algorithms.

SHA-256 hash: The SHA-256 hash algorithm produces irreversible data fragments. These fragments can be used to verify the packet tampering.

AES symmetric key encryption: The AES symmetric key algorithm produces reversible data fragments. Because symmetric keys are vulnerable to malicious hacking, it is not used for an important packet solely.

Asymmetric key encryption: Encrypts use the public and private key pairs recorded in the wallet file. Since there is no process of transmitting the public key, it cannot join the network if the public key is not recorded in the node block. Packets created with this encryption method cannot be tampered with or falsified unless passwords for wallet files and wallet files are leaked.

The scheme of transaction sequence contributes to ensure the security in which query packet and broadcast packet are presented. To serve security purpose, train packet, signature and wallet file also need to be explained.

Train Packet: Train packets are encrypted and decrypted in the same way as broadcasts. A station will ignore a packet if it has the similar value to previous ones, or if the time recorded in the packet is too long ago, or in the future.

Signature: Signature means encrypting certain text with a private key. Some history blocks require a signature to be active, and therefore, blocks require a signature that cannot be freely issued by the station or forged.

Wallet file: Wallet files are stored with the rwl extension and are encrypted with a symmetric key. Username and password must be entered to open a wallet which can be joined to the network if the public key is recorded as a node block in the blockchain of the RCANE network. Wallet files should never be uploaded online or shared with others.

4 Evaluation

4.1 Setup

This section performs some experiments to verify the developments of RCANE Project. The experiments are set up by using a console version of RCANE Core on both development running on AWS (Amazon Web Services, US) and server computer was provided by DevStack, South Korea. The configuration of DevStack: non-GPU, 16 vCPUs, 32 GB RAM, and operation system is Ubuntu 14. The purpose of the use of normal server computer is to prove that the RCANE network can work well even by using not good configuration server computers.

Each ten transactions are conducted in three different scenarios of one station, three stations and five stations, in which the performance of RCANE network are verified based on the transaction confirmation time, the number of transaction per second, and the latency to set up the transaction. A transaction request has been sent whenever a previous one completely finished. All of stations have same stakes so that the voting weight is equal. A transaction is confirmed when above a half of acknowledgement votes is broadcasted. Blocks are added on the blockchain database over 30 s passed after block creation.

4.2 Result

The results have shown that the performance of RCANE network is increased dramatically in comparison with our previous work. It is clear that the performance of RCANE network will much better if high configuration computers are used. The occupied capacity and cancellation block were presented clearly in our previous work and they are almost similar in this paper. So, in this section, transaction confirmation time, TpS and latency will be emphasized.

The TpS of RCANE network has shown in Fig. 10, where the number of TpS is increased by increasing the number of station joined in RCANE network. In theory, there is no limited number of TpS because this number will be increased if new stations joined in network. This is a great advantage of RCANE network.

Fig. 10
figure 10

The relationship between TpS and the number of stations in RCANE network

Full size image

The transaction confirmation time in three scenarios are shown in Tables 1, 2, and 3, where No. is the number of transactions, Time(s) is the confirmation time. These results have shown that the transaction confirmation time is reduced considerably in comparison with our previous work. They have also shown that the transaction speed is improved meaningfully in comparison with conventional blockchains since it wastes the few time for the verification. RCANE has independent pending queues for each node to synchronize the broadcasted blocks itself. Therefore, it does not need to save many transactions in one block like conventional blockchains, whereas it is able to make each history block to corresponding node block immediately. This is only capable in the semi-centralized network. The verification is fully not required because the stations are already verified by credible process named APoS voting. If the latency of internet network is ignored, the latency of RCANE network may approach to mini or micro seconds. In other words, the transaction requests are almost conducted immediately.

Table 1 Transaction confirmation time in case of one station
Full size table
Table 2 Transaction confirmation time in case of three station
Full size table
Table 3 Transaction confirmation time in case of five station
Full size table

The average of transaction confirmation time is shown in Fig. 11, where the transaction confirmation time increases in case of the joined nodes increase. The values are 2.8749 s for one station, 6.6309 s for three stations, and 8.6 s for five stations while these values are 4.257 s for one station and 34.339 s for five stations in previous work. The gradient of transaction confirmation time increase when the number of joined station increases. This is one currently existing problem that must be solved in the next research.

Fig. 11
figure 11

The relationship between transaction confirmation time and the number of stations in RCANE network

Full size image

The proposed method for next research to solve the mentioned existing problem of transaction confirmation time, and to increase TpS which are firstly presented as below:

  • Only two random stations are requested for authentication to vote for a transaction block (the higher the computing power, the higher the probability of selection).

  • The node has requested transaction which has to vote for oneself.

  • The three entities can cast the same 10 votes.

  • The required votes are 21/30, so that all three of entities should vote for the block to activate the transaction block. Two of entities should dis-vote to deactivate the transaction block.

5 Conclusion

This paper presented alternative developments for our previous work in terms of security network problem and the performance of RCANE platform. Herein, the background of RCANE platform is briefly introduced. In addition, algorithms for security, and the transaction sequence of RCANE blockchain are presented clearly. Another important advantage of RCANE network is that the scalability problem can be solved by using the pending history block manager. It is clearly shown that the mechanism of RCANE enables fast transaction rates that were not possible in decentralization networks. It proposed a new way to invalidate illegally generated blocks by the reasonable block cancellation weight formula. This alternative development of RCANE platform helps to prove its executability in reality to create the ‘content market’ by adapting to our preconceived perspectives of the current political, social, and economic systems. It is easy to prove that the performance of RCANE network will be much better in case of using high-power computer.