Systems and methods for efficiently and securely processing, accessing, and transmitting data via blockchain networks.

Abstract

This invention provides improved methods and systems for storing, sharing, accessing, and processing data (content) on a blockchain. In one embodiment, a method for identifying a target transaction on a blockchain is provided, including the step of identifying the target transaction using a search path, the search path comprising: 1) a root transaction index (RT) Index The method includes: 1) a public key (RTPK) associated with the root transaction and an ID (RTID) associated with the root transaction; and 2) at least one attribute associated with the root transaction and / or the target transaction. This enables the creation and use of search paths similar to those known about the Internet, but used for blockchains.

Description

Technical Field

[0001] This invention generally relates to improvements in data communication and exchange across electronic networks, particularly peer-to-peer networks (such as blockchain networks). It relates to data storage, access, retrieval, and processing, especially such data-related activities on blockchains. This invention is particularly suitable, but not limited to, processing data in a manner similar to that provided by websites and web pages, but using blockchain as the underlying mechanism or platform rather than web servers. Therefore, this invention provides a secure, efficient, and cryptographically implemented alternative infrastructure for data processing and transmission. Background Technology

[0002] In this document, 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 their variations. The term "user" in this document can refer to a person or a processor-based resource.

[0003] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system composed of blocks, which in turn are transactions. Each transaction is a data structure that encodes the transfer of control of digital assets among 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, allowing blocks to be chained together to create a permanent, immutable record of all transactions written into the blockchain from the very beginning. Transactions contain applets called scripts embedded in their inputs and outputs, specifying how and by whom the transaction's outputs can be accessed.

[0004] For a transaction to be written to the blockchain, it must be "verified." Network nodes perform the work of ensuring that each transaction is valid, while invalid transactions are rejected by the network. Software clients installed on nodes perform this verification work for unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and is written to the blockchain. Therefore, for a transaction to be written to the blockchain, it must: i) be verified by the first node receiving the transaction – if the transaction is verified, that node will relay it to other nodes in the network; ii) be added to a new block; and iii) be added to the public ledger of past transactions.

[0005] It would be highly advantageous if blockchain could be used for tasks and processes that could leverage its benefits (e.g., permanence of events, tamper-proof records, distributed processing, etc.) and have more uses in its applications.

[0006] One area of ​​interest is using blockchain to store, share, access, and control data between users. Currently, this is achieved via the internet, where servers host websites and pages, which users typically access through search engines to obtain the data they need.

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

[0008] Therefore, it is desirable to provide an arrangement that enables the advantageous use of the distributed, immutable, distributed, and permanent properties of blockchain to store, process, retrieve, search, and / or share such data on the blockchain. Such an improved scheme has now been devised.

[0009] The embodiments of this disclosure provide at least efficient and secure techniques for implementing blockchain schemes and for alternatives to storing, processing, searching, and / or retrieving data thereon or from them. The embodiments also provide at least a technical infrastructure for alternative blockchain implementations for storing, processing, retrieving, transmitting, searching, and / or sharing data among computing nodes. Because the present invention enables the use of blockchain networks in new ways and for providing improved technical results, it provides an improved network implementation of blockchain.

[0010] The embodiments also provide a scheme for securely controlling access to digital resources on technically different and improved computing platforms, including blockchains and blockchain protocols.

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

[0012] According to the present invention, a computer-implemented method and a corresponding system can be provided. The method can be described as a method for enabling or controlling the processing, storage, retrieval, identification, and / or sharing of data via a blockchain. Additionally or alternatively, it can be described as a method for associating or linking data stored in (separate / different) blockchain transactions to achieve the identification, retrieval, and / or sharing of said data.

[0013] Additionally or alternatively, it can be described as a method for identifying target transactions (Tx) on a blockchain. A target transaction can be a transaction that a user (human or machine) is searching for or attempting to locate / identify.

[0014] The method may include the following steps:

[0015] Use a search path to identify the target transaction. This search path includes:

[0016] i) Root Transaction Index (RT) Index This includes the public key (RTPK) associated with the root transaction.

[0017] and the ID (RTID) associated with the root transaction; and

[0018] ii) At least one attribute associated with the root transaction and / or the target transaction.

[0019] In one or more embodiments, at least one attribute may be empty.

[0020] Advantageously, this enables the creation and use of search paths similar to those known about the Internet, but used for peer-to-peer network architectures (e.g., blockchains).

[0021] The term "ID" is used to denote "identifier". Root Transaction Index (RT) Index This can be a hash of a function that includes a public key (RTPK) and an ID (RTID). This function can be a concatenation.

[0022] At least one of the attributes can be a mnemonic associated with the root transaction or the target transaction. The mnemonic can be a human-readable identifier, term, or label. This provides the advantage that searching content on the blockchain can be performed more easily, quickly, and with fewer input errors, thus providing an enhanced and improved search / storage / sharing / data communication solution.

[0023] In this document, "sharing" can include providing, sending, communicating, transmitting, or providing access to portions of data to nodes or users. The term "processing" can be interpreted as any activity relating to a transaction or its associated data, including generating, transmitting, verifying, accessing, searching, sharing, submitting, and / or identifying data to the blockchain network.

[0024] Preferably, the root transaction and / or target transaction includes a (search) protocol identifier. Preferably, the protocol identifier is associated with and / or indicates a blockchain-based protocol used to search, store, and / or retrieve data within one or more blockchain transactions. The protocol identifier can be an indicator or mark. It can indicate that the transaction was formed according to a predetermined protocol. This may be a protocol other than the protocol of the underlying blockchain. It can be a search protocol according to any embodiment described herein (i.e., a search protocol that may be referred to as the “meta-network” protocol described herein).

[0025] The method may include the following steps: using a block detector to identify at least one transaction in the blockchain that includes a protocol flag.

[0026] This method may include the following steps: identifying at least one transaction, including a protocol identifier, in the blockchain, and storing data related to the at least one transaction in a resource outside the blockchain. This provides the advantage of storing data efficiently for rapid access.

[0027] Preferably, the data related to at least one transaction includes:

[0028] At least one index associated with the transaction;

[0029] At least one index associated with another transaction linked to that transaction; and / or

[0030] Keywords associated with the transaction.

[0031] The method may further include the step of accessing a portion of data stored in or referenced from the target transaction. Preferably, a blockchain transaction may include a portion of data, or a reference to a portion of data. A reference to a portion of data may be a pointer, address, or other indicator of the location where data is stored. A portion of data may be any type of data or digital content, such as a computer-executable project, text, video, image, sound file, etc. A portion of data may be referred to as "content." A portion of data or a reference to it may be in a processed form. For example, it may be a hash digest of a portion of data. Data may be stored on or off the blockchain (i.e., "off-chain").

[0032] Preferably, the public key (RTPK) associated with the root transaction includes a human-readable prefix. This provides the advantage that the public key includes a portion of text that is more easily read or recognized by humans, making searching, processing, accessing, and retrieving easier, faster, and less error-prone.

[0033] The method may include the following steps: processing at least one blockchain node transaction (Node) that includes the following:

[0034] Protocol identifier;

[0035] Discretionary public key (DPK); and

[0036] Freely determined transaction ID (DTxID).

[0037] This combination of features enables the individual data portions stored in node transactions to be identified on the blockchain and linked / associated with each other when provided in multiple transactions. It allows for the construction of graph or tree structures that reflect the hierarchical relationships between the data portions, thus facilitating their processing and sharing.

[0038] The discretionary public key (DPK) and / or discretionary transaction ID (DTxID) can be "discretionary" in that they are provided as part of this invention, rather than as essential components of a transaction as defined by the protocol of the underlying blockchain. In other words, they are not required for transactions to be valid according to the protocol of the underlying blockchain. They are additional, non-essential items provided as part of this invention, not because the blockchain protocol requires them.

[0039] Preferably, the data portion, references to that data portion, protocol flags, freely determined public key (DPK), and / or freely determined transaction ID (DTxID) are provided at a position following the script opcode within the transaction (Tx), which is used to mark the output as invalid for subsequent use as input in subsequent transactions.

[0040] The script opcode can be the OP_RETURN opcode from one or more variants of the blockchain protocol, or it can be a functionally similar / equivalent opcode from another blockchain protocol.

[0041] Preferably, a transaction (Tx) also includes one or more attributes. This makes the method of searching data / content more detailed. Attributes can also be called "values," "tags," "markers," or "identifiers." They can be used to describe or annotate data portions, or provide additional information related to data portions.

[0042] The present invention also provides a corresponding system arranged and configured to perform steps of any embodiment of the methods described herein. It may include a computer-implemented system comprising:

[0043] Processor; and

[0044] The memory includes executable instructions that, when executed by a processor, cause the system to perform any embodiment of the computer-implemented methods described herein.

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

[0046] Some embodiments of the method / system of the present invention may include one or more features as described below, particularly those in the section entitled "Naming and Addressing". Attached Figure Description

[0047] These and other aspects of the invention will become apparent from and be elucidated by reference to the embodiments described herein. Embodiments of the invention will now be described by way of example only and with reference to the accompanying drawings, in which:

[0048] Figure 1 A blockchain transaction embodying the present invention is shown, in which data is stored in multiple outputs;

[0049] Figure 2 A blockchain transaction embodying the present invention is shown, in which data is stored in the input.

[0050] Figure 3 A series of blockchain transactions embodying the present invention are shown, in which data is stored on the output of multiple blockchain transactions;

[0051] Figure 4 A blockchain transaction embodying the present invention is shown, which transmits payments to allow access to data via atomic swaps;

[0052] Figure 5 This illustrates a blockchain transaction embodying the present invention for exchanging... Figure 4 Payment for the transaction;

[0053] Figure 6 The invention illustrates a secret value held by a participant in a blockchain transaction that embodies the present invention, the blockchain transaction issuing a token to allow access to the data via atomic swap;

[0054] Figure 7 and Figure 8 A blockchain transaction embodying the present invention is shown, used to issue tokens to allow access to data via atomic swaps;

[0055] Figure 9 and Figure 10 This illustrates a blockchain transaction embodying the present invention, used for exchanging via... Figure 7 and Figure 8 The token issued in the transaction;

[0056] Figure 11 and Figure 12 It shows the access to the Figure 9 and Figure 10 Secret blockchain transactions for exchange;

[0057] Figure 13 A diagram illustrating a meta-network structure according to an embodiment of the present invention is provided.

[0058] Figure 14 An illustration of a meta-network tree for the domain “bobsblog” that includes an MURL search path, according to an embodiment of the present invention, is shown.

[0059] Figure 15 A diagram is provided illustrating how to perform a search within the infrastructure of an embodiment of the present invention.

[0060] Figure 16 Illustrative interactions between a local full-copy peer and a global full-copy peer are shown according to embodiments of the present invention.

[0061] Figure 17 A meta-network tree (or graph) is shown for reference to the illustrative use cases described below.

[0062] Figure 18 A flowchart is shown that illustrates the process embodied in the illustrative use case provided below.

[0063] Figure 19 This is a schematic diagram illustrating a computing environment in which various embodiments can be implemented. Detailed Implementation

[0064] In the remainder of this document, the protocol that defines the operation of embodiments of the present invention will be referred to as the "meta-network protocol".

[0065] According to embodiments of the present invention, the terms "content" and "data" may be used interchangeably herein to refer to data stored in blockchain transactions.

[0066] Overview

[0067] As mentioned above, it has been recognized that there is a need for an improved and / or alternative infrastructure for storing, writing, accessing, and viewing data between and by computing nodes. Leveraging the inherent advantages of blockchain technology (e.g., immutable records, cryptographically implemented control and access, built-in payment mechanisms, the ability to publicly inspect the ledger, etc.) would be advantageous. However, from many technical perspectives, building an "internet implemented with blockchain" is challenging.

[0068] These challenges may include, but are not limited to: how to locate specific portions of data within a network; how to protect and control access to data so that only authorized parties have access; how to transfer data from one party to another in a peer-to-peer manner; how to arrange data so that it can be logically related but still stored in different locations within the network, and subsequently how to combine it from different locations to provide overall and enhanced results; how to provide and / or store data in a hierarchical manner; how to allow users and parties with different computing platforms to access the data they need; and how to store, provide, and share data across (potentially global) computing networks without relying on or requiring large storage servers and centralized data controllers.

[0069] This invention provides such an improved solution in a manner similar to the Internet in some respects, but using a platform with hardware and software components entirely different from those known in the prior art, and achieving its results in a completely different way. According to embodiments of the invention, servers storing Internet / network data and providing it to end users are replaced by blockchain exchanges residing on the blockchain network. To achieve this, several innovations must be designed. These will be described in the following sections.

[0070] Inserting data into the blockchain "meta-network" (refer to...) Figure 1 The diagram illustrates a blockchain transaction embodying the present invention, in which first data to be stored on the blockchain is stored in one or more first outputs of the transaction, and second data representing attributes of the first data is stored in one or more second outputs of the transaction. One or more first portions <content 1> of the first data are stored in the spendable outputs of the transaction. Data <attribute 1> and <attribute 2> representing the corresponding attributes of the first data, as well as flags indicating that data is being stored according to the metanetwork protocol, are stored in the second unspendable outputs of the transaction. The term "unspendable" used to indicate that at least one first and / or second output of the transaction may include a script opcode (OPRETURN) used to mark the output as invalid for subsequent use as input in subsequent transactions.

[0071] It is advantageous to store the content and attributes of the data separately in a separate output (UTXO) of the transaction.

[0072] Figure 2 A blockchain transaction embodying the present invention is illustrated, in which first data <Content 1> to be stored on the blockchain is stored in the transaction input. Metanet identifiers and attribute data <Attribute 1> and <Attribute 2> are displayed in a manner similar to... Figure 1 The arrangement shown is stored in the non-spendable output of the transaction.

[0073] Data Insertion

[0074] Data insertion method

[0075] We hope to insert the following data into the blockchain.

[0076] a) Metanet logo

[0077] b) Attributes

[0078] c) Content

[0079] Content refers to the data to be stored on the blockchain. The metanet identifier is a 4-byte prefix that acts as an identifier for any data related to the metanet protocol, while attributes contain indexing, licensing, and encoding information about the content. This can include, but is not limited to, data type, encryption, and / or compression schemes. Such attributes are often also referred to as metadata. To avoid confusion with transaction metadata, this term will be avoided in this document.

[0080] The following technologies can be used to embed this data into blockchain scripts:

[0081] 1. OP_RETURN - In this method, all data (attributes and content) is placed after OP_RETURN in the locked script of the provable, non-spendable transaction output.

[0082] Here is an example of the output script using this operator:

[0083] UTXO0:OP_RETURN<Metanet Flag> <attributes> <content>

[0084] 2. OP_RETURN with OP_DROP - In this case, OP_RETURN includes attributes, and the content is stored before OP_DROP in the spendable transaction script (lock or unlock). The content can be split into multiple packets in the transaction input and output. If data is inserted into the transaction input, OP_MOD can be used as a checksum for the data instead of network node verification to ensure its validity. For example, a 32-bit OP_MOD operation can be performed and checked to see if it equals a pre-calculated value.

[0085] In this case, the attribute can contain information about how the content data packets were reassembled. Additionally, providing the hash of the reassembled data packet H (content 1 + content 2) as an attribute allows verification that the recommended reassembly scheme has been used.

[0086] Figure 1 The diagram illustrates a transaction that implements the second data insertion method. For simplicity, the transaction only includes the content inserted into its output, which is signed by its single input. Figure 2 The method shown can also be used with the OP_DROP statement to insert content into another input.

[0087] If the content is large, it may be advantageous to divide it across multiple transactions. Such an arrangement... Figure 3 As shown in the image. Figure 3 A pairwise blockchain transaction embodying the present invention is illustrated, in which first data <content> to be stored on the blockchain is divided into two blocks <content block 1> and <content block 2>, which can then be reassembled into <content> = <content block 1>||<content block 2>, where the operator "||" concatenates the content data blocks of the two blocks. This concatenation operator can be replaced by any desired bitwise or similar piecewise binary operator. The two blocks <content block 1> and <content block 2> are then stored in the corresponding spendable outputs of separate blockchain transactions, while data related to the attributes of the content data is stored in the corresponding non-spendable outputs of the blockchain transaction. Again, the attributes can contain information about the reassembly scheme. For example, the content can be raw data, an executable program, or an HTML webpage. Additionally, content 1 can include a pointer to the location of content 2 on the blockchain, which functions in the same way as an embedded HTML link within a webpage.

[0088] It should be noted that the two transactions will use the same public key P (and ECDSA signature) as input, so that although <Content Block 1> and <Content Block 2> are stored in different transactions with TxID1 and TxID2 respectively, they can be related by the same public key P.

[0089] Utilizing the role of network node verification

[0090] Here, the transaction verification process performed by the network nodes is used to gain an advantage when storing this data. This is because all data in the transaction output will be signed by the owner of the public key P in at least one transaction input (if the SIGHASH|ALL flag is present), and this signature will be checked during the transaction verification process performed by all network nodes.

[0091] This ensures

[0092] ●Data Integrity - If the data is corrupted, the CHECKSIG operation will fail.

[0093] ●Data Authenticity - The owner of P has verifiable witnessing and signing of the data.

[0094] This is particularly advantageous for content that is segmented across multiple transactions, because the input signature of P provides a provable link between the segmented components of the data, as referenced above. Figure 3 The arrangement shown is described.

[0095] Rabin's signature

[0096] Another way to ensure data authenticity is to use Rabin signatures, which can be used to sign the data itself rather than the entire message. This can be advantageous because the signer does not need to sign every individual transaction in which the data appears, and the signature can be reused across multiple transactions.

[0097] Rabin signatures can be easily verified in a script. These can be incorporated into case (2) above by inserting Rabin signature verification before the OP_DROP command.

[0098] <content1><Rabin Sig(content1)>FUNC_CHECKRABSIG OP_DROP<H(P1)> [CheckSigP1]

[0099] It should be noted that this cannot be done in case (1) above, because the script containing OP_RETURN fails in any case, so verification cannot be performed.

[0100] Specific examples of using Rabin signatures

[0101] introduce

[0102] Digital signatures are a fundamental part of blockchain protocols. They ensure that any transaction recorded on the blockchain has been authorized by the rightful holder of the token being sent. In blockchain transactions, the Elliptic Curve Digital Signature Algorithm (ECDSA) is used to sign transaction messages. However, ECDSA signatures are typically applied to the entire transaction.

[0103] There are use cases for blockchains where participants from outside the network might want to provide signatures for arbitrary data types, which network participants can then use. With Rabin digital signatures, any segment of data can be signed—even if it originates outside the blockchain and is then placed in one or more transactions.

[0104] We will now demonstrate how data can be signed and verified directly in scripts using the algebraic structures of the Rabin cryptosystem.

[0105] Rabin Digital Signature

[0106] Rabin Digital Signature Algorithm

[0107] Background Mathematics

[0108] Definition – Integer mod p

[0109] Integer modulo p is defined as the following set

[0110]

[0111] Fermat's Little Theorem

[0112] Let p be a prime number. Then, for any integer a, the following condition applies.

[0113] a p-1 ≡1 mod p

[0114] Euler's Criterion

[0115] Let p be a prime number. r is a quadratic remainder mod p if and only if the following equation is satisfied.

[0116]

[0117] Modulo square root (p = 3 mod 4)

[0118] Let p be a prime number such that p ≡ 3 mod 4. Then for any integer r satisfying Euler's criterion, if a is an integer, then such that...

[0119] a 2 ≡r mod p

[0120] Then, a has a solution of the form:

[0121]

[0122] Chinese Remainder Theorem

[0123] Given pairs of coprime positive integers n1, n2, ..., n k and any integer a1, a2, ..., a k A system of simultaneous congruences

[0124]

[0125] It has a unique solution modulus N = n1n2…n k As a special case of the Chinese Remainder Theorem, it can be shown that:

[0126] If and only if

[0127] When x≡r mod n1·n2,

[0128] x≡r mod n1 and x≡r mod n2

[0129] Rabin Digital Signature Algorithm

[0130] The Rabin digital signature algorithm can be described as follows:

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

[0132] To generate the key, prime numbers p and q are chosen, each with a bit length approximately k / 2, such that p ≡ 3 mod 4 and q ≡ 3 mod 4. Their product n = p·q is then calculated. The private key is (p, q), and the public key is n = p·q.

[0133] In order to sign message m, the signer chooses to fill U such that H(m||U) satisfies

[0134]

[0135] The signature S is calculated using the following formula

[0136]

[0137] The signature of message m is a pair (S, U). Verification can be performed simply by checking the following formula for a given m, U, and S.

[0138] H(m||U)≡S 2 mod n (Equation 1).

[0139] An integer λ exists in the range 0,…,n-1 such that…

[0140] H(m||U)+λ·n=S 2 When (Equation 2) is true, this is true.

[0141] The factor λ can be safely included in the signature to provide the combination (S,λ,U).

[0142] The advantages of the Rabin signature scheme are as follows:

[0143] a) Signature generation is computationally expensive, while signature verification is computationally easy.

[0144] b) The security of the signature depends solely on the difficulty of integer factorization. Therefore, Rabin signatures are inherently unforgeable (unlike RSA).

[0145] c) The hash function value H(m||U) must have a size similar to the public key n.

[0146] The verification in the script is simple and straightforward, as it only requires squaring the given signature, performing modular reduction, and then checking whether the result is equal to H(m||U).

[0147] Rabin's signature certificate

[0148] Let p and q be coprime, and n = p·q. Using the Chinese Remainder Theorem, we can show:

[0149] If and only if

[0150] S 2 ≡H(m||U)mod p

[0151] S 2 When ≡H(m||U)mod q,

[0152] but

[0153] S 2 ≡H(m||U)mod n

[0154] Use the following equation

[0155]

[0156] It can be shown that:

[0157] S 2 ≡H(m||U)mod q

[0158] so

[0159]

[0160] Here, it is assumed that H(m||U) satisfies the Euler criterion. Through similar calculations, it can also be shown that:

[0161] S 2 ≡H(m||U)mod p.

[0162] Blockchain Rabin's signature

[0163] Signature verification in script

[0164] A small amount of arithmetic and stack manipulation opcodes are needed to verify the Rabin signature. Consider the following form of redemption script.

[0165] OP_DUP OP_HASH160 <H 160 (n)>OP_EQUALVERIFY OP_MUL OP SWAP OP 2 OP ROLLOP CAT FUNC HASH3072 OP ADD OP_SWAP OP_DUP OP_MUL OP_EQUAL

[0166] Where n is the signer's public key. This evaluates to true if and only if the following input is given.

[0167] <s> <m><λ> <n>

[0168] Where m is an arbitrary message, and (S,λ,U) is a valid Rabin signature. Alternatively, if the Rabin signature has been checked using Equation 1 above, the redemption script is given by the following:

[0169] OP_DUP OP_HASH160 <H 160 (n)>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

[0170] In this case, it will evaluate to true if and only if the following input is given.

[0171] <s> <m> <n>

[0172] Both of these exchange scripts use the 3072-bit hash projection function "FUNC_HASH3072". For a given message / padding concatenation, the following script generates the FUNC_HASH3072 hash projection:

[0173] OP_SHA256{OP_2OP_SPLIT OP_SWAP OP_SHA256 OP_SWAP}(x11)

[0174] OP_SHA256 OP_SWAP OP_SHA256{OP_CAT}(x11)

[0175] Data compression

[0176] Internet data consists of JavaScript and common file types (e.g., text files (SML, HTML, etc.), video files (MPEG, M-JPEG, etc.), image files (GIF, JPEG, etc.), and audio files (AU, WAV, etc.), as described in more detail at the following link: 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 on the blockchain.

[0177] Before embedding large file sizes onto the blockchain, they can be compressed using one of several existing encoding schemes. Lossless data compression algorithms such as run-length encoding and Huffman coding can be used for several applications, including ZIP files, executable programs, text documents, and source code.

[0178] Depending on the specific input data, many different algorithms exist. Apple's lossless and adaptive transform audio coding can be used to compress audio files, PNG and TIFF for compressing image files, while movie files can be compressed using one of many lossless video codecs. Flags within the attribute can be used to indicate any compression of the data content. For example, the flag in the attribute used for the LZW lossless coding scheme would be... <lzw>.

[0179] Decryption of encryption and payments

[0180] Data encryption

[0181] Content owners can choose to protect their content before embedding it on the blockchain. This ensures that the content cannot be viewed without the necessary permissions.

[0182] There are many recognized techniques for encrypting data (plaintext or other data types). These techniques can be categorized as asymmetric encryption or symmetric encryption.

[0183] Elliptic curve cryptography (ECC) is asymmetric because it relies on public-key pairs. It is one of the most secure cryptographic systems. For ECC cryptography, the Koblitz algorithm can be used to encrypt data.

[0184] In symmetric schemes, a single key is used to both encrypt and decrypt data. The Advanced Encryption Standard (AES) algorithm is considered one of the most secure symmetric algorithms, generated from such a secret as a seed, as described in more detail in the following literature: C. Paar and J. Pelzl, Chapter 4 of "Understanding Cryptography", Springer-Verlag Berlin Heidelberg, 2nd ed., 2010, pp. 87–118.

[0185] When encrypting data stored on a blockchain, there are advantages to using the same cryptographic system as the underlying blockchain. These advantages are:

[0186] - The encryption security level is the same as that of the underlying system on which the data is stored.

[0187] The software architecture required to store encrypted data will have a smaller codebase.

[0188] - Key management in the wallet can be used for both transactions and encryption / decryption.

[0189] Because the same key can be used for both encryption and payments, it is more efficient, thus requiring fewer keys. This also reduces storage space.

[0190] The ability to exchange / purchase decrypted data may require fewer communication channels.

[0191] - Because the keys used for encryption and transactions are of the same data structure, security is improved, thus mitigating targeted attacks against specific key types.

[0192] For illustrative purposes, this paper describes how the Koblitz algorithm can be used to encrypt data using ECC.

[0193] Koblitz algorithm

[0194] Given an ECC key pair P1 = S1·G, the Koblitz algorithm allows anyone to encrypt a message using the public key P1, such that only someone who knows the corresponding private key S1 can decrypt the message.

[0195] Suppose we want to encrypt the plaintext message 'hello world' using the Koblitz method. This is done character by character. The following is an example of encrypting and decrypting the first character 'h'.

[0196] 1. The character 'h' is mapped to a point on the secp256k1 curve. This can be achieved by mapping the plaintext character to an 8-bit number using the ASCII convention. The point on the curve is then calculated by multiplying the base point G by that number. In this example, 'h' maps to 104 in ASCII, and the elliptic curve point is determined by P. m =104·G is given.

[0197] 2. Then use public key P1 to point P m Encryption is performed. This is done by selecting a random temporary key k0 and calculating point pairs C. m ={k0·G,Q} (where Q:=P) m This can be achieved by using +k0·P1), and then the point pair can be broadcast.

[0198] 3. The owner of private key S1 can compute P m =Q-S1·k0·G to decrypt the original point. Then, they can recover the original ASCII number through trial and error or with the help of a lookup table to determine which number x corresponds to P. m =x·G.

[0199] Using blockchain to purchase licenses

[0200] Storing data on the blockchain has a clear advantage over having payment mechanisms built into the system. Payments can be used for purchases.

[0201] - Decrypt the data to view / use

[0202] - Permission to insert data at a specific address

[0203] In both cases, the buyer uses a token to purchase a secret that grants them permission to do something. This secret can be a hash preimage or a private key.

[0204] An efficient and secure way to conduct such purchases is to use atomic swaps. This keeps secure communication channels to a minimum and ensures that payment is made to the seller and the buyer is kept confidential, or that no event occurs.

[0205] Purchasing licenses using access tokens is also convenient. These are secret values ​​(usually hash preimages) owned by the buyer that they can use to make purchases. Buyers can purchase such access tokens in bulk in advance and then activate them when they actually want to use the licenses.

[0206] Now refer to Figure 4 and Figure 5 Describe how to perform an atomic exchange.

[0207] Atomic swaps using hash puzzles or private key puzzles

[0208] Suppose Alice is the owner of a secret. This secret could be a hash preimage of a known hash digest, or a private key with a known public key. Suppose Bob wants to use a token to buy the secret from Alice. Describe a mechanism called an atomic swap that enables this transaction. This is atomic in the sense that Alice obtains the token and reveals the secret to Bob, or neither event occurs at all.

[0209] The method is as follows:

[0210] Alice has the 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 .

[0211] Alice possesses the secret of either the preimage X of the known hash digest H(X) or the private key S1 of the known public key P1 = S1·G.

[0212] They agreed that Alice would sell the secret to Bob for the price of tokens.

[0213] Before this, Bob must set up a transaction to send the temporary key k0 to Alice outside the block, so that Alice can calculate the component r0 of the digital signature.

[0214] For reference Figure 4 ,

[0215] 1. Bob will transfer the tokens locked via the following exchange script R (illustratively written):

[0216] For hash preimages:

[0217] R=[Hash Puzzle H(X)][CheckSig P A ]

[0218] This forces the preimage X to be exposed in the input of the exchange script.

[0219] Regarding the private key:

[0220] R=[Private Key Puzzle P1,r0][CheckSig P A ]

[0221] This forces the private key S1 to be computed from the input of the exchange script. In this case, Bob and Alice must agree on the temporary key k0 used to construct r0, where (r0, R y )=k0·G.

[0222] 2. Because Alice knows her secret (X or S1), she can use... Figure 5 The transaction shown spends her funds on the blockchain. This allows Bob to verify her secret.

[0223] As an optional security feature, Alice and Bob can use their public key P A ,P B To establish a shared secret S known only to the two of them. This can be achieved in the manner outlined in International Patent Publication No. WO 2017 / 145016. In this case, S can be added to the preimage X in the hash puzzle so that X is not publicly revealed on the blockchain. Similarly, in the private key puzzle, S can be used as a temporary key k0 to ensure that only Alice or Bob can compute the private key.

[0224] If Alice decides not to spend her funds, a time-locked refund can be introduced into the program to prevent Bob's funds from being locked by Alice.

[0225] Purchase with tokens

[0226] Suppose a situation similar to the one described above exists, but Bob wants to redeem a pre-purchased access token in exchange for a secret.

[0227] Alice and Bob must follow a procedure similar to that described in previous chapters, but using a similar sequence of atomic exchanges. The process has two phases: token issuance and token redemption.

[0228] Phase 1: Token Issuance

[0229] The token issuance phase is essentially Bob purchasing a token in a single transaction. For example, consider the following scenario: Alice has 10 different secrets X1, X2, ..., X... 10 Bob wants to purchase 10 tokens T1, T2, ..., T in a single transaction, each granting him access to the corresponding secret. 10 .

[0230] First, Bob generates a set of 10 tokens from a secret seed value known only to him. These tokens are created by hashing the seed in order to form a hash chain, where each token is computed as:

[0231] T i =H 10-i (Y) for i∈{1,2,…,10}.

[0232] Alice and Bob now each possess 10 secret values, which can be revealed in a hash puzzle for use, such as exchanging tokens. However, in order to issue these tokens, they must also each generate a secret initialization value I. Alice and I Bob These values ​​are given below:

[0233]

[0234] I Bob =H 10 (Y).

[0235] It should be noted that Alice's initializer is simply a random integer without specific meaning, but Bob's initializer should be the hash of his first token, T1 = H. 9 (Y). Extending the token chain to the initial value in this way allows for token issuance and also limits tokens to be used for subsequent redemptions later. Figure 6 The table shows all the secret values ​​stored by each participant.

[0236] Alice and Bob can now agree to purchase 10 tokens for 10 units each. These tokens can be purchased in several ways; here, we'll use atomic swaps. Atomic swaps are broadcast separately by Alice and Bob. Figure 7 and Figure 8 The transaction shown in the figure begins with the output of both transactions, where the output of each transaction requires the solution to two hash puzzles and a valid signature.

[0237] Once two transactions occur in the blockchain, Alice and Bob can share their shared initialization value I. Alice and I Bob And complete the atomic exchange of token issuance.

[0238] Due to this atomic swap, Alice receives payment for 10 tokens and the two initialization values ​​are revealed. It should be noted that only Bob's secret I is revealed here. Bob =H 10 (Y) is meaningful because it will limit the first hash puzzle to be solved [hash puzzle (T1)], the solution of which is the initial value H. 10 (Y) preimage H 9 (Y).

[0239] Phase 2: Token Exchange

[0240] At some point in the future, Bob wants to redeem his first token, T1=H. 9 (Y) receives its first secret X1, but as mentioned earlier, it has already paid for that secret by purchasing a valid token. The token exchange process will take the form of another atomic swap, where the solution to the locking hash puzzle is token T. i And the corresponding secret X i .

[0241] In order to redeem his token, Bob should broadcast... Figure 9 The transaction shown has its output locked by two hash puzzles. When Alice sees this transaction, she broadcasts it as follows: Figure 10 The example shown is a similar transaction of her own, the output of which is locked using the same two hash puzzles. The two participants can now exchange their secrets T1 and X1 and unlock the outputs of these transactions. Both parties can now exchange the nominal fee x by providing the correct unlocking script that also exposes both secrets. Figure 11 and Figure 12 The transaction with these unlock scripts is shown in the image.

[0242] The completion of this atomic exchange for the tokens reveals Bob's first secret X1 to Alice, reveals Bob's first token T1 to Alice, and, given that the amount x is appropriately large to encourage both parties to spend locked outputs, results in a net zero exchange of funds. 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) = T1 has just been revealed to Alice. This process can be repeated recursively until Bob has used his last token T. 10 =Y until.

[0243] Naming and Addressing

[0244] Nodes and edge structures

[0245] The methods for inserting data into the blockchain by providing data within transactions have already been explained. The protocol for logically structuring these transactions is now presented, allowing for node addressing, permissioning, and content versioning control. The structure of this distributed peer-to-peer metanet is similar to the existing Internet.

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

[0247] The goal of the structure described here is:

[0248] (i) Linking related content across different transactions to enable data search, identification, and access.

[0249] (ii) Allows the use of human-readable keyword search to identify content, thereby improving search speed, accuracy, and efficiency.

[0250] (iii) Building and simulating server-like structures in the blockchain

[0251] Our approach is to structure the data associated with the meta-network as a directed graph. The nodes and edges of this graph correspond to:

[0252] Node - A transaction associated with the MetaNet protocol. Nodes store content. (The terms "content" and "data" are used interchangeably within this document.)

[0253] The node is accessible through the means of...<Metanet Flag> Created using the previous OP_RETURN. Each node is assigned a public key P. node The combination of the public key and the transaction ID uniquely specifies the node's index ID. node :=H(P node ||TxID node ).

[0254] The hash function used should conform to the underlying blockchain protocol that this invention will use with, for example, SHA-256 or RIPEMD-160.

[0255] Edge - the relationship between child nodes and parent nodes.

[0256] Edge in signature Sig P parent Edges are created when they appear as inputs to a meta-network transaction, so only the parent node can grant permission to create edges. Each node can have at most one parent node, and a parent node can have any number of children. In the language of graph theory, each node has an indegree of at most 1, and each node has an outdegree that is arbitrary.

[0257] It should be noted that the edge is a meta-network protocol aspect and it is not itself a transaction associated with the underlying blockchain.

[0258] A valid metanode (with a parent) is given by a transaction of the following form:

[0259]

[0260] This transaction contains all the information needed to specify the following nodes and their parent indices:

[0261] ID node =H(P node ||TxID node ),

[0262] ID parent =H(P parent ||TxID parent ).

[0263] Furthermore, because the parent node's signature is required, only the parent node can create edges extending to the child node. If <TxID parent If a field does not exist or does not point to a valid metanet transaction, the node is an orphan. This node has no higher-level nodes that can reach it.

[0264] Additional attributes can be added to each node. These attributes can include flags, names, and keywords. These attributes will be discussed later in this document.

[0265] As shown, the index of a node (transaction) can be divided into:

[0266] a) Public key P node We interpret it as the address of the node.

[0267] b) Transaction IDTxID node We interpret this as the version of the node.

[0268] This structuring produces two advantageous features:

[0269] 1. Version Control - If two nodes have the same public key, we interpret the node with the transaction ID as the latest version of that node, which has the maximum proof-of-work. If the nodes are in different blocks, this can be checked by the block height. For transactions in the same block, this is determined by the Topological Transaction Ordering Rule (TTOR).

[0270] 2. Permission - only if public key P node The owner of a node can only create its children when they sign the transaction input during the creation of the child node. Therefore, P node It represents not only the address of a node, but also the permission to create child nodes. This is intentionally similar to a standard blockchain transaction—the public key is not only an address, but also the permission associated with that address.

[0271] It should be noted that because the parent node's signature appears in the UXTO unlock script, it is verified through the standard network node verification process when the network accepts the transaction. This means that permission to create child nodes is verified by the blockchain network itself.

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

[0273] The node and edge structure allows the meta-network to be visualized as a graph, such as Figure 13 As shown.

[0274] Domains, naming, and location content in the metanet

[0275] The hierarchical structure of the meta-network graph allows for rich, domain-like structures. We interpret orphan nodes as top-level domains (TLDs), their children as subdomains, their grandchildren as sub-subdomains, and so on, and nodes without children as endpoints. See also Figure 13 .

[0276] Domain name is interpreted as ID node Each top-level domain in a metanet can be viewed as a tree, where the root is an orphan node and the leaves are nodes with no children. The metanet itself is a global set of trees that form a graph.

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

[0278] As mentioned earlier, the Internet uses the Domain Name System (DNS) to associate human-readable names with Internet Protocol (IP) addresses. DNS is decentralized in a sense, although in practice it is controlled by a small number of key players (e.g., governments and large corporations). Depending on your DNS provider, the same name can lead you to different addresses. This problem is inherent when mapping short, human-readable names to computer-generated numbers.

[0279] We assume the existence of a decentralized index ID that maps human-readable top-level domains to root nodes. root An equivalent distributed system. In other words, there exists a 1-1 function κ that maps human-readable names to the root node index of the meta-network, for example:

[0280] κ(′bobsblog′)=ID bobsblog (=H(P bobsblog ||TxID bobsblog ))

[0281] The input to the left is human-readable words, while the output to the right is a hash digest, which will typically be a 256-bit data structure. Note that P... bobsblog and TxID bobsblog This is typically not human-readable either. In the standard IP protocol, this would be a mapping from www.bobsblog.com to the IP address of the corresponding domain within the network.

[0282] The mapping κ should be interpreted as a measure to ensure backward compatibility between the metanet and the Internet when replicating the human readability of domain names published by DNS, but the naming and addressing schemes that provide the structure of the metanet do not explicitly depend on the mapping.

[0283] Possible existing forms of mapping functions include the DNSLink system adopted by the InterPlanetary File System (IPFS) or the OpenNIC service (https: / / www.openic.org). This mapping can be stored as part of the DNS in existing TXT records. This is similar to DNSLink in IPFS; see https: / / docs.ipfs.io / guides / concepts / dnslink / . However, broadly speaking, these sacrifice some elements of decentralization to provide a 1-1 mapping; see https: / / hackernoon.com / ten-terrible-attempts-to-make-the-inter-planetary-file-system-human-friendly-e4e95df0c6fa

[0284] The public key used as the address of a meta-network node is not a human-readable object. This can make human users' searching, referencing, and input activities error-prone and slow. However, it is possible to create human-readable public key addresses that include a plaintext prefix that can be directly deciphered by the user.

[0285] The difficulty of creating such an address depends on the character length of the required prefix. This means that a human-recognizable address can be used as a node address, which depends solely on the creation effort of the owner rather than a central publication. For a given prefix, many different human-recognizable addresses exist due to the remaining characters in the suffix, so many node addresses can share a common prefix while still remaining unique.

[0286] An example of a human-recognizable address with the required prefix is:

[0287] P bobsblog :bobsblogHtKNngkdXEeobR76b53LETtpyT

[0288] Prefix: bobsblog

[0289] Suffix: HtKNngkdXEeobR76b53LETtpyT

[0290] The human-readable address above can be used for sensing and checking from the name 'bobsblog' to the node index ID. bobsblog The mapping assists meta-network nodes in determining the searchability of addresses. It should be noted that the prefix is ​​not unique here, but the entire address itself is a unique entity.

[0291] Selected address P vanity Together with TxID, they form an ID. node The combination is also beneficial because it means there is no central publisher for domain names (TxIDs are generated by decentralized proof-of-work), and names are recoverable from the blockchain itself. Advantageously, there are no longer any points of failure existing within the Internet DNS.

[0292] Since the metadomain already provides a permission system (public key), there is no need to issue credentials to prove ownership. The use of blockchain for this purpose has been explored. However, according to the present invention, a separate blockchain is not necessary for this functionality, as everything can be accomplished within a single blockchain.

[0293] Compared to existing technologies, this significantly reduces the amount of resources (hardware, processing resources, and energy) required for this invention. It also provides a completely different architecture in terms of the arrangement of device and system components.

[0294] The advantage of this naming system is that users can identify top-level domains in the metanet using memorable words (e.g., company names) rather than hash digests. This also makes searching domains faster, as searching by keywords is quicker than searching by hash digests. It also reduces input errors, thus providing improved search tools for data stored on the blockchain.

[0295] Given the mapping from domain names to node indexes, we can establish resource locators similar to Uniform Resource Locators (URLs) on the Internet. We call this the MetaURL (MURL) and it takes the following form.

[0296] MURL='mnp:'+' / / domain name'+' / path'+' / file'.

[0297] Each component of a URL—protocol, domain name, path, and file—has been mapped to the structure of MURL, making the object more intuitive for users and enabling its integration with the existing structure of the Internet.

[0298] This assumes that each node has a name associated with its public key (address), which is unique at each level within 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 will have the same public key, and therefore the latest version will be used.

[0299] The table below provides an analogy between the MetaNet protocol and the Internet protocol:

[0300]

[0301] Table: Summary of Analogies between Internet Protocols and MetaNet Protocols

[0302] Search Metanet

[0303] We have defined the meta-graph structure of the exemplary embodiment such that each node has a unique index and can have a name to which it belongs. This allows for content location using MURL. To also enable fast search functionality, we allow additional keywords to be assigned to nodes.

[0304] The fixed attributes of a node are its index and the index of its parent node, while the optional attributes are its name and keyword.

[0305] Node attributes

[0306]

[0307] In one example, a practical approach for searching metanets could be to first use a block explorer to trawl the blockchain, identifying all transactions by their metanet identifiers, checking if they are valid metanet nodes, and if so, recording their index and keywords in a database or other storage resource. This database can then be used to efficiently search for nodes using the desired keywords. Once the index of a node is found using the desired keywords, its contents can be retrieved from the block explorer and viewed.

[0308] For example, consider Figure 14 Branch P1, where P0, P1, and P are public keys. 1,1 The nodes represent the homepage, topic page, and subtopic page, respectively. These nodes are given the names 'bobsblog', 'summer', and 'caribbean', and their attributes are as follows:

[0309] Homepage node P0

[0310]

[0311]

[0312] Topic page node P1

[0313]

[0314] Subtopic node P 1,1

[0315]

[0316] In this example, leaf node P 1,1,1 P 1,1,2 and P 1,1,3 They are given the names 'beaches', 'nightlife', and 'food' respectively, and are used to store individual blog posts. The complete domain structure is shown in the diagram overleaf at the end of the page, including the MURL search path associated with each node in the tree.

[0317] It should be noted that the MetaNet can also be incorporated into Content Addressable Networks (CAN) by storing the hash of the content stored by node transactions as an additional attribute. This means that MetaNet nodes can also be indexed and searched by content hash.

[0318] The naming and addressing methods described above offer numerous technical advantages over existing technologies, including:

[0319] 1. Public Key Addresses - The system uses the same public-private key pairs as the blockchain to assign node addresses. This means the same set of keys is used for both token management and content data permission. This provides an efficient and secure solution.

[0320] 2. Decentralized Domain - Domain publication is achieved through the inclusion of TxIDs, which can only be generated by proof-of-work. node Furthermore, it is completely decentralized. Domain names can also be incorporated into human-readable public keys to achieve a fair distribution of the required domain public keys. Again, this scheme offers enhanced efficiency and security.

[0321] 3. Graph Structure - The naming and addressing architecture specifies a graph that can be constructed from a subset of blockchain data, including meta-network nodes. This design uses an ordered structure to map the complexities of the Internet to the blockchain, allowing the blockchain to fully replicate its functionality and scalability while maintaining security.

[0322] Blockchain search engine

[0323] Search Engines – Existing Technology

[0324] Existing search engines (SEs) rely on powerful web crawlers to locate, index, and rank web content based on user queries. (The same basic principle can be extended to third-party blockchain SEs that crawl the meta-web).

[0325] SE identifies relevant HTML meta tags and content by searching for keywords in the query. The crawling results are then indexed, including analyzing and cataloging any embedded image / video / media files. Finally, taking into account the user's location, language, and device, the most relevant results in the index are programmatically ranked.

[0326] A typical SE should have the following functionalities:

[0327] 1. Web Crawling - Identifying Internet data and crawling it using relevant metadata such as domain names, linked pages, and related keywords. Discovering new Internet content from existing content and crawling any related information.

[0328] 2. Indexing - Analyzing and cataloging content data. This information is stored in the database.

[0329] 3. Services and ratings - Content indexes are rated in order of relevance to user queries.

[0330] Block Detector

[0331] The closest blockchain analogue to an internet search engine (SE) is a blockchain explorer, sometimes called a 'block explorer' or 'blockchain browser'. A blockchain explorer is a web application that enables user-friendly queries on the blockchain at a high level and functions similarly to a web browser, but connects to the blockchain instead of the internet.

[0332] In most cases, these detectors allow searching through blocks (indexed by the hash of the block header), transactions (indexed by TxID), addresses, and unspent transaction outputs (UTXOs) as input. Many detectors also provide their own application programming interfaces (APIs) for retrieving raw transaction and block data. See https: / / blockexplorer.com / api-ref.

[0333] While block detectors vary in capability, they are generally useful for compiling transactions in a user-friendly, extractable format and displaying their basic information—such as the transaction's currency value, coin confirmations and history, and addresses. Many detectors also allow viewing individual inputs and lock scripts of transactions, although there is inconsistency between how these detectors and more advanced sites (e.g., Blockchair https: / / blockchair.com / ) choose to present this information.

[0334] Recently, many extensions have emerged to the basic blockchain detectors used to run web applications based on blockchain data. These applications (e.g., Memo.cash https: / / memo.cash / protocol and Matter https: / / www.mttr.app / home) catalog and organize blockchain transactions containing specific protocol identifiers, and display the data encoded within those specific transactions, much like a block detector.

[0335] However, there are two important problems with using blockchain detectors, and the embodiments of the present invention solve these problems:

[0336] 1. Universality - There is currently no industry standard for browsing content data stored in transactions. Content data refers to any data that is not related to the protocols used to create and guarantee the underlying blockchain.

[0337] 2. Keyword Search – The content data stored in transactions needs to be retrieved using human-readable keywords. This is typically not a feature of current block detectors, as they are designed to query protocol-based properties of transactions (e.g., block height, TxID, and address), not keywords as search input. (However, some detectors, such as Blockchair, can search for words if they are directly included in the transaction's script.)

[0338] Importantly, as stated above, the robust naming and addressing structure of this invention facilitates and enables the construction of more complex blockchain detectors compared to those known in the art.

[0339] The proposed meta-web search engine

[0340] Browser wallet applications communicate with third-party search engines to discover node identities (IDs). node It should be envisioned that this third party could provide a powerful and versatile service capable of replicating existing Internet search engines.

[0341] The MetaNet search engine, maintained by a third party, is a database of all MetaNet transactions mined from the blockchain and identifiable by MetaNet protocol identifiers. This database can be accessed through IDs... node All meta-network nodes are indexed by a range of node names, keywords, TxIDs, and block heights.

[0342] Services such as BitDB (https: / / bitdb.network / ) already exist, continuously synchronizing with the blockchain and maintaining transaction data in a standard database format. Browser wallets delegate the responsibility of crawling, indexing, servicing, and rating metanetwork transactions to this third party, and connect to its service when locating content stored on the metanetwork graph.

[0343] Efficiency can be achieved by using a database dedicated solely to metanet data. Unlike BitDB, this database will not store data associated with all transactions, but only that which contains metanet identifiers. Some databases, such as non-relational databases like MongoDB, may be more efficient at storing the graph structure of the metanet. This will allow for faster queries, lower storage requirements, and more efficient association of related content within the metanet domain.

[0344] Figure 15 This demonstrates how a browser wallet interacts with a third-party search engine when a user searches for content within the meta-network infrastructure. Importantly, it should be noted that, compared to the Internet, no routing is required, thus this invention offers significant advantages in terms of efficiency, speed, processing power, and required resources.

[0345] The process is as follows:

[0346] 1. The end user enters keywords in the browser's wallet search bar.

[0347] 2. The browser wallet sends the keyword query to the third-party SE.

[0348] 3. SE checks its database for keywords and returns the IDs of any meta-network nodes containing relevant content. node Third parties can also return additional indexes on each node to the user, as well as provide suggestions on related content.

[0349] 4. Browser wallets use node identifiers and their associated domain names to construct MURLs.

[0350] 5. The browser wallet requests content belonging to a specified node from any network peer that has a full copy of the blockchain.

[0351] 6. The network peer provides the requested content to the browser wallet. Because the peer has a copy of the blockchain, it must also have a copy of the content, therefore it only makes one request and never forwards the request to other network peers.

[0352] It is important to emphasize that the third-party SE is only responsible for indexing and maintaining the attribute records of the meta-network nodes, while the original content data stored on the nodes is stored by network peers with full copies of the blockchain (e.g., full copy peers, archives).

[0353] Content Display – Meta Browser

[0354] Browser wallet applications simulate the same front-end capabilities that any typical web browser should provide. These capabilities include, but are not limited to:

[0355] 1. Search - Provides access to search engines (SEs) to locate content.

[0356] 2. Retrieval - Communicating with the server to facilitate the delivery of content using known protocols (e.g., Hypertext Transfer Protocol (HTTP)).

[0357] 3. Decipher - Parse the raw code (e.g., in JavaScript) and execute it.

[0358] 4. Rendering - Efficiently display the parsed content for end users to view.

[0359] 5. User Interface (UI) - Provides users with an intuitive interface for interacting with content, including action buttons and mechanisms for user input.

[0360] 6. Storage - Local temporary storage capacity for caching Internet content, cookies, etc., to improve repeated access to content.

[0361] In some embodiments, the software component of a browser wallet application that acts as a web browser is able to perform the above functions on meta-content embedded in the blockchain, which is searchable (using SE) and retrievable (from peers) using its attributes.

[0362] Reassembly, decompression and decryption

[0363] According to certain embodiments of the present invention, the web browser software component of a browser wallet application is capable of handling all operations that need to be performed on a given metanet content. Generally, there are many such operations that need to be performed, but we assume that at least the following operations are performed by the application using metanet protocols and infrastructure.

[0364] Reassembly - When metanet content needs to be segmented and inserted into multiple individual node transactions, the application will request content from all relevant nodes and reconstruct the original content. The ordering and structure of the fragmented content can be encoded using additional flags in each node's attributes.

[0365] Decompression - If the content data is stored on the blockchain in compressed form, a flag should be included to indicate to the browser wallet which standard compression scheme has been used. The application will decompress the content based on this flag.

[0366] Decryption - When content is encrypted, a flag should be used to indicate the encryption scheme. The application will locate the key from its decryption key wallet (discussed below) and decrypt the content data for use according to the encryption scheme used.

[0367] When performing these operations on content data, flags can be used to indicate to the browser wallet that a given operation needs to be performed. This applies to any other operation, as appropriate.<operation_flag> It can be included as part of the attributes of the node to which the operation is applied.

[0368] Cache

[0369] Caching local files and cookies is a common and important feature of typical web browsers. Browser wallet applications also use local storage in a similar way to optionally save IDs related to content of interest. node And records of other node attributes. This allows for more efficient finding and retrieval of content from frequently accessed meta nodes.

[0370] MetaNet addresses the inherent problem of caching Internet data, which is mutable and can be altered or deleted by web browsing software depending on the provider. When caching MetaNet data, users can always easily verify that the data is in the same state as when it was originally included on the blockchain as an immutable record.

[0371] Hierarchical Deterministic Key Management

[0372] The deterministic key Dk is a private key initialized from a single "seed" key. 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 "chaincode") (see HD Wallet-BIP-32 / BIP-44) to derive the deterministic key. These keys are related to each other and can be fully recovered from the seed key. The seed also allows for easy importing / exporting of wallets between different wallet implementations if the user wishes to use an external wallet with a meta-web browser wallet, providing additional flexibility.

[0373] Hierarchical deterministic (HD) wallets are a well-known method of deriving deterministic keys. In an HD wallet, a parent key generates a series of child keys, which in turn generate a series of grandchild keys, and so on. This tree-like structure is a powerful mechanism for managing multiple keys.

[0374] In a preferred embodiment, the HD wallet can be merged into... Figure 15 In the meta-network architecture shown.

[0375] The advantages of using an HD wallet include:

[0376] 1. The structure can use different branches of subkeys to express additional organizational meanings for different purposes. For example, users can dedicate different branches (and their corresponding subkeys) to different types of data.

[0377] 2. Security: Users can create a set of public keys without a corresponding private key, enabling the HD wallet to have receive-only functionality and making it suitable for use on insecure servers. Furthermore, the risk of exposure is low because fewer secrets need to be stored.

[0378] 3. Recovery If the key is lost / damaged, it can be recovered from the seed key.

[0379] Bypass network server

[0380] This invention provides a novel mechanism for browsers (clients) and web servers to communicate and exchange information via a distributed peer-to-peer internet connection, bypassing Domain Name System (DNS) servers and typical network routing procedures. See http: / / www.theshulers.com / whitepapers / internet_whitepaper / . This invention also provides a new network architecture that includes peers maintaining a full copy of the blockchain, from which content can be delivered to browser wallet applications.

[0381] Local full-copy peer-to-peer

[0382] Consider a system of local peers in each geographic region (e.g., postal district, town, city). We assume that within this local area network, at least one peer maintains a full copy of the blockchain; we call this peer the Local Full Copy Peer (LFCP). For our purposes, the LFCP only needs to store blockchain transactions including the metanet identifier, but is not limited to this.

[0383] By default, all users send a 'get' request to the LFCP. Since the peers maintain a complete and up-to-date copy of the entire blockchain, all requests can be satisfied, as any queried node ID will be available to the LFCP. It should be noted that a meta-network search engine can also act as the LFCP if the SE is powerful and large enough to store meta-network content and perform the main functions of a typical SE.

[0384] In the simplest case, each LFCP will have the same storage and disk space overhead, as they will all need to be able to store the entire blockchain (approximately 200GB on writes). The difference between each LFCP is that it should scale its capacity to respond to local requests from MetaNet users. Therefore, assuming that every MetaNet user in the world queries its nearest LFCP, each LCFP should strive to scale its operational capacity to meet its local requirements. Densely populated areas such as cities will require LFCP operations involving many cluster servers, while sparsely populated areas such as towns will require fewer LCFP operations.

[0385] It's important to note that disk space requirements are general, while CPU requirements per LFCP adapt to local area network needs. An example of an adaptive network is Freenet—see https: / / blockstack.org / papers / .

[0386] One advantage of such a system is its ability to retrieve data with a given ID. node When accessing related content, users only need a single (local) connection to their LFCP. LFCP does not need to forward requests to other peers because it guarantees that it can provide the required content.

[0387] MetaNet offers many advantages over the Internet—such as decentralization and deduplication—similar to other peer-to-peer (P2P) file-sharing services like IFPS. However, MetaNet improves upon these existing P2P models by ensuring immutability and, crucially, by eliminating the need to flood the network with requests for a given content.

[0388] The meta-network infrastructure is also robust to the failure of any LFCP by employing these peer networks. This means that if an LFCP is deactivated, the end user simply defaults to using their next nearest LFCP. This can be even more efficient if the LFCPs communicate with each other to indicate which nearby peers are below or above capacity for requests at any given time. This allows users to send their requests to the most appropriate peer and establish a dynamic balance of request allocation among nearby LFCPs.

[0389] Global full-copy peer-to-peer

[0390] Now consider the scenario where general disk space requirements become too large for smaller peers, a situation that occurs as the meta-network portion of the blockchain expands and grows with adoption.

[0391] In this scenario, smaller LFCPs should use their disk space capacity to store meta-network node transactions based on a popularity system (existing technologies exist for rating content by request volume and quality). This means that LFCPs now need to adjust both their CPU (for request processing capacity) and their storage allocation (for content serving capacity) to suit their local geographic needs in terms of both content volume and quality.

[0392] To address the limitation that LFCP cannot currently store all metanetwork transaction content, the concept of Global Full Replica Peers (GFCP) can be utilized. GFCP is a full replica peer with the following properties:

[0393] 1. GFCP increases its disk space capacity in order to always maintain a full copy of the blockchain.

[0394] 2. GFCP has significantly more CPU resources, allowing it to handle a marked number of requests compared to LFCP. In the event that many LFCP instances become unavailable, the global full-replica peers should be able to handle a sudden increase in demand.

[0395] GFCP has two main functions. First, it acts as fault protection for user requests for metanet content when requests overflow from LFCP. Second, GFCP acts as an archive peer to store all historically mined metanet content, ensuring that content from any metanet node is still accessible even if many LFCPs omit some content from their local storage provisioning.

[0396] Global database (data bank)

[0397] The concept of GFCP is powerful and illustrates how the overall architecture of the meta-network can provide solutions to existing problems; creating a global database that covers everything.

[0398] Previously, it was impossible to securely construct a universal and globally accessible database because it required a central authority to maintain it. This central authority injected points of failure and points of trust into the system. Crucially, if we rely on an organization to store and maintain all internet data, we need to trust that organization is operating correctly and legitimately without corrupting the information.

[0399] By leveraging the meta-network infrastructure, the issues of trust and centralization are effectively removed from the concept of a global data center. Now, GFCPs can be created that rely solely on them to provide the necessary disk space for storage without verifying or authenticating the information to be stored.

[0400] Through the meta-network, the process of verifying stored content is performed by network nodes, thus the general global database can be trusted because it cannot corrupt blockchain information. GFCP does not need to be trusted; it only needs to provide storage.

[0401] The fact that all GFCPs can store the same information that is always verifiable and provable for the blockchain itself means that information can be replicated among many such GFCPs.

[0402] This means that the problem of having a single point of failure is also solved by having many global databases exist in parallel and provably store the same information.

[0403] Figure 16 A system with two LFCPs and one GFCP is shown, and it is illustrated how each peer can support another peer in a network where damage to each peer is robust.

[0404] The various aspects of the present invention, which can be implemented in the above-described browser wallet application embodiments, provide numerous distinguishing features and advantages over the prior art, including but not limited to:

[0405] 1. Deterministic Keys - Perform hierarchical deterministic key management for both tokens and metanet addresses within the same wallet component of the application. This allows for key organization by reducing storage requirements and enabling multiple functions for key recovery.

[0406] 2. Payment Mechanism - This application allows consumers to pay merchants directly without referring to another application or third-party payment service that will be verified and trusted as per usual practice. This allows for the purchase and delivery of digital content via the same blockchain platform.

[0407] 3. Bypassing the Network Server – This application facilitates bypassing conventional network servers that would routinely handle large volumes of traffic, requests, and routing. This is because the application only needs to request content from a single LFCP, ensuring that requests are not forwarded to other LFCPs to serve users. This reduces overall traffic and the completion time of each request.

[0408] 4. Timed Access – This application facilitates timed access to content by synchronizing with and using the blockchain to enforce access permissions based on the current state of the content. This eliminates the need for third-party services that monitor user privileges over time, while protecting the rights of the original owner.

[0409] Use Case - Decentralized App Store (Swapp Store)

[0410] The first use case of the meta-network architecture presented here (for illustrative purposes only) is decentralized payment and distribution for applications (apps).

[0411] Consider the following scenario: App developer Alice and consumer Bob want to transact with each other. The transaction will take the form of an atomic swap, where a secret key granting Bob access to application data is exchanged for tokens. The encrypted application data has been publicly disclosed as part of the metanet node transaction.

[0412] Applications exchanged at the atomic level are called Swapps. Third-party platforms (Swapp stores) can be used to catalog and announce applications existing on the metanet, but the payment and transfer of access keys to users (e.g., Bob) does not require any third party and can be done directly between the merchant and the consumer.

[0413] The following sections detail the process of buying and selling Swapp, from Alice's app creation to Bob's deployment. Throughout the process, Alice and Bob will interact with the metanet using their respective browser wallets.

[0414] release

[0415] 1. Alice wrote the application. The data that makes up the application is... <app>The content it represents. She also used the secret key S. k Encrypt it as<e(App)> .

[0416] 2. Alice creates a node transaction ID. AliceApp To set up her first metadomain (tree). She generates 1AliceAppHtKNngkdXEeobR76b53LETtpy(P) which will be used as the node address. AliceApp ).

[0417] 3. Then, Alice creates the children of the first node to form a tree that corresponds to the meta-network library of her application. Alice's tree domain is... Figure 17 As shown in the image.

[0418] One of the leaf nodes in this tree corresponds to the node with an index ID. App Her application <app>The node. In this node, Alice will encrypt the application data.<e(App)> Insert it into the node's input script (scriptSig). Use the secret key s k Use the Koblitz method to encrypt app data.

[0419] The node's transaction is shown below.

[0420]

[0421] 4. Alice's Public Broadcast ID AliceApp P AliceApp And the domain name 'AliceApp'. This can be achieved through social media, internet websites, or by using third-party meta-websites.

[0422] Buy

[0423] 1. Bob wanted to download a puzzle game and saw Alice's app listed on the Metanet website (Swapp store) that he checked on his browser wallet.

[0424] 2. Bob then communicates with Alice using information from the website and sets up an atomic swap. The swap is designed so that Bob will pay Alice an agreed-upon price, and Alice will reveal the secret key. k Or none of these events will occur.

[0425] 3. The atomic swap is complete, and Bob's browser wallet will transfer the secret key s k It is stored in its access key / token wallet.

[0426] deploy

[0427] Bob now possesses keys that will allow him to decrypt application data previously released by Alice. k To download and deploy the app, Bob did the following.

[0428] 1. Bob used the MetaNet search engine (SE) to find data related to the encrypted app.<e(App)> The associated MURL. It uses the keywords 'AliceApp' and 'App' as input in the browser wallet's search bar. The third-party SE parses the query and returns the following MURL:

[0429] mnp: / / aliceapp / games / puzzle / app

[0430] This locator corresponds to a unique meta-network node ID. App This node includes encrypted app data in its input script.

[0431] 2. Bob's browser wallet receives the MURL and then sends a request to the nearest appropriate LFCP. The peer provides Bob with the requested data.<e(App)> .

[0432] 3. Browser wallet based on ID App This involves processing data using attributes. This includes using secret keys. k Decrypt application data and process <app>.

[0433] 4. Bob will apply <app>He downloaded it to his computer from his browser. Now, Bob can deploy the application locally without having to purchase access permissions again.

[0434] Figure 18 The entire process outlined in the illustrative use case above is shown. The flowchart shows two action branches: Alice's branch (starting on the left) and Bob's branch (starting on the right). The branch corresponding to Alice shows the initial release phase, and the branch corresponding to Bob shows the purchase phase via atomic swap settings.

[0435] On Bob's branch, he broadcast the following transaction TxID Bob As part of the atomic exchange setup phase:

[0436]

[0437] In this transaction, the output is locked via a private key puzzle, which requires the secret decryption key s. k Reveal it to Bob so Alice can spend it.

[0438] In the diagram, Alice and Bob's branches converge at the point where Alice successfully completes the atomic swap transaction. This occurs when Alice broadcasts the transaction TxID. Alice Realize in time:

[0439]

[0440] Once the transaction is broadcast, Alice and Bob's actions diverge again. Alice receives a payment of x tokens, while Bob receives the secret decryption key s. k Furthermore, it can retrieve and decrypt Alice's applications from the meta-network.

[0441] Turn now Figure 19 This document provides an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure. In various embodiments, the computing device 2600 can be used to implement any system shown and described above. For example, the computing device 2600 can be configured to function as a data server, network server, portable computing device, personal computer, or any electronic computing device. Figure 19 As shown, computing device 2600 may include one or more processors (collectively referred to as 2602) having one or more levels of cache memory and memory controller, the processors being configured to communicate with a storage subsystem 2606 including main memory 2608 and permanent storage device 2610. As shown, main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. Storage subsystem 2606 and cache memory 2602 may be used to store information, such as details associated with transactions and blocks as described in this disclosure. One or more processors 2602 may be used to provide steps or functions of any embodiment described in this disclosure.

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

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

[0444] The network interface subsystem 2616 can provide an interface to other computing devices and networks. The network interface subsystem 2616 can be used as an interface for receiving data from and transferring data to other systems different from the computing device 2600. For example, the network interface subsystem 2616 enables data technicians to connect the device to a network, allowing them to transfer data to and receive data from the device while located at a remote location (e.g., a data center).

[0445] User interface input device 2612 may include one or more user input devices, such as a keyboard; pointing devices such as an integrated mouse, trackball, touchpad, or graphics tablet; a scanner; a barcode scanner; a touchscreen integrated into the display; audio input devices such as a voice identification system or microphone; and other types of input devices. Generally, the term "input device" is used to include all possible types of means and mechanisms for inputting information into computing device 2600.

[0446] 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. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light-emitting diode (LED) display, or a projector, or other display devices. Generally, the term "output device" is used to encompass all possible types of means and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with applications performing the described processes and variations thereof, when such interaction is appropriate.

[0447] Storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data constructs that can provide the functionality of at least one embodiment of the present disclosure. When executed by one or more processors, application programs (programs, code modules, instructions) can provide the functionality of one or more embodiments of the present disclosure and may be stored in storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. Additionally, storage subsystem 2606 may provide a repository for storing data used according to the present disclosure. For example, main memory 2608 and cache memory 2602 may provide volatile storage for programs and data. Persistent storage device 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid-state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM, DVD, or Blu-ray) with associated removable media, and other similar storage media. Such programs and data may include programs for performing steps as described in one or more embodiments of the present disclosure, as well as data associated with transactions and blocks described in the present disclosure.

[0448] The computing device 2600 can be of various types, including portable computer devices, tablet computers, workstations, or any other devices described below. Additionally, the computing device 2600 may include another device that can be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that can be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Therefore, the device can be configured to convert optical signals into electrical signals, which can be transmitted for processing via the ports connecting the device to the computing device 2600. Due to the constantly evolving nature of computers and networks, Figure 19 The description of the computing device 2600 depicted herein is intended only as a particular example to illustrate a preferred embodiment of the device. Figure 19 Many other configurations of the system, with more or fewer components, are possible.

[0449] It should be noted that the above embodiments are illustrative rather than limiting of the invention, and those skilled in the art will be able to devise many alternative embodiments without departing from the scope of the invention as defined by the appended claims. Any reference numerals in parentheses in the claims should not be construed as limiting the claims. The words "comprising" and the like do not exclude the presence of any element or step other than those listed in any claim or the entire specification. In this specification, "comprising" means "include" or "consist of," and "comprising" means "including" or "consisting of." The singular form of an element does not exclude the plural form of such element, and vice versa. The invention can be implemented by hardware comprising several different elements and by a suitably programmed computer. In device claims listing several components, several of these components can be implemented by one and the same hardware. The fact that certain means are recited in dissimilar dependent claims does not imply that combinations of these means cannot be advantageously used.< / app> < / app> < / app> < / app> < / lzw> < / n> < / m> < / s> < / n> < / m> < / s> < / content> < / attributes>

Claims

1. A method of identifying a target transaction on a blockchain, the target transaction being a node in a tree of blockchain transactions, the tree comprising a root transaction, the method comprising the steps of: identifying the target transaction using a search path, the search path comprising: i) a root transaction index for the root transaction, the root transaction index comprising a combination of: a public key associated with the root transaction and an ID associated with the root transaction; and ii) an attribute associated with the target transaction, wherein the attribute is a name, the name is associated with a public key of the target transaction, and the public key of the target transaction represents the target transaction in a level of the tree under the root transaction.

2. The method of claim 1, wherein: the root transaction index comprises: a hash of a function of the public key and the ID.

3. The method of claim 2, wherein, the function is concatenation.

4. The method of claim 1, wherein: the name is a mnemonic associated with the target transaction.

5. The method of any one of claims 1 to 4, wherein: the target transaction comprises at least one further attribute.

6. The method of claim 5, wherein: the at least one further attribute comprises a keyword.

7. The method of any one of claims 1 to 4, wherein: the root transaction and / or the target transaction comprises a protocol flag.

8. The method of claim 7, further comprising the step of: identifying at least one transaction comprising the protocol flag in the blockchain using a block explorer.

9. The method of claim 7, further comprising the step of: identifying at least one transaction comprising the protocol flag in the blockchain and storing data relating to the at least one transaction in an off-blockchain resource.

10. The method of claim 9, wherein: the data relating to the at least one transaction comprises: at least one index associated with a transaction; at least one index associated with another transaction linked to the transaction; and / or a keyword associated with the transaction.

11. The method of any one of claims 1-4, further comprising the step of: accessing a portion of data stored in or referenced from the target transaction.

12. The method of any one of claims 1 to 4, wherein: the public key associated with the root transaction comprises a human-readable prefix.

13. A computer-implemented system comprising: a processor; and a memory comprising executable instructions that, as a result of execution by the processor, cause the system to perform the method of any one of claims 1 to 12.

14. A non-transitory computer-readable storage medium having stored thereon executable instructions that, as a result of being executed by a processor of a computer system, cause the computer system to at least perform the method of any one of claims 1 to 12. ​

Images