Systems and methods implemented by computer storing data in blockchain

Abstract

To provide a method for storing data on a blockchain like a Bitcoin blockchain.SOLUTION: A method includes the step of generating a plurality of blockchain transactions, each of the plurality of blockchain transactions storing therein respective portions (<Content chunk 1> and <Content chunk 2>) of first data which should be stored in the blockchain and second data (<Metanet Flag>) indicating that the portions of the first data are associated with each other.SELECTED DRAWING: Figure 1

Description

[Technical field]

[0001] The present invention relates generally to cryptographic techniques for improvements in data communication and exchange across electronic networks, particularly peer-to-peer networks such as blockchain networks. The present invention relates to data storage, access, retrieval, and processing, and in particular to such data-related operations on blockchains. The present invention is particularly, but not exclusively, suitable for use in processing data in a manner similar to that provided by websites and web pages, but using blockchains rather than web servers as the underlying mechanism or platform. The present invention thus provides an alternative infrastructure for data processing and transfer, implemented with secure and efficient cryptography. [Background technology]

[0002] In this specification, we use the term "blockchain" to encompass all forms of electronic, computer-based, distributed ledgers. These include consensus-based blockchain and transaction chain technologies, permissioned and permissionless ledgers, shared ledgers, and variations thereof. Although other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin may be referred to herein for convenience and illustrative purposes, but it should be noted that the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are within the scope of the present invention. The term "user" as used herein may refer to a human or processor-based resource. The term "Bitcoin" is used herein to encompass all variations and versions of protocols derived from the Bitcoin protocol.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a computer-based decentralized distributed system, composed of blocks, which in turn are composed of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in the blockchain system, and contains at least one input and at least one output. Each block contains a hash of the previous block, and these blocks are chained together to create a permanent, immutable record of all transactions written to the blockchain since origin. Transactions contain small programs, known as scripts, that embed their inputs and outputs and specify how and by whom the transaction's outputs are accessible. In the Bitcoin platform, these scripts are written using a scripting language based on the stack.

[0004] In order for a transaction to be written to the blockchain, it must be validated. Network nodes (miners) perform the work to ensure that invalid transactions are rejected from the network and that each transaction is valid. A software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing the UTXO's lock and unlock scripts. If the execution of the lock and unlock scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, it must be (i) validated by the first node that receives the transaction, and if the transaction is valid, the node relays the transaction to other nodes in the network, (ii) added to a new block constructed by miners, and (iii) mined, i.e., added to the public ledger of past transactions.

[0005] Although blockchain technology is most widely known for its use in implementing cryptocurrencies, digital entrepreneurs are beginning to exploit the use of both the cryptographic security system on which Bitcoin is based and the data that can be stored on the blockchain to implement new systems. It would be highly advantageous if blockchain could be used for tasks and processes that are not limited to the field of cryptocurrencies. Such solutions could make their uses more diverse while taking advantage of the benefits of blockchain (e.g. permanence, tamper resistance of the record of events, decentralized processing, etc.).

[0006] One such area of ​​interest is the use of blockchain for the storage, sharing, access and control of data between users. Today, this is accomplished through the Internet and typically involves servers hosting websites and pages that users visit to access desired data through search engines.

[0007] However, some observers have begun to consider using blockchain to solve some of the shortcomings of the Internet, such as the control of vast amounts of data and content by a central party. See, for example, “Life After Google: The Fall of Big Data and the Rise of the Blockchain Economy”, George Gilder, Gateway Editions, July 2018, ISBN-10: 9781621575764 and ISBN-13:978-1621575764.

[0008] It would therefore be desirable to provide an arrangement that advantageously utilizes the decentralized, immutable, distributed and permanent characteristics of the blockchain to allow such data to be stored, processed, retrieved, searched and / or shared on the blockchain. Such an improved solution is herein devised. Summary of the Invention

[0009] The embodiments of the present disclosure provide at least alternative efficient and secure techniques for implementing blockchain solutions and storing, processing, searching, and / or retrieving data on or from a blockchain. The embodiments further provide at least alternative blockchain-implemented technical infrastructures for storing, processing, retrieving, transferring, searching, and / or sharing data between computing nodes. To enable blockchain networks to be used in new ways and to provide improved technical results, the present invention provides improved blockchain-implemented networks.

[0010] The embodiments further provide a solution for secure control of access to digital resources via technologically distinct improved computing platforms including blockchain and blockchain protocols.

[0011] The invention is defined in the accompanying claims.

[0012] In accordance with the present invention, a computer-implemented method and corresponding system may be provided. The method may be described as a method for enabling or controlling the processing, storage, retrieval, identification, and / or sharing of data via a blockchain, where "sharing" may include providing a node or user to send, communicate, transmit, or provide access to a portion of the data. The term "processing" may be interpreted to mean any activity related to a transaction or its associated data, including generating, sending, verifying, accessing, retrieving, sharing, submitting to a blockchain network, and / or identifying.

[0013] The method may include generating a plurality of blockchain transactions, each of the plurality of blockchain transactions storing therein a respective portion of first data to be stored on the blockchain and second data indicating that the portions of the first data are associated with each other.

[0014] By storing in multiple blockchain transactions respective portions of first data to be stored in the blockchain and second data indicating that the portions of first data are related to each other, this provides the advantage of allowing huge amounts of data to be stored in the blockchain, such that the data is permanently stored in distributed storage, thereby freeing the owners of the data from the need for data recovery means while allowing the data to be immediately reconstructed when required.

[0015] Each digital signature may be applied to the portion of the first data.

[0016] This provides the advantage that the first data can be more easily isolated from the second data and can be digitally signed by a third party independent of the second data, thereby making the process more generally applicable and allowing faster data processing, which makes the method more protocol independent.

[0017] At least some of the portions of the first data may each be digitally signed with a single private key of a public-private key pair of a cryptosystem.

[0018] This allows the portions of the first data to be easily reassembled, while also allowing the digital signature to be used in validating transactions as part of the mining process.

[0019] At least some of the portions of the first data may each be digitally signed using a respective private key of a public-private key pair of a cryptosystem, the private keys being related to each other.

[0020] At least one of the digital signatures may be based on a cryptosystem having a public-private key pair, where the private key is based on a number of prime numbers and a corresponding public key is based on a product of a number of the prime numbers.

[0021] This offers the advantage of providing a signature scheme that is computationally cheap to verify, thereby improving processing efficiency.

[0022] At least one of the digital signatures may be a Rabin signature.

[0023] This offers the advantage that distributors can provide authentication from the original source of the data using Rabin signatures, which allow the content itself to be signed by the original author to prove its authenticity.

[0024] The second data may include data relating to a recombination of the first data.

[0025] The first data may be included in multiple first inputs and / or first outputs of multiple of the blockchain transactions.

[0026] By storing the first data in a plurality of first inputs and / or first outputs, this provides the advantage of allowing data storage density within a transaction to be maximised.

[0027] At least one second input and / or at least one second output of at least one of the blockchain transactions may include indicative data indicating that the transaction includes the first data.

[0028] This provides the advantage of avoiding unnecessary processing of blockchain transactions that do not include the first data, thereby improving processing efficiency.

[0029] The second data may represent at least one attribute of the first data, which is at least one of a data type of the first data, a data encryption method, a data compression method, index information, permission information, encoding information, keyword information, or search information.

[0030] The first data may be included only in a first output of at least one of the plurality of blockchain transactions.

[0031] This provides the advantage of making it possible to check the validity of the transactions as part of the blockchain mining process. Data integrity is guaranteed through the existing miner validation process of the underlying blockchain. This allows the blockchain to be used as a trusted global server, where the integrity of the stored data is guaranteed by the miners and therefore can be stored and distributed by other parties without the need for trust.

[0032] At least one of the first output and / or the second output of at least one of the blockchain transactions may include a script opcode that marks the output as invalid for subsequent use as an input into a subsequent transaction.

[0033] This provides the advantage of avoiding processing the output as part of the unspent transaction output (UTXO) data, thereby improving processing efficiency. For example, the OP_RETURN operator may also be used to terminate an executable program embedded in the first data.

[0034] The method may further comprise the step of applying data compression to the first data and / or the second data.

[0035] The present invention also provides a system including a processor and a memory including executable instructions that, upon execution by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0036] The present invention also provides a non-transitory computer readable storage medium having stored thereon executable instructions which, when executed by a processor of a computer system, cause the computer system to at least perform a computer-implemented method as described herein.

[0037] These and other aspects of the invention will be apparent from and will be taught with reference to the embodiments described herein, which are described hereinafter, by way of example only, and with reference to the accompanying drawings, in which: [Brief description of the drawings]

[0038] [Figure 1] 1 illustrates a blockchain transaction embodying the present invention in which data is stored in multiple outputs. [Diagram 2] 1 illustrates a blockchain transaction embodying the present invention in which data is stored in an input. [Diagram 3] 1 illustrates a series of blockchain transactions embodying the present invention, where data is stored across the outputs of multiple blockchain transactions. [Figure 4] 1 illustrates a blockchain transaction embodying the invention, sending a cryptocurrency payment to grant access to data using an atomic swap. [Diagram 5] 5 shows a blockchain transaction embodying the invention that redeems the payment for the transaction of FIG. [Figure 6] 1 illustrates a secret value held by a participant in a blockchain transaction embodying the present invention that issues tokens to grant access to data using atomic swaps. [Figure 7] 1 illustrates a blockchain transaction embodying the present invention that issues tokens to grant access to data using atomic swaps. [Figure 8] 1 illustrates a blockchain transaction embodying the present invention that issues tokens to grant access to data using atomic swaps. [Figure 9] FIG. 9 shows a blockchain transaction embodying the invention for redeeming a token issued using the transaction of FIGS. 7 and 8. [Figure 10] FIG. 9 shows a blockchain transaction embodying the invention for redeeming a token issued using the transaction of FIGS. 7 and 8. [Figure 11] FIG. 11 shows a blockchain transaction for accessing the secret exchanged by the transactions of FIGS. 9 and 10. [Figure 12] FIG. 11 shows a blockchain transaction for accessing the secret exchanged by the transactions of FIGS. 9 and 10. [Figure 13] 1 provides an illustration of a meta-net graph structure according to an embodiment of the present invention. [Figure 14] 1 illustrates a representation of a metanet graph tree for the domain "bobslog" including an MURL search path, according to an embodiment of the present invention. [Figure 15] 1 shows an outline of an illustrative embodiment of a browser-wallet according to an example of the present invention and how its core functionality can be split across different components of the application. [Figure 16] 1 provides an illustration of how searching for content can be performed within the infrastructure of an embodiment of the present invention. [Figure 17]4 shows illustrative interactions between local and global full-copy peers in accordance with an embodiment of the present invention. [Figure 18] Illustrates a metanet tree (or graph) for use in referring to the illustrative use cases described below. [Figure 19] 1 shows a flow chart illustrating a process embodied in the illustrative use case described below. [Figure 20] FIG. 1 illustrates a schematic diagram of a computing environment in which various embodiments can be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0039] The term "Bitcoin" is used herein merely for convenience and is intended to include any cryptocurrency / blockchain protocol, including, but not limited to, all variations derived from the Bitcoin protocol, and any alternative protocols for other blockchains. In the remainder of this specification, the protocol that governs the operation of embodiments of the present invention will be referred to as the "Metanet Protocol."

[0040] The terms “content” and “data” may be used interchangeably herein to refer to data stored in a blockchain transaction in accordance with embodiments of the present invention.

[0041] <Summary> As discussed above, there is a recognized need for improved and / or alternative infrastructures for storing, writing, accessing, and viewing data. It would be advantageous to utilize the inherent advantages of blockchain technology (e.g., immutable records, cryptographically enforced control and access, embedded payment mechanisms, ability to publicly inspect the ledger, etc.). However, the construction of a "blockchain-enabled Internet" is challenging from many technical perspectives.

[0042] These challenges may include, but are not limited to, how to protect and control access to certain portions of data within the network, such that only authorized parties can gain access; how to transfer data from party to party in a peer-to-peer manner; how to organize data so that it can be logically related while still being stored in different locations within the network, and how to later combine data from different locations to provide aggregated and augmented results; how to provide and / or store data in a hierarchical manner; how to allow users and parties having different computing platforms access to desired data; how to store, provide, and share data across a (potentially global) computing network without relying on or requiring large-scale storage servers and centralized data controllers; and how to improve the efficiency of such data-related activities over the network.

[0043] The present invention provides such an improved solution, which achieves its results in a completely different way, in a manner similar to the Internet in some respects, but using a completely different platform of hardware and software components than those known in the art. According to an embodiment of the present invention, the servers that store the Internet / Web data and provide it to end users are replaced by blockchain transactions that exist on a blockchain network. To achieve this, several innovations had to be devised. These are described in the following sections.

[0044] <Inserting data into the blockchain "Metanet"> Referring to Figure 1, a blockchain transaction embodying the present invention is shown, in which first data to be stored on the blockchain is stored in one or more first outputs of the transaction, and second data representing attributes of the first data is stored in one or more second outputs of the transaction.<Content 1> The data is stored in the transaction's spendable outputs.<Attribute 1> and<Attribute 2> represent attributes of the first data, each together with a flag indicating that the data has been stored according to the Metanet protocol, and are stored in a second, unspendable output of the transaction. The term "unspendable" is used to indicate that at least one of the first and / or second outputs of the transaction may include a script opcode (OP RETURN) that marks the output as invalid for later use as an input to a later transaction.

[0045] It is advantageous to store the content and attributes of the data in separate outputs of the transaction.

[0046] Figure 2 shows the first data to be stored on the blockchain.<Content 1> 1 shows a block chain transaction embodying the present invention, in which the following is stored in the input of the transaction: Metanet flags, and attribute data<Attribute 1> and<Attribute 2> is stored in the unspent output of the transaction in a manner similar to the configuration shown in Figure 1.

[0047] <insert data> <How to insert data> It is desirable to be able to insert the following data into the blockchain: a) Metanet Flag b) Attributes c) Content

[0048] Content is the data to be stored on the blockchain, Metanet flags are a 4-byte prefix that acts as an identifier for any data related to the Metanet protocol, while attributes contain index, permission, and encoding information about the content.

[0049] This may include, but is not limited to, data type, encryption and / or compression scheme. Such attributes are sometimes referred to as metadata. This term is avoided herein to avoid confusion with transaction metadata.

[0050] The following techniques can be used to embed this data within Bitcoin scripts:

[0051] 1. OP_RETURN: In this method, all data (attributes and content) is placed after OP_RETURN in the lock script of obviously unusable transaction output. An example of an output script using this operator is as follows: UTXO0:OP_RETURN<Metanet Flag> <attributes> <content>

[0052] 2. OP_RETURN with OP_DROP: In this case, the OP_RETURN contains attributes while the content is stored before the OP_DROP in the available transaction script (either lock or unlock). The content can be split into multiple data packets in the transaction inputs and outputs. However, since only output scripts can be signed in the Bitcoin protocol, it is advantageous to insert the data into the transaction output. If the data is inserted into the transaction input, OP_MOD can be used as a checksum on the data to ensure its validity, instead of a miner verification. For example, one could perform a 32-bit OP_MOD operation and check that it is equal to a pre-computed value.

[0053] In this case, the attribute may contain information about how the content data packets are recombined. Furthermore, providing the hash of the recombined data packets H(content1 + content2) as an attribute makes it possible to verify that the recommended recombination scheme is used.

[0054] A transaction implementing the second data insertion method is shown in Figure 1. For simplicity, this transaction only contains content inserted into its output that is signed by its single input. Content inserted into additional inputs may also be possible using the OP_DROP statement, using the method shown in Figure 2.

[0055] If the content is very large, it may be advantageous to split the content into multiple transactions. Such an arrangement is illustrated in Figure 3. Figure 3 shows a pair of blockchain transactions embodying the invention, where the first data to be stored in the blockchain is <content>There are two chunks<Content chunk 1> and<Content chunk 2> These are divided into: <content>=<Content chunk 1> ||<Content chunk 2> where the operator "||" concatenates the two chunks of content data. This concatenation operator may be replaced by any desired bitwise or similar piecewise binary operation.<Content chunk 1> and<Content chunk 2> are then stored in the respective appropriate outputs of separate blockchain transactions, while data relating to attributes of the content data are stored in the respective unusable outputs of the blockchain transactions. Again, the attributes may include information regarding the recombination scheme. For example, the content may be raw data, an executable program, or an HTML web page. Additionally, content1 may include a pointer to the location of content2 on the blockchain, which functions in the same manner as an embedded HTML link in a web page.

[0056] Note that both transactions take the same public key P (and ECDSA signature) as input. As a result,<Content chunk 1> and<Content chunk 2> may be associated with the same public key P even though they are stored in different transactions having TxID1 and TxID2, respectively.

[0057] <Developing the role of minor verification> Now, the transaction validation process performed by the miners is used to gain an advantage when storing this data, since all data in the transaction output is signed by the owner of the public key P in at least one transaction input (if the SIGHASH|ALL flag is present), and this signature is checked in the transaction validation process performed by all miners.

[0058] This ensures that: · Data integrity: If the data is corrupted, the CHECKSIG operation fails. · Data reliability: It is proven that the owner of P has proven and signed the data.

[0059] This is particularly advantageous for content split across multiple transactions when, as described above with reference to the configuration shown in Figure 3, the input signature of P provides a provable link between the split components of the data.

[0060] <Rabin signature> Another way to prove data reliability is to use Rabin signatures. These can be used to sign the data itself rather than the entire message. This can be advantageous as the signer does not need to sign every individual transaction in which the data appears, and the signature can be reused across multiple transactions.

[0061] Rabin signatures can be easily verified within a script. These can be incorporated into case (2) above by inserting Rabin signature verification before the OP_DROP command. That is, <content1><Rabin Sig (content1)> FUNC_CHECKRABSIGOP_DROP <H(P1)>[CheckSig P1] It should be noted that this cannot be done in the above case (1) because any script containing OP_RETURN will fail anyway and thus cannot reach verification.

[0062] <Specific Example of Using Rabin Signature> <Introduction> Digital signatures are a fundamental part of the Bitcoin protocol. They ensure that any Bitcoin transaction recorded on the blockchain is authenticated by the legitimate holder of the Bitcoin being sent. In a standard Bitcoin P2PKH transaction, the transaction message is signed using the elliptic curve digital signature algorithm (ECDSA). However, ECDSA signatures are typically applied to the entire transaction.

[0063] There are several use cases of the Bitcoin blockchain where an external participant to the network may desire to provide signatures for any data type made available by network participants. By using the Rabin digital signature, any piece of data can be signed even if it originates outside the Bitcoin blockchain and is placed within one or more transactions.

[0064] The following shows how data can be directly signed and verified within a Bitcoin script by leveraging the algebraic structure of the Rabin cryptosystem.

[0065] <Rabin Digital Signature> <Rabin Digital Signature Algorithm> <Underlying Mathematical Processing> Definition: Integers mod p The integers modulo p are defined as the set

number

[0066] Fermat's Little Theorem Let p be a prime number. Next, apply the following to any integer a:

number

[0067] Euler's criterion Let p be a prime number. r is a quadratic modulo p if and only if

number

[0068] Modular square root (p=3 mod 4) Let p be a prime number, as follows:

number

number

number

[0069] Chinese Remainder Theorem mutually prime positive integers n1,n2,...,n k and any integers a1, a2,...,a k Given a pair of , the following system of simultaneous congruences is N=n1n2...n k It has a unique solution modulo .

number

Mathematics

Mathematics

[0070] <Rabin Digital Signature Algorithm> The Rabin Digital Signature Algorithm can be explained as follows.

[0071] For any message m, let H be a collision-resistant hash algorithm with k output bits.

[0072] To generate the keys, select prime numbers p and q, each of length approximately k / 2, such that the following equation

Mathematics

[0073] To sign the message m, the signer selects padding U such that the following equation is satisfied.

Mathematics

Mathematics

Mathematics

Number

[0074] The advantageous features of the Rabin signature scheme are as follows. a) Signature generation is computationally expensive, but signature verification is computationally easy. b) The security of the signature depends only on the difficulty of prime factorization. As a result, the Rabin signature is (unlike RSA) essentially forgery-proof. c) The following hash function values must be of the same size as the public key n.

Number

Number

[0075] <Rabin Signature Proof> Let p and q be prime numbers, and n = p·q. By the Chinese Remainder Theorem, the following expression:

Number

Number

Number

Number

Math

Math

Math

[0076] <Rabin Signature in Bitcoin> <Signature Verification within Script> To verify a Rabin signature, only a few arithmetic and stack operation opcodes are needed. Consider a Redeem script of the following form. OP_DUP OP_HASH160 <H 160 > OP_EQUALVERIFY OP_MUL OP_SWAP OP_2 OP_ROLL OP_CAT FUNC_HASH3072 OP_ADD OP_SWAP OP_DUP OP_MUL OP_EQUAL

[0077] Here, n is the signer's public key. This evaluates to true (TRUE) if and only if the following input is provided. <s> <m><λ> <n>

[0078] where m is an arbitrary message and (S, λ, U) is a valid Rabin signature. Alternatively, if the Rabin signature is verified using Equation 1 above, then the Redeem script can be given as OP_DUP OP_HASH160 <H 160 > OP_DUP OP_TOALTSTACK OP_SWAP<roll index> OP_ROLL OP_CAT FUNC_HASH3072 OP_SWAP OP_MOD OP_SWAP OP_DUP OP_MUL OP_FROMALTSTACK OP_MOD OP_EQUAL

[0079] In this case, the script will evaluate to TRUE if and only if the following input is provided: <s> <m> <n>

[0080] Both Redeem scripts use a 3072-bit hash projection function, "FUNC_HASH3072". For a given message / padding concatenation, a FUNC_HASH3072 hash projection is generated using the following script: OP_SHA256 {OP_2 OP_SPLIT OP_SWAP OP_SHA256 OP_SWAP} (x11) OP_SHA256 OP_SWAP OP_SHA256 {OP_CAT}(x11)

[0081] <Data compression> Internet data consists of JavaScript and common file types such as text files (SML, HTML, etc.), video files (MPEG, M-JPEG, etc.), image files (GIF, JPEG, etc.), and audio files (AU, WAV, etc.), as detailed in, for example, https: / / www.doc.ic.ac.uk / ~nd / surprise_97 / journal / vol1 / mmp / #text. Using the data insertion techniques described above, these different data types can also be embedded into the blockchain.

[0082] Large file sizes can be compressed using one of several existing encoding methods before being embedded into the blockchain. Lossless data compression algorithms such as run-length Huffman coding can be used in several applications, including ZIP files, executable programs, text documents, and source code.

[0083] There are many different algorithms, depending on the particular input data. Apple Lossless and Adaptive Transform Acoustic Coding can be used to compress audio files, PNG and TIFF for compressing graphic files, while video files can be compressed using one of many lossless video codecs. Optional compression of the data content can be indicated using flags in the attributes. For example, the flag for the LZW lossless encoding method in the attributes is: <lzw>It could be.

[0084] <Encryption and paid decryption> <Data Encryption> Content owners may choose to protect their content before embedding it on the blockchain, ensuring that the content cannot be viewed without obtaining the necessary permissions.

[0085] There are many established techniques for encrypting data (plaintext or other data types). These can be classified as asymmetric or symmetric encryption.

[0086] Elliptic Curve Cryptography (ECC) is asymmetric because it relies on a public-private key pair. It is one of the most secure cryptosystems and is typically used in cryptocurrencies such as Bitcoin. ECC cryptography uses the Koblitz algorithm to encrypt data.

[0087] In symmetric methods, a single key is used to both encrypt and decrypt data. The Advanced Encryption Standard (AES) algorithm is considered one of the most secure symmetric algorithms seeded with a kind of secret and is described in detail, for example, in C. Paar and J. Pelzl, Chapter 4 in "Understanding Cryptography," Springer-Verlag Berlin Heidelberg 2 nd Ed., 2010, pp. 87-118.

[0088] When encrypting data stored in a blockchain, there are advantages to using the same cryptosystem as the underlying blockchain. In Bitcoin, this is the secp256k1 rule for ECC key pairs for asymmetric cryptography, and the SHA-256 hash function for symmetric cryptography. These advantages are: · The encryption security level is the same as the underlying system on which the data is stored. The software architecture required to store the encrypted data has a smaller code base. · Key management within the wallet can be used for both transactions and encryption / decryption. It is more efficient, since the same key can be used for both encryption and payments in cryptocurrency, and fewer keys are needed. This also reduces storage space. Fewer communication channels are needed to exchange / purchase the ability to decrypt data. The keys used for encryption and transactions are the same data structures, improving security and mitigating attacks targeting specific types of keys. · Keys can be purchased using the underlying cryptocurrency.

[0089] For purposes of illustration, we will explain how the Koblitz algorithm can be used to encrypt data using ECC.

[0090] <Koblitzアルゴリズム> Given an ECC key pair P1 = S1 · G, the Koblitz algorithm allows anyone to encrypt a message using the public key P1, so that only those who know the corresponding private key S1 can decrypt the message.

[0091] Suppose we want to encrypt the message "hello world" using the Koblitz algorithm. This is done character by character. The first letter "h" is encrypted and decrypted as follows:

[0092] 1. The letter 'h' is mapped to a point on the secp256k1 curve. This is accomplished using the ASCII rules for mapping plaintext characters to 8-bit numeric values. The point on the curve is then calculated by multiplying the base point G by this number. In this example, "h" maps to ASCII 104, and the elliptic curve point is P m = 104 G.

[0093] 2. Point P m is then encrypted using the public key P1. This involves choosing a random ephemeral key k0 and encrypting the pair of points C m This is achieved by computing ={k0·G,Q}, where Q:=P m +k0·P1, which may then be broadcast.

[0094] 3. The owner of the private key S1 is P m = Q-S1 k0 G. They can then recover the original ASCII numbers by trial and error or by using a lookup table to determine which number x is P. m = x G.

[0095] Using blockchain to buy permissions Storing data on the blockchain has the obvious advantage that a payment mechanism is built into the system. Payments can be used to purchase: Decrypt data for viewing / use. Permission to insert data at a specific address.

[0096] In both cases, buyers are using cryptocurrency, e.g. Bitcoin, to purchase a secret that gives them permission to do something. This secret can be a hashed pre-image, or a private key.

[0097] An efficient and secure way to make such purchases is to use atomic swaps, which minimize the need for secure communication channels and guarantee that the seller is never paid, the secret is never revealed to the buyer, or any other event occurs.

[0098] In addition to paying with cryptocurrency, it can also be convenient to purchase permissions using access tokens, which are secret values ​​(typically hashed pre-images) owned by the buyer that the buyer can use to make purchases. Such tokens can be purchased in bulk by buyers in advance and activated when they actually want to use the permissions.

[0099] In the following, we will explain how an atomic swap is performed with reference to Figures 4 and 5.

[0100] <Atomic swap using hash puzzle or private key puzzle> Suppose Alice is the owner of a secret. This secret can be a hash preimage of a known hash digest, or a private key of a known public key. Suppose Bob wants to use Bitcoin to buy this secret from Alice. A mechanism known as an atomic swap is described that allows this transaction to occur. It is atomic in the sense that either Alice is paid Bitcoin, the secret is revealed to Bob, or no event occurs.

[0101] The method is as follows. Alice has a public / private key pair P A =S A G's private key S A Bob owns a public / private key pair P B =S B G's private key S B Owns. Alice possesses a secret that is a pre-image X of a known hash digest H(X) or a private key S1 of a known public key P1 = S1 · G. They agree on the price of Bitcoins for which Alice sells the secret to Bob. Prior to all of this, Bob must set up a transaction off-block to send Alice the ephemeral key k0 so that she can calculate the digital signature component r0.

[0102] Now, reference is made to FIG. 1. Bob transfers funds locked by Redeem script R (described briefly below) to Alice. Regarding hash preimage,

number

number

[0103] 2. Now that Alice knows her secret (X or S1), she can spend her funds on the Bitcoin blockchain using the transaction shown in Figure 5. This allows Bob to determine her secret.

[0104] As an optional security feature, Alice and Bob may use their public keys P to establish a shared secret S known only to both parties. A , P B This may be accomplished in the manner outlined in International Patent Publication No. WO2017 / 145016. In this case, S may be added to the pre-image X in the hash puzzle to ensure that X is not publicly disclosed on the blockchain. Similarly, in the private key puzzle, S may be used as a temporary key k0 to ensure that only Alice or Bob can compute the private key.

[0105] To prevent Bob's funds from being locked by Alice if she does not pay her funds, time-locked funds can be introduced into the procedure.

[0106] <Purchase using tokens> Suppose the same situation exists as above, but instead of paying cryptocurrency for Alice's secret, at the point of use, Bob may want to redeem a previously purchased access token in exchange for the secret.

[0107] The procedure that Alice and Bob have to follow is similar to that described in the previous section, but instead uses the same sequence of atomic swaps. There are two phases of the process: token issuance and token redemption.

[0108] Phase 1: Token Issuance The token issuance phase is effectively a one-time purchase of tokens by Bob. For example, Alice issues 10 distinct secrets X1, X2, ..., X 10 Bob has 10 tokens T1,T2,...,T 10 Consider a scenario where you want to make a one-time purchase of

[0109] First, Bob generates a set of 10 tokens from a secret seed value Y known only to him. These tokens are generated by sequential hashing of the seed, forming a hash chain, where each token is calculated as follows:

number

number

[0110] Now, Alice and Bob can agree on a price of 10 cryptocurrency units for the purchase of 10 tokens. The purchase of these tokens can occur in a number of ways, which is illustrated here using an atomic swap. An atomic swap is initiated by Alice and Bob broadcasting the transactions shown in Figures 7 and 8, respectively. In both transactions, the outputs require the solution to two hash puzzles and a valid signature.

[0111] Once both transactions appear on the blockchain, Alice and Bob will update their initializer values ​​I Alice and I Bob They can share and complete atomic swaps to issue tokens.

[0112] As a result of this atomic swap, Alice receives payment for the purchase of 10 tokens and both initializer secrets are revealed. Note that Bob’s secret I Bob =H 10 Only (Y) is meaningful because it defines the first hash puzzle to be solved [HashPuzzle (T1)]. The solution to this puzzle is given by the initializer H 10 Pre-image H of (Y) 9 (Y).

[0113] Phase 2: Token Redemption At some point in the future, Bob will receive his first token T1=H 9 Y wishes to redeem (Y) and receive his initial secret X1, but he has already paid for this secret by purchasing a valid token. The process of redeeming a token takes the form of another atomic swap, where the solution to the lock hash puzzle is to redeem the token T i , and the corresponding secret X i It is.

[0114] To redeem his tokens, Bob must broadcast a transaction whose outputs are locked by two hash puzzles, as shown in Figure 9. When Alice sees this transaction, she broadcasts a similar transaction of her own, as shown in Figure 10, whose outputs are locked by the same two hash puzzles. The two participants can now exchange their secrets T1 and X1 and unlock the outputs of these transactions. Both parties can now redeem the nominal fee x by providing the correct unlock script that also reveals both secrets. The transactions with these unlock scripts are shown in Figures 11 and 12.

[0115] Completing this atomic swap to redeem the token involves disclosing Alice's initial secret X1 to Bob, disclosing Bob's initial secret T1 to Alice, and exchanging cryptocurrency funds for a total of zero, provided that the amount x is large enough to incentivize both parties to spend the locked output. Crucially, this also establishes that the next token Bob can spend must be a solution T2 to the hash puzzle H(T2), where the target hash H(T2)=T2 is disclosed to Alice. This process also establishes that Bob will receive his final token T 10 You can repeat recursively until you use Y.

[0116] <Naming and addressing> <Node and edge structure> Above we have described how data can be inserted into the blockchain by providing it in a transaction. Below we present a protocol that structures these transactions in a logical way that allows for node addressing, permissioning, and content versioning. The structure of this decentralized peer Metanet is similar to the existing Internet.

[0117] Of note, this is a “tier-2” protocol that does not change the underlying blockchain protocol or rules of consensus.

[0118] The purpose of the structure described here is to: (i) Associating related content within different transactions and enabling data to be searched, identified, and accessed. (ii) enabling identification of content using human-readable keyword searches to improve the speed, accuracy and efficiency of searches; (iii) Building and emulating server-like structures within the blockchain.

[0119] Our approach is to structure the data associated with the Metanet as a directed graph, where the nodes and edges correspond to the following:

[0120] Node: A transaction associated with the Metanet protocol. A node stores content. (The terms "content" and "data" are sometimes used interchangeably herein.)

[0121] The node is immediately<Metanet Flag> Each node has a public key P node The combination of the public key and the transaction ID uniquely specifies the index of the node below.

number

[0122] The hash function used must be consistent with the underlying blockchain protocol: in the case of Bitcoin, the present invention should be used with SHA-256 or RIPEMD-160.

[0123] Edge: The association of a child node with a parent node. The edge is signed Sig P parent appears in the input of a Metanet transaction. Thus, only parents can be allowed to create edges. Every node may have at most one parent, and a parent node may have any number of children. In graph theory terms, the in-degree of each node is at most 1, and the out-degree of each node is arbitrary.

[0124] It is important to note that an edge is an aspect of the Metanet protocol and is not itself a transaction associated with the underlying blockchain.

[0125] A valid Metanet node (one that has a parent) is given a transaction of the following form: [Table 1] [Table 1]

[0126] This transaction contains all the information necessary to specify the index of a node and its parent.

number

[0127] Furthermore, the signature of the parent node is required so that only parents can create edges to their children. <T x ID parent If the field is absent or it does not point to a valid Metanet transaction, the node is an orphaned child: it has no higher-level nodes reachable by it.

[0128] Additional attributes may be added to each node. These may include flags, names, and keywords. These are described later in this specification.

[0129] As shown, the index of nodes (transactions) can be decomposed into: a) Public key (P node ): This is interpreted as the address of the node. b) Transaction ID (TxID) node ): This is interpreted as the version of the node.

[0130] Two advantageous features arise from this structuring. 1. Version Control: If there are two nodes with the same public key, the node with the transaction ID having the maximum proof-of-work is interpreted as the latest version of that node. If the nodes are in different blocks, this can be checked by block height. For transactions within the same block, this is determined by the Topological Transaction Ordering Rule (TTOR). 2. Permission: A child of a node can only be generated if the owner of the public key P node signs the transaction input in the generation of the child node. Thus, P node represents not only the address of the node but also the permission for the generation of child nodes. This is intentionally similar to a standard Bitcoin transaction. That is, the public key is not only an address but also the permission associated with that address.

[0131] Note that since the signature of the parent node appears in the UXTO unlock script, it is verified through the standard miner verification process when the transaction is accepted by the network. This means that the permission to generate a child node is verified by the Bitcoin network itself.

[0132] It is worth noting that a standard Internet Protocol (IP) address is unique only within a network at a specific point in time. On the other hand, the index of a node within the Metanet is unique at all times, and there is no concept of separate networks. This allows data to be permanently anchored to a single object ID node .

[0133] The node and edge structure allows the Metanet to be visualized as a graph, as shown in Figure 13.

[0134] <Domains, Naming, and Content Location within the Metanet> The hierarchical structure of the Metanet graph makes a rich domain-like structure emerge: we interpret nodes with no parents as top-level domains (TLDs), children of parentless nodes as subdomains, grandchildren as sub-subdomains, etc., and nodes with no children as endpoints. See Figure 13.

[0135] Domain name is ID node Each top-level domain in the Metanet can be thought of as a tree, with the root being a node with no parents, and the leaves being nodes with no children. The Metanet itself is a global collection of trees that form a graph.

[0136] Although the Metanet protocol does not specify that any node contains content data, leaf (child) nodes represent the ends of directed paths in the data tree and are therefore typically used to store content data. However, content may be stored at any node in the tree. Protocol-specific flags included as attributes in the node may be used to specify the role of the node in the data tree (disk space, folder, file, or permission changes).

[0137] Recall that the Internet uses the Domain Name System (DNS) to associate human readable names with Internet Protocols (IPs). The DNS is decentralized in some sense, but in practice it is controlled by a few major players like governments and large corporations. Depending on the DNS provider, the same name may go to different addresses. The problem arises when mapping short human readable names to computer generated numeric values.

[0138] We use human-readable top-level domain names as the decentralized index ID of the root node. root In other words, there exists a one-to-one function k that maps human readable names to Metanet root node indices:

number

[0139] Map k should be interpreted as a means to ensure backward compatibility of the Metanet with the Internet in reproducing the human readability of domain names published by the DNS, but the naming and addressing schemes that provide the structure of the Metanet do not explicitly depend on this map.

[0140] Possible forms for the mapping function k include the DNSLink system used by IPFS (Interplanetary File System) or the OpenNIC service (https: / / www.openic.org). This mapping can be stored as part of DNS in an existing TXT record, similar to DNSLink in IPFS, see https: / / docs.ipfs.io / guides / concepts / dnslink / . However, these usually sacrifice some element of decentralization to provide a one-to-one map, see https: / / hackernoon.com / ten-terrible-attempts-to-make-the-inter-planetary-file-system-human-friendly-e4e95df0c6fa.

[0141] <Vanity address> Public keys used as addresses of Metanet nodes are not human-readable objects. This can make search, lookup, and input activity error-prone and slow for human users. However, there are human-readable public key addresses, i.e. vanity addresses P, that contain a plaintext prefix that is directly interpretable by a user. vanity It is possible to generate a vanity address.

[0142] The difficulty in generating such addresses depends on the character length of the desired prefix. This means that human-recognizable vanity addresses may be used as node addresses that are not issued by a central authority and rely only on the effort of the owner to generate them. For a given prefix, there are many different vanity addresses depending on the remaining characters in the suffix. Thus, many node addresses can share a common prefix while still retaining uniqueness.

[0143] Examples of vanity addresses with desirable prefixes are: Pbobsblog:bobsblogHtKNngkdXEeobR76b53LETtpyT Prefix:bobsblog Suffix:HtKNngkdXEeobR76b53LETtpyT

[0144] The vanity address above is derived from the node index ID "bobsblog" bobsblog This may be used to sense check the mapping to , and to aid in the discoverability of nodes in the Metanet by address. Note that the prefixes are not unique here, but the entire address itself is a unique entity.

[0145] Selected address P vanity The combination of TxID is ID node , which is advantageous since it means there is a decentralized issuer of domain names (TxIDs are generated with decentralized proof-of-work) and names are recoverable from the blockchain itself. Advantageously, there are no longer any points of failure that exist within the Internet DNS.

[0146] Metanet domains already provide a permissioning system (public keys), so there is no need to issue certificates to prove ownership. Using blockchain for this purpose is explored, for example, in namecoin (https: / / namecoin.org / ). In accordance with the present invention, however, there is no need to use a separate blockchain for this function, since everything is accomplished within one blockchain.

[0147] This significantly reduces the amount of resources (hardware, processing resources, and energy) required by the present invention compared to the prior art. The present invention also provides a completely different architecture in terms of the configuration of equipment and system components.

[0148] The advantage of this naming system is that it allows users to identify top-level domains in the Metanet by memorable words (e.g., company names) rather than by hash digests. It also speeds up searches on domains, since it is faster to search against keywords than against hash digests. It reduces typing errors, and therefore provides improved search tools for data stored on the blockchain.

[0149] Now that we have a map from domain names to node indices, we can construct a resource locator similar to that of an Internet Uniform Resource Locator (URL), which we call a Metanet URL (MURL), and which has the following form:

number

[0150] Each component of the URL, namely, the protocol, domain name, path, and file, is mapped to the structure of the MURL, making the object more intuitive for the user and enabling integration with the existing structure of the Internet.

[0151] This assumes that each node has a name associated with its public key (address) that is unique at the level in the domain tree. This name is always the rightmost component of the MURL for a given node. If two nodes at the same level in the tree have the same name, they have the same public key and thus the latest version is incorporated.

[0152] The following table gives the similarities between the Metanet protocol and the Internet protocol. [Table: Summary of Similarities between the Internet and the Metanet Protocol]

Table 2

[0153] <Metanet Search>[ We defined an embodiment for the description of the Metanet graph structure in which each node can have a unique index and a name belonging to it. This enables the location of content using the MURL. Also, to enable a quick search function, we assigned additional keywords to the nodes.

[0154] The fixed attributes of the node are the index and the index of the parent node, and the optional attributes are the name and the keyword.

Number

[0155] In one example, the actual method of searching the Metanet may first use a block explorer to trawl through the blockchain, identify all transactions with a Metanet flag, check that they are valid Metanet nodes, and if so, record their indexes and keywords in a database or other storage resource. This database can then be used to efficiently search for nodes with the desired keywords. Once an index for a node with the desired keyword is found, its contents can be retrieved from the block explorer and viewed.

[0156] As an example, consider branch P1 in Figure 14. Public keys P0, P1, and P 1,1 The nodes corresponding to "bobsblog", "summer", and "caribbean" represent the home page, topic page, and subtopic page, respectively. These nodes are given the names "bobsblog", "summer", and "caribbean", and their attributes are shown below.

number

[0157] In this example, the leaf node P 1,1,1 , P 1,1,2 , and P 1,1,3 are given the names "beaches", "nightlife", and "food", respectively, and are used to store separate blog posts. The complete domain structure, including the MURL search paths associated with each node in the tree, is shown above the leaves of the figure.

[0158] The Metanet can also incorporate a content addressable network (CAN) by storing the hash of the content stored by node transactions as an additional attribute. This also means that Metanet nodes can be indexed and searched by content hash.

[0159] The above-described naming and addressing method provides numerous technical advantages over the prior art, including: 1. Public Key Addresses: The system uses the same public-private key pair to assign node addresses, just like the blockchain. This means that the same set of keys is used both to manage cryptocurrency funds and to authorize content data. This provides an efficient and secure solution. 2. Decentralized domain: TxIDs can only be generated through proof-of-work node The issuance of domain names is fully decentralized through the inclusion of a public key P that is human readable, allowing for a fair distribution of desired domain public keys. vanity (vanity addresses) can also be incorporated. Again, this solution offers improved efficiency and security. 3. Graph Structure: The naming and addressing architecture specifies a graph that can be constructed from a subset of blockchain data, including Metanet nodes. This design maps the complexity of the Internet onto the blockchain with an ordered structure, so that it fully replicates its functionality and scalability while remaining secure.

[0160] <Browser-Wallet Application> Recall that in the Metanet protocol, all data resides directly on the blockchain itself. In this section, we present an illustrative computer application embodiment, where for convenience we refer to it as a "browser-wallet" that can efficiently access, view, and interact with the Metanet data stored on the blockchain.

[0161] We begin with a discussion of the core components and functionality of how a browser-wallet interfaces with a decentralized peer internet, before providing a detailed explanation in the remainder of this chapter.

[0162] <Summary> <Component> A Browser-Wallet is an application that allows end-users to interact with the Metanet infrastructure on the blockchain. This application should allow exploratory searches of the Metanet graph for specific content embedded in the tree. Additionally, the Browser-Wallet handles retrieval, decryption, recombination and (optionally) caching of content.

[0163] A browser-wallet application combines these elements with cryptocurrency payment mechanisms by supporting native (or external) wallets. A browser-wallet contains the following core elements combined into a single computer application:

[0164] Blockchain Search Engine:ID node Supports third-party search engines to query Metanet nodes by various indexes including node name, keywords, block height, and TxID.

[0165] Display Window: Software that unpacks the content returned to the browser by full-copy blockchain peers. This covers decryption, recombination, caching, and redemption of access tokens.

[0166] Cryptocurrency Wallet: Dedicated key management for blockchain currencies. Can be native to the application or allow communication and synchronization with external wallets (software or hardware). Can write standard blockchain transactions, as well as new Metanet node transactions. Can mediate on-chain purchases of access keys and access tokens.

[0167] Hierarchical, deterministic key management is utilized for both cryptographic public keys and Metanet node addresses.

[0168] Access Key / Token Wallet: Dedicated key management for purchased access keys or tokens. Can receive keys or tokens purchased with cryptocurrency wallet but do not have permission to them. They may be hidden from the user to expire at a later date. This may be achieved through the use of a trusted execution environment. Timed access is secured by synchronizing with the blockchain and querying the current block height.

[0169] <Function> The Metanet Browser-Wallet specification guarantees the following functionality for applications: 1. Hierarchical Key Management: The keys used to control funds and to manage the Metanet tree (graph) utilize the same hierarchical deterministic key infrastructure, reducing the burden on users to maintain key records for Metanet content. 2. Refer to external cryptocurrency wallets: The ability to authenticate and synchronize with external (not native to the application) wallets allows for additional security by eliminating the browser-wallet as a point of failure. The application describes the blockchain transaction and requires a signature from an external wallet that contains the key, delegating this responsibility to a separate software or hardware. 3. Searching Metanet Content: The Browser-Wallet can support and query third-party search engines whose functions may include crawling, indexing, serving, and ranking Metanet node transaction data in the Global Database. A database of OP_RETURN transactions containing Metanet protocol flags may be constructed. BitDB2.0 - see https: / / bitdb.network / . Search engines can provide browser-wallets with node indexes that make data discoverable. 4. Reading Data and Writing to the Blockchain: In addition to using search engines and full nodes to serve content to browsers, cryptocurrency wallet support also makes it possible to write content directly from the browser-wallet to the Metanet. 5. Data Decryption and Decryption: The browser-wallet handles the decryption keys and can perform on-the-fly decryption of Metanet content. 6. Node Identifier (ID node ) Caching: Unique node identifiers can be cached locally for more efficient lookups and queries. 7. Web Server Bypass: Given a node index, a browser-wallet can query any full-copy member of a peer-to-peer (P2P) blockchain network for content located at the node. Since the Metanet exists on-chain, any full-copy peer must have a local copy of the node and its content. This means that a user's browser-wallet only needs to query a single peer, and it can do so directly, without the need for an intermediate web server. Figure 15 shows a schematic of the Browser-Wallet and how its core functionality is split across the different components of the application.

[0170] <Blockchain search engine> Search Engines: Existing Technology Traditionally known search engines (SEs) rely on powerful web crawlers to locate, index, and rank web content according to user queries (the same underlying principles can be extended to third-party blockchain SEs crawling the Metanet).

[0171] The SE identifies relevant HTML meta tags and content through searching for keywords in the query. The results of the crawl are later indexed, where any embedded image / video / media files are analyzed and catalogued. The most relevant results from the index are then programmatically ranked, taking into account the user's location, language, and device.

[0172] A typical SE should have the following features: 1. Crawling: Internet data is identified and crawled through relevant metadata such as domain names, linked pages, and relevant keywords. New Internet content is discovered through existing content and further crawled for any relevant information. 2. Indexing: The content data is analyzed and catalogued. This information is stored in a database. 3. Serving and Ranking: The content index is ranked in order of relevance to the user's query.

[0173] <Block explorer> The closest blockchain analogue to an internet search engine (SE) is a blockchain explorer, sometimes called a "block explorer" or "blockchain browser". A blockchain explorer is a web application that allows user-friendly querying of the blockchain at a high level, and functions similarly to a web browser, but connected to the blockchain instead of the internet. See https: / / en.bitcoin.it / wiki / Block_chain_browser.

[0174] In most cases, these explorers take as input and allow searching blocks (indexed by the hash of the block header), transactions (indexed by TxID), addresses and unspent transaction outputs (UTXOs). Many explorers provide their own application programming interface (API) to read raw transaction and block data. See https: / / blockexplorer.com / api-ref.

[0175] Block explorers, varying in their capabilities, are usually useful for breaking down transactions and displaying their basic information, such as the currency value, coins and addresses traded, and their history, in an easy-to-understand format for users. Many explorers, such as Bitcoin.com https: / / explorer.bitcoin.com / bch and Blockchain.com https: / / www.blockchain.com / explorer, also make the individual inputs and lock scripts of a transaction viewable, although there is inconsistency in how this information is selected and presented between these and more advanced sites, such as Blockchair https: / / blockchair.com / .

[0176] In recent years, there have been many extensions of the basic blockchain explorer that are used to run web applications based on blockchain data. These applications, such as Memo.cash https: / / memo.cash / protocol and Matter https: / / www.mttr.app / home, operate similarly to block explorers that sort and organize blockchain transactions that contain specific protocol identifiers, as well as display the data encoded within those specific transactions.

[0177] However, there are two important problems with using a blockchain explorer, which are solved by embodiments of the present invention: 1. Universality: There is currently no industry-wide standard for viewing the content data stored in a transaction. Content data represents any data that is not related to the protocol used to create and secure the underlying blockchain. 2. Keyword Search: The content data stored in transactions needs to be searchable by human-readable keywords. Keyword search is typically not a feature of current block explorers, since they are used to query protocol-based characteristics of transactions, such as block height, TxID, and address, rather than taking keywords as search input. (However, some, e.g. Blockchair, can search for words if the words are directly included in the transaction script.)

[0178] Importantly, the powerful naming and addressing structure of the present invention, as described above, enables and enables the construction of much more sophisticated blockchain explorers than have previously been known.

[0179] <Proposed Metanet Search Engine> The browser-wallet application uses the node identifier (ID node ) to discover user-generated content. It is believed that such third parties may offer a powerful and versatile set of services that replicate the capabilities of existing Internet search engines.

[0180] A third party Metanet search engine maintains a database of all Metanet transactions mined on the blockchain, identifiable by Metanet protocol flags. This database is organized into node All Metanet nodes can be sorted by a range index that includes node name, keywords, TxID, and block height.

[0181] Services already exist, such as Bit DB https: / / bitdb.network / , which keeps transaction data in a standard database format, constantly synchronized with the blockchain. The browser-wallet offloads the responsibility of crawling, indexing, serving and ranking Metanet transactions to such third parties, and connects to those services when identifying content to be stored in the Metanet graph.

[0182] By having a database dedicated only to Metanet data, efficient savings can be made. Unlike BitDB, it does not store data associated with entire transactions, but only stores data that includes Metanet flags. Certain databases, such as non-relational databases like MongoDB, can be more efficient at storing the Metanet graph structure. This allows for faster queries, smaller storage space, and more efficient association of related content within the Metanet domain.

[0183] Figure 16 shows how the Browser-Wallet interacts with a third party search engine when a user searches for content within the Metanet infrastructure. Importantly, it should be noted that in contrast to the Internet, no routing is required and thus the present invention provides significant advantages in terms of efficiency, speed, processing and required resources.

[0184] The process is as follows. 1. End-user enters keywords into the browser-wallet search bar. 2. The browser-wallet sends a keyword query to the third-party SE. 3. The SE checks the keyword against its database and finds the IDs of any Metanet nodes that contain related content. node Third parties can provide related content suggestions as well as return other indexes at each node to the user. 4. Browser - The wallet uses the node identifier and its associated domain name to construct an MURL. 5. The browser-wallet requests content belonging to a particular node from any network peer that has a full copy of the blockchain. 6. The network peer provides the requested content to the browser-wallet. Since the peers have a copy of the blockchain, they also have a copy of the content, so only one request is made and it is never forwarded to other network peers.

[0185] It is emphasized that third-party SEs are only responsible for indexing and maintaining records of the attributes of Metanet nodes, while the raw content data stored in the nodes is instead stored by network peers that have a full copy of the blockchain (e.g., full-copy peers, miners, archives).

[0186] <Content display-Metanet browser> The Browser-Wallet application emulates the same front-end capabilities that any standard web browser should offer. These features include, but are not limited to: 1. Searching: Providing access to search engines (SEs) to locate content. 2. Retrieval: Communicating with the server to achieve the transfer of content using a known protocol, for example the Hypertext Transfer Protocol (HTTP). 3. Interpreting: Parsing the raw code (e.g. JavaScript) and executing it. 4. Rendering: Effectively displaying the parsed content to be viewed by the end user. 5. User interface (UI): Provide an intuitive interface for interacting with content, including action buttons and mechanisms for user input. 6. Storage: Local temporary storage capabilities such as caches, cookies, etc. of Internet content to enhance repeat access to that content.

[0187] In certain embodiments, the software component of the browser-wallet application responsible for operating as a web browser can perform the above-mentioned functions on Metanet content embedded in the blockchain, which is searchable (using the SE) and readable (from peers) using their attributes.

[0188] <Recombination, Decompression, and Decryption> According to a specific embodiment of the present invention, the web browser software component of the browser-wallet application is capable of handling all operations that need to be performed on a given Metanet content. Although there are many such operations that typically need to be performed, we envision at least the following being performed by the application using the Metanet protocols and infrastructure:

[0189] Recombination: When Metanet content needs to be composed and inserted into multiple separate node transactions, the application requests the content from all involved nodes and reconstructs the original content. The order and structure of the sharded content can be encoded using additional flags in the attributes of each node.

[0190] Decompression: If the content data is stored on the blockchain in compressed form, it should include a flag to indicate to the browser-wallet which standard compression method is used. The application will decompress the content according to this flag.

[0191] Decryption: If the content is encrypted, a flag should be used to specify the encryption method. The application will locate a key from its decryption key wallet (described below) and decrypt the content data for use according to the encryption method used.

[0192] When performing these operations on the content data, flags can be used to indicate to the browser-wallet that a given operation should be performed. This is done by specifying the appropriate flag as part of the attributes of the node to which the operation applies.<operation_flag> This generalization is generalized to any other operation that may involve

[0193] <Caching> Local file caching and cookies are common and important features of standard web browsers. The Browser-Wallet application stores IDs node It also uses local storage in a similar manner to keep a record of the number of nodes and optionally other node attributes related to the content of interest. This allows for more efficient lookup and retrieval of content from frequently visited Metanet nodes.

[0194] The Metanet solves the problems inherent with caching Internet data, which is mutable and can be altered or censored by web browsing software depending on the provider. When caching Metanet data, users can always easily verify that it is in the same state as when it was originally included as an immutable record on the blockchain.

[0195] <Cryptocurrency wallet> <Hierarchical deterministic key management> A deterministic key (DK) is a private key initialized from a single "seed" key (Andreas M. Antonopoulos, Chapter 5 in "Mastering Bitcoin" O'Reilly 2 nd Ed., 2017, pp. 93-98). The seed is a randomly generated number that acts as a master key. A hash function can be used to combine the seed with other data, such as an index number or a "chain node" (see HD Wallets-BIP-32 / BIP-44), to derive a deterministic key. These keys are related to each other and are fully recoverable with the seed key. The seed allows for easy import / export of wallets between different wallet implementations, and gives additional flexibility if users want to use external wallets in conjunction with a Metanet browser-wallet.

[0196] Hierarchical deterministic (HD) wallets are a popular method of derivation of deterministic keys. In HD wallets, a parent key generates a set of child keys, which in turn derive a set of grandchild keys, etc. This tree-like structure is a powerful mechanism for managing several keys.

[0197] In a preferred embodiment, the HD wallet can be incorporated into the Metanet structure shown in Figure 16. Advantages of using an HD wallet include: 1. Structure: An additional organizational semantic may represent the use of different key rings for different purposes. For example, a user may dedicate different branches (and their corresponding subkeys) to different types of data. 2. Security: Users can generate a set of public keys without having the corresponding private key, making HD wallets function in a receive-only capacity and suitable for use with insecure servers. Also, only a small number of secrets need be stored, so the risk of exposure is low. 3. Recovery: If keys are lost / corrupted, they can be restored from the seed key.

[0198] <Support for native (internal) and external wallets> Advantageously, embodiments of the present invention can merge the functionality of a traditional web browser directly with one or more cryptocurrency wallets, functionally combining payments for "internet" content with the delivery of "internet" content to end users.

[0199] To achieve this, embodiments of the browser-wallet may have a dedicated built-in software component that acts as a cryptocurrency wallet, native to the application itself, and can be used to manage cryptocurrency keys and to authorize transactions as payments for Metanet content within the browser-wallet itself.

[0200] This means that the browser component of the application can prompt the wallet component to authorize the necessary payment by purchasing a decryption key, access token, or other item to view Metanet content. The application does not need to call an external third party to process the payment. Thus, the Metanet content of interest is consumed by the application and paid for on the spot.

[0201] <External wallet> The same advantages and functionality can be achieved by embodiments of the present application even if the user wishes to manage or hold their cryptocurrency private keys in an external wallet (software or hardware) instead or wishes to use multiple wallets. This may be executed instead of or in relation to the original wallet of the application.

[0202] In such an embodiment, the application establishes a link or pairing with the external wallet and synchronizes with it, but does not store the private key within the browser-wallet itself. Instead, the browser component prompts that a payment for the content be made, and the application requests authorization by digital signature from the selected external wallet. This authorization is performed by the user, and the browser-wallet can broadcast the transaction and view the paid content.

[0203] <Reading and writing of Metanet transactions> The unique advantage of Metanet is that it uses the same data structure, i.e., the blockchain, to record payments and content data. This means that in addition to a software wallet generating transactions purely based on cryptocurrency exchanges, it can be used to write content data to the Metanet infrastructure.

[0204] Wallets built natively into applications can write more complex transactions to the blockchain than standard simplified payment verification (SPV) clients. See https: / / bitcoin.org / en / glossary / simplified-payment-verification. Wallets allow users to choose to write Metanet node transactions to the blockchain directly from their application by selecting the content data to be embedded in the blockchain from their computer.

[0205] Because the browser-wallet application has a user interface (UI), it allows the wallet component to generate and broadcast transactions that include content data configured in the browser component or previously on the user's computer, a capability that would be very difficult for a dedicated wallet to accomplish on its own.

[0206] <Access Key / Token Wallet> Recall from the above that built into the Metanet protocol is the ability to encrypt content with an ECC key pair or an AES symmetric key, and to purchase corresponding decryption keys or tokens, which we call access keys or access tokens.

[0207] Such keys / tokens grant the user permission to view or edit content (either one-time use or multiple use), and serve a different role than the key that controls the user's cryptocurrency wallet (although the same key may be used for both purposes if desired.) For this reason, it is advantageous to introduce a new wallet, separate from the application's native cryptocurrency wallet, that is used to store and manage access keys and tokens.

[0208] It is also possible to introduce the concept of timed access to Metanet content by expiring access keys / tokens after a certain period of time. This can be achieved by requiring that access keys / tokens are stored in a Trusted Execution Environment (TEE) and are not directly accessible by users.

[0209] The fact that access keys / tokens can "disappear" can be a motivating factor for not storing them in cryptocurrency wallets to ensure that you do not run the risk of your cryptocurrency private keys disappearing.

[0210] In a manner similar to cryptocurrency wallets, decryption keys and access tokens can be stored and managed deterministically for efficient processing and deployment. Decryption keys (e.g., ECC private keys) can be generated and restored by subsequent additions to a master key, while access tokens can be reconstructed using a hash chain seeded by some initial token.

[0211] It is important to distinguish here that cryptocurrency wallets handle the generation of deterministic keys for key pairs used when transacting with other users and when creating new Metanet nodes, while key / token wallets handle the keys and tokens purchased via cryptocurrency wallets.

[0212] <Block height permissioning> Timelocks can be included in the Bitcoin scripting language to enable block height validation. The oOp_code OP_CHECKLOCKTIMEVERIFY (CLTV) sets the block height at which transaction outputs (UTXOs) are allowed for spending.

[0213] The benefits of block height permitting are twofold: 1. Version control: In the Metanet protocol, the node with the latest version can be identified from the node at the maximum block height. Browser-wallets can be configured to not only show the latest version of a file by block height, but also allow for proof-of-work version control. 2. Timed access: The browser-wallet application can automatically periodically revoke the decryption keys purchased by the user. This ensures that viewers can only access the content data during the time period they paid for. Cloning of the decryption keys can be prevented by storing them in a trusted execution environment (TEE). Furthermore, the atomic swap involves the purchase of a deterministic key Dk (for decrypting the content data). This deterministic key is publicly visible, but the TEE can be used to sign the binding of Dk with a securely enclaved private key.

[0214] Browser-wallets can be configured to synchronize with the current state of the blockchain to use the block height as a proxy for their own time, rather than relying on any external clock or third party time oracle.

[0215] <Web server bypass> The present invention enables a new mechanism for browsers (clients) and web servers to communicate and exchange information over a distributed peer internet, which bypasses domain name system (DNS) servers and standard network routing procedures. See http: / / www.theshulers.com / whitepapers / internet_whitepaper / . The present invention provides a new network architecture where browser-wallet applications can be provided content, including peers that maintain a full copy of the blockchain.

[0216] <Local full copy peer> Consider a system of local peers in each geographic region, e.g., zip code, town, city. We assume that within this local network, at least one peer maintains a full copy of the blockchain. We call this a Local Full-Copy Peer (LFCP). For our purposes, an LFCP need only store blockchain transactions that include the Metanet flag, but is not limited to doing so.

[0217] All users, by default, send "get" requests to the LFCP. As peers maintain a complete up-to-date copy of the entire blockchain, all requests can be serviced because any node ID requested is available to the LFCP. Note that a Metanet search engine may act as an LFCP if the SE is powerful and large enough to store Metanet content and perform the primary functions of a standard SE.

[0218] In the simplest case, all LFCPs have the same storage and disk space overhead when they need to be able to store the complete blockchain (approximately 200 GB at the time of filing). The distinction between each LFCP is that they scale their capabilities in response to local demand from Metanet users. Thus, if each Metanet user around the world requests their nearest LFCP by default, each LFCP should try to scale their operational capabilities to meet their local demand. Densely populated areas, such as cities, require LFCP operations that include many clustered servers. On the other hand, sparse areas, such as smaller towns, require smaller LFCP operations.

[0219] It is important to note that while the disk space requirements are generic, the CPU requirements per LFCP adapt to the needs of the local network. This is an example of an adaptive network like Freenet. See https: / / blockstack.org / papers / .

[0220] One advantage of such a system is that for a given ID node The advantage of this is that when retrieving content associated with a , users only need to create a single (local) connection with their LFCP - there is no need for LFCP to send requests to other peers, as they are guaranteed to be provided with their own requested content.

[0221] The Metanet offers many advantages over the Internet, such as decentralization and non-redundancy, which are similar to other peer-to-peer (P2P) file sharing services such as IFPS. However, the Metanet improves upon these existing P2P models by eliminating immutability and, crucially, the need to flood the network with requests for a given piece of content.

[0222] The Metanet infrastructure is robust to the failure of any one LFCP by utilizing this network of peers. This means that if an LFCP is disabled, end users simply default to their next closest LFCP. This can be made more efficient if the LFCPs communicate with each other to indicate nearby peers that are under or over capacity in terms of requests at any given time. This allows users to send their requests to the most appropriate peer and establish a dynamic equilibrium of requests among nearby LFCPs.

[0223] <Global full copy peer> We now consider a scenario in which the universal disk space requirements become too large for smaller peers, which could arise as the Metanet portion of the blockchain scales and grows through adoption.

[0224] In this case, the smaller LFCPs should use their disk space capabilities to store Metanet node transactions based on a popularity system (there are existing technologies to rank content by the volume and nature of requests). This means that LFCPs will adjust both their CPU (for request processing capacity) and their storage allocation (for content serving capacity) to suit their local geographic demands, both in terms of volume and nature of content.

[0225] To address the fact that LFCP cannot store all Metanet transaction content, the concept of Global Full-Copy Peer (GFCP) can be used. A GFCP is a full-copy peer with the following properties: 1.GFCP will increase its disk space capacity to maintain a full copy of the blockchain at all times. 2. GFCP has substantial CPU resources and can handle significantly more requests than LFCP. Global full copy peers must be able to handle a sudden increase in requests if a large number of LFCPs fail.

[0226] There are two main functions of the GFCP. First, it acts as a failsafe for user requests for Metanet content in the event of overflow requests from the LFCP. Second, the GFCP acts as an archive peer to store all previously mined Metanet content. This ensures that any Metanet node's content is accessible even if multiple LFCPs omit some content from their storage provisions.

[0227] <Global Data Bank> The concept of the GFCP is a powerful one, explaining how the Metanet’s overall architecture provides a solution to the existing problem of generating a comprehensive global databank.

[0228] Traditionally, a universal, globally accessible data bank could not be constructed securely because it would have to be maintained by a central authority, which would inject both a point of failure and a point of trust into the system. Importantly, when we rely on an organization to store and maintain all of the Internet's data, we need to trust that they are doing so correctly, legally, and without corrupting information.

[0229] With the Metanet infrastructure, we have effectively removed both of these problems, the trust problem and the centralization problem, from the Global Data Center concept, where such GFCPs can be created because they depend on providing the necessary disk space for storage, and not on verifying and authenticating the information to be stored.

[0230] With Metanet, the process of verifying what is stored is done by miners. Thus, universal global data banks can be trusted because they will not corrupt the blockchain information. GFCPs do not need to be trusted, they only need to provide storage.

[0231] The fact that all GFCPs can store the same information, always verifiable and provable against the blockchain itself, means that it can be reproduced across many such GFCPs.

[0232] This also means solving the problem of having a single point of failure by having multiple global databanks existing in parallel and provably storing the same information.

[0233] FIG. 17 shows a system of two LFCPs and one GFCP and illustrates how each peer can support other peers in a network that is robust to individual peer failures.

[0234] Aspects of the present invention that may be embodied in the above-described browser-wallet application embodiments provide a number of significant features and advantages over the prior art, including, but not limited to, the following. 1. Deterministic Keys: Hierarchical deterministic key management for both cryptocurrencies and Metanet addresses is performed within the same wallet component of the application. This allows for the organization of multi-function keys, reducing their storage requirements and enabling key recovery. 2. Payment Mechanism: The application allows consumers to pay merchants directly without having to point to a separate application or third-party payment service that traditionally provides authentication and trust. This allows digital content purchases and delivery to occur over the same blockchain platform. The application inherently takes advantage of Bitcoin payments, which involve the exchange of small amounts of value, or more complex transactions involving multiple parties. 3. Web Server Bypass: Applications achieve bypass of traditional web servers that traditionally handle high volume traffic, requests, and routing, because applications only need to request content from a single LFCP that is guaranteed to serve the user without the need to forward requests to other LFCPs. This reduces the overall traffic volume and the completion time of each request. 4. Timed Access: Applications achieve timed access to content by synchronizing with the blockchain and using the blockchain to enforce access permissions based on the current state of the blockchain. This removes the need for third-party services to monitor user rights over time while protecting the rights of the original owner.

[0235] Example of use: Decentralized app store (Swapp store) The first use case (for illustrative purposes only) for the Metanet architecture presented here relates to decentralized payment and distribution of applications (apps).

[0236] We consider a scenario where an app developer, Alice, and a consumer, Bob, want to transact with each other. This transaction takes the form of an atomic swap, in which money is exchanged for a secret key that allows Bob to access the application data. The encrypted application data has already been published as part of the Metanet node transaction.

[0237] Atomic swap applications are known as Swapps. A third-party platform (the Swapp Store) may be used to catalog and advertise applications that exist on the Metanet. However, payment for access keys and transfers to users like Bob can be made directly between merchants and consumers without the need to involve a third party.

[0238] The following sections detail the process that can be used to buy and sell Swapps, from the creation of the app by Alice to its deployment by Bob. Throughout the process, Alice and Bob interact with the Metanet using their respective browser-wallets.

[0239] <Publishing> 1. Alice writes an application. The data that makes up this application is <app>She has a secret key S k Encrypt it using<e(App)> . 2. Alice receives the node transaction ID Alice_App and configure her first Metanet domain (tree). She creates 1AliceAppHtKNngkdXEeobR76b53LETtpy (P AliceApp ) 3. Alice then creates children of the first node to form a tree that corresponds to her application's Metanet library. Alice's tree domain is shown in Figure 18. One of the leaf nodes in this tree has index ID App Her application with <app>In this node, Alice encrypts the application data<e(App)> Insert the secret key s into the node's input script (scriptSig). k The data is encrypted using the Koblitz algorithm. This node transaction is shown below: [Table 3] [Table 3] 4. Alice has ID AliceApp , P AliceApp and publicly broadcast the domain name "AliceApp", which may be via social media, an internet website, or using a third party Metanet website.

[0240] <Purchase> 1. Bob wants to download a puzzle game listed on a Metanet website (Swapp store) that he browses to on his browser-wallet and wants to see Alice’s app. 2.Bob then contacts Alice using the information from the website to set up an atomic swap. The swap consists of Bob paying Alice the agreed upon price in Bitcoins and Alice exchanging the secret key s k The event is designed to either disclose a 3. The atomic swap is complete and Bob’s browser-wallet receives the secret key s k in your access key / token wallet.

[0241] <Expand> Bob now has the key s that allows him to decrypt the application data previously published by Alice. k To download the app and deploy it, Bob does the following: 1.Bob uses a Metanet search engine (SE) to search for encrypted app data.<e(App)> To find the MURL associated with , he uses the keywords "AliceApp" and "App" as input into the search bar in his browser-wallet. The third-party SE resolves the query and returns the following MURL: mnp: / / aliceapp / games / puzzle / app This locator is a unique Metanet node ID that contains the encrypted app data in its input script. App Corresponds to. 2. Bob's browser-wallet receives this MURL and sends a request to the nearest appropriate LFCP peer. This peer returns the requested data to Bob.<e(App)> to provide. 3. Browser-Wallet is ID App This is done by processing data according to the attributes of the secret key s k Decrypt the application data using <app>This includes processing. 4.Bob is an application <app>from his browser to his computer. Bob can now deploy the application locally without having to purchase access up front.

[0242] Figure 19 illustrates the overall process outlined in the illustrative use case above. The flow chart shows two action branches: Alice's (starting on the left) and Bob's (starting on the right). The branch corresponding to Alice shows the initial issue phase, while Bob's shows the phase of setting up the purchase via an atomic swap.

[0243] On Bob’s branch, during the atomic swap setup phase, he creates the following transaction TxID: Bob Broadcast. [Table 4] [Table 4]

[0244] In this transaction, the output is a secret decryption key s that Alice must disclose to Bob for him to spend. k It is locked by a secret key puzzle that requires

[0245] In this diagram, Alice's and Bob's branches converge when Alice successfully completes the atomic swap transaction. This is because Alice has transaction TxID Alice This is achieved when broadcasting [Table 5] [Table 5]

[0246] As soon as this transaction is broadcast, Alice and Bob's actions diverge again: Alice receives a payment of xBitcoins, while Bob receives the secret decryption key s k and can read and decrypt Alice's application from the Metanet.

[0247] Referring to FIG. 20, an illustrative simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the illustrated systems described above. For example, the computing device 2600 may be configured for use as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in FIG. 20, the computing device 2600 may include one or more processors with one or more levels of cache memory and memory controller (collectively labeled 2602) that may be configured to communicate with a storage subsystem 2606 that includes a main memory 2608 and a permanent storage device 2610. The main memory 2608 may include a dynamic random access memory (DRAM) 2618 and a read only memory (ROM) 2620 as shown. The storage subsystem 2606 and the cache memory 2602 may be used for storage of information such as details associated with transactions and blocks as described in this disclosure. The processor 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0248] The processor 2602 may also communicate with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0249] Bus subsystem 2604 may provide a mechanism that allows the various components and subsystems of computing device 2600 to communicate with each other as intended. Although bus subsystem 2604 is illustrated generally as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0250] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616, in some embodiments, may act as an interface to receive data from and transmit data to other systems in the computing device 2600. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network so that the data technician can send data to and receive data from the device without being in a remote location, such as a data center.

[0251] User interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into computing device 2600.

[0252] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device, etc. The display subsystem may include a cathode ray tube (CRT), a liquid crystal display (LCD), a light emitting diode (LED) display, or a flat-panel device such as a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface and facilitate user interaction with applications that perform the processes and transformations described herein, when such interaction is appropriate.

[0253] The storage subsystem 2606 may provide a computer-readable storage medium that stores basic programming and data structures that provide the functionality of at least one embodiment of the present disclosure. Applications (e.g., programs, code modules, instructions) that, when executed by one or more processors, provide the functionality of one or more embodiments of the present disclosure may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 also provides a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The permanent storage device 2610 may provide permanent (non-volatile) storage of programs and data and may include a magnetic hard disk drive, one or more floppy disk drives associated with removable media, one or more optical drives (e.g., CD-ROM, or DVD, or Blue-Ray) drives associated with removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments described in this disclosure, and data associated with the transactions and blocks described in this disclosure.

[0254] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, optical connector, etc.). A device that can be connected to the computing device 2600 may include multiple ports configured to receive optical fiber connectors. The device may thus be configured to convert optical signals into electrical signals that are transmitted to the computing device 2600 through the ports connecting the devices for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 20 is intended only as a specific example for purposes of describing a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 20.

[0255] It should be noted that the above-described embodiments illustrate, rather than limit, the invention, and that those skilled in the art can devise many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs in parentheses are not intended to limit the claims. The terms "comprising" and "comprising", etc. do not exclude the presence of elements or steps other than those listed in any claim or the specification as a whole. In this specification, "comprising" means "having or consisting of" and "comprising" means "comprising or consisting of". A singular reference of an element does not exclude a plural reference of such an element. Vice versa. The invention can be implemented by means of hardware comprising several distinct elements, and by means of a suitably programmed computer. In a device claim enumerating several means, several of these means may be embodied by one and the same item of hardware. The mere fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage.< / app> < / app> < / app> < / app> < / lzw> < / n> < / m> < / s> < / n> < / m> < / s> < / content> < / content> < / content> < / attributes>

Claims

1. 1. A method for storing data in a blockchain, the method comprising:

1. A method comprising: generating a plurality of blockchain transactions, each of the plurality of blockchain transactions storing therein a respective portion of first data to be stored on the blockchain and second data indicating that the portions of the first data are related to each other.

Images