High-speed blockchain payment method and system

Abstract

A method for high-speed blockchain payments is disclosed, where the payment involves a transfer of funds from a user's (110) account to a private collateral account of a service provider (120). According to an embodiment, the method includes the steps of receiving, by the service provider (120), a private intention to pay from the user (110), where the private intention to pay includes a payment index, a random payment ID, and an address of the private collateral account of the service provider (120); modifying, by the service provider (120), the intention to pay by replacing the address of the collateral account of the service provider (120) with a commitment and providing the modified intention to pay to a majority of state keepers (130) of the blockchain (140); and updating, by the service provider (120), the state of the blockchain (140). The method includes the steps of: receiving payment authorizations from the state keeper (130), each payment authorization including a modified payment intent signed with the private key of the respective state keeper (130); evaluating the received payment authorizations, by the service provider (120), aggregating the successfully evaluated payment authorizations, and sending the aggregation result to the user (110); receiving, by the service provider (120), a final transaction created by the user (110) after verifying the aggregation result, verifying that the user (110) has correctly constructed the final transaction according to a given protocol, and accepting the payment if the verification of the final transaction is successful.

Description

[Technical field]

[0001] The present invention relates to a method, system, and computer-readable medium for high-speed blockchain payments. [Background technology]

[0002] Digital currencies implemented as permissionless blockchains such as Ethereum offer a fundamentally different alternative to traditional payment systems. One of the most notable differences is that there is no or only a few centralized entities that control the balances or payments of all user accounts. Instead, each transaction is approved by a large decentralized system in which anyone can participate. This provides a strong guarantee that prevents any entity from censoring payments.

[0003] However, such systems are not practical for scenarios such as retail or online payments. In particular, they have high latency and no on-chain privacy, which makes them unusable for everyday small payments. Means exist to address these shortcomings. The most prominent technique is to leverage smart contracts, which provide additional functionality. In addition to standard blockchain payments, two types of such systems can be identified that are relevant for retail payments: those that offer low latency and those that offer on-chain privacy.

[0004] There are several techniques that address the latency issue through smart contracts. Payment channels allow users to establish a relationship with a single service provider. However, they require a separate fixed collateral for each such relationship, which is impractical. Payment hubs connect users to multiple service providers, but the fixed collateral is large and therefore not scalable to a larger number of registered users. Sidechains allow payments to be quickly approved by a smaller set of validating entities, but introduce additional trust assumptions and high communication complexity. On the one hand, the Snappy payment system (for reference, see V. Mavroudis, K. Wust, A. Dhar, K. Kostiainen, and S. Capkun: “Snappy: Fast On-Chain Payments with Practical Collaterals”, 27th Annual Network and Distributed System Security (NDSS) Symposium 2020, 23-26 February 2020, San Diego, CA, USA, https: / / www.ndss-symposium.org / wp-content / uploads / 2020 / 02 / 24049-paper.pdf) uses small user collateral but violates the strong censorship-resistance guarantees of permissionless blockchains.

[0005] On the other hand, the Zether payment system (for reference, see B. Bunz, S. Agrawal, M. Zamani, and D. Boneh: "Zether: Towards Privacy in a Smart Contract World", July 2020, pp. 423-443, https: / / crypto.stanford.edu / ~buenz / papers / zether.pdf) addresses on-chain privacy by providing confidential and anonymous transactions. It has much stronger security and privacy guarantees than standard blockchain transactions, but its payments are slow, as the system does not provide any mechanism to address the latency issue.

[0006] We observe that most systems offer only very specific additional features while often violating other properties. In the current prior art, there is no system that offers (a) fast payments, (b) censorship resistance, (c) small collateral, (d) on-chain privacy, and (e) no additional trust assumptions. [Prior art documents] [Non-patent literature]

[0007] [Non-Patent Document 1] V. Mavroudis, K. Wust, A. Dhar, K. Kostiainen, and S. Capkun: "Snappy: Fast On-Chain Payments with Practical Collaterals," 27th Annual Network and Distributed System Security (NDSS) Symposium 2020, 23-26 February 2020, San Diego, CA, USA, https: / / www.ndss-symposium.org / wp-content / uploads / 2020 / 02 / 24049-paper.pdf [Non-Patent Document 2] B. Bunz, S. Agrawal, M. Zamani, and D. Boneh: "Zether: Towards Privacy in a Smart Contract World", July 2020, pages 423~443, https: / / crypto.stanford.edu / ~buenz / papers / zether.pdf

Non-patent document 3

Non-patent document 4

Non-patent document 5

Non-patent document 6

[0008] It is therefore an object of the present invention to improve and further develop methods and systems for high speed blockchain payments such that at least some of the above mentioned drawbacks are mitigated or overcome. [Means for solving the problem]

[0009] According to the present invention, the aforementioned object is achieved by a computer-implemented method for fast blockchain payments, where the payment involves a transfer of funds from a user's account to a private collateral account of a service provider, the method comprising the steps of: receiving, by the service provider, a private payment intention from the user, where the private payment intention includes a payment index, a random payment ID, and an address of the private collateral account of the service provider; modifying, by the service provider, the payment intention by replacing the address of the collateral account of the service provider by a commitment and providing the modified payment intention to a majority of the blockchain statekeepers; receiving, by the service provider, payment authorizations from the blockchain statekeepers, where each payment authorization includes the modified payment intention signed with the private key of the respective statekeeper; evaluating, by the service provider, the received payment authorizations, aggregating the successfully evaluated payment authorizations, and sending the aggregation result to the user; receiving, by the service provider, a final transaction created by the user after verifying the aggregation result, verifying that the user has correctly constructed the final transaction according to a given protocol, and accepting the payment if the validation of the final transaction is successful.

[0010] Furthermore, the above mentioned object is achieved by a system for high speed blockchain payments and by a non-transitory processor-readable medium according to the independent claims.

[0011] Embodiments of the present invention provide a blockchain payment method and system that takes a hybrid approach providing both fast and private payments with real collateral, and strong security guarantees, including censorship-resistance and no additional trust assumptions.

[0012] According to one embodiment of the present invention, a random payment ID of a user's payment intention is generated by computing a verifiable random function VRF hash of the payment index. In this regard, it is noted that a verifiable random function (VRF) is a public-key version of a keyed cryptographic hash (for reference, see S. Goldberg, L. Reyzin, D. Papadopoulos, and J. Vcelak, "Verifiable Random Functions (VRFs)", Internet Engineering Task Force, Internet-Draft draft-irtf-cfrg-vrf-09, May 2021, in progress [online]. Available: https: / / datatracker.ietf.org / doc / html / draft-irtf-cfrg-vrf-09). Anyone in possession of the public key pk can verify the correctness of the hash, but only the owner of the private key sk can generate the hash. More precisely, given an input value x, the owner of the private key sk can compute a hash y=VRFhash(sk,x) for the input x. The owner of the private key can also compute a match proof π = VRFprove(sk,x). An important property of VRF is that the hash algorithm is deterministic in the sense that it always produces the same output y given the same pair of inputs (sk,x). Using the public key and the proof, it is possible to verify that the hash was computed correctly. Given pk, x, and π, if VRFverify(pk,x,π) outputs valid, then the hash is valid. Anyone can deterministically obtain the VRF output y from the proof π by computing y = VRFproof2hash(π).

[0013] Embodiments of the present invention take advantage of one or more of the following properties of VRF: Trusted Uniqueness: Assuming that keys are generated in a trustworthy manner, i.e., with correct randomness, a computationally limited adversary cannot find two proofs π1 and π2 for pk, x, two distinct hash outputs y1 and y2, such that both VRFverify(pk, x, π1) and VRFverify(pk, x, π2) validly output them. Reliable collision resistance: Assuming the keys were generated in a trustworthy manner, it should be computationally infeasible for an adversary to find x1 and x2 that have the same hash output, even if they know the private key. Complete pseudorandomness: An adversarial verifier cannot distinguish between a genuine hash output y and a random hash output without knowing the proof of the genuine hash. The adversary is allowed to observe the output hashes and proofs for various chosen inputs at any time.

[0014] According to one embodiment of the present invention, the modification by the service provider of the payment intent received from the user is to update the address of the collateral account of the service provider to a commitment c m =C(m,r m ), where m is the address of the service provider's collateral account, and r mis a random blinding factor and C is a commitment function. In general, the goal of cryptographic commitments is to commit a value that remains hidden and reveal it at a later point in time. The Pedersen commitment is one particular variant of such a scheme. It provides a commitment that is fully concealing (a computationally unbounded adversary cannot learn anything about the original message) and computationally binding (a computationally bounded adversary cannot compute two different messages for the same commitment). Furthermore, Pedersen commitments are homomorphic, which means that two commitments can be combined without requiring knowledge of either the original messages or the blinding factors. More information on Pedersen commitments can be found in T. P. Pedersen, "Non-interactive and information-theoretic secure verifiable secret sharing," in Advances in Cryptology - CRYPTO '91, 1992, pp. 129-140, which is incorporated herein by reference.

[0015] According to one embodiment of the present invention, it may be provided that the service provider evaluates the private payment intention received from the user by verifying the correctness of a zero-knowledge proof computed by the user to indicate that the user's balance is sufficient to make the payment.

[0016] According to one embodiment of the present invention, it may be provided that the service provider evaluates the private payment intent received from the user by verifying the correctness of a zero-knowledge proof computed by the user against the user's collateral balance to indicate that the sum of all pending payments, including the current payment, is less than the user's current collateral balance.

[0017] According to one embodiment of the present invention, the payment authorization from the blockchain statekeeper may include a BLS signature computed by each statekeeper over the modified intent to pay using the private key of the respective statekeeper. BLS (Boneh-Lynn-Shacham) digital signatures (see for reference D. Boneh, B. Lynn, and H. Shacham, "Short signatures from the Weil pairing", in Advances in Cryptology - ASIACRYPT 2001, pp. 514-532, 2001) are a signature scheme that provides short and secure digital signatures. Furthermore, multiple signatures σ1, ..., σ from different signers may be used. n into a single signature. For simplicity, the user provides functions Sign(sk,m), Vf(pk,m,σ), and AggrSig({σ1,...,σ n}), AggrPk({pk1,...,pk n}) can be assumed.

[0018] According to one embodiment of the present invention, once the service provider receives payment authorizations from at least half of the state keepers, it verifies the state keepers' signatures of the modified payment intention using each state keeper's public key and aggregates the successfully verified signatures to obtain an aggregated authorization signature.

[0019] According to one embodiment of the present invention, a smart contract executed in the blockchain may be used to manage the user's collateral account, the service provider's collateral account, and each of the collateral accounts of the blockchain's state keeper, where the smart contract stores a dictionary that maps account addresses to ElGamal homomorphic encrypted values. A smart contract is software that runs on the blockchain and provides an interface to interact with data. In other words, a smart contract is a computer program or transaction protocol that is configured to automatically execute and operate on the blockchain. Specifically, a smart contract is a processor-executable program (code) stored on a non-transitory processor-readable medium that, when executed by a processing circuit, causes the processing circuit to perform program functions. The code is available (i.e., can be inspected) to all members present on the network. Those skilled in the art will recognize that a "smart contract" is a technical aspect of a blockchain network used, for example, for automation, and is not a legal or other means of constraining human activity.

[0020] According to one embodiment of the present invention, upon receiving the payment, a smart contract executing in the blockchain may, in a next action, finalize the payment to transfer funds from the user to the service provider. If successful, the smart contract may store the random payment ID, the service provider's committed address, the aggregated approval signature, and a quorum of approving state keepers in a list of the user's finalized transactions.

[0021] According to one embodiment of the present invention, it may be provided that the user's final transaction in the smart contract is performed using encrypted payment amounts in the user's and service provider's private accounts.

[0022] According to one embodiment of the present invention, it may be provided that a smart contract executed within the blockchain is used to process a payment request initiated by a service provider if a transaction does not appear on the blockchain after a predefined or configurable time.

[0023] According to one embodiment of the present invention, it may be provided that the service provider directs a settlement request to the user or the Statekeeper to be reimbursed through a confidential payment from either the user's private collateral account or the respective Statekeeper's private collateral account.

[0024] There are several ways in which the teaching of the present invention can be designed and further developed in an advantageous manner. For this purpose, reference should be made on the one hand to the dependent claims and on the other hand to the following description of preferred embodiments of the invention, which are illustrated by way of example in the figures. In connection with the description of preferred embodiments of the present invention with the aid of the figures, preferred embodiments and further developments of the present teaching are generally described. [Brief description of the drawings]

[0025] [Figure 1] 1 is a table illustrating Snappy data structures used in a system according to an embodiment of the present invention. [Diagram 2] 1 is a table illustrating Zether functions used in a system according to an embodiment of the present invention. [Diagram 3] 4 is a table showing a data structure of a transaction format used in a system according to an embodiment of the present invention. [Figure 4] 1 is a table showing the data structure of a smart contract used in a system according to an embodiment of the present invention. [Diagram 5] FIG. 2 is a schematic diagram illustrating a payment process between a user and a service provider according to an embodiment of the present invention. [Figure 6] FIG. 1 illustrates a change of payment intention performed according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0026] 1 to 4 are examples of notifications used in the embodiments of the present invention described in detail below.

[0027] Apart from regular blockchain transactions, there are countless other payment systems that sit on top of the blockchain as smart contracts. These systems introduce optional additional features, mainly to provide specific properties not offered by regular blockchain transactions. In the current prior art, they can be classified into three main types of payment systems, mainly related to scenarios such as retail or online stores:

[0028] 1. Standard blockchain payment. For example, in Ethereum, such a transaction only contains the sender, the recipient, the payment amount, and a digital signature created by the sender's account. Once the transaction is mined and finalized on the blockchain, the payment value is transferred from the sender's account to the recipient's account.

[0029] Due to their simplicity, such payments have low fees but are slow as they require waiting (usually a few minutes) until the transaction is securely finalized on the blockchain, making such payments impractical for small and fast payments in everyday use. However, their main advantage over, for example, credit card providers, is that these blockchain payments are decentralized and therefore there is no specific entity that could block the transaction.

[0030] 2. Fast blockchain payments. To address the latency issue, there are systems implemented as smart contracts that allow fast confirmation of payments. The main idea is that users deposit collateral into the smart contract. This collateral is used to provide a guarantee to the receiving service provider so that they can accept the payment before it is finalized on the blockchain. There are several systems that use such mechanisms.

[0031] Payment channels allow for the establishment of relationships between specific users and service providers. Such channels allow for the creation of multiple transactions without submitting all transactions to the blockchain network. In particular, it is possible to combine hundreds or thousands of transactions into a single blockchain transaction. However, such channels are not practical for retail payments, as users would need to set up payment channels with every service provider individually. This results in high collateral being fixed and is not scalable for users.

[0032] Payment hubs, on the other hand, allow a user to communicate with several service providers. In this case, the user registers in a single smart contract that connects the user with multiple service providers. Upon registration, the user also needs to deposit collateral as a guarantee. The main drawback in such systems is that the size of the collateral that the hub operator needs to place scales with the total amount of registered users in the system and is therefore very large. Therefore, such systems are not scalable for larger deployment scenarios.

[0033] Sidechains are an alternative that rely on a smaller set of transaction validators, who collectively track and approve incoming transactions. However, the main problem with such systems is their trust assumptions. In particular, at least 2 / 3 of the validators must be trusted. Moreover, these systems usually communicate via BFT (Byzantine Fault Tolerance) protocols, which have a high degree of complexity and are therefore costly in terms of latency and computational effort.

[0034] The Snappy payment system (already described above), which constitutes the criteria for embodiments of the present invention, allows for fast approval of payments with small amounts of user collateral. This is achieved through a mechanism whereby each transaction is approved by a state-keeping entity. The state-keeper acts as an untrusted entity that collectively tracks and approves Snappy transactions. As the state-keeper guarantees most merchants a fixed transaction fee (as opposed to a value-based fee from, for example, a credit card provider), it can be assumed that most merchants will also act as state-keepers. The state-keeper also requires the deposit of collateral during a one-time registration process.

[0035] The main advantage of Snappy is that the user collateral only needs to cover the expenditures of a particular user, i.e. it does not depend on any other factors. On the other hand, the statekeeper collateral grows according to the total sales in the system. This is acceptable, since the service provider, acting as the statekeeper, benefits from low fixed payment fees. These fees are much lower compared to credit card providers.

[0036] 3. Private Blockchain Payments. It is possible to achieve on-chain privacy through smart contracts as well. An embodiment of the invention uses the private payment system Zether (already mentioned above) as a benchmark. By using the zero-knowledge proof system Σ-Bullets, it manages custom accounts that store and transfer encrypted amounts, thus providing confidential (and optionally anonymous) payments on top of a permissionless blockchain. Such a system has strong security and privacy guarantees in contrast to standard blockchain payments.

[0037] Each of the above mentioned payment systems offers interesting properties, however, they still have notable limitations and drawbacks.

[0038] Vulnerability to censorship. Resistance to censorship is one of the main motivations for using permissionless blockchains for payments. However, in fast payment systems like payment hubs, sidechains, and Snappy, these guarantees are broken. This is because a transaction can only be safely accepted if the approval of the majority of state-keeping entities is received. It is recalled that the state-keeping entities are usually other competing service providers. Since statekeepers receive approval requests in plaintext with details of the intent to pay, they can perform arbitrary censorship against certain service providers or users. This is a real threat in competitive environments such as retail or online stores. Therefore, the security properties offered by fast blockchain payment systems leveraging majority approvals are weak and do not offer any advantage over other existing systems such as credit card providers, especially with regard to censorship.

[0039] Lack of confidentiality and anonymity. Another particular limitation of fast payment systems is weak privacy. For example, in Snappy, users register in the system with their main blockchain account. Thus, all transactions are traceable to their identity. All data in such systems is publicly available, thus allowing anyone to perform profiling of all users. This can be exploited, for example, for marketing purposes or political purposes. Such profiling can raise even stronger privacy concerns than, for example, payments by credit card.

[0040] Apart from user profiling, current fast payment systems also expose important business information of the service provider to the public. In particular, all transaction details are publicly stored in plaintext in the state of the smart contract. It is therefore possible to track each service provider's transactions and thus obtain information about its sales. In a retail or online business competitive scenario, this is a real drawback of using such a system.

[0041] Security over practicality. Payment systems exist that do not have the above problems. In particular, private payment systems, in contrast to fast payment systems, introduce strong security and privacy guarantees. By design, they are resistant to any censorship and do not allow any profiling of their user base. However, such systems are not practical in real-world scenarios such as retail and online payments. In particular, such systems do not offer any mechanism to reduce confirmation latency and therefore suffer from the same latency issues as regular blockchain payments.

[0042] In view of the above, the proposed system and method according to embodiments of the present invention adopts a hybrid approach that provides both fast and private payments. According to embodiments, the proposed payment method / system has the further property of being flexible by design and can be deployed in different scenarios depending on whether public, confidential or anonymous payments are desired. In particular, it is designed to be censorship-resistant, regardless of whether public, confidential or anonymous deployment scenario is chosen.

[0043] According to one embodiment of the present invention, the payment method / system accepts payments at similar speeds as Snappy, i.e., it provides both a payment protocol and a settlement protocol that are designed around particularly strong security and privacy guarantees compared to Snappy, and the process is compatible with improved Zether-style private accounts for payments and collateral.

[0044] In contrast to Snappy, the payment method / system according to the embodiments of the present invention provides and manages its own (private) accounts. This allows for easier integration of both private payments and private settlements. The management can be performed by a dedicated smart contract. In addition to Zether-style accounts, the payment method / system according to the embodiments of the present invention also introduces a new type of private collateral account. To allow settlement claims to be transferred confidentially, these collateral accounts are managed completely differently compared to common Zether-style accounts.

[0045] The exact details of the individual steps in the payment process according to an embodiment of the invention are completely changed for Zether. In particular, the service provider and the user create a new type of payment intent that hides all details and guarantees resistance to any censorship from the state keeper. In addition to that, since every account contains an encrypted balance, the service provider verifies the zero-knowledge proof created by the user to ensure that the private collateral balance is sufficient to cover the pending payment. Finally, the finalized transaction in the payment system smart contract is executed using the encrypted payment amount in the private account. All of these mechanisms provide fast payments that are secure (censorship-resistant) and private (confidential and anonymous).

[0046] According to an embodiment of the present invention, the settlement process, in contrast to Snappy, can be split into two separate functions for charging different entities. In particular, a process for charging the user and a process for charging the Statekeeper can be provided. In both cases, the process is completely redesigned to allow the service provider to be reimbursed through confidential payments from a newly introduced private secured account.

[0047] All of the above mechanisms contribute to a new and unique payment system with properties not achieved in any previous system. In conclusion, the solution according to the embodiments of the present invention results in a system that is fast, censorship-resistant, confidential, anonymous, has small user collateral, and does not require any additional trust assumptions.

[0048] The main technical challenges that need to be overcome in order to build such a new system are:

[0049] censorship: The service provider needs a majority approval for each payment. In particular, the statekeeper needs to ensure that it has not signed a conflicting transaction for a particular user. Thus, the service provider needs some notion of the identity of the user. In previous designs of fast payment systems (Snappy), the statekeeper approves a payment intent that includes the identity of the user, the identity of the service provider, and the payment value, all in plaintext. This automatically introduces a failure link, since the statekeeper can intentionally censor a particular user or service provider. It is recalled that if the service provider does not receive signatures from a majority of statekeepers, it cannot safely accept the payment. This is considered a real threat in a typical retail payment scenario, where the service provider takes on the role of the statekeeper. A set of colluding service providers (statekeepers) may decide not to process any payments of another conflicting victim service provider. To prevent censorship in a decentralized payment system like Snappy, the payment method / system according to an embodiment of the present invention is designed to meet three high-level goals (a.-c.):

[0050] a. Payment Value-Based Censorship. The first goal towards censorship resistance is to hide the payment price. The main problem is that a malicious statekeeper may be able to infer the identity of the recipient based on the payment price. A particular item is almost uniquely identifiable according to its price. Thus, a malicious statekeeper may still discriminate against a particular service provider in certain cases. Similarly, in certain scenarios, a malicious statekeeper may discriminate against a particular user. A malicious statekeeper may prevent a targeted user from buying any item if it can somehow infer what was purchased. The goal of this mitigation is that a statekeeper cannot discriminate against a service provider (or user) based on the transaction value.

[0051] b. Service provider identity-based censorship. In simple designs such as in Snappy, the statekeeper receives the identity of the service provider in plaintext. This is to ensure that no one can create a second transaction for a different transaction that conflicts with the approved transaction. In such designs, the statekeeper can still see in plaintext who the recipient of a payment is. Thus, the statekeeper may perform censorship based on the identity of the service provider (recall that the statekeeper is usually other competing service providers). Therefore, it is desired that all service providers are treated equally. More precisely, the goal is to hide the identity of the service provider from the statekeeper during the payment approval process. The rationale is that if the statekeeper does not know who the payment recipient (service provider) is, it cannot discriminate against a particular service provider by selectively blocking that payment. It is noted that a blanket DoS attack in which the statekeeper does not approve any payments is of course possible.

[0052] c. User Identity-Based Censorship. The statekeeper needs to check if it has already signed a transaction for a particular user and payment index. In a simple design, as in traditional systems, the payment intent would simply contain the user's identity. Thus, the statekeeper can discriminate against certain users since the user's address is available in plaintext in the payment intent. This is perhaps the most difficult problem to solve, since the statekeeper needs to know some association with the user's identity.

[0053] privacy: An embodiment of the present invention leverages techniques introduced in private payment systems and combines it with the design of a Snappy-like system that supports fast payments. In this regard, one of the problems is to devise a system that offers the same security guarantees as fast payment systems, but does not compromise any privacy guarantees offered by private payment systems. The main challenges throughout the private payment and private settlement process are:

[0054] Private Payment Process. In a simple design, one could devise a payment process similar to, for example, the Snappy payment system, with the difference that the final step in the smart contract simply triggers a payment in an existing private payment system like Zether. Such a design has several drawbacks. First of all, Snappy would violate the privacy guarantees of private payment systems, since it would disclose the user's details. Furthermore, it would also violate Snappy's security guarantees. In particular, the service provider would need to check whether the collateral of the user or the state keeper is sufficient to cover current and all pending transactions. As all payments involve encrypted amounts, the payment process would need to provide additional mechanisms to enable such checks.

[0055] Private settlement process. Most of the issues arise regarding the correct processing of settlement requests. In particular, the statekeeper needs to verify whether there are conflicting transactions in the system, i.e. whether a certain user has made two different transactions related to the same payment index.

[0056] According to an embodiment, the present invention provides a payment method / system that supports fast, secure and anonymous payments as well as confidential settlement.

[0057] To allow for censorship-resistance, embodiments of the present invention implement at least one of obfuscating the payment value, obfuscating the identity of the service provider, and obfuscating the identity of the user.

[0058] Obfuscating Payment Values. One of our main observations is that the statekeeper does not need to know the amount of each approved payment. Previously, a Snappy transaction was uniquely identified given all four values: the Snappy index, the user's address, the service provider's address, and the payment value. However, if a triplet containing only the payment index, the user's address, and the service provider's address is unique, it is sufficient to consider the transaction unique.

[0059] Obfuscating the identity of the service provider. Additionally, it is recognized that the Snappy protocol can be modified such that the address of the service provider remains hidden from statekeepers during payment authorization, preventing censorship against the service provider. The main technical challenge is to hide the address so that it is still securely bound to the payment authorization and can be revealed later for settlement if necessary. In this context, embodiments of the present invention leverage Pedersen commitments, which allow the service provider to blind the address for the duration of the payment authorization and assess additional costs.

[0060] The idea is that the service provider must first obtain the payment intention INT from the user. c Upon receiving,the service provider converts the addresses in the payment intention into,Pedersen commitments,c,=,C(τ,),, where,r,is a random blinding value. m The state keeper signs the intent to pay, including the blinded identity of the service provider. The commitment is only opened when the service provider needs to request a payment, in which case an entity acting as an arbiter verifies it.

[0061] Obfuscating User Identity: According to an embodiment of the present invention, censorship is prevented by replacing the user payment intent address with a Randomized Payment ID (RPID) that is generated using a separately verifiable Random Function (VRF) for each payment.

[0062] More precisely, upon registration, a user may generate a VRF key pair. The VRF public key is registered in the payment system's smart contract together with the user's deposit, and the user keeps the private key to himself. For each new payment, the user uses the private key to generate a new RPID as VRF output using the current (monotonically increasing) payment index as VRF input. The user also creates a VRF proof that allows the service provider to verify that the RPID was correctly created for the current payment index. The State Keeper authorizes only one payment per RPID.

[0063] The security and privacy guarantees of such mitigation depend on two properties of VRFs. The first property is uniqueness, which ensures that only one correct VRF output (in this case, RPID) can be generated for the same VRF input (in this case, payment index). A malicious user cannot create multiple RPIDs for the same index, and the state keeper tracks double-spends per payment index, so a malicious user cannot double-spend. The second property is pseudorandomness, which ensures that every RPID cannot be linked to the user's address, or to any previous RPID used by the same user. This prevents the state keeper from censoring payments based on the user's identity.

[0064] To allow for privacy of payments, i.e. to provide strong privacy guarantees during payments, embodiments of the present invention leverage Zether-style transactions that transfer funds from users to service providers confidentially (or possibly anonymously). These payments can be processed in the same way as Zether (i.e., encrypted payment values ​​are transferred using zero-knowledge proofs). However, according to embodiments, further improvements can be introduced in the payment process to provide assurances to the service provider. This consists of an additional zero-knowledge proof of the user and a signature to sign the payment request that can be used later during settlement to show that the collateral is sufficient to cover the payment value.

[0065] Thus, embodiments of the present invention provide a payment method / system that achieves the following aspects: 1. Use a commitment scheme to hide payment values ​​and use VRF to hide user identities. 2. Use range proofing to prove balance when making payments. 3. Combine the above with a payment collateral system to achieve privacy-preserving, censorship-resistant, and fast payments on the blockchain.

[0066] An embodiment of the present invention uses two types of accounts: user accounts and collateral accounts. User accounts can be used to freely transfer funds to other user accounts. Collateral accounts, on the other hand, are managed only by the smart contract and are used in settlement claims. The main idea is that users deposit collateral in the smart contract. This collateral is used to provide a guarantee to the receiving service provider so that the receiving service provider can accept the payment before it is finalized on the blockchain.

[0067] For both types of accounts, the balance is stored as a ciphertext. In this regard, a smart contract may be provided to store a dictionary that maps account addresses (i.e., ElGamal public keys) to ElGamal homomorphically encrypted values.

[0068] For user accounts, embodiments of the present invention assume the same model as existing private payment systems such as Zether (disclosed in B. Bunz, S. Agrawal, M. Zamani, and D. Boneh: “Zether: Towards Privacy in a Smart Contract World”, July 2020, pp. 423-443, https: / / crypto.stanford.edu / ~buenz / papers / zether.pdf, incorporated herein by reference). In particular, accounts are managed in epochs. The receiving account stores incoming transactions in a pending list and rolls them over to the account balance only at the end of each epoch. This prevents front-running of transactions. Additionally, embodiments of the present invention may leverage zero-knowledge proofs for user accounts of the same type as described in the Zether reference above.

[0069] Collateral accounts are similar to user accounts but are managed differently. In particular, transfers, except for registration and deregistration, can only be triggered internally by smart contracts during settlement. Furthermore, the zero-knowledge proof statements are slightly different from those required for user accounts. Specific details are explained in more depth below.

[0070] According to an embodiment, in order to use the system according to the invention, a user should ensure that the following conditions are met: · Own the VRF (Verifiable Random Function) key pair used to create the Random Payment ID (RPID). Owns the ElGamal key pair for the system user account that holds the primary funds for user payments. Owns the ElGamal key pair for the system collateral account used during settlement.

[0071] To register details in the system, it may be provided that a user triggers the registration process by initiating a blockchain transaction that includes the following details: -Register the corresponding VRF public key in the system. Register the collateral account address that will be linked to the public key in the VRF.

[0072] Finally, upon registration, the system's smart contract may create a new user entry C[c] in its state, which may include the following details (as in the table shown in FIG. 4): The address corresponding to the user's collateral account. A new dictionary D of finalized transactions. A new dictionary O of observed transaction hashes. A new dictionary T (trace) of past billings. Its first entry is C[c].T[0].idx ←⊥ and C[c].T[0].pool c ←c b where c b is the cryptogram corresponding to the initial balance of the user’s collateral account.

[0073] Regarding the registration of a service provider, before using the system, the service provider must ensure that the following conditions are met: · Own a valid key pair for one main user account through which payments will be transferred. Possess a valid key pair for one secondary user account to which the payments will be transferred. The service provider receives a value vi from each state keeper, which is part of each state keeper’s collateral that the state keeper assigned to the service provider.

[0074] As will be appreciated by those skilled in the art, if only confidential payments are required and used, the main user account and the secondary user account may be the same.

[0075] To register details in the system, a service provider may trigger the service provider registration process by initiating a blockchain transaction that includes the following details: Register the address of a secondary user account.

[0076] Finally, upon registration, the system's smart contract creates a new user entry M[m] in its state, which contains (as in the table shown in Figure 4): · Secondary user account addresses submitted by service providers.

[0077] Regarding Statekeeper registration, before using the system, Statekeepers must ensure that the following conditions are met: Possess a valid Boneh-Lynn-Shacham (BLS) key pair. Owns the ElGamal key pair for the collateral account used during settlement. · Allocate a portion of the total collateral to each service provider, i.e. create k values ​​for each service provider, all of which should sum to the total collateral. For each value v using the ElGamal public key of the collateral account i The ciphertext c i Encrypt it to. Each assigned value v i to the corresponding service provider. · Sum of all ciphertexts

[0078]

number

[0079] A zero-knowledge proof that π is equal to the total collateral reg Create a.

[0080] To register the details in the system, the Statekeeper may trigger the Statekeeper registration process by initiating a blockchain transaction that includes the following details: · BLS public key. (As described in T. Ristenpart and S. Yilek, "The power of proofs-of-possession: Securing multiparty signatures against rogue-key attacks", in Advances in Cryptology - EUROCRYPT 2007, M. Naor, Ed. Berlin, Heidelberg: Springer Berlin Heidelberg, 2007, pp. 228-245) Proofs of knowledge of the BLS private key to prevent rogue-key attacks. All ciphertexts c i , ..., c k ·Zero-knowledge proofπ reg

[0081] Finally, upon registration, the system's smart contract may perform the following actions (as in the table shown in Figure 4): · Verify proof of knowledge of the BLS private key. ·Zero-knowledge proofπ reg Verify. Create a new entry S[s] in that state that contains (according to the table shown in Figure 4): - BLS public key. - Statekeeper collateral account address - A list of k ciphertexts corresponding to the allocation portions for each service provider.

[0082] The most important function in the system is the payment process. This process, which can be triggered by a transaction signed by a user, transfers funds confidentially (or anonymously) to a specific service provider. This is the intended use case according to embodiments of the invention, and in general, this payment process should be successful unless either the user or the state keeper behaves maliciously.

[0083] The exact process and steps involved in creating and processing a high speed transaction according to an embodiment of the invention will now be described with reference to Figure 5, where method steps 1 to 8 are shown. The notation follows the tables shown in Figures 1 to 4, and in particular Figure 4, which provide a summary of transaction details.

[0084] 1. Initialize payment As shown in step 1 in FIG. 5, the user 110 payment index i, Random payment ID RPID=VRFhash(sk vrf ,i), · The address of the service provider's private collateral account m Contains the private payment intent pint c Create a.

[0085] The user 110 may then create confidential (or optionally anonymous) transaction details.

[0086] Confidential payments. In this case, the user 110 has the ElGamal public key y of the user 110, the ElGamal public key y of the service provider 120,

[0087]

number

[0088] , User 110’s ElGamal private key x, User 110’s user account balance bf , and the payment amount v, we can execute the Zether function, i.e., CreateTransferTx.

[0089]

number

[0090] And zero-knowledge proof π tans (User 110 has sufficient balance,

[0091]

number

[0092] ) and the signature σ trans and returns:

[0093] Anonymous payments. For anonymous payments, the user 110 creates a pseudonym set that includes both the user's 110 account and the service provider's 120 account.

[0094]

number

[0095] and the index i of the user account for user 110 f and the index of the service provider's user account i to , the ElGamal private key x of user 110, and the balance b of the user account of user 110. f , the payment amount v, and the current state of the smart contract 150 in the system.

[0096]

number

[0097] , nonce u, and zero-knowledge proof π trans and returns:

[0098] In addition, the user 110 derives a second zero-knowledge proof π col The proof must be for the user's private collateral balance. In particular, it must show that the sum of all pending payments, including the current payment, is less than the user's 110 current private collateral balance. The current collateral balance can be found in the trace C[c]. More formally,

[0099]

number

[0100] where n denotes the final index of the list C[c].T. Such proofs can be efficiently created or verified using Σ-Bullets, which we denote by way of example a hybrid system based on Σ-Protocols combined with Bulletproofs (see B. Bunz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, and G. Maxwell, "Bulletproofs: Short proofs for confidential transactions and more," Cryptology ePrint Archive, Report 2017 / 1066, 2017, https: / / eprint.iacr.org / 2017 / 1066, which is incorporated herein by reference).

[0101] According to an embodiment of the present invention, the user 110 may provide the following details: ·Payment Intention PINT c , ·VRF public key pk vrf , ·VRF Proofπ vrf =VRFprove(sk vrf ,i), -Crypto payment amount, ·Zero-knowledge proofπ col , List of pending transactions c may be sent to the service provider 120.

[0102] 2 User Rating As shown in FIG. 5, after payment initialization, in step 2, the service provider 120 performs the following checks: For each index j ∈ {1,...,PINTc[i]}, there exists a confirmed transaction τ' with index j such that either τ ∈ BC[c] or τ ∈ S[c]; Received pk vrf is registered on the system's smart contract 150, ·VRFverify (pk vrf ,i,π vrf )=T, · VRFproof2hash(π vrf )=RPID, Sensitive / anonymous payment details, especially zero-knowledge proofs π trans and signature σ trans Verify the correctness of An additional zero-knowledge proof π to ensure that the user 110's private collateral is sufficient to cover all pending transactions and the current transaction. col Verify can be executed.

[0103] 3. Obfuscating Service Provider Addresses According to an embodiment of the present invention, the service provider 120 may use the intent-to-pay PINT to hide its collateral address. c That is, the service provider 120 may change its collateral address to a commitment c m =C(m,r m ), where r m is a random blinding factor.

[0104] The service provider 120 then receives the modified payment intention PINT c to a majority of state keepers 130 (eg, via broadcasting).

[0105] Payment intention PINT executed by the service provider 120 and the user 110 c The modification is exemplarily shown in FIG.

[0106] 4 Payment Authorization According to an embodiment of the present invention, each state keeper 130 may evaluate the intent to pay received from a service provider 120 as follows.

[0107] State Keeper 130 checks that State Keeper 130 has not already approved a payment with the same RPID from its local list of State Keepers 130. If a matching RPID is found, State Keeper 130 aborts and notifies Service Provider 120 accordingly.

[0108] On the other hand, if State Keeper 130 has not seen the respective RPID value for the same index before, State Keeper 130 authorizes the payment and sends it back to Service Provider 120. According to an embodiment of the present invention, the authorization of the payment is performed by the BLS signature. σ i =Sign(PINT c ,sk sk ) The state keeper 130 may add the approved RPID values ​​to its local list.

[0109] 5 Statekeeper Rating If a majority of state keepers 130 deny the intent to pay, the service provider 120 notifies the user 110 and stops the payment process.

[0110] If successful, i.e., if at least half of the statekeepers 130 approve the intent to pay, the service provider 120 will Vf(PINT c ,σ i ,pk sk ) Check for the success of A = AggrSig({σ i ,...,σ n}) Consolidate into.

[0111] In addition to verifying signatures and aggregating them, service provider 120 may check that each state keeper 130 that approved the intent has assigned sufficient collateral to service provider 120. This may be easily done since service provider 120 knows the corresponding portion of each state keeper's 130 collateral in plaintext.

[0112] According to one embodiment of the present invention, the service provider 120 receives the intent to pay PINT c Let us use the blinding coefficient r m , VRF proof π vrf , and zero-knowledge proof π col , and in their long-term state in order to be able to claim payment at a later time.

[0113] Additionally, the service provider 120 receives the aggregated BLS signature A and the blinding factor r m and may be transmitted to the user 110.

[0114] 6. Check your commitments According to one embodiment of the present invention, user 110 verifies the aggregated BLS signature A, as shown in step 6 in FIG.

[0115] Furthermore, the user 110 determines whether the commitment of the service provider 120 contained in the intention to pay is C(m,r m )

[0116] 7 Transaction Finalization According to one embodiment of the present invention, as shown in step 7 in FIG. 5, the user 110 enters the following details: Destination: the system's smart contract address, · From: Any blockchain address, Payment index, RPID:RPID, · Committed address c m , · Confidential Payments: Payment Data

[0117]

number

[0118] , or Anonymous Payments: Payment Data

[0119]

number

[0120] ,

[0121]

number

[0122] , π trans , σ trans , · Aggregated BLS signature A, ·Approval quorum q, ·Operation, ·Zero-knowledge proofπ trans , ·User's system signature σ trans , Skipped indexes Create a final transaction that includes one or more of the following:

[0123] The user 110 can use (σtrans , to the service provider 120. According to one embodiment, the user 110 sends the created transaction (signed via claim may be transmitted in addition.

[0124] 8. Accepting Payments As shown in step 8b in Figure 5, upon receiving the final transaction from the user 110, the service provider 120 verifies that the user 110 has constructed the transaction correctly and signed all the details correctly, i.e., following the predefined payment protocol. They check that the user has not substituted, omitted, or modified any of the values.

[0125] Once the user's 110 transaction is verified, the service provider 120 can securely release the goods (for which the funds are intended) to the user 110.

[0126] Finally, the service provider 120 broadcasts the transaction to the blockchain 140.

[0127] 9. Logging payments According to one embodiment of the present invention, upon receiving the payment, the system's smart contract 150 finalizes a confidential (or anonymous) payment that transfers funds from the user 110 to the service provider 120.

[0128] Additionally, if successful, the smart contract 150 will include the following details: RPID, · Service provider's committed address c m , Collected authorization signatures A, · Quorum of approving state keepers, q may be stored in the user's 110 list of finalized transactions C[c].D[i], where i is the index of the current transaction.

[0129] As will be appreciated by those skilled in the art, the RPID may be a group

[0130]

number

[0131] Since all RPIDs in the set are members of i+1, there are a finite number of them. Thus, there is a non-zero, but very low, probability that user 110 generates an RPID value that already exists. If this occurs, state keeper 130 can reject the payment intention and service provider 120 can inform user 110 accordingly. User 110 can restart the payment procedure from the beginning, but this time with payment index i+1. According to one embodiment of the present invention, in the final transaction, an additional field is added to inform that one index was skipped due to a collision.

[0132] In a simple implementation of the payment process as described above, state keeper 130 would maintain an ever-growing list of already approved RPID values. According to an embodiment of the present invention, it may be provided that state keeper 130 can truncate its local list and periodically remove sufficiently old (e.g., older than 24 hours) RPID values ​​in order to reduce its storage requirements. Such truncation is safe to perform, since service provider 120 can detect reuse of sufficiently old payment index values ​​from blockchain 140.

[0133] An embodiment of the present invention addresses the case where a transaction does not appear on the blockchain 140 after a reasonable (e.g., predefined or configurable) time. In such a case, it may be provided that the service provider 120 can initiate the settlement process. A payment may fail due to a malicious user 110 double-spending his funds or due to an obscure state keeper signing a contradictory transaction. In both cases, it may be provided that the service provider 120 is eligible to be reimbursed by the system's smart contract 150, provided that the service provider 120 complies with the payment protocol.

[0134] According to an embodiment of the invention, it may be provided that the service provider 120 may claim settlement from either the state keeper 130's collateral or the user 110's collateral. Below, we discuss both cases, where τ denotes the transaction being claimed and τ′ denotes another approved transaction that conflicts with τ.

[0135] File a claim with the State Keeper If there are conflicting transactions signed by the same state keeper 130, the service provider 120 may initiate a claim from the collateral of the ambiguous state keeper 130. To initiate a settlement request, the service provider 120 may submit a transaction to the system, the request including the following details: · Payment intention PINT that the service provider 120 wants to settle c Details of Payment Intention PINT c Aggregated BLS signature A, which signs · a quorum q of signatories who have signed the intention to pay, · Blinding coefficient r m , ·VRF Proofπ vrf , Public keys corresponding to secondary accounts of service providers 120 registered in the system

[0136]

number

[0137] A signature σ m , Public key y sk and

[0138]

number

[0139] Two ciphertexts to encrypt the payment amount using

[0140]

number

[0141] (Here, the public key y sk corresponds to the collateral account of the ambiguous Statekeeper 130, and the public key

[0142]

number

[0143] corresponds to a secondary user account of the service provider 120), the address m of a secondary user account at the service provider 120; Ambiguous State Keeper 130 collateral account addresses, A list of conflicting transactions

[0144]

number

[0145] (For efficiency,

[0146]

number

[0147] may be assumed to contain the details of τ'), ·c* and

[0148]

number

[0149] encrypt the same value, and a zero-knowledge proof π that shows that the collateral of the fuzzy state keeper 130 is sufficient to cover the current transaction being claimed. claim (For efficiency, it is assumed that at most one state keeper 130 is claimed, and thus a service provider 120 is required to submit only one such zero-knowledge proof to a particular ambiguous state keeper 130.) may include one or more of:

[0150] According to one embodiment of the present invention, a settlement request may be processed as follows: Upon receiving the above details in a blockchain 140 transaction, the payment system smart contract 150 performs the following actions: Verify that the state does not already contain a transaction that has been settled, Verify that the collateral account of the service provider 120 is registered in the payment system smart contract 150; Verify that the collateral account of the opaque state keeper 130 is registered in the payment system smart contract 150; ·Signature of service provider 120 σ m Verify, · The claimed Statekeeper 130 has both quorums τ q and τ' q Verify that it is truly contained within ·Quorum τq and τ' q Given a,aggregated BLS signature,τ, A and τ' A Verify, ·τ cm =C(m,r m ), verifying the commitment by checking that VRFverify(C[c].pk vrf ,i,π vrf )=T VRFproof2hash(π vrf )=τ RPID By checking that vrf Verify the correctness of A zero-knowledge proof π based on the (encrypted) portion of the collateral balance that the State Keeper 130 has assigned to the Service Provider 120 claim Verify the correctness of If all checks are successful, the payment system smart contract 150 subtracts the encrypted amount c* from the collateral account of the state keeper 130;

[0151]

number

[0152] to the secondary user account at the service provider 120 (this may be done along with the normal transfer process); Once the corresponding amount has been transferred, the smart contract 150 of the payment system stores the details of the claimed transaction in a list C[c].D of finalized transactions of the user 110; Return to normal Execute.

[0153] Bill the user If there are no conflicting transactions, the service provider 120 can initiate a claim from the collateral of the user 110. To initiate a settlement request, the service provider 120 must provide the following details: · Payment intention PINT that the service provider 120 wants to settle c Details of Payment Intention PINT c Aggregated BLS signature A, which signs · a quorum q of signatories who have signed the intention to pay, · Blinding coefficient r m , ·VRF Proofπ vrf , Public key y corresponding to the collateral account of user 110 c A signature σ c , Public keys corresponding to secondary accounts of service providers 120 registered in the system

[0154]

number

[0155] A signature σ m , · Public key y c and

[0156]

number

[0157] Two ciphertexts to encrypt the payment amount using

[0158]

number

[0159] , the address of the collateral account of the service provider 120; A list of transactions that were pending approval

[0160]

number

[0161] ·c* and

[0162]

number

[0163] Both cryptographically encrypted values ​​are the same, and the collateral of user 110 is included along with the current transaction being claimed.

[0164]

number

[0165] A zero-knowledge proof that proves that π is sufficient to cover all transactions in col A transaction may be created using one or more of:

[0166] According to one embodiment of the present invention, a payment request may be processed as follows: Upon receiving the above details in the blockchain 140 transaction, the payment system smart contract 150 performs the following actions: Verify that the state does not already contain a transaction that has been settled, Verify that the collateral account of the service provider 120 is registered in the payment system smart contract 150; Verify that the collateral account of the opaque state keeper 130 is registered in the payment system smart contract 150; ·Signature of service provider 120 σ m Verify, Verify the signature of user 110 on transaction τ; Verify that there are no transactions in that state that conflict with either τ or any pending transactions. According to an embodiment, this is carried out by: - The payment system smart contract 150 searches the list of finalized transactions, i.e., τ and all

[0167]

number

[0168] For C[τ c ].D[τ i ] and

[0169]

number

[0170] Check out, The payment system smart contract 150 searches the list of observed transactions, i.e., τ and all

[0171]

number

[0172] About

[0173]

number

[0174] Check out, This can occur in two steps: ·

[0175]

number

[0176] Verify the signature of the user 110 for each of the transactions in ·Quorum τ q Given a,aggregated BLS signature,τ, A Verify the following: All

[0177]

number

[0178] For quorum τ' q Given a,aggregated BLS signature,τ', A Verify the following: ·τ cm =C(m,r m ), and verify the commitment by checking that VRFverify(C[c].pk vrf ,i,π vrf )=T VRFproof2hash(π vrf )=τ RPID By checking that vrf Verify the correctness of ·C[c].T[j].pcol c Find the past collateral balance stored in [c].T[j].idx<τ i VC[c].T[j].idx=⊥ and

[0179]

number

[0180] The condition of is satisfied, in other words, the entry is the index τ of the transaction whose corresponding system index is settled. jis the highest index such that no transaction with the same system index idx is included in the set of pending transactions offered by the service provider 120; ·Zero-knowledge proofπ col , i.e., the historical collateral balance found in the previous step is used to determine the number of settled transactions and

[0181]

number

[0182] be sufficient to cover all transactions in

[0183]

number

[0184] Verify that encrypts the same value, If all checks are successful, the payment system smart contract 150 subtracts the encrypted amount c* from the collateral account of the State Keeper 130;

[0185]

number

[0186] to the secondary user account at the service provider 120 (this may be done along with the normal transfer process); Once the corresponding amount has been transferred, the smart contract 150 of the payment system creates a new entry C[c].T[n+1].idx←τ i and

[0187]

number

[0188] where n is the length of list T,

[0189]

number

[0190] is the updated collateral balance of user 110, The payment system smart contract 150 stores details of the settled transaction in a list C[c].D of finalized transactions of the user 110; ·lastly,

[0191]

number

[0192] For each pending transaction in C[c].D that has not yet been finalized,

[0193]

number

[0194] Regarding the smart contract 150 of the payment system,

[0195]

number

[0196] where H is a collision-resistant hash function (in other words, the smart contract records the hash of the intent to pay if the intent to pay has not yet been finalized and is only currently being observed), Return to normal Execute.

[0197] The fast payment method / system according to the embodiments disclosed herein provides the advantage of censorship resistance. During approval, the only way for the statekeeper to know additional information about the transaction is by inspecting the intent to pay. In this case, the statekeeper cannot perform censorship on the payment amount, since it is completely removed from the intent. Furthermore, the statekeeper cannot know the identity of the service provider, since the Pedersen commitment is completely hidden and the blinding value is never disclosed to the statekeeper. It turns out that dictionary attacks on the RPID are not possible, since the statekeeper needs to know the VRF proof, which is not provided to the statekeeper at any point in time. It is recalled that the service provider has an economic incentive to protect privacy. Thus, the identity of the user also remains hidden.

[0198] The fast payment method / system according to the embodiments disclosed herein provides the further advantage of guaranteed funds. Once the service provider's intent to pay is approved and the service provider follows the protocol, the service provider must be guaranteed to receive funds even if the payment fails. If the payment is successful, this guarantee is naturally met. If the payment fails, the smart contract of the payment system must be shown to always accept the service provider's settlement request if the service provider follows the protocol.

[0199] The only difference in Statekeeper settlement from previous designs of fast payment systems such as Snappy is that the final transaction while billing the Statekeeper is performed in secret. Such a transaction is guaranteed to be successful, since benign service providers create correct zero-knowledge proofs for the collateral account balance.

[0200] If the user requests it, the provided zero-knowledge proof π colIt must be shown that always succeeds. The main idea here is that if the correct proof does not succeed, the payment system smart contract needs to find a different past collateral entry. By design, this entry will correspond to a transaction τ' that has a lower index and was settled later (after the creation of the zero-knowledge proof). If τ' was pending during the creation of the zero-knowledge proof, the service provider would not have considered this transaction in its proof, and therefore would be at fault. On the other hand, if τ' was not pending (i.e., it had been finalized), the service provider would have failed to follow the protocol, since it should have created a zero-knowledge proof for a more recent collateral balance. In either case, if the proof fails, the service provider knows that it did not follow the protocol.

[0201] The fast payment method / system according to the embodiments disclosed herein provides the further advantage of correct settlement: for statekeeper settlement, the payment system smart contract verifies a zero-knowledge proof that the private statekeeper collateral is sufficient to cover the current transaction and all pending transactions. Thus, given that an adversary cannot create a false proof, it is guaranteed that the statekeeper collateral will not be overspent.

[0202] The discussion on correct user settlement is a bit more complicated and we will only explain the rough intuition. The main idea is that the user creates a zero-knowledge proof of the current collateral during the settlement. During the settlement, the payment system smart contract backtraces its state to find the corresponding past collateral. If the state Sc (see the table in Figure 1) is compatible with the transaction (i.e. the service provider has done its due diligence) and there are no conflicting transactions in the system, the user's collateral is sufficient to cover the costs. Thus, the payment system smart contract checks that there are no conflicting transactions and finds past collateral that is compatible with the information provided by the service provider. The proof of compatibility provides the accompanying zero-knowledge proof.

[0203] The fast payment method / system according to the embodiments disclosed herein provides the additional benefit of payment privacy: during the payment, neither the benign service provider nor the user reveals their identity or the payment amount at any point during the payment. Thus, the same guarantees of confidentiality and anonymity as in Zether apply to the payment process according to the embodiments of the present invention.

[0204] The fast payment method / system according to the embodiments disclosed herein provides the further advantage of settlement privacy. Settlement does not support anonymity. However, it supports confidentiality of both user and statekeeper collateral. For a statekeeper, if all service providers do not disclose all their allocated portions of the total collateral, the total balance of the statekeeper's collateral remains private. If only one service provider keeps its allocation private, the exact total amount remains private. The only information that can be known from revealing the partial allocation is the lower bound of the statekeeper's collateral. This is due to the fact that the statekeeper does not share the disclosed total value with any other party, but only a portion to each service provider. Furthermore, all operations on the collateral can be performed either through zero-knowledge proofs or encrypted homomorphic operations.

[0205] Furthermore, the user's pledge remains completely private. Neither the user nor the service provider reveals their identity and payment amount at any time, and all operations on the user pledge are performed through zero-knowledge proofs. Therefore, it can be concluded that the same privacy guarantees as in Zether apply. As will be appreciated by those skilled in the art, this holds under the assumption that neither the user nor the service provider publicly discloses the payment amount in plaintext. This is a fair assumption, since both parties have an economic incentive to protect each other's privacy.

[0206] Many modifications and other embodiments of the inventions described herein will come to mind to one skilled in the art to which the inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. It is to be understood, therefore, that the invention is not limited to the specific embodiments disclosed, but that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation. [Explanation of symbols]

[0207] 110 users 120 Service Providers 130 State Keeper 140 Blockchain 150 Smart Contracts

Claims

1. 1. A computer-implemented method for high-speed blockchain payments, wherein the payment involves a transfer of funds from a user's (110) account to a service provider's (120) private collateral account, the method comprising: receiving, by the service provider (120), a private payment intention from the user (110), the private payment intention including a payment index, a random payment ID, and an address of a private collateral account of the service provider (120); modifying, by the service provider (120), the intent to pay by replacing the address of the collateral account of the service provider (120) with a commitment, and providing the modified intent to pay to a majority of state keepers (130) of a blockchain (140); receiving, by the service provider (120), payment authorizations from state keepers (130) of a blockchain (140), each payment authorization including the modified intent to pay signed with the private key of the respective state keeper (130); evaluating the received payment authorizations by the service provider (120), tallying the successfully evaluated payment authorizations, and sending the tallying result to the user (110); receiving, by the service provider (120), the final transaction created by the user (110) after verifying the aggregation result, verifying that the user (110) has correctly constructed the final transaction according to a given protocol, and accepting the payment if the verification of the final transaction is successful; 11. A computer-implemented method comprising:

2. 2. The method of claim 1, wherein the random payment ID of the user's (110) payment intention is generated by computing a verifiable random function VRF hash of the payment index.

3. The step of modifying the payment intention received from the user (110) by the service provider (120) includes modifying the address of the collateral account of the service provider (120) to a commitment c m =C(m,r m ), where m is the address of the collateral account of the service provider (120), and r m 2. The method of claim 1, wherein ∑ is a random blinding factor and C is a commitment function.

4. Evaluating, by the service provider (120), a private payment intention received from the user (110) by verifying the correctness of a zero-knowledge proof computed by the user (110) to indicate that the user's (110) balance is sufficient to make the payment.

4. The method of claim 1, further comprising:

5. Evaluating, by the service provider (120), the private intent to pay received from the user (110) by verifying the correctness of a zero-knowledge proof computed by the user (110) against the user's collateral balance to indicate that the sum of all pending payments, including the current payment, is less than the user's (110) current collateral balance.

4. The method of claim 1, further comprising:

6. 2. The method of claim 1, wherein the payment authorization from the statekeepers (130) of the blockchain (140) includes a BLS signature calculated by each of the statekeepers (130) on the modified intent to pay using the private key of each of the statekeepers (130).

7. 2. The method of claim 1, wherein, upon receiving payment authorizations from at least half of the state keepers, the service provider verifies the state keepers' signatures of the modified intent-to-pay using the public keys of each of the state keepers and aggregates the successfully verified signatures to obtain an aggregated authorization signature.

8. 2. The method of claim 1, wherein a smart contract (150) executing within the blockchain (140) is used to manage a collateral account for the user (110), a collateral account for the service provider (120), and a collateral account for each of the state keepers (130) of the blockchain (140), and wherein the smart contract stores a dictionary that maps account addresses to ElGamal homomorphic encrypted values.

9. When the smart contract (150) executing in the blockchain (140) receives the payment, it performs the following actions: an action of finalizing the payment to transfer funds from the user (110) to the service provider (120); If successful, storing the random payment ID, the committed address of the service provider (120), the aggregated approval signature, and a quorum of approving state keepers (130) in the user's (110) list of finalized transactions; The method of claim 7, wherein the

10. 10. The method of claim 9, wherein the user's (110) final transaction in the smart contract (150) is executed using an encrypted payment amount in a private account of the user (110) and the service provider (120).

11. 10. The method of claim 1, wherein a smart contract (150) running within the blockchain (140) is used to process a settlement request initiated by the service provider (120) if a transaction does not appear on the blockchain (140) after a predefined or configurable time.

12. directing, by the service provider (120), a settlement request to the user (110) or the statekeeper (130) to be reimbursed via confidential payment from either the private collateral account of the user (110) or the private collateral account of the respective statekeeper (130); 12. The method of claim 11, further comprising:

13. A system for high-speed blockchain payments, wherein payments involve the transfer of funds from a user's (110) account to a service provider's (120) private collateral account, the system comprising: receiving, from a user (110), a private payment intention from the user (110), the private payment intention including a payment index, a random payment ID, and an address of a private collateral account of the service provider (120); modifying the intention to pay by replacing the address of the collateral account of the service provider (120) with a commitment and providing the modified intention to pay to a majority of state keepers (130) of a blockchain (140); receiving payment authorizations from state keepers (130) of a blockchain (140), each payment authorization including the modified intent to pay signed with the private key of the respective state keeper (130); Evaluating the received payment authorizations, tallying the successfully evaluated payment authorizations, and sending the tallying results to the user (110); receiving a final transaction created by the user (110) after verifying the aggregation result, verifying that the user (110) has correctly constructed the final transaction according to a given protocol, and accepting the payment if the verification of the final transaction is successful; A system comprising a processor circuit configured to:

14. 1. A non-transitory processor-readable medium having stored thereon processor-executable instructions for performing a method for high-speed blockchain payments, wherein the payment involves a transfer of funds from a user's (110) account to a private collateral account of a service provider (120), the method comprising: receiving, by the service provider (120), a private payment intention from the user (110), the private payment intention including a payment index, a random payment ID, and an address of a private collateral account of the service provider (120); modifying, by the service provider (120), the intention to pay by replacing the address of the collateral account of the service provider (120) with a commitment, and providing the modified intention to pay to a majority of state keepers (130) of a blockchain (140); receiving, by the service provider (120), payment authorizations from state keepers (130) of a blockchain (140), each payment authorization including the modified intent to pay signed with the private key of the respective state keeper (130); evaluating the received payment authorizations by the service provider (120), tallying the successfully evaluated payment authorizations, and sending the tallying result to the user (110); receiving, by the service provider (120), the final transaction created by the user (110) after verifying the aggregation result, verifying that the user (110) has correctly constructed the final transaction according to a given protocol, and accepting the payment if the verification of the final transaction is successful; 1. A non-transitory processor-readable medium comprising:

Images