System and method for efficient and secure processing, access and transmission of data via blockchain network

Abstract

The present disclosure provides improved methods and systems for processing, storing, sharing, retrieving, writing, and accessing data (content) on a blockchain. The invention may form part of a protocol for storing, searching and accessing data. In particular, improved efficiency and enhanced access control permissions are provided. Embodiments of the present disclosure comprise the steps of: processing at least one blockchain transaction (Tx), the at least one blockchain transaction (Tx) comprising: a protocol flag; a freely decided public key (DPK); and a freely decided transaction ID (DTxID). They are freely decided in the sense that they do not need to be part of the base blockchain protocol but according to the invention. This combination of features enables portions of data to be identified, retrieved, and shared on a blockchain, and can also be linked / associated with each other when provided in multiple transactions. It enables the construction of a graph or tree structure that reflects the hierarchical relationship between the data portions, thereby facilitating their processing, searching and sharing.

Description

[0001] This application is a divisional application of the patent application with Chinese Application No. 201980078226.4 (PCT International Application No. PCT / IB2019 / 060226), filing date of November 27, 2019, and title of "Systems and Methods for Efficiently and Securely Processing, Accessing, and Transmitting Data via a Blockchain Network". Technical Field

[0002] The present disclosure generally relates to improvements in data communication and exchange across electronic networks, particularly peer-to-peer networks such as blockchain networks. It relates to data storage, access, retrieval, and processing, and particularly to such data-related activities on a blockchain. The present disclosure is particularly suitable for but not limited to use when processing data in a manner similar to that provided by websites and web pages, but using a blockchain as the underlying mechanism or platform instead of a web server. Accordingly, the present disclosure provides a secure, efficient, cryptographically implemented alternative infrastructure for data processing and transfer. It also provides technical solutions for controlling access to data stored on a blockchain, including improved permissioning and access control mechanisms for granting access rights to authorized users. It also provides advantageous embodiments that reduce the amount of time and computing resources required to locate and access data stored on a blockchain. Other technical advantages are also provided. 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 blockchain and transaction chain technologies, permissioned and unpermissioned ledgers, shared ledgers, and their variants. It should be noted that the present invention is not limited to use with a particular blockchain, and alternative blockchain implementations and protocols fall within the scope of the present invention. The term "user" may refer to a person or a processor-based resource in this document.

[0004] A blockchain is a peer-to-peer electronic ledger that is implemented as a computer-based decentralized distributed system consisting of blocks, which in turn consist of transactions. Each transaction is a data structure that encodes the transfer of digital asset control rights between participants in the blockchain system and includes at least one input and at least one output. Each block contains the hash value of the previous block, such that the blocks are linked together to create a permanent, immutable 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. On some platforms, these scripts are written using a stack-based scripting language.

[0005] To write a transaction to the blockchain, it must be "validated". Network nodes perform work to ensure that each transaction is valid, while invalid transactions are rejected by the network. The software client installed on the node performs this validation work on unspent transactions (UTXOs) by executing their locking and unlocking scripts. If the execution of the locking and unlocking scripts evaluates to TRUE, the transaction is valid and the transaction is written to the blockchain. Therefore, to write a transaction to the blockchain, it is necessary to: i) have the transaction validated by the first node that receives it - if the transaction is verified, that node relays it to other nodes in the network; ii) add the transaction to the newly constructed block; and iii) the transaction is mined, i.e., added to the public ledger of past transactions.

[0006] Digital entrepreneurs have started exploring the use of both cryptographic security systems and the data that can be stored on the blockchain to enable new systems. It would be highly beneficial if the blockchain could be used for tasks and processes. Such a scenario would be able to leverage the benefits of the blockchain (e.g., permanence of events, tamper-proof records, distributed processing, etc.) while having more uses in its applications.

[0007] One such area of concern is the use of the blockchain to store, share, access, and control data among users. Today, this is achieved via the Internet, where servers host websites and pages that users typically access via search engines to access the required data.

[0008] However, some observers have started envisioning the use of the blockchain to address certain drawbacks of the Internet, such as the control of large amounts of data and content by centralized parties. For example, see "Life After Google: The Fall of Big Data and the Rise of the Blockchain Economy", George Gilder, Gateway Editions, July 2018, ISBN-10: 9781621575764 and ISBN-13: 978-1621575764. Summary of the Invention

[0009] Accordingly, it is desirable to provide an arrangement that enables the advantageous use of the distributed, immutable, and permanent nature of a blockchain to store, process, retrieve, search for, and / or share such data on the blockchain. Such an improved solution has now been devised. Embodiments of the present disclosure provide at least alternative efficient and secure techniques for implementing a blockchain solution and for storing, processing, searching for, and / or retrieving data thereon or therefrom. Embodiments also provide at least an alternative technical infrastructure for a blockchain implementation for storing, processing, retrieving, transmitting, searching for, and / or sharing data between computing nodes. Since the present invention enables the use of a blockchain network in a new way and for providing improved technical results, the present disclosure provides an improved network for blockchain implementation.

[0010] Embodiments also provide a solution for securely controlling access to digital resources on technically different and improved computing platforms that include a blockchain and a blockchain protocol.

[0011] The invention is defined in the appended claims. According to the present disclosure, computer-implemented methods and corresponding systems can be provided. The method can be described as a method for enabling or controlling the processing, storage, retrieval, identification, and / or sharing of data via a blockchain. Additionally or alternatively, it can be described as a method for associating or linking data stored in (separate / different) blockchain transactions to enable the identification, retrieval, and / or sharing of the data.

[0012] According to one aspect of the present disclosure, a plurality of blockchain transactions are arranged in a (logical) hierarchy such that a portion of the data provided or referenced in at least one additional transaction in a lower level of the hierarchy can be accessed or identified by comparison with an encryption key used to sign a first transaction in a higher level of the hierarchy.

[0013] According to another aspect that can be used in combination with or separately from the first aspect, a first blockchain transaction can be used to control access to a portion of the data provided or referenced in at least one additional transaction in a lower level of a hierarchy of blockchain transactions based on the encryption key used to sign the first blockchain transaction. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] Figure 1 A blockchain transaction embodying the invention is shown in which data is stored in a plurality of outputs;

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

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

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

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

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

[0021] Figure 7 and Figure 8 A blockchain transaction embodying the present invention is shown for issuing tokens to allow access to data via atomic swaps;

[0022] Figure 9 and Figure 10 A blockchain transaction embodying the present invention is shown for exchanging Figure 7 and Figure 8 Tokens issued by transactions;

[0023] Figure 11 and Figure 12 shows the access by Figure 9 and Figure 10 The transaction is exchanged on a secret blockchain transaction;

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

[0025] Figure 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.

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

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

[0028] Figure 17 Illustrates an illustrative interaction between a local full - copy peer and a global full - copy peer according to an embodiment of the present invention.

[0029] Figure 18 Illustrates a meta - network tree (or graph) for use in reference to the illustrative use cases described below.

[0030] Figure 19 Illustrates a flowchart that illustrates the process embodied in the illustrative use cases provided below.

[0031] Figure 20 Is a schematic diagram showing a computing environment in which various embodiments may be implemented.

[0032] Figure 21 Illustrates an example logical data structure according to an embodiment of the present disclosure, which is used in techniques for enhancing the efficiency of data identification, access, and retrieval from transactions stored on a blockchain.

[0033] Figure 22 Illustrates a representation Figure 21 of the meta - network structure of the logical data structure. Detailed Description

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

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

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

[0037] Overview

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

[0039] These challenges may include, but are not limited to: how to locate a specific portion of data in the network; how to protect and control access to data so that only authorized parties can gain access; how to transfer data from one party to another in a peer-to-peer manner; how to arrange data such that it can be logically related but still stored in different locations within the network and subsequently how to combine it from different locations to provide 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, and how to improve the efficiency of such data-related activities on the network.

[0040] The present disclosure provides such an improved solution in a manner that is in some respects similar to the Internet, but uses a platform of hardware and software components that are completely different from those known in the prior art and achieves its results in a completely different way. 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 residing on a blockchain network. To achieve this, several innovations must be designed. These will be described in the following sections.

[0041] Insert data into the blockchain "Meta Network"

[0042] Referring to Figure 1 , a blockchain transaction embodying the present invention is shown, in which first data to be stored on the blockchain is stored in one or more first outputs of the transaction, and second data representing the attributes of the first data is stored in one or more second outputs of the transaction. One or more first parts <content1> of the first data are stored in the spendable outputs of the transaction. Data <attribute1> and <attribute2> representing the corresponding attributes of the first data and a flag indicating that the data is being stored according to the meta-network protocol are stored in the second non-spendable output of the transaction. The term "non-spendable" is used to indicate that at least one of the first and / or second outputs of the transaction may include a script opcode (OP RETURN) that is used to mark the output as invalid for subsequent use as an input to a subsequent transaction.

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

[0044] Figure 2 A blockchain transaction embodying the present invention is shown, in which 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 stored in the unspendable output of the transaction in a manner similar to Figure 1 the arrangement shown.

[0045] Data insertion

[0046] Data insertion method

[0047] It is desired to be able to insert the following data into the blockchain

[0048] a) Metanet flag

[0049] b) Attribute

[0050] c) Content

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

[0052] The following techniques can be used to embed this data into the blockchain script:

[0053] 1. OP_RETURN - In this method, all data (attributes and content) are placed after OP_RETURN in the locking script of a provably unspendable transaction output.

[0054] An example of an output script using this operator is as follows:

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

[0056] 2. OP_RETURN with OP_DROP - In this case, OP_RETURN contains attributes, and the content is stored before OP_DROP in the spendable transaction script (lock or unlock). The content can be split into multiple data packets in the transaction inputs and outputs. However, it is advantageous to insert the data into the transaction output because only the output script can be signed in some blockchain protocols. If the data is inserted into the transaction input, OP_MOD can be used as a checksum for the data instead of network node verification to ensure its validity. For example, a 32-bit OP_MOD operation can be performed and checked if it equals a pre-computed value.

[0057] In this case, the attributes can contain information on how to reconstruct the content data packets. Additionally, providing the hash of the reconstructed data packet H(content1 + content2) as an attribute enables verification that the recommended reconstruction scheme has been used.

[0058] Figure 1 A transaction implementing the second data insertion method is shown. For simplicity, the transaction only includes inserting the content in its output, which is signed by its single input. Using Figure 2 the method shown to use the OP_DROP statement can also insert the content into additional inputs.

[0059] If the content is large, it may be advantageous to split it across multiple transactions. Such an arrangement is shown in Figure 3 Figure. Figure 3 A pair of blockchain transactions embodying the present invention is shown, in which first data <content> to be stored on the blockchain is split into two chunks <content chunk1> and <content chunk2>, which can then be recombined as <content> = <content chunk1> || <content chunk2>, where the operator "||" concatenates the content data of the two chunks. This concatenation operator can be replaced by any desired bitwise or similar segmented binary operator. Then the two chunks <content chunk1> and <content chunk2> are stored in the respective spendable outputs of separate blockchain transactions, while data related to the attributes of the content data is stored in the respective unspendable outputs of the blockchain transactions. Again, the attributes can contain information on the recombination scheme. For example, the content can be raw data, an executable program, or an HTML web page. Additionally, content1 can include a pointer to the location of content2 on the blockchain, which functions in the same way as an embedded HTML link within a web page.

[0060] Note that two transactions will take the same public key P (and ECDSA signature) as input, such that although <Chunk 1 of content> and <Chunk 2 of content> are stored in different transactions with TxID1 and TxID2 respectively, they can be related by the same public key P.

[0061] Function of using network node verification

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

[0063] This ensures

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

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

[0066] This is especially beneficial for content split across multiple transactions because the input signature of P provides a provable link between the split components of the data, as described by the arrangement shown in the reference above Figure 3 as described.

[0067] Rabin signature

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

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

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

[0071] Note that this cannot be done in case (1) above, because in any case, the script containing OP_RETURN fails and thus verification cannot be achieved.

[0072] Specific example of using Rabin signature

[0073] Introduction

[0074] Digital signatures are a fundamental part of some blockchain protocols. It ensures that any transaction recorded on the blockchain has been authorized by the legitimate holder of the tokens being sent. In a standard P2PKH transaction, the transaction message is signed using the Elliptic Curve Digital Signature Algorithm (ECDSA). However, ECDSA signatures are typically applied to the entire transaction.

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

[0076] Now it will be shown how data can be directly signed and verified in a script by leveraging the algebraic structure of the Rabin cryptosystem.

[0077] Rabin Digital Signature

[0078] Rabin Digital Signature Algorithm

[0079] Background Mathematics

[0080] Definition - Integer mod p

[0081] The integers modulo p are defined as the following set

[0082]

[0083] Fermat's Little Theorem

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

[0085] a p-1 ≡ 1 mod p

[0086] Euler's Criterion

[0087] Let p be a prime number. r is a quadratic residue mod p if and only if the following holds

[0088]

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

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

[0091] a 2 ≡ r mod p

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

[0093]

[0094] Chinese Remainder Theorem

[0095] Given pairs of relatively prime positive integers n1, n2, …, n k and arbitrary integers a1, a2, …, a k , the system of simultaneous congruences

[0096]

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

[0098] if and only if

[0099] x ≡ r mod n1·n2, then

[0100] x ≡ r mod n1 and x ≡ r mod n2 Rabin Digital Signature Algorithm

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

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

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

[0104] To sign the message m, the signer selects padding U such that H(m||U) satisfies

[0105]

[0106]

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

[0108]

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

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

[0111] This is true if and only if there exists an integer λ in the range 0,…, n - 1 such that

[0112] H(m||U) + λ·n = S 2 (Equation 2).

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

[0114] The advantageous features of the Rabin signature scheme are as follows

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

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

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

[0118] Verification in the script is straightforward because it only requires squaring the given signature, performing modular reduction, and then checking whether the result is equal to H(m||U).

[0119] Rabin signature proof

[0120] Let p, q be relatively prime, and n = p·q. By the Chinese Remainder Theorem, it can be shown that

[0121] if and only if

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

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

[0124] then

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

[0126] Using the following equations

[0127]

[0128] it can be shown that

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

[0130] Therefore

[0131]

[0132] wherein it has been assumed that H(m||U) satisfies Euler's criterion. By similar calculations, it can also be shown that

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

[0134] Rabin signature in blockchain

[0135] Signature verification in script

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

[0137] OP_DUP OP_HASH160 <H 160 (n)> OP_EQUALVERIFY OP_MUL OP_SWAP OP_2OP_ROLL OP_CAT FUNC_HASH3072 OP_ADD OP_SWAP OP_DUP OP_MUL OP_EQUAL

[0138] where n is the signer's public key. This will evaluate to true if and only if the following inputs are available

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

[0140] where m is any 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:

[0141] OP_DUP OP_HASH160<H 160 (n)>OP_DUP OP_TOALTSTACK OP_SWAP<roll index>OP_ROLL OP_CAT FUNC_HASH3072 OP_SWAP OP_MOD OP_SWAP OP_DUP OP_MUL OP_FROMALTSTACK OP_MOD OP_EQUAL

[0142] In this case, this will evaluate to true if and only if the following inputs are present

[0143] <s> <m> <n>

[0144] In both of these exchange 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:

[0145] OP_SHA256{OP_2OP_SPLIT OP_SWAP OP_SHA256 OP_SWAP}(x11)OP_SHA256 OP_SWAP OP_SHA256{OP_CAT}(x11)

[0146] Data compression

[0147] Internet data consists of JavaScript and common file types (e.g., text files (SML, HTML, etc.), video files (MPEG, M-JPEG, etc.), image files (GIF, JPEG, etc.), and audio files (AU, WAV, etc.)), for example, as described in more detail at the following link: https: / / www.doc.ic.ac.uk / ~nd / surprise_97 / journal / vol1 / mmp / #text . Using the above data insertion techniques, these different data types can also be embedded on the blockchain.

[0148] Before embedding a larger file size on the blockchain, it can be compressed using one of several existing coding 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.

[0149] Depending on the specific input data, there are many different algorithms. Apple Lossless and Adaptive Transform Acoustic Coding can be used to compress audio files, PNG and TIFF for 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 for the LZW lossless coding scheme in the attribute would be <lzw>。

[0150] Encryption and decryption of payment

[0151] Data encryption

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

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

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

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

[0156] When encrypting data stored on the blockchain, there are advantages to using the same cryptographic system as the underlying blockchain. This can be the secp256k1 convention for ECC key pairs in asymmetric cryptography, and the SHA-256 hash function in symmetric cryptography. These advantages are:

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

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

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

[0160] - Since the same key can be used for encryption and payment, it is more efficient and thus fewer keys are required. This also reduces storage space.

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

[0162] - Since the keys used for encryption and transactions are the same data structure, security is enhanced, thus mitigating targeted attacks against specific key types.

[0163] For illustrative purposes, a description is given of how the Koblitz algorithm can be used to encrypt data using ECC.

[0164] Koblitz algorithm

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

[0166] Suppose it is desired 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.

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

[0168] 2. Then the point P m is encrypted using the public key P1. This is achieved by choosing a random temporary key k0 and calculating the pair of points C m = {k0·G, Q} (where Q := P m + k0·P1), and then this pair of points can be broadcast.

[0169] 3. The owner of the private key S1 can decrypt the original point by calculating P m = Q - S1·k0·G. Then, they can 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.

[0170] Use blockchain to purchase license Z

[0171] Storing data on the blockchain has the distinct advantage of having a payment mechanism built into the system. Payments can be used to purchase

[0172] - decrypt data for viewing / use

[0173] - permission to insert data at a specific address

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

[0175] An efficient and secure way to make this purchase is to use an atomic swap. This keeps the secure communication channel minimal and ensures that payment is made to the seller and the secret is revealed to the buyer, or that nothing happens.

[0176] It is also convenient to use an access token to purchase the permission. This is a secret value (usually a hash preimage) that the buyer has and can use to make the purchase. The buyer can purchase a large number of such access tokens in advance and then activate them when they actually want to use the permission.

[0177] Now we will refer to Figure 4 and Figure 5 to describe how to perform an atomic swap.

[0178] Atomic swap using hash puzzle or private key puzzle

[0179] Suppose Alice is the owner of the secret. The secret can be a hash preimage of a known hash digest or a private key of a known public key. Suppose Bob wants to use a token to buy the secret from Alice. Describe the mechanism called atomic swap that enables this transaction to occur. This is atomic in the sense that either Alice gets paid the token and reveals the secret to Bob, or nothing happens.

[0180] The method is as follows:

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

[0182] Alice has the secret that is either the preimage X of a known hash digest H(X) or the private key S1 of a known public key P1 = S1·G.

[0183] They agree that Alice will sell the secret to Bob at the token price.

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

[0185] Now refer to Figure 4 ,

[0186] 1. Bob transfers the token locked by the following redemption script R (written schematically) to Alice:

[0187] For the hash preimage:

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

[0189] This forces the preimage X to be exposed in the input of the redemption script.

[0190] For the private key:

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

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

[0193] 2. Since Alice knows her secret (X or S1), she can spend her funds on the blockchain with the help of Figure 5 the transactions shown. This enables Bob to determine her secret.

[0194] 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 achieved in the manner outlined in International Patent Publication No. WO 2017 / 145016. In this case, S can be added to the preimage X in the hash puzzle so as not to publicly disclose X on the blockchain. Similarly, in the private key puzzle, S can be used as the temporary key k0 to ensure that only Alice or Bob can compute the private key.

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

[0196] Purchase using token

[0197] Suppose the same situation as described above exists, but Bob wishes to redeem an access token purchased in advance in exchange for the secret.

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

[0199] Phase 1: Token issuance

[0200] ​​The token issuance phase is actually Bob's single purchase of tokens. For example, consider the following scenario: Alice has 10 different secrets X1, X2, …, X 10 , and Bob wishes to purchase 10 tokens T1, T2, …, T 10 that each grant him access to the corresponding secret.

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

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

[0203] Alice and Bob now each have 10 secret values that can be revealed in a hash puzzle for, e.g., redeeming tokens. However, to issue these tokens, they must also generate secret initialisation values I Alice and I Bob . These values are given as follows:

[0204]

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

[0206] It should be noted that Alice's initialiser is simply a random integer with no specific meaning, but Bob's initialiser should be the hash of his first token T1 = H 9 (Y). Extending the token chain to the initialisation value in this way allows token issuance to also define the tokens to be used for successive redemption later. Figure 6 All the secret values held by each participant are shown in

[0207] Now Alice and Bob can agree to purchase 10 tokens at a price of 10 units. The purchase of these tokens can be done in various ways, and here atomic swap is used for illustration. The atomic swap starts with Alice and Bob broadcasting the transactions shown in Figure 7 and Figure 8 respectively, where the output in both transactions requires the solution of two hash puzzles and a valid signature.

[0208] Once the two transactions appear in the blockchain, Alice and Bob can share their shared initialisation values I Alice and I Bob , and complete the atomic swap for token issuance.

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

[0210] Phase 2: Token Exchange

[0211] At some future point, Bob wants to exchange his first token T1 = H 9 (Y) and receive his first secret X1, but as previously mentioned he has already paid for this secret by purchasing a valid token. The process of exchanging the token will take the form of another atomic swap, where the solution to the locked hash puzzle is the token T i and the corresponding secret X i .

[0212] To exchange his token, Bob should broadcast the transaction shown in Figure 9 , the output of which is locked with two hash puzzles. When Alice sees this transaction, she broadcasts her own similar transaction as shown in Figure 10 , the output of which is locked with the same two hash puzzles. The two participants can now exchange their secrets T1 and X1 and unlock the outputs of these transactions. The two parties can now exchange the nominal fee x by providing the correct unlocking scripts that also expose the two secrets. Figure 11 and Figure 12 show the transactions with these unlocking scripts.

[0213] The completion of this atomic swap for token exchange reveals Alice's first secret X1 to Bob, reveals Bob's first token T1 to Alice, and given that the amount x is large enough to encourage both parties to spend the locked output, there is a net zero exchange of funds. Crucially, this also establishes that the next token Bob can use must be the solution T2 of the hash puzzle [hash puzzle H(T2)], where the target hash H(T2) = T1 has just been revealed to Alice. This process can be recursively repeated until Bob has used his last token T 10 = Y.

[0214] Naming and addressing

[0215] Node and edge structure

[0216] It has been explained above how data can be inserted into the blockchain by providing data within a transaction. Now presented is a protocol for structuring these transactions in a logical manner that allows for node addressing, permissioning, and content version control. The protocol also enables the creation of a hierarchy of data transfer transactions. The structure of the distributed peer-to-peer metanet is similar to the existing Internet.

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

[0218] The goals of the structure described herein are:

[0219] (i) To associate relevant content in different transactions to enable searching, identifying, and accessing of data, and to allow the logical hierarchy of related parts of the data to be reflected in the transactions on the blockchain

[0220] (ii) To allow the identification of content using human-readable keyword searches to improve search speed, accuracy, and efficiency

[0221] (iii) To construct and simulate a server-like structure within the blockchain

[0222] Our approach is to structure the data associated with the metanet as a directed graph. The nodes and edges of the graph correspond to:

[0223] Nodes - Transactions associated with the metanet protocol. Nodes store content. (The terms "content" and "data" are used interchangeably within this document).

[0224] Nodes are created by including an OP_RETURN just before <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 ).

[0225] The hash function used should conform to the underlying blockchain protocol that the present invention will use, such as SHA-256 or RIPEMD-160.

[0226] Edges - The association of child nodes with parent nodes.

[0227] Edges are in the signature Sig P parent Created when it appears in the input of a meta-network 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 in-degree of each node is at most 1, and the out-degree of each node is arbitrary.

[0228] Note that an edge is an aspect of the meta-network protocol and is not itself a transaction associated with the underlying blockchain.

[0229] A valid meta-network node (with a parent) is given by a transaction of the following form:

[0230]

[0231] This transaction contains all the information required to specify the indices of the node and its parent:

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

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

[0234] In addition, since the signature of the parent node is required, only the parent can create an edge to a child. If the <TxID parent > field does not exist or it does not point to a valid meta-network transaction, the node is an orphan. There is no higher-level node that can reach it.

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

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

[0237] a) public key P node , which we interpret as the address of the node

[0238] b) transaction ID TxID node , which we interpret as the version of the node

[0239] This structuring gives rise to two favorable features:

[0240] 1. Version control - If there are two nodes with the same public key, we interpret the node with the transaction ID that has the maximum 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).

[0241] 2. Permission - A child node of a node can be created only if the owner of the public key P node signs the transaction input when creating the child node. Thus, P node represents not only the address of the node but also the permission to create a child node. This is intentionally similar to a standard blockchain transaction - the public key is not only an address but also the permission associated with that address.

[0242] It should be noted that since the signature of the parent node 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 a child node is verified by the blockchain network itself. The permission and access control aspects of the present disclosure are described in more detail below, as well as mechanisms for enhancing these technical benefits.

[0243] It is worth noting that a standard Internet Protocol (IP) address is unique within a network only at a given point in time. On the other hand, the index of a node in the metaweb 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 .

[0244] The node and edge structure allow the metaweb to be visualized as a graph, as Figure 13 shown.

[0245] Enhanced scheme for efficient data location and retrieval

[0246] Similar to the Internet, the metaweb provides a technology platform and infrastructure for storing and accessing large amounts of data. It is highly desirable to perform this operation in such a way that data can be identified and accessed in an efficient and timely manner, otherwise the system may become impractical for use because it takes too long or requires too many resources (e.g., energy and computing devices) to locate and retrieve what the user needs. This is especially important for arrangements implemented on a peer-to-peer, decentralized architecture (e.g., blockchain).

[0247] To further improve efficiency, embodiments of the present disclosure described herein may include a hierarchical data architecture, which is implemented via relevant transactions on the blockchain. Figure 21 And 22 show simple examples where such an enhancement is implemented according to Figure 22 in Figure 21 Exemplary logical data structures. Figure 22 Can be implemented using the naming and addressing techniques described herein and other techniques to build multiple associated transactions that include or reference various data portions that are related in a logical hierarchy.

[0248] Data can be organized in a hierarchy at the same logical level. The logical level and hierarchy can be specified, influenced, or determined based on the needs of entities such as institutions, enterprises, computing networks, data stores, or other types of entities that need to store (potentially large amounts of) data related to the items with which they interact, provide, or use. For example, within a company, an employee can have a name, address, DoB, etc., or a shareholder can have an associated name, shares, and history, etc. Instead of storing information related to these data types in a transaction at the same hierarchical level of the meta-network structure (as shown by the solid boxes on the right side), they can be stored and arranged at different hierarchical levels, as shown by the solid boxes of Figure 21 The order of the levels is not related to the functionality of the scheme. Figure 22 As shown.

[0249] For example, at level n, a transaction can store the name of a shareholder, and at level n+1, a transaction can store the shares of the shareholder, and so on. A mapping is stored and maintained that provides a mechanism for determining the hierarchical level at which different data types are stored. The mapping can be stored on or off the blockchain in any suitable form. Thus, a user who wishes to locate and retrieve a specific type of data (e.g., shareholder, shareholder history) can use the mapping to inform them which level of the meta-network they need to go directly to. In other words, the depth of the structure provides an indication of the type of data stored there (level n+1 = shareholder share data). A query can be performed based on the determination of which key signed the transaction being examined.

[0250] Consider Figure 21 , which shows a logical data structure that includes data stored in a hierarchy at various logical levels LL-01 to LL-06, and compare it with Figure 21 And Figure 22 For comparison, Figure 22 Shows a meta-network structure that represents the same data structure according to such an embodiment and is implemented on the corresponding blockchain level "BL". Transactions can be generated according to the meta-network protocol techniques described herein. It can be seen that data at the same logical level (e.g., LL-03 in Figure 21 ) can be stored in Figure 22 In the different levels of transactions within the meta-network system shown. If the user knows the mapping, they can go to the transaction at level BL-05 to find the history of the shareholders, without having to traverse the previous transactions to locate the required data. Regardless of the amount of data stored in the entire system, this enables faster results to be provided to the user, facilitates the scalability of the implemented solution, and reduces the computing resources required for data identification and access from the peer-to-peer network. The mapping records and stores the relationship between the items in the hierarchy and the levels at which the data types are stored. Using the indexing technique of the protocol, a hierarchy / graph of the associated transactions is generated. When the user wishes to access a specific type of data (e.g., shareholder name), the mapping is referenced to obtain an indication of the level at which the data type is stored, and then the transaction at that level can be quickly and efficiently accessed to obtain the required data. The mapping can be stored on-chain or off-chain in any suitable manner.

[0251] Enhanced license and access control

[0252] In addition to the license-related advantages discussed above, the control- and security-related aspects of the present disclosure can be further enhanced by organizing, storing, identifying, and retrieving data based on a hierarchy. In such a hierarchy, the data is stored as pairs of related categories and instances. For example, at level n in the hierarchy, a transaction will store an indication of a certain type or class of data ("type" or "category") that is stored at level n+1. Then, the transaction at level n+1 stores an instance of that data category. At level n+2, the transaction stores an indication of a different type of data that is stored at level n+3, where the transaction at level n+3 stores an instance of that data type. In effect, the transactions at levels n and n+2 act as headers, while the transactions at levels n+1 and n+3 store the actual data. The advantage of this is that we can prove how many instances exist in a category by disclosing the least amount of information (i.e., the headers). Each instance transaction is signed by the same public key, so the administrator or owner can provide that public key to an authorized party, enabling them to identify from an inspection of the blockchain how many transactions were signed with that public key.

[0253] This is illustrated in Figure 21 and 22 which provides a simple example of how this is achieved, where the instance transactions are dependent on the category transactions. Figure 21 and 22

[0254] Figure 21 For purposes of comparison and explanation, Figure 21 Shows the hierarchy of data items that can be achieved using embodiments of the present disclosure described herein in the absence of an additional enhanced access control mechanism. The items on the left side of the hierarchy (dashed boxes) are shown at logical levels LL-01 to LL-06. The number of annual leave days taken by an employee is stored as a data item in LL-06. To determine how many days of annual leave a particular employee has taken, the user needs to disclose the "Annual Leave" transaction at LL-05, as the annual leave transaction has been signed by an encryption key that provides access to the transactions provided below it in the hierarchy. (Recall that the party having the key to access LL05 can use that key to access data at all levels below, but not data at higher levels (i.e., LL-04 or higher)). However, the drawback of doing so is that LL-05 may contain data that the owner does not wish to disclose. For example, sensitive or secret data may be stored at that level, or data that the owner does not wish to share with the access party for some other reason. Therefore, an enhanced degree of access control is needed, which can allow the data owner / controller to protect the data in the blockchain in an improved and more fine-grained manner.

[0255] Turning to Figure 22 the improved access mechanism shown, which is implemented using transactions formed according to the meta-network protocol described herein, we see that a new P node has been inserted into the hierarchy at blockchain level (BL) 06 between the "Annual Leave" transaction at BL-05 and the transaction at BL-07 that includes the actual data of the days taken. Thus, the BL-05 transaction introduces a permission control or key provision mechanism that prevents any party granted level BL-06 and below from accessing other data stored higher up in the structure. In our simple example, only the "Annual Leave (Taken)" transaction at BL-06 needs to be disclosed by providing the key for BL-06 to the authorized party so that they can calculate the number of days taken so far. More complex arrangements can be designed to provide subtly different permission levels and access rights to different authorized users, and for the purpose of partitioning data stored across multiple non-adjacent blockchain transactions, thereby achieving a more flexible and usable data storage facility on the blockchain.

[0256] The permission control node at BL-06 may or may not include additional data or metadata.

[0257] Domain, naming and location content in Meta Network

[0258] The hierarchy of the meta-network graph allows for the emergence of rich domain-like structures. We interpret orphan nodes as top-level domains (TLDs), the children of orphan nodes as subdomains, the grandchildren as sub-subdomains, etc., and childless nodes as end-points. See Figure 13 。

[0259] Domain names are translated into IDs node 。Each top-level domain in the meta-network can be regarded as a tree, where the root is an orphan node and the leaves are nodes without children. The meta-network itself is a global set of trees that form a graph.

[0260] The meta-network protocol does not specify that any node contains content data, but the leaf (childless) nodes represent the ends of the directed paths in 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 nodes can be used to specify the role of the nodes in the data tree (disk space, folder, file, or permission to change).

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

[0262] We assume the existence of a decentralized index ID that maps human-readable top-level domain names to root nodes root of an equivalent distributed system. In other words, there exists a one-to-one function κ that maps human-readable names to the meta-network root node index, e.g.:

[0263] κ('bobsblog') = ID bobsblog (= H(P bobsblog ||TxID bobsblog ))

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

[0265] The mapping k should be interpreted as a measure to ensure backward compatibility between the meta-network and the Internet when replicating the human readability of domain names published by DNS, but the naming and addressing scheme that provides the structure of the meta-network does not explicitly depend on this mapping.

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

[0267] The public key used as the address of a metanet node is not a human-readable object. This can make the search, reference, and input activities of human users error-prone and slow. However, a human-readable public key address can be created, which includes a plaintext prefix that can be directly interpreted by the user.

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

[0269] An example of a human-readable address with the required prefix is:

[0270] P bobsblog :bobsblogHtKNngkdXEeobR76b53LETtpyT

[0271] Prefix:bobsblog

[0272] Suffix:HtKNngkdXEeobR76b53LETtpyT

[0273] The above human-readable address can be used to sense-check the mapping from the name 'bobsblog' to the node index ID bobsblog and assist the metanet node through the searchability of the address. It should be noted that the prefix is not unique here, but the entire address itself is a unique entity.

[0274] The selected address P vanity combined with the TxID to form the ID node is also beneficial because this means that there is no central publisher of domain names (TxIDs are generated by decentralized proof-of-work), and the name can be recovered from the blockchain itself. Advantageously, there will no longer be a single point of failure as exists within the Internet DNS.

[0275] Since the meta-domain already provides a licensing system (public key), there is no need to issue credentials to prove ownership. Using a blockchain for this purpose has been explored. However, according to the present invention, there is no need to use a separate blockchain for this function because everything can be achieved within one blockchain.

[0276] Compared with the prior art, this significantly reduces the amount of resources (hardware, processing resources, and energy) required by the present invention. In terms of the arrangement of device and system components, it also provides a completely different architecture.

[0277] The advantage of this naming system is that users can identify top-level domains in the meta-network by memorable words (e.g., company names) instead of hash digests. This also makes domain searching faster because search keywords are faster than hash digests. This also reduces input errors, thus providing an improved search tool for data stored in the blockchain.

[0278] Given the mapping from domain names to node indices, we can establish a resource locator similar to the Uniform Resource Locator (URL) of the Internet. We call this the meta-network URL (MURL), and it has the following form

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

[0280] Each component of the URL - protocol, domain name, path, and file - has been mapped to the structure of the MURL, making the object more intuitive to users and enabling it to be integrated with the existing structure of the Internet.

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

[0282] The following table gives the analogy between the meta-network protocol and the Internet protocol:

[0283]

[0284] Table: Summary of the analogy between Internet protocols and meta-network protocols

[0285] Search Meta Network

[0286] We have defined the meta-web graph structure of the exemplary embodiments such that each node has a unique index and may have a name attributed to it. This allows content to be located using a MURL. To also implement a fast search function, we allow additional keywords to be attributed to nodes.

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

[0288] Node attributes

[0289]

[0290] In one example, a utility method for searching the meta-web could be to first trawl through the blockchain using a block detector and identify all transactions via the meta-web flag, check if they are valid meta-web nodes, and if so, record their indices and keywords in a database or other storage resource. The 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 detector and viewed.

[0291] For example, consider Figure 14 branch P1, where the nodes corresponding to public keys P0, P1, and P 1,1 represent the home page, the topic page, and the sub-topic page, respectively. These nodes are given the names 'bobsblog','summer', and 'caribbean', and their attributes are as follows:

[0292] Home page node P0

[0293]

[0294] Topic page node P1

[0295]

[0296] Sub-topic page node P 1,1

[0297]

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

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

[0300] The naming and addressing methods described above provide numerous technical advantages over the prior art, including:

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

[0302] 2. Decentralized domains - The publication of domain names is fully decentralized by including only TxIDs generated by proof-of-work. Domain names can also incorporate human-readable public keys P that implement the fair distribution of the required domain public keys. node vanity Again, this solution provides enhanced efficiency and security.

[0303] 3. Graph structure - The naming and addressing architecture specifies a graph that can be constructed from a subset of the blockchain data including Metaweb nodes. This design uses an ordered structure to map the complexity of the Internet onto the blockchain, such that the blockchain fully replicates its functionality and scalability while maintaining security.

[0304] Browser wallet application

[0305] As previously described, in the Metaweb protocol, all data exists directly on the blockchain itself. In this section, we provide an example of an illustrative computer application that can effectively access, display, and interact with the Metaweb data stored on the blockchain, referred to herein for convenience as the "browser wallet".

[0306] We will first discuss how the browser wallet interfaces with the core components and functionality of the distributed peer-to-peer Internet, and then provide a more detailed description for the remainder of this section.

[0307] Overview

[0308] Components

[0309] The browser wallet is an application designed to allow end-users to interact with the Metaweb infrastructure on the blockchain. This application should allow for exploratory searches of the Metaweb graph to find specific content embedded in the tree. Additionally, the browser wallet will handle the retrieval, decryption, recombination, and caching (optional) of content.

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

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

[0312] Display window - Software that unpacks the content returned from the full - copy blockchain peer to the browser. This covers the decryption, recombination, caching, and redemption of access tokens.

[0313] Wallet - Special - key management of the assets (such as currency) of the blockchain. It can be application - local or authorized to communicate and synchronize with external wallets (software or hardware). It is capable of writing standard blockchain transactions as well as new MetaNet node transactions. It can mediate on - chain purchases of access keys and access tokens.

[0314] Hierarchical deterministic key management can be used for both public keys and MetaNet node addresses simultaneously.

[0315] Access key / token wallet - Special - key management of the access keys or tokens used for purchases. The wallet can be used to receive the keys or tokens for purchases, but does not have permission to the keys or tokens. The keys or tokens can be hidden from the user to allow for later expiration. This can be achieved by using a trusted execution environment. Timed access can be guaranteed by synchronizing with the blockchain and querying the current block height.

[0316] Functionality

[0317] The specification of the MetaNet browser wallet ensures the following functions of the application.

[0318] 1. Hierarchical key management - The keys used to control funds and manage the MetaNet tree (diagram) utilize the same hierarchical deterministic key infrastructure, thus reducing the burden on users to maintain the key records of their MetaNet content.

[0319] 2. Pointing to external wallets - The ability to authorize and synchronize with external (non - application - local) wallets allows for additional security by removing the browser wallet as a point of failure.

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

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

[0322] The search engine can provide node indexing for the browser wallet, which allows data to be found.

[0323] 4. Read and Write Data to the Blockchain - In addition to using the search engine and full nodes to provide content for the browser, support for the wallet also allows content to be written directly from the browser wallet to the Metaweb.

[0324] 5. Decompression and Decryption of Data - The browser wallet processes the decryption key and can perform decompression on Metaweb content in situ.

[0325] 6. Cache Node Identity (ID node ) - The unique node identity can be cached locally for more efficient lookup and query.

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

[0327] This means that the user's browser wallet only needs to query a single peer, which can be done directly without an intermediate network server.

[0328] Figure 15 A schematic diagram of the browser wallet is shown, as well as how to split its core functions among different components of the application.

[0329] Blockchain search engine

[0330] Search Engine – Prior Art

[0331] 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 Metaweb).

[0332] The SE searches for relevant HTML meta tags and content by keywords in the query. Subsequently, the crawl results are indexed, where any embedded image / video / media files are analyzed and cataloged. Then, the most relevant results in the index are programmatically rated considering the user's location, language, and device.

[0333] Typical SEs should have the following functionality:

[0334] 1. Crawling - Identify Internet data and crawl it with relevant metadata such as domain names, linked pages, and relevant keywords. Discover new Internet content through existing content and also crawl for any relevant information.

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

[0336] 3. Serving and rating - Rate the content index in order of relevance to user queries.

[0337] Block explorer

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

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

[0340] Block explorers, while varying in capabilities, are generally useful for cataloging transactions in a user-friendly extractable form and displaying their basic information - for example, addresses. Many explorers also allow viewing of the individual inputs and locking scripts of a transaction, although there is an inconsistency between these explorers and more advanced sites (e.g., Blockchair https: / / blockchair.com / ) in how they present this information.

[0341] Recently, there have been many extensions to the basic blockchain explorers 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 ) catalog and organize blockchain transactions containing specific protocol identifiers, as well as display the data encoded within those specific transactions, in the same way as block explorers.

[0342] However, there are two important problems with using blockchain explorers, which embodiments of the present invention solve:

[0343] 1. General - There is currently no industry standard for browsing content data stored in transactions. Content data refers to any data that does not relate to the protocols used to create and secure the underlying blockchain.

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

[0345] Importantly, as described above, the powerful naming and addressing structure of the present invention facilitates and enables the construction of a blockchain explorer that is more complex than those known in the art.

[0346] Proposed Meta Network search engine

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

[0348] The meta-web search engine third party maintains a database of all meta-web transactions mined into the blockchain that are identifiable by meta-web protocol flags. This database can catalog all meta-web nodes through a range index that includes ID node , node names, keywords, TxID, and block height.

[0349] There are already services that continuously synchronize with the blockchain and maintain transaction data in a standard database format. The browser wallet transfers the responsibility for crawling, indexing, serving, and rating meta-web transactions to this third party and connects to its service when locating content stored on the meta-web graph.

[0350] Efficiency can be saved by having a database dedicated solely to meta-web data. This database will not store data associated with all transactions, but only those that contain meta-web flags. Some databases, such as non-relational databases like MongoDB, may be more efficient at storing the graph structure of the meta-web. This will allow for faster queries, lower storage space, and more efficient correlation of related content within the meta-web domain.

[0351] Figure 16 Illustrates how the browser wallet interacts with a third-party search engine when a user searches for content within the meta-web infrastructure. Importantly, it should be noted that, in contrast to the Internet, there is no need for routing, and thus the present invention provides significant advantages in terms of efficiency, speed, processing, and resources required.

[0352] The process is as follows:

[0353] 1. The end user enters a keyword in the search bar of the browser wallet.

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

[0355] 3. The SE checks the keyword against its database and returns the IDs of any metanet nodes containing relevant content node . The third party may also return additional indices on each node to the user, as well as provide suggestions for relevant content.

[0356] 4. The browser wallet constructs an MURL using the node identifier and the domain name associated with it.

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

[0358] 6. The network peer provides the requested content to the browser wallet. Since 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.

[0359] It should be emphasized that the third-party SE is only responsible for indexing and maintaining the property records of the metanet nodes, while the original content data stored on the nodes is stored by network peers (e.g., full-copy peers, archives) having a full copy of the blockchain.

[0360] Content display – Meta Network browser

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

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

[0363] 2. Retrieve - Communicate with the server to facilitate the transfer of content using known protocols (e.g., Hypertext Transfer Protocol (HTTP)).

[0364] 3. Interpret - Parse the original code (e.g., in JavaScript) and execute it.

[0365] 4. Render - Efficiently display the parsed content for the end user to view.

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

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

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

[0369] Reorganization, decompression and decryption

[0370] According to certain embodiments of the present invention, a web browser software component of a browser wallet application is capable of handling all operations that need to be performed on a given piece of meta-web content. Generally speaking, 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 meta-web protocol and infrastructure.

[0371] Reassembly - In the case where meta-web 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 sorting and structure of fragmented content can be encoded using additional flags in the attributes of each node.

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

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

[0374] 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 a suitable <operation_flag> can be included as part of the attributes of the node to which the operation is applied.

[0375] Cache

[0376] Caching of local files and cookies is a common and important function of a typical web browser. The browser wallet application also uses local storage in a similar way to optionally save records of IDs node and other node attributes related to the content of interest. This allows for more efficient lookup and retrieval of content from frequently accessed meta-web nodes.

[0377] The Meta Web solves the inherent problem of caching Internet data, which is variable and can be changed or deleted by web browsing software according to the provider. When caching Meta Web 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.

[0378] Hierarchical deterministic key management

[0379] The deterministic key Dk is a private key initialized from a single "seed" key. The seed is a randomly generated number that acts as the master key. A hash function can be used to combine the seed with other data (e.g., an index number or "chain code") to derive the deterministic key. These keys are related to each other and can be fully restored from the seed key. If a user wishes to use an external wallet in combination with the Meta Web browser wallet, the seed also allows for easy import / export of the wallet between different wallet implementations, thus giving additional freedom.

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

[0381] In a preferred embodiment, the HD wallet can be incorporated into Figure 16 the Meta Web architecture shown. The advantages of using an HD wallet include:

[0382] 1. Structure Different branches of the child keys can be used for different purposes to express additional organizational meanings. For example, a user can dedicate different branches (and their corresponding child keys) to different types of data.

[0383] 2. Security A user can create a series of public keys without the corresponding private key, thus giving the HD wallet the functionality of being a receive-only wallet and being suitable for use on an insecure server. Also, since fewer secrets need to be stored, the risk of exposure is lower.

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

[0385] Local (internal) and external wallet support

[0386] Advantageously, embodiments of the present invention can directly incorporate the functionality of a conventional web browser and one or more wallets. Fundamentally, this is how the Meta Web combines payments for "Internet" content with its delivery to end users.

[0387] To achieve this, embodiments of the browser wallet can have a dedicated built-in software component that serves as the wallet. The wallet is local to the application itself and can be used to manage private keys and authorize transactions for payments for metaweb content within the browser wallet itself.

[0388] 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 metaweb content. The application does not need to call an external third party to process the payment, so the metaweb content of interest is consumed by the application and paid for in place.

[0389] External Wallet

[0390] If the user wishes to manage or save their private keys on an external wallet (software or hardware) or even use multiple wallets, the same advantages and functionality can be achieved through embodiments of the application. This can be done in lieu of or in combination with the application's local wallet.

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

[0392] Read and write Meta Network transactions

[0393] The essential advantage of the metaweb is that it uses the same data structure - the blockchain - to record both payment and content data. This means that software wallets can also be used to write content data to the metaweb infrastructure.

[0394] The local wallet built into the application is capable of writing transactions to the blockchain, which are more complex compared to a typical Simplified Payment Verification (SPV) client. The wallet allows the user to choose to write metaweb node transactions directly from the application to the blockchain by selecting content data from their computer to be embedded in the blockchain.

[0395] Since the browser wallet application has a user interface (UI), it allows the wallet component to create and broadcast a transaction that includes content data that has been pre-constructed in the browser component or on the user's computer. It would be very difficult for a specially configured wallet that processes on its own to achieve this functionality.

[0396] Access key / token wallet

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

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

[0399] 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 access keys / tokens be stored in a trusted execution environment (TEE) and that the user not have direct access to the access keys / tokens.

[0400] The fact that access keys / tokens can be "burned" is also a motivating factor for not storing them in a wallet to ensure there is no risk of a private key being burned.

[0401] In a manner similar to 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 addition to a master key, while access tokens can be reconstructed using a hash chain seeded by some initial token.

[0402] It is important here to distinguish between the deterministic key generation of the wallet handling key pairs, which are used for transactions with other users and creating new MetaNet nodes, and the key / token wallet handling keys and tokens that have been purchased by the wallet.

[0403] Block height permission

[0404] Time locks can be included in the script language to implement block height permission. The op_code OP_CHECKLOCKTIMEVERIFY (CLTV) sets the block height at which a transaction output (UTXO) can be spent.

[0405] The advantages of block height permission are twofold:

[0406] 1. Version control - In the MetaNet protocol, the latest version of a node can be identified from the maximum block height. Browser wallets can be set to display only the most recent version of a file by block height, thus implementing proof-of-work version control.

[0407] 2. Timed access - The browser wallet application can periodically burn the decryption keys purchased atomically by the user. This ensures that the viewer can access the content data only during the period for which they have made a payment. Cloning of the decryption keys can be prevented by storing them in a trusted execution environment (TEE). Additionally, the atomic swap involves the purchase of a deterministic key Dk (for decrypting the content data). Although this deterministic key is publicly visible, the TEE can be used to sign the combination of Dk with the securely enclaved private key.

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

[0409] Bypass network server

[0410] The present invention allows for a new mechanism for a browser (client) and a web server to communicate and exchange information through distributed peer - to - peer Internet communication bypassing the domain name system (DNS) server and typical network routers. See http: / / www.theshulers.com / whitepapers / internet_whitepaper / The present invention provides a new network architecture including peers that maintain a full copy of the blockchain, from which content can be provided to the browser wallet application.

[0411] Local full-copy peer

[0412] Consider a system of local peers in each geographical area (e.g., postal district, town, city). We assume that within this local area network, at least one peer maintains a full copy of the blockchain, which we call the 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.

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

[0414] In the simplest case, each LFCP will have the same storage and disk space overhead, as each will need to be able to store the entire blockchain (about 200GB when written). The difference between each LFCP is that the LFCP should expand its capabilities to respond to the requirements of local requests from Metaweb users. Thus, if by default every Metaweb user in the world queries their closest LFCP, each LCFP should strive to expand its operating capabilities to meet its local requirements. Populated areas such as cities will require LFCP operations that include many cluster servers, while sparsely populated areas such as small towns will require fewer LCFP operations.

[0415] It is important to note that the disk space requirements are universal, while the CPU requirements for each LFCP adapt to the local area network needs. This is an example of an adaptive network, for example, Freenet - see https: / / blockstack.org / papers / 。

[0416] One advantage of such a system is that when retrieving content associated with a given ID node the user only needs to make a single (local) connection to their LFCP. The LFCP does not need to forward the request to other peers, as it guarantees that it can provide the required content itself.

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

[0418] The Metaweb infrastructure is also robust to the failure of any one LFCP by adopting the network of these peers. This means that if an LFCP is deactivated, the end user simply defaults to using their next closest LFCP. This can be made more efficient if the LFCPs communicate with each other to indicate which nearby peers are below or above capacity 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 among nearby LFCPs.

[0419] Global full-copy peer

[0420] Now consider the scenario when the universal disk space requirements become too large for smaller peers, which can happen as the Metaweb portion of the blockchain expands and grows with adoption.

[0421] In this case, the smaller LFCP should use its disk space capacity to store meta-network node transactions based on a popularity system (there is existing technology for volume of requests and essential rating of content). This means that the LFCP now trims both its CPU (for request processing capabilities) and its storage allocation (for content serving capabilities) to adapt to its local geographical requirements in terms of both content volume and nature.

[0422] To address the fact that the LFCP can no longer store all meta-network transaction content, the concept of a Global Full-Copy Peer (GFCP) can be utilized. A GFCP is a full-copy peer with the following properties:

[0423] 1. The GFCP grows its disk space capacity to always maintain a full copy of the blockchain.

[0424] 2. The GFCP has a significant amount of CPU resources such that, compared to the LFCP, it can handle significantly more requests. In case many LFCPs are compromised, the Global Full-Copy Peer should be able to handle a sudden increase in demand.

[0425] The GFCP has two main functions. First, it acts as a fail-safe for user requests for meta-network content when requests overflow from the LFCP. Second, the GFCP acts as an archival peer to store all meta-network content mined historically, which ensures that any meta-network node content can be accessed even if many LFCPs omit some content from their local storage provisions.

[0426] Global database (data bank)

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

[0428] Prior to this, it was not possible to securely construct a general and globally accessible database because a central authority was required to maintain the database. This central authority injected points of failure and trust into the system. Critically, if we rely on an organization to store and maintain all Internet data, we need to trust that the organization operates correctly and legally without destroying information.

[0429] Through the meta-network infrastructure, the two issues of trust and centrality are effectively removed from the concept of a global data center. Now, a GFCP can be created because it is only relied upon to provide the disk space required for storage without verifying and authenticating the information to be stored.

[0430] Through the meta-network, the process of verifying stored content is carried out by network nodes, so a general global database can be trusted because it cannot corrupt blockchain information. The GFCP does not need to be trusted, only to provide storage.

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

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

[0433] Figure 17 A system with two LFCPs and one GFCP is shown, and it is illustrated how each peer can support another peer in a network that is robust to damage to the individual peers.

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

[0435] 1. Deterministic Keys - Hierarchical deterministic key management for both tokens and meta-network addresses is performed within the same wallet component of the application. This allows organizing keys by reducing their storage requirements and enabling multiple functions for key recovery.

[0436] 2. Payment Mechanism - The application allows consumers to pay merchants directly without referring to another application or third-party payment service that would conventionally authenticate and provide trust. This allows for the purchase and delivery of digital content via the same blockchain platform. The application inherits some advantages of specific payments, including low-value exchanges or more complex transactions involving multiple parties.

[0437] 3. Bypass Network Server - The application facilitates bypassing of conventional network servers that would conventionally handle large amounts of traffic, requests, and routing. This is because the application only needs to request content from a single LFCP, which ensures that requests do not need to be forwarded to other LFCPs to serve users. This reduces the total traffic and the completion time for each request.

[0438] 4. Timed Access - The application facilitates timed access to content by synchronizing with the blockchain and implementing 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 owners.

[0439] Use case - Decentralized application store (Swapp store)

[0440] The first use case (for illustrative purposes only) of the meta-network architecture presented here is decentralized payment and distribution for an application (app).

[0441] 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, in which money (or tokens) is exchanged for a secret key that grants Bob access to the app's data. The encrypted app data has been made public as part of a metaweb node transaction.

[0442] The app swapped at the atomic level is called a Swapp. A third-party platform (the Swapp Store) can be used to catalog and advertise apps existing on the metaweb, but the payment for and transfer of the access key to the user (e.g., Bob) does not need to involve any third party and can be done directly between the merchant and the consumer.

[0443] The following sections detail the process for buying and selling Swapps, from when Alice creates the app to when Bob deploys it. Throughout the process, Alice and Bob will use their respective browser wallets to interact with the metaweb.

[0444] Release

[0445] 1. Alice writes the app. The data that makes up the app is <app>The content represented. She also uses the secret key S k to encrypt it as <e(App)>.

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

[0447] 3. Then, Alice creates the children of the first node to form a tree that corresponds to the metanet library of her application. Alice's tree domain is shown in Figure 18 .

[0448] One of the leaf nodes on this tree corresponds to her application with index ID App <app>The node. In this node, Alice inserts the encrypted application data <e(App)> into the input script (scriptSig) of the node. Using the secret key s k to encrypt the app data using the Koblitz method.

[0449] The node transaction is as follows.

[0450]

[0451] 4. Alice publicly broadcasts the ID AliceApp , P AliceApp and the domain name 'AliceApp'. This can be achieved via social media, internet websites, or by using a third-party meta website.

[0452] Purchase

[0453] 1. Bob wants to download a puzzle game and sees Alice's app listed on the meta website (Swapp Store) viewed on his browser wallet.

[0454] 2. Then, Bob uses the information from the website to communicate with Alice and sets up an atomic swap. The swap is designed such that Bob will pay Alice the agreed-upon price, and Alice will reveal the secret key s k , or neither of these events will occur.

[0455] 3. The atomic swap is completed, and Bob's browser wallet stores the secret key s k in its access key / token wallet.

[0456] Deployment

[0457] Bob now has the key s k that will allow him to decrypt the application data previously released by Alice. To download and deploy the app, Bob performs the following.

[0458] 1. Bob uses the meta web search engine (SE) to find the MURL associated with the encrypted app data <e(App)>. He uses the keywords 'AliceApp' and 'App' as the input to the search bar in his browser wallet. The third-party SE parses the query and returns the following MURL:

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

[0460] This locator corresponds to the unique meta web node ID App , which includes the encrypted app data in its input script.

[0461] 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)>.

[0462] 3. The browser wallet processes the data according to the properties of the ID App . This includes using the secret key s k to decrypt the application data and process <app>。

[0463] 4. Bob will apply <app>Downloaded from his browser to his computer. Now, Bob can deploy the application locally without having to repurchase access rights.

[0464] Figure 19 Illustrates the entire process outlined in the above illustrative use case. The flowchart shows two action branches: Alice's branch (starting on the left) and Bob's branch (starting on the right). The branch corresponding to Alice shows the initial release phase and the Bob branch shows the phase of setting up the purchase via atomic swap.

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

[0466]

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

[0468] The branches of Alice and Bob in the figure converge at the point where Alice successfully completes the atomic swap transaction. This is achieved when Alice broadcasts the transaction TxID Alice When:

[0469]

[0470] Once the transaction is broadcast, the action branches of Alice and Bob diverge again. Alice receives 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 meta network.

[0471] Now example embodiments are provided for illustration:

[0472] An embodiment of one aspect of the present disclosure may provide a computer-implemented method that includes the steps of: providing or using a plurality of blockchain transactions in a (logical) hierarchy such that a data portion provided or referenced in at least one additional transaction in a lower level of the hierarchy can be accessed or identified by comparison with an encryption key used to sign a first transaction in a higher level of the hierarchy; at least one transaction in the hierarchy (the first transaction or the additional transaction) may include: a transaction ID (TxID); a protocol flag; a discretionary public key (DPK); and / or a discretionary transaction ID (DTxID).

[0473] Additionally or alternatively, the method may include: using a first blockchain transaction to provide access to or prohibit access to a portion of data provided or referenced in at least one additional transaction in a lower level in the hierarchy of blockchain transactions, based on the cryptographic key used to sign the first blockchain transaction.

[0474] Embodiments of another aspect of the present disclosure may provide a computer-implemented method that includes the steps of: using a first blockchain transaction to provide access to or prohibit access to a portion of data provided or referenced in at least one additional blockchain transaction in a lower level in the hierarchy of blockchain transactions implemented on a blockchain, based on the cryptographic key used to sign the first blockchain transaction. Optionally, the hierarchy is a logical hierarchy.

[0475] Optionally, the first transaction and / or the additional transaction may include: a transaction ID (TxID); a protocol flag; a discretionary public key (DPK); and a discretionary transaction ID (DTxID).

[0476] The method may further include the steps of: storing and / or maintaining a mapping between the key used to sign the first transaction and at least one additional transaction in the lower level of the hierarchy.

[0477] A method according to one or more aspects of the present disclosure may include the steps of: generating or providing a plurality of associated blockchain transactions, wherein at least some of the transactions are generated or provided according to embodiments of the meta-network protocol described herein; the plurality of associated transactions may implement a logical hierarchy of data items related to an entity or be based on a logical hierarchy of data items related to an entity.

[0478] Additionally or alternatively, embodiments of the present disclosure may include a method that includes using at least one blockchain transaction (Tx) that includes a transaction ID (TxID), the transaction including:

[0479] A protocol flag;

[0480] A discretionary public key (DPK); and

[0481] A discretionary transaction ID (DTxID)

[0482] The transaction (Tx) may be the first transaction and / or an additional transaction in the lower level of the hierarchy. The use of the transaction may include processing, accessing, generating, accessing data from a peer-to-peer network (e.g., a blockchain), and / or searching within the peer-to-peer network.

[0483] This combination of features enables data parts to be identified on the blockchain and, when provided in multiple transactions, to be linked / associated with each other. It enables the construction of a graph or tree-like structure that reflects the hierarchical relationship between the data parts, thereby facilitating their processing, search, access, generation, and sharing.

[0484] As is known in the art of blockchain protocols, a transaction ID (TxID) is an identifier for a transaction—each blockchain transaction has a unique ID as part of the underlying blockchain protocol. In contrast, a discretionary public key (DPK) and / or discretionary transaction ID (DTxID) can be "discretionary" in that they are provided as part of the present invention, rather than being provided as an essential component of a transaction as mandated by the underlying blockchain's protocol. In other words, they are not required for a transaction to be valid according to the underlying blockchain's protocol. Additionally or alternatively, they can be described as additional, non-essential items provided as part of the present invention, rather than because they are required by the blockchain protocol.

[0485] Preferably, the protocol flag is associated with and / or indicates a blockchain-based protocol for searching, storing, and / or retrieving data in one or more blockchain transactions. The protocol flag may be an indicator or marker. It may indicate that the transaction was formed according to a predetermined protocol. This may be a protocol other than the protocol of the underlying blockchain. It may be a search protocol according to any embodiment described herein (i.e., a search protocol that may be referred to as a "metanet" protocol described herein).

[0486] According to embodiments of the present invention, a discretionary transaction ID can be an identifier, label, indicator, or tag associated with a transaction (Tx). We use the term "indicator" to encompass all of these terms. It should be noted that, as is known in the art and readily understood by those skilled in the art, each transaction on a blockchain is uniquely identified by an identifier, commonly referred to in the art as a TxID. The TxID is a fundamental, essential, and non-discretionary part of the underlying blockchain protocol. This non-discretionary TxID should not be confused with the discretionary transaction ID (DTxID) referred to herein.

[0487] Preferably, a blockchain transaction (Tx) also includes a portion of data, or a reference to a portion of data. The reference to a portion of data can be a pointer, address, or other indicator of the location where the data is stored. The portion of data can be any type of data or digital content, such as, for example, a computer-executable item, text, video, image, sound file, etc. The portion of data can be referred to as "content". The portion of data or the reference thereto can be in a processed form. For example, it can be a hash digest of the portion of data. The data can be stored on-chain or off-chain (i.e., "off-chain").

[0488] Preferably, a portion of data, or a reference to a portion of data, a protocol flag, a discretionary public key (DPK), and / or a discretionary transaction ID (DTxID) are provided in the output (UTXO) of a blockchain transaction. One or more of them can be provided in a locking script associated with the output (UTXO).

[0489] Preferably, the portion of data, the reference to a portion of data, the protocol flag, the discretionary public key (DPK), and / or the discretionary transaction ID (DTxID) are provided at a location after a script opcode within the transaction (Tx), which is used to mark the output as invalid for subsequent use as an input to a subsequent transaction.

[0490] The script opcode can be the OP_RETURN opcode in one or more variants of some blockchain protocols, or a functionally similar / equivalent opcode of another blockchain protocol.

[0491] Preferably, the transaction (Tx) also includes one or more attributes. This makes the method of searching for data / content more detailed. The attributes can also be referred to as "values", "tags", or "marks" or "identifiers". They can be used to describe or annotate the data portion, or to provide additional information related to the data portion.

[0492] Preferably, the one or more attributes include keywords, tags, or identifiers associated with:

[0493] i) the portion of data provided or referenced in the transaction (Tx); and / or

[0494] ii) the transaction (Tx).

[0495] Preferably, the transaction (T X ) also includes an input, which includes:

[0496] a parent public key (PPK) associated with a logical parent transaction (LPTx), which is identified by a discretionary transaction ID (DTxID); and

[0497] a signature generated using the parent public key (PPK).

[0498] This enables a logical hierarchy to be constructed between a transaction and the data embedded therein. Accordingly, multiple associated or logically linked transactions on a blockchain can be processed efficiently, securely, and rapidly. Logically associated transactions may not be stored on the blockchain at consecutive block heights, but they can be easily, efficiently, and securely identified and / or accessed.

[0499] Preferably, the method further comprises the steps of: using a discretionary public key (DPK) and a transaction ID (TxID) to identify a transaction (Tx) or a logical parent transaction within a blockchain.

[0500] Additionally or alternatively, the present disclosure may provide a computer-implemented method comprising the steps of:

[0501] associating a public key with a blockchain transaction (Tx) comprising a transaction ID; and

[0502] searching for a blockchain transaction (Tx) based on the transaction ID and the transaction public key.

[0503] Accordingly, the method can be an improved solution for storing, searching, identifying, communicating, and / or accessing data via a blockchain. The method can provide improvements for data communication and exchange across an electronic network, particularly a peer-to-peer (blockchain) network.

[0504] As described above, the public key and / or the transaction ID can be discretionary. According to this embodiment of the present invention, any of the features described above or herein can also be utilized, but for the sake of brevity and clarity, they are not repeated or reproduced herein.

[0505] It may further comprise the steps of: accessing or otherwise processing a portion of the data provided within or referenced from a transaction (Tx). A transaction may include a transaction ID (TxID), a protocol flag, a discretionary public key (DPK), and a discretionary transaction ID (DTxID). A transaction (Tx) may also include a portion of data, or a reference to a portion of data. The portion of data or the reference to the portion of data, the protocol flag, the discretionary public key (DPK), and / or the discretionary transaction ID (DTxID) may be provided in an output (UTXO), preferably in a locking script associated with the output (UTXO).

[0506] The portion of data, the reference to the portion of data, the protocol flag, the discretionary public key (DPK), and / or the discretionary transaction ID (DTxID) may be provided at a position after a script opcode within the transaction (Tx) that is used to mark the output as invalid for subsequent use as an input to a subsequent transaction.

[0507] A transaction (Tx) can include one or more attributes. The one or more attributes can include keywords, tags, or identifiers associated with:

[0508] i) a portion of the data provided or referenced in the transaction (Tx); and / or ii) the transaction (Tx).

[0509] The transaction (T X ) can also include an input that includes: a parent public key (PPK) associated with a logical parent transaction (LPTx), where the logical parent transaction (LPTx) is identified by a freely determined transaction ID (DTxID); and a signature generated using the parent public key (PPK).

[0510] The method can include: using a freely determined public key (DPK) and a transaction ID (TxID) to identify a transaction (Tx) or a logical parent transaction within a blockchain. This can be performed during a search step.

[0511] A protocol flag can be associated with and / or indicate a blockchain-based protocol for searching, storing, and / or retrieving data in one or more blockchain transactions.

[0512] Additionally or alternatively, the method of the present disclosure can include any one or more of the following:

[0513] Generating a plurality of blockchain transactions, where each of the plurality of blockchain transactions stores a respective portion of first data to be stored on the blockchain and second data indicating that the portions of the first data are related to each other.

[0514] Preferably: a respective digital signature may be applied to the portion of the first data; preferably, at least some of the portions of the first data are each digitally signed by means of a single private key of a public-private key pair of a cryptosystem. Preferably, at least some of the portions of the first data are each digitally signed by means of a respective private key of a public-private key pair of a cryptosystem, and the private keys are related to each other. Preferably, at least one of the digital signatures is based on a cryptosystem having a public-private key pair, wherein the private key is based on a plurality of prime numbers, and the corresponding public key is based on the product of the plurality of prime numbers. At least one of the digital signatures may be a Rabin signature. The second data may include data related to the recombination of the first data. The first data may be included in a plurality of first inputs and / or first outputs of the plurality of blockchain transactions. Preferably, at least one second input and / or at least one second output of at least one of the blockchain transactions includes indication data indicating that the transaction includes the first data. The second data may represent at least one attribute of the first data, and the at least one attribute is at least one of a data type, a data encryption scheme, a data compression scheme, index information, permission information, encoding information, keyword information, or search information of the first data. The first data may be included only in at least one respective first output of the plurality of blockchain transactions. At least one first output and / or second output of at least one of the blockchain transactions may include a script opcode for marking the output as invalid for subsequent use as an input to a subsequent transaction. Additionally or alternatively, the method of the present disclosure may include any one or more of the following:

[0515] Generating a blockchain transaction having at least one first input and / or at least one first output, and at least one second input and / or at least one second output, wherein the at least one first input and / or at least one first output contains first data to be stored on the blockchain, and the at least one second input and / or at least one second output contains second data representing at least one attribute of the first data, wherein at least one of the at least one second input and / or at least one of the second outputs is separate from the or each first input and / or first output.

[0516] Preferably: the first data is included in a plurality of the first inputs and / or the first outputs; the second data may include data related to the recombination of the first data; at least one of the second inputs and / or at least one of the second outputs may include indication data indicating that a transaction includes the first data; the second data may represent at least one attribute of the first data, and the at least one attribute is at least one of a data type, a data encryption scheme, a data compression scheme, index information, permission information, encoding information, keyword information, or search information of the first data; the first data may be included in at least one of the first outputs; at least one of the first outputs and / or the second outputs may include a script opcode for marking the output as invalid for subsequent use as an input to a subsequent transaction; at least one of the first outputs may be redeemable by means of at least one key corresponding to a respective digital signature applied to the first data; a digital signature may be applied to the first data - preferably, at least one of the digital signatures is based on a cryptosystem having a public-private key pair, wherein the private key is based on a plurality of prime numbers, and the corresponding public key is based on the product of the plurality of prime numbers. At least one of the digital signatures may be a Rabin signature; a data compression technique or process or algorithm may be applied to the first data and / or the second data.

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

[0518] a processor; and

[0519] a memory including executable instructions, which, when executed by the processor, cause the system to perform any embodiment of the computer-implemented method described herein.

[0520] It may include a peer-to-peer network or may be implemented on a peer-to-peer network, preferably, the peer-to-peer network is a blockchain network.

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

[0522] Now turning to Figure 20 , an illustrative simplified block diagram of a computing device 2600 that can be used to practice at least one embodiment of the present disclosure is provided. 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 be used as a data server, a network server, a portable computing device, a personal computer, or any electronic computing device. As Figure 20 As shown, the computing device 2600 may include one or more processors (collectively 2602) having one or more levels of cache memory and a 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, the main memory 2608 may include dynamic random access memory (DRAM) 2618 and read-only memory (ROM) 2620. The storage subsystem 2606 and the cache memory 2602 may be used to store information, such as details associated with transactions and blocks described in this disclosure. The (one or more) processors 2602 may be used to provide the steps or functions of any of the embodiments described in this disclosure.

[0523] (One or more) processors 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.

[0524] 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 expected. Although the bus subsystem 2604 is schematically shown as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0525] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may be used as an interface for receiving data from other systems different from the computing device 2600 and for transmitting data to other systems. For example, the network interface subsystem 2616 may enable a data technician to connect a device to a network such that the data technician can transmit data to and receive data from the device while located at a remote location (e.g., a data center).

[0526] 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. Generally, the use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0527] 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. Generally, 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 interaction of a user with an application that performs the described processes and variations thereof, when such interaction is appropriate.

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

[0529] 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 can be connected to the computing device 2600 through one or more ports (e.g., USB, headphone jack, Lightning connector, etc.). The device that can be connected to the computing device 2600 may include a plurality of ports configured to accept fiber optic connectors. Thus, the device may be configured to convert an optical signal into an electrical signal that can 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, Figure 20 The description of the computing device 2600 depicted is only intended as a specific example for the purpose of illustrating the preferred embodiments of the device. Many other configurations with more or fewer components than the Figure 20 system depicted are possible.

[0530] It should be noted that the above embodiments illustrate rather than limit the invention, and those skilled in the art will be able to design many alternative embodiments without departing from the scope of the invention as defined by the appended claims. In the claims, any reference signs in parentheses shall not be construed as limiting the claim. The word "comprising" etc. does not exclude the presence of elements or steps other than those listed in any claim or the whole specification. In this specification, "comprise" means "include or consist of", and "comprising" means "including or consisting of". The singular form of an element does not exclude the plural form of such element, and vice versa. The invention can be implemented by hardware including 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 piece of hardware. The fact that certain means are recited in mutually different dependent claims does not indicate that a combination of these means cannot be used to advantage.< / app> < / app> < / app> ​< / app> < / lzw> < / n> < / m> < / s> < / n> < / m> < / s> < / content> < / attributes>

Claims

1. A computer-implemented method, comprising the following steps: Using a first blockchain transaction to provide access to or prohibit access to a portion of data provided or referenced in at least one additional blockchain transaction in a lower level of a hierarchy of blockchain transactions implemented on a blockchain, based on a cryptographic key used to sign the first blockchain transaction.

2. The method according to claim 1 further comprises the following steps: Storing and / or maintaining a mapping between the key used to sign the first blockchain transaction and at least one additional blockchain transaction in the lower level of the hierarchy.

3. The method according to claim 1, wherein, The first blockchain transaction and / or the at least one additional blockchain transaction in the lower level of the hierarchy includes: A transaction ID (TxID); A protocol flag; A discretionary public key (DPK); and A discretionary transaction ID (DTxID).

4. The method according to claim 3, wherein: The transaction ID (TxID) is an identifier of the first blockchain transaction and / or at least one additional blockchain transaction, and this identifier is a basic, required, and non-discretionary part of the blockchain protocol; The protocol flag indicates that the transaction is formed according to a protocol other than the blockchain protocol; and The discretionary public key (DPK) and the discretionary transaction ID (DTxID) are not specified or required by the blockchain protocol.

5. The method according to claim 3, wherein: The protocol flag indicates that the transaction is formed according to a protocol for searching, storing, or retrieving data in one or more blockchain transactions.

6. The method according to claim 4, wherein: The portion of the data or a reference to the portion of the data, the protocol flag, the discretionary public key (DPK), and / or the discretionary transaction ID (DTxID) are provided within the output of the first blockchain transaction and / or at least one additional blockchain transaction.

7. The method according to claim 6, wherein: The portion of the data or a reference to the portion of the data, the protocol flag, the discretionary public key (DPK), and / or the discretionary transaction ID (DTxID) are provided within a locking script associated with the output.

8. The method according to claim 3, wherein The portion of the data, the reference to the portion of the data, the protocol flag, the discretionary public key (DPK), and / or the discretionary transaction ID (DTxID) are provided at a position after a script opcode within a blockchain transaction (Tx), and the script opcode is used to mark the output as invalid for subsequent use as an input to a subsequent blockchain transaction.

9. The method according to claim 1, wherein: The first blockchain transaction and / or at least one additional blockchain transaction includes one or more attributes.

10. The method according to claim 9, wherein: The one or more attributes include keywords, tags, or identifiers associated with: i) A portion of the data provided or referenced in the first blockchain transaction and / or at least one additional blockchain transaction; and / or ii) The first blockchain transaction and / or at least one additional blockchain transaction.

11. The method according to claim 1, wherein, The first blockchain transaction and / or at least one additional blockchain transaction further includes an input, the input including: A parent public key (PPK) associated with a logical parent transaction (LPTx), wherein the logical parent transaction (LPTx) is identified by the discretionary transaction ID (DTxID); and A signature generated using the parent public key (PPK).

12. The method according to claim 1, further comprising the steps of: Using the discretionary public key (DPK) and the transaction ID (TxID) to identify the first blockchain transaction, the at least one additional blockchain transaction, and / or the logical parent transaction within the blockchain.

13. The method according to claim 1, wherein The first blockchain transaction and / or at least one additional blockchain transaction includes a unique index, the unique index including: A concatenation of the public key and the transaction ID; and / or A hash of the public key and the transaction ID; and / or A hash of the concatenation of the discretionary public key and the discretionary transaction ID.

14. The method according to any one of claims 1 to 3, wherein, The hierarchy is a logical hierarchy.

15. A computer-implemented system, comprising: A processor; And A memory including executable instructions, the executable instructions causing the system to perform any implementation of the computer-implemented method according to any one of claims 1 to 14 when executed by the processor.

16. A non-transitory computer-readable storage medium having stored thereon executable instructions, the executable instructions causing a computer system to perform at least an implementation of the method according to any one of claims 1 to 14 when executed by a processor of the computer system.

Images