A computer-based system and method for storing data on a blockchain.

Abstract

To disclose a method for storing data on a blockchain, such as Bitcoin blockchain.SOLUTION: A method includes a step of generating a blockchain transaction having at least one first input and / or at least one first output containing first data (<Content 1>) to be stored on a blockchain, and at least one second input and / or at least one second output containing second data (<Attribute 1>, <Attribute 2>) representing at least one attribute of the first data. At least one second input and / or at least one second output is separate from each first input and / or first output.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention generally relates to cryptographic techniques for improved 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 particularly to such data-related operations on a blockchain. The present invention is particularly suitable for use in processing data in a manner similar to that provided by websites and web pages, but using a blockchain as the underlying mechanism or platform instead of a web server. Thus, the present invention provides an alternative infrastructure for data processing and transfer, implemented by secure and efficient cryptographic methods.

Background Art

[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. While other blockchain implementations have been proposed and developed, the most widely known application of blockchain technology is the Bitcoin ledger. Bitcoin is here referred to for convenience and illustrative purposes, but the present invention is not limited to use with the Bitcoin blockchain, and alternative blockchain implementations and protocols are to be considered within the scope of the present invention. The term "user" may here represent human or processor-based resources. The term "Bitcoin" is here used 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 are in turn composed of transactions. Each transaction is a data structure encoding the transfer of control of digital assets between participants in the blockchain system, and includes at least one input and at least one output. Each block contains the hash of the previous block, and these blocks are linked together to produce a permanent and immutable record of all the transactions written to the blockchain since its inception. Transactions contain small programs known as scripts. Scripts embed their inputs and outputs and specify how and by whom the outputs of the transaction can be accessed. In the Bitcoin platform, these scripts are written using a stack-based scripting language.

[0004] For a transaction to be written to the blockchain, it must be verified. Network nodes (miners) perform work to ensure that invalid transactions are rejected from the network and that each transaction is valid. The software client installed on the nodes performs this verification work on the unspent transaction outputs (UTXOs) by executing the lock and unlock scripts for the UTXOs. If the execution of the lock and unlock scripts evaluates to true (TRUE), the transaction is valid and the transaction is written to the blockchain. Thus, for a transaction to be written to the blockchain, (i) it must be verified 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) it must be added to a new block constructed by the miner, and (iii) it must be mined, i.e., added to the public ledger of past transactions.

[0005] While blockchain technology is most widely known for its use in cryptocurrency implementations, digital entrepreneurs are beginning to develop uses for both Bitcoin's underlying cryptographic security system and data that can be stored on the blockchain to implement new systems. Blockchain would be highly advantageous if it could be used for tasks and processes not limited to the cryptocurrency domain. Such solutions could diversify their applications while leveraging the benefits of blockchain (e.g., permanence, tamper resistance to event recording, decentralized processing, etc.).

[0006] One such area of ​​interest is the use of blockchain for storing, sharing, accessing, and controlling data among users. Today, this is achieved via the internet, involving servers that host websites and pages that users visit to access desired data, typically through search engines.

[0007] However, some observers are beginning to consider using blockchain to address some of the shortcomings of the internet, such as the control of vast amounts of data and content by a central party. For example, see: "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] Therefore, it is desirable to provide a configuration that takes advantage of the decentralized, immutable, distributed, and perpetual properties of blockchain to enable such data to be stored, processed, read, retrieved, and / or shared on the blockchain. Such an improved solution is devised here. [Overview of the Initiative]

[0009] Embodiments of this disclosure provide, at least, alternative, efficient, and secure technologies for implementing blockchain solutions and for storing, processing, retrieving, and / or retrieving data on or from a blockchain. Embodiments further provide, at least, a technical infrastructure implemented by an alternative blockchain for storing, processing, retrieving, transferring, retrieving, and / or sharing data between computing nodes. To enable the use of blockchain networks in novel ways and to provide improved technical results, the present invention provides a network implemented by an improved blockchain.

[0010] The embodiment further provides a solution for secure control of access to digital resources via technically different and improved computing platforms, including blockchain and blockchain protocols.

[0011] The present invention is defined in the appended claims.

[0012] According to the present invention, a method implemented by a computer may be provided. The method may be a method for storing data on a blockchain, the method comprising the step of generating a blockchain transaction having at least one first input and / or at least one first output containing first data to be stored on the blockchain, and at least one second input and / or at least one second output containing second data representing at least one attribute of the first data, wherein the at least one second input and / or at least one second output is separate from the first input and / or first output.

[0013] By storing the first data separately from the second data representing at least one attribute of the first data, this offers the advantage of enabling the storage of data on the blockchain in a manner independent of the protocol used to process the data, thereby making processing more generally applicable. Furthermore, separating the first and second data offers the advantage of enabling the first data to be digitally signed by a third party more quickly. In addition, the explicit separation of data attributes and content provides a standardized procedure for inserting data into the blockchain. This captures both existing data insertion methods and support for future storage. Moreover, once data is inserted into the blockchain, it can have a unique identifier and location. This eliminates the burden on users of storing local copies of data, as it becomes immutable once contained in the blockchain. This also means that data can be read by users at any time without the need for a disaster recovery mechanism.

[0014] The first data may be included in a plurality of the first inputs and / or the first outputs.

[0015] By storing the first data in multiple first inputs and / or first outputs, this offers the advantage of maximizing data storage density within a transaction.

[0016] The second data may include data related to the recombination of the first data.

[0017] At least one of the second inputs and / or at least one of the second outputs may include instruction data indicating that a transaction includes the first data.

[0018] This offers the advantage of avoiding unnecessary processing of blockchain transactions that do not contain the aforementioned first data, thereby improving processing efficiency.

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

[0020] The first data may be included in at least one of the first outputs.

[0021] This offers the advantage of enabling the validity of the transaction to be checked as part of the blockchain mining process. Data integrity is guaranteed through the existing miner verification 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.

[0022] At least one of the first and / or second outputs may include a script opcode that marks the output as invalid for subsequent use as input to a later transaction.

[0023] This offers the advantage of avoiding processing the output as part of the unspent transaction output (UTXO) data, thereby improving processing efficiency.

[0024] At least one of the first and / or second outputs may be spendable.

[0025] This offers the advantage that the first data can include an executable program. This can prevent it from operating with unusable output, which would otherwise result from, for example, the OP_RETURN operator. The OP_RETURN operator also has the additional advantage of terminating the executable program.

[0026] At least one of the first outputs may be redeemable by at least one key corresponding to each digital signature applied to the first data.

[0027] This offers the advantage of utilizing the process of verifying the digital signature of a transaction, which is performed as part of the cryptocurrency mining process to verify that the transaction is valid, to further verify the validity of the first and / or second data.

[0028] A digital signature may be applied to the aforementioned first data.

[0029] This offers the advantage of making the first data more easily isolated from the second data and allowing it to be digitally signed by a third party independent of the second data. This makes the process more generally applicable and enables faster data processing. This makes the method more protocol-independent.

[0030] At least one of the digital signatures may be based on a cryptographic system having a public-private key pair, wherein the private key is based on a plurality of prime numbers, and the corresponding public key is based on the product of the plurality of prime numbers.

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

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

[0033] This offers the advantage that distributors can use Rabin signatures to provide authentication from the original source of the data. This allows the content itself to be signed by the original author to prove its authenticity.

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

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

[0036] The present invention also provides a non-temporary computer-readable storage medium that stores executable instructions, wherein the executable instructions, as a result of being executed by the processor of a computer system, cause the computer system to execute at least the method implemented by the computer described in this specification.

[0037] The above-described and other aspects of the present invention are evident from and taught by reference to the embodiments described herein. Embodiments of the present invention are described below by mere examples and with reference to the accompanying drawings. [Brief explanation of the drawing]

[0038] [Figure 1] This illustrates a blockchain transaction that embodies the present invention, in which data is stored in multiple outputs. [Figure 2] This shows a blockchain transaction that embodies the present invention, where data is stored as input. [Figure 3] This illustrates a series of blockchain transactions that embody the present invention, in which data is stored across the outputs of multiple blockchain transactions. [Figure 4]This presents a blockchain transaction embodying the invention, which involves sending a cryptocurrency payment to grant access to data using an atomic swap. [Figure 5] Figure 4 shows a blockchain transaction that embodies the present invention, redeeming the payment for the transaction. [Figure 6] The invention embodies a blockchain transaction that issues tokens to grant access to data using atomic swaps, and represents a secret value held by participants within that transaction. [Figure 7] This illustrates a blockchain transaction embodying the present invention, in which tokens are issued to grant access to data using atomic swaps. [Figure 8] This illustrates a blockchain transaction embodying the present invention, in which tokens are issued to grant access to data using atomic swaps. [Figure 9] Figures 7 and 8 show blockchain transactions that embody the present invention, redeeming tokens issued using the transactions. [Figure 10] Figures 7 and 8 show blockchain transactions that embody the present invention, redeeming tokens issued using the transactions. [Figure 11] Figures 9 and 10 show the blockchain transactions used to access the secrets exchanged through these transactions. [Figure 12] Figures 9 and 10 show the blockchain transactions used to access the secrets exchanged through these transactions. [Figure 13] This invention provides a description of a metanet graph structure according to embodiments of the present invention. [Figure 14] This describes a metanet graph tree for the domain "bobslog" including an MURL search path, according to an embodiment of the present invention. [Figure 15]An outline of an embodiment illustrating a browser-wallet according to one example of the present invention is provided, showing how its core functionality can be divided across different components of the present application. [Figure 16] This provides a diagram illustrating how content retrieval can be performed within the infrastructure of an embodiment of the present invention. [Figure 17] The following describes the interaction between a local full copy peer and a global full copy peer according to embodiments of the present invention. [Figure 18] This section shows a metanet tree (or graph) for use when referring to usage examples for the explanations described later. [Figure 19] A flowchart illustrating the process embodied in the usage examples described later is shown. [Figure 20] This is a schematic diagram showing a computing environment in which various embodiments can be implemented. [Modes for carrying out the invention]

[0039] The term “Bitcoin” is used here solely for convenience and is intended to include, but is not limited to, any cryptocurrency / blockchain protocol, including all variations derived from the Bitcoin protocol and any alternative protocols for other blockchains. For the remainder of this specification, the protocol determining the operation of embodiments of the present invention is referred to as the “Metanet protocol.”

[0040] The terms "content" and "data" may be used synonymously here to refer to the data stored in blockchain transactions according to embodiments of the present invention.

[0041] <Overview> As mentioned above, there is a recognized need for improved and / or alternative infrastructure for storing, writing, accessing, and viewing data among and by computing nodes. Utilizing the inherent advantages of blockchain technology (e.g., immutable records, cryptographically enforced control and access, embedded payment mechanisms, the ability to publicly inspect ledgers, decentralized architecture, etc.) is advantageous. However, constructing an "Internet implemented by blockchain" presents challenges from many technical standpoints.

[0042] These challenges may include, but are not limited to, how to protect and control access to specific portions of data within a network, so that only authorized parties can access such data; how to transfer data from party to party in a peer-to-peer manner; how to structure data so that it can be logically correlated while remaining stored in different locations within the network; how to subsequently combine data from different locations to provide collective and augmented results; how to provide and / or store data in a hierarchical manner; how to grant access to desired data to users and parties with different computing platforms; how to store, provide and share data across computing networks (which may be global) without relying on or requiring large-scale storage servers and centralized data control units; and how to improve the efficiency of such data-related activities on the network.

[0043] Here, “sharing” may include providing nodes or users with the ability to transmit, communicate, transmit, or provide access to data portions. The term “processing” may be interpreted as meaning any activity relating to a transaction or its associated data, including generating, transmitting, verifying, accessing, searching, sharing, submitting to a blockchain network, and / or identifying.

[0044] The present invention provides an improved solution that, in some respects, is similar to the internet, but achieves the same results in a completely different way, using a platform of hardware and software components that are completely different from those conventionally known. According to embodiments of the present invention, servers that store and provide internet / web data to end users are replaced by blockchain transactions residing on a blockchain network. To achieve this, several innovations had to be devised, which are described in the following chapters.

[0045] <Inserting data into the blockchain "Metanet"> Referring to Figure 1, a blockchain transaction embodying the present invention is shown. Here, the first data to be stored on the blockchain is stored in one or more first outputs of the transaction, and the second data representing the attributes of the first data is stored in one or more second outputs of the transaction. One or more first parts of the first data<Content 1> The data is stored in the transaction's spendable output.<Attribute 1> and<Attribute 2> Each represents an attribute of the first data, along with a flag indicating that the data is stored according to the Metanet protocol, and is stored in the transaction's second unspendable output. The term "unspendable" is used to indicate that at least one of the transaction's first and / or second outputs may contain a script opcode (OP RETURN) that marks the output as invalid for subsequent use as input to a later transaction.

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

[0047] Figure 2 shows the first data to be stored on the blockchain.<Content 1> This indicates a blockchain transaction embodying the present invention, in which the following are stored in the transaction input: Metanet flags and attribute data.<Attribute 1> and<Attribute 2> This is stored in the transaction's unavailable output in a manner similar to the configuration shown in Figure 1.

[0048] <Insert data> <Data insertion method> It is desirable that the following data be inserted into the blockchain. a) Metanet flag b) Attributes c) Content

[0049] Content is data that should be stored on the blockchain, Metanet flags are 4-byte prefixes that serve as identifiers for any data related to the Metanet protocol, while attributes include index, permission, and encoding information about the content.

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

[0051] The following techniques can be used to embed this data within a Bitcoin script.

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

[0053] 2. OP_RETURN with OP_DROP: In this case, OP_RETURN includes attributes, while the content is stored before OP_DROP in the available transaction script (either lock or unlock). Content can be divided into multiple data packets within the transaction input and output. However, since only the output script 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 for the data to guarantee its validity, instead of miner verification. For example, a 32-bit OP_MOD operation can be performed and checked to ensure that it is equal to a pre-calculated value.

[0054] In this case, the attribute may include information about how the content data packets are recombined. Furthermore, providing the hash H(content1 + content2) of the recombined data packets as an attribute allows for verification that the preferred recombination method is being used.

[0055] A transaction performing the second data insertion method is shown in Figure 1. For simplicity, this transaction includes only the content inserted into its output, signed by its single input. Content inserted into additional inputs can also be done using the OP_DROP statement with the same method as shown in Figure 2.

[0056] When the content is very large, it may be advantageous to divide the content into multiple transactions. Such a configuration is shown in Figure 3. Figure 3 shows a pair of blockchain transactions that embody the present invention. Here, the first data to be stored on the blockchain <content>is two chunks<Content chunk 1> and<Content chunk 2> These are divided into, <content>=<Content chunk 1> ||<Content chunk 2> The data can be recombined later as shown below. Here, the operator "||" concatenates two chunks of content data. This concatenation operator may be replaced by any desired bitwise or similar piecewise binary operation. Two chunks<Content chunk 1> and<Content chunk 2> This is then stored in the appropriate output of each separate blockchain transaction. Meanwhile, data related to the attributes of the content data is stored in the unavailable output of each blockchain transaction. Here again, the attributes may include information about the recombination method. For example, the content may be raw data, an executable program, or an HTML webpage. Furthermore, content1 may include a pointer to the blockchain location of content2. This pointer functions in the same way as an embedded HTML link in a webpage.

[0057] It should be noted that both transactions take the same public key P (and ECDSA signature) as input. As a result,<Content chunk 1> and<Content chunk 2> These can be associated by the same public key P, even though they are stored in different transactions, each having TxID1 and TxID2, respectively.

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

[0059] This guarantees the following: · Data integrity: If the data is corrupted, the CHECKSIG operation fails. · Data reliability: It is proved that the owner of P has proved and signed the data.

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

[0061] <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.

[0062] 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.

[0063] <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.

[0064] There are several use cases of the Bitcoin blockchain where participants outside 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.

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

[0066] <Rabin digital signature> <Rabin digital signature algorithm> <Underlying mathematical processes> Definition: Integers mod p The set of integers modulo p is defined as follows:

number

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

number

[0068] Euler's criterion Let p be a prime number. r is a quadratic remainder modulo p only in the following cases and in the following cases:

number

[0069] Modular square root (p=3 mod 4) Let p be a prime number, and the following equation applies.

number

number

number

[0070] Chinese Remainder Theorem Relatively prime positive integers n1, n2, ..., n k and any integers a1, a2, ..., a k Given pairs of congruences, the following system of congruences is given by N=n1n2...n k It has a unique solution modulo .

number

Number

Number

[0071] <Rabin Digital Signature Algorithm> The Rabin Digital Signature Algorithm can be described as follows.

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

[0073] To generate the keys, for the following equation

Number

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

Number

Number

Number

Number

[0075] 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

[0076] <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

[0077] <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

[0078] 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>

[0079] Here, m is an arbitrary message and (S,λ,U) is a valid Rabin signature. Alternatively, if the Rabin signature is verified using Equation 1 above, the Redeem script is given as follows: 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

[0080] In this case, the script evaluates to TRUE only if the following inputs are provided and only if they are provided. <s> <m> <n>

[0081] Both Redeem scripts use the 3072-bit hash projection function "FUNC_HASH3072". Given a message / padding concatenation, the 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)

[0082] <Data compression> Internet data is composed 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, for example, at 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 in the blockchain.

[0083] Large file sizes can be compressed using one of several existing encoding schemes before being embedded in 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.

[0084] Many different algorithms exist, depending on the specific input data. Apple Lossless and Adaptive Transform Acoustic Coding can be used to compress audio files, PNG and TIFF for graphic file compression, and video files, respectively. Video files, on the other hand, can be compressed using one of many lossless video codecs. Any compression of data content can be indicated using flags in the attributes. For example, the flag for the LZW lossless coding scheme in the attributes is: <lzw>It is possible.

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

[0086] Many established techniques exist for encrypting data (plaintext or other data types). These can be classified as asymmetric encryption or symmetric encryption.

[0087] Elliptic Curve Cryptography (ECC) is asymmetric because it relies on a public-private key pair. It is one of the most secure cryptographic systems and is commonly used in cryptocurrencies like Bitcoin. In ECC cryptography, the Koblitz algorithm can be used to encrypt data.

[0088] In symmetric schemes, a single key is used for both encrypting and decrypting data. The Advanced Encryption Standard (AES) algorithm is considered one of the most secure symmetric algorithms, using something like a secret as a seed, 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.

[0089] When encrypting data stored on a blockchain, there are advantages to using the same cryptographic system as the underlying blockchain. In Bitcoin, this is the secp256k1 rule for ECC key pairs in asymmetric cryptography, and the SHA-256 hash function in symmetric cryptography. These advantages are as follows: • The encryption security level is the same as the underlying system on which the data is stored. • The software architecture required to store encrypted data has a smaller codebase. • Key management within the wallet can be used for both transactions and encryption / decryption. • The same key can be used for both encryption and cryptocurrency payments, making it more efficient and requiring fewer keys. This also reduces storage space. • Fewer communication channels are needed to exchange / purchase the ability to decode data. • Because the keys used for encryption and transactions share the same data structure, security is improved and attacks targeting specific types of keys are mitigated. • Keys can be purchased using the underlying cryptocurrency.

[0090] For explanatory purposes, this document explains how the Koblitz algorithm can be used to encrypt data using ECC.

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

[0092] Let's assume it's desirable to encrypt the message "hello world" using the Koblitz method. This is done character by character. The first character "h" is encrypted and decrypted as follows:

[0093] 1. The character "h" is mapped to a point on the secp256k1 curve. This is achieved by using the ASCII rules to map the plaintext character to an 8-bit numerical value. The point on the curve is then calculated by multiplying the base point G by this numerical value. In this example, "h" is mapped to 104 in ASCII, and the elliptic curve point is P m = 104·G.

[0094] 2. The point P m is then encrypted using the public key P1. This is achieved by selecting a random ephemeral key k0 and calculating the pair of points C m = {k0·G, Q}, where Q := P m + k0·P1. This can then be broadcast.

[0095] 3. The owner of the secret key S1 can decrypt the original point by calculating P m = Q - S1·k0·G. They can then restore the original ASCII numerical value by trial and error or using a lookup table to establish which numerical value x corresponds to P m = x·G.

[0096] <Use of blockchain for purchasing permissions> Storing data on the blockchain has the obvious advantage that a payment mechanism is incorporated into the system. Payments can be used to purchase the following. · Decryption data for viewing / using. · Permission to insert data at a specific address.

[0097] In both cases, the buyer is using a cryptocurrency, such as Bitcoin, to purchase a secret that gives them permission to do something. This secret can be a hash preimage or a secret key.

[0098] An efficient and secure way to make such a purchase is to use an atomic swap. This minimizes the secure communication channel and ensures that the seller is paid, the secret is not disclosed to the buyer, or that no event occurs.

[0099] In addition to cryptocurrency payments, it may also be convenient to purchase permission using access tokens. These are secret values ​​(typically hash preimages) owned by the buyer that the buyer can use to make purchases. Such tokens may be purchased in bulk by the buyer beforehand and activated when they actually want to use the permission.

[0100] The following explains how atomic swaps are performed, with reference to Figures 4 and 5.

[0101] <Atomic swap using a hash puzzle or secret key puzzle> Suppose Alice owns a secret. This secret could be a hash preimage of a known hash digest, or the 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 as making this transaction possible. It is atomic in the sense that Alice is paid with Bitcoin, the secret is disclosed to Bob, or nothing happens.

[0102] The method is as follows: Alice's public / private key pair P A =S A G's private key S A Bob owns the public / private key pair P. B =S B G's private key S B To own. Alice possesses a secret which is either a preimage X of a known hash digest H(X), or the private key S1 of a known public key P1=S1·G. They have agreed on the Bitcoin price for which Alice will sell the secret to Bob. Prior to these steps, Bob must set up an off-block transaction to send the temporary key k0 to Alice so that Alice can compute r0, which is a component of the digital signature.

[0103] Now, refer to Figure 4. 1. Bob sends Alice the funds locked by the Redeem script R (described in general terms). Regarding hash preimages,

number

number

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

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

[0106] To prevent Bob's funds from being locked by Alice if Alice fails to pay hers, time-locked funds may be introduced into the procedure.

[0107] <Purchase using tokens> Let's assume the same situation as described above exists. However, instead of paying for Alice's secret with cryptocurrency, Bob could choose to redeem a pre-purchased access token in exchange for the secret at the time of use.

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

[0109] Phase 1: Token Issuance The token issuance phase is, in effect, a one-time purchase of tokens by Bob. For example, Alice purchases 10 different secrets X1, X2, ..., X 10 Bob has 10 tokens T1, T2, ..., T, each granting him access to his respective secret. 10 Consider a scenario where you want to purchase something once.

[0110] 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 the seed, forming a hash chain. Here, each token is calculated as follows:

number

number

[0111] Here, Alice and Bob can agree on a price of 10 units of cryptocurrency for the purchase of 10 tokens. The purchase of these tokens can occur in several ways, which will be explained here using atomic swaps. The atomic swap is initiated by Alice and Bob, who broadcast the transactions shown in Figures 7 and 8, respectively. In both transactions, the output requires the solution to two hash puzzles and a valid signature.

[0112] Once both transactions appear on the blockchain, Alice and Bob will use their initializer value I Alice and I Bob By sharing this information, you can complete the atomic swap for token issuance.

[0113] As a result of this atomic swap, Alice receives payment for the purchase of 10 tokens, and both initializer secrets are revealed. It should be noted that Bob's secret here is Bob =H 10 Only (Y) is meaningful because it defines the first hash puzzle [HashPuzzle (T1)] that needs to be solved. The solution to this puzzle is initializer H 10 (Y) Preimage H 9 (Y)

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

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

[0116] Completion of this atomic swap to redeem tokens has an exchange of a total of zero cryptocurrency funds, with Alice's first secret X1 being disclosed to Bob and Bob's first secret T1 being disclosed to Alice, provided that the amount x is large enough to encourage both parties to use the locked output. Crucially, this also establishes that the next token Bob can use must be the solution T2 to the hash puzzle [Hash Puzzle H(T2)], where the target hash H(T2)=T2 is disclosed to Alice. This process is such that Bob's last token T 10 It can be recursively repeated until Y is used.

[0117] <Naming and addressing> <Node and edge structure> We have explained above how data can be inserted into the blockchain by providing data within a transaction. Below, we present a protocol that structures these transactions in a logical way that enables node addressing, permissioning, and content versioning control. The structure of this decentralized peer Metanet is similar to the existing internet.

[0118] It should be noted that this is a "tier-2" protocol that does not change the underlying blockchain protocol or consensus rules.

[0119] The purpose of the structure described here is as follows: (i) To associate related content within different transactions, enabling the retrieval, identification, and access of data. (ii) Enable the identification of content using human-readable keyword search to improve search speed, accuracy, and efficiency. (iii) Build and emulate a server-like structure within the blockchain.

[0120] Our approach is to structure the data associated with Metanet as a directed graph. The nodes and edges of this graph correspond to the following:

[0121] Node: A transaction associated with the Metanet protocol. Nodes store content. (The terms "content" and "data" may be used synonymously in this specification.)

[0122] The node immediately<Metanet Flag> It is generated by including an OP_RETURN with a public key P. Each node is generated by including an OP_RETURN with a public key P. node It is signed with [this method]. The combination of the public key and the transaction ID uniquely specifies the index of the following node.

number

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

[0124] Edge: The association between a child node and its parent node. The edge is signed Sig P parent Edges are generated when they appear in the input of a Metanet transaction. Therefore, only parents may be allowed to generate 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.

[0125] It should be noted that edge is an aspect of the Metanet protocol and is not a transaction associated with the underlying blockchain itself.

[0126] A valid Metanet node (with a parent) is given by a transaction of the following form: [Table 1] [Table 1]

[0127] This transaction contains all the information necessary to specify the node's index and its parent.

number

[0128] Furthermore, since the parent node's signature is required, only the parent can generate edges to its children. <T x ID parent If a field does not exist or does not point to a valid Metanet transaction, the node is an orphaned child. It does not have any higher-level nodes that it can reach.

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

[0130] As shown in the diagram, the node (transaction) index can be broken down as follows: a) Public key (P node ): This is interpreted as the node's address. b) Transaction ID (TxID) node ): This is interpreted as the node version.

[0131] This structuring gives rise to two advantageous features. 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.

[0132] 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.

[0133] It is worth noting that a standard Internet Protocol (IP) address is unique only within a network at a particular 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 enables data to be permanently anchored to a single object ID node .

[0134] The node and edge structure enables the visualization of the Metanet as a graph, as shown in Figure 13.

[0135] <Domain, Naming, and Content Location within the Metanet> The hierarchical structure of the Metanet graph gives rise to a rich domain-like structure. We interpret nodes without parents as top-level domains (TLDs), their children as subdomains, their grandchildren as sub-subdomains, and so on, and nodes without children as endpoints. See Figure 13.

[0136] The domain name is the ID. node It is interpreted as follows: Each top-level domain within Metanet can be thought of as a tree with a root node (a node without a parent) and leaves (nodes without children). Metanet itself is a global collection of trees that form a graph.

[0137] The Metanet protocol does not stipulate that any node must contain content data, however leaf (child) nodes represent the ends of directed paths in the data tree and are therefore typically used to store content data. Nevertheless, content may be stored in any node in the tree. Protocol-specific flags included as attributes of a node may be used to specify the role of the node in the data tree (disk space, folder, file, or permission modification).

[0138] Remember that the internet uses the Domain Name System (DNS) to associate human-readable names with Internet Protocol (IP) addresses. While DNS is decentralized in some ways, it's actually controlled by a few major players, such as governments and large corporations. Depending on the DNS provider, the same name might be assigned to a different address. This problem arises when mapping short, human-readable names to computer-generated numbers.

[0139] We use human-readable higher-level domain names as the root node's decentralized index ID. root Assume there exists an equivalent distributed system that maps to the following: In other words, there exists the following one-to-one function k that maps human-readable names to Metanet root node indices.

number

[0140] Map k should be interpreted as a means to ensure backward compatibility of Metanet with the Internet when reproducing the human readability of domain names issued by DNS, but the naming and addressing scheme that provides the structure of Metanet does not explicitly depend on this map.

[0141] Possible forms of 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 the DNS within an existing TXT record. This is 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.

[0142] <Vanity Address> The public key used as the address of a Metanet node is not a human-readable object. This can make searching, referencing, and inputting activities error-prone and slow for human users. However, a human-readable public key address, i.e., a vanity address P, which includes a plaintext prefix that can be directly interpreted by the user, is available. vanity It is possible to generate this. Vanity addresses are conventionally known.

[0143] The difficulty in generating such addresses depends on the length of the desired prefix. This means that human-readable vanity addresses can be used as node addresses that depend solely on the owner's effort to generate them, rather than being issued centrally. For a given prefix, many different vanity addresses exist depending on the remaining characters in the suffix. Thus, many node addresses can share a common prefix while maintaining uniqueness.

[0144] An example of a vanity address with a desirable prefix is ​​as follows: Pbobsblog:bobsblogHtKNngkdXEeobR76b53LETtpyT Prefix:bobsblog Suffix:HtKNngkdXEeobR76b53LETtpyT

[0145] The vanity address above is derived from the name "bobsblog" and the node index ID bobsblog This may be used to perform a sense check on the mapping to a node and to aid in the searchability of nodes within the Metanet by address. Note that while the prefix is ​​not unique here, the entire address itself is a unique entity.

[0146] Selected address P vanity The combination with TxID is ID node This is advantageous because it forms a system where there is a non-central issuer for the domain name (TxID is generated by decentralized proof-of-work), and the name is reconstructible from the blockchain itself. Advantageously, there are no longer any points of failure within Internet DNS.

[0147] Since the Metanet domain already provides a permission system (public key), there is no need to issue a certificate to prove ownership. Using blockchain for this purpose has been explored, for example, in namecoin (https: / / namecoin.org / ). According to the present invention, however, everything is accomplished within a single blockchain, so there is no need to use a separate blockchain for this function.

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

[0149] The advantage of this naming system is that users can identify top-level domains within Metanet by memorable words (e.g., company names) rather than hash digests. This also speeds up domain searches because searching by keywords is faster than searching by hash digests. It reduces input errors and therefore provides an improved search tool for data stored on the blockchain.

[0150] Since we have a map from domain names to node indexes, we can construct a resource locator similar to that of an Internet URL (Uniform Resource Locator). We call this a Metanet URL (MURL), and it is in the following format:

number

[0151] 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.

[0152] 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.

[0153] 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

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

[0155] 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

[0156] One possible method for searching for a Metanet is to first use a block explorer to trawl through the blockchain, identify all transactions with the Metanet flag, check if they are valid Metanet nodes, and if so, record their indices 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 of a node with the desired keywords is found, its contents can be read from the block explorer and viewed.

[0157] For example, considering branch P1 in Figure 14, the public keys P0, P1, P 1,1 The corresponding nodes represent the homepage, topic page, and subtopic page, respectively. These nodes are given the names "bobsblog," "summer," and "caribbean," and their attributes are shown below.

number

[0158] In this example, leaf node P 1,1,1 , P 1,1,2 , and P 1,1,3 These 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 path associated with each node in the tree, is shown above the leaves in the diagram.

[0159] 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 their content hash.

[0160] The naming and addressing methods described above offer numerous technical advantages over prior art, including the following: 1. Public Key Address: The system, like a blockchain, uses the same public-private key pair to assign node addresses. This means that the same key set is used for both managing cryptocurrency funds and authorizing content data. This provides an efficient and secure solution. 2. Decentralized domain: TxID that can only be generated by proof-of-work node By including this, the issuance of domain names becomes completely decentralized. Domain names enable the fair distribution of desired domain public keys, and human-recognizable public keys P vanity Vanity addresses can also be incorporated. Here too, this solution provides improved efficiency and security. 3. Graph Structure: The naming and addressing architecture specifies a graph that can be composed of a subset of blockchain data, including Metanet nodes. This design maps the complexity of the internet to the blockchain using an ordered structure. As a result, it fully replicates its functionality and scalability while remaining secure.

[0161] <Browser-Wallet Application> It's important to remember that in the Metanet protocol, all data resides directly within the blockchain itself. In this chapter, we present an embodiment of a computer application for illustrative purposes. Here, for convenience, we refer to a "browser-wallet" that can efficiently access, display, and interact with Metanet data stored on the blockchain.

[0162] Before providing a more detailed explanation in the remainder of this chapter, we will begin with a discussion of the core components and functions of how a browser-wallet interfaces with the decentralized peer internet.

[0163] <Summary> <Component> The browser - wallet is an application that enables end - users to interact with the Metanet infrastructure on the blockchain. This application should enable exploratory search of the Metanet graph for specific content embedded in the tree. Furthermore, the browser - wallet handles content reading, decoding, recombining, and caching (optional).

[0164] The browser - wallet application combines these elements with the cryptocurrency payment mechanism by supporting native (or external) wallets. The browser - wallet includes the following core elements integrated into a single computer application.

[0165] Blockchain search engine: Supports a third - party search engine to query Metanet nodes with various indexes including ID node , node name, keyword, block height, and TxID.

[0166] Display window: Software that unpacks the content returned to the browser by a full - copy blockchain peer. This covers access token decoding, recombining, caching, and redemption.

[0167] Cryptocurrency wallet: Manages the private keys of the blockchain's currency. It can be native to the application or permit communication and synchronization with an external wallet (software or hardware). It can write standard blockchain transactions as well as new Metanet node transactions. It can mediate on - chain purchases of access keys and access tokens.

[0168] Hierarchical deterministic key management is used for both the cryptocurrency public key and the Metanet node address.

[0169] Access Key / Token Wallet: Dedicated key management for purchased access keys or tokens. Keys or tokens purchased using a cryptocurrency wallet can be received, but without permission to them. They may be hidden from the user so that they expire later. This may be achieved through the use of a trusted execution environment. Secure time-stamped access is achieved by synchronizing with the blockchain and querying the current block height.

[0170] <Function> The specifications of the Metanet Browser-Wallet guarantee the following functions of the application. 1. Hierarchical Key Management: The keys used to control funds and 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. Pointing to an External Cryptocurrency Wallet: The ability to authenticate and synchronize with an external (not natively part of the application) wallet enables additional security by removing the browser-wallet as a point of failure. The application describes blockchain transactions, requests signatures from an external wallet that holds the keys, and delegates this responsibility to separate software or hardware. 3. Search for Metanet Content: The browser-wallet supports and can query a third-party search engine that may include functions such as crawling, indexing, serving, and ranking Metanet node transaction data in a global database. A database of OP_RETURN transactions including Metanet protocol flags may be constructed. See BitDB2.0 - https: / / bitdb.network / . The search engine can provide the browser-wallet with a node index that makes the data discoverable. 4. Data Reading and Blockchain Writing: In addition to providing content to browsers using search engines and full nodes, support for cryptocurrency wallets also makes it possible to write content directly from browser-wallets to Metanet. 5. Data decompression and decryption: The browser-wallet can handle the decryption key and perform the decompression of Metanet content on the fly. 6. Node Identifier (ID) node Caching: For more efficient lookups and queries, unique node identifiers can be cached locally. 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 placed on the node. Since Metanet exists on-chain, any full copy peer must have a local copy of the node and its content. This means the user's browser-wallet only needs to query a single peer. This can be done directly without the need for an intermediate web server. Figure 15 shows an overview of the browser-wallet and how its core functionality is divided across different components of the application.

[0171] <Blockchain Search Engine> Search engine: Existing technology Traditional search engines (SEs) rely on powerful web crawlers to locate, index, and rank web content based on user queries. (The same underlying principles can be extended to third-party blockchain SEs that crawl Metanet).

[0172] The SE identifies relevant HTML meta tags and content through keyword searches within the query. The crawl results are then indexed. Here, any embedded images / videos / media files are analyzed and categorized (cataloged). Next, the program ranks the most relevant results from the index, taking into account the user's location, language, and device.

[0173] A typical systems engineer should have the following functions: 1. Crawling: This involves identifying internet data and crawling it through relevant metadata such as domain names, linked pages, and associated keywords. New internet content is discovered through existing content and further crawled for any relevant information. 2. Indexing: Content data is analyzed and categorized (cataloged). This information is stored in a database. 3. Provision and Ranking: Content indexes are ranked in order of relevance to user queries.

[0174] <Block Explorer> The closest blockchain analogy 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 enables high-level, user-friendly queries of the blockchain. It functions similarly to a web browser, but connects to the blockchain instead of the internet. See https: / / en.bitcoin.it / wiki / Block_chain_browser.

[0175] In most cases, these explorers allow you to take blocks (indexed by the hash of the block header), transactions (indexed by the TxID), addresses, and unspent transaction output (UTXO) as input and search them. Many explorers provide their own application programming interfaces (APIs) for reading raw transaction and block data. See https: / / blockexplorer.com / api-ref.

[0176] Block explorers are useful for classifying transactions and displaying their basic information, such as the value of the currency being traded, the coins and addresses, and their history, in a format that is easy for the user to understand, while varying their capabilities. Many explorers, such as Bitcoin.com (https: / / explorer.bitcoin.com / bch) and Blockchain.com (https: / / www.blockchain.com / explorer), and more advanced sites like Blockchair (https: / / blockchair.com / ), have inconsistencies in how they select and present this information, but some even allow viewing of the individual inputs and lock scripts of transactions.

[0177] In recent years, many extensions of basic blockchain explorers have emerged, 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), function similarly to block explorers, classifying and organizing blockchain transactions that contain specific protocol identifiers, as well as displaying the encoded data within those specific transactions.

[0178] However, there are two important issues associated with the use of blockchain explorers. These are resolved by embodiments of the present invention. 1. Universality: There is currently no industry-wide standard for viewing content data stored in a transaction. Content data represents any data unrelated to the protocol used to generate and secure the underlying blockchain. 2. Keyword Search: Content data stored in a transaction needs to be searchable using human-readable keywords. Keyword search is not typically a feature of current block explorers, as they use protocol-based characteristics of the transaction, such as block height, TxID, and address, rather than taking keywords as search input. (However, some, such as Blockchair, can search for words if the word is directly included in the transaction's script.)

[0179] Importantly, the robust naming and addressing structure of the present invention enables and facilitates the construction of more sophisticated blockchain explorers than those previously known, as described above.

[0180] <Suggested Metanet search engine> Browser-wallet applications use node identifiers (IDs). node ) To discover , communicate with a third-party search engine. Such third parties are thought to be able to provide a variety of powerful services that replicate the capabilities of existing Internet search engines.

[0181] The third party of the Metanet search engine maintains a database of all Metanet transactions mined in the blockchain that can be identified by the Metanet protocol flag. This database can classify all Metanet nodes by a range index that includes ID node , node name, keyword, TxID, and block height.

[0182] Services such as Bit DB https: / / bitdb.network / already exist. This continuously synchronizes with the blockchain and maintains transaction data in a standard database format. The browser-wallet offloads the responsibility of crawling, indexing, providing, and ranking Metanet transactions to such third parties and connects to those services when identifying the content stored in the Metanet graph.

[0183] By having a dedicated database only for Metanet data, efficient savings can be made. Unlike Bit DB, this does not store data associated with all transactions, but only stores data containing the Metanet flag. A specific database such as a non-relational database like MongoDB can be more efficient when storing the graph structure of Metanet. This enables faster queries, less storage space, and more efficient association of related content within the Metanet domain.

[0184] Figure 16 illustrates 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, routing is not required, and therefore the present invention offers significant advantages in terms of efficiency, speed, processing, and required resources.

[0185] The process is as follows: 1. The end user enters keywords into the browser-wallet search bar. 2. The browser-wallet sends keyword queries to a third-party SE. 3. The SE checks the keywords against its own database and finds the ID of any Metanet node containing related content. node It returns the following. A third party can provide suggestions for related content and also return other indexes in each node to the user. 4. The browser-wallet uses the node identifier and its associated domain name to construct the MURL. 5. The browser-wallet requests content belonging to a specific node from any network peer that has a full copy of the blockchain. 6. Network peers provide the requested content to the browser-wallet. Since peers have a copy of the blockchain, they also have a copy of the content, and therefore only one request is made, which is never forwarded to other network peers.

[0186] Third-party SEs are only responsible for indexing and maintaining records of Metanet node attributes, while it is emphasized that the raw content data stored on the nodes is instead stored by network peers (e.g., full copy peers, miners, archives) that possess a full copy of the blockchain.

[0187] <Content Display - Metanet Browser> Browser-wallet applications emulate the same front-end capabilities that any standard web browser should offer. These capabilities include, but are not limited to, the following: 1. Searching: Provides access to search engines (SE) to locate content. 2. Retrieval: Connect with the server to transfer content using a known protocol, such as the Hypertext Transfer Protocol (HTTP). 3. Interpreting: Parse and execute the raw code (e.g., JavaScript). 4. Rendering: Effectively displaying parsed content that should be viewed by the end user. 5. User Interface (UI): Provides an intuitive interface for interacting with content, including action buttons and mechanisms for user input. 6. Storage: Local temporary storage capabilities such as internet content caches and cookies to improve repeated access to content.

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

[0189] <Recombining, decompressing, and decrypting> According to a particular embodiment of the present invention, the web browser software component of a browser-wallet application can handle all the operations that need to be performed on a given Metanet content. While there are many such operations that generally need to be performed, we assume that at least the following will be performed by the application using the Metanet protocol and infrastructure.

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

[0191] Decompression: When content data is stored on the blockchain in a compressed format, it should include a flag in the browser-wallet to indicate which standard compression method is being used. The application decompresses the content according to this flag.

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

[0193] When performing these actions on content data, a flag can be used in the browser-wallet to indicate that a given action needs to be performed. This is appropriate as part of the attributes of the node to which the action applies.<operation_flag> This can be generalized to any other actions that may be included.

[0194] <Cash advance> Local file caching and cookies are common and essential features of standard web browsers. Browser-wallet applications are ID node Local storage is also used in a similar manner to optionally retain records and other node attributes related to the content of interest. This allows for more efficient lookup and retrieval of content from frequently visited Metanet nodes.

[0195] Metanet solves the inherent problems associated with caching internet data, which is mutable and can be modified 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 first included as an immutable record on the blockchain.

[0196] <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 (See Ed., 2017, pp. 93–98). The seed is a randomly generated number that acts as the 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 can be fully restored by the seed key. The seed enables easy import / export of wallets between different wallet implementations and gives users more flexibility if they wish to use an external wallet in conjunction with the Metanet browser wallet.

[0197] Hierarchical deterministic (HD) wallets are a well-known method for deriving deterministic keys. In an HD wallet, a parent key generates a set of child keys, and these child keys derive a set of grandchild keys, and so on. This tree-like structure is a powerful mechanism for managing several keys.

[0198] In a preferred embodiment, the HD wallet can be incorporated into the Metanet structure shown in Figure 16. The advantages of using the HD wallet include: 1. Structure: An additional organizational meaning can represent the use of different key bundles 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 possessing the corresponding private key, allowing the HD wallet to function with receive-only capabilities, making it suitable for use on insecure servers. Furthermore, since only a small number of secrets need to be stored, the risk of exposure is low. 3. Recovery: If keys are lost or corrupted, they can be recovered from the seed key.

[0199] <Support for both internal and external wallets> Advantageously, embodiments of the present invention can directly merge the functionality of a traditional web browser with one or more cryptocurrency wallets. Functionally, this is equivalent to combining payments for "Internet" content with the delivery of "Internet" content to end users.

[0200] To achieve this, a browser-wallet embodiment may have a dedicated built-in software component that acts as a cryptocurrency wallet. This wallet is inherent 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.

[0201] 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 in situ.

[0202] <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 connection with the application's native wallet.

[0203] 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 is to 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 broadcasts the transaction and can view the paid content.

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

[0205] Wallets built 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 directly from their applications to the blockchain by selecting the content data that should be embedded from their computer to the blockchain.

[0206] Because browser-wallet applications have a user interface (UI), wallet components can generate and broadcast transactions containing content data configured within the browser component or on the user's computer beforehand. This capability is extremely difficult for a dedicated wallet to achieve on its own.

[0207] <Access Key / Token Wallet> From the above explanation, recall that the Metanet protocol has built-in capabilities to encrypt content using an ECC key pair or an AES symmetric key, and to purchase the corresponding decryption key or token. We refer to these as access keys or access tokens.

[0208] Such keys / tokens grant users permission to view or edit content (one-time or multiple-use), and serve a different purpose from the keys that control 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 used to store and manage access keys and tokens, separate from the application's built-in cryptocurrency wallet.

[0209] It is also possible to introduce the concept of timed access to Metanet content by deactivating the access key / token after a specific period of time. This can be achieved by requiring that the access key / token be stored in a Trusted Execution Environment (TEE) and not directly accessible to the user.

[0210] The fact that access keys / tokens can "disappear" can be an incentive not to store them in a cryptocurrency wallet, in order to ensure that you do not take on the risk of losing your cryptocurrency private keys.

[0211] Similar to cryptocurrency wallets, decryption keys and access tokens can be stored and managed deterministically to enable efficient processing and deployment. Decryption keys (e.g., ECC private keys) can be generated and restored by subsequent additions to a master key. Access tokens, on the other hand, can be reconstructed using a hash chain seeded with some initial token.

[0212] Here, it is important to distinguish that a cryptocurrency wallet handles the generation of deterministic keys for key pairs used when transacting with other users and generating new Metanet nodes, while a key / token wallet handles keys and tokens purchased by a cryptocurrency wallet.

[0213] <Block height permissioning> Timelocks can be included in the Bitcoin scripting language to enable block height permission. The oOp_code OP_CHECKLOCKTIMEVERIFY (CLTV) sets the block height that transaction outputs (UTXOs) are allowed to use.

[0214] The advantages of permitting block height are as follows: 1. Version control: In the Metanet protocol, the latest version node can be identified from the node with the highest block height. Browser wallets can be configured to display the latest version of a file based on block height, and also enable proof-of-work version control. 2. Timed Access: Browser-wallet applications can automatically and periodically expire decryption keys purchased by users. This ensures that viewers can access content data only during the time period they paid for. Cloning of decryption keys can be prevented by storing them in a trusted execution environment (TEE). Furthermore, atomic swaps involve the purchase of a deterministic key (Dk) (for decrypting content data). This deterministic key is publicly visible, but the TEE can be used to sign the combination of the Dk and a securely enclaved private key.

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

[0216] <Web server bypass> This invention enables a novel mechanism for browsers (clients) and web servers to communicate and exchange information over a decentralized peer internet, which bypasses Domain Name System (DNS) servers and standard network routing procedures. See http: / / www.theshulers.com / whitepapers / internet_whitepaper / . This invention provides a novel network architecture in which browser-wallet applications can be served content, including peers that maintain a full copy of the blockchain.

[0217] <Local Full Copy Peer> Consider a system of local peers in each geographical area, such as a postal code, town, or 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 only needs to store blockchain transactions that include Metanet flags, but is not limited to that.

[0218] By default, all users send "get" requests to the LFCP. All requests are serviceable because any requested node ID is available to the LFCP when peers maintain a complete and up-to-date copy of the entire blockchain. Note that a Metanet search engine may act as the LFCP if it is powerful and large enough to store Metanet content and perform the core functions of a standard SE.

[0219] In its simplest example, all LFCPs would have the same storage and disk space overhead (approximately 200GB at the time of filing) if they were all required to store a complete blockchain. The distinction between each LFCP is that they scale their capabilities in response to local demands from Metanet users. Thus, if each Metanet user worldwide requests their nearest LFCP by default, each LFCP should attempt to scale its operational capacity to meet their local demands. Densely populated areas like cities would require LFCP operations involving many clustered servers, while sparsely populated areas like smaller towns would require fewer LFCP operations.

[0220] While disk space requirements are general, it's important to note that CPU requirements for each LFCP adapt to the demands of the local network. This is an example of an adaptive network like Freenet. See https: / / blockstack.org / papers / .

[0221] One advantage of such a system is that given an ID node When retrieving content associated with a peer, the user only needs to establish a single (local) connection with their LFCP. The LFCP does not need to send requests to other peers, as other peers are guaranteed to be served their own requested content.

[0222] Metanet offers many advantages over the internet, such as decentralization and non-redundancy. These are similar to other peer-to-peer (P2P) file-sharing services like IFPS. However, Metanet improves upon these existing P2P models by eliminating immutability and, more importantly, the need to flood the network with requests for a given content.

[0223] The Metanet infrastructure is robust to any one LFCP failure by leveraging this network of peers. This means that if an LFCP is disabled, end users simply use their next nearest LFCP by default. This can be more efficient when LFCPs communicate with each other to indicate which nearby peers are below or above 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 balance of requests among nearby LFCPs.

[0224] <Global Full Copy Peer> Here, we consider a scenario where the universal disk space requirement becomes too large for smaller peers. This can occur because the Metanet portion of the blockchain scales and grows through adoption.

[0225] In this case, smaller LFCPs should use their disk space capabilities to store Metanet node transactions based on the popularity of the system (there are existing techniques for ranking content by the volume and characteristics of the requests). This means that LFCPs adjust both their CPU (for request processing capacity) and their storage allocation (for content delivery capacity) to suit their local geographical requests in terms of both the volume and characteristics of the content.

[0226] To address the fact that LFCPs cannot store all Metanet transaction content, the concept of a Global Full-Copy Peer (GFCP) can be used. A GFCP is a full-copy peer with the following characteristics: 1. GFCP increases its disk space capacity to always maintain a full copy of the blockchain. 2. GFCPs have considerable CPU resources and can therefore handle significantly more requests than LFCPs. Global Full Copy peers must be able to handle a sudden surge in requests if many LFCPs fail.

[0227] GFCP has two main functions. First, it acts as a fail-safe for user requests for Metanet content in the event of an overflow request from LFCP. Second, GFCP acts as an archive peer to store all Metanet content mined in the past. This ensures that any Metanet node content remains accessible even if many LFCPs omit some content from their storage provisioning.

[0228] <Global Databank> The GFCP concept is powerful and explains how Metanet's overall architecture provides a solution to the existing problem of generating a comprehensive global data bank.

[0229] Traditionally, universal, globally accessible data banks could not be configured securely because they had to be maintained by a central authority. This central authority injects both points of failure and points of trust into the system. Importantly, if we rely on an organization to store and maintain all of our internet data, we need to trust that they are doing so correctly and legally without corrupting the information.

[0230] With the Metanet infrastructure, we have effectively eliminated both of these issues—trust and centralization—from the concept of a global data center. Here, such a GFCP can be generated because it does not rely on providing the disk space necessary for storage, but does not rely on verifying and authenticating the information to be stored.

[0231] Metanet verifies what is stored, and this verification process is performed by miners. Therefore, universal global data banks are trustworthy because they do not corrupt blockchain information. GFCP does not need to be trusted; it only needs to provide memory.

[0232] The fact that all GFCPs can store the same information, and that they are always verifiable and provable against the blockchain itself, means that this can be replicated across a large number of such GFCPs.

[0233] This also means solving the problem of having a single point of failure by having multiple global data banks in parallel and storing the same information in a verifiable way.

[0234] Figure 17 shows a system with two LFCPs and one GFCP, illustrating how each peer can support other peers in a network that is robust against the failure of individual peers.

[0235] Aspects of the present invention that may be implemented in the browser-wallet application embodiments described above provide a number of outstanding features and advantages over the prior art, including but not limited to the following: 1. Deterministic Keys: Hierarchical deterministic key management for both cryptocurrency and Metanet addresses is performed within the same wallet component of the application. This allows for the organization of keys with multiple functions, reduces their storage requirements, and enables key recovery. 2. Payment Mechanism: The application allows consumers to pay merchants directly without needing to refer to another application or third-party payment service that traditionally provides authentication and trust. This enables the purchase and delivery of digital content through the same blockchain platform. The application inherently offers the advantages of Bitcoin payments, including small value exchanges, or more complex transactions involving multiple parties. 3. Web Server Bypass: Applications can bypass traditional web servers that handle high volumes of traffic, requests, and routing. This is because applications only need to request content from a single LFCP that is guaranteed to serve the user without having to forward requests to other LFCPs. This reduces the overall traffic volume and the completion time for each request. 4. Timed Access: The application achieves 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 eliminates the need for third-party services to monitor user rights over time while protecting the rights of the original owner.

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

[0237] We consider a scenario where app developer Alice and consumer Bob want to trade 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 application data. The encrypted application data is already exposed as part of a Metanet node transaction.

[0238] Atomic swap applications are known as Swapps. Third-party platforms (Swapp stores) may be used to categorize and advertise applications present on Metanet. However, payment for access keys and their transfer to users like Bob do not need to involve a third party and can be done directly between merchants and consumers.

[0239] The following chapters detail the processes that can be used to buy and sell Swapp, from Alice's app creation to Bob's deployment. Throughout the process, Alice and Bob interact with Metanet using their respective browser wallets.

[0240] <Publishing> 1. Alice describes the application. The data that makes up this application is: <app>This is the content shown by. She has secret key S k Encrypt it using<e(App)> . 2. Alice is the node transaction ID. Alice_App Generate and set her first Metanet domain (tree). She should use 1AliceAppHtKNngkdXEeobR76b53LETtpy (P AliceApp ) generates. 3. Alice then generates children of the first node to form a tree corresponding to the Metanet library in her application. Alice's tree domain is shown in Figure 18. One of the leaf nodes in this tree is an index ID. App Her application <app>This is the corresponding node. On this node, Alice handles the encryption application data.<e(App)> Insert this into the node's input script (scriptSig). The application data is the secret key s k It is encrypted using the Koblitz method. This node transaction is shown below. [Table 3] [Table 3] 4. Alice is ID AliceApp , P AliceApp , and publicly broadcast the domain name "AliceApp". This can be done via social media, internet websites, or third-party Metanet websites.

[0241] <Purchase> 1. Bob wants to download a puzzle game listed on the Metanet website (Swapp Store) that he views on his browser wallet and see Alice's app. 2. Bob then contacts Alice using information from the website and sets up an atomic swap. The swap involves Bob paying Alice the agreed price in Bitcoin, and Alice receiving the secret key s k It is designed to either disclose information or to ensure that no event occurs. 3. Once the atomic swap is complete, Bob's browser wallet will show the secret keys. k Store it in your own access key / token wallet.

[0242] <Expand> Bob now has the keys that will allow him to decrypt the application data that Alice had previously issued. k It has. To download the app and deploy it, Bob does the following: 1. Bob uses the Metanet search engine (SE) to encrypt app data<e(App)> Find the MURL associated with it. 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 contains a unique Metanet node ID that includes encrypted application data within its input script. App It corresponds to. 2. Bob's browser-wallet receives this MURL and sends the request to the nearest appropriate LFCP. This peer then sends the requested data to Bob.<e(App)> To provide. 3. Browser-wallet is ID App The data is processed according to the attributes of the secret key. k Use to decode application data <app>This includes processing [something]. 4. Bob is an application <app>He downloads it from his browser to his computer. Bob can now deploy applications locally without having to purchase access beforehand.

[0243] Figure 19 illustrates the overall process outlined in the use case described above. The flowchart shows two action branches: Alice's (starting from the left) and Bob's (starting from the right). Alice's branch represents the initial issuance phase, while Bob's represents the phase of setting up the purchase via atomic swap.

[0244] In Bob's branch, as part of the atomic swap setup phase, he entered the following transaction TxID Bob Broadcast it. [Table 4] [Table 4]

[0245] In this transaction, the output is the secret decryption keys that should be disclosed to Bob for Alice to use (spend). k It is locked by a secret key puzzle that requires [something].

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

[0247] As soon as this transaction is broadcast, Alice and Bob's actions fork again. Alice receives payment in xBitcoin, while Bob receives the secret decryption key s k It can receive data and read and decode Alice's application from Metanet.

[0248] Referring to Figure 20, a simplified block diagram is provided for describing a computing device 2600 that may be used to carry out at least one embodiment of the present disclosure. 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 to be used as a data server, a web server, a portable computing device, a personal computer, or any electronic computing device. As shown in Figure 20, the computing device 2600 may include one or more processors having one or more levels of cache memory and memory control units (collectively labeled 2602) that can be configured to communicate with a storage subsystem 2606 which includes a main memory 2608 and a permanent storage device 2610. The main memory 2608 may include, as shown, a dynamic random access memory (DRAM) 2618 and a read-only memory (ROM) 2620. The storage subsystem 2606 and the cache memory 2602 may be used for storing information such as transaction and block-related details as described in the present disclosure. The processor 2602 may be used to provide any step or function of any embodiment described herein.

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

[0250] The bus subsystem 2604 may provide a mechanism that enables the various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0251] The network interface subsystem 2616 may provide interfaces to other computing devices and networks. In some embodiments, the network interface subsystem 2616 may function as an interface for receiving data from and sending data to other systems of the computing device 2600. For example, the network interface subsystem 2616 allows data technicians to connect the device to a network. As a result, data technicians can send data to and receive data from the device even if they are in a remote location such as a data center.

[0252] The user interface input device 2612 may include one or more user input devices, such as a keyboard, integrated mouse, trackball, touchpad, or graphics tablet; a scanner, barcode scanner, touchscreen integrated into a display; a voice recognition system; an audio input device such as a microphone; and other types of input devices. Generally, the use of the term “input device” is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0253] 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 planar display such as a cathode ray tube (CRT), liquid crystal display (LCD), light-emitting diode (LED) display, or projection, or other display device. Generally, the use of the term “output device” is intended to include all possible types of devices and mechanisms that output information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface and facilitate user interaction with an application that performs the processes and variations described herein, when such interaction is appropriate.

[0254] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data structures that provide functionality for at least one embodiment of the Disclosure. Applications (e.g., programs, code modules, instructions), when executed by one or more processors, may provide functionality for one or more embodiments of the Disclosure and 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 further provides a repository for storing data used in accordance with the Disclosure. For example, main memory 2608 and cache memory 2602 may provide volatile storage for programs and data. Permanent storage devices 2610 may provide permanent (non-volatile) storage for programs and data and may include magnetic hard disk drives, one or more floppy disk drives associated with removable media, one or more optical drives (e.g., CD-ROM, or DVD, or Blu-ray) associated with removable media, and other similar storage media. Such programs and data may include programs for performing steps of one or more embodiments described in the Disclosure, and data associated with transactions and blocks described in the Disclosure.

[0255] The computing device 2600 may be of various types, including a portable computer, a tablet computer, a workstation, or any other device described later. Furthermore, 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.). The device that can be connected to the computing device 2600 may include multiple ports configured to receive optical fiber connectors. Thus, this device may be configured to convert optical signals into electrical signals transmitted to the computing device 2600 through ports to which the device is connected for processing. Due to the constantly changing characteristics of computers and networks, the description of the computing device 2600 shown in Figure 20 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Many other configurations are possible with more or fewer components than the system shown in Figure 20.

[0256] It should be noted that the embodiments described above are illustrative, not limiting, of 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 numerals in parentheses are not intended to limit the claims. The terms “comprising,” “comprises,” etc., do not preclude the existence of elements or steps other than those enumerated in any claim or throughout the specification. In this specification, “comprising” means “having or comprising,” and “comprising” means “comprising or comprising.” A singular reference to an element does not preclude multiple references to that element, and vice versa. The invention can be implemented by hardware comprising several distinct elements and by a appropriately programmed computer. In an apparatus claim enumerating several means, some of these means may be embodied by a single identical hardware item. The mere fact that certain means are described in different dependent claims does not imply that combinations of these means cannot be used advantageously.< / app> < / app> < / app> < / app> < / lzw> < / n> < / m> < / s> < / n> < / m> < / s> < / content> < / content> < / content> < / attributes>

Claims

1. A computer-based method for storing content data on a blockchain, wherein the method is The steps include generating a blockchain transaction, wherein the blockchain transaction grants access to content data, and the content data is not related to the protocol used to generate and secure the blockchain, The aforementioned blockchain transaction is A first output comprising the content data to be stored on the blockchain, A second output comprising at least one attribute data representing at least one attribute of the content data, It has, i) The at least one second output is separate from each of the first outputs, ii) A method wherein the content data is stored in the available portion of the at least one first output of the blockchain transaction, and the attribute data is stored in the unavailable portion of the at least one second output of the blockchain transaction.

2. The at least one attribute includes at least one keyword, The method according to claim 1, wherein the at least one attribute includes a flag indicating that the content data is stored in accordance with a protocol for structuring the blockchain transactions in a logical manner.

3. The method described above is: By providing or using a search engine, block explorer, or browser, Identify multiple blockchain transactions containing the aforementioned flag, The method according to claim 2, further comprising the step of using at least one keyword of the attribute data as a search key for searching and retrieving the content data stored in the plurality of blockchain transactions.

4. The method according to claim 3, further comprising the step of storing the plurality of blockchain transactions including the flag in a database.

5. The aforementioned attribute data is, i) Data related to the recombination of the content data, or ii) A search key for searching the content data stored in the blockchain, The method according to claim 1 or 2, including the method described in claim 1 or 2.

6. The method according to any one of claims 1 to 5, wherein the at least one second output includes instruction data indicating that the blockchain transaction includes the content data.

7. The method according to any one of claims 1 to 6, wherein the attribute data represents at least one attribute of the content data, which is at least one of the data type, data encryption method, data compression method, index information, permission information, encoding information, or search information of the content data.

8. The method according to any one of claims 1 to 7, wherein the at least one first output and / or the at least one second output includes a script opcode for marking the output invalid for subsequent use as input to a later transaction.

9. The method according to any one of claims 1 to 8, wherein the at least one first output is redeemable by at least one key corresponding to each digital signature applied to the content data.

10. The method according to any one of claims 1 to 9, wherein a digital signature is applied to the content data.

11. At least one of the aforementioned digital signatures is i) Based on a cryptographic system having a public-private key pair, the private key is based on a plurality of prime numbers, and the corresponding public key is based on the product of a plurality of the aforementioned prime numbers, or ii) The method according to claim 10, wherein the signature is Rabin signature.

12. The method according to any one of claims 1 to 11, further comprising the step of applying data compression to the content data and / or attribute data.

13. The method according to any one of claims 1 to 12, wherein the content data includes audio files, graphic or image files, video files, text documents, source code, executable programs, HTML web pages, or internet data.

14. A system implemented by a computer, Processor and A memory including executable instructions that cause the system to perform a method performed by a computer according to any one of claims 1 to 13 as a result of execution by the processor, A system that includes this.

15. A non-temporary computer-readable storage medium storing executable instructions, wherein the executable instructions, as a result of being executed by the processor of a computer system, cause the computer system to perform at least the method according to any one of claims 1 to 13.

Images