WO2022182303A1

WO2022182303A1 - A block chain system

Info

Publication number: WO2022182303A1
Application number: PCT/TR2021/050175
Authority: WO
Inventors: Gurkan OZTURK; Murat Sen
Original assignee: Cloudpeer Global Teknoloji A. S.
Priority date: 2021-02-26
Filing date: 2021-02-26
Publication date: 2022-09-01

Abstract

The invention relates a blockchain system comprising a first node (10) and at least one second node (20) associated with the first node (10). The blockchain system is operating under the process steps of pairing the first node (10) and at least the second node (20) in a virtual private network, sending a transaction request by the first node (10) to the paired second node (20); control of the transaction request sent to the second node (10) by a super node (60); verification of the controlled transaction request by the super node (60) with consensus validation; if the validation is acknowledged, creation of a transaction block (12) is by a block generator (70) on the second node (20) corresponding to the sent transaction request.

Description

A BLOCK CHAIN SYSTEM

TECHNICAL FIELD

The invention relates to a blockchain system, in particular a blockchain system used in a virtual private network.

BACKGROUND OF THE ART

A blockchain system consists of several nodes, with each node having a shared ledger. The data associated with the blocks is recorded chronologically in the shared ledger. The data associated with a block corresponds to a set of transactions whose legitimacy is agreed upon by all nodes over a period of time. In other words, the shared ledger records a scheduled chain of data blocks, hence it is called a "blockchain". Each node can synchronize the shared ledger and verify the authenticity of each transaction.

A public blockchain system is completely decentralized and transparent to the public. Any individual or organization can become a node in the public blockchain system; this means that any entity can become a node and maintain the shared ledger and require all nodes to reach a consensus on a data block and save the data block. This makes the use of the blockchain system within the company risky in terms of privacy.

On the other hand, publicly inaccessible blockchain systems are known in the art. CN111211958A relates to a method and device for providing VPN service. A blockchain network and node equipment, the blockchain network comprises a plurality of nodes, and the plurality of nodes comprise a service node and a relay node, wherein forwarding sequence information of the plurality of nodes is recorded in an intelligent contract of the blockchain network, each node is used for determining whether a subsequent node exists in the node or not according to the forwarding sequence information when receiving a VPN connection request of a client, the VPN connection request is forwarded tothe subsequent node if the subsequent node exists in the node, and the service node is also used for providing VPN service for the client when receiving the VPN connection request. BRIEF DESCRIPTION OF THE INVENTION

The object of the invention is to ensure privacy of data in the blockchain system.

Another object of the invention is to provide cost advantage and save energy when using the blockchain system.

To achieve above mentioned objective, invention relates to a blockchain system comprising a first node and at least one second node associated with the first node. The blockchain system is operating under the process steps of pairing the first node and at least the second node in a virtual private network, sending a transaction request by the first node to the paired second node; control of the transaction request sent to the second node by a super node; verification of the controlled transaction request by the super node with consensus validation; if the validation is acknowledged, creation of a transaction block is by a block generator on the second node corresponding to the sent transaction request. Transaction requests made within the virtual private network and transaction blocks created as a result of transaction requests are prevented from being viewed by third party software or third parties thanks to the blockchain system. Additionally, the performance of the nodes in the virtual private network and virtual private network can be adjusted by controlling and verifying with the super node. Moreover, the super node in the closed network can operate on a normal computer without the need for a high-performance computer. This provide cost advantage and allow energy savings.

In a preferred embodiment of the invention the transaction results of the transaction blocks are recorded in a ledger within the first and at least the second node in a process. Thus, the transaction results of the transaction blocks are prevented from being seen by third party software or third parties.

In a preferred application of the invention, the transaction results of the transaction blocks in the first and at least the second node are recorded in a ledger by means of at least one smart contract. Thanks to smart contracts, the ledger is protected from any security vulnerabilities and unauthorized access or modification requests.

In a preferred application of the invention, the transaction results of the transaction blocks are recorded by at least one smart contract in a chronological order in the ledger. Thus, the transaction order of the transaction results in the ledger is preserved and in case of a possible error, it is ensured that it is determined during which transaction. In an alternative application, it can be recorded in the ledger alphabetically.

In a preferred embodiment of the invention, the super node synchronizes the ledger and block heights of at least one second node matching the first node. Thus, it is ensured that the transaction requests after the pairing the nodes are transmitted securely between the nodes.

In a preferred application of the invention the super node detects by creating a gap information the downtime status of the any node among any node of at least the second node pairing the first node or missing the processing of the transaction results of the transaction blocks. Thus, the downtime of the nodes in the virtual private network is detected without the need for any additional resources.

In a preferred application, the super node blocks the first or at least the second node when the gap information does not match. Thus, it is ensured that transaction request information between nodes is not lost.

In a preferred embodiment of the invention, the block generator sends the transaction block corresponding to the verified transaction request to each node in the virtual private network. Thus, tracking of the transaction blocks created on any node is ensured.

In a preferred embodiment of the invention the block generator collects a confirmation message from each node regarding the sending of the transaction block to each node. In this way, it can be checked whether the transaction block is registered at each node in the virtual private network.

BRIEF DESCRIPTION OF THE FIGURES

Figure 1 is a schematic representation of the nodes and block generator in the inventive blockchain system.

Figure 2 is a enlarged representation of the node in figure 1.

DETAILED DESCRIPTION OF THE INVENTION

In this detailed explanation, development of the invention is explained without any limitation and only with reference to examples to better explain the subject matter. In Figure 1, the nodes and the block generator in the subject matter blockchain system are shown schematically. The blockchain system includes a first node (10) and at least a second node (20). In the preferred embodiment, a five-node blockchain system is used, comprising a first node (10), a second node (20), a third node (30), a fourth node (40), and a fifth node (50). The first node (10) is linked with other nodes (20, 30, 40, 50) in a virtual private network in a signal transmitting manner. The first node (10) pairs with the second node (20) in the virtual private network to perform a transaction request. After the pairing is acknowledged, it sends a transaction request to the second node (20) over the first node (10). Consensus verification and control of the sent transaction request is conducted by a super node (60) in the virtual private network. The super node (60) monitors the performance of the virtual private network and nodes regardless of whether they are operational and physically ready to provide transaction request forwarding services. In addition, it creates proactive alerts in case of any potential problem or detection. These alerts can be monitored from any management console developed for this purpose. If the transaction request is confirmed by the super node (60), a transaction block (14) is created by a block generator (70) on the second node (20) to which the transaction request is sent.

Figure 2 is an enlarged representation of the node given in figure 1. The first node (10) contains a transaction block (12) that is construed as a result of transaction requests. The transaction block (14) contains information such as the start date and execution time of the transaction request. The transaction result of the transaction block (14) is recorded in a ledger (14) located in the first node (10). The transaction cannot be accessible to a third- party software or any third party since it is recorded in the ledger (14). Within the first node (10), at least one smart contract (16) is contained that allows the transaction results to be recorded in the ledger (14). Three smart contracts (16) are utilized in the preferred application. Smart contracts (16) are basic computer codes used to manage and interfere with all ledgers (14) and transaction block (12) activities. All flow inside the first node (10) is managed by smart contracts (16). For example, if a new transaction block (12) is created on the first node (10) by the block generator (70), the smart contracts (16) are triggered for the new transaction block (12) and copies the transaction block (12) to a block storage and is insert it as the last block of the chain. After insertion, the smart contracts (16) record the transaction result of the transaction block (12) in the ledger (14). Also, any query request is handled by smart contracts (16) to manage all actions on the first node. In this way, the ledger (14) is protected from any security vulnerabilities and unauthorized access or modification requests. In the working principle of the subject matter blockchain starts with the pairing of the first node (10) and any node (20, 30, 40, 50) and sending a transaction request between them. A transaction request is a preformed packet received directly from any node (10, 20, 30, 40, 50) in the network to insert in a block. The transaction request contains a transaction header. The transaction header contains the unique reference number to identify the transaction request. It also includes the computed cryptographic hash of a transaction body and the timestamp for the transaction creation moment. The transaction request also contains the transaction body. The transaction body contains the proposed transaction content, result part, signature and node IDs information. The proposed transaction content includes the part for the transaction request. The result section contains information about the status of the transaction request before and after, and information for recording and monitoring the transaction request. The signature part contains the personal signature of the node (10, 20, 30, 40, 50) that created the transaction request. The node IDs section contains the list of nodes (10, 20, 30, 40, 50) in the network to be confirmed. The transaction request sent is checked by the super node (60) and consensus verification is performed. As consensus verification, a parametrically defined consensus model is used, which can be maintained according to the number of nodes in the virtual private network. Successful consensus is required to establish fault-tolerant transaction and block generation within the virtual private network. If n is the total number of nodes in the network, to reach consensus, the minimum number of peers to be accepted and validated is n > (n/2)+1. For example, in a network with 5 nodes + 1 block generator (70) + super node (60), it is necessary to set a minimum of 3 parameters for successful consensus verification. In this way, it is determined that more than half of the nodes (10, 20, 30, 40, 50) must accept and apply for the same change, and thus it can be considered as the final record. The super node (60) also synchronizes the height points of both the ledger (14) and transaction blocks (12) of the nodes (10, 20, 30, 40, 50) along with the consensus verification. In case any node (10, 20, 30, 40, 50) is down for a while and misses processing some transaction blocks (12) distributed by the block generator (70), it will be identified as void information by the super node (60) during periodic checks. The super node (60) does not allow the node to create new transactions until the gap information is filled. The super node (60) will determine the height of the last transaction block (12) after the gap information is filled and send the missing transaction blocks (12) to the relevant node for processing. After the consensus verification is completed, the transaction block (12) is created by the block generator (70) in response to the transaction request on the second node (20). The block generator (70) is to ensure that the generated transaction blocks (12) have the same transaction block (12) height on all notes and the same state version across all ledgers 14. Any conflict between transaction blocks (12) located on nodes (10, 20, 30, 40, 50) will cause a fork issue, which means a duplication and loss of data consistency in the blockchain network. To mitigate the problem, the super node (60) needs to approve and queue the transaction blocks (12) before the block generator (70) issues it. The block generator (70) follows a certain sequence to generate the transaction blocks (12). First, the consensus verification of the transaction requests is performed by the super node (60). After verification, the transaction request must be confirmed on each node (10, 20, 30, 40, 50) in the virtual private network. The approval process can be defined as the collection of node signatures in the requested transaction request. Depending on the governance model, the predefined nodes (10, 20, 30, 40, 50) must sign the transaction before treating the transaction as an approved transaction and creating the transaction block (12) as a now immutable record. All nodes (10, 20, 30, 40, 50) play the role of a client to create a transaction and also become the approver of transaction requests by placing their signatures. After the confirmation is completed, the transaction block (12) is created by the block generator (70) and placed in the block. When creating the transaction block (12), a block header is determined and consists of four different fields; First, a block number is determined. The specified block number is a sequence number from the first transaction block (12) to the latest. The second field contains a valid block hash. The current block hash information contains the cryptographic hash of the data layer and metadata layer. The third field contains the previous block hash information. Thanks to the third block hash information, the hash value of the previous transaction blocks (12) is calculated, and it is ensured that the blocks of the chain structure are followed and matched from the last to the formation. The last field contains a timestamp and contains the date and time of the creation of the transaction block (12). At the bottom of the header is a data layer. The data layer contains single or multiple transaction requests of all packets, depending on the parameter of having a single or multiple transaction request in a block option. At the bottom of the data layer is a metadata layer. The metadata layer contains the block certificate, public key and signature. After the transaction block (12) is created, the block generator (70) broadcasts the final block to all nodes (10, 20, 30, 40, 50) in the network. It will be to gather confirmations from each node (10, 20, 30, 40, 50) that it has been received and successfully processed by all of the transaction block (12). The generated transaction block (12) is decrypted using a combination of zero knowledge proof (ZKP) and encryption of confidential content. Confidential content will be encrypted as an attachment to the block or transaction and shared only with the relevant nodes (10, 20, 30, 40, 50). This way, all nodes (10, 20, 30, 40, 50) will keep the cryptographic hash of the secret content. This will allow all nodes (10, 20, 30, 40, 50) to store data without knowing its contents. Only the parties concerned with the data will be able to examine the data with the password they have to decrypt it. In this way, confidentiality will be provided as end-to-end security for users in the blockchain system, the content will not be shared with any irrelevant party, and the hash shared with users ensures that the features of the blockchain system can be used with high security standards.

REFERENCE NUMBERS

10 First Node 12 Transaction Block 14 Notebook (Ledger)

16 Smart Contract 20 Second Node

30 Third Node 40 Fourth Node 50 Fifth Node 60 Super Knots 70 Block Generator

Claims

1- A blockchain system comprising a first node (10) and at least one second node (20) associated with the first node (10) characterized in that blockchain system operating under the process steps of pairing the first node (10) and at least the second node (20) in a virtual private network, sending a transaction request by the first node (10) to the paired second node (20); control of the transaction request sent to the second node (10) by a super node (60); verification of the controlled transaction request by the super node (60) with consensus validation; if the validation is acknowledged, creation of a transaction block (12) is by a block generator (70) on the second node (20) corresponding to the sent transaction request.

2- A blockchain system according to Claim 1 , wherein the transaction results of the transaction blocks are recorded in a ledger (14) within the first and at least the second node (10, 20) in a process.

3- A blockchain system according to claim 2, wherein the transaction results of the transaction blocks in the first and at least the second node (10, 20) are recorded in a ledger (140) by means of at least one smart contract (16).

4- A blockchain system according to Claim 3, wherein the transaction results of the transaction blocks (12) are recorded by at least one smart contract (16) in a chronological order in the ledger (14).

5- A blockchain system according to any of the preceding claims, wherein the super node (60) synchronizes the ledger (14) and block heights of at least one second node (20) matching the first node (10).

6- A blockchain system according to Claim 5, wherein the super node (60) detects by creating a gap information the downtime status of the any node among any node of at least the second node (20) pairing the first node (10) or missing the processing of the transaction results of the transaction blocks (12).

7- A blockchain system according to claims 5-6, wherein the super node (60) blocks the first or at least the second node (10, 20) when the gap information does not match. 8- A blockchain system according to any of the preceding claims, wherein the block generator (70) sends the transaction block (12) corresponding to the verified transaction request to each node (10, 20) in the virtual private network. 9- A blockchain system according to Claim 8, wherein the block generator (30) collects a confirmation message from each node (10, 20) regarding the sending of the transaction block (12) to each node (10, 20).