WO2022240352A1

WO2022240352A1 - Method and apparatus for handling policies in a communications network using blockchains

Info

Publication number: WO2022240352A1
Application number: PCT/SE2022/050474
Authority: WO
Inventors: Fredrik Johansson
Original assignee: Rz Capital Holding Ab
Priority date: 2021-05-14
Filing date: 2022-05-16
Publication date: 2022-11-17

Abstract

A method performed by an apparatus for handling one or more policies in a communication network is provided. The apparatus maintains a first policy related to a first blockchain. The apparatus communicates (201) a first updated policy, wherein the first updated policy relates to the first blockchain. The first updated policy is communicated using a second blockchain. Based on the first updated policy, the apparatus determines (202) whether or not to adjust the first blockchain and/or the first policy. The apparatus adjusts (203) the first blockchain and/or the first policy based at least partially on the first updated policy.

Description

METHOD AND APPARATUS FOR HANDLING POLICIES IN A COMMUNICATIONS NETWORK USING BLOCKCHAINS

TECHNICAL FIELD

Embodiments herein relate to an apparatus and a method therein. In some aspects, they relate to handling one or more policies in a communication network.

BACKGROUND

Current systems relating to blockchains have given the world an ability to achieve more than just making a crypto transaction on a blockchain. Although each system provides its unique features, they face issues in many aspects of the real-world scenarios. Some aspects of blockchain systems will now be described.

Consensus algorithms In recent times, an immense amount of research has been conducted in distributed data recording, peer-to-peer transmission, consensus mechanism, encryption algorithm and other computer technologies. SHA256 algorithm was proposed by Guilford J.D which is employed in the blockchain. The original exchange of any length recorded is computed twice by SHA256 algorithm so that it can acquire the hash value and the hash value’s length is 256. One of the many hashing applications is the Merkle tree and proof of work (POW). The Merkle tree has a structure of a tree, where every leaf node has a hash value and a non-leaf node carries its child node’s hash value. It stores transaction information and generates digital signatures. It increases the scalability and improves efficiency of the blockchain. It can verify data without extracting the complete blockchain network node. Timestamp was introduced to record the time of block data to solve the problem of “double spending”, making it possible for data to reconstruct the history. In addition to proof of existence, timestamp ensures that the database is not manipulated and saves from fraudulent activity. In peer-to-peer technology there is no central node or existence of any hierarchy structure, every node on the network has equal status. Each node will undertake the network routing, data validation and data transmission. To secure data transmission and allow ownership verification, blockchain uses the asymmetric encryption algorithm called Elliptic Curve Cryptography (ECC), with each user having a pair of keys, one public and one private. Users sign the transaction information with ECC, meanwhile, other users can verify the signature with the public key of the signed user. Furthermore, the public key is also used to identify different users and construct their Bitcoin addresses.

Proof-of-Work (POW)

PoW is a cryptographic puzzle first presented by C.Dwork and M.Noar. The foundation for it was set to prevent spams and curb the denial of service attacks. Satoshi Nakamoto was amongst the first to adopt this system in the Bitcoin system. Further, a hybrid protocol was presented by Bentov et al, that relied on PoW and Proof of Stake (POS) protocols and combined both of their advantages, establishing an element more superior. Ateniese et al proposed an alternative to PoW that is Proof of Space, which specified the amount of memory rather relied on memory access as in PoW. Arthur Gervais et al introduced “a novel quantitative framework to analyze the security and performance implications of various consensus and network parameters of PoW blockchains” by Gervais et al., 2016. They devised optimal adversarial strategies to affect double-spending and selfish mining taking into account real-world constraints and attacks. Alex Biryukov et al introduced Equihash that “an asymmetric proof-of-work with tunable parameters”, it is a “PoW based on the generalized birthday problem and enhanced Wagner’s algorithm for it” (Biryukov et al., 2017).

Proof-of-Stake (POS)

Peercoin first time used Proof of Stake in 2012. PoS generally means proof of ownership of the currency. PoS does not have mining so it does not utilize computing power, like PoW. It solves the energy problem in the current blockchain system such as Bitcoin and Ethereum. The nodes possess a certain amount of stake, that is the currency, in a blockchain. The higher the stake of the party the more likely it is to release a new block and become the leader. A reward is also issued in PoS protocol just like it is issued in PoW. PoS is a more cost-effective method and saves energy. However, there is a problem of monopoly in PoS, which is unfair for many participants. Yuefei Gao et al proposed Proof of Stake sharding protocol to increase scalability. Fahad Saleh introduced the ‘first formal economic model’ of PoS and explained how the consensus works under it (Saleh, 2018).

Delegated Proof-of-Stake (DPOS)

DPOS is a relatively new consensus algorithm that is better than energy inefficient and poorly protected PoW and PoS. It ensures the representation of transactions within a blockchain. DPOS is a fast, outstanding and advantageous consensus algorithm model.

To solve the consensus problem, DPOS uses voting and elections, which is fairer and saves computing power. Every holder of the stake can vote, fulfilling a certain number of representatives and all have equal rights. To maintain the ‘long-term purity’ representatives can be changed by holders at any time. Its main advantage is that it saves computation energy and is more cost-effective than PoW and PoS. DPOS removes the biases caused by PoS with equity and decentralizes the decision making on the network.

Practical Byzantine Fault Tolerance (PBFT)

The Practical Byzantine Fault Tolerance (PBFT) is an algorithm that can tolerate Byzantine faults caused by the Byzantine General Problem. Miguel Castro and Barbara Liskov first introduced it in their paper, solving the problem caused by faulty nodes’ low efficiency. PBFT is based on message authentication codes that go through three-phase protocols and automatically cast the replicas if failure occurs. It depends on three-phase messages before to execute operations. PBFT consensus is highly efficient and enables high-frequency exchanging. All the nodes in the network are identified and all the faulty nodes are restricted in the network. The requirements set for this consensus algorithm is challenging to apply it to public blockchain Also, the great amount of calculations required for this consensus protocol made it impossible to employ.

Blockchain Applications Side Chains Side-chains are a new and innovative addition to the Bitcoin protocol which develops a connection between the main Bitcoin chain and an additional side-chain. The interaction will let the side-chains transfer each other’s assets with two-way peg. The vision for this framework is to increase the functionality and enhance capabilities through pegging with some other chains for the Bitcoin currency. This allows more extensibility that the Bitcoin system usually allows. Fundamentally, the validity of side-chains does not depend on provisions, the tokens of one chain are only secured by side-chain when it provides its miners' incentives to convert the data that can be represented by standard approved format. The security of the Bitcoin network cannot be easily changed for other blockchains. Furthermore, it is impossible and unfeasible to merge-mines of Bitcoin miners with side-chains. Cosmos is another innovation that allows trust-free communication between multiple chains to take place. It has deployed the Nakamoto PoW consensus method for Jae Kwon’s Tendermint algorithm leading to interchain communication. Essentially, it connects heterogeneous chains called zones with a master chain called Hub. This interchain communication is restricted only to the transfer of digital assets and not random information. Interchain communication allows a return path for data, e.g. to verify and validate the status of transfer from the sender. One of the significant unsolved problems is defining validator sets for the zoned chains and stimulating them like side-chains. The common assumption is that each zone holds a token of a certain value and pays them with it. The early stages of the design still lack thorough details to achieve scalability over validity. However, the lack of coherence between the zones and the hub can be beneficial as it can lead to additional flexibility over the zoned chains compared to a system with strong connections

SUMMARY

As a part of developing embodiments herein a problem was identified by the inventors and will first be discussed.

When updating blockchain assets, it may in some scenarios be necessary to generate updated distinct policies for a particular blockchain. A policy as used herein may be a public key, an address, and/or standards for key generations and/or address generations for that particular blockchain. This may be to further use the generated key and/or address etc. e.g., to enable communication with one or more blockchains, e.g. such as to send transactions to and/or from the respective one or more blockchains. A problem arises as every entity participating in a first blockchain may need to update its policies in order to be able to communicate with one or more blockchains, e.g. the first blockchain and/or one or more other blockchains. Policies, e.g. keys and/or address generation standards, may be controlled by a centralized system node.

An object of embodiments herein is to improve the performance and security of blockchain systems.

According to an aspect of embodiments herein, the object is achieved by a method performed by an apparatus. The method may be for handling one or more policies. The method may use a plurality of blockchains or distributed ledgers. The method is performed in a communication network. The apparatus maintains a first policy related to a first blockchain. The apparatus communicates a first updated policy. The first updated policy relates to the first blockchain. The first updated policy is communicated using a second blockchain. The apparatus, based on the first updated policy, determines whether or not to adjust the first blockchain and/or the first policy. The apparatus adjusts the first blockchain and/or the first policy based at least partially on the first updated policy.

According to another aspect of embodiments herein, the object is achieved by an apparatus configured to handle one or more policies in a communication network. The apparatus is adapted to maintain a first policy related to a first blockchain. The apparatus is configured to:

- communicate a first updated policy, wherein the first updated policy is adapted to relate to the first blockchain, and wherein the first updated policy is arranged to be communicated using a second blockchain,

- based on the first updated policy, determine whether or not to adjust the first blockchain and/or the first policy, and

- adjust the first blockchain and/or the first policy based at least partially on the first updated policy.

By communicating a first updated policy using a second blockchain, the apparatus is enabled to, based on the first updated policy, to determine whether or not policies related to the first blockchain and/or the first policy need to be updated, and then adjust the first blockchain and/or the first blockchain accordingly such that communication to, from, and/or using the first blockchain is enabled. In other words, an efficient way to distribute and update policies in distributed nodes in a distributed network maintaining one or more blockchains is achieved.

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments herein are described in more detail with reference to attached drawings in which:

Figure 1 is schematic block diagram illustrating a communications network herein.

Figure 2 is a flowchart depicting an embodiment of a method herein.

Figure 3a-b are schematic block diagrams illustrating embodiments of an apparatus herein.

DETAILED DESCRIPTION To improve to improve the performance and security of blockchain systems, embodiments herein refer to a Libonomy system or Libonomy network, which may be implemented, at least partially by an apparatus 101.

Figure 1 illustrates a communications network 100. The communications network

100 may comprise an apparatus 101 and a remote network node 102.

In some embodiments the apparatus 101 may be any one out of or comprise any one or more out of: a computing device, a network node, a blockchain system, and a distributed system, e.g. comprising a first one or more network nodes and/or a second one or more network nodes. In some embodiments the remote network node 102 may be any one out of or comprise any one or more out of: a computing device and a network node. The apparatus 101 and the remote network node 102 may maintain, e.g. manage, at least partially a set of blockchains, e.g. a first blockchain and/or a second blockchain. Each blockchain may comprise coins, tokens, data, and/or assets. The blockchains chain these coins, tokens, data, and/or assets by means of cryptographic hash values of the respective coins, tokens, data, and/or assets, e.g. validated by other nodes maintaining at least part of the same blockchain. The set of blockchains may also be maintained by a system node, e.g. the system node being a computing device or a network node.

Methods herein may be performed in the communications network 100, e.g. a wired or wireless communication network. Methods herein may be performed by the apparatus

101 and/or the remote network node 102. As an alternative, a Distributed Node (DN) and functionality, e.g. comprised in a cloud, may be used for performing or partly performing the methods herein. Additionally or alternatively, methods herein may further be performed by any of the one or more network nodes, e.g. collectively as a system.

A number of embodiments will now be described, some of which may be seen as alternatives, while some may be used in combination.

Figure 2 shows example embodiments of a method performed by the apparatus 101. The method may be for handling one or more policies, e.g. security policies. The method may use plurality of distributed ledgers, such as one or more blockchains, e.g., the first blockchain and/or the second blockchain. The method may be performed in the communication network 100. The apparatus 101 maintains a first policy related to the first blockchain, e.g. a first distributed ledger. The first policy may be any one of a security policy and/or a blockchain policy. The first policy may relate to any rules that need to be distributed within the communication network 100 e.g. for operating one or more blockchains, such as the first blockchain and/or the second blockchain. I.e. the first policy may for example at least partially define how to communicate in the first blockchain.

The method comprises the following actions, which actions may be taken in any suitable order.

Action 201

The apparatus 101 communicates a first updated policy, e.g. a first updated security policy, e.g. with the remote network node 102. Communicating the first updated policy may relate to receiving the first updated policy from the remote network node 102 and/or transmitting the first updated policy to the remote network node 102. The first updated policy may be a policy relating to the first blockchain. In other words, the first updated policy may indicate how to at least partially communicate in the first blockchain. The first updated policy may be communicated using the second blockchain, e.g. the second distributed ledger. In other words, the second blockchain may be used to send update information for the first blockchain. This may e.g. relate to storing key-pairs, updating system rules, and/or a list of supported blockchains, e.g. the blockchains in the set of blockchains such as the first and/or the second blockchain, and the coins, tokens, data, and/or assets present on that chain.

Action 202

Based on the first updated policy, the apparatus 101 determines whether or not to adjust the first blockchain and/or the first policy.

Action 203

The apparatus 101 adjusts the first blockchain and/or the first policy based at least partially on the first updated policy, e.g. by adding a key related to the first blockchain.

The above embodiments will now be further explained and exemplified below. The embodiments below may be combined with any suitable embodiment above.

Multi-Currency Wallet

Embodiments herein illustrates an interoperability and cross platform transaction through Libonomy, e.g. using a multi-currency wallet, e.g. using one more blockchains. Using a multi-currency wallet, e.g. in the apparatus 101, allows for holding and interacting with any one or more blockchains, e.g. the set of blockchains such as the first blockchain and/or second blockchain, in the communication network 100.

In order to allow the wallet compatibility with other blockchains, e.g. with all the blockchains in the set of blockchains, a Libonomy node, e.g. the apparatus 101 and/or the remote network node 102, may be configured to interact with other blockchains using an on-chain mechanism, e.g. instead of utilizing a centralized server mechanism used by prior art. In other words, a blockchain, e.g. the first and/or the second blockchain may be used to send transactions among different blockchains.

The on-chain mechanism may be a mechanism wherein e.g. the apparatus 101 and/or the remote network node 102, may use an already created seed phrase and/or generated public addresses against, e.g. for communicating with, each blockchain.

In order to add other blockchain assets, e.g. the apparatus 101 and/or the remote network node 102, may thus only need to generate a public key for that blockchain, use the generated address to send transactions from the respective chain. This may be part of the first policy and/or first updated policy.

The address generation standards may be updated in an automated manner and on each upgrade of the system. In some embodiments, this need to be done as each blockchain in the set of blockchains may have different standards for key generation.

Hence, in order to solve the issue of whether to update the software on each standard inclusion, Libonomy key generation standards are controlled by a system node, e.g. the apparatus 101 and/or the remote network node 102.

Each side chain linking, e.g. on a protocol used by a blockchain in the set of blockchains, e.g. by the apparatus 101, may update the whole communication network 100, e.g. network nodes, e.g. the apparatus 101 and/or the remote network node 102 maintaining at least part of any of the blockchains in the set of blockchains, e.g. first and/or second blockchain, where nodes may be configured to upgrade, e.g. either themselves or manually as soon as the protocol policies are upgraded. The first policy and/or the first updated policy is not restricted to a blockchain specific rules but may include the other system rules as well. On upgrade e.g. the apparatus 101 and/or the remote network node 102, is included with the key-pair standards if there are any. Upgrading may relate to adjusting a blockchain and/or policy, e.g. as in action 203 above. In some embodiments, this relates to updating the apparatus 101 , a list of supported chains and any one or more of the coins/tokens/data/assets present on that chain.

The apparatus 101, e.g. a client side of apparatus 101, may have an interlacing module which is utilized to generate key pairs according to the related standards. In order to ensure security of user keys and/or to verify whether a node, e.g. the apparatus 101 and/or the remote network node 102 has been compromised or not, a checksum, e.g. a cryptographic hash, is provided, e.g. for each or some data on a blockchain, on the client. A node and network, e.g. at least partially based on the apparatus 101 and/or the remote network node 102, may provide the verification of the version, e.g. by means of any consensus algorithm.

One or more private keys of users may only be kept on his own system, e.g. the apparatus 101, and may only be utilized when the user has passed through 2-level decryption. This may be since encrypted files may be stored on a blockchain and may then be secured by means of the blockchain itself. The only thing a user, e.g. the apparatus 101, may need to do is to choose, e.g. select, a coin, decrypt an associated key, generate public keys and send assets from a respective chain wallet.

Embodiments herein may provide at least 6000 Transactions Per Second (TPS). Due to this speed, users of the apparatus 101, do not need to wait for the other chain’s transaction to be mined, e.g. verified, before it appears on the Libonomy software, e.g. becomes available to the apparatus 101 , e.g. by means of the first and/or second blockchain.

This may be performed since embodiments herein may already include each compatible blockchain’s node running in its core among the whole network so users don't have to wait extra for the transaction to be received in their wallet. In other words, the first and second blockchain are utilized collectively, e.g. when adjusting policies, and hence, the adjustments may be of higher performance. As soon as a transaction is accepted on a blockchain, e.g. the first and/or second blockchain, users, e.g. the apparatus 101, may receive this at directly on the software, e.g. by means of the first and/or second blockchain.

As embodiments herein may be realized by software, e.g. using a decentralized application, the system, e.g. the apparatus 101 and/or the remote network node 102, may utilize a gossip cluster mechanism, e.g. where there are multiple blockchain clusters running under the core and they update each other on each second. A gossip mechanism as used herein may be a way to distribute messages in a network, e.g. by means of replicating messages to synchronize knowledge in the communication network 100.

The selection of the nodes to update using a gossip mechanism may be performed by a protocol, e.g. using artificial intelligence, statistics and/or machine learning to decide how to best propagate the information in the network e.g. the communication network 100. This may be decided based on network node performance.

Nodes in the network, e.g. the apparatus 101, may thus transmit the data on their performance and region basis. Furthermore, a heart-beat mechanism may be utilized to check for a node’s, e.g. the apparatus 101, presence and to provide signals whether the node has received any kind of transaction or not. A heartbeat mechanism may relate to a regular, e.g. periodic, communication pattern.

To perform the method actions above, the apparatus 101 may be e.g. configured to perform any one or more of the above actions 201-204.

The apparatus 101 may comprise an arrangement depicted in Figures 3a and 3b.

The apparatus 101 may comprise an input and output interface 300 configured to communicate with network nodes e.g. in blockchain systems. The input and output interface 300 may comprise a wireless and/or wired receiver not shown and a wireless and/or wired transmitter not shown.

The apparatus 101 is further configured to, e.g. by means of a communicating unit 320 in the apparatus 101, communicate, e.g. receive from the remote network node 102 and/or transmit to the remote network node 102, a first updated policy, e.g. a first updated security policy, wherein the first updated policy is adapted to relate to the first blockchain, and wherein the first updated policy is arranged to be communicated using a second blockchain, e.g. a second distributed ledger. The apparatus 101 is further configured to, e.g. by means of a determining unit 310 in the apparatus 101 , based on the first updated policy, determine whether or not to adjust the first blockchain and/or the first policy.

The apparatus 101 is further configured to, e.g. by means of an adjusting unit 330 in the apparatus 101 , adjust the first blockchain and/or the first policy based at least partially on the first updated policy, e.g. by adding a key related to the first blockchain.

The embodiments herein may be implemented through a respective processor or one or more processors, such as the processor 360 of a processing circuitry in the apparatus 101 depicted in Figure 3a, together with respective computer program code for performing the functions and actions of the embodiments herein. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the apparatus 101. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the apparatus 101.

The apparatus 101 may further comprise a memory 370 comprising one or more memory units. The memory 370 comprises instructions executable by the processor in apparatus 101. The memory 370 may be arranged to be used to store e.g. information, indications, data, configurations, and applications to perform the methods herein when being executed in the apparatus 101.

In some embodiments, a computer program 380 comprises instructions, which when executed by the respective at least one processor 360, cause the at least one processor of the apparatus 101 to perform the actions above.

In some embodiments, a respective carrier 390 comprises the respective computer program 380, wherein the carrier 390 may be one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium. Those skilled in the art will appreciate that the units in the apparatus 101 described above may refer to a combination of analog and digital circuits, and/or one or more processors configured with software and/or firmware, e.g. stored in the apparatus 101, that when executed by the respective one or more processors such as the processors described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuitry (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a system-on-a-chip (SoC). When using the word "comprise" or “comprising” it shall be interpreted as non limiting, i.e. meaning "consist at least of".

The embodiments herein are not limited to the above described preferred embodiments. Various alternatives, modifications and equivalents may be used.

Claims

1. A method performed by an apparatus (101) for handling one or more policies in a communication network (100), wherein the apparatus (101) maintains a first policy related to a first blockchain, the method comprises: communicating (201) a first updated policy, wherein the first updated policy relates to the first blockchain, and wherein the first updated policy is communicated using a second blockchain, based on the first updated policy, determining (202) whether or not to adjust the first blockchain and/or the first policy, and adjusting (203) the first blockchain and/or the first policy based at least partially on the first updated policy.

2. The method according to claim 1 wherein the apparatus (101) is represented by any one out of: a computing device, a network node, a blockchain system, and a distributed system comprising one or more network nodes in the communication network (100).

3. A computer program (380) comprising instructions, which when executed by a processor (360), causes the processor (360) to perform actions according to any of the claims 1-2.

4. A carrier (390) comprising the computer program (380) of claim 3, wherein the carrier (390) is one of an electronic signal, an optical signal, an electromagnetic signal, a magnetic signal, an electric signal, a radio signal, a microwave signal, or a computer-readable storage medium.

5. An apparatus (101) configured to handle one or more policies in a communication network (100), wherein the apparatus (101) is adapted to maintain a first policy related to a first blockchain, the apparatus (101) being configured to: communicate a first updated policy, wherein the first updated policy is adapted to relate to the first blockchain, and wherein the first updated policy is arranged to be communicated using a second blockchain, based on the first updated policy, determine whether or not to adjust the first blockchain and/or the first policy, and adjust the first blockchain and/or the first policy based at least partially on the first updated policy.