Blockchain-based escrow marketplace
The blockchain-based escrow marketplace uses NIZKPs to verify token ownership anonymously, ensuring secure and private transactions by maintaining token confidentiality and reducing escrow workload.
Patent Information
- Application Number
- JP2024174682
- Authority / Receiving Office
- JP · JP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-12-21
- Filing Date
- 2024-10-04
- Publication Date
- 2025-07-03
AI Technical Summary
Existing transaction systems that involve intermediaries often require disclosing sensitive transaction details and assets to the intermediary, compromising privacy and security.
A blockchain-based escrow marketplace that uses non-interactive zero knowledge proofs (NIZKPs) to verify ownership of tokens without disclosing their content, allowing anonymous transactions through an escrow that maintains token confidentiality and ensures secure transfer of assets.
Enables secure, private transactions by verifying ownership through an escrow that remains unaware of the token content, protecting parties from fraudulent misrepresentations and reducing the escrow's workload while maintaining anonymity.
Smart Images

Figure 2025100338000001_ABST
Abstract
Description
Technical Field
[0001] Embodiments of the present disclosure relate to an escrow marketplace based on blockchain, and more particularly to facilitating transactions between entities using such a marketplace.
Background Art
[0002] Using an intermediary in a transaction provides additional security. For example, the intermediary can hold and verify the assets being traded. However, using an intermediary often involves providing the intermediary with temporary rights to the assets or other assets, which may involve disclosing various details of the transaction to the intermediary.
Summary of the Invention
[0003] One or more embodiments of the present disclosure may include a method that includes obtaining, from a first entity, a predicate, a first purchase price, and a first public key associated with the first entity. The method may also include publishing the predicate, the first purchase price, and the first public key. The method may further include obtaining, from a second entity, an encryption of a token and one or more proof-of-knowledge certificates, where the token satisfies the predicate. The encryption of the token can be encrypted using the first public key. The method may further include verifying the ownership of the token based on the proof-of-knowledge certificates. The method may also include obtaining, from the first entity, an asset corresponding to the first purchase price. The method may further include transmitting at least a portion of the proof-of-knowledge certificate that includes an updated hash value, where the updated hash value represents the ownership of the token transferred from the second entity to the first entity. The method may further include verifying that the updated hash value is posted to a token blockchain. The method may further include providing the encryption of the token to the first entity and transferring the asset corresponding to the first purchase price to the second entity.
[0004] The objectives and advantages of the embodiments are at least realized and achieved by the elements, features, and combinations particularly pointed out in the claims.
[0005] It should be understood that both the foregoing general description and the following detailed description are merely illustrative and explanatory and not restrictive.
Brief Description of the Drawings
[0006] Exemplary embodiments are described and explained with further particularity and detail through the use of the following attached drawings.
[0007]
Figure 1
[0008]
Figure 2A
Figure 2B
Figure 2C
[0009]
Figure 3
[0010]
Figure 4
DETAILED DESCRIPTION OF THE INVENTION
[0011] The present disclosure relates to the use of escrow for securely transferring tokens between users. For example, an escrow can provide a marketplace for a buyer to offer a particular token associated with or otherwise identifying ownership of a given asset that the buyer wishes to purchase. For example, the asset can be real estate and the token can represent ownership of the real estate and / or rights related to ownership of the real estate. A seller can identify an offer in the marketplace and initiate a transaction through the escrow. For example, the seller may hold a token associated with ownership of the desired real estate. The escrow may function as an intermediary such that both the seller and the buyer execute the requirements of the transaction. For example, the escrow can verify that the seller is the current owner of the token. As another example, the escrow may receive and inspect the payment provided by the purchaser in exchange for ownership of the token. During the transaction, the escrow may temporarily hold the payment until it can confirm that ownership of the token has been transferred to the buyer. The transfer of the token from the seller to the buyer can be verified by a new block posted to a blockchain that updates the token ownership information. After verifying that the new block is on the blockchain (e.g., that ownership has changed), the escrow may transfer the payment to the seller.
[0012] In these and other embodiments, the content of the transferred token may remain secret from the escrow throughout the process. For example, the predicates associated with the token may be used by the buyer to identify the token without disclosing the content of the token to the escrow. Additionally or alternatively, the seller may prove ownership of the token without disclosing the content of the token. For example, one or more non-interactive zero knowledge proofs (NIZKPs) generated by the seller can be used to prove ownership of the token to the escrow. Additionally or alternatively, similar or equivalent NIZKPs can be used by the seller to prove ownership of the asset associated with the token to the escrow.
[0013] In some embodiments, the content of the token can be hidden from the escrow even when transferring the token from the escrow to the buyer. For example, an encrypted version of the token can be used at the exchange. For example, the seller can encrypt the token using the public key associated with the buyer. Only the buyer can decrypt the encrypted token using the private key associated with the public key. In these and other embodiments, the identities of the buyer and seller may remain anonymous to each other. For example, the buyer and seller may use newly generated keys for all transactions to keep their respective identities hidden. For example, the buyer may generate a new public key for each transaction published to the marketplace.
[0014] The use of such embodiments can improve the operation of computer systems and related blockchain technologies. For example, embodiments of the present disclosure can provide additional protection for interactions between parties by providing an escrow as an intermediary. In particular, parties can execute transactions anonymously with each other. For example, a party need not know with whom it is transacting, nor need they transact simultaneously with each other. For example, parties can execute transactions with the escrow at different times instead of directly with each other. In some embodiments, users and / or tokens between transactions may not be linkable (e.g., a particular user may or may not be able to trace a particular transaction and / or token). Further, the escrow initiates and verifies the transfer of token ownership between parties using a token blockchain. This can protect parties from fraudulent misrepresentations that may occur regarding ownership. Further, embodiments of the present disclosure enable secure transactions between parties by permitting limited disclosure of information. In particular, the content of the token may remain hidden from the escrow throughout the transaction process. For example, the escrow may not have access to the actual content of the token but can verify the ownership of the token in a trustworthy manner. Further, the escrow can verify that the token is the correct token for the transaction based on a token identifier that does not disclose the content of the token. This can protect the privacy of the transaction while reducing the workload of the escrow.
[0015] One or more exemplary embodiments are described with reference to the accompanying drawings.
[0016] FIG. 1 is a diagram showing an exemplary system 100 that can utilize an escrow 110 as an intermediary to facilitate transactions between users. The system 100 can include a user A 120, a user B 121, a user C 122, a first blockchain 130, and a second blockchain 140. In some embodiments, the first blockchain 130 can include consecutive blockchain entries including a first blockchain entry 135a, a second blockchain entry 135b, and a third blockchain entry 135c.
[0017] The escrow 110 can include a third party or a trusted entity that operates as an intermediary between users. For example, the escrow 110 can permit the transfer and / or verification of information, assets, tokens, or other aspects of a transaction without directly transferring the information, assets, tokens, or other aspects of the transaction between the parties to the transaction. For example, the escrow 110 can enable users A 120 and B 121 to transfer and receive tokens and assets while remaining anonymous.
[0018] In operation, the escrow 110 can be configured to facilitate a transaction between user A 120 and user B 121. For example, user A 120 can be a buyer who purchases from user B 121, who is the seller. The transaction can be conducted via the escrow 110, and the escrow 110 can be the intermediary and verifier of the transaction. In these and other embodiments, users A and B 121 can interface with the escrow 110 and thus do not necessarily need to interact with each other.
[0019] In some embodiments, the escrow 110 has its escrow public key (pk ecan be posted so that it can be used by the user. A user who wishes to purchase an asset can send asset information to escrow. For example, user A120 can wish to purchase token (T). Escrow 110 can obtain information from user A120 regarding the user's interest in token (T). For example, user A120 can have a token predicate (P i ), a first purchase price (s i ), and a first public key (pk i ) to send to escrow 110. The token requirement predicate (P i ) can include the requirements for token (T). For example, the token requirement predicate (P i ) can include an identifier or other property of token (T) such that the owner or holder of token (T) can identify token (T) based on the token requirement predicate (P i ). For example, mathematically speaking, P i (T) is solved as true, indicating that token (T) satisfies the token requirement predicate (P i ). The purchase price (s i ) can identify the amount of a given asset that user A120 intends to pay for token (T). For example, the purchase price (s i ) can specify the amount of the type of cryptocurrency that the user is offering for token (T). The first public key (pk i ) can encrypt information in such a way that only the owner of the corresponding secret key (sk i ) (e.g., user A120) can decrypt the information. Escrow 110 can publish or otherwise make available to the public a tuple (P i , s i , pk i ) that includes information from user A120 indicating interest in token (T).
[0020] In some embodiments, escrow 110 can, in a way that does not identify user A120, a tuple (P i , si , pk i ) can be disclosed. For example, all of the token requirement predicate, purchase price, and / or public key can include information lacking the identification information that links user A120 to the information in the tuple. In these and other embodiments, the escrow 110 can maintain a database or other data store that associates the information from the tuple with user A120.
[0021] In some embodiments, user B121 can identify the information disclosed by the escrow 110. User B121 can analyze the information and determine that user B121 has the token (T) that user A110 is looking for. For example, mathematically speaking, P i (T) can be solved as true for the token (T) held by user B121. In some examples, P i (T f ) is solved as false, such a solution may indicate that the token (T f ) held by user B121 is not the token that user A120 is looking for.
[0022] In some embodiments, user B121 can determine that the first purchase price (s i ) identified in the tuple meets the minimum price that user B121 desires to sell the token (T). User B121 can determine that the first purchase price (s i ) in the marketplace is acceptable for the token (T). User B121 desires to sell the token (T) to user A120 and can initiate a transaction with the escrow 110 to sell the token (T) to user A120 at the purchase price (s i ).
[0023] In some embodiments, to effect the transfer of token (T) to user A120, user B121 may generate various information to indicate and effect the transfer of ownership. For example, user B121 may generate one or more proof-of-knowledge certificates and an encryption of token (T), and provide that information to escrow 110. Escrow 110 may verify the current ownership of token (T) based on the one or more proof-of-knowledge certificates.
[0024] In some embodiments, the proof-of-knowledge certificate may include h l where h l may correspond to the hash value posted last or most recently on the first blockchain 130. The last hash value may represent the current owner of token (T). User B121 may call an initial randomness value (r) from a storage device, where (r) may correspond to the most recent randomness value on the first blockchain 130, and (T) and (r) may satisfy h l =Hash(T||r), where Hash may represent a hash function and || may represent the concatenation of two elements (e.g., the concatenation of (T) and (r)). In some embodiments, the proof-of-knowledge certificate may further include a first proof of knowledge (π p ) indicating knowledge of (T) and (r). For example, a non-interactive zero-knowledge proof (NIZKP) may be used such that user B121 can prove to have knowledge of (T) and / or (r) without disclosing (T) and / or (r). Stated mathematically, user B121 may generate (π p ) of (T), (r) such that h l =Hash(T||r) and can be evaluated as true.
[0025] In some embodiments, user B121 can sample the updated randomness value (r0) and evaluate the updated hash value (h0) based on the token (T) and the updated randomness value (r0). For example, (h0) can be determined mathematically: h0 = Hash(T||r0). In some embodiments, one or more proofs of knowledge certificates can include the updated hash value (h0). User B121 can additionally generate a second proof of knowledge (π0) to be included in the proof of knowledge certificate, where the second proof of knowledge can represent knowledge of the last hash value (h l ) and the updated hash value (h0). For example, (π0) can represent the provable knowledge of user B121 regarding (r), (r0), and (T) such that h l = Hash(T||r) and h0 = Hash(T||r0). User B121 can additionally generate a first signed instruction (σ π0 ) related to the second proof of knowledge (π0). For example, mathematically deriving the first signed instruction can include the evaluation of σ π0 = Sign(sk j , s||π0), where (σ π0 ) is a signed value related to the second proof, Sign is an encryption / signature function where a value is signed / encrypted using a signature key, (sk j ) can represent the signature key of user B121, (s) can represent the hash of the last block in blockchain 130 related to the token, and (π0) can represent the second proof of knowledge. User B121 can further calculate a second signed instruction (σ i ) related to the first public key (pk T0 ) related to user A120. For example, the second signed instruction (σ T0 ) can be mathematically represented as σ T0 = Sign(sk j , h l ||pk i ), where (σ T0 ) is a signed value related to the first public key, and (sk j ) can represent the signature key of user B121.
[0026] In some embodiments, user B121 can compute the encryption (c) of the token (T). For example, mathematically deriving the encryption (c) of the token (T) can include the evaluation of c = Enc(pk i ,T||r0), where (c) is the encrypted value associated with the token (T), Enc is an encryption function that encrypts a value using a public key ((pk i ), etc.), (pk i ) represents the first public key of user A120, and (r0) can represent an updated randomness value. The encryption (c) can protect the token (T) such that the content of the token (T) and / or the updated randomness value can only be accessed by the private key associated with the public key. User B121 can further compute a third proof of knowledge (π enc ), and the third proof of knowledge can include a proof of knowledge that (c) is a valid encryption of a particular (T||r0) that satisfies h0 = Hash(T||r0) under the public key (pk i ), where (h0) represents an updated hash value and (r0) represents an updated randomness value.
[0027] In some embodiments, escrow 110 can obtain one or more proof of knowledge certificates from user B121. For example, the proof of knowledge certificate can include one or more of the last hash value (h l ) in the first blockchain 130, the updated hash value (h0), the first proof of knowledge (π p ), the second proof of knowledge (π0), the encryption (c) of the token, the third proof of knowledge (π enc ), the first signed instruction (σ π0 ), and / or the second signed instruction (σ T0 ).
[0028] In some embodiments, the escrow 110 can verify one or more knowledge proof certificates obtained from User B121. For example, after receiving the knowledge proof certificate, the escrow 110 can verify the certificate to verify that User B121 is the current owner of the token and / or that User B121 possesses the knowledge utilized to transfer ownership of the token (T). For example, the escrow 120 can verify the first knowledge proof (π p ), the second knowledge proof (π0), the third knowledge proof (π enc ), the first signed instruction (σ π0 ), and / or the second signed instruction (σ T0 ).
[0029] After verifying that User B121 is the current owner of the token, the escrow 110 can request that User A120 send the asset corresponding to the purchase price identified in the tuple previously submitted by User A120. For example, the escrow 110 can obtain from User A120 an amount of cryptocurrency corresponding to the first purchase price (s i ), such as a specific amount of BITCOIN (registered trademark), ETHERIUM (registered trademark), TETHER (registered trademark), others, or a combination thereof. In some embodiments, the escrow 110 can verify the transfer of the cryptocurrency. For example, the escrow 110 can verify the transfer of an amount of cryptocurrency related to the first purchase price (s i ) from User A120 to the escrow 110 as an entry on the second blockchain 140.
[0030] In response to successfully verifying the transfer of the asset, the escrow 110 can initiate the transfer of the token (T) from user B121 to user A120. For example, the escrow 110 can send information to be posted to the first blockchain 130 that reflects the update of the ownership of the token (T). In some embodiments, the information sent from the escrow 110 to the first blockchain 130 can include at least the updated hash value (h0). For example, the escrow 110 can send the last hash value (h l ), the updated hash value (h0), the first proof of knowledge (π p ), the first signed value (σ π0 ), and / or the second signed value (σ T0 ) to the first blockchain 130. The first blockchain 130 can post the updated hash value (h0) to the first blockchain 130 to reflect the update of the ownership of the token (T). The escrow 110 can verify that the updated hash value (h0) is added after the last hash value (h l ) in the first blockchain 130, so that the updated hash value (h0) becomes the last block in the blockchain 130 related to the ownership of the token (T). For example, Hash(T||r0) representing (h0) can be added after the last hash value (h l ) at the end of the blockchain entry included in the first blockchain 130.
[0031] After successfully verifying that the updated hash value (h0) has been posted to the first blockchain 130, the escrow 110 can complete the transaction by providing the token (T) to user A120 and the asset to user B121. For example, the escrow 110 can provide the encryption (c) of the token (T) to user A120. User A120 can use the private key (sk i ) associated with the first public key (pk iUsing [[ID=]], the encryption of the token can be decrypted to obtain an unencrypted version of the token (T). Additionally or alternatively, the escrow 110 can transfer the asset corresponding to the first purchase price to user B121. For example, the escrow 110 can send cryptocurrency from the escrow account of the escrow 110 to the cryptocurrency wallet of user B121. The escrow 110 can further send a transaction completion message to user B121.
[0032] If user C122 attempts to purchase the token (T) currently owned by user A120, the same process is followed. For example, the escrow 110 can obtain the token (T), the second purchase price (s k ), and the second public key (pk k ) identifying the second token requirement predicate (P k ) from user C122. The second token requirement predicate (P k ) can also help identify the token (T) such that P k (T) is resolved to true. The escrow 110 can make the second tuple (P k , s k , pk k ) obtained from user C122 publicly available. User A120 can decide to transfer the ownership of the token (T) in exchange for the second purchase price.
[0033] In some embodiments, user A120 can prove to escrow 110 that user A120 is the current owner of token (T) and can provide a second set of knowledge proof certificates. In some embodiments, user A120 can calculate a second set of knowledge proof certificates based on the updated hash value (h0), the updated randomness value (r0), and its own knowledge of token (T). For example, user A120 can sample a second updated randomness value (r1) and evaluate the second updated hash value (h1) and the second randomness value (r1) of token (T). User A120 can further prove that h0 = Hash(T||r0) and P k (T) is true, and generate a fourth knowledge proof (π p ) of the updated randomness value (r0) and token (T).
[0034] In some embodiments, user A120 can further calculate a fifth knowledge proof (π1), a third signed instruction (σ π1 ), and a fourth signed instruction (σ T1 ). For example, mathematically speaking, user A120 can calculate a fifth knowledge proof (π1) of (r0), (r1), and (T) such that h0 = Hash(T||r0) and h1 = Hash(T||r1), and evaluate σ π1 = Sign(sk i , s||π1) and σ T1 = Sign(sk i , h0||pk k ), where (sk i ) is the secret key of user A120 and (pk k ) is the second public key associated with user C122. User A120 can further calculate a second encryption (c0) of token (T) and a sixth knowledge proof (π enc ). For example, mathematically speaking, user A120 can evaluate c0 = Enc(pk k , T||r1), and the second public key (pk k) is used to evaluate the sixth proof (π that (c0) is a valid encryption of a specific (T||r1) that satisfies h1 = Hash(T||r1) enc ) can be evaluated.
[0035] In some embodiments, the escrow 110 can obtain a second set of knowledge proof certificates from user A120 and verify the current ownership of the token (T). For example, the escrow 110 can obtain (h0, h1, π p ', π1, c0, π enc ', σ π1 , σ T1 ) from user A120 and verify (π p ', π1, π enc ', σ π1 , σ T1 ). In response to verifying the ownership of the token based on the second set of knowledge proof certificates, the escrow 110 can obtain an asset corresponding to the second purchase price from user C122. The escrow 110 can send all or part of the second set of knowledge proof certificates to be posted to the first blockchain 130 to indicate the transfer of ownership. For example, the escrow 110 can send the updated hash value (h0), the second updated hash value (h1), the fifth knowledge proof (π1), the third signed value (σ π1 ), and the fourth signed value (σ T1 ) to the first blockchain 130. The escrow 110 can verify that the second updated hash value (h1) is posted to the first blockchain 130. For example, the escrow 110 can verify that the second updated hash value is added after the third blockchain entry 135c.
[0036] In some embodiments, escrow 110 can observe or identify that the posting of the second updated hash value to the first blockchain 130 has failed. In these embodiments, escrow 110 can cancel the transaction between user A 120 and user C 122. For example, escrow 110 can return the assets received from user C 122 to user C 122. Escrow 110 can further send a transaction failure notification to user A 120. Escrow 110 can also discard the second encryption and second proof of knowledge certificate set obtained from user A 120.
[0037] Changes, additions, or omissions may be made to system 100 without departing from the scope of the present disclosure. For example, the designation of different elements as described is meant to assist in explaining the concepts described herein and is not limiting. As another example, system 100 may include any number of other elements or may be implemented within a system or environment other than those described. For example, system 100 can include any number of users who can pass tokens. As another example, any number of administrators may exist who provide input to and / or control blockchain 130. As another example, any number of blockchains may exist, such as a first blockchain representing the ownership of one token, a second blockchain representing the ownership of another token, a third blockchain representing transactions of one type of cryptocurrency, and a fourth blockchain representing transactions of another type of cryptocurrency.
[0038] Figures 2A through 2C show an exemplary flowchart of an exemplary method 200 for executing a transaction in a blockchain-based escrow marketplace according to one or more embodiments of the present disclosure. One or more operations of method 200 can be performed by a system or apparatus such as system 100, escrow 110, user A 120, user B 121, user C 122, first blockchain 130, and / or second blockchain 140, or a combination thereof. Although separate blocks are shown, various blocks of method 200 may be divided into additional blocks, combined into fewer blocks, or removed depending on the implementation.
[0039] In block 210, a predicate, a purchase price, and a public key associated with a first entity can be obtained. For example, the escrow can receive a predicate (P i ), a purchase price (s i ), and a public key (pk i ) from a first entity attempting to purchase a particular token (T) and / or an asset for which the token (T) indicates ownership. The predicate (P i ) can include an identifier or other property of the token (T) such that an owner or holder of the token (T) can identify the token (T) based on the predicate (P i ). The purchase price (s i ) can identify the amount of a given asset, e.g., an amount in US dollars, an amount of cryptocurrency, etc., that the first entity intends to pay for the token (T). The public key (pk i ) can be a public key associated with the first entity. The public key (pk i ) can be part of a public / secret key pair (pk i sk i sk i, ) that is used to encrypt information such that only the holder of the corresponding secret key (sk i ) can decrypt the information.
[0040] In block 215, the escrowi )), purchase price (s i ), and public key (pk i ) can be published as a tuple and made available to the public. For example, an escrow can publish (P i , s i , pk i ) without identifying the first entity. Such a post can be made via a website, message board, blockchain, or other publicly accessible electronic location.
[0041] In block 220, token encryption and a proof of knowledge certificate can be obtained. For example, a second entity can analyze the published tuple (P i , s i , pk i ) and determine that the second entity has the token (T) that the first entity is looking for. The second entity can calculate the encryption of the token (T) using the public key of the first entity and generate a proof of knowledge certificate proving ownership of the token (T). The encryption and the proof of knowledge certificate can be provided to the escrow.
[0042] In some embodiments, the proof of knowledge certificate can include one or more of a final hash value (e.g., the most recently posted hash value in a blockchain indicating that the second entity is the owner), an updated hash value (e.g., a hash value indicating the new ownership after transfer from the second entity to the first entity), a first proof of knowledge, the encryption of the token, a second proof of knowledge, a third proof of knowledge, a first signed instruction, and / or a second signed instruction.
[0043] In block 225, the ownership of the token can be verified based on the proof-of-knowledge certificate. For example, the escrow can verify that the proof-of-knowledge certificate actually describes sufficient knowledge about the token (T), such that the second entity is the current owner of the token and / or owns the knowledge used to transfer the ownership of the token (T).
[0044] In block 230, the asset corresponding to the purchase price can be obtained from the first entity. For example, the escrow can obtain from the first entity an amount of cryptocurrency corresponding to the purchase price (s i ) such as a specific amount of BITCOIN (registered trademark), ETHERIUM (registered trademark), TETHER (registered trademark), others, or a combination thereof. In some embodiments, the escrow can verify the transfer of the cryptocurrency using the blockchain associated with the cryptocurrency. Additionally or alternatively, the escrow can verify that the purchase price has appeared in the escrow's digital wallet or other account.
[0045] In block 235, the escrow can send at least a portion of the proof-of-knowledge certificate to the token blockchain. For example, the escrow can send at least the updated hash value (h0) to the blockchain and initiate the token transfer. The ownership of the token can be transferred by posting the updated hash value (h0) to the token blockchain.
[0046] In block 240, the escrow can verify whether the updated hash value has been posted to the blockchain. For example, the escrow can verify whether the updated hash value is the last hash value (h lIt can be verified that it has been added to the token blockchain after ). As a result, the updated hash value (h0) becomes the block last posted to the token blockchain, reflecting the change in ownership. As another example, the escrow can determine that the updated hash value (h0) was not correctly posted to the token blockchain. For example, the escrow can find that the updated hash value (h0) was not posted after the last hash value (h l ). For example, the failure can be due to a lack of knowledge of the token (T) of the second entity, a calculation error, a shortage of actors to verify the block containing the updated hash value (h0), or other reasons. If the updated hash value is posted to the blockchain, method 200 can proceed to block 245 in FIG. 2B. If the updated hash value is not posted to the blockchain, method 200 can proceed to block 260 in FIG. 2C.
[0047] In block 245, based on the updated hash value (h0) being posted to the blockchain, the escrow can provide the encryption of the token to the first entity. For example, the escrow can use the public key of the first entity to encrypt the token (T) generated by the second entity (e.g., c = Enc(pk i , T||r0)) as described in this disclosure. For example, the first entity can decrypt the encryption of the token to obtain an unencrypted version of the token (T).
[0048] In block 250, the escrow can transfer the asset corresponding to the purchase price to the second entity. For example, the escrow can transfer the amount of cryptocurrency received from the first entity to the second entity.
[0049] In block 255, the escrow can send a transaction completion confirmation to the second entity. For example, after sending the encryption of the token (T) to the first entity and the cryptocurrency to the second entity, the escrow can notify the first entity and the second entity that the transaction has been completed.
[0050] In block 260, based on the fact that the updated hash value (h0) has not been posted to the blockchain, the escrow can return the assets obtained from the first entity to the first entity. For example, the escrow can temporarily hold the cryptocurrency received from the first entity in a digital wallet. The escrow can send back the same amount of cryptocurrency received from the first entity because the transfer of ownership via the blockchain has failed. In some embodiments, the escrow can also send a transaction failure message to the first entity.
[0051] In block 265, the escrow can abort the transaction and send a transaction failure message to the second entity. For example, the escrow can discard the encryption and proof-of-knowledge certificate obtained from the second entity and notify the second entity. In some embodiments, the failure notice can describe the reason for the failure.
[0052] Changes, additions, or omissions may be made to method 200 without departing from the scope of the present disclosure. For example, the operations of method 200 may be performed in a different order. Additionally or alternatively, two or more operations may be executed simultaneously. Further, the steps and operations outlined are provided by way of example, and some of the steps and operations may be optional, combined into fewer steps and operations, or extended into additional steps and operations without detracting from the essence of the disclosed embodiments.
[0053] Figure 3 shows an exemplary flowchart of an exemplary method 300 for selling tokens through escrow according to one or more embodiments of the present disclosure. For example, method 300 may be an example or extension of blocks 220, 250, and / or 255 of FIGS. 2A and 2B. One or more operations of method 300 may be performed by a system or device such as system 100, escrow 110, user A 120, user B 121, user C 122, first blockchain 130, and / or second blockchain 140, or a combination thereof. Although separate blocks are shown, various blocks of method 300 may be divided into additional blocks, combined into fewer blocks, or removed depending on the implementation.
[0054] In block 310, the second entity may select an offer from the marketplace. For example, the escrow may publish an offer received from the first entity to the marketplace. For example, the escrow may publish, as information from the first entity indicating interest in token (T), a tuple of predicate, purchase price, and public key (P i ,s i ,pk i ), or make it available to the public. The second entity may select a tuple having a predicate (P i ) associated with the token (T) held by the second entity and the offer (s i ) to which the second entity agrees.
[0055] In block 315, the second entity may sample an updated randomness value. For example, the second entity may sample a new randomness value as an updated randomness value (r0) from the set of all real numbers associated with the token (T) and the new owner.
[0056] In block 320, the second entity may generate an initial randomness value and a first proof of knowledge of the token. For example, the first proof of knowledge (π p) can show the knowledge of the token (T) and the initial randomness value (r) related to the ownership of the token (T). For example, using NIZKP, the second entity can prove that it has the knowledge of (T) and (r) without disclosing (T) and / or (r).
[0057] In block 325, the second entity can generate a second proof of knowledge of the initial randomness value, the updated randomness value, and the token. For example, the second proof of knowledge (π0) can show the knowledge of the last hash value (h l ) and the updated hash value (h0). For example, the second proof of knowledge is a NIZKP representing the provable knowledge of the second entity of the initial randomness value (r), the updated randomness value (r0), and the token (T), where h l =Hash(T||r) and h0=Hash(T||r0).
[0058] In block 330, the second entity may generate an encryption of the token. For example, the second entity can encrypt the token using the public key (pk i ). The encryption (c) can protect the token (T) such that the content of the token (T) and / or the updated randomness value can only be accessed by the private key associated with the public key of the first entity. In other words, an escrow or other intermediary cannot observe the content of the token (T) without the private key.
[0059] In block 335, a third proof of knowledge of the encryption (c) can be generated. For example, the second entity can generate a third proof of knowledge that can include a proof of knowledge that (c) is a valid encryption of a specific (T||r0) that satisfies h0=Hash(T||r0) under the public key (pk i ).
[0060] In block 340, a first signed instruction can be calculated. For example, a second entity can calculate a first signed instruction related to a second proof of knowledge (e.g., as described in this disclosure, σ π0 =Sign(sk j ,s||π0)).
[0061] In block 345, a second signed instruction can be calculated. For example, a second entity can calculate a signed instruction related to the public key related to the first entity (e.g., as described in this disclosure, σ T0 =Sign(sk j ,h l ||pk i ).
[0062] In block 350, the second entity can send the proof of knowledge, encryption, and / or signed instruction to escrow. For example, the second entity can send one or more of the first proof of knowledge, the second proof of knowledge, encryption, the third proof of knowledge, the first signed instruction, and / or the second signed instruction to prove its own ownership of the token (T). In some embodiments, the second entity can also send the last hash value (h l ) and the updated hash value (h0).
[0063] In block 355, the second entity can receive an asset related to the offer. For example, the second entity can receive cryptocurrency corresponding to the purchase price (s i ) posted on the marketplace as part of the first entity's offer from escrow.
[0064] In block 360, the second entity can receive a transaction completion confirmation. For example, escrow can indicate to the second entity that the escrow has successfully transferred the encryption of the token to the first entity and the transfer of the cryptocurrency to the second entity is complete.
[0065] Changes, additions, or omissions may be made to method 300 without departing from the scope of the present disclosure. For example, the operations of method 300 may be performed in a different order. As an addition or alternative, two or more operations may be executed simultaneously. Further, the steps and operations outlined are provided as examples, and some of the steps and operations may be optional, combined into fewer steps and operations, or expanded into additional steps and operations without detracting from the essence of the disclosed embodiments.
[0066] FIG. 4 shows an exemplary computing system 400 according to at least one embodiment described in the present disclosure. Computing system 400 may include a processor 410, a memory 420, a storage device 430, and / or a communication unit 440. All of these may be communicatively coupled. Any or all of the systems 100 of FIG. 1 may be implemented as a computing system that is consistent with computing system 400, such as escrow 110, user A 120, user B 121, user C 122, first blockchain 130, and / or second blockchain 140 of FIG. 1. For example, user A 120 may perform operations using an electronic device that is consistent with computing system 400. As another example, first blockchain 130 may be stored and / or verified across multiple instantiations of a computer that is consistent with computing system 400.
[0067] Typically, processor 410 may include any computer, computing entity, or processing device including various computer hardware or software modules, and may be configured to execute instructions stored on any applicable computer-readable storage medium. For example, processor 410 may include a microprocessor, a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or any other digital or analog circuit configured to interpret and / or execute program instructions and / or process data.
[0068] Although a single processor is shown in FIG. 4, it is understood that processor 410 may include any number of processors distributed across any number of networks or physical locations and configured to perform any number of the operations described in this disclosure, individually or jointly. In some embodiments, processor 410 may interpret and / or execute program instructions and / or process data stored in memory 420. In some embodiments, processor 410 may load program instructions into memory 420.
[0069] After the program instructions are loaded into memory 420, processor 410 may execute the program instructions, such as instructions for performing any of methods 200 and / or 300 of FIGS. 2A - 3. For example, processor 410 may obtain instructions related to facilitating transactions between users, verifying token ownership, posting information to the blockchain, and the like.
[0070] Memory 420 and storage device 430 may include a computer-readable storage medium or one or more computer-readable storage media carrying or having computer-executable instructions, or a data structure stored therein. Such computer-readable storage media can be any available media that can be accessed by a computer such as processor 410. For example, memory 420 and / or storage device 430 may store a complete copy of a blockchain (e.g., the first blockchain 130 of FIG. 1). In some embodiments, computing system 400 may or may not include either memory 420 and / or storage device 430.
[0071] By way of example and not limitation, such computer-readable storage media can include non-transitory computer-readable storage media including random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disk storage, magnetic disk storage or other magnetic storage devices, flash memory devices (e.g., solid state storage devices), or other storage media that can be used to carry or store desired program code in the form of computer-executable instructions or data structures. Combinations of the above may also be included within the scope of computer-readable storage media. Computer-executable instructions may include, for example, instructions and data configured to cause processor 410 to perform a particular operation or a group of operations.
[0072] The communication unit 440 may include any component, device, system, or combination thereof configured to transmit or receive information via a network. In some embodiments, the communication unit 440 may communicate with other locations, devices in the same location, or other components within the same system. For example, the communication unit 440 may include a modem, a network card (wireless or wired), an optical communication device, an infrared communication device, a wireless communication device (e.g., an antenna), and / or a chipset (e.g., a Bluetooth device, an 802.6 device (e.g., a metropolitan area network (MAN)), a WiFi device, a WiMax device, cellular communication equipment, etc.), etc. The communication unit 440 may enable data exchange with a network and / or any other device or system described in this disclosure. For example, the communication unit 440 may enable the system 400 to communicate with other systems, such as communication devices and / or other networks.
[0073] Those skilled in the art can understand that after reviewing this disclosure, changes, additions, or omissions can be made to the system 400 without departing from the scope of this disclosure. For example, the system 400 may include more or fewer components than those explicitly illustrated and described.
[0074] The foregoing disclosure is not intended to limit the present invention to the disclosed detailed form or a particular field of use. Accordingly, various alternative embodiments and / or modifications to this disclosure are considered possible in light of this disclosure, whether or not explicitly described or shown herein. Therefore, it is understood that changes may be made in form and detail without departing from the scope of this disclosure by describing embodiments of this disclosure. Accordingly, this disclosure is limited only by the claims.
[0075] In some embodiments, components, modules, engines, and services different from those described herein may be implemented as objects or processes (e.g., separate threads) running on a computing system. Although some of the systems and processes described herein are described as being implemented generally in software (stored in and / or executed by general purpose hardware), dedicated hardware implementations or combinations of software and dedicated hardware implementations are also possible and contemplated.
[0076] The terms used herein and especially in the appended claims (e.g., the body of the appended claims) are generally intended to be terms in a “broad” sense (e.g., the term “comprising” should be interpreted as “comprising but not limited to,” the term “having” should be interpreted as “having but not limited to,” etc.).
[0077] Furthermore, if an intent to enumerate a specific number of introduced claims is present, such intent is to be shown explicitly in the claims, and if no such enumeration is present, no such intent exists. For example, for purposes of illustration, the following appended claims may include the use of introductory phrases “at least one” and “one or more” to introduce an enumeration of claims. However, the use of such phrases should not be considered to limit any particular claim that includes such phrases introducing an enumeration of claims to embodiments that include only one such enumeration, even when the same claim includes the introductory phrase “one or more” or “at least one” and the indefinite article “a” or “an” (e.g., “a” and / or “an” should be interpreted as meaning “at least one” or “one or more”). That is, the same applies to the use of the definite article to introduce an enumeration of claims.
[0078] Furthermore, when an enumeration of a specific number of introduced claims is explicitly recited, one of ordinary skill in the art should understand that such an enumeration is to be construed as meaning at least the number recited (e.g., a recitation of "two enumerations" without other modifiers means at least two enumerations, or two or more enumerations). Further, in examples where a recitation such as "at least one of A, B, and C, etc." or "one or more of A, B, and C, etc." is used, typically such a configuration is intended to include A alone, B alone, C alone, A and B together, A and C together, B and C together, or A, B, and C together, etc. For example, the use of the term "and / or" is intended to be construed in this manner.
[0079] Furthermore, any disjunctive word or phrase representing two or more alternative terms, whether in the description, claims, or drawings, should be understood to contemplate including one of the terms, any of the terms, or both terms. For example, the phrase "A or B" should be understood to include the possibility of "A" or "B" or "A and B".
[0080] However, the use of such a phrase should not be considered to mean that the introduction of an enumeration of claims by the indefinite article "a" or "an" limits any particular claim that includes such an introduced enumeration of claims to embodiments that include only one such enumeration, even when the same claim includes the introductory phrases "one or more" or "at least one" and the indefinite article "a" or "an" (e.g., "a" and / or "an" should be construed to mean "at least one" or "one or more"). That is, the same holds true for the use of the definite article used to introduce an enumeration of claims.
[0081] Furthermore, the use of terms such as "first," "second," "third," etc. is not necessarily used to imply a particular order in this specification. Usually, terms such as "first," "second," "third," etc. are used to distinguish between different elements. In the absence of a specific indication that terms such as "first," "second," "third," etc. mean a particular order, these terms should not be understood to mean a particular order.
[0082] All examples and conditional language set forth in this specification are intended for the teaching purpose of assisting the reader in understanding the present invention and the concepts that the present invention contributes to the further development of the technology, and should be construed as not being limited to such specifically recited examples and conditions. Although embodiments of the present disclosure have been described in detail, it should be understood that various changes, alternatives, and selections can be made without departing from the spirit and scope of the present disclosure.
[0083] The foregoing description of the disclosed embodiments has been provided to enable those skilled in the art to make and use the present disclosure. Various changes to these embodiments will be readily apparent to those skilled in the art. Also, the general principles defined herein may be applied to other embodiments without departing from the spirit or scope of the present disclosure. Accordingly, the present disclosure is not intended to be limited to the embodiments shown herein, but rather to follow the broadest scope consistent with the principles and novel features disclosed herein.
[0084] In addition to the above embodiments, the following appendices are further disclosed. (Appendix 1) A method, comprising: obtaining from a first entity a predicate, a first purchase price, and a first public key associated with the first entity; publishing the predicate, the first purchase price, and the first public key; obtaining from a second entity an encryption of a token, one or more knowledge proof certificates of the token, a token satisfying the predicate, and an encryption of the token encrypted using the first public key; Verifying the ownership of the token based on the knowledge proof certificate; Obtaining, from the first entity, an asset corresponding to the first purchase price; Sending at least a part of the knowledge proof certificate to a token blockchain, wherein a part of the knowledge proof certificate includes an updated hash value, and the updated hash value represents the ownership of the token transferred from the second entity to the first entity; Verifying that the updated hash value is posted to the token blockchain; Providing the encryption of the token to the first entity; Transferring the asset corresponding to the first purchase price to the second entity; A method comprising. (Appendix 2) The knowledge proof certificate includes the last hash value in the token blockchain, and the last hash value represents the current owner of the token, the updated hash value, the first knowledge proof, the second knowledge proof, the third knowledge proof, the first signed instruction, and the second signed instruction. The method according to Appendix 1. (Appendix 3) The first knowledge proof includes knowledge of an initial randomness value and the token, and the last hash value of the token includes the first hash value of the first concatenation of the token and the initial randomness value. The method according to Appendix 2. (Appendix 4) The second knowledge proof includes knowledge of an initial randomness value, an updated randomness value, and the token. The last hash of the token includes the first hash value of the first concatenation of the token and the initial randomness value. The updated hash value includes the second hash value of the second concatenation of the token and the updated randomness value. The method according to Appendix 2. (Appendix 5) The third knowledge proof includes knowledge of the encryption of the token, and the encryption of the token includes encryption using the first public key of the second concatenation of the token and the updated randomness value, so that the second hash value of the second concatenation of the token and the updated randomness value satisfies the updated hash value, the method according to Appendix 2. (Appendix 6) The first signed instruction includes a third concatenation of the hash of the latest block in the token blockchain and the second knowledge proof, and the first signed instruction is signed with the signature key of the second entity, the method according to Appendix 2. (Appendix 7) The second signed instruction includes a fourth concatenation of the last hash value and the first public key associated with the first entity, and the second signed instruction is signed with the signature key of the second entity, the method according to Appendix 2. (Appendix 8) The encryption of the token includes encryption of the concatenation of the token and the updated randomness value newly sampled by the second entity, the method according to Appendix 1. (Appendix 9) The method further includes verifying the asset corresponding to the first purchase price by at least referring to the blockchain associated with the asset, the method according to Appendix 1. (Appendix 10) A part of the knowledge proof certificate sent to the token blockchain further includes the last hash value, the updated hash value, the second knowledge proof, the first signed instruction, and the second signed instruction in the token blockchain corresponding to the token, the method according to Appendix 1. (Appendix 11) The method is executed by an escrow entity, the content of the token remains unknown to the escrow entity, the identity of the first entity remains unknown to the second entity, and the identity of the second entity remains unknown to the first entity, the method according to Appendix 1. (Appendix 12) obtaining a second predicate, a second purchase price, and a second public key from a third entity; Obtaining, from the first entity, a second encryption of the token and a second set of knowledge proof certificates, wherein the second encryption is performed using the second public key; Verifying the second encryption of the token based on the second set of knowledge proof certificates; Obtaining, from the third entity, a second asset corresponding to the second purchase price; Transmitting a part of the second set of knowledge proof certificates to the token blockchain, wherein the part includes at least a second updated hash value determined by the first entity; Responding to the inability to confirm that the second updated hash value has been added to the token blockchain by returning the obtained second asset to the third entity; The method according to Appendix 1, further comprising the above steps. (Appendix 13) The method according to Appendix 1, wherein the asset includes a cryptocurrency. (Appendix 14) One or more non-transitory computer-readable media storing instructions, which, when executed by one or more processors of a system, cause the system to perform operations, and the operations include: Obtaining, from a first entity, a predicate, a first purchase price, and a first public key associated with the first entity; Publicly disclosing the predicate, the first purchase price, and the first public key; Obtaining, from a second entity, an encryption of a token, one or more knowledge proof certificates of the token, a token satisfying the predicate, and an encryption of the token encrypted using the first public key; Verifying the ownership of the token based on the knowledge proof certificate; Obtaining, from the first entity, an asset corresponding to the first purchase price; Transmitting at least a portion of the knowledge proof certificate to a token blockchain, wherein a portion of the knowledge proof certificate includes an updated hash value, and the updated hash value represents the ownership of a token transferred from the second entity to the first entity; Verifying that the updated hash value is posted to the token blockchain; Providing encryption of the token to the first entity; Transferring an asset corresponding to the first purchase price to the second entity; One or more non-transitory computer-readable media comprising the foregoing. (Appendix 15) The knowledge proof certificate includes a last hash value in the token blockchain, and the last hash value represents the current owner of the token, the updated hash value, a first knowledge proof, a second knowledge proof, a third knowledge proof, a first signed instruction, and a second signed instruction. One or more non-transitory computer-readable media according to Appendix 14. (Appendix 16) The first knowledge proof includes knowledge of an initial randomness value and the token, and the last hash value of the token satisfies a first hash value of a first concatenation of the token and the initial randomness value. One or more non-transitory computer-readable media according to Appendix 15. (Appendix 17) The second knowledge proof includes knowledge of an initial randomness value, an updated randomness value, and the token, the last hash of the token includes a first hash value of a first concatenation of the token and the initial randomness value, and the updated hash value includes a second hash value of a second concatenation of the token and the updated randomness value. One or more non-transitory computer-readable media according to Appendix 15. (Appendix 18) The third knowledge proof includes knowledge regarding encryption of the token. The encryption of the token includes encryption using a second public key of a second concatenation of the token and the updated randomness value, such that a second hash value of the second concatenation of the token and the updated randomness value satisfies the updated hash value, one or more non-transitory computer-readable media according to Appendix 15. (Appendix 19) The first signed instruction includes a third concatenation of a hash of the latest block in the token blockchain and the second proof of knowledge, and the first signed instruction is signed with a signing key of the second entity, one or more non-transitory computer-readable media according to Appendix 15. (Appendix 20) The second signed instruction includes a fourth concatenation of the last hash value and the first public key associated with the first entity, and the second signed instruction is signed with a signing key of the second entity, one or more non-transitory computer-readable media according to Appendix 15.
Explanation of Signs
[0085] 110 Escrow 120 User A 121 User B 122 User C
Claims
1. A method comprising: obtaining, from a first entity, a predicate, a first purchase price, and a first public key associated with the first entity; publishing the predicate, the first purchase price, and the first public key; obtaining, from a second entity, token encryption, one or more knowledge proof certificates of the token, a token satisfying the predicate, and encryption of the token encrypted using the first public key; verifying the ownership of the token based on the knowledge proof certificate; obtaining, from the first entity, an asset corresponding to the first purchase price; transmitting at least a portion of the knowledge proof certificate to a token blockchain, wherein a portion of the knowledge proof certificate includes an updated hash value, and the updated hash value represents the ownership of the token transferred from the second entity to the first entity; verifying that the updated hash value is posted to the token blockchain; providing the encryption of the token to the first entity; transferring the asset corresponding to the first purchase price to the second entity; A method comprising the above steps.
2. The method according to claim 1, wherein the knowledge proof certificate includes a last hash value in the token blockchain, and the last hash value represents the current owner of the token, the updated hash value, a first knowledge proof, a second knowledge proof, a third knowledge proof, a first signed instruction, and a second signed instruction.
3. The method according to claim 2, wherein the first knowledge proof includes knowledge of an initial randomness value and the token, and the last hash value of the token includes a first hash value of a first concatenation of the token and the initial randomness value.
4. The method according to claim 2, wherein the second knowledge proof includes knowledge of an initial randomness value, an updated randomness value, and the token, the last hash of the token includes a first hash value of a first concatenation of the token and the initial randomness value, and the updated hash value includes a second hash value of a second concatenation of the token and the updated randomness value.
5. The third knowledge proof includes knowledge of the encryption of the token, and the encryption of the token includes encryption using the first public key of a second concatenation of the token and an updated randomness value, such that a second hash value of the second concatenation of the token and the updated randomness value satisfies the updated hash value, the method of claim 2.
6. The first signed instruction includes a third concatenation of a hash of the latest block in the token blockchain and the second knowledge proof, and the first signed instruction is signed with a signing key of the second entity, the method of claim 2.
7. The second signed instruction includes a fourth concatenation of the last hash value and the first public key associated with the first entity, and the second signed instruction is signed with a signing key of the second entity, the method of claim 2.
8. The encryption of the token includes encryption of a concatenation of the token and an updated randomness value newly sampled by the second entity, the method of claim 1.
9. The method of claim 1 further comprising verifying the asset corresponding to the first purchase price by at least referring to a blockchain associated with the asset.
10. A part of the knowledge proof certificate sent to the token blockchain further includes a last hash value in the token blockchain corresponding to the token, the updated hash value, a second knowledge proof, a first signed instruction, and a second signed instruction, the method of claim 1.
11. The method is executed by an escrow entity, the content of the token remains unknown to the escrow entity, the identity of the first entity remains unknown to the second entity, and the identity of the second entity remains unknown to the first entity, the method of claim 1.
12. obtaining a second predicate, a second purchase price, and a second public key from a third entity; obtaining, from the first entity, a second encryption of the token and a second knowledge proof certificate set, the second encryption being performed with the second public key; Verifying a second encryption of the token based on the second knowledge proof certificate set; Obtaining, from the third entity, a second asset corresponding to the second purchase price; Transmitting a part of the second knowledge proof certificate set to the token blockchain, the part including at least a second updated hash value determined by the first entity; Responding to the inability to confirm that the second updated hash value has been added to the token blockchain, returning the obtained second asset to the third entity; The method according to claim 1, further comprising.
13. The method according to claim 1, wherein the asset includes a cryptocurrency.
14. One or more non-transitory computer-readable media storing instructions, which, when executed by one or more processors of a system, cause the system to perform operations, the operations including: Obtaining, from a first entity, a predicate, a first purchase price, and a first public key associated with the first entity; Disclosing the predicate, the first purchase price, and the first public key; Obtaining, from a second entity, an encryption of a token, one or more knowledge proof certificates of the token, a token satisfying the predicate, and an encryption of the token encrypted using the first public key; Verifying the ownership of the token based on the knowledge proof certificate; Obtaining, from the first entity, an asset corresponding to the first purchase price; Transmitting at least a part of the knowledge proof certificate to a token blockchain, the part of the knowledge proof certificate including an updated hash value, the updated hash value representing the ownership of the token transferred from the second entity to the first entity; Verifying that the updated hash value is posted to the token blockchain; Providing the encryption of the token to the first entity; Transferring the asset corresponding to the first purchase price to the second entity; One or more non-transitory computer-readable media including.
15. The knowledge certificate includes the last hash value in the token blockchain, and the last hash value represents the current owner of the token, the updated hash value, the first knowledge proof, the second knowledge proof, the third knowledge proof, the first signed instruction, and the second signed instruction, according to one or more non-transitory computer-readable media of claim 14.
16. The first knowledge proof includes knowledge of an initial randomness value and the token, and the last hash value of the token satisfies the first hash value of a first concatenation of the token and the initial randomness value, according to one or more non-transitory computer-readable media of claim 15.
17. The second knowledge proof includes knowledge of an initial randomness value, an updated randomness value, and the token, the last hash of the token includes the first hash value of a first concatenation of the token and the initial randomness value, and the updated hash value includes the second hash value of a second concatenation of the token and the updated randomness value, according to one or more non-transitory computer-readable media of claim 15.
18. The third knowledge proof includes knowledge regarding the encryption of the token, The encryption of the token includes encryption using the second public key of a second concatenation of the token and the updated randomness value, such that the second hash value of the second concatenation of the token and the updated randomness value satisfies the updated hash value, according to one or more non-transitory computer-readable media of claim 15.
19. The first signed instruction includes a third concatenation of the hash of the latest block in the token blockchain and the second knowledge proof, and the first signed instruction is signed with the signature key of the second entity, according to one or more non-transitory computer-readable media of claim 15.
20. The second signed instruction includes a fourth concatenation of the last hash value and the first public key associated with the first entity, and the second signed instruction is signed with the signature key of the second entity, according to one or more non-transitory computer-readable media of claim 15.