Computer-implemented system and method for storing, retrieving, and communicating data via peer-to-peer network

Abstract

A system for searching in a blockchain for data / content stored in one or more blockchain transactions and accessing the data / content is provided. It may be used in conjunction with a protocol for searching for a blockchain. Embodiments of the invention may be arranged to enable a user to search, access, view, write and / or retrieve a portion of data provided in at least one blockchain transaction (Tx), and may further be arranged to identify the at least one transaction (Tx) based on a transaction index (TXindex), the transaction index (TXindex) comprising a transaction ID and a public key associated with the transaction (Tx). The system can comprise a search tool, wherein the search tool is arranged in the block chain search system; or arranged to interface and / or communicate with a blockchain search system. The system may also include at least one cryptocurrency wallet.

Description

[0001] This application is a divisional application of the invention patent application with Chinese application number 2019800782423 (corresponding to PCT international application number PCT / IB2019 / 059803), application date November 14, 2019, and invention name “Computer-implemented system and method for storing, retrieving and communicating data via a peer-to-peer network”. Technical Field

[0002] The present invention generally relates to data improvements for data communication and exchange across electronic networks, particularly peer-to-peer networks such as blockchain networks and the like. It relates to storage, access, retrieval and processing, and in particular to such data-related activities on blockchains. The present invention is particularly suitable for, but not limited to, use when data is processed in a manner similar to that provided by websites and web pages, but using blockchains as the underlying mechanism or platform rather than network servers. Thus, the present invention provides a secure, efficient, cryptographically implemented alternative infrastructure for data processing and transmission. Background Art

[0003] In this document, we use the term "blockchain" to include all forms of electronic, computer-based distributed ledgers. These include consensus-based blockchains and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variations. The term "user" in this article can refer to a person or a processor-based resource.

[0004] A blockchain is a peer-to-peer electronic ledger implemented as a decentralized, distributed computer-based system that consists of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of control of digital assets between participants in a blockchain system and includes at least one input and at least one output. Each block contains a hash of the previous block, so that blocks are linked together to create a permanent, unchangeable record of all transactions that have been written to the blockchain since its inception. Transactions contain small programs called scripts embedded in their inputs and outputs that specify how and by whom the outputs of the transaction can be accessed.

[0005] In order for a transaction to be written to the blockchain, it must be “validated”. Network nodes perform work to ensure that each transaction is valid, and invalid transactions are rejected by the network. The software client installed on the node performs this validation work on unspent transactions (UTXO) by executing their locking script and unlocking script. If the execution of the locking script and unlocking script evaluates to true (TRUE), then the transaction is valid and the transaction is written to the blockchain. Therefore, in order for a transaction to be written to the blockchain, it must: i) be validated by the first node that receives the transaction – if the transaction is validated, then the node relays it to other nodes in the network; ii) the transaction is added to a new block that is constructed; and iii) the transaction is added to the public ledger of past transactions.

[0006] It would be extremely advantageous if blockchain could be used for tasks and processes that are not limited to the cryptocurrency space. Such a solution would be able to leverage the benefits of blockchain (e.g., permanent, tamper-proof records of events, distributed processing, etc.) while being more versatile in its applications.

[0007] One such area of ​​interest is using blockchain to store, share, access and control data between users. Today, this is accomplished via the Internet, where servers host websites and pages that users typically access through search engines to access the data they need.

[0008] However, some observers have begun to envision using blockchain to address certain shortcomings of the Internet, such as the control of large amounts of data and content by centralized parties. 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

[0009] Therefore, it is desirable to provide an arrangement that enables such data to be stored, processed, retrieved, searched and / or shared on a blockchain, advantageously utilizing the distributed, immutable and permanent nature of the blockchain. Such an improved scheme has now been devised.

[0010] Embodiments of the present disclosure provide at least alternative efficient and secure technologies for implementing blockchain solutions and for storing, processing, searching and / or retrieving data on or from them. Embodiments also provide at least an alternative blockchain-implemented technical infrastructure for storing, processing, retrieving, transmitting, searching and / or sharing data between computing nodes. Because the present invention enables blockchain networks to be used in new ways and to provide improved technical results, the present invention provides an improved blockchain-implemented network.

[0011] Embodiments also provide schemes for securely controlling access to digital resources on technologically different and improved computing platforms, including peer-to-peer networks such as blockchains and blockchain protocols.

[0012] The invention is defined in the appended claims.

[0013] According to the present invention, a computer-implemented method / system may be provided. The present invention may be arranged to store, retrieve and / or share data across a peer-to-peer network such as a blockchain. Data may be stored across one or more blockchain transactions. Conventionally or alternatively, the present invention may be referred to as a search system. It may be arranged to operate together with or in conjunction with a blockchain search protocol. As described, the blockchain search protocol may be substantially related to the "metanet" protocol described herein.

[0014] In this document, "sharing" may include providing, sending, communicating, transferring or providing access to a portion of data to a node or user. The term "processing" may be interpreted to mean any activity related to a transaction or its associated data, including generating, transmitting, verifying, accessing, searching, sharing, submitting to a blockchain network and / or identifying.

[0015] The system may be arranged to enable a (human or machine) user to search, access, view, retrieve and / or otherwise process portions of data provided in or referenced by at least one blockchain transaction (Tx). Thus, a blockchain transaction may include portions of data, or references to portions of data. A reference to a portion of data may be a pointer, address or other indicator of a location where the data is stored. A portion of data may be any type of data or digital content, such as a computer executable item, 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 the blockchain or outside the blockchain (i.e., "off-chain").

[0016] Preferably, the system is arranged to be based on a transaction index (TX index ) to identify at least one transaction (T x), the transaction index includes the transaction ID and the transaction (T x ) associated with the public key.

[0017] As will be readily understood by those skilled in the art, each blockchain transaction (T X ) has its own unique identifier (ID) so that it can be identified on the blockchain. Advantageously, the present invention combines this existing ID with a public key associated with and / or provided within a transaction so that the combination forms a unique identifier for the transaction. This facilitates fast and efficient searching of the blockchain.

[0018] Preferably, the system includes a search facility that is disposed within the blockchain search system (i.e., local or internal); or is arranged to interface and / or communicate with the blockchain search system (i.e., external to the search system).

[0019] Preferably, the system comprises at least one cryptocurrency wallet. Preferably, the at least one wallet is arranged to generate, store and / or process hierarchical deterministic keys. The at least one cryptocurrency wallet may be arranged to store at least one cryptographic key and / or at least one token in a trusted execution environment (TEE).

[0020] Preferably, the system comprises: a decompression component arranged to decompress the portion of data if it is compressed; a reassembly component; and / or a decryption component arranged to decrypt the portion of data if it is encrypted. The reassembly component may be arranged to reassemble portions of data retrieved from more than one transaction on the blockchain.

[0021] Preferably, the system comprises at least one presentation component arranged to present the data portion to a user in an audible and / or visual form.

[0022] Preferably, the search system includes a method for inputting or generating a search path to identify at least one transaction (T x ), the search path includes:

[0023] i) Transaction Index (TX) index );as well as

[0024] ii) and transaction (T x ) is associated with at least one attribute.

[0025] Preferably, at least one of the attributes is a mnemonic associated with the transaction; and / or at least one attribute is empty.

[0026] Preferably, the (search) system is arranged to communicate with a cryptocurrency wallet or other resource to facilitate processing, storage and / or generation of cryptographic keys, blockchain transactions and / or digital signatures.

[0027] Preferably, the system is arranged to store a transaction index (TX index ). Preferably, the system is arranged to store respective transaction indexes for more than one transaction.

[0028] Preferably, the system is also arranged to transfer control of the portion of the cryptocurrency to the destination before accessing the data portion. Advantageously, this enables the system to use the blockchain as a storage / retrieval / search mechanism as well as a payment and control mechanism without having to use separate infrastructure for different activities.

[0029] Preferably, the system is also arranged to send a request for the data portion to a peer on the blockchain; and / or receive the data portion from a peer on the blockchain. This enables the creation of an infrastructure that involves using a third party to interact with the blockchain and provide the user with the required data and / or write data to the blockchain on behalf of the user.

[0030] Preferably, a plurality of transactions are provided on the blockchain, each transaction having or providing a portion of the data or referencing a portion of the data.

[0031] Preferably, multiple transactions (T X ) include one, some or all of the inputs, the inputs including:

[0032] The Parent Public Key (PPK) associated with the Logical Parent Transaction (LPTx), identified by a discretionary transaction ID (DTxID); and

[0033] A signature generated using the parent public key (PPK).

[0034] This enables the construction of a logical hierarchy between transactions and their embedded data. As a result, multiple associated or logically linked transactions on the blockchain can be processed efficiently, securely, and quickly. Logically associated transactions may not be stored at consecutive block heights on the blockchain, but they can be easily and securely identified and / or accessed.

[0035] Preferably, the system is also arranged to control access to portions of the data using a time lock mechanism. This provides a greater degree of control over access to data on the blockchain.

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

[0037] Processor; and

[0038] A memory comprising executable instructions that, due to being executed by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0039] 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, causes the computer system to perform at least any embodiment of the method described herein.

[0040] Some embodiments of the method / system of the present invention may include one or more of the features described below, particularly in the section entitled "Browser / Wallet Application".

[0041] Thus, the present disclosure may provide improved solutions for storing, searching, identifying, communicating, and / or accessing data via a blockchain. Embodiments provide improvements for data communication and exchange across electronic networks, particularly across peer-to-peer blockchain networks. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] These and other aspects of the invention will become apparent from and elucidated with 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:

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

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

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

[0046] Figure 4 A blockchain transaction embodying the present invention is shown, the blockchain transaction transmitting a cryptocurrency payment to allow access to data via an atomic swap;

[0047] Figure 5 A blockchain transaction embodying the present invention is shown for redeeming Figure 4 Payment of transactions;

[0048] Figure 6 shows secret values ​​held by participants in a blockchain transaction embodying the present invention, the blockchain transaction issuing tokens to allow access to data via atomic swaps;

[0049] Figure 7 and Figure 8 A blockchain transaction embodying the present invention is shown for issuing a token to allow access to data by means of an atomic swap;

[0050] Fig. 9 and Fig.10 A blockchain transaction embodying the present invention is shown for redeeming Figure 7 and Figure 8 Tokens issued by transactions;

[0051] Fig.11 and Fig.12 shows the method for accessing the Fig. 9 and Fig.10 The transaction is exchanged on a secret blockchain transaction;

[0052] Fig.13 An illustration of a metanet graph structure according to an embodiment of the present invention is provided.

[0053] Fig.14 A diagram of a metanet graph tree for the domain "bobsblog" including a MURL search path is shown in accordance with an embodiment of the present invention.

[0054] Fig.15 A schematic diagram showing an illustrative embodiment of a browser wallet according to one example of the present invention and how its core functionality is split between different components of the application.

[0055] Fig.16 A diagram is provided that illustrates how searching for content is performed within the infrastructure of an embodiment of the present invention.

[0056] Fig.17 An illustrative interaction between a local full replica peer and a global full replica peer is shown in accordance with an embodiment of the present invention.

[0057] Fig.18 A metanet tree (or graph) is shown for use with reference to the illustrative use cases described below.

[0058] Fig.19 A flow chart is shown that illustrates the process embodied by the illustrative use case provided below.

[0059] Fig. 20 is a schematic diagram illustrating a computing environment in which various embodiments may be implemented. DETAILED DESCRIPTION

[0060] In the remainder of this document, the protocol that determines the operation of embodiments of the present invention will be referred to as the "Metanet Protocol".

[0061] According to embodiments of the present invention, the terms "content", "digital content" and "data" may be used interchangeably herein to refer to data stored in, referenced via, or otherwise accessed via blockchain transactions. Data is additional / discretionary data transmitted, communicated, or stored via a blockchain, as opposed to data required by the underlying blockchain protocol as part of the transaction code itself.

[0062] Overview

[0063] As described above, it has been recognized that there is a need for an improved and / or alternative infrastructure to store, write, access, and view data between and by computing nodes. Using the advantages inherent in blockchain technology (e.g., immutable records, cryptographically enforced control and access, built-in payment mechanisms, the ability to publicly inspect the ledger, distributed architecture, etc.) would be advantageous. However, building a "blockchain-enabled Internet" is challenging from many technical perspectives.

[0064] 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 can gain access; how to transmit data from one party to another in a peer-to-peer manner; how to arrange data so that it can be logically associated but still stored in different locations within the network, and how to subsequently combine it from different locations to provide an overall and enhanced result; how to provide and / or store data in a hierarchical manner; how to allow users and parties with different computing platforms to access the required data; how to store, provide, and share data across (potentially global) computing networks without relying on or requiring large storage servers and centralized data controllers.

[0065] The present invention provides this improved solution in a manner that is similar in some respects to the Internet, but achieves its results in a completely different manner, using a platform of completely different hardware components and software components than those known in the prior art. According to an embodiment of the present invention, the servers that store Internet / network data and provide it to end users are replaced by blockchain exchanges that reside on the blockchain network. In order to achieve this, several innovations must be devised. These are described in the following sections.

[0066] Insert data into the blockchain "metanet" for reference Figure 1, shows 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 of the first data <content 1> are stored in the spendable output of the transaction. Data <attribute 1> and <attribute 2> representing respective attributes of the first data and a flag indicating that the data is being stored according to the metanet protocol are stored in a second unspendable output of the transaction. The term "unspendable" is used to indicate that at least one first and / or second output of the transaction may include a script opcode (OPRETURN) for marking the output as invalid for subsequent use as an input to a subsequent transaction.

[0067] It is advantageous to store the content and attribute parts of the data separately in separate outputs of the transaction.

[0068] Figure 2 A blockchain transaction embodying the present invention is shown, in which the first data <content 1> to be stored on the blockchain is stored in the input of the transaction. The metanet flag and the attribute data <attribute 1> and <attribute 2> are similar to Figure 1 The arrangement shown is stored in the unspendable output of the transaction.

[0069] Data Insertion

[0070] Data insertion method

[0071] Hopefully the following data can be inserted into the blockchain

[0072] a) MetaNet Logo

[0073] b) Attributes

[0074] c) Content

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

[0076] The following techniques can be used to embed this data into blockchain scripts:

[0077] 1. OP_RETURN - In this method, all the data (attributes and contents) in the locking script of the provably unspendable transaction output is placed after the OP_RETURN.

[0078] An example output script using this operator is as follows:

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

[0080] 2. OP_RETURN with OP_DROP - In this case, the OP_RETURN contains the attributes, while the content is stored in the spendable transaction script (locked or unlocked) before the OP_DROP. The content can be split into multiple packets in transaction inputs and outputs. If the data is inserted into the transaction input, the OP_MOD can be used as a checksum on 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 is equal to a pre-calculated value.

[0081] In this case, the attributes may contain information about how to reassemble the content packets. Additionally, providing the hash of the reassembled packet H(Content 1 + Content 2) as an attribute enables verification that the recommended reassembly scheme has been used.

[0082] Figure 1 A transaction implementing the second data insertion method is shown in . For simplicity, this transaction only includes the content inserted into its output, which is signed by its single input. Figure 2 The method shown here can also be used to insert content into another input using the OP_DROP statement.

[0083] If the content is large, it may be advantageous to split it over multiple transactions. Figure 3 Shown in. Figure 3 A pair of blockchain transactions embodying the present invention is shown, in which a first data <content> to be stored on the blockchain is split into two chunks <content chunk 1> and <content chunk 2>, which can then be reassembled as <content>=<content chunk 1> / / <content chunk 2>, where the operator " / / " concatenates the content data of the two chunks. The concatenation operator can be replaced by any desired bitwise or similar piecewise binary operator. The two chunks <content chunk 1> and <content chunk 2> are then stored in corresponding spendable outputs of separate blockchain transactions, while data related to attributes of the content data are stored in 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 web page. In addition, 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 web page.

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

[0085] Using the role of network node verification

[0086] Here, the transaction verification process performed by the network nodes is used to gain an advantage in 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 in the transaction verification process performed by all network nodes.

[0087] This ensures

[0088] Data integrity - If the data is corrupted, the CHECKSIG operation will fail.

[0089] Data authenticity - the owner of P has provably witnessed and signed the data.

[0090] This is particularly beneficial for content that is split over multiple transactions, since P's input signature provides a provable link between the split components of the data, as described above in reference Figure 3 The arrangement shown in is described.

[0091] Rabin's signature

[0092] Another way to ensure the authenticity of data 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 signatory does not need to sign each individual transaction in which the data appears, and the signature can be reused in multiple transactions.

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

[0094] <content1><Rabin Sig(content1)>FUNC_CHECKRABSIG OP_DROP <H(P 1 )>[CheckSigP 1 ]

[0095] Note that this cannot be done in case (1) above, since the script containing the OP_RETURN fails regardless, so verification cannot be achieved.

[0096] A concrete example using Rabin signatures

[0097] introduce

[0098] Digital signatures are a fundamental part of blockchain protocols. They ensure that any transaction recorded on the blockchain has been authorized by the legitimate 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 usually applied to the entire transaction.

[0099] There are some use cases for blockchains where participants from outside the network may want to provide signatures for arbitrary data types that can then be used by network participants. By using Rabin digital signatures, any piece of data can be signed - even if it originates outside the blockchain - and then placed in one or more transactions.

[0100] It will now be shown how data can be signed and verified directly with a script by exploiting the algebraic structure of the Rabin cryptosystem.

[0101] Rabin Digital Signature

[0102] Rabin Digital Signature Algorithm

[0103] Background Mathematics

[0104] Definition – Integer mod p

[0105] The integers modulo p are defined as the set

[0106]

[0107] Fermat's Little Theorem

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

[0109] a p - 1 ≡1mod p

[0110] Euler criterion

[0111] Let p be a prime number. r is a quadratic remainder mod p if and only if

[0112]

[0113] Modular square root (p = 3 mod 4)

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

[0115] a 2 ≡r mod p

[0116] Then, a has the form of a solution of

[0117]

[0118] Chinese Remainder Theorem

[0119] Given pairs of mutually prime positive integers n 1 , n 2 , ..., n k and any integer a 1 , a 2 , ..., a k , a system of simultaneous congruences

[0120]

[0121] Has a unique solution modulus N = n 1 n 2 …n k As a special case of the Chinese Remainder Theorem, it can be shown that:

[0122] If and only if

[0123] x≡r mod n 1 ·n 2 hour,

[0124] x≡r mod n 1 And x≡r mod n 2 Rabin Digital Signature Algorithm

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

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

[0127] To generate the key, select prime numbers p and q, each with a bit length of approximately k / 2, such that p≡3mod 4, q≡3mod 4 and calculate the product n=p·q. The private key is (p, q) and the public key is n=p·q.

[0128] To sign a message m, the signer chooses padding U such that H(m||U) satisfies

[0129]

[0130]

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

[0132]

[0133] The signature of a message m is the pair (S, U). Verification can be done simply by checking that for a given m, U, and S,

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

[0135] If and only if there exists an integer λ in the range 0, ..., n-1 such that

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

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

[0138] Rabi n The beneficial features of the signature scheme are as follows:

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

[0140] b) The security of the signature depends only on the difficulty of integer factorization. Therefore, the Rabin signature is inherently unforgeable (unlike RSA).

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

[0142] Verification in Script is straightforward, as it only requires squaring the given signature, performing a modular reduction, and then checking that the result is equal to H(m||U).

[0143] Rabin Signature Proof

[0144] Let p and q be relatively prime numbers, and n = p·q. By using the Chinese remainder theorem, it can be shown that:

[0145] If and only if

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

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

[0148] but

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

[0150] Use the following equation

[0151]

[0152] It can be shown that:

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

[0154] so

[0155]

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

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

[0158] Rabin signature in blockchain

[0159] Signature verification in scripts

[0160] A small amount of arithmetic and stack manipulation opcodes are required to verify the Rabin signature. Consider a redemption script of the form

[0161] OP_DUP OP_HASH160<H 160 (n)>OP_EQUALVERIFY OP_MULOP_SWAP OP_2 OP_ROLLOP_CAI F UNC_HASH3072 OP_ADD OP_SWAP OP_DUP OP_MUL OP_EQUAL

[0162] Where n is the signer's public key. This will evaluate to true if and only if the following input is present

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

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

[0165] OP_DUP OP_HASH160 <H 160 (n)>OP_DUP OP_TOALTSTACK OP_SWAP<roll index> OP_ROLL OP_CAT FUNC_HASH3072OP_SWAP OP_MOD OP_SWAP OP_DUP OP_MUL OP_FROMALTSTACKOP_MOD OP_EQUAL

[0166] In this case, this will evaluate to true if and only if the input is

[0167] S> <m> <n>

[0168] In both redemption scripts, the 3072-bit hash projection function "FUNC HASH3072" is used. For a given message / padding concatenation, the following script is used to generate the FUNC HASH3072 hash projection:

[0169] OP_SHA256{OP_2OP_SPLIT OP_SWAP OP_SHA256OP_SWAP}(x11)

[0170] OP_SHA256OP_SWAP OP_SHA256{OP_CAT}(x11)

[0171] Data Compression

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

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

[0174] There are many different algorithms, depending on the specific input data. Apple Lossless and Adaptive Transform Vocoding can be used to compress audio files, PNG and TIFF can be used to compress graphic files, and movie files can be compressed using one of many lossless video codecs. Flags within the attributes can be used to indicate any compression of the data content. For example, the flag in the attributes for the LZW lossless encoding scheme would be <lzw>.

[0175] Encryption and decryption of payments

[0176] Data encryption

[0177] Owners of content can choose to protect content before embedding it on the blockchain. This ensures that the content cannot be viewed without the necessary permissions.

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

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

[0180] In a symmetric scheme, a single key is used for both encryption and decryption of data. The Advanced Encryption Standard (AES) algorithm is considered one of the most secure symmetric algorithms generated by such a secret as a seed, for example as described in more detail in C. Paar and J. Pelzl, Chapter 4 in "Understanding Cryptography", Springer-Verlag Berlin Heidelberg, 2nd edition, 2010, pages 87-118.

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

[0182] -The encryption is only as secure as the underlying system on which the data is stored.

[0183] -The software architecture required to store encrypted data will have a smaller code base.

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

[0185] - It is more efficient since the same key can be used for encryption and payments in cryptocurrency, so fewer keys are required. This also reduces storage space.

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

[0187] - Improved security since the keys used for encryption and transactions are the same data structure, thus mitigating targeted attacks on specific key types.

[0188] -Keys can be purchased using the underlying cryptocurrency.

[0189] For purposes of illustration, it is described how the Koblitz algorithm may be used to encrypt data using ECC.

[0190] Koblitz algorithm

[0191] Given an ECC key pair P 1 =S 1 G, Koblitz algorithm allows anyone to use the public key P1 to encrypt a message when only the corresponding private key S is known 1 can decrypt the message.

[0192] Suppose you wish to encrypt the plaintext message 'hello world' using the Koblitz method. This is done character by character. The first character 'h' is encrypted and decrypted as follows.

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

[0194] 2. Then use the public key P 1 Point P m This is done by choosing a random temporary key k 0 And calculate the point pair C m ={k 0 ·G,Q}(where Q:=P m +k 0 ·P 1 ) to achieve this, and then the point pair can be broadcast.

[0195] 3. Private key S 1 The owner of can calculate P m =QS 1 ·k 0 G to decrypt the original point. They can then recover the original ASCII number by trial and error or with the help of a lookup table to establish which number x corresponds to P m =x·G.

[0196] Using blockchain to purchase licenses

[0197] Storing data on a blockchain has the obvious advantage that payment mechanisms are built into the system. Payments can be used to purchase

[0198] -Decrypt data for viewing / use

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

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

[0201] An efficient and secure way to make such a purchase is to use an atomic swap. This keeps the secure communication channel to a minimum and ensures payment to the seller and disclosure of the secret to the buyer, or that nothing has happened.

[0202] In addition to paying with cryptocurrency, it is convenient to purchase licenses using access tokens. This is a secret value (usually a hashed preimage) that the buyer has that he can use to make the purchase. The buyer can purchase such access tokens in bulk in advance and then activate them when he actually wants to use the license.

[0203] Now refer to Figure 4 and Figure 5 Describes how to perform atomic swaps.

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

[0205] Assume Alice is the owner of a secret. The secret can be a hash preimage of a known hash digest, or a private key of a known public key. Assume Bob wishes to purchase the secret from Alice using a token. Describe a mechanism called an atomic swap that enables this transaction to occur. This is atomic in the sense that Alice gets paid with a token and the secret is revealed to Bob, or nothing happens.

[0206] The method is as follows:

[0207] Alice has a public / private key pair P A =S A G's private key S A , Bob has a public / private key pair P B =S B G's private key S B .

[0208] Alice has the preimage X which is a known hash digest H(X) or a known public key P 1 =S 1 G's private key S 1 The secret.

[0209] They agree that Alice will sell the secret to Bob for a token price.

[0210] Before this can happen, Bob must set up a transaction to send the temporary key k outside the block. 0 Send it to Alice so that Alice can calculate the digital signature component r 0 .

[0211] Reference Figure 4 ,

[0212] 1. Bob transfers the tokens locked via the following redemption script R (written schematically) to Alice:

[0213] For the hash preimage:

[0214] R=[Hash PuzzleH(X)][CheckSig P A ]

[0215] This forces the preimage X to be exposed in the redeem script's input.

[0216] For private key:

[0217] R=[Private Key Puzzle P 1 , r 0 ][CheckSig P A ]

[0218] This forces the private key S 1 can be computed from the inputs to the redeem script. In this case, Bob and Alice must construct 0 The temporary key k 0 reached a consensus, where (r 0 , R y ) = k 0 ·G.

[0219] 2. Since Alice knows her secret (X or S 1 ), so she can use Figure 5 The transaction shown spends her funds on the blockchain. This allows Bob to determine her secret.

[0220] As an optional security feature, Alice and Bob can use their public keys P A , P B to establish a shared secret S known only to the two of them. This can be done 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 k 0 This ensures that only Alice or Bob can calculate the private key.

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

[0222] Purchase using tokens

[0223] Assume the same situation as described above, but instead of paying Alice for her secret in cryptocurrency at the time of use, Bob wishes to redeem an access token purchased in advance in exchange for the secret.

[0224] The procedure that Alice and Bob must follow is similar to the case described in the previous section, but uses a similar sequence of atomic swaps. There are two phases to the process; token issuance and token redemption.

[0225] Phase 1: Token Release

[0226] The token issuance phase is actually a single purchase of tokens by Bob. For example, consider the following scenario: Alice has 10 different secrets X 1 , X 2 , ..., X 10 , and Bob wishes to make a single purchase of 10 tokens T that each grant him access to the corresponding secret 1 , T 2 ,…,T 10 .

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

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

[0229] Alice and Bob now each have 10 secret values ​​that can be revealed in a hash puzzle to, for example, redeem 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 as follows:

[0230] I Alice = k,

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

[0232] Note that Alice's initialiser is simply a random integer with no particular meaning, but Bob's initialiser should be the hash of his first token, T 1 =H 9 (Y). Extending the token chain to an initialization value in this manner allows token issuance to also define tokens to be used later for subsequent redemption. Figure 6 All secret values ​​kept by each participant are shown in .

[0233] Alice and Bob can now agree to buy 10 tokens for 10 units of cryptocurrency. The purchase of these tokens can be done in a variety of ways, illustrated here using atomic swaps. Atomic swaps are broadcast by Alice and Bob respectively. Figure 7 and Figure 8 The outputs in both transactions require the solution of two hash puzzles and a valid signature.

[0234] Once two transactions appear in the blockchain, Alice and Bob can share their shared initialization value I Alice and I Bob , and complete the atomic swap of token issuance.

[0235] As a result of this atomic swap, Alice receives payment for the purchase of 10 tokens and both initialization value secrets are revealed. Note that only Bob’s secret I Bob =H 10 (Y) is meaningful because it will limit the first hash puzzle to be solved [Hash puzzle (T 1 )], whose solution is the initialization value H 10 The preimage H of (Y) 9 (Y).

[0236] Phase 2: Token Redemption

[0237] At some point in the future, Bob wants to redeem his first token T 1 =H 9 (Y) and receives its first secret X 1 , but as mentioned above, the secret has been paid by purchasing a valid token. The process of exchanging tokens will take the form of another atomic swap, in which the solution to the locked hash puzzle is the token T i and the corresponding secret X i .

[0238] To redeem his tokens, Bob should broadcast Fig. 9 The transaction shown in , the output of which is locked with two hash puzzles. When Alice sees this transaction, she broadcasts Fig.10 The two participants can now exchange their secret T 1 and X 1 , and unlock the outputs of these transactions. The two parties can now exchange the nominal fee x by providing the correct unlocking script that also reveals the two secrets. Fig.11 and Fig.12 A transaction with these unlocking scripts is shown in .

[0239] The completion of this atomic swap for exchanging tokens reveals Alice’s first secret X to Bob 1 , revealing Bob’s first token T to Alice 1 , and given that the amount x is suitably large to encourage both parties to spend the locked output, there is a net zero exchange of cryptocurrency funds. Crucially, this also establishes that the next token Bob can spend must be the hash puzzle [Hash puzzle H(T 2 )] solution T 2 , where the target hash H(T 2 )=T 1 This process can be repeated recursively until Bob has used his last token T 10 =Y.

[0240] Naming and addressing

[0241] Node and edge structure

[0242] It has been explained above how data can be inserted into the blockchain by providing it within a transaction. Now a protocol is presented for structuring these transactions in a logical manner that allows for node discovery, licensing, and content versioning. The structure of this distributed peer-to-peer metanet is similar to the existing Internet.

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

[0244] The goals of the structure described here are:

[0245] (i) Associating related content from different transactions to enable search, identification and access to data

[0246] (ii) Allow human-readable keyword searches to identify content to improve search speed, accuracy, and efficiency

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

[0248] 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:

[0249] Node - Transactions associated with the Metanet Protocol. Nodes store content. (The terms "content" and "data" are used interchangeably in this document).

[0250] The node is included by<Metanet Flag> Each node is assigned a public key P node The combination of the public key and the transaction ID uniquely specifies the index ID of the node. node :=H(P node ||TxID node ).

[0251] The hash function used should be consistent with the underlying blockchain protocol that the present invention will use with SHA-256 or RIPEMD-160.

[0252] Edge - the association of a child node with a parent node.

[0253] Edge in Signature Sig P parent It is created when it appears in the input of a MetaNet transaction, so only the parent can give permission to create an edge. All nodes can have at most one parent, and a parent node can have any number of children. In the language of graph theory, the indegree of each node is at most 1, and the outdegree of each node is arbitrary.

[0254] It should be noted that edges are aspects of the metanet protocol and are not themselves transactions associated with the underlying blockchain.

[0255] A valid metanet node (with a parent) is given by a transaction of the following form:

[0256]

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

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

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

[0260] Furthermore, since the signature of the parent node is required, only the parent can create an edge to the child. <txidparent>If the field does not exist or does not point to a valid Metanet transaction, the node is an orphan. The node has no higher-level nodes that can reach it.

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

[0262] As shown, the index of nodes (transactions) can be divided into

[0263] a) Public key P node , which we interpret as the address of the node

[0264] b) Transaction ID TxID node , which we interpret as the version of the node

[0265] This structuring yields two advantageous features:

[0266] 1. Versioning - If there are two nodes with the same public key, we interpret the node with the transaction ID that has the largest proof of work as the latest version of that node. 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).

[0267] 2. Permission - only if the public key P node The node's children can only be created when the owner of P signs the transaction input when creating the child node. node Not only does it represent the address of a node, but it also represents the permission to create child nodes. This is intentionally similar to standard blockchain transactions - a public key is not only an address, but also the permission associated with that address.

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

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

[0270] The node and edge structure allows the meta-network to be visualized as a graph, e.g. Fig.13 shown.

[0271] Domains, naming, and locating content in the Metanet

[0272] The hierarchical structure of the metanet graph allows for a rich domain-like structure to emerge. We interpret orphan nodes as top-level domains (TLDs), children of orphan nodes as subdomains, grandchildren as sub-subdomains, etc., and childless nodes as end-points. Fig.13 .

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

[0274] The MetaNet protocol does not specify that any node contains content data, but leaf (childless) nodes represent the end of a directed path on the data tree and will therefore typically be used to store content data. However, content can be stored at any node in the tree. Protocol-specific flags included as attributes in the node can be used to specify the role of a node in the data tree (disk space, folder, file, or permission change).

[0275] As mentioned earlier, the Internet uses the Domain Name System (DNS) to associate human-readable names to 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 companies). Depending on your DNS provider, the same name can take you to different addresses. This problem is inherent in mapping short human-readable names to computer-generated numbers.

[0276] We assume that there is a decentralized index ID that maps human-readable top-level domains to root nodes root In other words, there is a 1-1 function K that maps human-readable names to meta-network root node indices, such as:

[0277] K('bobsblog') = ID bobsblog (=H(P bobsblog ||TxID bobsblog ))

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

[0279] The mapping κ should be interpreted as a measure to ensure backward compatibility of the Metanet with the Internet when replicating human readability of DNS-published domain names, but the naming and addressing scheme providing the structure of the Metanet does not explicitly depend on this mapping.

[0280] 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). The mapping can be stored in an existing TXT record as part of DNS. This is similar to DNSLink in IPFS, see https: / / docs.ipfs.io / guides / concepts / dnslink / . However, in general, these sacrifice some elements of decentralization in order to provide a 1-1 mapping, see https: / / hacke r noon.co m / ten-ter r ible-attempts-to-make-the-ineer-planetary- fi le-system-human-friendly-e4e95df0c6fa

[0281] Vanity Address

[0282] The public keys used as addresses of MetaNetwork nodes are not human-readable objects. This can make search, referencing, and input activities by human users error-prone and slow. However, it is possible to create human-recognizable public key addresses - vanity addresses P vanity - It includes a plain text prefix that can be directly interpreted by the user. Vanity addresses are known in the art.

[0283] The difficulty of creating such an address depends on the length of characters in the required prefix. This means that human-readable vanity addresses can be used as node addresses that rely only on the owner's creation effort rather than central publication. For a given prefix, there are many different vanity addresses due to the remaining characters in the suffix, so many node addresses can share a common prefix while still remaining unique.

[0284] An example of a vanity address with the desired prefix is:

[0285] Pb obsblog :bobsblogHtKNngkdXEeobR76b53LETtpyT

[0286] Prefix: bobsblog

[0287] Suffix: HtKNngkdXEeobR76b53LETtpyT

[0288] The vanity address above can be used to sense the node index ID from the name 'bobsblog' bobsblog It should be noted that the prefix is ​​not unique here, but the entire address itself is a unique entity.

[0289] Selected address P vanity Together with TxID, it forms ID node The combination of is also beneficial because it means there is no central issuer of domain names (TxIDs are generated by decentralized proof of work), and names are recoverable from the blockchain itself. Advantageously, there are no more points of failure that exist within the Internet DNS.

[0290] Since the metadomain already provides a permission system (public keys), there is no need to issue certificates to prove ownership. This has been done, for example, in Namecoin ( https: / / namecoin.org / ) explores using blockchain for this purpose. However, according to the present invention, there is no need to use a separate blockchain for this function, as everything can be achieved within one blockchain.

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

[0292] The advantage of this naming system is that users are able to identify top-level domains in the Metanet by memorable words (e.g., company names) rather than hash digests. This also makes searching for domains faster because it is faster to search for keywords rather than hash digests. This also reduces typing errors, thus providing an improved search tool for data stored on the blockchain.

[0293] Given that we have a mapping from domain names to node indices, we can create a resource locator similar to the Internet's uniform resource locator (URL). We call this a metanet URL (MURL) and it is of the form

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

[0295] Each of the components of a URL—protocol, domain name, path, and file—has been mapped to the structure of an MURL, making the object more user-intuitive and enabling it to integrate with the existing structure of the Internet.

[0296] This assumes that each node has a name associated with its public key (address) that is unique at the level within the domain tree. The 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, so the latest version is used.

[0297] The following table gives an analogy between the Metanet Protocol and the Internet Protocol:

[0298]

[0299]

[0300] Table: Summary of analogies between Internet Protocol and Metanet Protocol

[0301] Search MetaNet

[0302] We have defined the meta-graph structure of the exemplary embodiment so that each node has a unique index and can have a name attributed to it. This allows the use of MURLs to locate content. To also enable fast search functionality, we allow additional keywords to be attributed to nodes.

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

[0304] Node properties

[0305]

[0306] In one example, a practical method for searching the metanet may be to first trawl the blockchain using a block explorer and identify all transactions by the metanet flag, check if it is a valid metanet node, and if so, record its index and keyword in a database or other storage resource. This database can then be used to efficiently search for nodes by the desired keyword. Once the index of a node is found by the desired keyword, its content can be extracted from the block explorer and viewed.

[0307] For example, consider Fig.14 Branch P 1 , where corresponds to the public key P 0 , P 1 and P 1，1 The nodes represent the home page, topic page, and sub-topic page respectively. These nodes are given the names 'bobsblog', 'summer', and 'caribbean', and their properties are as follows:

[0308] Home Node P 0

[0309]

[0310] Topic page node P1

[0311]

[0312] Subtopic page node P 1，1

[0313]

[0314]

[0315] In this example, the leaf node P 1，2，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 over leaf at the end of the page, including the MURL search paths associated with each node in the tree.

[0316] We should note that the Metanet can also be incorporated into the Content Addressable Network (CAN) by storing the hash of the content stored by the node transaction as an additional attribute. This means that the Metanet nodes can also be indexed and searched by content hash.

[0317] The naming and addressing method described above provides numerous technical advantages over existing technologies, including:

[0318] 1. Public key address - The system uses the same public-private key pair as the blockchain to assign node addresses. This means that the same set of keys is used for both the management of cryptocurrency funds and the licensing of content data. This provides an efficient and secure solution.

[0319] 2. Decentralized Domains - Domain names are published by including a TxID that can only be generated by proof of work node Domain names can also incorporate human-readable public keys P that achieve fair distribution of required domain public keys. vanity (Vanity Address). Again, this solution provides enhanced efficiency and security.

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

[0321] Browser wallet application

[0322] As described above, in the Metanet protocol, all data exists directly on the blockchain itself. In this section, we provide an embodiment of an illustrative computer application that can effectively access, display, and interact with Metanet data stored on the blockchain, which is simply referred to as a "browser wallet" for convenience herein.

[0323] We will first discuss the core components and functionality of how browser wallets interface with the distributed peer-to-peer Internet, before providing a more detailed description in the remainder of this section.

[0324] Overview

[0325] Components

[0326] The browser wallet is an application designed to allow end users to interact with the Metanet infrastructure on the blockchain. The application should allow exploratory searching of the Metanet graph to find specific content embedded in the tree. In addition, the browser wallet will handle the retrieval, decryption, reassembly and caching (optional) of content.

[0327] The browser wallet application will combine these elements with a cryptocurrency payment mechanism by supporting a local (or external) wallet. The browser wallet will include the following core elements combined into a single computer application.

[0328] Blockchain search engine - supports third-party search engines through various indexes (including ID node , node name, keyword, block height and TxID) to query the MetaNet node.

[0329] Display Window - Software that unpacks content returned to the browser by a full copy of the blockchain peer. This covers decryption, reassembly, caching, and redemption of access tokens.

[0330] Cryptocurrency Wallet - Dedicated key management for the blockchain's currency. Can be local to the application or authorized to communicate and sync with external wallets (software or hardware). Able to write standard blockchain transactions as well as new metanet node transactions. Can mediate on-chain purchases of access keys and access tokens.

[0331] Hierarchical deterministic key management can be used for both cryptocurrency public keys and metanet node addresses.

[0332] Access Key / Token Wallet - Dedicated key management for purchased access keys or tokens. A cryptocurrency wallet may be used to receive purchased keys or tokens, but without having permission to the keys or tokens. The keys or tokens may be hidden from the user to allow for later expiration. This may be accomplished by using a trusted execution environment. Timed access may be guaranteed by syncing with the blockchain and querying the current block height.

[0333] Functional

[0334] The specifications of the MetaNet browser wallet ensure the following functions of the application.

[0335] 1. Hierarchical Key Management - The keys used to control funds and manage the Metanet tree (Figure) utilize the same hierarchical deterministic key infrastructure, thereby reducing the burden on users to maintain key records for their Metanet content.

[0336] 2. Pointing to external cryptocurrency wallets - The ability to authorize and sync with external (non-app local) wallets allows additional security by removing the browser wallet as a point of failure.

[0337] The application can write blockchain transactions and require the signature of an external wallet that holds the keys, thereby delegating this responsibility to separate software or hardware.

[0338] 3. Search for Metanet Content - The browser wallet can support and query third-party search engines, which can include crawling, indexing, serving and rating Metanet node transaction data in the global database. A database of OP RETURN transactions containing Metanet protocol flags can be constructed. See BitDB 2.0- https: / / bitdb.network / .

[0339] Search engines can provide browser wallets with node indexes, which allows data to be found.

[0340] 4. Read and write data to the blockchain - In addition to using search engines and full nodes to provide content to browsers, support for cryptocurrency wallets also allows content to be written directly from browser wallets to the metanet.

[0341] 5. Decompression and decryption of data - The browser wallet handles the decryption keys and can perform decompression on the Metanet content in situ.

[0342] 6. Cache Node Identity (ID node )-Unique node identities can be cached locally for more efficient lookups and queries.

[0343] 7. Bypass Network Server - Given a node index, the browser wallet can query any full replica member of the peer-to-peer (P2P) blockchain network to obtain the content located at the node. Because the metanet exists on-chain, any full replica peer must have a local copy of the node and its content.

[0344] This means that the user’s browser wallet only needs to query a single peer, which can be done directly without the need for an intermediary network server.

[0345] Fig.15 A diagram showing a browser wallet and how its core functionality is split between different components of the application.

[0346] Blockchain search engine

[0347] Search Engines - Prior Art

[0348] Search engines (SEs) known in the prior art rely on powerful web crawlers to locate, index, and rate web content based on user queries. (The same basic principle can be extended to third-party blockchain SEs that crawl the metanet).

[0349] The SE identifies relevant HTML meta tags and content through keyword searches in the query. The crawl results are then indexed, where any embedded images / videos / media files are analyzed and cataloged. The most relevant results in the index are then programmatically ranked, taking into account the user's location, language, and device.

[0350] A typical SE should have the following functionality:

[0351] 1. Crawl - Identify Internet data and crawl through related metadata such as domain names, linked pages, and related keywords, etc. Discover new Internet content through existing content and also crawl for any related information.

[0352] 2. Indexing - Analyze and catalog content data. This information is stored in a database.

[0353] 3. Serving and Rating - Rating content indexes in order of relevance to user queries.

[0354] Block Detector

[0355] The closest blockchain analog to an Internet search engine (SE) is a blockchain explorer, which is sometimes called a 'block explorer' or 'blockchain browser.' A blockchain explorer is a web application that enables user-friendly queries of the blockchain at a high level, and functions similarly to a web browser, but connects to the blockchain rather than the Internet.

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

[0357] Block explorers vary in their capabilities, but are generally useful for cataloging transactions and displaying basic information about them in a form that is easily digestible by users—for example, the monetary value of the transaction, the confirmation and history of the coin, and the address. Many explorers also allow viewing of a transaction's individual inputs and locking scripts, although these are not as common as more advanced sites (e.g., Blockchair). https: / / blockchair.com / ) choose to provide this information.

[0358] Recently, there are many extensions to the basic blockchain explorer for running web applications based on blockchain data. These applications (e.g., Memo.cash https: / / memo.cash / protocol and Matter https: / / www.mttr.app / home ) catalogs and organizes blockchain transactions containing specific protocol identifiers like a block explorer, and displays the data encoded within those specific transactions.

[0359] However, there are two significant problems with using blockchain detectors, which embodiments of the present invention address:

[0360] 1. Universality - Currently there is no industry standard for browsing content data stored in transactions. Content data refers to any data that is not related to the protocol used to create and secure the underlying blockchain.

[0361] 2. Keyword Search - The content data stored in the transaction needs to be searchable by human-readable keywords. This is not generally a function of current block explorers, as current block explorers are used to query the protocol-based properties of transactions (e.g., block height, TxID, and address), rather than keywords as search input. (However, some explorers such as Blockchair can search for these words if they are included directly in the script of the transaction).

[0362] Importantly, as described above, the powerful naming and addressing structure of the present invention facilitates and enables the construction of more complex blockchain probes than are known in the art.

[0363] Metanet Search Engine

[0364] The browser wallet application communicates with a third-party search engine to discover the node identity (ID node ). It is contemplated that this third party may provide a powerful and versatile service that replicates the capabilities of existing Internet search engines.

[0365] The third party Metanet search engine maintains a database of all Metanet transactions mined into the blockchain that can be identified by the Metanet protocol logo. This database can be obtained by including ID node , node name, keyword, TxID and block height range index catalogs all meta-network nodes.

[0366] There are already existing platforms such as BitDB https: / / bitdb.network / The browser wallet transfers the responsibility of crawling, indexing, serving and rating Metanet transactions to this third party and connects to its service when locating content stored on the Metanet graph.

[0367] By having a database dedicated only to Metanet data, efficiency can be saved. Unlike Bit DB, this database will not store data associated with all transactions, but only those containing the Metanet flag. Certain 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 space, and more efficient association of related content within the Metanet domain.

[0368] Fig.16 It is shown how a browser wallet interacts with a third party search engine when a user searches for content within the Metanet infrastructure. It is important to note that in contrast to the Internet, no routing is required, and thus the present invention provides significant advantages in terms of efficiency, speed, processing, and required resources.

[0369] The process is as follows:

[0370] 1. The end user enters keywords in the browser wallet search bar.

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

[0372] 3. The SE checks the keyword against its database and returns the ID of any MetaNetwork Node that contains relevant content node . Third parties may also return other indexes on each node to the user and provide suggestions for related content.

[0373] 4. The browser wallet constructs the MURL using the node ID and the domain name associated with it.

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

[0375] 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, so only one request is made and the request is never forwarded to other network peers.

[0376] It should be emphasized 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 (e.g., full-copy peers, archives) that have a full copy of the blockchain.

[0377] Content Display – MetaNet Browser

[0378] The browser wallet application emulates the same front-end capabilities that any typical web browser should provide. These features include but are not limited to:

[0379] 1. Search - Provides access to a search engine (SE) to locate content.

[0380] 2. Retrieval - Communicate with a server to facilitate transfer of content using known protocols such as Hypertext Transfer Protocol (HTTP).

[0381] 3. Interpretation - Parsing the original code (e.g., in JavaScript) and executing it.

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

[0383] 5. User Interface (UI) - Provide users with an intuitive interface to interact with content, including action buttons and mechanisms for user input.

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

[0385] In certain embodiments, a software component of a browser wallet application responsible for acting as a web browser is able to perform the above functions on metanet content embedded in a blockchain that is searchable (using SE) and retrievable (from peers) using its attributes.

[0386] Reassembly, decompression and decryption

[0387] According to certain embodiments of the invention, the web browser software component of the browser wallet application is able to handle all operations that need to be performed on a given metanet content. In general, 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 the metanet protocol and infrastructure.

[0388] Reassembly - In the case where the metanet content needs to be split and inserted into multiple separate node transactions, the application will request the 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 the properties of each node.

[0389] Decompression - In cases where 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 app will decompress the content based on this flag.

[0390] Decryption - In the case where the 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.

[0391] 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, for which the appropriate<operation_flag> May be included as part of the properties of the node to which the operation applies.

[0392] Cache

[0393] The caching of local files and cookies is a common and important function of typical web browsers. Browser wallet applications also use local storage in a similar manner to optionally save IDs related to content of interest. node This allows for more efficient lookup and retrieval of content from frequently visited MetaNetwork nodes.

[0394] The Metanet solves the inherent problem of caching Internet data, which is mutable and can be changed or truncated 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.

[0395] Cryptocurrency wallets

[0396] Hierarchical Deterministic Key Management

[0397] A deterministic key Dk is a private key initialized from a single "seed" key. The seed is a randomly generated number that acts as a master key. A hash function can be used to combine the seed with other data (e.g., an index number or "chain code") (see, HD Wallets - BIP-32 / BIP-44) to derive a deterministic key. These keys are related to each other and can be fully recovered from the seed key. The seed also allows easy import / export of wallets between different wallet implementations, giving an additional degree of freedom if the user wishes to use an external wallet in conjunction with the Metanet Browser Wallet.

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

[0399] In a preferred embodiment, the HD wallet can be incorporated into Fig.16 In the meta-network architecture shown in .

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

[0401] 1. Structure Different branches of subkeys can be used for different purposes to express additional organizational meaning. For example, users can dedicate different branches (and their corresponding subkeys) to different types of data.

[0402] 2. Security Users can create a series of public keys without corresponding private keys, making HD wallets capable of receiving only and suitable for use on unsecured servers. Moreover, since fewer secrets need to be stored, the risk of exposure is lower.

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

[0404] Local (internal) and external wallet support

[0405] Advantageously, embodiments of the present invention can directly merge the functionality of a conventional web browser with one or more cryptocurrency wallets. Fundamentally, this is how the Metanet combines payment for "Internet" content with its delivery to end users.

[0406] To achieve this, an embodiment of the browser wallet may have a dedicated built-in software component that acts as a cryptocurrency wallet. The wallet is local to the application itself and can be used to manage cryptocurrency private keys and authorize transactions as payment for metanet content within the browser wallet itself.

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

[0408] External Wallet

[0409] If a user wishes to manage or store their cryptocurrency private keys on an external wallet (software or hardware) or even use multiple wallets, the same benefits and functionality can be achieved through embodiments of the application. This can be performed instead of or in conjunction with the application's local wallet.

[0410] In such an embodiment, the application establishes a link or pairing with the external wallet and syncs with it, but does not store private keys in the browser wallet itself. Instead, when the browser component prompts to pay for content, the application requests authorization via a digital signature from the selected external wallet. The authorization is made by the user, and the browser wallet can broadcast the transaction and view the paid content.

[0411] Read and write Metanet transactions

[0412] The essential advantage of the Metanet is that it uses the same data structure - the blockchain - to record both payments and content data. This means that in addition to creating transactions based solely on the exchange of cryptocurrency, software wallets can also be used to write content data to the Metanet infrastructure.

[0413] The local wallet built into the application is able to write transactions to the blockchain that are more complex than a typical Simplified Payment Verification (SPV) client. The wallet allows the user to choose to write Metanet node transactions directly from the application to the blockchain by selecting the content data to be embedded in the blockchain from their computer.

[0414] Since the browser wallet application has a user interface (UI), it allows the wallet component to create and broadcast transactions including content data that has been pre-constructed in the browser component or on the user's computer. This function would be very difficult to achieve for a specially configured wallet that handles it on its own.

[0415] Access Key / Token Wallet

[0416] As described above, built into the Metanet protocol is the ability to encrypt content using ECC key pairs or AES symmetric keys, and the ability to purchase corresponding decryption keys or tokens. We refer to these keys or tokens as access keys or access tokens.

[0417] These keys / tokens grant the user permission to view or edit content (either single use or multi-instance use), and serve a different purpose than the keys that control the user's cryptocurrency wallet (although the same key can be used for both purposes if desired). For this reason, it is advantageous to introduce a new wallet for storing and managing access keys and tokens that is separate from the application's local cryptocurrency wallet.

[0418] The concept of timed access to metanet content can also be introduced by allowing access keys / tokens to be burned after a certain period of time. This can be achieved by requiring that the access keys / tokens be stored in a trusted execution environment (TEE) and not directly accessible to users.

[0419] The fact that access keys / tokens can be "burned" is also a motivation factor to not store them in a cryptocurrency wallet to ensure there is no risk of the cryptocurrency private keys being burned.

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

[0421] It is important here to distinguish between cryptocurrency wallets handling deterministic key generation of key pairs that are used to transact with other users and create new metanet nodes, and key / token wallets handling keys and tokens that have been purchased by a cryptocurrency wallet.

[0422] Block height permission

[0423] Timelocks can be included in the scripting language to implement block height permissions. op_code OP_CHECKLOCKTIMEVERIFY(CLTV) sets the block height at which a transaction output (UTXO) is allowed to be spent.

[0424] The advantages of block height permissioning are twofold:

[0425] 1. Version control - In the Metanet protocol, the latest version of a node can be identified from the node at the maximum block height. The browser wallet can be set to only display the latest version of the file by block height, thereby implementing proof-of-work version control.

[0426] 2. Timed Access - The browser wallet application can periodically burn the decryption key purchased by the user at the atomic level. This ensures that the viewer can only access the content data during the time period for which they have made payment. Cloning of the decryption key can be prevented by storing the decryption key in a trusted execution environment (TEE). In addition, atomic swaps involve the purchase of a deterministic key Dk (used to decrypt the content data). Although this deterministic key is publicly visible, the TEE can be used to sign a combination of Dk and a securely enclaved private key.

[0427] The browser wallet can be arranged to synchronize with the current state of the blockchain so as to use block height as its own proxy for time, rather than relying on any external clock or third-party time oracle.

[0428] Bypass network server

[0429] The present invention allows browsers (clients) and web servers to communicate and exchange information through a new mechanism for distributed peer-to-peer Internet communications that bypasses Domain Name System (DNS) servers and typical network routing procedures. http: / / www.theshulers.com / whitepapers / internet_whitepaper / The present invention provides a new network architecture comprising peers that maintain a full copy of the blockchain, from which content can be served to browser wallet applications.

[0430] Local full replica peer

[0431] Consider a system of local peers in each geographic area (e.g., zip code, town, city). We assume that within this local area network, at least one peer maintains a full copy of the blockchain, and we refer to this peer as a local full copy peer (LFCP). For our purposes, the LFCP only needs to store blockchain transactions including the metanet flag, but is not limited to this.

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

[0433] 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 (about 200GB at write time). The difference between each LFCP is that the LFCP should scale its capabilities to respond to local requests from Metanet users. Therefore, if by default every Metanet user in the world queries its closest LFCP, each LCFP should seek to scale its operational capabilities to meet its local requirements. Densely populated areas such as cities will require LFCP operations involving many clustered servers, while sparsely populated areas such as small towns will require fewer LCFP operations.

[0434] It is important to note that the disk space requirements are generic, while the CPU requirements for each LFCP are adapted to the LAN needs. This is an example of an adaptive network, e.g. Freenet - see https: / / blockstack.org / papers / .

[0435] One advantage of such a system is that it is very easy to retrieve a node When requesting the associated content, the user only needs a single (local) connection to its LFCP. The LFCP does not need to forward the request to other peers because it itself guarantees that it can provide the required content.

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

[0437] The metanet infrastructure is also robust to impairment of any one LFCP by employing a network of these peers. This means that if an LFCP is deactivated, the end user simply defaults to using its next closest LFCP. This can be more efficient if the LFCPs communicate with each other to indicate which nearby peers are below or above capacity in terms of requests at any given time. This can allow users to send their requests to the most appropriate peer and establish a dynamic balance of request distribution between nearby LFCPs.

[0438] Global full replica peer

[0439] Now consider the scenario when the general disk space requirements become too large for smaller peers, which will occur as the metanet portion of the blockchain scales and grows with adoption.

[0440] In this case, the smaller LFCP should use its disk space capacity storage metanet node transactions based on the popularity system (there are existing technologies for ranking content by request volume and nature). This means that the LFCP now tailors both its CPU (for request processing capacity) and its storage allocation (for content serving capacity) to suit its local geographic needs in terms of both content volume and nature.

[0441] In order to solve the fact that LFCP cannot store all metanet transaction contents now, the concept of global full copy peer (GFCP) can be used. GFCP is a full copy peer with the following properties:

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

[0443] 2. GFCP has considerable CPU resources, so that it can handle significantly more requests than LFCP. In case many LFCPs are impaired, the global full replica peers should be able to cope with the sudden increase in demand.

[0444] There are two main functions of the GFCP. First, it acts as a failsafe for user requests for MetaNet content when requests overflow from LFCPs. Second, the GFCP acts as an archive peer to store all MetaNet content mined historically, which ensures that any MetaNet node content can still be accessed even if many LFCPs omit certain content from their local storage supply.

[0445] Global database (data bank)

[0446] The concept of GFCP is powerful and illustrates how the overall architecture of the MetaNetwork can provide solutions to existing problems; creating an all-encompassing global database.

[0447] Prior to this, it has not been possible to securely construct a universal and globally accessible database because a central authority is required to maintain the database. This central authority injects points of failure and trust into the system. Crucially, if we rely on one organization to store and maintain all Internet data, we need to trust the fact that that organization is operating correctly and legally, and will not corrupt information.

[0448] Through the Metanet infrastructure, the two issues of trust and centrality are effectively removed from the concept of a global data center. Now, it is possible to create a GFCP that is only relied upon to provide the disk space required for storage without verifying and authenticating the information to be stored.

[0449] Through the metanet, the process of verifying the stored content is performed by the network nodes, so the universal global database can be trusted because it cannot corrupt the blockchain information. The GFCP does not need to be trusted, it only needs to provide storage.

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

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

[0452] Fig.17 A system with two LFCPs and one GFCP is shown, and explains how each peer can support the other peer in a network that is robust to impairments of the individual peers.

[0453] Aspects of the present invention that may be implemented in the above-described embodiments of the browser wallet application provide a number of distinguishing features and advantages over the prior art, including but not limited to:

[0454] 1. Deterministic Keys - Hierarchical deterministic key management for both cryptocurrencies and metanet addresses is performed in the same wallet component of the application. This allows keys to be organized through multiple functions that reduce their storage requirements and enable key recovery.

[0455] 2. Payment Mechanism - The application allows consumers to pay merchants directly without having to point to another application or third-party payment service that will authenticate and provide trust as per convention. This allows the purchase and delivery of digital content via the same blockchain platform.

[0456] 3. Bypass Web Servers - This application facilitates bypassing the conventional web servers that would traditionally handle a large amount of traffic, requests, and routing. This is because the application only needs to request content from a single LFCP, which ensures that the request does not need to be forwarded to other LFCPs to serve the user. This reduces the total traffic as well as the completion time of each request

[0457] 4. Timed Access - The app facilitates timed access to content by syncing with the blockchain and using the blockchain to enforce access permissions based on its current state. This removes the need for third-party services to monitor user privileges over time while protecting the rights of the original owner.

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

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

[0460] Consider the following scenario: App developer Alice and consumer Bob wish to transact with each other. The transaction will take the form of an atomic swap, where money is exchanged for a secret key that grants Bob access to the app data. The encrypted app data has been made public as part of the Metanet Node transaction.

[0461] Applications exchanged at the atomic level are called Swapps. A third-party platform (Swapp Store) can be used to catalog and advertise applications present on the Metanet, but the payment and transfer of access keys to the user (e.g., Bob) does not require the involvement of any third party and can be done directly between the merchant and the consumer.

[0462] The following section details the process from Alice creating an app to Bob deploying the app for buying and selling Swapp. Throughout the process, Alice and Bob will use their respective browser wallets to interact with the Metanet.

[0463] release

[0464] 1. Alice writes an application. The data that makes up the application is <app>She also uses the secret key S k Encrypt it as<e(App)> .

[0465] 2. Alice creates a node transaction ID AliceApp to set up her first metadomain (tree). She generates 1AliceAppHtKNngkdXEeobR76b53LETtpy(P AliceApp ).

[0466] 3. Alice then creates children of the first node to form a tree that corresponds to the meta-network library of her application. Alice's tree domain is Fig.18 Shown in.

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

[0468] The node transaction is shown below.

[0469]

[0470] 4. Alice's public broadcast ID AliceApp , P AliceApp and the domain name 'AliceApp'. This can be done via social media, an internet website or by using a third party metanet website.

[0471] Buy

[0472] 1. Bob wants to download a puzzle game and sees Alice’s app listed on the Metanet website (Swapp Store) that he views on his browser wallet.

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

[0474] 3. The atomic swap is completed, and Bob's browser wallet transfers the secret key s k Stored in their access key / token wallet.

[0475] deploy

[0476] Bob now has the key s that will allow him to decrypt the application data Alice previously published k To download the app and deploy it, Bob does the following.

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

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

[0479] This locator corresponds to a unique metanet node ID App , which includes the encrypted app data in its input script.

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

[0481] 3. Browser wallet based on ID App This includes using the secret key s k Decrypt application data and process it <app>.

[0482] 4. Bob will apply <app>From his browser to his computer. Now Bob can deploy the application locally without having to re-purchase access.

[0483] Fig.19 The entire process outlined in the illustrative use case above is shown. The flowchart shows two branches of actions: Alice's branch (starting on the left) and Bob's branch (starting on the right). The branch corresponding to Alice shows the initial posting stage and the Bob branch shows the stage of setting up the purchase via an atomic swap.

[0484] On Bob's branch, he broadcasts the following transaction TxID Bob As an atomic swap setup phase:

[0485]

[0486] In this transaction, the output is locked by a private key puzzle that requires the secret decryption key s k Revealed to Bob so Alice can spend.

[0487] Alice and Bob’s branches in this diagram converge at the point where Alice successfully completes the atomic swap transaction. This happens when Alice broadcasts the transaction TxID Alice When achieving:

[0488]

[0489] Once this transaction is broadcast, Alice and Bob’s branches of action diverge again. Alice receives a payment of x tokens, while Bob receives the secret decryption key s k , and is able to retrieve and decrypt Alice's application from the Metanet.

[0490] Now turn to Fig. 20 , 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 of the systems shown and described above. For example, the computing device 2600 can be configured to function as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. Fig. 20 As shown, computing device 2600 may include one or more processors (collectively referred to as 2602) with one or more levels of cache memory and memory controller, which may be configured to communicate with a storage subsystem 2606 including a main memory 2608 and a 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 described in the present disclosure. Storage subsystem 2606 also includes clock 2624. (One or more) processors 2602 may be used to provide the steps or functions of any embodiment described in the present disclosure.

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

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

[0493] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may serve as an interface to receive data from and transmit data to other systems other than the computing device 2600. For example, the network interface subsystem 2616 may enable a data technician to connect the device to a network so that the data technician may transmit data to and receive data from the device while being located at a remote location (e.g., a data center).

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

[0495] 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 device. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. One or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with an application that performs the described processes and variations therein, when such interaction is appropriate.

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

[0497] The computing device 2600 may be of various types, including a portable computer device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 via one or more ports (e.g., a USB, a headphone jack, a lightning connector, etc.). The device that may be connected to the computing device 2600 may include a plurality of ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted through the port connecting the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, Fig. 20 The description of the computing device 2600 depicted in FIG. 2 is intended only as a specific example for the purpose of illustrating a preferred embodiment of the device. Fig. 20 Many other configurations of the systems depicted with more or fewer components are possible.

[0498] It should be noted that the above embodiments illustrate rather than limit the present invention, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the present invention as defined by the appended claims. In the claims, any reference numerals in parentheses shall not be interpreted as limiting the claims. The words "comprising, comprise" and the like do not exclude the presence of elements or steps other than those listed in any claim or the entire specification. In this specification, "comprise" means "include or consist of", and "comprising" means "including or consist of". The singular form of an element does not exclude the plural form of such elements, and vice versa. The present invention may be implemented by hardware comprising several different elements and by a suitably programmed computer. In a device claim enumerating several components, several of these components may be implemented by one and the same hardware. The fact that certain means are recorded in mutually different dependent claims does not mean that a combination of these means cannot be used advantageously.< / app> < / app> < / app> < / app> < / txidparent> < / lzw> < / n> < / m> < / n> < / m> < / s> < / content> < / attributes>

Claims

1. A method performed by a computer-implemented system, the computer-implemented system being arranged to enable a user to search, access, view, write and / or retrieve portions of data provided or referenced from a target blockchain transaction on a blockchain, the method comprising the steps of: Using a blockchain detector, browser, or wallet, a target blockchain transaction on the blockchain is identified using a search path, the search path comprising: i) a unique transaction index, the unique transaction index comprising a combination of a public key associated with the target blockchain transaction and a transaction ID associated with the target blockchain transaction; and ii) a name attributed to the target blockchain transaction according to a blockchain-based search protocol.

2. The method according to claim 1, wherein: The target blockchain transaction includes at least one attribute.

3. The method according to claim 1 or 2, wherein: The unique transaction index includes: a hash of a function of the public key and the transaction ID. The method of claim 3 , wherein the function is a concatenation.

5. The method according to claim 2, wherein: The at least one attribute includes a mnemonic associated with the target blockchain transaction.

6. A method according to any preceding claim, wherein: The target blockchain transaction includes a protocol flag.

7. The method according to claim 6, further comprising the steps of: At least one blockchain transaction including the protocol flag is identified in the blockchain using the blockchain detector.

8. The method according to claim 6 or 7, further comprising the following steps: At least one blockchain transaction including the protocol flag is identified in the blockchain, and data related to the at least one blockchain transaction is stored in a resource outside the blockchain.

9. The method according to claim 8, wherein: The data related to the at least one blockchain transaction includes: at least one index associated with the transaction; at least one index associated with another transaction linked to the transaction; and / or Keywords associated with the transaction.

10. A method according to any preceding claim, wherein: The public key associated with the target blockchain transaction includes a human-readable prefix.

11. A computer-implemented system comprising: processor; as well as A memory comprising executable instructions, wherein the executable instructions, when executed by the processor, cause the system to perform any embodiment of the method performed by a computer-implemented system as described in any one of claims 1 to 10. 12 . A non-transitory computer-readable storage medium having executable instructions stored thereon, wherein the executable instructions, when executed by a processor of a computer system, cause the computer system to at least perform an embodiment of the method according to claim 1 .

Images