TECHNICAL FIELD

Embodiments herein relate to an apparatus and a method therein. In some aspects, they relate to triggering a transfer of data between blockchains using a smart contract. Embodiments herein also relate to a computer program and a carrier.

BACKGROUND Current systems relating to blockchains have given the world an ability to achieve more than just making a crypto transaction on a blockchain, also referred to as a blockchain network or blockchain system. 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 analyse 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

Smart contracts

A smart contract is a self-executing contract comprising program code, e.g. an Ethereum smart contract, and comprises at least one condition, e.g. terms of an agreement, e.g. between a buyer and a seller, being directly written into lines of code in the smart contract. The program code in the smart contact may be distributed over a decentralized blockchain network. The program code controls an execution of a transaction, which transaction is then trackable and irreversible, i.e. as it is performed over the blockchain network.

SUMMARY

As a part of developing embodiments herein a problem was identified by the inventors and will first be discussed. Blockchains generally use an on-chain order book for providing a way for buyers and sellers to record transactions in a blockchain network. This means that the order book is stored and maintained by the blockchain it is managing the transactions for. The problem with current on-chain order books is that the records need to be verified across the blockchain network of which it operates. Thus, any movement of data, or switch of ownership of data through transactions in the blockchain network cause an increase in traffic on the blockchain network as more transaction thus need to be verified. This increase fees in the blockchain and reduces the throughput of the blockchain network which in return makes for inefficient and complex blockchain networks. Furthermore, current blockchain systems only allows for transactions within one blockchain network, and have a limited performance, e.g. performing a low number of Transactions Per Second (TPS). Hence, blockchain networks are limited in terms of performance.

An object of embodiments herein is to improve the performance of blockchain networks.

According to an aspect of embodiments herein, the object is achieved by a method performed by an apparatus for transferring data between a first blockchain and a second blockchain in a communications network. The transferring of data is performed by using a third blockchain. The third blockchain comprises transaction information of transactions between a plurality of blockchains. The transferring of data is performed by using a triggering smart contract. The apparatus obtains a first condition for triggering a transfer of first data from the first blockchain to the second blockchain. The apparatus produces the triggering smart contract. The triggering smart contract triggers the apparatus to perform a transfer of the first data from the first blockchain to the second blockchain when the first condition is fulfilled. The apparatus provides the triggering smart contract to the third blockchain. The apparatus triggers a transfer of the first data from the first blockchain to the second blockchain. The triggering of the transfer is based on fulfilling the first condition of the triggering smart contract.

According to an aspect of embodiments herein, the object is achieved by an apparatus configured to transfer data between a first blockchain and a second blockchain in a communications network. The transferring of data is performed by using a third blockchain. The third blockchain comprises transaction information of transactions between a plurality of blockchains. The transferring of data is performed by using a triggering smart contract. The apparatus is configured to: obtain a first condition for triggering a transfer of first data from the first blockchain to the second blockchain, produce the triggering smart contract, wherein the triggering smart contract triggers the apparatus to perform a transfer of the first data from the first blockchain to the second blockchain when the first condition is fulfilled, provide the triggering smart contract to the third blockchain, and trigger a transfer of the first data from the first blockchain to the second blockchain, wherein the apparatus is configured to trigger the transfer based on fulfilling the first condition of the triggering smart contract. Since the triggering smart contract triggers the transfer of the first data from the first blockchain to the second blockchain when the first condition is fulfilled, the administrative tasks of keeping track of orders is alleviated by the smart contract. Instead of verifying the transactions on a single blockchain, this is handled by the smart contract on a third blockchain. The transfer of the first data is then triggered when the condition is fulfilled, i.e. the smart contract will cause the transaction to be performed. Thus, it is possible to achieve an interoperable blockchain network without excess verification need of order books on the first blockchain or the second blockchain. In other words, a reduced need for verification is achieved in blockchain systems, which thus reduces a load for maintaining blockchains, reduces traffic in a communication network, and thus improves performance for blockchain systems.

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

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.

A blockchain may also be referred to as a blockchain system and/or blockchain network, or merely as a chain. The terms may be used to describe the data stored and/or the network nodes involved in storing/maintaining the blockchain. The use of storing a transaction, e.g., to be verified/validated, in a blockchain may be referred to as chaining. The apparatus 101 and the remote network node 102 may maintain, e.g. manage at least partially, a set of blockchains, e.g. any one or more out of: a first blockchain 111 , a second blockchain 112, and/or a third blockchain 113. Each blockchain may comprise coins, tokens, data, and/or assets. The blockchains chains, i.e. stores, by cryptographical means, these coins, tokens, data, and/or assets by means of cryptographic hash values of the respective coins, tokens, data, and/or assets. These may be validated by other network nodes maintaining at least part of the same blockchain. In other words, similar to normal blockchain validation/verification. Any one or more blockchain in 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, e.g. the apparatus 101 or the remote network node 102. The apparatus 101 and e.g. the remote network node 102, may also maintain smart contracts, e.g. a triggering smart contract 114 e.g. produced by the apparatus 101. The triggering smart contract 114 may be stored and managed by the third blockchain 113. The apparatus may, via the triggering smart contract 114, trigger transactions of data between the first and/or second blockchain. The first blockchain 111 and the second blockchain 112 may both be any suitable blockchain network. The third blockchain 113 may be any blockchain network suitable for handling data transfers between the first blockchain 111 and the second blockchain 112. The third blockchain 113 may be a blockchain wherein transactions are verified by a machine learning mechanism, thus, the verification is automated and of much higher performance. This may be since the verification of transactions at the third blockchain 113 may be speculative due to learned behavior, e.g. of previous transactions.

The apparatus 101 may comprise, or may be connected to a hardware wallet 103. The hardware wallet 103 may be configured to handle users interacting with the apparatus 101, e.g. to initiate a transaction. The hardware wallet 103 may be a multi- currency wallet utilized in order to interact with the apparatus 101.

The apparatus 101 may comprise or may be connected to a Decision Agent Module (DAM) 104. The DAM 104 translates data between one or more blockchains 111, 112, 113, e.g. via the third blockchain 113. The DAM 104 may further identify whether or not there is a consensus on any of the blockchains 111, 112, 113, e.g. regarding a transaction. The DAM 104 translates data, and checks consensus, e.g. by first identifying transactions based on specific headers and/or tags. The DAM 104 may be a machine learning based algorithm built to differentiate packets from different blockchains and to be written into the third blockchain 113 by tagging them. The apparatus 101 may comprise or may be connected to a Relay module 104, also referred to as a relayer. The relay module may include the DAM 104, and may provide identification of the network and transaction type which is occurring

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. For example, while the triggering smart contract 114 may be produced and provided by the apparatus 101, when the triggering smart contract triggers a transfer of data, the triggering may occur on a different entity, e.g. the remote network node 102. The triggering may e.g. also occur by multiple entities concurrently. Hence, the apparatus 101 may e.g. in various embodiments be one or more devices depending on how the triggering smart contract 114 is triggered and e.g. how the blockchain networks are distributed. In other words, any of the blockchains 111, 112, 113 and may be distributed on one or more network nodes including the apparatus 101.

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 in the communications network 100. The method may use a plurality of one or more blockchains such as the first blockchain 111 , the second blockchain 112, and the third blockchain 113. The method is for transferring data between the first blockchain 111 and the second blockchain 112 in the communications network 100. The transferring of data is performed by using the third blockchain 113 and triggered by the triggering smart contract 114. The third blockchain 113 may comprise transaction information of transactions between a plurality of blockchains 111, 112, 113 and/or transactions recorded of any one or more out of the first, second and/or third blockchain 111, 112, 113. The method comprises any one or more of the following actions, which actions may be taken in any suitable order.

Action 201 The apparatus 101 obtains from the first hardware wallet 103, a first condition for triggering a transfer of first data from the first blockchain 111 to the second blockchain

112. The first hardware wallet 103 may be a secure storage medium comprising at least one cryptographic parameter, e.g. identifier or key, for proving ownership of data, e.g. which data is comprised in one or more blockchains 111, 112, 113. This may be the first data in the first blockchain 111. Obtaining the first condition may further comprise authenticating that the first data is allowed to be transferred. The first condition may be part of an order to exchange assets.

Action 202

The apparatus 101 produces the triggering smart contract 114. The triggering smart contract 114 triggers the apparatus 101 , and/or another network entity such as the remote network node 102, to perform a transfer of the first data from the first blockchain 111 to the second blockchain 112 when the first condition is fulfilled. The triggering smart contract 114 may comprise executable program code, and since the triggering smart contract 114 may be distributed in a blockchain, e.g. the third blockchain 113. Any entity, e.g. network node, that is part of managing the third blockchain 113, e.g. such as the remote network node 102, may independently or in collaboration, perform the actions triggered by the program code in the smart contract 114.

Action 203

The apparatus provides the triggering smart contract 114 to the third blockchain

113. The third blockchain 113 may be used, by the apparatus 101 and/or the remote network node 102, to verify and/or validate the triggering smart contract 114 e.g. using a machine learning mechanism, e.g. using the DAM 104. The triggering smart contract 114 may be distributed to several nodes managing the third blockchain 113, e.g. the apparatus 101 and/or the remote network node 102.

Action 204

The apparatus 101 triggers a transfer of the first data from the first blockchain 111 to the second blockchain 112. The triggering of the transfer is based on fulfilling the first condition of the triggering smart contract 114.

The following Actions 205-208 may be the optional actions performed when the triggering smart contract 114 triggers the transfer of data. Action 205

The apparatus 101 and/or the remote network node 102 obtains a first indication of the first data to be transferred from the first blockchain 111 to the second blockchain 112. The obtaining of the first indication is performed when triggering the transfer of the first data.

Action 206

The apparatus 101 and/or the remote network node 102 identifies transaction parameters of the first data. The transaction parameters may comprise a network type and/or a transaction type.

Action 207

The apparatus 101 and/or the remote network node 102 generates a first transaction comprising the first data. The first transaction is to be provided to the second blockchain 112. Generating the first transaction may be based on the first indication and/or the transaction parameters.

Action 208 The apparatus 101 and/or the remote network node 102 may provide the first transaction to the second blockchain 112. The first transaction and/or information related to the first transaction is alternatively or additionally provided to the third blockchain 113.

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

Embodiments herein may relate to improving actions related to Decentralized Exchanges (DEX).

Embodiments herein, may provide users the ability to carry out cross chain assets trading and using an interoperable DEX by utilizing its on-chain assets where assets may be interchangeable with other blockchains. In other words, in embodiments herein, it is possible to efficiently move data between blockchains.

In some embodiments herein, a DEX, is built on the application layer of an aphelion protocol, i.e. a machine learning based blockchain protocol where transactions may be validated and/or verified using an artificial intelligence instead of always having to first validate a transaction by a plurality of nodes in a blockchain network. Embodiments herein may use a smart contract technology where users are able to trade their assets not only on aphelion based blockchains, but also across other blockchains.

Some embodiments herein operate by using smart contracts, e.g. the triggering smart contract 114, where the on-chain order book is instead maintained using smart contracts, e.g. the triggering smart contract 114. An order of how and when to perform a transaction may then be triggered and/or performed by the triggering smart contract 114. The problem with current on chain order book models in the market is that the records need to be verified across the nodes in a blockchain network which in return increases the fees on the platform. This also reduces the throughput of the network which in return makes the system inefficient and induces complex platforms. The other problem is current solutions are not interoperable and have very low TPS. In contrast, embodiments herein are completely different from the present systems by being fully interoperable, e.g. embodiments herein provide a way to transfer data between blockchains, in a scalable manner. This is since verification may at least partially be performed by a machine learning algorithm and may be performed on a separate blockchain network, e.g. the third blockchain network 113, thus reducing traffic on the first and/or second blockchain networks 111, 112. The mechanism of embodiments herein may relate to users connecting through their hardware wallet, e.g. the hardware wallet 103, with a DEX, e.g. the apparatus 101, and may carry out trade with all the available assets. This works since the order book functionality is written within smart contracts, e.g. the triggering smart contract 114. In this way, users do not lose access to their assets and always are in control and the trade occurs directly between the two intermediary parties, i.e. as they may affect what is stated in the first condition, e.g. as obtained in actions above. Using the aphelion application layer, e.g. using the third blockchain 113, the smart contract is able to communicate with the other blockchains, e.g. the first and/or second blockchain 111, 112, which are linked. This is since embodiments herein may connect the first blockchain 111 and the second blockchain 112 via the third blockchain 113, wherein transactions over the third blockchain 113 may at least partially be verified using a machine learning mechanism.

Embodiments herein may relate to a relayer mechanism, e.g. performed by the relay module 105. The relayer mechanism in embodiments herein performed identification of the network and transaction type which is occurring. The relayer allows the packets to be transferred in between the two different blockchains, e.g. the first and second blockchains 111, 112, and by keeping a record of cross chain transactions on the third blockchain 113 provides a complete transparency. The relayer may use a packet identification mechanism which allows data to be easily traded between different blockchains.

The relay module 105 may comprise the DAM 104 which is a machine learning based algorithm built to differentiate packets from different blockchains and to be written into the third blockchain 113, e.g. an aphelion chain, by tagging them. The DAM 104 use a prediction module for allowing nodes to virtually vote in order to verify the output of the agent and the data which is to be written on the blockchain. This may be a machine learning mechanism, e.g. the machine learning mechanism discussed above.

The DAM 104 may include the ability to translate the data between different blockchains. Any transaction to/from a blockchain network 111, 112, 113 is structured and written into the respective chain.

The smart contract interoperability is also facilitated by the above mechanism. In other words, the triggering smart contract 114 may be distributed in one or more blockchains. The smart contract interoperability may be necessary because in some embodiments, the cross chain transactions may happen between tokens or between token and crypto. Hence, some embodiments herein may allow for a transfer of data to happen in a cross-chain contract manner and help the network, e.g. any blockchain 111, 112, 113, to gain liquidity by utilizing cross-chain liquidity providers.

In some embodiments herein, the hardware wallet 103 may is already enriched with the ability to store data of other blockchains. The hardware wallet 103 may be a multi- currency wallet utilized in order to interact with embodiments herein to allow for multi- blockchain assets to be stored directly on one or more blockchains described herein, e.g. the third blockchain 113.

Embodiments herein may be carried out for asset exchange, e.g. data transfer, in a cross-chain manner. This may be to allow the asset exchange between all the blockchains built on aphelion protocol, e.g. machine learning based and/or interoperable blockchains, as well.

Embodiments herein may include the tokens built using smart contracts as well.

This is since each blockchain may be injected with a DAM module, e.g. the DAM 104, which may allow for the identification of the blockchain consensus, e.g. using a machine learning mechanism.

The transactions on aphelion based chains, e.g. the third blockchain 113, may not need to follow up through a process of relayer restructuring as the packets may be the same or similar. The transactions of such blockchains related to smart contracts may be directly identifiable using the packet headers and tags by DAM, e.g. the DAM 104. This enables embodiments herein to operate with maximum throughput, e.g. as smart contracts such as the triggering smart contract 114 is easily identifiable. Embodiments herein may further already be integrated with a development kit, e.g. Cusp Standard Development Kit (SDK), which automatically lists new assets, and/or developers may upgrade the lists as well. Using the SDK, embodiments herein are adaptable to communicate with custom injected own liquidity providers as well.

A liquidity provider as used herein may be any entity depositing tokens into a smart contract and receiving pool tokens in return. I.e. these may be part of managing the smart contracts and may be part of performing the methods triggered by smart contract, e.g. the triggering smart contract 114. The pool tokens may e.g. track the liquidity provider's share of the total reserves and may e.g. be traded in for an underlying asset.

To perform the method actions above, the apparatus 101 is configured to perform any one or more of the above actions 201-208. The apparatus 101 is configured to transfer data between a first blockchain 111 and a second blockchain 112 in a communications network 100, wherein the transfer of data is performed by using the third blockchain 113 and triggered by the triggering smart contract 114, e.g. wherein the third blockchain 113 comprises transaction information of transactions between a plurality of blockchains 111, 112, 113. 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 receiver (not shown) and a wireless transmitter (not shown).

The apparatus 101 may further be configured to, e.g. by means of an obtaining unit 301 in the apparatus 101, obtain, e.g. from a first hardware wallet 103, a first condition for triggering a transfer of first data from the first blockchain 111 to the second blockchain 112, e.g. wherein the first hardware wallet 103 is a secure storage medium comprising at least one cryptographic parameter, e.g. identifier or key, for proving ownership of data, e.g. which data is comprised in one or more blockchains 111, 112,

113, e.g. the first data in the first blockchain 111, and e.g. wherein the apparatus 101 is configured to obtain the first condition by further authenticating that the first data is allowed to be transferred.

The apparatus 101 may further be configured to, e.g. by means of the obtaining unit

301 in the apparatus 101 , obtain a first indication of the first data to be transferred from a first blockchain 111 to the second blockchain 112, e.g. wherein the apparatus 101 is configured to obtain the first indication is performed when triggering the transfer of the first data.

The apparatus 101 may further be configured to, e.g. by means of a producing unit

302 in the apparatus 101, produce the triggering smart contract 114, wherein the triggering smart contract 114 triggers the apparatus 101 to perform a transfer of the first data from the first blockchain 111 to the second blockchain 112 when the first condition is fulfilled.

The apparatus 101 may further be configured to, e.g. by means of a providing unit

303 in the apparatus 101, provide the triggering smart contract 114 to the third blockchain 113.

The apparatus 101 may further be configured to, e.g. by means of the providing unit

303 in the apparatus 101, provide the first transaction to the second blockchain 112, e.g. wherein the first transaction and/or information related to the first transaction is alternatively or additionally provided to the third blockchain 113.

The apparatus 101 may further be configured to, e.g. by means of a triggering unit

304 in the apparatus 101 , trigger a transfer of the first data from the first blockchain 111 to the second blockchain 112, wherein the apparatus 101 is configured to trigger the transfer based on fulfilling the first condition of the triggering smart contract 114.

The apparatus 101 may further be configured to, e.g. by means of an identifying unit 305 in the apparatus 101, identify transaction parameters of the first data, e.g. wherein the transaction parameters comprise a network type and/or a transaction type.

The apparatus 101 may further be configured to, e.g. by means of a generating unit 306 in the apparatus 101, generate a first transaction comprising the first data, e.g. wherein the first transaction is to be provided the second blockchain 112, e.g. wherein the apparatus 101 is configured to generate the first transaction based on the first indication and/or the transaction parameters.

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.