Concept for providing conditional access to an online service

Abstract

The present disclosure is related to a concept for providing conditional access to an online service. A smart contract deployed on a blockchain network is used to lock a predetermined amount of digital assets of a user for a predetermined locking duration. A proof is provided to the online service that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service. The proof is verified and access for the user to the online service may be granted in case the verification is successful.

Description

[0001] CONCEPT FOR PROVIDING CONDITIONAL ACCESS

[0002] TO AN ONLINE SERVICE

[0003] Field

[0004] The present disclosure relates to methods and apparatuses which can be used to prevent spamming or creating fake identities personalized by intelligent Al bots.

[0005] Background

[0006] An Al bot, or Artificial Intelligence bot, is a software application programmed to perform tasks or simulate conversations with human users or other systems using artificial intelligence. These tasks can range from answering questions, providing recommendations, executing specific tasks, to engaging in conversational interactions, often mimicking human-like responses. Al bots can operate across various platforms, including websites, messaging apps, and mobile apps, and are used in a wide range of applications, from customer service and support to entertainment, education, and personal assistants.

[0007] Al bots leverage technologies such as natural language processing (NLP), machine learning (ML), and sometimes deep learning (DL), to understand, interpret, and respond to user inputs or environmental data. The sophistication of an Al bot can vary widely, from simple rule-based systems that follow predefined pathways to more advanced systems that learn and adapt from interactions and data over time, offering more nuanced and contextually relevant responses.

[0008] Al bot behavior is becoming more and more indistinguishable from real user behavior. Creating Al bots can easily be done by anybody at little to no cost. Therefore, Al bots may be used with malicious intent, for example for creating fake identities / fake accounts.

[0009] Thus, there is a demand to make using Al bots for such malicious intents more difficult.

[0010] Summary This demand is met by methods, apparatuses, and computer programs in accordance with the appended claims.

[0011] According to a first aspect, the present disclosure provides a method for providing conditional access to an online service. The proposed method includes using a smart contract deployed on a blockchain network to lock a predetermined amount of digital assets of a user for a predetermined locking duration. The method further includes providing a proof to the online service that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service. The proposed method also includes verifying the proof. The proposed method includes obtaining access for the user to the online service in case the verification is successful. Upon successful verification, the online service may grant the user access to the online service, benefits, or functionalities reserved for users who have locked the requisite amount of digital assets.

[0012] To mitigate the creation of fraudulent accounts, the present disclosure proposes to implement a system that elevates the cost of account creation through the use of digital asset collateral. The proposed solution requires users to lock-up a certain amount of digital assets (e.g., cryptocurrency) for a predetermined period using a digital asset time-lock mechanism. To ensure the uniqueness of the lock-up and avoid the issue of 'double locking', embodiments of the proposed solution can ensure that already locked digital assets cannot be locked again. The proposed solution allows users to prove that they have locked a specified amount of digital assets (e.g., cryptocurrency) for a certain duration in a specific account, without actually revealing the account's details. When users wish to open an account or register for a service that requires proof of such a lock-up, they may present the proof (e.g., a zero-knowledge proof) generated with the help of the smart contract. Online services requiring this proof of lock-up may then use the same smart contract to verify the authenticity of the proof (e.g., zero-knowledge proof) presented to them. This may ensure that only those who have genuinely committed their digital assets (e.g., cryptocurrency) as collateral can register for these services.

[0013] In some embodiments, the method further includes denying access to the online service in case the verification of the proof is unsuccessful. In some embodiments, the method includes generating a cryptographic commitment to the locked amount of digital assets and the locking duration, using a zero-knowledge proof (ZKP) protocol to generate a ZKP based on the cryptographic commitment that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service, verifying the ZKP, and obtaining access for the user to the online service in case the verification of the ZKP is successful.

[0014] In some embodiments, the cryptographic commitment comprises a hash of the locked predetermined amount of digital assets, the predetermined locking duration, and a user-specific secret (pre-image).

[0015] In some embodiments, the ZKP protocol comprises demonstrating knowledge of the userspecific secret (pre-image) of the cryptographic commitment matching a hashed secret (hashed pre-image) of digital asset transactional data related to the locking recorded in the blockchain network.

[0016] In some embodiments, the ZKP protocol comprises demonstrating that the locked amount of digital assets and the locking duration of the cryptographic commitment match with digital asset transactional data related to the locking recorded in the blockchain network.

[0017] In some embodiments, the ZKP protocol comprises demonstrating that that the locked amount of digital assets and the locking duration meet or exceed the threshold specified by the online service.

[0018] In some embodiments, the method includes the smart contract receiving a hash of the locked amount of digital assets, the locking duration, a transaction ID, and a hashed secret, and storing the received hash as digital asset transactional data in the blockchain network.

[0019] In some embodiments, the method includes the smart contract adding the received hash as a new leaf to a first Merkle tree representing digital asset transactional data, the smart contract storing a root of the first Merkle tree in a block of the blockchain network, and the smart contract providing a copy of the first Merkle tree to the user. In some embodiments, the method includes the smart contract receiving the cryptographic commitment from the user and storing information on the cryptographic commitment on the blockchain network.

[0020] In some embodiments, storing information on the cryptographic commitment on the blockchain network includes the smart contract adding the received cryptographic commitment as a new leaf to a second Merkle tree representing a plurality of cryptographic commitments, the smart contract storing a root of the second Merkle tree on the blockchain network, and the smart contract providing a copy of the second Merkle tree to the user.

[0021] In some embodiments, the method includes the user generating a Merkle proof based on the copy of the second Merkle tree and the cryptographic commitment, and using the Merkle proof for the ZKP protocol. For example, the Merkle proof may be sent to the smart contract and / or the online service.

[0022] In some embodiments, the ZKP protocol comprises demonstrating knowledge of the userspecific secret of the cryptographic commitment matching the hashed secret (hashed preimage) in the first Merkle tree representing digital asset transactional data.

[0023] In some embodiments, the ZKP protocol comprises demonstrating that the locked amount of digital assets and the locking duration of the cryptographic commitment match with the hash of the locked amount of digital assets, the locking duration, the transaction ID, and a hashed secret (hashed preimage) in the first Merkle tree representing digital asset transactional data.

[0024] In some embodiments, the ZKP protocol comprises using the threshold specified by the online service, the stored root of the first Merkle tree representing the plurality of digital asset transactions, and the Merkle proof of adding the cryptographic commitment as leaf node to the second Merkle tree representing the plurality of cryptographic commitments for verifying the ZKP.

[0025] In some embodiments, the method includes the user sending instructions to the smart contract for locking the predetermined amount of the user’s digital assets for the predetermined locking duration. In some embodiments, the method includes the smart contract releasing the predetermined amount of digital assets to the user after the predetermined locking duration has elapsed.

[0026] According to a further aspect, the present disclosure provides a system for providing conditional access to an online service. The system includes a blockchain network configured to execute a smart contract to lock a predetermined amount of digital assets of a user for a predetermined locking duration, a user device configured to provide a proof to the online service that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service, and an online-server configured to execute the online service, to verify the proof, and to grant access for the user to the online service in case the verification is successful.

[0027] According to a further aspect, the present disclosure provides a method for a smart contract deployed on a blockchain network. The method includes receiving (from a user) instructions for locking a predetermined amount of a user’s digital assets for a predetermined locking duration. In response to the instructions, the smart contract locks the predetermined amount of digital assets for the predetermined locking duration. After the predetermined locking duration has elapsed, the smart contract releases the predetermined amount of digital assets to the user.

[0028] In some embodiments, the method includes the smart contract receiving a hashed userspecific secret (pre-image) from the user, generating a hash of the locked amount of digital assets, the locking duration, and the hashed secret, and storing the hash as digital asset transactional data in the blockchain network.

[0029] In some embodiments, the method includes the smart contract adding the hash as a new leaf to a first Merkle tree representing digital asset transactional data, storing a root of the first Merkle tree in a block of the blockchain network, and optionally providing a copy of the first Merkle tree to the user.

[0030] In some embodiments, the method includes the smart contract receiving a cryptographic commitment from the user. The cryptographic commitment comprises a hash of the locked predetermined amount of digital assets, the predetermined locking duration, and a user- specific secret (pre-image). The method includes the smart contract storing information on the cryptographic commitment on the blockchain network.

[0031] In some embodiments, storing information on the cryptographic commitment on the blockchain network includes adding the received cryptographic commitment as a new leaf to a second Merkle tree representing a plurality of cryptographic commitments, storing a root of the second Merkle tree on the blockchain network, and the smart contract providing a copy of the second Merkle tree to the user.

[0032] According to a further aspect, the present disclosure provides a server for a smart contract deployed on a blockchain network. The server comprises processing circuitry configured to receive (from a user) instructions for locking a predetermined amount of a user’s digital assets for a predetermined locking duration. In response to the instructions, the processing circuitry is configured to lock the predetermined amount of digital assets for the predetermined locking duration. After the predetermined locking duration has elapsed, the processing circuitry is configured to release the predetermined amount of digital assets to the user.

[0033] According to a further aspect, the present disclosure provides a method for a user device. The method includes sending, to a smart contract deployed on a blockchain network, instructions for locking a predetermined amount of a user’s digital assets for a predetermined locking duration, and requesting access to an online service. Requesting access includes providing a proof (e.g., a ZKP) to the online service that the user has locked an amount of digital assets (e.g., cryptocurrencies) meeting or exceeding a threshold specified by an online service.

[0034] In some embodiments, the instructions for locking include the predetermined amount of digital assets, the locking duration, and a hashed user-specific secret (pre-image).

[0035] In some embodiments, the method includes receiving a copy of a first Merkle tree from the smart contract. The first Merkle tree comprises a leaf corresponding to a hash of the predetermined amount of digital assets, the locking duration, and the hashed user-specific secret.

[0036] In some embodiments, the method includes sending a cryptographic commitment to the smart contract. The cryptographic commitment comprises a hash of the predetermined amount of digital assets, the predetermined locking duration, and the user-specific secret (pre-image).

[0037] In some embodiments, the method includes receiving a copy of a second Merkle tree from the smart contract. The second Merkle tree comprises a leaf corresponding to the user’s cryptographic commitment.

[0038] In some embodiments, the method includes generating a Merkle proof based on the copy of the second Merkle tree and the cryptographic commitment, and sending the Merkle proof to the online service and / or to the smart contract.

[0039] In some embodiments, the method includes generating a ZKP based on the cryptographic commitment, the predetermined amount of digital assets, and the locking duration, and sending the ZKP to the online service and / or to the smart contract for verification.

[0040] According to a further aspect, the present disclosure provides a user device. The user device comprises processing circuitry configured to send, to a smart contract deployed on a blockchain network, instructions for locking a predetermined amount of a user’s digital assets for a predetermined locking duration, and request access to an online service. Requesting access includes providing a proof (e.g., a ZKP) to the online service that the user has locked an amount of digital assets (e.g., cryptocurrencies) meeting or exceeding a threshold specified by an online service.

[0041] According to a further aspect, the present disclosure provides a method for an online service. The method includes receiving a request for access to the online service from a user, requesting a proof (e.g., ZKP) that the user has locked an amount of digital assets meeting or exceeding a threshold specified by an online service, verifying the proof, and providing access for the user to the online service in case the verification is successful or denying access to the online service in case the verification is unsuccessful.

[0042] In some embodiments, the proof comprises a ZKP based on a cryptographic commitment to a locked amount of digital assets and a locking duration, a minimum amount of digital assets, and a minimum locking duration meeting or exceeding the threshold specified by the online service. According to a further aspect, the present disclosure provides an apparatus for an online service. The apparatus comprises processing circuitry configured to receive a request for access to the online service from a user, request a proof (e.g., ZKP) that the user has locked an amount of digital assets meeting or exceeding a threshold specified by an online service, verify the proof, and provide access for the user to the online service in case the verification is successful or deny access to the online service in case the verification is unsuccessful.

[0043] Brief description of the Figures

[0044] Some examples of apparatuses and / or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

[0045] Fig. 1 shows a flowchart of a method for providing conditional access to an online service in accordance with an embodiment of the present disclosure;

[0046] Fig. 2 shows a block diagram of a system for providing conditional access to an online service in accordance with an embodiment of the present disclosure;

[0047] Fig. 3 shows an example of a first Merkle tree and a second Merkle tree;

[0048] Fig. 4 shows a message sequence chart for generating a ZKP for a cryptocurrency lockup; and

[0049] Fig. 5 shows a process of building a ZKP, including validating that the hashed information in a Merkle tree leaf represents a certain amount of cryptocurrency locked for a specific time period.

[0050] Detailed Description

[0051] Some examples are now described in more detail with reference to the enclosed figures. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications of the features as well as equiv- alents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not be restrictive of further possible examples.

[0052] Throughout the description of the figures same or similar reference numerals refer to same or similar elements and / or features, which may be identical or implemented in a modified form while providing the same or a similar function. The thickness of lines, layers and / or areas in the figures may also be exaggerated for clarification.

[0053] When two elements A and B are combined using an “or”, this is to be understood as disclosing all possible combinations, i.e. only A, only B as well as A and B, unless expressly defined otherwise in the individual case. As an alternative wording for the same combinations, "at least one of A and B" or "A and / or B" may be used. This applies equivalently to combinations of more than two elements.

[0054] If a singular form, such as “a”, “an” and “the” is used and the use of only a single element is not defined as mandatory either explicitly or implicitly, further examples may also use several elements to implement the same function. If a function is described below as implemented using multiple elements, further examples may implement the same function using a single element or a single processing entity. It is further understood that the terms "include", "including", "comprise" and / or "comprising", when used, describe the presence of the specified features, integers, steps, operations, processes, elements, components and / or a group thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, processes, elements, components and / or a group thereof.

[0055] Fig- 1 illustrates a flowchart of a method 10 for providing conditional access to an online service in accordance with embodiments of the present disclosure. Method 10 may be implemented by a system 20 for providing conditional access to the online service. A basic block diagram of system 20 is shown in Fig. 2. System 20 comprises a user device 22 related to a user, a smart contract 24 deployed on a blockchain network, and an online service 26 running on one or more online servers. User device 22, smart contract 24, and online service 26 each comprise processing circuitry configured to perform acts of method 10 which relate to the respective entities. For example, the respective processing circuitry may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer or a programmable hardware component being operable with accordingly adapted software. In other words, the described functions of the user device 22, smart contract 24, and online service 26 may as well be implemented in software, which is then executed on one or more programmable hardware components. Such hardware components may comprise a general-purpose processor, a Digital Signal Processor (DSP), a micro-controller, etc. For example, storage circuitry of the user device 22, smart contract 24, and online service 26 may comprise at least one element of the group of a computer readable storage medium, such as an magnetic or optical storage medium, e.g. a hard disk drive, a flash memory, Floppy-Disk, Random Access Memory (RAM), Programmable Read Only Memory (PROM), Erasable Programmable Read Only Memory (EPROM), an Electronically Erasable Programmable Read Only Memory (EEPROM), or a network storage.

[0056] User device 22 may be an electronic device that individuals may use for various personal, professional, or educational purposes. Examples include desktop computers, lap- tops / notebooks, tablets, or smartphones.

[0057] Smart contract 24 may be a self-executing computer program or a piece of code that is stored and executed on a blockchain platform (e.g., Ethereum, Binance Smart Chain, Cardano, Solana, or similar platforms) with terms of agreement between two parties being directly written into lines of code. The code and the agreements contained therein exist across a distributed, decentralized blockchain network. Smart contracts permit trusted transactions and agreements to be carried out among disparate, anonymous parties without the need for a central authority, legal system, or external enforcement mechanism. They may render transactions traceable, transparent, and irreversible.

[0058] Online service 22 may encompass a wide range of internet-based activities and platforms that may offer various functionalities to users. Examples of online services in accordance with embodiments of the present disclosure are online services related to communication and social networking, such as email services, social media platforms, messaging and video call services, streaming platforms, or online gaming platforms. Further examples of online services in accordance with embodiments of the present disclosure are online services related to e-commerce and marketplaces, such as online retail stores or digital marketplaces. Further examples of online services in accordance with embodiments of the present disclosure are online services related to financial services, such as online banking and payment services, or investment and trading platforms. There may be online services in accordance with embodiments of the present disclosure related to education and learning, such as e-leaming platforms, or research databases and libraries. Online services related to productivity and collaboration may be cloud storage and file sharing services, project management and collaboration tools, telehealth services, or fitness and wellness apps. These examples represent just a fraction of the vast array of online services available today.

[0059] Method 10 includes using 12 the smart contract 24 deployed on the blockchain network to lock a predetermined amount of digital assets of a user for a predetermined locking duration. That is, method 10 may include the user or the user device 22 sending instructions to the smart contract 24 for locking the predetermined amount of the user’s digital assets for the predetermined locking duration. The smart contract 24 may be set up to time-lock the desired amount of digital assets. This means the digital assets may be locked in by contract 24 and cannot be moved or accessed until a specified time has passed. The smart contract 24 may include logic for accepting a specific amount of digital assets to lock (e.g., in a blockchain wallet capable of interacting with the blockchain network, holding the digital assets, and signing transactions), recording the locking duration as specified by the user or the contract terms, implementing a locking mechanism that prevents the withdrawal of the assets until the end of the locking period, and optionally providing functions for depositing the digital assets, checking a balance, and withdrawing the digital assets after the lock period expires. Thus, smart contract 24 may release the predetermined amount of digital assets to the user after the predetermined locking duration has elapsed.

[0060] The user must own the digital assets that they intend to lock in the smart contract 24. The digital assets could be cryptocurrencies like ETH for Ethereum, tokens compliant with the blockchain's standards (e.g., ERC-20 tokens on Ethereum), or other types of digital assets supported by the blockchain.

[0061] Users or their devices 22 may interact with the smart contract 24 by sending transactions to it from their blockchain wallets, following the contract's rules for locking and eventually unlocking their digital assets. Method 10 further includes providing 14 a proof to the online service 26 and / or to smart contract 24 that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service 26. Here, meeting or exceeding the threshold may be understood such that the locked amount of digital assets and the locking duration have to exceed a respective threshold.

[0062] The proof that the user has locked a required amount, could be done using concepts of on- chain verification or off-chain verification. For on-chain verification, the user may provide the online service 26 with their public address used for locking the digital assets. The online service 26 may then query the blockchain or use a blockchain explorer to confirm the transaction details, including the amount locked. The smart contract 24 may include a public function that allows anyone to query whether a specific address has locked assets meeting the threshold. This function may return a true / false response without revealing the actual amount locked. For off-chain verification, the smart contract 24 or the user device 22 may generate a cryptographic proof (like a digital signature or a zero-knowledge proof (ZKP)) that the user has met the required threshold(s). This proof can be verified by anyone without revealing the exact amount or compromising the user's privacy. The user may submit verification information (e.g., public address, cryptographic proof, or oracle verification) to the online service 26.

[0063] Method 10 further includes verifying 16 the proof. Depending on the method used, the online service 26 and / or smart contract 24 can independently verify the alleged amount by interacting with the blockchain, using blockchain explorers, or validating cryptographic proofs.

[0064] Method 10 further includes obtaining 18 access for the user to the online service 26 in case the verification is successful. Upon successful verification, the online service 26 may grant the user access to the online service, benefits, or functionalities reserved for users who have locked the requisite amount of digital assets. Upon unsuccessful verification, the online service 26 may deny access to the online service.

[0065] In some embodiments, method 10 may further include generating a cryptographic commitment to the locked amount of digital assets and the locking duration. The cryptographic commitment to the locked amount of digital assets and the locking duration may enable a secure and cryptographic way of proving that a specific amount of digital assets has been locked in a contract for a predetermined period without revealing the exact details (the amount and duration).

[0066] The user or user device 22 may generate the cryptographic commitment using a hash function or another cryptographic algorithm. This commitment may combine information about the amount of digital assets they intend to lock or have locked and the duration for which these assets will be locked. The actual values may not be directly stored or be visible on the blockchain, preserving the user's privacy. The cryptographic commitment may allow others (e.g., the smart contract 24 itself or third parties) to verify that the user has indeed locked an amount of assets for a certain duration without knowing the specific details. This verification may rely on the unique properties of cryptographic functions, where the commitment is computationally infeasible to reverse or guess without the original data that was committed.

[0067] A way to create a cryptographic commitment is by using a hash function. The user may hash a concatenation of the digital asset amount X and locking duration D (along with any additional nonce or random data to ensure uniqueness). The output hash may serve as the commitment C. Thus, in some embodiments, the cryptographic commitment C comprises a hash of the locked predetermined amount X of digital assets, the predetermined locking duration D, and a user-specific secret (pre-image). The commitment may include details like the amount locked, the expiration time of the lock, and a user secret (pre-image), e.g., H(amount, lock duration, secret). The commitment may be designed in such a way that these details cannot be directly extracted from it.

[0068] Method 10 or act 14 may include using a zero-knowledge proof (ZKP) protocol to generate a ZKP based on the cryptographic commitment C that the user has locked an amount of digital assets meeting or exceeding a threshold T specified by the online service.

[0069] ZKPs allow one party (the prover) to prove to another party (the verifier) that a certain statement is true without revealing any information beyond the validity of the statement itself. For example, the user or a person wishing to prove the existence of the time-locked digital assets would then create a ZKP related to this commitment. This ZKP would demonstrate that they have locked a specific amount of digital assets for a certain period without revealing the actual digital asset address or other sensitive details. The prover (user) wants to prove that they have locked an amount X which meets or exceeds a threshold T set by the online service, without revealing X. For this purpose, an appropriate ZKP protocol may be chosen that may support proving numerical conditions such as range proofs or threshold proofs. Examples include zk-SNARKs (Zero-Knowledge Succinct NonInteractive Argument of Knowledge) or zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge). The prover may construct a proof using their private inputs (X Z>, and nonce) and the public inputs (commitment C and threshold 7). The proof demonstrates that they know values X, Z>, and nonce such that C = D, nonce) and X> T, meaning the locked amount meets or exceeds the threshold. Using the chosen ZKP protocol, the prover may generate the proof P that satisfies the conditions above without revealing X, D, or nonce.

[0070] Method 10 or act 16 may include verifying the ZKP. For example, the user or user device 22 may submit the proof P along with the public commitment C to the online service 26 and / or to smart contract (as intermediate trusted entity). The online service 26, acting as the verifier, may use the ZKP protocol to verify proof P against the public commitment C and the known threshold T. This process may check the validity of the proof without requiring any knowledge of the private inputs. The verifier can check this proof against the commitment and verify that the crypto is indeed locked as claimed. Because it is a ZKP, the verifier learns nothing about the crypto address or any other details beyond the fact that the claimed amount is locked for the stated duration. If the proof P is valid, the online service 26 can be confident that the user has indeed locked an amount of digital assets meeting or exceeding the threshold Z, all without learning the exact amount X or any other private details. The online service 26 may grant access for the user to the online service in case the verification of the ZKP is successful.

[0071] In preparation for the ZKP, method 10 may include the user or user device 22 sending a hash of the locked amount of digital assets, the locking duration, and a hashed secret to the smart contract 24 (e.g., H(real_amount_locked, real lock duration, H(secret), where the values real amount locked, real lock duration, H(secret) come from a previously made lockup transaction by the smart contract 24). The smart contract 24 may store the received hash (e.g., H(real_amount_locked, real lock duration, H(secret)) as digital asset transactional data in the blockchain network. As schematically shown in Fig. 3, the smart contract 24 may add the received hash (e.g., H(real_amount_locked, real lock duration, H(secret)) as a new leaf 32 to a first Merkle tree 30 (Merkle Treel) representing digital asset transactional data. A Merkle tree, also known as a hash tree, is a data structure to efficiently summarize and verify the integrity of sets of data. A Merkle tree comprises leaf nodes which are the bottom-most nodes in the tree, each containing the hash of a data block. For example, each leaf of first Merkle tree 30 (Merkle Treel) may represent a single (locking) transaction's hash (e.g., H(real_amount_locked, re- al lock duration, H(secret)). Each parent node higher up in the tree may be created by taking the hash of the concatenation of its children's hashes. This process may repeat recursively up the tree. At the top of the tree 30 is a single node called the root or Merkle root 34. This node contains a single hash that effectively summarizes all the data in the leaf nodes below it. The hashes of individual data blocks (leaf nodes) may be paired and concatenated, then hashed again to produce the hashes of their parent nodes. This process may be repeated until a single hash (the Merkle root) remains. The root hash represents the entire dataset. Any change in the data would result in a different Merkle root.

[0072] Method 10 may include the smart contract 24 storing the root 34 of the first Merkle tree 30 (Merkle Treel) representing the digital asset transactional data in a block of the blockchain network and providing a copy of the first Merkle tree 30 (and / or its root 24) to the user. With this, the user or user device 22 may generate a first Merkle proof, for example, or use it otherwise for a ZKP protocol.

[0073] A Merkle proof is a concept to demonstrate the existence and integrity of a specific data element within a dataset, without revealing or needing to know the entire dataset. To provide a Merkle proof for a specific data element (e.g., H(real_amount_locked, real lock duration, H(secret)), the hash of the specific data block (e.g., H(real_amount_locked, re- al lock duration, H(secret)) is needed for which the proof is being generated. Further, a list of sibling hashes is needed These are the hashes of the data elements (sibling nodes) paired with the target data and its ancestors up the tree to the root. Finally, the Merkle root is needed which is the single hash at the top of the Merkle tree that represents the summary of all data in the tree. Given these components, the Merkle proof may verify that the target data block is indeed part of the dataset represented by the Merkle root. At a stage after the locking transaction, method 10 may further include the smart contract 24 receiving the cryptographic commitment (e.g., H(real_amount_locked, real lock duration, secret)) from the user device 22 and storing information on the cryptographic commitment on the blockchain network. For example, as illustrated in Fig. 3 (right), smart contract 24 may add the received cryptographic commitment (e.g., H(real_amount_locked, re- al lock duration, secret)) as a new leaf 37 to a second Merkle tree 35 (Merkle Tree2) representing a plurality of cryptographic commitments. The smart contract 24 may store a (updated) root 39 of the second Merkle tree 35 on the blockchain network and provide a copy of the second Merkle tree 35 (or its root 39) to the user.

[0074] With copy of the second Merkle tree 35 (or its root 39), the user may generate a second Merkle proof, for example. As such, method 10 may further include the user or user device 22 generating the second Merkle proof based on the copy of the second Merkle tree 35 and the cryptographic commitment 37. The second Merkle proof may be used for the ZKP protocol. For example, the second Merkle proof may be sent to the online service 26 and / or the smart contract 24 to prove that the user’s commitment is on the blockchain.

[0075] The ZKP protocol may prove the knowledge of a secret (pre-image) that hashes to a value in Merkle Treel with matching duration and amount. The ZKP protocol may further prove the inclusion of the cryptographic commitment in Merkle Tree2. The ZKP protocol may further prove that the amount in the cryptographic commitment exceeds a requested mini- mum amount and that the duration in the cryptographic commitment exceeds a requested minimum duration.

[0076] Merkle Treel contains leaves with digital asset transactional data: duration, amount, transac- tionlD, and Hash(secret). Merkle Treel serves as a public ledger of transactions with obscured secrets (pre-images). Merkle Tree2 contains cryptographic commitments for transactions: duration, amount, and secret (pre-image). The inclusion of the commitment in Merkle Tree2 can be proven using the second Merkle proof.

[0077] To prove transaction details and conditions, the user can generate the cryptographic commitment using duration, amount and secret (e.g., H(real_amount_locked, real lock duration , secret ) and use the values duration, amount and secret in the ZKP process. The user may produce the second Merkle proof showing the commitment's inclusion in Merkle Tree2. This may be done by presenting the second Merkle proof to online service 26. The second Merkle proof may be a series of cryptographic hashes that when properly combined, align with the root hash of Merkle Tree2.

[0078] Embodiments of the present disclosure may use a ZKP protocol (e.g., zk-SNARKs, Bullet- Proof, etc.) to construct proofs that demonstrate knowledge of a secret that, when hashed, matches the Hash(secret) in Merkle Treel, and prove that duration and amount from the commitment match a transaction in Merkle Treel (e.g., H(real_amount_locked, re- al lock duration, H(secret)), and verify that amount > minimum amount and duration > minimum duration.

[0079] The online service 26 may verify the ZKP against the public minimum amount and mini- mum duration, the root of Merkle Treel (for secret verification), and the second Merkle proof of inclusion in Merkle Tree2. Successful verification may confirm the validity of the claim and the compliance with the specified conditions without revealing the actual data (aka witness).

[0080] Fig- 4 shows a message sequence chart 40 illustrating an example operation of the smart contract 24 for generating ZKPs of cryptocurrency lockup without exposing user addresses.

[0081] At 41, user device 22 sends a cryptographic commitment to the smart contract 24, wherein cryptographic commitment comprises a hash of the predetermined amount of locked digital assets, the predetermined locking duration, and the user-specific secret (e.g., H(real_amount_locked, real lock duration, secret)).

[0082] At 42, smart contract 24 adds the received cryptographic commitment as new leaf 37 to the second Merkle tree 35 representing a plurality of cryptographic commitments and updates the root 39 of the second Merkle tree 35. Smart contract 24 may send a copy of the second Merkle tree 35 to user device 22.

[0083] At 43, user device 22 sends instructions to smart contract 24 for locking the predetermined amount of the user’s digital assets for the predetermined locking duration. This may also involve providing a hash of the locked amount of digital assets, the locking duration, and a hashed secret to the smart contract 24 (e.g., H(real_amount_locked, real lock duration, H(secret), where the values real amount locked, real lock duration, H(secret) come from the lockup transaction by the smart contract 24).

[0084] At 44, smart contract 24 locks the predetermined amount of the user’s digital assets for the predetermined locking duration. This may also involve adding the hash (e.g., H(real_amount_locked, real lock duration, H(secret)) as new leaf 32 to first Merkle tree 30 (Merkle Treel) representing digital asset transactional data.

[0085] The skilled person having benefit from the present disclosure will appreciate that the order of acts 41 to 44 may also be altered and that the user’s digital assets may be locked before the cryptographic commitment is added to the second Merkle tree 35.

[0086] At 45, user device 22 generates a ZKP based on the cryptographic commitment, the predetermined amount of digital assets, and the locking duration.

[0087] At 46, user device 22 sends the generated ZKP to smart contract 24 for verification. Alternatively, user device 22 may also send the generated ZKP to online service 26 for verification.

[0088] At 47, smart contract 24 (or online service 26) verifies the ZKP against the Merkle root of the second Merkle tree 35. The first Merkle tree 30 may also be used in the verification process.

[0089] After verification, smart contract 24 may send the verification result to online service 26, for example.

[0090] Fig. 5 shows a message sequence chart 50 of an example process of building a ZKP, including validating that the hashed information in a Merkle tree leaf represents a certain amount of cryptocurrency locked for a specific time period.

[0091] At 51, user device 22 generates data corresponding to locked digital asset amount A, locking duration D (along with any additional nonce or random data to ensure uniqueness) and sends (act 52) this data to an external tool or system for generating the cryptographic commitment C. Upon generating the hash, the external tool or system may send the hash back to the user as cryptographic commitment (act 53). At 54, the user may store the cryptographic commit- ment locally on user device 22, for example. The skilled person having benefit from the present disclosure will appreciate that the external tool or system is not necessarily needed for generating the cryptographic commitment. This could also be done locally on user device 22.

[0092] At 55, user adds the received cryptographic commitment as new leaf 37 to the second Merkle tree 35 representing a plurality of cryptographic commitments and updates the root 39 of the second Merkle tree 35. In the illustrated example, smart contract 24 is not involved in storing and updating the second Merkle tree 35. The Merkle root 39 or a copy of the second Merkle tree 35 is provided to user at 56.

[0093] At 57, user 22 locks the predetermined amount of the user’s digital assets for the predetermined locking duration. This may also involve sending 58, to smart contract 24 deployed on the blockchain network, instructions for locking the predetermined amount of the user’s digital assets for the predetermined locking duration. This may also involve adding the hash (e.g., H(real_amount_locked, real lock duration, H(secret)) as new leaf 32 to first Merkle tree 30 (Merkle Treel) representing digital asset transactional data. At 59, the locking transaction may be confirmed to the user 22. The skilled person having benefit from the present disclosure will appreciate that the order of acts 51 to 59 may also be altered and that the user’s digital assets may be locked before the cryptographic commitment is added to the second Merkle tree 35.

[0094] At 61, user device 22 may request the external tool or system to generate a ZKP based on the cryptographic commitment, the predetermined amount of digital assets, and the locking duration. At 62, the external tool or system provides the generated ZKP to user or user device 22 which can then provide the ZKP and other information (e.g., second Merkle proof) to online service 26 for verification.

[0095] The present disclosure proposes a smart contract 24 including a function to time-lock a specified amount of cryptocurrency for a predetermined duration. Users may interact with this function by sending their cryptocurrency to the smart contract that holds the funds until the time-lock period expires. Users may generate cryptographic commitments by hashing relevant data: the amount of cryptocurrency, the time-lock duration, and a unique identifier or nonce. These commitments are a cryptographic way to represent the locked funds without revealing the crypto address. The smart contract 24 may manage a Merkle tree, where each leaf node represents a user's hashed commitment. As new commitments are added by users, the smart contract 24 updates the Merkle tree and its root, ensuring an efficient and secure structure for storing and verifying commitments. Users may generate ZKPs to prove they have a commitment in the Merkle tree corresponding to a time-locked amount of cryptocurrency. The ZKP allows users to demonstrate the existence of their locked funds in the contract without revealing their specific commitment or personal details. The smart contract may provide functions to verify these ZKPs. When a user submits a ZKP, the smart contract may verify it against the stored Merkle root and the corresponding commitment, confirming the validity of the claim without exposing the user's address or the specific details of the locked funds.

[0096] Users may first lock their funds using the time-lock function of the smart contract. Then they may generate a cryptographic commitment related to this lockup and submit it to the smart contract, which adds it to the Merkle tree. To prove the lockup when requested, users generate a ZKP related to their commitment and submit it for verification. The smart contract may verify this proof against the Merkle tree, ensuring the integrity and privacy of the entire process.

[0097] In the following, some examples of the proposed concept are presented:

[0098] An example (e.g., example 1) relates to a method for providing conditional access to an online service, the method comprising using a smart contract deployed on a blockchain network to lock a predetermined amount of digital assets of a user for a predetermined locking duration, providing a proof to the online service that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service, verifying the proof, and obtaining access for the user to the online service in case the verification is successful.

[0099] Another example (e.g., example 2) relates to a previous example (e.g., example 1) or to any other example, further comprising denying access to the online service in case the verification is unsuccessful.

[0100] Another example (e.g., example 3) relates to a previous example (e.g., one of the examples 1 or 2) or to any other example, further comprising generating a cryptographic commitment to the locked amount of digital assets and the locking duration, using a zero-knowledge proof, ZKP, protocol to generate a ZKP based on the cryptographic commitment that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service, verifying the ZKP, and obtaining access for the user to the online service in case the verification of the ZKP is successful.

[0101] Another example (e.g., example 4) relates to a previous example (e.g., example 4) or to any other example, further comprising that the cryptographic commitment comprises a hash of the locked predetermined amount of digital assets, the predetermined locking duration, and a user-specific secret.

[0102] Another example (e.g., example 5) relates to a previous example (e.g., example 4) or to any other example, further comprising that the ZKP protocol comprises demonstrating knowledge of the user-specific secret of the cryptographic commitment matching a hashed secret of digital asset transactional data related to the locking recorded in the blockchain network.

[0103] Another example (e.g., example 6) relates to a previous example (e.g., one of the examples 4 or 5) or to any other example, further comprising that the ZKP protocol comprises demonstrating that the locked amount of digital assets and the locking duration of the cryptographic commitment match with digital asset transactional data related to the locking recorded in the blockchain network.

[0104] Another example (e.g., example 7) relates to a previous example (e.g., one of the examples 4 to 6) or to any other example, further comprising that the ZKP protocol comprises demonstrating that that the locked amount of digital assets and the locking duration exceed the threshold specified by the online service.

[0105] Another example (e.g., example 8) relates to a previous example (e.g., one of the examples 1 to 7) or to any other example, further comprising the smart contract receiving a hash of the locked amount of digital assets, the locking duration, a transaction ID, and a hashed secret, and storing the received hash as digital asset transactional data in the blockchain network.

[0106] Another example (e.g., example 9) relates to a previous example (e.g., example 8) or to any other example, further comprising the smart contract adding the received hash as a new leaf to a first Merkle tree representing digital asset transactional data, the smart contract storing a root of the first Merkle tree in a block of the blockchain network, and the smart contract providing a copy of the first Merkle tree to the user.

[0107] Another example (e.g., example 10) relates to a previous example (e.g., one of the examples 1 to 9) or to any other example, further comprising the smart contract receiving the cryptographic commitment from the user and storing information on the cryptographic commitment on the blockchain network.

[0108] Another example (e.g., example 11) relates to a previous example (e.g., example 10) or to any other example, further comprising that storing information on the cryptographic commitment on the blockchain network comprises the smart contract adding the received cryptographic commitment as a new leaf to a second Merkle tree representing a plurality of cryptographic commitments, the smart contract storing a root of the second Merkle tree on the blockchain network, and the smart contract providing a copy of the second Merkle tree to the user.

[0109] Another example (e.g., example 12) relates to a previous example (e.g., example 11) or to any other example, further comprising the user generating a Merkle proof based on the copy of the second Merkle tree and the cryptographic commitment, and using the Merkle proof for the ZKP protocol.

[0110] Another example (e.g., example 13) relates to a previous example (e.g., one of the examples 9 to 12) or to any other example, further comprising that the ZKP protocol comprises demonstrating knowledge of the user-specific secret of the cryptographic commitment matching the hashed secret in the first Merkle tree representing digital asset transactional data.

[0111] Another example (e.g., example 14) relates to a previous example (e.g., one of the examples 9 to 13) or to any other example, further comprising that the ZKP protocol comprises demonstrating that the locked amount of digital assets and the locking duration of the cryptographic commitment match with the hash of the locked amount of digital assets, the locking duration, the transaction ID, and a hashed secret in the first Merkle tree representing digital asset transactional data. Another example (e.g., example 15) relates to a previous example (e.g., one of the examples 9 to 14) or to any other example, further comprising that the ZKP protocol comprises using the threshold specified by the online service, the stored root of the first Merkle tree representing the plurality of digital asset transactions, and the Merkle proof of adding the cryptographic commitment as leaf node to the second Merkle tree representing the plurality of cryptographic commitments for verifying the ZKP.

[0112] Another example (e.g., example 16) relates to a previous example (e.g., one of the examples 1 to 15) or to any other example, further comprising the user sending instructions to the smart contract for locking the predetermined amount of the user’s digital assets for the predetermined locking duration.

[0113] Another example (e.g., example 17) relates to a previous example (e.g., one of the examples 1 to 16) or to any other example, further comprising the smart contract releasing the predetermined amount of digital assets to the user after the predetermined locking duration has elapsed.

[0114] Another example (e.g., example 18) relates to a previous example (e.g., one of the examples 1 to 17) or to any other example, further comprising that the digital assets comprise cryptocurrencies.

[0115] An example (e.g., example 19) relates to a method for a smart contract deployed on a blockchain network, the method comprising receiving instructions for locking a predetermined amount of a user’s digital assets for a predetermined locking duration, in response to the instructions, locking the predetermined amount of digital assets for the predetermined locking duration, and releasing the predetermined amount of digital assets to the user after the predetermined locking duration has elapsed.

[0116] Another example (e.g., example 20) relates to a previous example (e.g., example 19) or to any other example, further comprising receiving a hashed user-specific secret from the user, generating a hash of the locked amount of digital assets, the locking duration, and the hashed secret, and storing the hash as digital asset transactional data in the blockchain network. Another example (e.g., example 21) relates to a previous example (e.g., example 20) or to any other example, further comprising adding the hash as a new leaf to a first Merkle tree representing digital asset transactional data, storing a root of the first Merkle tree in a block of the blockchain network, and providing a copy of the first Merkle tree to the user.

[0117] Another example (e.g., example 22) relates to a previous example (e.g., one of the examples 19 to 21) or to any other example, further comprising receiving a cryptographic commitment from the user, the cryptographic commitment comprising a hash of the locked predetermined amount of digital assets, the predetermined locking duration, and a user-specific secret, storing information on the cryptographic commitment on the blockchain network.

[0118] Another example (e.g., example 23) relates to a previous example (e.g., example 22) or to any other example, further comprising that storing information on the cryptographic commitment on the blockchain network comprises adding the received cryptographic commitment as a new leaf to a second Merkle tree representing a plurality of cryptographic commitments, storing a root of the second Merkle tree on the blockchain network, and the smart contract providing a copy of the second Merkle tree to the user.

[0119] An example (e.g., example 24) relates to a method for user device, the method comprising sending, to a smart contract deployed on a blockchain network, instructions for locking a predetermined amount of a user’s digital assets for a predetermined locking duration, and requesting access to an online service, wherein requesting access comprises providing a proof to the online service that the user has locked an amount of digital assets meeting or exceeding a threshold specified by an online service.

[0120] Another example (e.g., example 25) relates to a previous example (e.g., example 24) or to any other example, further comprising that the instructions comprise the predetermined amount of digital assets, the locking duration, and a hashed user-specific secret.

[0121] Another example (e.g., example 26) relates to a previous example (e.g., example 25) or to any other example, further comprising receiving a copy of a first Merkle tree from the smart contract, the first Merkle tree comprising a leaf corresponding to a hash of the predetermined amount of digital assets, the locking duration, and the hashed user-specific secret. Another example (e.g., example 27) relates to a previous example (e.g., one of the examples 25 to 26) or to any other example, further comprising sending a cryptographic commitment to the smart contract, the cryptographic commitment comprising a hash of the predetermined amount of digital assets, the predetermined locking duration, and the user-specific secret.

[0122] Another example (e.g., example 28) relates to a previous example (e.g., example 27) or to any other example, further comprising receiving a copy of a second Merkle tree from the smart contract, the second Merkle tree comprising a leaf corresponding to the cryptographic commitment.

[0123] Another example (e.g., example 29) relates to a previous example (e.g., example 28) or to any other example, further comprising generating a Merkle proof based on the copy of the second Merkle tree and the cryptographic commitment, and sending the Merkle proof to the online service.

[0124] Another example (e.g., example 30) relates to a previous example (e.g., one of the examples 27 to 29) or to any other example, further comprising generating a ZKP based on the cryptographic commitment, the predetermined amount of digital assets, and the locking duration, and sending the ZKP to the online service.

[0125] An example (e.g., example 31) relates to a method for an online service, the method comprising receiving a request for access to the online service from a user, requesting a proof that the user has locked an amount of digital assets meeting or exceeding a threshold specified by an online service, and verifying the proof, and providing access for the user to the online service in case the verification is successful.

[0126] Another example (e.g., example 32) relates to a previous example (e.g., example 31) or to any other example, further comprising denying access to the online service in case the verification is unsuccessful.

[0127] Another example (e.g., example 33) relates to a previous example (e.g., one of the examples 31 or 32) or to any other example, further comprising that the proof comprises a ZKP based on a cryptographic commitment to a locked amount of digital assets and a locking duration, a minimum amount of digital assets, and a minimum locking duration meeting or exceeding the threshold specified by the online service.

[0128] The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

[0129] Examples may further be or relate to a (computer) program including a program code to execute one or more of the above methods when the program is executed on a computer, processor or other programmable hardware component. Thus, steps, operations or processes of different ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor- or computer-readable and encode and / or contain machine-executable, processor-executable or computer-executable programs and instructions. Program storage devices may include or be digital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ((F)PLAs), (field) programmable gate arrays ((F)PGAs), graphics processor units (GPU), application-specific integrated circuits (ASICs), integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

[0130] It is further understood that the disclosure of several steps, processes, operations or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execution of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and / or be broken up into several substeps, -functions, -processes or -operations.

[0131] If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system. The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Furthermore, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

Claims1. A method for providing conditional access to an online service, the method comprising using a smart contract deployed on a blockchain network to lock a predetermined amount of digital assets of a user for a predetermined locking duration; providing a proof to the online service that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service; verifying the proof; and obtaining access for the user to the online service in case the verification is successful.

2. The method of claim 1, further comprising denying access to the online service in case the verification is unsuccessful.

3. The method of claim 1, comprising generating a cryptographic commitment to the locked amount of digital assets and the locking duration; using a zero-knowledge proof, ZKP, protocol to generate a ZKP based on the cryptographic commitment that the user has locked an amount of digital assets meeting or exceeding a threshold specified by the online service; verifying the ZKP; and obtaining access for the user to the online service in case the verification of the ZKP is successful.

4. The method of claim 4, wherein the cryptographic commitment comprises a hash of the locked predetermined amount of digital assets, the predetermined locking duration, and a user-specific secret.

5. The method of claim 4, wherein the ZKP protocol comprises demonstrating knowledge of the user-specific secret of the cryptographic commitment matching a hashed secret of digital asset transactional data related to the locking recorded in the blockchain network.

6. The method of claim 4, wherein the ZKP protocol comprisesdemonstrating that the locked amount of digital assets and the locking duration of the cryptographic commitment match with digital asset transactional data related to the locking recorded in the blockchain network.

7. The method of any one of claims 4, wherein the ZKP protocol comprises demonstrating that that the locked amount of digital assets and the locking duration exceed the threshold specified by the online service.

8. The method of claim 1, further comprising the smart contract receiving a hash of the locked amount of digital assets, the locking duration, a transaction ID, and a hashed secret; and storing the received hash as digital asset transactional data in the blockchain network.

9. The method of claim 8, further comprising the smart contract adding the received hash as a new leaf to a first Merkle tree representing digital asset transactional data; the smart contract storing a root of the first Merkle tree in a block of the blockchain network; and the smart contract providing a copy of the first Merkle tree to the user.

10. The method of claim 1, further comprising the smart contract receiving the cryptographic commitment from the user and storing information on the cryptographic commitment on the blockchain network.

11. The method of claim 10, wherein storing information on the cryptographic commitment on the blockchain network comprises the smart contract adding the received cryptographic commitment as a new leaf to a second Merkle tree representing a plurality of cryptographic commitments; the smart contract storing a root of the second Merkle tree on the blockchain network; and the smart contract providing a copy of the second Merkle tree to the user.

12. The method of claim 11, further comprisingthe user generating a Merkle proof based on the copy of the second Merkle tree and the cryptographic commitment; and using the Merkle proof for the ZKP protocol.

13. The method of claim 9, wherein the ZKP protocol comprises demonstrating knowledge of the user-specific secret of the cryptographic commitment matching the hashed secret in the first Merkle tree representing digital asset transactional data.

14. The method of claim 9, wherein the ZKP protocol comprises demonstrating that the locked amount of digital assets and the locking duration of the cryptographic commitment match with the hash of the locked amount of digital assets, the locking duration, the transaction ID, and a hashed secret in the first Merkle tree representing digital asset transactional data.

15. The method of claim 9, wherein the ZKP protocol comprises using the threshold specified by the online service, the stored root of the first Merkle tree representing the plurality of digital asset transactions, and the Merkle proof of adding the cryptographic commitment as leaf node to the second Merkle tree representing the plurality of cryptographic commitments for verifying the ZKP.

16. The method of claim 1, further comprising the user sending instructions to the smart contract for locking the predetermined amount of the user’s digital assets for the predetermined locking duration.

17. The method of claim 1, further comprising the smart contract releasing the predetermined amount of digital assets to the user after the predetermined locking duration has elapsed.

18. A method for a smart contract deployed on a blockchain network, the method comprising receiving instructions for locking a predetermined amount of a user’s digital assets for a predetermined locking duration;in response to the instructions, locking the predetermined amount of digital assets for the predetermined locking duration; and releasing the predetermined amount of digital assets to the user after the predetermined locking duration has elapsed.

19. A method for user device, the method comprising sending, to a smart contract deployed on a blockchain network, instructions for locking a predetermined amount of a user’s digital assets for a predetermined locking duration; and requesting access to an online service, wherein requesting access comprises providing a proof to the online service that the user has locked an amount of digital assets meeting or exceeding a threshold specified by an online service.

20. A method for an online service, the method comprising receiving a request for access to the online service from a user; requesting a proof that the user has locked an amount of digital assets meeting or exceeding a threshold specified by an online service; and verifying the proof; and providing access for the user to the online service in case the verification is successful.

Images