Methods, system, dapps and node for enabling storage of a file on one or more blockchains

Abstract

Methods, dapps and nodes for managing a file are disclosed. A service node (120) receives (B210) the file. A file dapp (110) allocates (B150) the file by including an allocate file request, including a filehash of the file, as a transaction, on a "hubchain" of the file dapp (110). In response, the service node (120) splits the file into a plurality of chunks. The service node (120) sends (C210), to the file dapp (110), an allocate chunk request, comprising the filehash, and a respective chunkhash of each chunk. The file dapp (110) sends (C118), to the service node (120), a response indicating that the file dapp (110) has obtained the chunk dapp (140). The service node (120) sends (C232) said each chunk and a proof to the chunk dapp (140). On success, the chunk dapp (140) stores (C460) said each chunk in a block of a blockchain managed by the chunk dapp (140).

Description

[0001] METHODS, SYSTEM, DAPPS AND NODE FOR ENABLING

[0002] STORAGE OF A FILE ON ONE OR MORE BLOCKCHAINS

[0003] TECHNICAL FIELD

[0004] The embodiments herein relate to applications of blockchain technology for storing data, such as files, documents, images, video, or the like, in a decentralized manner. In particular, the embodiments herein relate to methods and dapps, or nodes, for storing of data, e.g. without file size restrictions, on blockchains.

[0005] BACKGROUND

[0006] The field of digital file storage and management is crucial in our increasingly digital world, where vast amounts of data are generated daily. Existing solutions often face several challenges, primarily due to their reliance on centralized systems. Centralized file storage systems, while historically effective, are increasingly showing their limitations in the face of modern data demands.

[0007] One of the primary challenges with centralized systems is scalability. As the volume of data grows exponentially, centralized systems struggle to scale efficiently. Adding more storage capacity or increasing processing power can be both costly and complex, often requiring significant infrastructure changes. This can lead to bottlenecks where the system cannot handle the influx of data, resulting in slower performance and increased latency.

[0008] Another significant issue with centralized systems is the single point of failure. In a centralized storage architecture, all data flows through a single hub. If this central hub fails, due to hardware malfunction, cyber-attacks, or even natural disasters, the entire system can become inaccessible. This creates a significant risk for data loss and downtime, which can be detrimental to businesses and organizations that rely heavily on continuous data availability.

[0009] Centralized systems also offer limited flexibility in data storage management. These systems often come with predefined storage structures and protocols that may not suit the diverse requirements of various application. For instance, some applications can require high-speed access to frequently used files, while others might prioritize long-term archival of large datasets, e.g. with low risk of data loss. Centralized systems typically offer a one-size-fits-all solution, which can lead to inefficiencies and / or higher costs when used in connection with applications with specific requirements.

[0010] In response to these challenges, distributed storage solutions are gaining popularity.

[0011] Some known distributed storage solutions exist. However, security may be a concern, since the entire distributed storage solution may still be controlled and managed by one and the same provider, such as a company, or the like.

[0012] Therefore, there is a need for a more flexible storage solution that is capable of overcoming one or more of the shortcomings mentioned above.

[0013] SUMMARY

[0014] An object may thus be to overcome, or at least reduce, at least one of shortcoming, disadvantage, or problem of the known solutions, or at least present an alternative solution.

[0015] According to an aspect, the object is achieved by a method, performed by a system, for storing a file. The system includes a chain managing decentralized application, referred to as "platform dapp", a file managing decentralized application, referred to as "file dapp", a service node, at least one chunk storing decentralized application, referred to as "chunk dapp". The platform dapp manages the file dapp and the chunk dapp. The chunk dapp is registered with the file dapp. The system receives, by the service node, the file. The system generates, by the service node, a filehash based on the file. The system sends, by the service node to the file dapp, an allocate file request comprising the filehash. The system allocates, by the file dapp, the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp. The system sends, by the file dapp to the service node, an allocate file response indicating that the file is allowed to be stored. The system splits, by the service node, the file into a plurality of chunks, repeatedly performing a set of actions for each chunk of the plurality of chunks. The set of actions comprises that the system sends, by the service node to the file dapp, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on said each chunk. The system obtains, by the file dapp, a location for the chunk dapp to store said each chunk. The system saves, by the file dapp and on the hubchain, a respective record, comprising the respective chunkhash and the location.

[0016] The system sends, by the file dapp to the service node, an allocate chunk response indicating that the file dapp has obtained the chunk dapp for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp. The system sends, by the service node, a proof request, to the file dapp. The proof request comprises the respective chunkhash.

[0017] The system generates, by the platform dapp, a proof indicating that a transaction has occurred on the hubchain. The transaction confirms that the chunk dapp, indicated by the location, has been selected for storage of said each chunk.

[0018] The system sends, by the file dapp, the proof to the service node. The system sends, by the service node, said each chunk and the proof to the chunk dapp. The system checks, by the chunk dapp, that the proof is valid. The system decodes, by the chunk dapp, the proof to obtain a respective decoded chunkhash and a decoded identity, e.g. related to a particular chunk dapp for which the proof applies. The system determines, by the chunk dapp, that a current chunkhash, generated, e.g. by the chunk dapp, based on said each chunk to be stored, matches the respective decoded chunkhash. The system determines, by the chunk dapp, that the related decoded identity matches an identity of the chunk dapp, the identity being known to the chunk dapp. The system stores, by the chunk dapp, said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp.

[0019] According to another aspect, the object is achieved by a system configured for storing a file. The system includes a chain managing decentralized application, referred to as "platform dapp", a file managing decentralized application, referred to as "file dapp", a service node, at least one chunk storing decentralized application, referred to as "chunk dapp". The platform dapp manages the file dapp and the chunk dapp. The chunk dapp is registered with the file dapp. The system is configured for receiving, by the service node, the file. The system is configured for generating, by the service node, a filehash based on the file. The system is configured for sending, by the service node to the file dapp, an allocate file request comprising the filehash. The system is configured for allocating, by the file dapp, the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp. The system is configured for sending, by the file dapp to the service node, an allocate file response indicating that the file is allowed to be stored. The system is configured for splitting, by the service node, the file into a plurality of chunks, repeatedly performing a set of actions for each chunk of the plurality of chunks. The set of actions comprises that the system is configured for sending, by the service node to the file dapp, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on said each chunk. The system is configured for obtaining, by the file dapp, a location for the chunk dapp to store said each chunk.

[0020] The system is configured for saving, by the file dapp and on the hubchain, a respective record, comprising the respective chunkhash and the location. The system is configured for sending, by the file dapp to the service node, an allocate chunk response indicating that the file dapp has obtained the chunk dapp for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp. The system is configured for sending, by the service node, a proof request, to the file dapp. The proof request comprises the respective chunkhash.

[0021] The system is configured for generating, by the platform dapp, a proof indicating that a transaction has occurred on the hubchain. The transaction confirms that the chunk dapp, indicated by the location, has been selected for storage of said each chunk. The system is configured for sending, by the file dapp, the proof to the service node. The system is configured for sending, by the service node, said each chunk and the proof to the chunk dapp. The system is configured for checking, by the chunk dapp, that the proof is valid. The system is configured for decoding, by the chunk dapp, the proof to obtain a respective decoded chunkhash and a decoded identity, e.g. related to a particular chunk dapp for which the proof applies. The system is configured for determining, by the chunk dapp, that a current chunkhash, generated, e.g. by the chunk dapp, based on said each chunk to be stored, matches the respective decoded chunkhash.

[0022] The system is configured for determining, by the chunk dapp, that the related decoded identity matches an identity of the chunk dapp, the identity being known to the chunk dapp. The system is configured for storing, by the chunk dapp, said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp.

[0023] According to a further aspect, the object is achieved by a method, performed by a file managing decentralized application, referred to as "file dapp", for managing storing of one or more chunks representing a file. A system includes a chain managing decentralized application, referred to as "platform dapp", the file dapp, a service node, at least one chunk storing decentralized application, referred to as "chunk dapp". The platform dapp manages the file dapp and the chunk dapp. The chunk dapp is registered with the file dapp.

[0024] The file managing decentralized application receives, from the service node, an allocate file request comprising the filehash. The file managing decentralized application allocates the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp. The file managing decentralized application sends, to the service node, an allocate file response indicating that the file is allowed to be stored.

[0025] The file managing decentralized application receives, from the service node, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of a plurality of chunks forming the file.

[0026] The file managing decentralized application obtains a location for the chunk dapp to store said each chunk. The file managing decentralized application saves, on the hubchain, a respective record, comprising the respective chunkhash and the location. The file managing decentralized application sends, to the service node, an allocate chunk response indicating that the file dapp has obtained the chunk dapp for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp.

[0027] According to a still further aspect, the object is achieved by a file managing decentralized application, referred to as "file dapp", configured for managing storing of one or more chunks representing a file. A system includes a chain managing decentralized application, referred to as "platform dapp", the file dapp, a service node, at least one chunk storing decentralized application, referred to as "chunk dapp". The platform dapp manages the file dapp and the chunk dapp. The chunk dapp is registered with the file dapp. The file dapp is configured for:

[0028] The file managing decentralized application is configured for receiving, from the service node, an allocate file request comprising the filehash. The file managing decentralized application is configured for allocating the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp. The file managing decentralized application is configured for sending, to the service node, an allocate file response indicating that the file is allowed to be stored.

[0029] The file managing decentralized application is configured for receiving, from the service node, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of a plurality of chunks forming the file. The file managing decentralized application is configured for obtaining a location for the chunk dapp to store said each chunk. The file managing decentralized application is configured for saving, on the hubchain, a respective record, comprising the respective chunkhash and the location.

[0030] The file managing decentralized application is configured for sending, to the service node, an allocate chunk response indicating that the file dapp has obtained the chunk dapp for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp.

[0031] According to yet another aspect, the object is achieved by a method, performed by a service node, for managing storing of a file. A system includes a chain managing decentralized application, referred to as "platform dapp", a file managing decentralized application, referred to as "file dapp", the service node, at least one chunk storing decentralized application, referred to as "chunk dapp". The platform dapp manages, such as monitors, handles, and the like, the file dapp and the chunk dapp. The chunk dapp is registered with the file dapp. The service node receives the file. The service node generates a filehash based on the file. The service node sends, to the file dapp, an allocate file request comprising the filehash. The service node splits the file into a plurality of chunks. The service node sends, to the file dapp, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of the plurality of chunks.

[0032] The service node receives, from the file dapp, an allocate chunk response indicating that the file dapp has obtained the chunk dapp for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp.

[0033] The service node sends a proof request to the file dapp. The proof request comprises the respective chunkhash. The service node receives a proof from the file dapp. The service node sends said each chunk and the proof to the chunk dapp.

[0034] According to a yet further aspect, the object is achieved by a service node configured for managing storing of a file. A system includes a chain managing decentralized application, referred to as "platform dapp", a file managing decentralized application, referred to as "file dapp", the service node, at least one chunk storing decentralized application, referred to as "chunk dapp". The platform dapp manages, such as monitors, handles, and the like, the file dapp and the chunk dapp. The chunk dapp is registered with the file dapp. The service node is configured for receiving the file. The service node is configured for generating a filehash based on the file. The service node is configured for sending, to the file dapp, an allocate file request comprising the filehash. The service node is configured for splitting the file into a plurality of chunks. The service node is configured for sending, to the file dapp, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of the plurality of chunks. The service node is configured for receiving, from the file dapp, an allocate chunk response indicating that the file dapp has obtained the chunk dapp for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp. The service node is configured for sending a proof request to the file dapp. The proof request comprises the respective chunkhash. The service node is configured for receiving a proof from the file dapp. The service node is configured for sending said each chunk and the proof to the chunk dapp.

[0035] According to a still other aspect, the object is achieved by a method, performed by at least one chunk storing decentralized application, referred to as "chunk dapp", for storing at least one chunk of a file. A system includes a chain managing decentralized application, referred to as "platform dapp", a file managing decentralized application, referred to as "file dapp", a service node, the chunk dapp. The platform dapp manages, such as monitors, handles, and the like, the file dapp and the chunk dapp. The chunk dapp is registered with the file dapp. The least one chunk storing decentralized application receives, from the service node, said each chunk and the proof. The least one chunk storing decentralized application checks that the proof is valid. The least one chunk storing decentralized application decodes the proof to obtain a respective decoded chunkhash and a decoded identity, e.g. related to a particular chunk dapp for which the proof applies. The least one chunk storing decentralized application determines that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash. The least one chunk storing decentralized application determines that the related decoded identity matches an identity of the chunk dapp, the identity being known to the chunk dapp. The least one chunk storing decentralized application stores said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp.

[0036] According to a yet other aspect, the object is achieved by a chunk storing decentralized application, referred to as "chunk dapp", configured for storing at least one chunk of a file. A system includes a chain managing decentralized application, referred to as "platform dapp", a file managing decentralized application, referred to as "file dapp", a service node, the chunk dapp. The platform dapp manages, such as monitors, handles, and the like, the file dapp and the chunk dapp. The chunk dapp is registered with the file dapp. The chunk storing decentralized application is configured for receiving, from the service node, said each chunk and the proof. The chunk storing decentralized application is configured for checking that the proof is valid. The chunk storing decentralized application is configured for decoding the proof to obtain a respective decoded chunkhash and a decoded identity for which the proof applies. The chunk storing decentralized application is configured for determining that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash. The chunk storing decentralized application is configured for determining that the related decoded identity matches an identity of the chunk dapp, the identity being known to the chunk dapp. The chunk storing decentralized application is configured for storing said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp.

[0037] With some embodiments of the system, data is distributed across multiple chunk dapps, each associated with a respective cluster of blockchain nodes. In this manner, scalability is enhanced by allowing the system to grow successively by that further chunk dapps are added, e.g. in response to increased storage requirements or needs.

[0038] In some embodiments, fault tolerance is enhanced since the failure of a single computer, or even a single cluster of blockchain nodes providing a dapp, does not render the entire system inoperable. Data can still be accessed via other nodes of other clusters, ensuring availability and reliability. Moreover, in some embodiments, the decentralized storage system can provide greater flexibility in data management. Users can customize their storage configurations based on their specific needs, such as optimizing for speed, redundancy, or cost-efficiency. This adaptability makes the present decentralized systems more appealing for a wide range of applications, from personal data storage to enterprise-level data management, or the like.

[0039] BRIEF DESCRIPTION OF THE DRAWINGS

[0040] The various aspects of embodiments disclosed herein, including particular features and advantages thereof, will be readily understood from the following detailed description and the accompanying drawings, which are briefly described in the following.

[0041] Figure 1 is schematic overview of an example of a system in which embodiments herein may be implemented.

[0042] Figure 2 through Figure 9 are combined signaling and flowcharts illustrating embodiments of the methods herein.

[0043] Figure 10 is a block diagram illustrating embodiments herein.

[0044] Figure 11 is another block diagram illustrating embodiments herein.

[0045] Figure 12 is a further block diagram illustrating embodiments herein.

[0046] DETAILED DESCRIPTION

[0047] Throughout the following description, similar reference numerals have been used to denote similar features, such as nodes, actions, circuits, parts, items, elements, units or the like, when applicable.

[0048] A blockchain is a decentralized, distributed ledger technology that records transactions across multiple computers in a way that ensures the security, transparency, and immutability of the data. Each transaction is encrypted and grouped into a block, which is then linked to the previous block, forming a chain. The integrity and chronological order of the blockchain are maintained through consensus mechanisms, such as proof of work (PoW), proof of stake (PoS), or the like. This technology eliminates the need for a central authority by using a peer-to-peer network where each participant (node) has a copy of the ledger. Each blockchain can be carried on a network of blockchain nodes. A blockchain network includes a plurality of blockchain nodes. A smart contract is a self-executing contract with the terms of the agreement directly written into code. These contracts are stored and executed on a blockchain, enabling automatic, transparent, and tamper-proof performance of contractual clauses when predefined conditions are met. Smart contracts reduce the need for intermediaries, minimize fraud, and ensure that transactions are carried out exactly as agreed. They are commonly used for various applications, including financial services, supply chain management, and decentralized applications.

[0049] An application Binary Interface (ABI) is a JavaScript Object Notation (JSON) file that defines the functions and variables included in a smart contract. The ABI allows bytecode to be mapped into human-readable formats. In this manner, interacting programmatically with the smart contract is facilitated. As an example, in order to programmatically execute a function of a smart contract, a transaction is sent to the blockchain network defining the smart contract. The transaction can include the address of the smart contract (e.g. an address of the block in which the smart contract is stored), the function of the smart contract to be called, and optionally any parameters to be passed as input to the function. The smart contract function is executed, which causes change(s) to the smart contract's state, e.g. update variable values, or the like. The change(s) to the smart contract's state is recorded as part of the transaction in a new block added to the blockchain.

[0050] A decentralized application, "dapp", "DApp" or "Dapp", is a software programs that run on a blockchain or peer-to-peer (P2P) network of computers instead of on a single computer. Rather than operating under the control of a single authority, the dapp is spread across the network to be collectively controlled by its users. It is often built on a commercially available blockchain platform and has been developed for various purposes, including wallets, exchanges, gaming, personal finance, and social media. As an example, a decentralized application can be defined in terms of one or several smart contracts executing on a blockchain. Each decentralized application forms its own blockchain network. There can be only one decentralized application on one and the same blockchain network and one decentralized application can only run on one blockchain network. Furthermore, decentralized hosting solutions, such as IPFS, and the like, can be used to enhance availability of URL-addresses used to access a decentralized application. Alternatively or additionally, multiple URLs can be linked to the decentralized application to enhance availability. In view of the above, it can happen that smart contract, blockchain and dapp may have been used interchangeably.

[0051] A block is a discrete unit of data within a blockchain that contains a collection of transactions. Each block comprises a header and a body, where the header includes metadata such as a timestamp, a reference to the previous block (typically in the form of a cryptographic hash), and a nonce used in the consensus process, such as proof of work, or the like. The body contains the actual transaction data. Blocks are sequentially linked to form a chain, ensuring the integrity and immutability of the entire blockchain through cryptographic means.

[0052] A transaction is an individual operation recorded on the blockchain, representing the transfer of data or assets between parties. Each transaction includes a unique identifier, details of the parties involved, the value or data being transferred, and a digital signature to authenticate the sender's identity and authorize the transaction. Transactions are validated by the network's consensus mechanism before being grouped into a block and added to the blockchain, ensuring that all nodes maintain a consistent and tamper-proof ledger.

[0053] A transaction log of a blockchain is a comprehensive, chronological record of all transactions that have occurred within the blockchain network. This log is distributed across all nodes in the network, ensuring transparency and immutability. Each entry in the transaction log corresponds to a validated transaction, including details such as the transaction identifier, timestamp, participating parties, and the data or assets transferred. The transaction log is maintained and updated through the addition of new blocks, which are permanently linked to the previous blocks, forming an unalterable history of all network activity.

[0054] Blockchain Explorer:

[0055] A blockchain explorer is a specialized web-based application that provides a user interface for accessing and navigating the data stored on a blockchain. It allows users to search, view, and analyze blockchain transactions, blocks, addresses, and other relevant information in a transparent and user-friendly manner. A blockchain explorer typically offers functionalities such as displaying the status and details of recent and historical transactions, viewing the contents of individual blocks, checking the balance and activity of specific wallet addresses, and monitoring the overall health and statistics of the blockchain network. By providing realtime insights and comprehensive data access, blockchain explorers facilitate enhanced transparency and usability of blockchain systems.

[0056] BRID stands for Blockchain Reference ID and is the global reference ID (identity) for a blockchain that is common for all nodes.

[0057] Figure 1 shows an exemplifying system 100 according to the embodiments herein. The system is configured to store a file provided by an end user, e.g. via a service node 120.

[0058] The system 100 comprises a platform dapp 150, realized in the form of a decentralized application that is associated with a systemchain, i.e. a blockchain. The platform dapp 150 can be responsible for authentication of transactions on decentralized applications monitored by the platform dapp 150, e.g. proving that these transactions have occurred in the monitored decentralized application. The systemchain, managed by the platform dapp 150, can be referred to as a first blockchain.

[0059] The system 100 further comprises a file dapp 110, also realized in the form of a decentralized application that is associated with a hubchain, i.e. a blockchain. The file dapp 110 can be responsible for managing storage of the file, e.g. where to store the file, optionally handling payment for storing of the file, and / or the like. Yet further, in some examples, the file dapp 110 can be responsible for splitting of the file into chunks, e.g. instead of the service node 120. The hubchain, managed by the file dapp 110, can be referred to as a second blockchain.

[0060] Moreover, the system 100 comprises a chunkchain provider node 130 for registration of a set of chunk dapps 140-14n. The set of chunk dapp 140- 14n can comprise a chunk dapp 140, and optionally a further chunk dapp 14n, or the like. Sometimes, the set of chunk dapps 140- 14n comprises at least two chunk dapps 140-14n, e.g. include the chunk dapp 140 and the further chunk dapp 14n. The chunkchain provider node 130 can be a software application, a web application a script, a javascript of a webpage, or the like. The chunkchain provider node 130 can execute on a computer, a server, a PC, etc.. The chunkchain provider node 130 may typically not be a dapp. The chunkchain, managed by the chunk dapp 140-14n, can be referred to as a third blockchain.

[0061] Each chunk dapp of the set of chunk dapps 140-14n can be realized by a respective decentralized application, such as a dapp, or the like. Said each chunk dapp 140- 14n can be associated with a respective chunkchain, e.g. for storing of one or more chunks relating to the file.

[0062] The service node 120 can be a software application, a web application, a script, a javascript of a webpage, or the like. The software application can execute on a client device, such as a PC, a mobile phone, a TabletPC, a portable computer, virtual hardware, or the like.

[0063] An end user 1 can provide the file 2 to the service node 120, e.g. by selecting, such as using drag-n-drop, browse for file, or the like, the file via a graphical user interface of the service node 120.

[0064] Figure 2 through Figure 9 illustrates examples of the method, performed by the system 100, according to various embodiments herein.

[0065] In some examples, the file dapp 110 performs a method for managing, such as enabling, facilitating, or the like, storing of one or more chunks representing the file. In some examples, the service node 120 performs a method for managing, such as initiating, ordering, requesting, or the like, storing of the file. In some examples, the chunk dapp 140 performs a method for storing, such as saving, archiving, recording, preserving, retaining, or the like, at least one chunk of the file.

[0066] Referring to Figure 2, before a file can be stored, one or more actions can be performed in order to prepare the system 100. In this manner, it can for example be ensured that various software components, such as nodes, dapps, smart contracts on a blockchain, web applications, web pages, or the like, are aware of requisite information, such as URLs, identities of decentralized application, or the like, in order to send messages to each other. For this reason, the dapps and / or nodes may need to register with each other. The following actions are merely exemplary, and further registrations and / or setup can be required according to known procedures relating to systems including decentralized applications, general network communication, and the like.

[0067] The service node 120 can be setup as a frontend application associated with the file dapp 110. This can mean that the service node 120 is aware of an URL-address of the file dapp 110 as well as an identity of the file dapp 110, e.g. a BRID of the file dapp 110. The identity can identify the decentralized application, i.e. the file dapp 110, which can be found on one or more blockchain nodes of the hubchain. As an example, the service node 120 can use ABI JSON information, or the like, for setting up communication with the file dapp 110.

[0068] Action A310

[0069] The chunkchain provider node 130 can send a registration request, to the file dapp 110, for requesting registration of at least one chunk dapp 140- 14n. By means of the request, the chunkchain provider node 130 can thus register one or more chunk dapps 140-14n, e.g. at least one chunk dapp 140, with (or at) the file dapp 110. In this manner, the file dapp 110 is made aware which chunk dapps 140- 14n the file dapp 110 can select from when allocating chunks of a file as described below.

[0070] Each of said at least one chunk dapps 140-14n can manage a respective blockchain, referred to as "respective chunkchain". The blocks of the chunkchain have a maximum block size. The maximum block size can be expressed as a certain number of bits or bytes. Data can be stored on the respective chunkchain by that an associated chunk dapp adds a block, including one or more transactions, which in turn includes the data, to the chunkchain.

[0071] The chunks of the file can have a chunk size, e.g. a certain number of bits or bytes, that is less than or equal to the block size. In this manner, it can be ensured that a chunk can be included within one single block. Notably, the chunk is a piece of information or data and could therefore be referred to as chunk data.

[0072] As an example, the request can include a location, e.g. a URL and an identity (BRID), for accessing the chunk dapps 140- 14n and an identifier for identifying the owner. The identity for accessing a particular chunk dapp can be referred to as a "chunk dapp identity". The request can include information about redundancy level of the chunk dapps 140-14n, or a respective redundancy level for each of the chunk dapps 140-14n being registered.

[0073] In some examples, the redundancy level can refer to e.g. a number of blockchain nodes managing a chunkchain associated with the chunk dapp 140. Each blockchain node can maintain a complete copy of the entire chunkchain. The chunkchain is a blockchain managed by the chunk dapp 140-14n. Expressed differently, a copy of a particular chunk can be stored in a cluster, associated with a chunk dapp 140, where the cluster comprises a certain number of blockchain nodes, each blockchain node running on a respective physical and / or virtual machine, such as a computer, a virtual execution environment, or the like.

[0074] In some examples, the redundancy level can refer to a number of chunk dapps 140-14n employed for the storing of the file and / or said each chunk. Accordingly, multiple copies of an arbitrary chunk can be stored by a plurality of chunk dapps 140- 14n. Expressed differently, a copy of a particular chunk can be stored in multiple clusters, each cluster being associated with a respective chunk dapp 140.

[0075] Sometimes, the redundancy level can refer to a combination of the preceding examples.

[0076] Action A120

[0077] The file dapp 110 can receive the registration request.

[0078] Action A130

[0079] The file dapp 110 can, based on the registration request, register an owner of one or more chunk dapps 140- 14n.

[0080] As an example, the file dapp 110 can store, e.g. for each owner and for each registered chunk dapp 140-14n: location, such as a URL-address and an identity associated with the chunk dapp 140- 14n being registered, and optionally, redundancy level of the chunk dapp 140-14n being registered.

[0081] Action A140

[0082] The file dapp 110 can send a registration response to the chunkchain provider node 130. The response can include information about whether the registration was successful or not. Hence, in this manner, the response indicates to the chunkchain provider node 130 that the registration was successful, or possibly unsuccessful.

[0083] At this stage, the file dapp 110 can be provided with at least one chunk dapp 140 that can be used to allocate one or more chunks of a file that the file dapp 110 can be requested to store.

[0084] Action A350

[0085] The chunkchain provider node 130 can receive the registration response, e.g. from the file dapp 110.

[0086] Starting in Figure 3, it is described and illustrated how to save data, such as user data, a file, a stream, or the like, by means of the system 100 herein.

[0087] Action B210

[0088] The service node 120 receives data, e.g. from a device of an end user. The data can be user data, a file, a stream of data, or the like. For example, the data can be any header information and payload, a document file, a text file, a video file, an audio file, a token, a non-fungible token (NFT), a video stream, an audio stream, a feed including audio and / or video, a live stream, or the like. For simplicity, the data is referred to as "file" in the following.

[0089] Sometimes, the service node 120 can encrypt the file. In those examples, the file will in the following refer to the encrypted file, when applicable.

[0090] Action B220

[0091] The service node 120 can generate a filehash based on the received file. The filehash can be a value, typically with the same number of bits irrespectively of the size of the received file. As an example, the service node 120 can use a hashing algorithm to generate the filehash based on the contents of the received file. The hashing algorithm can be SHA 256, or the like. Generally, the term "filehash" refers to a hash, or hash value, determined based on data forming a file, such as the received file in this action.

[0092] The service node 120 can store the filehash and a reference to it. The reference can be a name, a filename, or the like, e.g. as assigned by the end user, e.g. when providing, such as uploading, or the like, the file to the service node 120. The reference can sometimes be automatically generated, e.g. by the device of the end user, by the service node 120, or the like.

[0093] Action B230

[0094] After action B220 above, the service node 120 sends an allocate file request to the file dapp 110.

[0095] The allocate file request can comprise the filehash, a size of the file from which the filehash was generated, an identity of the end user that provided the file to the service node 120. Optionally, the allocate file request can include metadata, such as a file type identifier, a Content-Type, or the like. In this manner, browsers are made aware of how to handle the file.

[0096] As an example, any conventional login-framework, such as AuthO, firebase authentication, or the like, can be used to authenticate the end user to the service node 120. Thus, the service node 120 can obtain the identity of the end user.

[0097] Action B140

[0098] The file dapp 110 can thus receive the allocate file request, from the service node 120, and process it further as described below.

[0099] Action B150

[0100] Once the allocate file request has been obtained by the file dapp 110, the file dapp 110 can check whether payment from the end user, as compensation for storing the file, is required. If the end user has remaining credits, a monthly subscription, or the like, payment may not necessarily be required.

[0101] However, in many cases payment from the end user to an owner associated with the file dapp 110 can be required. As an example, the amount of the payment can be dependent on the file size, as a prepayment for a certain number of files, etc. Any conventional payment platform, such as Stripe, cryptocurrency, or the like, can be used to facilitate the payment from the end user to the file dapp 110, e.g. to the owner to be compensated for the actions performed by the file dapp 110. Preferably, payment can be handled by the file dapp 110 and / or the platform dapp 150, e.g. using cryptocurrency, or the like.

[0102] As an example, the file dapp 110 can thus determine that the allocate file request can be responded to with a response indicating that the file is allowed to be stored, e.g. due to successful payment, remaining credits, or the like.

[0103] The file dapp 110 can store, e.g. as a transaction on the hubchain managed by the file dapp 110, information indicating that the file, identified by the filehash, is allowed to be stored.

[0104] In this manner, the file dapp 110 allocates, such as registers, or the like, that the file is allowed to be stored on the blockchain, managed by the file dapp 110.

[0105] Action B160

[0106] When the file is allowed to be stored, the file dapp 110 can send, to the service node 120, the response, such as an allocate file response, indicating that the file is allowed to be stored.

[0107] Action B270

[0108] The service node 120 can receive the allocate file response.

[0109] Action B280

[0110] The service node 120 can split the file into a plurality of chunks and assign each chunk of the plurality of chunks a respective index indicating a position of said each chunk to be used when reconstructing the file from the plurality of chunks. A piece of reconstruction information can comprise the respective index for each chunk of the plurality of chunks.

[0111] As an example, a file can be split into three chunks, or portions. In order to be able to know in which order the three chunks shall be put together when reconstructing the file, each of the three chunks can be associated with a respective index indicating that chunks position for reconstruction of the file. This action is preferably performed after action B270, but it can be performed before B270.

[0112] This action is possible to perform at any point in time after the file has been received, e.g. in action B210, by the service node 120.

[0113] Sometimes, the service node 120 can encrypt each chunk of the plurality of chunks. In these examples, the chunk will in the following refer to the encrypted chunk.

[0114] Now that the file has been split into the plurality of chunks, a set of actions can be repeatedly performed for each chunk of the plurality of chunks, see e.g Figure 4 through Figure 6. The set of actions can include one or more of action C210, C112, C114, C116, C118, C220, C222, C124, C126, C228, C230, C232, C434, C436, C445, C450, C455, and C460. Of course, execution of the set of actions can begin as soon as at least one chunk of the file is available for processing, e.g. storing and the like.

[0115] Hence, at this stage, e.g. after action B280, said each chunk is ready to be stored in at least one block of at least one chunk dapp 140-14n, i.e. in at least one block of a respective chunkchain of said at least one chunk dapp 140-14n.

[0116] Action C210

[0117] Accordingly, the service node 120 can send an allocate chunk request to the file dapp 110. The allocate chunk request can comprise the filehash, a respective chunkhash for said each chunk to be stored, a chunk size for said each chunk, reconstruction information, e.g. for said each chunk, and the like. The reconstruction information can indicate how said each chunk shall be inserted into the file, e.g. at which part of the file. As an example, the reconstruction information can be an index, such as an ordinal number indicating a position, or order, of said each chunk in the file. The reconstruction information can possibly be omitted, e.g. if there is an agreement regarding that chunks are required to be stored in a predefined order. Generally, the term "chunkhash" refers to a hash, or hash value, determined based on data forming a chunk, such as said each chunk in this action.

[0118] The respective chunkhash can be generated based on the contents of said each chunk. The generation of the chunkhash can be performed as part of action C210, as part of action B280, or the like. The chunkhash can be generated once the content of a chunk is known, and the chunkhash can be generated before the allocate chunk request is sent to the file dapp 110. Sometimes, the respective chunkhash for all of the plurality of chunks is generated before the repetition of the set of actions and / or sometimes before the sending C210 for said each chunk.

[0119] Action C112

[0120] The file dapp 110 can receive the allocate chunk request.

[0121] Action C114

[0122] The file managing decentralized application 110 obtains a location for the chunk dapp 140 to store said each chunk.

[0123] As an example, the file dapp 110 may now need to select a chunkchain that can store said each chunk, i.e. the location at which the chunk dapp 140 can store said each chunk. The selection of the chunkchain can be based on a desired redundancy level and / or the chunk size, and / or the like. Alternatively, the file dapp 110 can simply pick any arbitrary or non- arbitrary chunkchain, or chunk dapp, e.g. a first chunkchain among available chunkchains. When the chunkchain has been selected by the file dapp 110, the file dapp 110 can thus obtain a location for the selected chunkchain. The location, or indication of location, can include an URL-address and an identity associated with the selected chunkchain, or chunk dapp 140, provided at that URL-address. The identity, such as a BRID, serves to distinguish one or more chunkchains, from each other, that can be provided at one and the same URL- address.

[0124] In some examples, the file dapp 110, or an administrator node thereof, can monitor chunkchains to determine whether they are building blocks or not. If a chunkchain does not build blocks, it can be disabled, e.g. by the file dapp 110, whereby that chunkchain no longer is available for selection by the file dapp 110.

[0125] In some examples, the filechain provider node 130 can monitor chunkchains to determine whether they are low on space for storage of chunks. If a chunkchain is low on space, it can be disabled, e.g. by the filechain provider node 130, whereby that chunkchain no longer is available for selection by the file dapp 110.

[0126] Action C116 E.g. for said each chunk, the file dapp 110 saves the location of the selected chunkchain, e.g. by creating a respective record including the chunkhash and the location of the selected chunkchain. The respective record is thus stored by the file dapp 110, e.g. on the hubchain managed by the file dapp 110. Furthermore, the record can include the reconstruction information related to said each chunk.

[0127] In this manner, the records from the file dapp 110 can be extracted to obtain the location of any given chunkhash.

[0128] Action C118

[0129] The file dapp 110 can send an allocate chunk response, e.g. indicating that the file dapp 110 has successfully selected the chunkchain to store the data identified by the chunkhash.

[0130] The allocate chunk response can include the location of the selected chunkchain.

[0131] Action C220

[0132] After action C118, the service node 120 can receive the allocate chunk response. In this manner, the service node 120 is informed about the location of the chunkchain selected to store said each chunk, identified by the chunkhash.

[0133] Action C222

[0134] In order to initiate the storing of said each chunk, the service node 120 can send an initiate chunk request, which can include the chunkhash and the location.

[0135] Action C124

[0136] After action C222, the file dapp 110 can thus receive the initiate chunk request.

[0137] Action C125

[0138] The file dapp 110 can mark the chunk, e.g. identified by the chunkhash, as initialized, e.g. by adding a transaction, referred to as "initialized transaction", that the chunk was initialized to the blockchain, i.e. to a new block of the blockchain. The new block can also contain further transaction, not solely the initialized transaction. In this manner, the file dapp 110 obtains a transaction identity for the initialized transaction, e.g. when successful. If the chunk has already been initialized, a failure can occur. The marking as initialized serves the purpose to create a transaction to generate a ICCF proof of.

[0139] Action C126

[0140] The file dapp 110 can send an initiate chunk response, indicating successful initialization of the chunk, identified by the chunkhash. The initiate chunk response can indicate that the initialized transaction succeeded, e.g. by that the initiate chunk response includes the transaction identity.

[0141] Thanks to actions C222 through C126, the system 100 is able to handle errors, possibly occurring due to that the chunk dapp selected for storage of the chunk is not available, e.g. due to data center outage, data connection issues, or the like.

[0142] Action C228

[0143] The service node 120 can then receive the initiate chunk response.

[0144] Action C230

[0145] The service node 120 can send a proof request to the file dapp 110.

[0146] The proof request can be a request for a so called ICCF-proof, or the like. ICCF is a platform specific term, e.g. for a platform called Chromia, and stands for Interchain Confirmation Facility.

[0147] The proof request can comprise the chunkhash for which proof of initialization is requested.

[0148] In some examples, the service node 120 can obtain, such as fetch, request, or the like, an address or location relating to the file dapp 110. By means of the address or location, the service node 120 can send the proof request to the file dapp 110. The address or location can include an URL-address and an identity relating to a decentralized application realizing, or forming, the file dapp 110. As an example, generally herein, any arbitrary libraries compatible with the present system, such as the file dapp 110, or the like, can be used for handling, accessing, or the like, the decentralized applications described herein. Action C130

[0149] The file dapp 110 can receive the proof request.

[0150] Action C131

[0151] The file dapp 110 generates a proof, e.g. based on information provided in the proof request. The request can include e.g. the chunkhash, a chunk dapp identity (BRID), or the like. The proof can be a value, e.g. represented by a string of characters, or the like.

[0152] The proof indicates that a transaction has occurred on the hubchain managed by the file dapp 110. This proof can later be verified by the selected chunk dapp 140, e.g. see below.

[0153] The transaction can be that a chunkchain has been successfully selected for said each chunk, and optionally that payment has been performed successfully.

[0154] Action C132

[0155] The file dapp 110 sends the proof to the service node 120.

[0156] Action C231

[0157] The service node 120 receives the proof from the file dapp 110.

[0158] Action C232

[0159] The service node 120 sends the chunk and the proof to the selected chunk dapp 140.

[0160] Action C434

[0161] The chunk dapp 140 can receive the proof and the chunk.

[0162] Action C436

[0163] The chunk dapp 140 can validate the proof to find out whether or not the proof is valid, e.g. indicates that the file dapp 110 successfully allocated that chunk.

[0164] In order to validate the proof, the chunk dapp 140 can send the proof to the platform dapp 150. The platform dapp 150 can then check whether the transaction was successful or not, e.g. since one of the tasks of the platform dapp 150 is to monitor transactions such as to be able to confirm or disprove validity of transactions. Next, the platform dapp 150 can send a response to the chunk dapp 140. The response can thus indicate that the transaction was indeed successfully performed or that the transaction was not successfully performed.

[0165] The chunk dapp 140 can receive the response from the platform dapp 150 and if the response indicates that the transaction was successfully performed, then the following action can be performed.

[0166] However, if the validation of the proof fails, the chunk dapp 140 can send an error message to the service node 120. Then, the chunk dapp 140 does of course perform e.g. action C460 below.

[0167] Action C445

[0168] The chunk dapp 140 decodes the proof to obtain the chunkhash and the identity (BRID). This means that the chunk dapp 140 can derive the chunkhash and the identity from the proof. Notably, the identity or BRID is unique within a network.

[0169] Action C450

[0170] Next, the chunk dapp 140 determines a current chunkhash based on said each chunk to be stored, e.g. using a hashing algorithm. The chunk dapp 140 can then compare the current chunkhash with the chunkhash decoded from the proof.

[0171] When the current chunkhash matches the chunkhash decoded from the proof, the chunk dapp 140 can conclude that the chunk is allowed to be stored, at least with respect to that the chunk has been allowed, e.g. by the file dapp 110, to be stored.

[0172] Action C455

[0173] Moreover, the chunk dapp 140 compares the chunk dapp identity of the proof with a known chunk dapp identity of this chunk dapp 140. As an example, the comparing of the chunk dapp identity can mean that the chunk dapp identity of the selected chunk dapp 140 matches, such as is equal to, corresponds to, or the like, the chunk dapp identity decoded from the proof. The chunk dapp identity can be a BRID, or the like.

[0174] The chunk dapp identity can be determined by the platform dapp 150 when e.g. any chunk dapp 140-14n is deployed on the platform dapp 150. This chunk dapp identity has to be known by the file dapp 110, which is a reason for that the chunkchain provider node 130 informs the file dapp 110 about the chunk dapp identities during registration, including one or more of actions A310, A120, A130, A140, and A350.

[0175] When the chunk dapp identity of the proof matches the known chunk dapp identity of this chunk dapp 140, the chunk dapp 140 can proceed with action C460 as below.

[0176] Action C460.

[0177] The chunk dapp 140 can store said each chunk. As an example, the chunk dapp 140 can store the chunk in a block of the chunkchain managed by the chunk dapp 140. This can be achieved by that the chunk and the chunkhash is provided as input to a transaction to be stored in the block of the chunkchain.

[0178] In this manner, the chunk become part of a transaction log associated with the chunkchain. The transaction log can thus be used to obtain the chunk as explained below. As a result, the chunk need not be stored in a separate database, e.g. outside the chunkchain.

[0179] At this stage, e.g. when the set of actions has been performed and successfully completed for each of the chunks, e.g. forming the file, the file has been stored by one or more of the chunk dapps 140- 14n.

[0180] At this point, it may also be that the service node 120 can provide, such as display, alert, convey, or the like, an indication that the file has been successfully stored by at least the chunk dapp 140, e.g. to the user 1. The indication can thus be a message, a sound, an image indicating that the file was successfully stored, or the like.

[0181] As a concluding example, the chunk dapp 140 may typically only store the chunk when the proof is valid, when the identity of the proof matches the own identity of this chunk dapp 140, and when the chunkhash of the proof matches the chunkhash of the received chunk.

[0182] As an example, see e.g. Figure 7 and Figure 8, the service node 120 can be requested, e.g. by the end user, to retrieve the file.

[0183] One or more of the following actions may be performed, e.g. in any suitable order. Action D210

[0184] The service node 120 can then send the stored filehash associated with the file, e.g. indicated by the end user by means of the reference, to the file dapp 110.

[0185] Action D120

[0186] After action D210, the file dapp 110 receives the filehash.

[0187] Action D130

[0188] The file dapp 110 fetches a list of records including locations and associated chunkhashes and reconstruction information based of the filehash, which was created when the file was stored.

[0189] Action D140

[0190] The file dapp 110 sends the list and the reconstruction information, i.e. file storage information, to the service node 120.

[0191] Action D250

[0192] The service node 120 receives the list and the reconstruction information from the file dapp 120.

[0193] Now, the service node 120 can loop over the chunkhashes in order to retrieve a respective chunk for each chunkhash and then put together all of the respective chunks for all of the chunkhashes according to the reconstruction information in order to reconstruct the file. Therefore, action E210, E120, E130 and E240 can be performed for each chunkhash of the list. Equivalently, the service node 120 can send said at least one respective chunkhash to each location and loop over the set of locations.

[0194] Action E210

[0195] The service node 120 can send said each chunkhash to the location associated with said chunkhash according to the list.

[0196] As a result, the service node 120 provides said each chunkhash to a particular chunkchain 140 that has stored said each chunkhash as indicated by the file storage information. 1

[0197] Action E120

[0198] Then, the chunk dapp 140 can thus receive the chunkhash and obtain a respective chunk from the chunk dapp 140 identified by the location, e.g. in particular the identity of the location.

[0199] As an example, the chunk dapp 140 can retrieve from the chunkchain, managed by the chunk dapp 140, the previously stored record, identified by the chunkhash.

[0200] Action E130

[0201] The chunk dapp 140 sends the respective chunk related to said each chunkhash to the service node 120.

[0202] Action E240

[0203] Accordingly, the service node 120 can receive the respective chunk from the chunk dapp 140.

[0204] If the service node 120 has encrypted each respective chunk, then the service node 120 can decrypt the respective chunk.

[0205] Once the service node 120 has received at least two consecutive respective chunks, the service node 120 can begin to reconstruct the file. Sometimes, the service node 120 can wait until a set of chunks, comprising the respective chunk for at least two chunkhashes, preferably for all chunkhashes, have been received before reconstruction of the file is begun. Said at least two chunkhashes may typically correspond to chunks that should be placed adjacently each other in the file. Of course, in some examples, it may be that the entire file is included in only one chunk. In such cases, reconstruction begin when that single chunk has been received.

[0206] Action E250

[0207] Then, the service node 120 can reconstruct the file based on the set of chunks according to the reconstruction information. As an example, the reconstruction information can indicate that indices of the chunkhashes as stored in the register, e.g. on the hubchain, or the like, determines an order in which the related chunks shall be concatenated, e.g. put together, to form the file.

[0208] If the service node 120 has encrypted the file, then the service node 120 can decrypt the file.

[0209] Action E260

[0210] At this stage, the service node 120 can provide the file to the end user, e.g. as requested by the end user.

[0211] As a further example, with reference to Figure 9, it may happen that a file shall be deleted on request by the service node 120.

[0212] One or more of the following actions can then be performed, e.g. in any suitable order.

[0213] Action F210

[0214] The service node 120 can send a delete request for deletion of the file to the file dapp 110.

[0215] Action F120

[0216] Subsequently, the file dapp 110 can thus receive the delete request from the service node 120.

[0217] Action F130

[0218] In order to make it impossible, e.g. from the perspective of the service node 120, to retrieve the file, the file dapp 110 can delete the information about by which chunk dapp each chunk has been stored and optionally the related reconstruction information. As an example, the file dapp 110 can therefore delete this information from the hubchain by including the delete request, as a transaction, on the hubchain.

[0219] Action F140

[0220] The file dapp 110 can send a delete response indicating that the file cannot be retrieved anymore. Action F250

[0221] Then, the service node 120 can receive the delete response from the file dapp 110. The service node 120 can further indicate, e.g. in the graphical user interface associated with the service node 120, that the file has been deleted, e.g. to provide feedback to the end user. In this manner, the end user can be informed about that the deletion was successful.

[0222] In some embodiments, there is provided a system 100 configured for storing a file. The system 100 includes a chain managing decentralized application 150, referred to as "platform dapp 150", a file managing decentralized application 110, referred to as "file dapp 110", a service node 120, at least one chunk storing decentralized application 140-14n, referred to as "chunk dapp 140- 14n". The platform dapp 150 manages such as monitors, handles, and the like, the file dapp 110 and the chunk dapp 140. The chunk dapp 140 is registered with the file dapp 110. The system 100 is configured for receiving, by the service node 120, the file.

[0223] The system 100 is configured for generating, by the service node 120, a filehash based on the file.

[0224] The system 100 is configured for sending, by the service node 120 to the file dapp 110, an allocate file request comprising the filehash.

[0225] The system 100 is configured for allocating, by the file dapp 110, the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp 110.

[0226] The system 100 is configured for sending, by the file dapp 110 to the service node 120, an allocate file response indicating that the file is allowed to be stored.

[0227] The system 100 is configured for splitting, by the service node 120, the file into a plurality of chunks.

[0228] The system 100 is configured for repeatedly performing a set of actions for each chunk of the plurality of chunks. The set of actions can be implemented by that the system 100 is configured as follows.

[0229] The system 100 is configured for sending, by the service node 120 to the file dapp 110, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on said each chunk. The system 100 is configured for obtaining, by the file dapp 110, a location for the chunk dapp 140 to store said each chunk.

[0230] The system 100 is configured for saving, by the file dapp 110 and on the hubchain, a respective record, comprising the respective chunkhash and the location.

[0231] The system 100 is configured for sending, by the file dapp 110 to the service node 120, an allocate chunk response indicating that the file dapp 110 has obtained the chunk dapp 140 for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp 140.

[0232] The system 100 is configured for sending, by the service node 120, a proof request, to the file dapp 110. The proof request comprises the respective chunkhash.

[0233] The system 100 is configured for generating, by the platform dapp 150, a proof indicating that a transaction has occurred on the hubchain. The transaction confirms that the chunk dapp 140, indicated by the location, has been selected for storage of said each chunk.

[0234] The system 100 is configured for sending, by the file dapp 110, the proof to the service node 120.

[0235] The system 100 is configured for sending, by the service node 120, said each chunk and the proof to the chunk dapp 140.

[0236] The system 100 is configured for checking, by the chunk dapp 140, that the proof is valid.

[0237] The system 100 is configured for decoding, by the chunk dapp 140, the proof to obtain a respective decoded chunkhash and a decoded identity e.g. related to a particular chunk dapp 140 for which the proof applies.

[0238] The system 100 is configured for determining, by the chunk dapp 140, that a current chunkhash, generated, e.g. by the chunk dapp 140, based on said each chunk to be stored, matches the respective decoded chunkhash.

[0239] The system 100 is configured for determining, by the chunk dapp 140, that the related decoded identity matches an identity of the chunk dapp 140, the identity being known to the chunk dapp 140.

[0240] The system 100 is configured for storing, by the chunk dapp 140, said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp

[0241] 140. In some embodiments, the system 100 is configured for selecting, by the file dapp 110, at least one chunk dapp 140 from a plurality of chunk dapps 140-14n that have been registered with the file dapp 110.

[0242] In some embodiments, each chunk dapp 140-14n of the plurality of chink dapps 140- 14n is associated with a respective chunkchain.

[0243] The system 100 may be configured for sending, by the service node 120 to the file dapp 110, an initiate chunk request, comprising the respective chunkhash for said each chunk and the location.

[0244] The system 100 may be configured for marking, by the file dapp 110 and in response to the initiate chunk request, the chunk identified by the respective chunkhash of the initiate chunk request as initialized.

[0245] The system 100 may be configured for sending, by the file dapp 110, an initiate chunk response to the service node 120. The initiate chunk response indicates to the service node 120 that said each chunk has been initialized by the file dapp 110.

[0246] In some embodiment, said at least one chunk dapp 140- 14n comprises the chunk dapp 140 and a further chunk dapp 14n. The chunk dapp 140 only stores a portion of the plurality of chunks and the further chunk dapp 14n only stores a further portion of the plurality of chunks. The portion of the plurality of chunks is at least partially non-overlapping with the further portion of the plurality of chunks.

[0247] In some embodiments, the location comprises a Uniform Resource Locator, "URL", -address and an identity of the chunk dapp 140.

[0248] In some embodiments the system 100 is configured for, before the repeatedly performing of the set of actions, generating a set of chunkshashes based on the plurality of chunks. The set of chunkhashes comprises the respective chunkhash generated based on said each chunk, or wherein the set of actions comprises generating the respective chunkhash based on said each chunk. The generating is performed, before the sending C210 of the request, separately for said each chunk. The system 100 may be configured for sending, by the service node 120, a filehash to the file dapp 110. The system 100 may be configured for fetching, by the file dapp 110 and based on the filehash, file storage information. The file storage information comprises a set of locations, and at least one respective chunkhash associated with each location of the set, and related reconstruction information, such as an index for each one of said at least one respective chunkhash. The index preferably indicates a location within the file for a chunk corresponding to the chunkhash. The system 100 may be configured for sending, by the file dapp 110, the file storage information to the service node 120.

[0249] For said each location, the system 100 may be configured as follows.

[0250] The system 100 may be configured for providing, by the service node 120, said at least one respective chunkhash to a particular chunk dapp indicated by said each location of the file storage information. The particular chunk dapp is selected from said at least one chunk dapp 140-14n.

[0251] The system 100 may be configured for obtaining, by the particular chunk dapp, a respective chunk for each chunkhash of said at least one respective chunkhash, e.g. from the chunkchain of said particular chunk dapp. The system 100 may be configured for sending, by the particular chunk dapp, the respective chunk to the service node 120. The system 100 may be configured for receiving, by the service node 120, a set of chunks from each chunk dapp 140-14n of said at least one chunk dapp 140- 14n. The system 100 may be configured for reconstructing, by the service node 120, the file based on the set of chunks and the reconstruction information. The system 100 may be configured for providing, by the service node 120, the file. The system 100 may be configured for sending, by the service node 120, a delete request, comprising a filehash of the file to be deleted, to the file dapp 110. The system 100 may be configured for deleting, by the file dapp 110, each chunkhash associated with for the filehash of the delete request and a respective location associated with each chunkhash. The system 100 may be configured for sending, by the file dapp 110, a delete response to the service node 120. The delete response indicates to the service node 120 that the deletion of the file associated with the filehash succeeded. In some embodiments, the chunks of the chunkhashes, associated with the filehash, remains stored by the respective chunk dapp 140-14n.

[0252] In some embodiments, the system 100 is configured for, after the set of actions, providing, by the service node 120, an indication that the file has been successfully stored by at least the chunk dapp 140.

[0253] With reference to the combined signaling and flow charts above, the file managing decentralized application 110, referred to as "file dapp 110", can perform a method for managing storing of one or more chunks representing a file. A system 100 includes a chain managing decentralized application 150, referred to as "platform dapp 150", the file dapp 110, a service node 120, at least one chunk storing decentralized application 140-14n, referred to as "chunk dapp 140- 14n". The platform dapp 150 manages, such as monitors, handles, and the like, the file dapp 110 and the chunk dapp 140. The chunk dapp 140 is registered with the file dapp 110.

[0254] One or more of the following actions may be performed in any suitable order. The following actions have also been described above.

[0255] Action B140

[0256] The file managing decentralized application 110 receives, from the service node 120, an allocate file request comprising the filehash.

[0257] Action B150

[0258] The file managing decentralized application 110 allocates the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp 110.

[0259] Action B160

[0260] The file managing decentralized application 110 sends, to the service node 120, an allocate file response indicating that the file is allowed to be stored.

[0261] Action C112 The file managing decentralized application 110 receives, from the service node 120, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of a plurality of chunks forming the file.

[0262] Action C114

[0263] The file managing decentralized application 110 obtains a location for the chunk dapp 140 to store said each chunk.

[0264] Action C116

[0265] The file managing decentralized application 110 saves, on the hubchain, a respective record, comprising the respective chunkhash and the location.

[0266] Action C118

[0267] The file managing decentralized application 110 sends, to the service node 120, an allocate chunk response indicating that the file dapp 110 has obtained the chunk dapp 140 for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp 140.

[0268] With reference to Figure 10, a schematic block diagram of embodiments of the file dapp 110 is shown.

[0269] The file dapp 110 may comprise a processing unit 1001, such as a means for performing the methods described herein. The means may be embodied in the form of one or more hardware units and / or one or more software units. The term "unit" may thus refer to a circuit, a software block or the like according to various embodiments as described below.

[0270] The file dapp 110 may further comprise a memory 1002. The memory may comprise, such as contain or store, instructions, e.g. in the form of a computer program 1003, which may comprise computer readable code units.

[0271] According to some embodiments herein, the file dapp 110 and / or the processing unit 1001 comprises a processing circuit 1004 as an exemplifying hardware unit, which may comprise one or more processors. Accordingly, the processing unit 1001 may be embodied in the form of, or 'realized by', the processing circuit 1004. The instructions may be executable by the processing circuit 1004, whereby the file dapp 110 is operative to perform the methods of Figure 2 to Figure 9. As another example, the instructions, when executed by the file dapp 110 and / or the processing circuit 1004, may cause the file dapp 110 to perform the method according to Figure 2 to Figure 9.

[0272] In view of the above, in one example, there is provided a file dapp 110 for managing storing of one or more chunks representing a file. Again, the memory 1002 contains the instructions executable by said processing circuit 1004 whereby the file dapp 110 is operative for: receiving, from the service node 120, an allocate file request comprising the filehash, allocating the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp 110, sending, to the service node 120, an allocate file response indicating that the file is allowed to be stored, receiving, from the service node 120, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of a plurality of chunks forming the file, obtaining a location for the chunk dapp 140 to store said each chunk, saving, on the hubchain, a respective record, comprising the respective chunkhash and the location, and sending, to the service node 120, an allocate chunk response indicating that the file dapp 110 has obtained the chunk dapp 140 for storing of the chunk, wherein the allocate chunk response comprises the location of the chunk dapp 140.

[0273] Figure 10 further illustrates a carrier 1005, or program carrier, which provides, such as comprises, mediates, supplies and the like, the computer program 1003 as described directly above. The carrier 1005 may be one of an electronic signal, an optical signal, a radio signal and a computer readable medium.

[0274] In some embodiments, the file dapp 110 and / or the processing unit 1001 may comprise one or more of a receiving unit 1010, an allocating unit 1020, a sending unit 1030, an obtaining unit 1040, and a saving unit 1050 as exemplifying hardware units. The term "unit" may refer to a circuit when the term "unit" refers to a hardware unit. In other examples, one or more of the aforementioned exemplifying hardware units may be implemented as one or more software units.

[0275] Moreover, the file dapp 110 and / or the processing unit 1001 may comprise an Input / Output unit 1006, which may be exemplified by the receiving unit and / or the sending unit when applicable.

[0276] Accordingly, the file dapp 110 is configured for managing storing of one or more chunks representing a file. As mentioned, a system 100 includes a chain managing decentralized application 150, referred to as "platform dapp 150", the file dapp 110, a service node 120, at least one chunk storing decentralized application 140-14n, referred to as "chunk dapp 140- 14n". The platform dapp 150 manages, such as monitors, handles, and the like, the file dapp 110 and the chunk dapp 140. The chunk dapp 140 is registered with the file dapp 110.

[0277] Therefore, according to the various embodiments described above, the file managing decentralized application 110 and / or the processing unit 1001 and / or the receiving unit 1010 is configured for receiving, from the service node 120, an allocate file request comprising the filehash.

[0278] The file managing decentralized application 110 and / or the processing unit 1001 and / or the allocating unit 1020 is configured for allocating the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp 110.

[0279] The file managing decentralized application 110 and / or the processing unit 1001 and / or the sending unit 1030 is configured for sending, to the service node 120, an allocate file response indicating that the file is allowed to be stored.

[0280] The file managing decentralized application 110 and / or the processing unit 1001 and / or the receiving unit 1010, or another receiving unit (not shown), is configured for receiving, from the service node 120, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of a plurality of chunks forming the file.

[0281] The file managing decentralized application 110 and / or the processing unit 1001 and / or the obtaining unit 1040 is configured for obtaining a location for the chunk dapp 140 to store said each chunk. The file managing decentralized application 110 and / or the processing unit 1001 and / or the saving unit 1050 is configured for saving, on the hubchain, a respective record, comprising the respective chunkhash and the location.

[0282] The file managing decentralized application 110 and / or the processing unit 1001 and / or the sending unit 1030, or another sending unit (not shown), is configured for sending, to the service node 120, an allocate chunk response indicating that the file dapp 110 has obtained the chunk dapp 140 for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp 140.

[0283] With reference to the combined signaling and flow charts above, the service node 120 can perform a method for managing storing of a file. As mentioned, a system 100 includes a chain managing decentralized application 150, referred to as "platform dapp 150", a file managing decentralized application 110, referred to as "file dapp 110", the service node 120, at least one chunk storing decentralized application 140-14n, referred to as "chunk dapp 140-14n". The platform dapp 150 manages, such as monitors, handles, and the like, the file dapp 110 and the chunk dapp 140. The chunk dapp 140 is registered with the file dapp 110.

[0284] One or more of the following actions may be performed in any suitable order. The following actions have also been described above.

[0285] Action B210

[0286] The service node 120 receives the file.

[0287] Action B220

[0288] The service node 120 generates a filehash based on the file.

[0289] Action B230

[0290] The service node 120 sends, to the file dapp 110, an allocate file request comprising the filehash.

[0291] Action B280

[0292] The service node 120 splits the file into a plurality of chunks.

[0293] Action C210 The service node 120 sends, to the file dapp 110, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of the plurality of chunks.

[0294] Action C220

[0295] The service node 120 receives, from the file dapp 110, an allocate chunk response indicating that the file dapp 110 has obtained the chunk dapp 140 for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp 140.

[0296] Action C230

[0297] The service node 120 sends a proof request to the file dapp 110. The proof request comprises the respective chunkhash.

[0298] Action C231

[0299] The service node 120 receives a proof from the file dapp 110.

[0300] Action C232

[0301] The service node 120 sends said each chunk and the proof to the chunk dapp 140.

[0302] With reference to Figure 11, a schematic block diagram of embodiments of the service node 120 of Figure 1 is shown.

[0303] The service node 120 may comprise a processing unit 1101, such as a means for performing the methods described herein. The means may be embodied in the form of one or more hardware units and / or one or more software units. The term "unit" may thus refer to a circuit, a software block or the like according to various embodiments as described below. The service node 120 may further comprise a memory 1102. The memory may comprise, such as contain or store, instructions, e.g. in the form of a computer program 1103, which may comprise computer readable code units.

[0304] According to some embodiments herein, the service node 120 and / or the processing unit 1101 comprises a processing circuit 1104 as an exemplifying hardware unit. Accordingly, the processing unit 1101 may be embodied in the form of, or 'realized by', the processing circuit 1104. The instructions may be executable by the processing circuit 1104, whereby the service node 120 is operative to perform the methods of Figure 2 to Figure 9. As another example, the instructions, when executed by the service node 120 and / or the processing circuit 1104, may cause the service node 120 to perform the method according to Figure 2 to Figure 9.

[0305] In view of the above, in one example, there is provided a service node 120 for managing storing of a file. Again, the memory 1102 contains the instructions executable by said processing circuit 1104 whereby the service node 120 is operative for: receiving B210 the file, generating B220 a filehash based on the file, sending B230, to the file dapp 110, an allocate file request comprising the filehash, splitting B280 the file into a plurality of chunks, and sending C210, to the file dapp 110, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of the plurality of chunks, receiving C220, from the file dapp 110, an allocate chunk response indicating that the file dapp 110 has obtained the chunk dapp 140 for storing of the chunk, wherein the allocate chunk response comprises the location of the chunk dapp 140, sending C230 a proof request to the file dapp 110, wherein the proof request comprises the respective chunkhash, receiving C231 a proof from the file dapp 110, and sending C232 said each chunk and the proof to the chunk dapp 140.

[0306] Figure 11 further illustrates a carrier 1105, or program carrier, which provides, such as comprises, mediates, supplies and the like, the computer program 1103 as described directly above. The carrier 1105 may be one of an electronic signal, an optical signal, a radio signal and a computer readable medium.

[0307] In further embodiments, the service node 120 and / or the processing unit 1101 may comprise one or more of a receiving unit 1110, a generating unit 1120, a sending unit 1130, and a splitting unit 1140 as exemplifying hardware units. The term "unit" may refer to a circuit when the term "unit" refers to a hardware unit. In other examples, one or more of the aforementioned exemplifying hardware units may be implemented as one or more software units. Moreover, the service node 120 and / or the processing unit 1101 may comprise an Input / Output unit 1106, which may be exemplified by the receiving unit and / or the sending unit when applicable.

[0308] Accordingly, the service node 120 is configured for managing storing of a file. As mentioned, a system 100 includes a chain managing decentralized application 150, referred to as "platform dapp 150", a file managing decentralized application 110, referred to as "file dapp 110", the service node 120, at least one chunk storing decentralized application 140- 14n, referred to as "chunk dapp 140- 14n". The platform dapp 150 manages, such as monitors, handles, and the like, the file dapp 110 and the chunk dapp 140. The chunk dapp 140 is registered with the file dapp 110.

[0309] Therefore, according to the various embodiments described above, the service node 120 and / or the processing unit 1101 and / or the receiving unit 1110 is configured for receiving the file.

[0310] The service node 120 and / or the processing unit 1101 and / or the generating unit 1120 is configured for generating a filehash based on the file.

[0311] The service node 120 and / or the processing unit 1101 and / or the sending unit 1130 is configured for sending, to the file dapp 110, an allocate file request comprising the filehash. The service node 120 and / or the processing unit 1101 and / or the splitting unit 1140 is configured for splitting the file into a plurality of chunks.

[0312] The service node 120 and / or the processing unit 1101 and / or the sending unit 1130, or another sending unit (not shown), is configured for sending, to the file dapp 110, an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of the plurality of chunks. The service node 120 and / or the processing unit 1101 and / or the receiving unit 1110, or another receiving unit (not shown), is configured for receiving, from the file dapp 110, an allocate chunk response indicating that the file dapp 110 has obtained the chunk dapp 140 for storing of the chunk. The allocate chunk response comprises the location of the chunk dapp 140.

[0313] The service node 120 and / or the processing unit 1101 and / or the sending unit 1130, or another sending unit (not shown), is configured for sending a proof request to the file dapp 110. The proof request comprises the respective chunkhash. The service node 120 and / or the processing unit 1101 and / or the receiving unit 1110, or a further receiving unit (not shown) is configured for receiving the proof from the file dapp 110. The service node 120 and / or the processing unit 1101 and / or the sending unit 1130, again could be another sending unit (not shown), is configured for sending said each chunk and the proof to the chunk dapp 140.

[0314] With reference to the combined signaling and flow charts above, the least one chunk storing decentralized application 140- 14n can perform a method for storing at least one chunk of a file. A system 100 includes a chain managing decentralized application 150, referred to as "platform dapp 150", a file managing decentralized application 110, referred to as "file dapp 110", a service node 120, the chunk dapp 140-14n. The platform dapp 150 manages, such as monitors, handles, and the like, the file dapp 110 and the chunk dapp 140. The chunk dapp 140 is registered with the file dapp 110.

[0315] One or more of the following actions may be performed in any suitable order. The following actions have also been described above.

[0316] Action C434

[0317] The least one chunk storing decentralized application 140-14n receives, from the service node 120, said each chunk and the proof.

[0318] Action C436

[0319] The least one chunk storing decentralized application 140-14n checks that the proof is valid.

[0320] Action C445

[0321] The least one chunk storing decentralized application 140-14n decodes the proof to obtain a respective decoded chunkhash and a decoded identity e.g. related to a particular chunk dapp 140 for which the proof applies.

[0322] Action C450

[0323] The least one chunk storing decentralized application 140-14n determines that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash.

[0324] Action C455 The least one chunk storing decentralized application 140-14n determines that the related decoded identity matches an identity of the chunk dapp 140, the identity being known to the chunk dapp 140.

[0325] Action C460

[0326] The least one chunk storing decentralized application 140-14n stores said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp 140.

[0327] With reference to Figure 12, a schematic block diagram of embodiments of the chunk dapp 140 of Figure 1 is shown.

[0328] The chunk dapp 140 may comprise a processing unit 1201, such as a means for performing the methods described herein. The means may be embodied in the form of one or more hardware units and / or one or more software units. The term "unit" may thus refer to a circuit, a software block or the like according to various embodiments as described below. The chunk dapp 140 may further comprise a memory 1202. The memory may comprise, such as contain or store, instructions, e.g. in the form of a computer program 1203, which may comprise computer readable code units.

[0329] According to some embodiments herein, the chunk dapp 140 and / or the processing unit 1201 comprises a processing circuit 1204 as an exemplifying hardware unit. Accordingly, the processing unit 1201 may be embodied in the form of, or 'realized by', the processing circuit 1204. The instructions may be executable by the processing circuit 1204, whereby the chunk dapp 140 is operative to perform the methods of Figure 2 to Figure 9. As another example, the instructions, when executed by the chunk dapp 140 and / or the processing circuit 1204, may cause the chunk dapp 140 to perform the method according to Figure 2 to Figure 9.

[0330] In view of the above, in one example, there is provided a chunk dapp 140 for storing at least one chunk of a file. Again, the memory 1202 contains the instructions executable by said processing circuit 1204 whereby the chunk dapp 140 is operative for: receiving C434, from the service node 120, said each chunk and the proof, checking C436 that the proof is valid, decoding C445 the proof to obtain a respective decoded chunkhash and a decoded identity e.g. related to a particular chunk dapp 140 for which the proof applies, determining C450 that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash, determining C455 that the related decoded identity matches an identity of the chunk dapp 140, the identity being known to the chunk dapp 140, and storing C460 said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp 140.

[0331] Figure 12 further illustrates a carrier 1205, or program carrier, which provides, such as comprises, mediates, supplies and the like, the computer program 1203 as described directly above. The carrier 1205 may be one of an electronic signal, an optical signal, a radio signal and a computer readable medium.

[0332] In further embodiments, the chunk dapp 140 and / or the processing unit 1201 may comprise one or more of a receiving unit 1210, a checking unit 1220, a decoding unit 1230, a determining unit 1240, and a storing unit 1250 as exemplifying hardware units. The term "unit" may refer to a circuit when the term "unit" refers to a hardware unit. In other examples, one or more of the aforementioned exemplifying hardware units may be implemented as one or more software units.

[0333] Moreover, the chunk dapp 140 and / or the processing unit 1201 may comprise an Input / Output unit 1206, which may be exemplified by the receiving unit and / or the sending unit when applicable.

[0334] Accordingly, the chunk dapp 140 is configured for storing at least one chunk of a file. As mentioned, a system 100 includes a chain managing decentralized application 150, referred to as "platform dapp 150", a file managing decentralized application 110, referred to as "file dapp 110", a service node 120, the chunk dapp 140-14n. The platform dapp 150 manages, such as monitors, handles, and the like, the file dapp 110 and the chunk dapp 140. The chunk dapp 140 is registered with the file dapp 110. Therefore, according to the various embodiments described above, the chunk storing decentralized application 140- 14n and / or the processing unit 1201 and / or the receiving unit 1210 is configured for receiving, from the service node 120, said each chunk and the proof. The chunk storing decentralized application 140-14n and / or the processing unit 1201 and / or the checking unit 1220 is configured for checking that the proof is valid.

[0335] The chunk storing decentralized application 140-14n and / or the processing unit 1201 and / or the decoding unit 1230 is configured for decoding the proof to obtain a respective decoded chunkhash and a decoded identity e.g. related to a particular chunk dapp 140 for which the proof applies.

[0336] The chunk storing decentralized application 140-14n and / or the processing unit 1201 and / or the determining unit 1240 is configured for determining that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash.

[0337] The chunk storing decentralized application 140-14n and / or the processing unit 1201 and / or the determining unit 1240, or another determining unit (not shown), is configured for determining that the related decoded identity matches an identity of the chunk dapp 140, the identity being known to the chunk dapp 140.

[0338] The chunk storing decentralized application 140-14n and / or the processing unit 1201 and / or the storing unit 1250 is configured for storing said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp 140.

[0339] As used herein, the "subsequently to", "after", or the like, can refer to that one action is performed directly or indirectly following the performance of a preceding action, or at least portions thereof when applicable.

[0340] URL stands for Uniform Resource Locator.

[0341] As used herein, a cryptographic hash value, a hash, a hash value, a chunkhash, is a fixed-size string of characters generated from input data of arbitrary size. This process is accomplished using a hash function, which is a mathematical algorithm that transforms the input data into the hash value. The key characteristics of a cryptographic hash function can include one or more of the following properties. Deterministic - the same input always produces the same hash value. Fixed Output Size - the hash value has a fixed length regardless of input size. Preimage resistance - it is infeasible to reverse the hash to retrieve the original input. Collision resistance - it is infeasible for two different inputs to produce the same hash. Avalanche Effect - a small change in the input results in a significantly different hash value.

[0342] Cryptographic hash functions are used in digital signatures, data integrity verification, password hashing, and blockchain technology. Common examples include SHA-256 (Secure Hash Algorithm 256-bit) and MD5 (Message Digest Algorithm 5), and more.

[0343] As used herein, the term "response", "request", "message" refers to information capable of being sent between nodes in a network.

[0344] A file is any collection of data stored in a computer system, such as in a file system, or the like. The collection of data can be text, video, audio, signal data, tokens, and / or the like.

[0345] As used herein, the term "owner" refers to a natural person or legal entity capable of accepting payments and / or performing payouts.

[0346] As used herein, the term "record" can refer to a database record, e.g. arranged in structured format, a list, an array, a database, or the like.

[0347] As used herein, "msg" refers to "message", e.g. a message from one computer to another.

[0348] As used herein, the term "unit" may refer to one or more functional units, each of which may be implemented as one or more hardware units and / or one or more software units and / or a combined software / hardware unit in a node. In some examples, the unit may represent a functional unit realized as software and / or hardware of the node.

[0349] As used herein, the term "computer program carrier", "program carrier", or "carrier", may refer to one of an electronic signal, an optical signal, a radio signal, and a computer readable medium. In some examples, the computer program carrier may exclude transitory, propagating signals, such as the electronic, optical and / or radio signal. Thus, in these examples, the computer program carrier may be a non-transitory carrier, such as a non- transitory computer readable medium.

[0350] As used herein, the term "processing unit" may include one or more hardware units, one or more software units or a combination thereof. Any such unit, be it a hardware, software or a combined hardware-software unit, may be a determining means, estimating means, capturing means, associating means, comparing means, identification means, selecting means, receiving means, sending means or the like as disclosed herein. As an example, the expression "means" may be a unit corresponding to the units listed above in conjunction with the Figures.

[0351] As used herein, the term "software unit" may refer to a software application, a Dynamic Link Library (DLL), a software component, a software module, a software object, a React component, an object according to Component Object Model (COM), a software function, a software engine, an executable binary software file or the like.

[0352] The terms "processing unit" or "processing circuit" may herein comprise one or more processors, an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or the like. The processing circuit or the like may comprise one or more processor kernels.

[0353] As used herein, the expression "configured to / for" can refer to that a processing circuit can be configured to, such as adapted to or operative to, by means of software configuration and / or hardware configuration, perform one or more of the actions described herein.

[0354] As used herein, the term "action" may refer to an action, a step, an operation, a response, a reaction, a request, an activity or the like. It shall be noted that an action herein may be split into two or more sub-actions as applicable. Moreover, also as applicable, it shall be noted that two or more of the actions described herein may be merged into a single action.

[0355] As used herein, the term "memory" may refer to a hard disk, a magnetic storage medium, a portable computer diskette or disc, flash memory, random access memory (RAM) or the like. Furthermore, the term "memory" may refer to an internal register memory of a processor or the like.

[0356] As used herein, the term "computer readable medium" may be a Universal Serial Bus (USB) memory, a Digital Versatile Disc (DVD), a Blu-ray disc, a software unit that is received as a stream of data, a Flash memory, a hard drive, a memory card, such as a Multimedia Card (MMC), Secure Digital (SD) card, etc. One or more of the aforementioned examples of computer readable medium may be provided as one or more computer program products. As used herein, the term "computer readable code units" may be text of a computer program, parts of or an entire binary file representing a computer program in a compiled format or anything there between.

[0357] Any feature disclosed for one example and / or embodiment may be combined with one or more features disclosed for one or more other examples and / or embodiments without departing from the scope herein.

Claims

1. CLAIMS1. A method, performed by a system (100), for storing a file, wherein the system (100) includes a chain managing decentralized application (150), referred to as "platform dapp (150)", a file managing decentralized application (110), referred to as "file dapp (110)", a service node (120), at least one chunk storing decentralized application (140- 14n), referred to as "chunk dapp (140-14n)", wherein the platform dapp (150) manages the file dapp (110) and the chunk dapp (140), wherein the chunk dapp (140) is registered with the file dapp (110), wherein the method comprises: receiving (B210), by the service node (120), the file, generating (B220), by the service node (120), a filehash based on the file, sending (B230), by the service node (120) to the file dapp (110), an allocate file request comprising the filehash, allocating (B150), by the file dapp (110), the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp (110), sending (B160), by the file dapp (110) to the service node (120), an allocate file response indicating that the file is allowed to be stored, splitting (B280), by the service node (120), the file into a plurality of chunks, and repeatedly performing (B290) a set of actions for each chunk of the plurality of chunks, wherein the set of actions comprises: sending (C210), by the service node (120) to the file dapp (110), an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on said each chunk, obtaining (C114), by the file dapp (110), a location for the chunk dapp (140) to store said each chunk, saving (C116), by the file dapp (110) and on the hubchain, a respective record, comprising the respective chunkhash and the location, sending (C118), by the file dapp (110) to the service node (120), an allocate chunk response indicating that the file dapp (110) has obtained the chunk dapp (140) for storing of the chunk, wherein the allocate chunk response comprises the location of the chunk dapp (140),sending (C230), by the service node (120), a proof request to the file dapp (110), wherein the proof request comprises the respective chunkhash, generating (C131), by the platform dapp (150), a proof indicating that a transaction has occurred on the hubchain, wherein the transaction confirms that the chunk dapp (140), indicated by the location, has been selected for storage of said each chunk, sending (C132), by the file dapp (110), the proof to the service node (120), sending (C232), by the service node (120), said each chunk and the proof to the chunk dapp (140), checking (C436), by the chunk dapp (140), that the proof is valid, decoding (C445), by the chunk dapp (140), the proof to obtain a respective decoded chunkhash and a related decoded identity, determining (C450), by the chunk dapp (140), that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash, determining (C455), by the chunk dapp (140), that the related decoded identity matches an identity of the chunk dapp (140), the identity being known to the chunk dapp (140), and storing (C460), by the chunk dapp (140), said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp (140).

2. The method according to any one of the preceding claims, wherein the obtaining (C114) comprises selecting, by the file dapp (110), at least one chunk dapp (140) from a plurality of chunk dapps (140- 14n) that have been registered with the file dapp (110).

3. The method according to the preceding claim, wherein each chunk dapp (140-14n) of the plurality of chink dapps (140-14n) is associated with a respective chunkchain.

4. The method according to any one of the preceding claims, wherein the method comprises: sending (C222), by the service node (120) to the file dapp (110), an initiate chunk request, comprising the respective chunkhash for said each chunk and the location,marking (C125), by the file dapp (110) and in response to the initiate chunk request, the chunk identified by the respective chunkhash of the initiate chunk request as initialized, sending (C126), by the file dapp (110), an initiate chunk response to the service node (120), wherein the initiate chunk response indicates to the service node (120) that said each chunk has been initialized by the file dapp (110).

5. The method according to any one of the preceding claims, wherein said at least one chunk dapp (140-14n) comprises the chunk dapp (140) and a further chunk dapp (14n), wherein the chunk dapp (140) only stores a portion of the plurality of chunks and the further chunk dapp (14n) only stores a further portion of the plurality of chunks, wherein the portion of the plurality of chunks is at least partially non-overlapping with the further portion of the plurality of chunks.

6. The method according to any one of the preceding claims, wherein the location comprises a Uniform Resource Locator, "URL", -address and an identity of the chunk dapp (140).

7. The method according to any one of the preceding claims, wherein the method comprises, before the repeatedly performing (B290) of the set of actions, generating a set of chunkshashes based on the plurality of chunks, wherein the set of chunkhashes comprises the respective chunkhash generated based on said each chunk, or wherein the set of actions comprises generating () the respective chunkhash based on said each chunk, wherein the generating is performed, before the sending (C210) of the request, separately for said each chunk.

8. The method according to any one of the preceding claims, wherein the method comprises: sending (D210), by the service node (120), a filehash to the file dapp (110), fetching (D130), by the file dapp (110) and based on the filehash, file storage information, wherein the file storage information comprises a set of locations, and at least one respective chunkhash associated with each location of the set, and relatedreconstruction information, such as an index for each one of said at least one respective chunkhash, wherein the index preferably indicates a location within the file for a chunk corresponding to the chunkhash, sending (D140), by the file dapp (110), the file storage information to the service node (120), wherein the method comprises, for said each location: providing (E210), by the service node (120), said at least one respective chunkhash to a particular chunk dapp indicated by said each location of the file storage information, wherein the particular chunk dapp is selected from said at least one chunk dapp 140-14n, obtaining (E120), by the particular chunk dapp, a respective chunk for each chunkhash of said at least one respective chunkhash, e.g. from the chunkchain of said particular chunk dapp, sending (E130), by the particular chunk dapp, the respective chunk to the service node (120), receiving (E245), by the service node (120), a set of chunks from each chunk dapp (140-14n) of said at least one chunk dapp (140-14n), reconstructing (E250), by the service node (120), the file based on the set of chunks and the reconstruction information, and providing (E260), by the service node (120), the file.

9. The method according to any one of the preceding claims, wherein the method comprises: sending (F210), by the service node (120), a delete request, comprising a filehash of the file to be deleted, to the file dapp (110), deleting (F130), by the file dapp (110), each chunkhash associated with for the filehash of the delete request and a respective location associated with each chunkhash, and sending (F140), by the file dapp (110), a delete response to the service node (120), wherein the delete response indicates to the service node (120) that the deletion of the file associated with the filehash succeeded.

10. The method according to the preceding claim, wherein the chunks of the chunkhashes, associated with the filehash, remains stored by the respective chunk dapp (140-14n).

11. The method according to any one of the preceding claims, wherein the method comprises, after the set of actions, providing, by the service node (120), an indication that the file has been successfully stored by at least the chunk dapp (140).

12. A system (100) configured for storing a file, wherein the system (100) includes a chain managing decentralized application (150), referred to as "platform dapp (150)", a file managing decentralized application (110), referred to as "file dapp (110)", a service node (120), at least one chunk storing decentralized application (140-14n), referred to as "chunk dapp (140-14n)", wherein the platform dapp (150) manages the file dapp (110) and the chunk dapp (140), wherein the chunk dapp (140) is registered with the file dapp (110), wherein the system (100) is configured for: receiving, by the service node (120), the file, generating, by the service node (120), a filehash based on the file, sending, by the service node (120) to the file dapp (110), an allocate file request comprising the filehash, allocating, by the file dapp (110), the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp (110), sending, by the file dapp (110) to the service node (120), an allocate file response indicating that the file is allowed to be stored, splitting, by the service node (120), the file into a plurality of chunks, and repeatedly performing a set of actions for each chunk of the plurality of chunks, wherein the set of actions comprises: sending, by the service node (120) to the file dapp (110), an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on said each chunk, obtaining, by the file dapp (110), a location for the chunk dapp (140) to store said each chunk,saving, by the file dapp (110) and on the hubchain, a respective record, comprising the respective chunkhash and the location, sending, by the file dapp (110) to the service node (120), an allocate chunk response indicating that the file dapp (110) has obtained the chunk dapp (140) for storing of the chunk, wherein the allocate chunk response comprises the location of the chunk dapp (140), sending, by the service node (120), a proof request to the file dapp (110), wherein the proof request comprises the respective chunkhash, generating, by the platform dapp (150), a proof indicating that a transaction has occurred on the hubchain, wherein the transaction confirms that the chunk dapp (140), indicated by the location, has been selected for storage of said each chunk, sending, by the file dapp (110), the proof to the service node (120), sending, by the service node (120), said each chunk and the proof to the chunk dapp (140), checking, by the chunk dapp (140), that the proof is valid, decoding, by the chunk dapp (140), the proof to obtain a respective decoded chunkhash and a related decoded identity, determining, by the chunk dapp (140), that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash, determining, by the chunk dapp (140), that the related decoded identity matches an identity of the chunk dapp (140), the identity being known to the chunk dapp (140), and storing, by the chunk dapp (140), said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp (140).

13. The system (100) according to claim 12, wherein the system (100) is configured for selecting, by the file dapp (110), at least one chunk dapp (140) from a plurality of chunk dapps (140- 14n) that have been registered with the file dapp (110).

14. The system (100) according to the preceding claim, wherein each chunk dapp (140-14n) of the plurality of chink dapps (140-14n) is associated with a respective chunkchain.

15. The system (100) according to any one of claims 12-14, wherein the system (100) is configured for: sending, by the service node (120) to the file dapp (110), an initiate chunk request, comprising the respective chunkhash for said each chunk and the location, marking, by the file dapp (110) and in response to the initiate chunk request, the chunk identified by the respective chunkhash of the initiate chunk request as initialized, and sending, by the file dapp (110), an initiate chunk response to the service node (120), wherein the initiate chunk response indicates to the service node (120) that said each chunk has been initialized by the file dapp (110).

16. The system (100) according to any one of claims 12-15, wherein said at least one chunk dapp (140-14n) comprises the chunk dapp (140) and a further chunk dapp (14n), wherein the chunk dapp (140) only stores a portion of the plurality of chunks and the further chunk dapp (14n) only stores a further portion of the plurality of chunks, wherein the portion of the plurality of chunks is at least partially non-overlapping with the further portion of the plurality of chunks.

17. The system (100) according to any one of claims 12-16, wherein the location comprises a Uniform Resource Locator, "URL", -address and an identity of the chunk dapp (140).

18. The system (100) according to any one of claims 12-17, wherein the system (100) is configured for, before the repeatedly performing of the set of actions, generating a set of chunkshashes based on the plurality of chunks, wherein the set of chunkhashes comprises the respective chunkhash generated based on said each chunk, or wherein the set of actions comprises generating the respective chunkhash based on said each chunk, wherein the generating is performed, before the sending (C210) of the request, separately for said each chunk.

19. The system (100) according to any one of claims 12-18, wherein the system (100) is configured for: sending, by the service node (120), a filehash to the file dapp (110),fetching, by the file dapp (110) and based on the filehash, file storage information, wherein the file storage information comprises a set of locations, and at least one respective chunkhash associated with each location of the set, and related reconstruction information, such as an index for each one of said at least one respective chunkhash, wherein the index preferably indicates a location within the file for a chunk corresponding to the chunkhash, sending, by the file dapp (110), the file storage information to the service node (120), wherein the system (100) is configured for, for said each location: providing, by the service node (120), said at least one respective chunkhash to a particular chunk dapp indicated by said each location of the file storage information, wherein the particular chunk dapp is selected from said at least one chunk dapp 140- 14n, obtaining, by the particular chunk dapp, a respective chunk for each chunkhash of said at least one respective chunkhash, e.g. from the chunkchain of said particular chunk dapp, sending, by the particular chunk dapp, the respective chunk to the service node (120), receiving, by the service node (120), a set of chunks from each chunk dapp (140-14n) of said at least one chunk dapp (140-14n), reconstructing, by the service node (120), the file based on the set of chunks and the reconstruction information, and providing, by the service node (120), the file.

20. The system (100) according to any one of claims 12-19, wherein the system (100) is configured for: sending, by the service node (120), a delete request, comprising a filehash of the file to be deleted, to the file dapp (110), deleting, by the file dapp (110), each chunkhash associated with for the filehash of the delete request and a respective location associated with each chunkhash, andsending, by the file dapp (110), a delete response to the service node (120), wherein the delete response indicates to the service node (120) that the deletion of the file associated with the filehash succeeded.

21. The system (100) according to the preceding claim, wherein the chunks of the chunkhashes, associated with the filehash, remains stored by the respective chunk dapp (140-14n).

22. The system (100) according to any one of claims 12-21, wherein the system (100) is configured for, after the set of actions, providing, by the service node (120), an indication that the file has been successfully stored by at least the chunk dapp (140).

23. A method, performed by a file managing decentralized application (110), referred to as "file dapp (110)", for managing storing of one or more chunks representing a file, wherein a system (100) includes a chain managing decentralized application (150), referred to as "platform dapp (150)", the file dapp (110), a service node (120), at least one chunk storing decentralized application (140- 14n), referred to as "chunk dapp (140-14n)", wherein the platform dapp (150) manages the file dapp (110) and the chunk dapp (140), wherein the chunk dapp (140) is registered with the file dapp (110), wherein the method comprises: receiving (B140), from the service node (120), an allocate file request comprising the filehash, allocating (B150) the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp (110), sending (B160), to the service node (120), an allocate file response indicating that the file is allowed to be stored, receiving (C112), from the service node (120), an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of a plurality of chunks forming the file, obtaining (C114) a location for the chunk dapp (140) to store said each chunk, saving (C116), on the hubchain, a respective record, comprising the respective chunkhash and the location, andsending (C118), to the service node (120), an allocate chunk response indicating that the file dapp (110) has obtained the chunk dapp (140) for storing of the chunk, wherein the allocate chunk response comprises the location of the chunk dapp (140).

24. A computer program (1003), comprising computer readable code units which when executed by a file dapp (110) causes the file dapp (110) to perform the method according to claim 23.

25. A carrier (1005) comprising the computer program according to the preceding claim, wherein the carrier (1005) is one of an electronic signal, an optical signal, a radio signal and a computer readable medium.

26. A file managing decentralized application (110), referred to as "file dapp (110)", configured for managing storing of one or more chunks representing a file, wherein a system (100) includes a chain managing decentralized application (150), referred to as "platform dapp (150)", the file dapp (110), a service node (120), at least one chunk storing decentralized application (140- 14n), referred to as "chunk dapp (140-14n)", wherein the platform dapp (150) manages the file dapp (110) and the chunk dapp (140), wherein the chunk dapp (140) is registered with the file dapp (110), wherein the file dapp (110) is configured for: receiving, from the service node (120), an allocate file request comprising the filehash, allocating the file as being allowed to be stored by including the allocate file request, as a transaction, on a blockchain, referred to as "hubchain", managed by the file dapp (110), sending, to the service node (120), an allocate file response indicating that the file is allowed to be stored, receiving, from the service node (120), an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of a plurality of chunks forming the file, obtaining a location for the chunk dapp (140) to store said each chunk,saving, on the hubchain, a respective record, comprising the respective chunkhash and the location, and sending, to the service node (120), an allocate chunk response indicating that the file dapp (110) has obtained the chunk dapp (140) for storing of the chunk, wherein the allocate chunk response comprises the location of the chunk dapp (140).

27. A method, performed by a service node (120), for managing storing of a file, wherein a system (100) includes a chain managing decentralized application (150), referred to as "platform dapp (150)", a file managing decentralized application (110), referred to as "file dapp (110)", the service node (120), at least one chunk storing decentralized application (140-14n), referred to as "chunk dapp (140- 14n)", wherein the platform dapp (150) manages the file dapp (110) and the chunk dapp (140), wherein the chunk dapp (140) is registered with the file dapp (110), wherein the method comprises: receiving (B210) the file, generating (B220) a filehash based on the file, sending (B230), to the file dapp (110), an allocate file request comprising the filehash, splitting (B280) the file into a plurality of chunks, and sending (C210), to the file dapp (110), an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of the plurality of chunks, receiving (C220), from the file dapp (110), an allocate chunk response indicating that the file dapp (110) has obtained the chunk dapp (140) for storing of the chunk, wherein the allocate chunk response comprises the location of the chunk dapp (140), sending (C230) a proof request to the file dapp (110), wherein the proof request comprises the respective chunkhash, receiving (C231) a proof from the file dapp (110), and sending (C232) said each chunk and the proof to the chunk dapp (140).

28. A computer program (1103), comprising computer readable code units which when executed by a service node (120) causes the service node (120) to perform the method according to claim 27.

29. A carrier (1105) comprising the computer program according to the preceding claim, wherein the carrier (1105) is one of an electronic signal, an optical signal, a radio signal and a computer readable medium.

30. A service node (120) configured for managing storing of a file, wherein a system (100) includes a chain managing decentralized application (150), referred to as "platform dapp (150)", a file managing decentralized application (110), referred to as "file dapp (110)", the service node (120), at least one chunk storing decentralized application (140- 14n), referred to as "chunk dapp (140-14n)", wherein the platform dapp (150) manages the file dapp (110) and the chunk dapp (140), wherein the chunk dapp (140) is registered with the file dapp (110), wherein the service node (120) is configured for: receiving the file, generating a filehash based on the file, sending, to the file dapp (110), an allocate file request comprising the filehash, splitting the file into a plurality of chunks, and sending, to the file dapp (110), an allocate chunk request, comprising the filehash, and a respective chunkhash generated based on each chunk of the plurality of chunks, receiving, from the file dapp (110), an allocate chunk response indicating that the file dapp (110) has obtained the chunk dapp (140) for storing of the chunk, wherein the allocate chunk response comprises the location of the chunk dapp (140), sending a proof request to the file dapp (110), wherein the proof request comprises the respective chunkhash, receiving a proof from the file dapp (110), and sending said each chunk and the proof to the chunk dapp (140).

31. A method, performed by at least one chunk storing decentralized application (140- 14n), referred to as "chunk dapp (140-14n)", for storing at least one chunk of a file, wherein a system (100) includes a chain managing decentralized application (150), referred to as "platform dapp (150)", a file managing decentralized application (110), referred to as "file dapp (110)", a service node (120), the chunk dapp (140-14n), wherein the platform dapp(150) manages the file dapp (110) and the chunk dapp (140), wherein the chunk dapp (140) is registered with the file dapp (110), wherein the method comprises: receiving (C434), from the service node (120), each chunk of said at least one chunk and the proof, checking (C436) that the proof is valid, decoding (C445) the proof to obtain a respective decoded chunkhash and a related decoded identity, e.g. related to a particular chunk dapp (140) for which the proof applies, determining (C450) that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash, determining (C455) that the related decoded identity matches an identity of the chunk dapp (140), the identity being known to the chunk dapp (140), and storing (C460) said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp (140).

32. A computer program (1203), comprising computer readable code units which when executed by a chunk dapp (140) causes the chunk dapp (140) to perform the method according to claim 31.

33. A carrier (1205) comprising the computer program according to the preceding claim, wherein the carrier (1205) is one of an electronic signal, an optical signal, a radio signal and a computer readable medium.

34. A chunk storing decentralized application (140-14n), referred to as "chunk dapp (140- 14n)", configured for storing at least one chunk of a file, wherein a system (100) includes a chain managing decentralized application (150), referred to as "platform dapp (150)", a file managing decentralized application (110), referred to as "file dapp (110)", a service node (120), the chunk dapp (140- 14n), wherein the platform dapp (150) manages the file dapp (110) and the chunk dapp (140), wherein the chunk dapp (140) is registered with the file dapp (110), wherein the chunk dapp (140- 14n) is configured for: receiving, from the service node (120), said each chunk and the proof, checking that the proof is valid,decoding the proof to obtain a respective decoded chunkhash and a decoded identity (e.g. related to a particular chunk dapp (140) for which the proof applies), determining that a current chunkhash, generated based on said each chunk to be stored, matches the respective decoded chunkhash, determining that the related decoded identity matches an identity of the chunk dapp (140), the identity being known to the chunk dapp (140), and storing said each chunk in a respective block of a blockchain, referred to as "chunkchain", managed by the chunk dapp (140).

Images