Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/401—Transaction verification
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/04—Payment circuits
  • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
  • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/22—Payment schemes or models
  • G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
  • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3825—Use of electronic signatures
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3827—Use of message hashing
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
  • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
  • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
  • H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
  • H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
  • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
  • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/351—Virtual cards
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q2220/00—Business processing using cryptography
  • G06Q2220/10—Usage protection of distributed data files
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
  • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

• One approach to improving the speed of blockchain transactions involves the creation of bilateral, off-chain channels, known as state channels.
• state channels are used by cryptocurrencies such as Ethereum. While such channels are useful, current off-chain channels cannot allow parties to perform different types of interactions that utilize arbitrary conditions without going on-chain.
• Such ability is important for scaling off-chain channels via a hub-and-spoke model, where each party establishes a channel with a highly available (but untrusted) hub without a priori knowledge about the type and conditions of its off-chain transactions.
• Embodiments of the disclosure address this problem and other problems individually and collectively.
• One embodiment is related to a method comprising: receiving, by a hub computer from a first computer, a sender message comprising a promise corresponding to a transaction comprising a promise type, an amount, a first verification key (e.g., a first public key) associated with the first computer, computer code, and a digital signature; verifying, by the hub computer, the promise by at least verifying the digital signature using the first verification key, verifying that the amount is less than a first computer amount, and verifying that the hub computer is able to process the promise type; and in response to verifying, executing the computer code to perform the transaction.
• a first verification key e.g., a first public key
• FIG. 1 Another embodiment is related to a hub computer comprising: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium comprising code executable by the processor for implementing a method comprising: receiving from a first computer, a sender message comprising a promise corresponding to a transaction comprising a promise type, an amount, a first verification key associated with the first computer, computer code, and a digital signature; verifying the promise by at least verifying the digital signature using the first verification key, verifying that the amount is less than a first computer amount, and verifying that the hub computer is able to process the promise type; and in response to verifying, executing the computer code to perform the transaction.
• a sender message comprising a promise corresponding to a transaction comprising a promise type, an amount, a first verification key associated with the first computer, computer code, and a digital signature
• verifying the promise by at least verifying the digital signature using the first verification key, verifying that the amount is less than a first computer amount, and verify
• Another embodiment is related to a method comprising: establishing, by a first computer, an interaction channel with a hub computer, wherein the interaction channel corresponds to a channel contract; generating, by the first computer, a sender message comprising a first promise corresponding to a transaction comprising a promise type, an amount, a first verification key associated with the first computer, computer code, and a digital signature; and providing, by the first computer, the sender message to the hub computer, wherein the hub computer verifies the promise, executes the computer code to perform the transaction.
• FIG. 1 shows a block diagram of an interaction channel system according to embodiments.
• FIG. 2 shows a block diagram of components of a hub computer according to embodiments.
• FIG. 3 shows a block diagram of components of a service provider computer according to embodiments.
• FIG. 4 shows a flow diagram illustrating a registration method according to embodiments.
• FIG. 5 shows a flow diagram illustrating a channel formation method according to embodiments.
• FIG. 6 shows a flow diagram illustrating a promise creation method according to embodiments.
• FIG. 7 shows a flow diagram illustrating an interaction completion method according to embodiments.
• FIG. 8 shows a block diagram of a universal payment channel system according to embodiments.
• a “user” may include an individual.
• a user may be associated with one or more personal accounts and/or mobile devices.
• the user may also be referred to as a client in some embodiments.
• a “user device” may be a device that is operated by a user.
• user devices may include a mobile phone, a smart phone, a card, a personal digital assistant (PDA), a laptop computer, a desktop computer, a server computer, a thin-client device, a tablet PC, etc.
• the user device may include one or more processors capable of processing user input.
• the user device may also include one or more input sensors for receiving user input. As is known in the art, there are a variety of input sensors capable of detecting user input, such as accelerometers, cameras, microphones, etc.
• the user input obtained by the input sensors may be from a variety of data input types, including, but not limited to, audio data, visual data, or biometric data.
• the user device may comprise any electronic device that may be operated by a user, which may also provide remote communication capabilities to a network.
• remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network.
• a “digital wallet” may include an electronic device or service that allows an individual to conduct electronic commerce transactions.
• a digital wallet may store user profile information, credentials, bank account information, one or more digital wallet identifiers and/or the like and can be used in a variety of transactions, such as, but not limited to, eCommerce transactions, social network transactions, money transfer/ personal payment transactions, mobile commerce transactions, proximity payment transactions, gaming transactions, etc.
• a digital wallet may be designed to streamline the purchase and payment process.
• a digital wallet may allow the user to load one or more payment cards onto the digital wallet so as to make a payment without having to enter an account number or present a physical card.
• Digital wallets may also be used manage cryptocurrencies and execute cryptocurrency transactions, including, for example, receiving cryptocurrencies at a cryptocurrency address associated with the digital wallet holder or transmitting cryptocurrencies to other cryptocurrency addresses.
• a "key pair" may include a pair of linked cryptographic keys.
• a key pair can include a public key and a corresponding private key.
• a first key e.g., a public key
• a second key e.g., a private key
• a public key may be able to verify a digital signature generated with the corresponding private key.
• the public key may be distributed throughout a network in order to allow for verification of messages signed using the corresponding private key.
• Public and private keys may be in any suitable format, including those based on RSA or elliptic curve cryptography (ECC).
• ECC elliptic curve cryptography
• a public key of a public/private key pair may be a used as a service provider identifier that identifies a service provider.
• a public key can be a verification key.
• a “digital signature” may include an electronic signature for a message.
• a digital signature may be a numeric data value, an alphanumeric data value, or any other type of data.
• a digital signature may be a unique data value generated from a message (or data packet) and a private key using a cryptographic algorithm.
• a validation algorithm using a public key may be used to verify the signature.
• a digital signature may be used to demonstrate the veracity of the sender.
• a “hash” or “hash value” may include any data element produced using a “hashing function.”
• a hashing function may be used to transform data of arbitrary size to data of fixed size (e.g., 1 KB, 10 alphanumeric characters, etc.).
• a hash function may be used to generate commitments to secret data, such as a secret token, without revealing the secret data itself.
• Some hash functions are “collision resistant,” meaning it is difficult to determine two inputs that produce the same hash output. Collision resistant hash functions can be used as a security feature in blockchains.
• An “interaction” may include a reciprocal action or influence.
• An interaction can include a communication, contact, or exchange between parties, devices, and/or entities.
• Example interactions include a transaction between two parties and a data exchange between two devices.
• an interaction can include a user requesting access to secure data, a secure webpage, a secure location, and the like.
• an interaction can include a payment transaction in which two devices can interact to facilitate a payment.
• a "blockchain” can be a distributed database that maintains a continuously-growing list of records secured from tampering and revision.
• a blockchain may include a number of blocks of interaction records. Each block in the blockchain can contain also include a timestamp and a link to a previous block.
• interaction records in a blockchain may be stored as a series of "blocks," or permanent files that include a record of a number of interactions occurring over a given period of time.
• Blocks may be appended to a blockchain by an appropriate node after it completes the block and the block is validated.
• Each block can be associated with a block header.
• a blockchain may be distributed, and a copy of the blockchain may be maintained at each full node in a verification network. Any node within the verification network may subsequently use the blockchain to verify interactions.
• a “node” may be a point at which lines or pathways intersect or branch or can be a central or connecting point.
• a node can also be a “computer node,” which can be any computer or device that connects to the verification network.
• a node that can fully verify each block and interaction in the blockchain can be a full node.
• a “full node” can store the full blockchain (i.e. , each block and each interaction).
• a “user device” may be a computer node in a verification network.
• a “block header” can be a header including information regarding a block.
• a block header can be used to identify a particular block of a blockchain.
• a block header can comprise any suitable information, such as a previous hash, a Merkle root, a timestamp, and a nonce.
• a block header can also include a difficulty value.
• a “nonce” can include an arbitrary number.
• a nonce can be a value that can be adjusted by a full node while performing a proof-of- work process.
• a nonce can be input into a hash function along with block data to determine the output hash value.
• a correct nonce also referred to as a golden nonce yields an output hash value that satisfies a predetermined criteria, such as being less than a difficulty value.
• a nonce can be of any suitable length (e.g., 32- bits).
• An “off-chain channel” or “interaction channel” may include a channel used to perform transactions or micro-transactions without broadcasting results to other devices.
• An example of an interaction channel can be a “state channel.”
• An off-chain channel can be performed without broadcasting results to a blockchain.
• An off-chain channel may be referred to as a “layer two channel.”
• Channels in the Lightning Network are examples of off-chain channels.
• an off-chain channel may be implemented utilizing a smart contract deployed on the blockchain. The participants on the off-chain channel can then perform transactions with one another without broadcasting to the blockchain.
• the off-chain channel can be closed by broadcasting “closing,” at which point the funds on the off-chain channel are distributed to the participants.
• a “promise” may include an assurance that a particular thing will occur.
• a promise may be used by a first user to interact with a second user, when the first user promises to provide an amount to the second user.
• a promise can also be used to initiate an interaction between two users via a hub computer.
• a promise can include data that indicates for a first user to transfer a first amount of a first digital currency to a second user.
• a promise can include data associated with the proposed interaction, a smart contract, and an interaction channel used to perform the interaction.
• a promise can be included in a list of promises of a smart contract.
• a promise can include data such as a channel identifier that identifies the interaction channel to be used for the interaction, a promise type, a first verification key associated with a first computer, a second verification key associated with a second computer, computer code (e.g., bytecode), a contract status of the interaction channel (e.g., “Active,” “Closed,” etc.), an index variable, a client credit variable that tracks the amount of digital currency held by a client, an amount (e.g., an amount of digital currency to be transferred from the first user to the second user), a hash value formed from an underlying secret, an expiry time after which the promise can no longer be claimed, a secret received indicator, and a digital signature formed using the previously mentioned variables.
• a “promise type” can include a category of promise.
• a promise type can indicate what category of promise is being made.
• a promise type can be included in a promise.
• a promise type can be a value, such as an integer, an enum, a string, etc. that can be read by a device to determine the type of the promise.
• Computer code can include a sequence or set of instructions in a programming language. Computer code can be executed by a computer to perform functionality. Computer code can include source code, bytecode, machine code, etc.
• “Bytecode” can include computer object code.
• bytecode can be converted into binary machine code, by an interpreter, so that the code can be read by a computer’s hardware processor.
• bytecode can include compact numeric codes, constants, and references (normally numeric addresses) that encode a result of a compiler parsing and performing semantic analysis of things like type, scope, and nesting depths of program objects of a program’s source code. Bytecode eliminates the need to recompile source code for each target platform. Even though interpreters differ between platforms, the application's bytecode does not.
• a developer can build an application in a high-level, human-readable programming language such as Java, C# or Python.
• a high-level language helps to simplify and optimize the application development process.
• the language statements e.g., source code
• a compiler converts the source code to bytecode.
• the bytecode can be an intermediary code that bridges the gap between the high-level source code and low-level machine code.
• the compiler is a special type of program that translates statements in the source code to bytecode, machine code, or another programming language.
• a “smart contract” can include a computer program or protocol that performs functionality.
• a smart contract can automatically execute, control, or document relevant events and actions according to the terms of a contract or an agreement.
• a smart contract can expose functions that are callable by other devices (e.g., using an API).
• a smart contract can be stored in memory and/or on a blockchain.
• a “hashed timelock contract” can include a type of smart contract.
• a hashed timelock contract can be a smart contract that utilizes a hashlock and a timelock.
• a hashed timelock contract can include conditional code that, when executed, allows two devices to establish an expiry time and a hashlock that can be unlocked using a secret. For example, a device receiving funds in a transaction can perform two actions to access the funds from the hashed timelock contract: 1 ) enter the correct secret and 2) claim payment within a specific timeframe.
• a “secret” can include data that is not meant to be widely known.
• a secret can be data or a value, and can be stored by a single computer until revealed to other computers.
• a secret can be used to resolve a hashed timelock contract or other hashing verification method.
• a second computer can generate a random value to be a secret.
• the second computer can hash the secret and provide the hash value to a first computer. Later, the second computer can provide the secret to the first computer to complete the interaction.
• the first computer can determine a derived hash value from the secret and compare the derived hash value to the hash value to determine if the interaction is to be finalized.
• a “receipt” may include an indication that something is being received.
• a receipt may be used to claim a promise.
• a receipt can include data associated with a smart contract and an interaction channel. For example, if a promise includes a proposed interaction amount, where a client credit is proposed to be increased by the interaction amount, then the receipt may include an updated client credit that includes the interaction amount.
• a receipt can indicate that an interaction has been finalized.
• a receipt can be included in a list of receipts of a smart contract.
• An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc.
• An “issuer” may typically refer to a business entity (e.g., a bank) that maintains an account for a user. An issuer may also issue credentials stored on a user device to the user.
• An “accumulator” can include a set of data.
• an accumulator can condense a set of values into a smaller data object, such that there is a witness value for each value included in the condensed set of values. It can be infeasible to find a witness for a value that has not been accumulated in the accumulator.
• a Merkle tree can be an example of an accumulator, which is a cryptographic primitive that lets one commit to a set of values, and later prove that a particular value is a member of the set of values.
• An accumulator can also be an RSA-based accumulator.
• Executing can include carrying out or putting into effect a program.
• a computer can execute computer code to carry out or put into effect the computer code.
• executing computer code can include starting to process computer code, where the computer code can be processed at once or over time. Execution can be a process by which a computer reads and acts on the instructions of a computer program.
• a “processor” may include a device that processes something.
• a processor can include any suitable data computation device or devices.
• a processor may comprise one or more microprocessors working together to accomplish a desired function.
• the processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and/or system -generated requests.
• the CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).
• a “memory” may be any suitable device or devices that can store electronic data.
• a suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method.
• Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.
• a “server computer” may include a powerful computer or cluster of computers.
• the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit.
• the server computer may be a database server coupled to a Web server.
• the server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers.
• Embodiments provide for interaction channels that allow two devices to agree on a smart contract off-chain (e.g., a promise contract) that specifies the conditions on which interactions can happen. If either party violates any of the terms, the other party can later deploy the promise contract on-chain as needed to receive a remedy as agreed upon in the smart contract.
• a smart contract off-chain e.g., a promise contract
• embodiments provide for interactions where only one device deposits an amount to the agreed off- chain interaction contract, enabling lightweight interactions.
• Any smart contact between two or more devices can be implemented according to embodiments, which allows the devices to use their pre-deposited on-chain collaterals for any off-chain interactions.
• the off-chain interactions can include those that are not anticipated at the time that the interaction channel is set up.
• protocols according to embodiments can be implemented on Ethereum using accumulators to achieve efficient concurrent programmable transactions, and the gas overhead of an HTLC smart contract can be measured to be ⁇ 100K, which can be amortized over many off-chain interactions.
• Such arbitrary conditions can include fractional payments (e.g., a user pays a second user a maximum of $10 if the interaction is claimed in 1 hour, but only $5 if the interaction is claimed thereafter), reservation cancellation (e.g., a user can be returned a promised amount if they attempt to cancel a hotel reservation prior to a time based deadline), an amount match between parties up to a predetermined total amount (e.g., a user promises to buy up to a total amount of gas ($100) from a gas station, but only ends up using a portion of the total amount of gas ($75).
• fractional payments e.g., a user pays a second user a maximum of $10 if the interaction is claimed in 1 hour, but only $5 if the interaction is claimed thereafter
• reservation cancellation e.g., a user can be returned a promised amount if they attempt to cancel a hotel reservation prior to a time based deadline
• an amount match between parties up to a predetermined total amount e.g., a user promises to buy
• State channels allow two devices to perform general purpose computation off-chain by mutually tracking the current state of the program.
• Existing state channel proposals have at least two technical problems.
• a second technical problem is that existing state channel proposals are overly complex and resource intensive, even for simple, programmable interactions.
• the authorization of an off-chain interaction via an interaction channel can be made less resource intensive since as the flow of the payments is usually unidirectional (e.g., from a sender to a receiver) while state channels need to track all state changes from both devices irrespective of the payment direction.
• Embodiments introduce a notion of programmable payment channels (PPC) that allow devices to agree, off-chain, on a set of conditions (e.g., in a smart contract) that the devices are attempting to impose for their off-chain interactions.
• PPC programmable payment channels
• An example of such a program is a hash-time-locked contract (HTLC).
• Interaction channel networks utilize HTLCs to provide trustless routing of interactions across a network.
• Embodiments utilize contracts on blockchains that are allowed and capable of deploying new contracts at deterministic addresses.
• Ethereum introduced the opcode CREATE2 in EIP-10142.
• Embodiments can utilize the above feature to achieve general programmability.
• contracts deploy contracts whose address is set by H(0xFF, sender, salt, bytecode) (where H is a hash function; which is replaced by a random oracle denoted by RO herein). This capability implies that an address of some yet- to-be-deployed contract can be foreseen. This property is dubbed as “prescience.”
• Embodiments provide for promises that represent a single instance of a programmable payment which is written as a contract that can be deployed on-chain by the PPC contract (e.g., interaction channel contract).
• Embodiments utilize the PPC contract to determine whether a promise should be deployed.
• the PPC contract can authenticate the payer and sender via digital signatures. After deploying the promise, to fast-forward to the last agreed off-chain execution state, embodiments require both parties’ signatures on the latest state. This mechanism is embedded into the promise contract.
• FIG. 1 shows a system 100 according to embodiments of the disclosure.
• the system 100 comprises a first user device 102, a first service provider computer 104 (an example of a first computer), a first blockchain network 106, a first certificate authority computer 108, a first authorizing entity computer 110, a hub computer 112, a second service provider computer 114 (an example of a second computer), a second blockchain network 116, a second certificate authority computer 118, a second authorizing entity computer 120, and a second user device [0058]
• the first user device 102 can be in operative communication with the first service provider computer 104.
• the first service provider computer 104 can be in operative communication with the first blockchain network 106, the first certificate authority computer 108, and the hub computer 112.
• the first blockchain network 106 can be in operative communication with the first authorizing entity computer 110 can the hub computer 112.
• the first certificate authority computer 108 can be in operative communication with the first authorizing entity computer 110.
• the hub computer 112 can be in operative communication with the second blockchain network 116 and the second service provider computer 114.
• the second service provider computer 114 can be in operative communication with the second user device 122, the second certificate authority computer 118, and the second blockchain network 116.
• the second blockchain network 116 can be in operative communication with the second authorizing entity computer 120.
• the second authorizing entity computer 120 can be in operative communication with the second certificate authority computer 118.
• FIG. 1 For simplicity of illustration, a certain number of components are shown in FIG. 1 . It is understood, however, that embodiments of the invention may include more than one of each component. In addition, some embodiments of the invention may include fewer than or greater than all of the components shown in FIG. 1 .
• Messages between at least the devices included in the system 100 in FIG. 1 can be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), SSL, ISO (e.g., ISO 8583) and/or the like.
• FTP File Transfer Protocol
• HTTP HyperText Transfer Protocol
• HTTPS Secure Hypertext Transfer Protocol
• SSL Secure Hypertext Transfer Protocol
• ISO e.g., ISO 8583
• the communications network may include any one and/or the combination of the following: a direct interconnection; the Internet; a Local Area Network (LAN); a Metropolitan Area Network (MAN); an Operating Missions as Nodes on the Internet (OMNI); a secured custom connection; a Wide Area Network (WAN); a wireless network (e.g., employing protocols such as, but not limited to a Wireless Application Protocol (WAP), l-mode, and/or the like); and/or the like.
• the communications network can use any suitable communications protocol to generate one or more secure communication channels.
• a communications channel may, in some instances, comprise a secure communication channel, which may be established in any known manner, such as through the use of mutual authentication and a session key, and establishment of a Secure Socket Layer (SSL) session.
• SSL Secure Socket Layer
• the first authorizing entity computer 110 and the second authorizing entity computer 120 can be operated by a first authorizing entity and a second authorizing entity respectively.
• the first authorizing entity and the second authorizing entity can be the same entity.
• the first and second authorizing entity computers can be issuing bank computers.
• the first certificate authority computer 108 and the second certificate authority computer 118 can be operated by the same or different certificate authorities.
• the first certificate authority computer 108 and the second certificate authority computer 118 can be computers that are operated by banks, payment processors, or other entities.
• the first blockchain network 106 may operate a first blockchain of a first digital currency.
• the second blockchain network 116 may operate a second blockchain of a second digital currency.
• the first and second digital currencies may be the same or different.
• the first blockchain network 106 may be operated or used by the first authority entity, and the second blockchain network 116 may be operated or used by the second authorizing entity.
• the first service provider computer 104 may be operated by a first service provider.
• the first service provider may provide access to a digital wallet to users.
• the first service provider computer 104 may be a digital wallet application server and may communicate with digital wallet applications installed on user devices.
• the second service provider computer 114 may be operated by a second service provider, and may be similar to the first service provider computer 104.
• the first user device 102 may be operated by a first user, and the second user device 122 may be operated by a second user.
• the hub computer 112 may be operated by a processing network, such as a payment processing network.
• the first authorizing entity computer 110 can manage accounts on behalf of users.
• the accounts can include a first digital currency, which can be a central bank digital currency (CBDC), a cryptocurrency, a fiat currency, etc.
• the first authorizing entity computer 110 may delegate key provisioning for using and/or accessing the account to the first certificate authority computer 108.
• the first certificate authority computer 108 may provide a key pair (e.g., through a digital certificate) that can be used to access the first blockchain network 106 to the first service provider computer 104.
• the first service provider computer 104 may then access or interact with the first blockchain network 106 using a received verification key (e.g., public key) of the key pair.
• a received verification key e.g., public key
• the first service provider computer 104 may then provide digital currency accounts to user devices.
• the first service provider computer 104 can provide a digital currency account to the first user device 102.
• the first user may install a digital wallet application on the first user device 102, which is used to obtain a digital currency account.
• the first user device 102 may communicate with the first blockchain network 106 via the first service provider computer 104.
• the first service provider computer 205 may open an interaction channel using a channel contract with the hub computer 112 on the first blockchain network 106 (e.g., as described in reference to FIG. 5).
• the interaction channel can facilitate the first service provider computer 104 in communicating and performing interactions (e.g., off-chain, on-chain, cross-chain transfers, etc.) on behalf of the first user device 102 directly with the hub computer 112, without accessing the first blockchain network 106.
• the interaction channel can allow the first service provider computer 104 to generate a promise to provide an amount to the second service provider computer 114 via the hub computer 112 (e.g., as described in reference to FIG. 6).
• the interaction channel can further allow the second service provider computer 114 to generate a secret to obtain the amount included in the promise (e.g., as described in reference to FIG. 7).
• a similar process can be performed between the second authorizing entity computer 120, the second certificate authority computer 118 (e.g., to provide a public key that acts as a second service provider identifier), the second blockchain network 116, the second service provider computer 114, the second user device 122, and the hub computer 112 to establish a second interaction channel between the second service provider computer 114 and the hub computer 112.
• the hub computer 112 may be separately in communication with the first blockchain network 106 and the second blockchain network 116, and the first service provider computer 104 via a first interaction channel and the second service provider computer 114 via the second interaction channel.
• the first service provider computer 104 and the hub computer 112 can establish an interaction channel, and the hub computer 112 does not have to operate as an intermediary between a first service provider computer 104 and a second service provider computer 114.
• the hub computer 112 and the first service provider computer 104 can form a state channel to conduct interactions between then without an additional party.
• FIG. 2 shows a block diagram of the hub computer 112 according to embodiments.
• the exemplary hub computer 112 may comprise a processor 204.
• the processor 204 may be coupled to a memory 202, a network interface 206, and a computer readable medium 208.
• the computer readable medium 208 can comprise a blockchain module 208A, a smart contract module 208B, and a communication module 208C.
• the memory 202 can be used to store data and code.
• the memory 202 can store a hub computer public key, a hub computer private key, smart contracts, etc.
• the memory 202 may be coupled to the processor 204 internally or externally (e.g., cloud based data storage), and may comprise any combination of volatile and/or non-volatile memory, such as RAM, DRAM, ROM, flash, or any other suitable memory device.
• the computer readable medium 208 may comprise code, executable by the processor 204, for performing a method comprising: receiving from a first computer, a sender message comprising a promise corresponding to a transaction comprising a promise type, an amount, a first verification key associated with the first computer, computer code, and a digital signature; verifying the promise by at least verifying the digital signature using the first verification key, verifying that the amount is less than a first computer amount, and verifying that the hub computer is able to process the promise type; and in response to verifying, executing the computer code to perform the transaction.
• the execution of the computer code can occur to implement a number of steps in the method, or can occur during the performances of the steps in the method.
• the blockchain module 208A may comprise code or software, executable by the processor 204, for processing blockchain related data and communicating with blockchain networks.
• the blockchain module 208A, in conjunction with the processor 204 can utilize public/private key pairs used to communicate with a blockchain network.
• the blockchain module 208A, in conjunction with the processor 204 may establish communication channels, such as interaction channels on blockchains. An interaction channel can be governed by a channel contract.
• the blockchain module 208A, in conjunction with the processor 204 may transfer digital currencies on-chain and off-chain.
• the blockchain module 208A, in conjunction with the processor 204 may allow the hub computer 112 to facilitate cross-chain interactions.
• the blockchain module 208A, in conjunction with the processor 204 can initiate the creation of a transaction entry in a block in a blockchain of a blockchain network.
• the smart contract module 208B may comprise code or software, executable by the processor 204, for deploying and maintaining smart contracts.
• the smart contract module 208B in conjunction with the processor 204, can deploy smart contracts to blockchains.
• the smart contract module 208B in conjunction with the processor 204, can access stored smart contracts and deploy the smart contracts to a blockchain using the blockchain module 208A.
• the smart contract module 208B in conjunction with the processor 204, can invoke functions and protocols of a smart contract that is deployed on a blockchain.
• the communication module 208C may comprise code or software, executable by the processor 204, for communicating with other devices.
• the communication module 208C in conjunction with the processor 204, can generate messages, forward messages, reformat messages, and/or otherwise communicate with other devices.
• the network interface 206 may include an interface that can allow the hub computer 112 to communicate with external computers.
• the network interface 206 may enable the hub computer 112 to communicate data to and from another device (e.g., service provider computers, blockchain networks, etc.).
• Some examples of the network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like.
• the wireless protocols enabled by the network interface 206 may include Wi-FiTM.
• Data transferred via the network interface 206 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the network interface 206 and other devices via a communications path or channel.
• any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.
• FIG. 3 shows a block diagram of a service provider computer 300 according to embodiments.
• the exemplary service provider computer 300 may comprise a processor 304.
• the processor 304 may be coupled to a memory 302, a network interface 306, and a computer readable medium 308.
• the computer readable medium 308 can comprise a blockchain module 308A, a digital wallet module 308B, and a communication module 308C.
• the memory 302 can be used to store data and code and may be similar to the memory 202 as described herein.
• the memory 302 can store verification keys, private keys, smart contracts, etc.
• the computer readable medium 308 may comprise code, executable by the processor 304, for performing a method comprising: establishing, by a first computer, an interaction channel with a hub computer, wherein the interaction channel corresponds to a channel contract; generating, by the first computer, a sender message comprising a first promise corresponding to a transaction comprising a promise type, an amount, a first verification key associated with the first computer, computer code, and a digital signature; and providing, by the first computer, the sender message to the hub computer, wherein the hub computer verifies the promise, executes the computer code to perform the transaction.
• the blockchain module 308A may comprise code or software, executable by the processor 304, for processing blockchain related data and communicating with blockchain networks.
• the blockchain module 308A, in conjunction with the processor 304 can utilize public/private key pairs used to communicate with a blockchain network.
• the blockchain module 308A, in conjunction with the processor 304 can allow the a user associated with a user account maintained by the service provider computer 300 to interact using amounts included in the user account.
• the blockchain module 308A, in conjunction with the processor 304 may transfer digital currencies on-chain and off-chain.
• the digital wallet module 308B may comprise code or software, executable by the processor 204, for maintaining a digital wallet application server.
• the digital wallet module 308B, in conjunction with the processor 304, can communicate with a plurality of user devices running a digital wallet application.
• the digital wallet module 308B, in conjunction with the processor 304, can maintain digital wallet applications that provide access between the service provider computer 300 and user devices and allows user devices to interact using amounts included in accounts in the digital wallet.
• the communication module 308C may comprise code or software, executable by the processor 304, for communicating with other devices.
• the communication module 308C in conjunction with the processor 304, can generate messages, forward messages, reformat messages, and/or otherwise communicate with other devices.
• the network interface 306 may be similar to the network interface 206 and will not be repeated here.
• FIG. 4 shows a flow diagram illustrating a registration method according to embodiments.
• the method illustrated in FIG. 4 will be described in the context of a client computer 400 registering with the hub computer 112.
• the client computer 400 can register to participate in the interaction methods provided by the hub computer 112.
• the client computer 400 can be a service provider computer (e.g., the first service provider computer 104, the second service provider computer 114, etc.).
• the client computer 400 can obtain cryptographic key pair including a verification key and a secret key (e.g., a public cryptographic key and a private cryptographic key).
• the client computer 400 can generate the cryptographic key pair in any suitable cryptographically secure method.
• the client computer 400 can obtain the cryptographic key pair from a certificate authority.
• the client computer 400 can generate and provide a registration request message including the verification key to the hub computer 112.
• the registration request message can also include additional data that identifies the client computer 400 (e.g., a client computer identifier, etc.).
• the hub computer 112 can determine whether or not the client computer 400 is already registered.
• the hub computer 112 can access a stored registry list that includes a plurality of verification keys corresponding to client computers that are registered with the hub computer 112.
• the hub computer 112 can evaluate the registry list to determine if the registry list already includes the verification key. If the registry list already includes the verification key, then the client computer 400 has already been registered and the hub computer 112 can notify the client computer 400 that the client computer 400 is already registered. If the registry list does not include the verification key, then the client computer 400 can proceed with step 408.
• the hub computer 112 can register the client computer 400.
• the hub computer 112 can register the client computer 400 by adding the verification key to the registry list.
• FIG. 5 shows a flow diagram illustrating a channel formation method according to embodiments. The method illustrated in FIG. 5 will be described in the context of the first service provider computer 104 communicating with the hub computer 112 to deploy a smart contract (e.g., a UPC smart contract) to establish an interaction channel.
• the smart contract can govern the usage of the interaction channel.
• the smart contract for the interaction channel can be a channel contract.
• Tables 1 and 2 are provided to illustrate details of the interaction channel and channel contract.
• the channel deploy protocol can be used to deploy an interaction channel.
• the first service provider computer 104 may receive instructions from the first user device 102 to begin the channel deploy protocol.
• the first service provider computer 104 and the hub computer 112 may agree on channel contract parameters prior to the channel deploy protocol, where the parameters include a channel identifier and a claim duration time.
• the channel identifier can be an alphanumeric value that uniquely identifies the interaction channel (e.g., 0001 ).
• the claim duration time can indicate how long the interaction channel will remain active (e.g., 4 hours).
• the first service provider computer 104 may transmit a request to open an interaction channel to the hub computer 112.
• the request to open an interaction channel can be a channel initiation request message.
• the channel initiation request message may include a channel identifier and a channel claim duration time used to deploy a channel contract.
• the channel initiation request message may further include identifying data of the first service provider computer 104 (e.g., a verification key of the first service provider computer 104).
• the channel initiation request message can indicate a particular blockchain for the interaction channel (e.g., with the user of a blockchain identifier).
• the channel initiation request message can indicate for the interaction channel to utilize the first blockchain network 106.
• the hub computer 112 may verify that the first blockchain network 106 is a supported blockchain network. For example, the hub computer 112 may verify that a communication channel has been established with the first blockchain network 106.
• the hub computer 112 can then generate a request identifier for the received request.
• the request identifier can be utilized to identify and track the request to deploy the channel contract to initialize the interaction channel.
• the request identifier may be used by the first service provider computer 104 to monitor the status of the interaction channel.
• the request identifier can be beneficial since the channel contract may not be immediately deployed on the first blockchain network 106. Therefore, the request identifier may be used by the first service provider computer 104 to query the hub computer 112 on the status of the first smart contract deployment.
• the hub computer 112 may transmit the request identifier and the channel identifier to the first service provider computer 104.
• the hub computer 112 can generate a channel contract deployment request message.
• the channel contract deployment request message can include the channel contract and a channel identifier.
• the channel contract deployment request message can also include the request identifier.
• the hub computer 112 can provide the channel contract deployment request message to the first blockchain network 106.
• the hub computer 112 may invoke a deploy contract function of the first blockchain network 106 to deploy the channel contract to the first blockchain network 106.
• the hub computer 112 may transmit instructions to the first blockchain network 106 to run the deploy contract function using the channel contract code.
• the first blockchain network 106 may run the deploy contract function(s).
• the channel contract can be in a block of a blockchain maintained by the first blockchain network 106.
• the first blockchain network 106 can obtain a contract identifier that identifies the location on the blockchain at which the channel contract is stored.
• the contract identifier may be an address of the channel contract on the first blockchain network 106.
• the first blockchain network 106 may generate a channel contract deployment response message comprising the contract identifier.
• the first blockchain network 106 can provide the channel contract deployment response message to the hub computer 112.
• the hub computer 112 can deposit funds to the channel contract after the deployment of the channel contract.
• the hub computer 112 can initialize the channel contract that is deployed to the blockchain of the first blockchain network 106.
• the hub computer 112 can execute an initialization function included in the channel contract.
• the hub computer 112 can initialize the channel contract using a hub computer verification key, the first service provider computer verification key, the channel identifier, and the claim duration time as input to the initialization function of the channel contract on the first blockchain network 106.
• the channel contract can process the received data to implement an interaction channel between the first service provider computer 104 and the hub computer 112, which can be identified by the channel identifier.
• the channel contract can include data relating to the devices involved in the to be established interaction channel.
• the channel contract can include data relating to the first service provider computer 104 and the hub computer 112.
• the channel contract can also include data related to interactions, promises, and receipts between the first service provider computer 104 and the hub computer 112.
• the channel contract can initialize the interaction channel by setting a channel status to “active,” in contrast to a channel status of “closed.”
• the channel contract can also set an indication of channel expiry to indicate that the channel is not expired.
• the channel contract can include the expiry date (e.g., March 15, 2023).
• the channel contract can also create an empty object (e.g., list, queue, etc.) that includes unresolved promises.
• the channel contract can store data relating to the hub computer 112, including the hub computer verification key, a hub deposit amount (e.g., currently at $0), an index of the latest receipt submitted by the hub computer 112 (e.g., currently null or 0), a hub computer credit value (e.g., currently at $0), and a Boolean that indicates that the hub computer 112 has not closed the channel.
• a hub deposit amount e.g., currently at $0
• an index of the latest receipt submitted by the hub computer 112 e.g., currently null or 0
• a hub computer credit value e.g., currently at $0
• Boolean that indicates that the hub computer 112 has not closed the channel.
• the channel contract can store data relating to the first service provider computer 104, including the first service provider computer verification key, a first service provider computer deposit amount (e.g., currently at $0), an index of the latest receipt submitted by the first service provider computer 104 (e.g., currently null or 0), a first service provider computer credit value (e.g., currently at $0), and a Boolean that indicates that the first service provider computer 104 has not closed the channel.
• a first service provider computer deposit amount e.g., currently at $0
• an index of the latest receipt submitted by the first service provider computer 104 e.g., currently null or 0
• a first service provider computer credit value e.g., currently at $0
• Boolean that indicates that the first service provider computer 104 has not closed the channel.
• the channel contract can also include the channel identifier that identifies the interaction channel (e.g., 0001), an indication of the ledger or blockchain that the channel contract resides on (e.g., an indication that the channel contract is on a blockchain maintained by the first blockchain networks 106), and the contract object itself that includes the code functionality (e.g., as depicted in Table 1 ).
• the channel identifier that identifies the interaction channel (e.g., 0001)
• an indication of the ledger or blockchain that the channel contract resides on e.g., an indication that the channel contract is on a blockchain maintained by the first blockchain networks 106
• the contract object itself that includes the code functionality (e.g., as depicted in Table 1 ).
• the channel contract can include a list of ingoing promises (e.g., promises made by the first service provider computer 104 to the hub computer 112) and a list of outgoing promises (e.g., promises made by the hub computer 112 to the first service provider computer 104).
• the list of ingoing promises and the list of outgoing promises can be initialized as empty lists.
• the promises can be added to the relevant ingoing or outgoing promise list.
• the promise lists can include all promises, both pending and completed.
• the channel contract can also include an ingoing accumulator and an outgoing accumulator.
• the ingoing accumulator and the outgoing accumulator can be data objects (e.g., cryptographic primitives) that store pending promises.
• the accumulators can be secure data objects that include pending promises and provide for efficient proofs of those pending promises being included in the accumulator.
• As promises are fulfilled (e.g., via receipts), the pending promises can be removed from the relevant accumulator.
• the channel contract can also include a net ingoing promise amount and a net outgoing promise amount.
• the net ingoing promise amount and the net outgoing promise amount can aggregate the amounts included in generated promises.
• the net ingoing promise amount can be a total amount promised by the first service provider computer 104 to the hub computer 112.
• the net outgoing promise amount can be a total amount promised by the hub computer 112 to the first service provider computer.
• the channel contract can also include a list of receipts that have been generated and registered with the interaction channel.
• a receipt can be an indication of completion of a promise.
• the channel contract can update the list of receipts as well as other data entries (e.g., accumulators, credits, etc.) that depend upon the completed promise that corresponds to the receipt.
• the amount of funds that a computer has in the interaction channel can be determined based on several of the aforementioned values included in the channel contract. For example, the total amount that the first service provider computer 104 has available for interactions can be determined based on of the first service provider computer deposit amount, the ingoing credit value (e.g., amount credited to the hub computer 112 by the first service provider computer 104), the outgoing credit value (e.g., amount credited to the first service provider computer 104 by the hub computer 112), the net ingoing promise value (e.g., amount promised to the hub computer 112 by the first service provider computer 104), and the net outgoing promise value (e.g., amount promised to the first service provider computer 104 by the hub computer 112).
• This total available amount for the first service provider computer 104 can be a first computer amount.
• the total available amount for the hub computer 112 can be a hub computer amount.
• the hub computer 112 can verify that an amount promised to the hub computer 112 by the first service provider computer 104 is less than the first computer amount. As such, the hub computer 112 can verify that the first service provider computer 104 has sufficient funds for the promise.
• Table 1 below, includes an example of a channel contract (e.g., a UPC contract) and various functions of the channel contract. Table 2, below, includes details of variables included herein.
• the hub computer 112 may transmit the request identifier and the contract identifier to the first service provider computer 104.
• the first service provider computer 104 may verify the deployment of the channel contract that implements the interaction channel. For example, the first service provider computer 104 may identify the channel contract on the blockchain using the contract identifier. The first service provider computer 104 can execute a get parameters function included in the channel contract to obtain parameters related to the interaction channel. For example, the first service provider computer 104 can execute an exposed function on the channel contract (e.g., a GetParams() function) and can receive output parameters. The parameters can include the channel identifier, the hub computer verification key, the first service provider computer verification key, and the claim duration time.
• a get parameters function included in the channel contract to obtain parameters related to the interaction channel.
• the first service provider computer 104 can execute an exposed function on the channel contract (e.g., a GetParams() function) and can receive output parameters.
• the parameters can include the channel identifier, the hub computer verification key, the first service provider computer verification key, and the claim duration time.
• the first service provider computer 104 can verify the obtained parameters. For example, the first service provider computer 104 can verify that the channel identifier, the first service provider computer verification key, the hub computer verification key, and the claim duration time are equal to the correct values as known by the first service provider computer 104.
• the first service provider computer 104 may access the first blockchain network 106 using the contract identifier to retrieve the smart contract and, after verifying the parameters of the smart contract, can store the smart contract locally.
• the first service provider computer 104 can communicate with the first blockchain network 106 using the channel identifier to verify that the channel contract is properly created and deployed to the first blockchain. For example, the first service provider computer 104 can verify that the channel contract is the correct contract. Furthermore, during step 520, the first service provider computer 104 can deposit and amount (e.g., funds) to the channel contract.
• amount e.g., funds
• a similar process can be performed between the second blockchain network 116, the second service provider computer 114, and the hub computer 112 to deploy a channel contract to the second blockchain network 116 that implements a second interaction channel between the hub computer 112 and the second service provider computer 114.
• the interaction channel between the first service provider computer 104 and the hub computer 112 can be a first interaction channel associated with a first channel contract.
• the interaction channel between the second service provider computer 114 and the hub computer 112 can be a second interaction channel associated with a second channel contract.
• Table 1 Example interaction channel contract i. Require SigVerify(R. a, [cid, R. idx, R. credit, R. acc], client, addr); ii. Set hub. rid ⁇ - R. idx, hub. credit ⁇ - R. credit, and hub. acc ⁇ - R. acc;
• Table 1 shows a channel contract (as exemplified by pseudocode) according to embodiments.
• the channel contract may comprise a number of functions including, but not limited to, an initialization function, a get parameters function, a deposit function, a register receipt function, a register promise function, a close function, and a withdraw function.
• the channel contract may be used to implement an interaction channel.
• the channel contract may be stored on a blockchain, a hub computer, and/or service provider computers.
• the initialize function may deploy and initiate the channel contract to a blockchain network.
• the initialization function lnit(cid’, vkH , vkc’, claimDuration’
• the initialization function defines and initializes the variables used throughout the channel contract.
• a first variable, cid may be a channel identifier that identifies the interaction channel.
• a second variable, claimDuration may identify the maximum duration that the devices have to submit any claims and is when the channel closes.
• the first and second variables may be passed to the UPC contract during the contract’s deployment phase.
• the verification keys of the two devices initializing the interaction channel are also provided to the channel contract for initialization.
• the get parameters function, GetParams() may be a function that is used to retrieve the channel parameters given at the initialization step of the contract.
• the get parameters function may be used by a device to verify that the channel contract was correctly deployed by the other device.
• the deposit function, Deposit(amount) may be a function that is used by a device to increase their on-chain deposit balance, and can be invoked any number of times as long as the contract’s status is “Active”.
• the register receipt function may be a function used by a device when they decide to close the channel.
• the register receipt function can be invoked by submitting the last receipt they received from the other device.
• the input to the register receipt function is a receipt object, R, detailed in Table 2.
• the register receipt function performs a series of verification checks before updating the on-chain credit values. The first check may ensure that the interaction channel is not in a “Closed” status. Next, the channel contract may ensure that the device invoking the function is a channel participant (e.g., the invoker has an address equal to either the hub.addr, or the client.addr).
• interaction channel if the interaction channel’s status is “Active” (e.g., this call is the initial call for closing of the channel contract), the status is changed to “Closing” and the channel expiry time is set by adding the claimDuration to the current timestamp.
• the signature of the promise, P is verified.
• another double spending check is performed by ensuring that the promise is inside the pending promise accumulators, by checking (e.g., membership proof) that the rid is smaller than the one recorded at the RegisterReceipt (e.g., the promise was created before the submitted receipt).
• the channel contract deploys the promise contract using the promise’s bytecode and salt. It further may keep a log of the promise by adding it to the unresolvedPromises list.
• the channel contract’s status and chanExpiry variables are set.
• the close function, Close() may be used in two distinct ways. In a first case, the device calling the close function does not have a receipt or promise and wants to close the channel without claiming any off-chain credits. The second case is for situations that the devices would like to close the channel cooperatively without waiting for the chanExpiry time to arrive. In this scenario, the devices first claim their receipt and promises, then invoke the close function.
• the close function may first ensure that the invoking device is a channel participant. Next, depending on which device is calling the function, the closed variable of that device will be set to “True”. If both devices (e.g., both the hub and the client) have their closed variables set to “True”, then the status of the channel is changed to “Closed”. Finally, similarly to the previous two functions, the contract’s status and chanExpiry variables are set accordingly.
• the withdraw function may be a function used by the devices to withdraw their funds once the interaction channel has been successfully closed.
• the function ensures that the interaction channel has been closed by checking the status. If the status is “Closing” then an extra validation of the timestamp against the channel’s expiry time (chanExpiry) is performed.
• the channel contract iterates through the list of unresolvedPromises and invokes the resolve function for each of the promise contracts. The return amount of the call of the withdraw function will be added to the credit of the receiver of that promise.
• the function transfers funds according to the deposit and credit amounts for each channel participant.
• FIG. 6 shows a flow diagram illustrating a promise creation method according to embodiments. The method illustrated in FIG. 6 will be described in the context of the first service provider computer 104 initiating a promise method that results in the first service provider computer 104 creating a first promise to the hub computer 112 and the hub computer 112 creating a second promise to the second service provider computer 114.
• the method illustrated in FIG. 6 may occur when the first service provider computer 104 attempts to perform a transaction with the second service provider computer 114 (e.g., provide a payment amount to the second service provider computer 114) using the already established channels with the hub computer 112 (e.g., previously established as described in reference to FIG. 5).
• the hub computer 112 e.g., previously established as described in reference to FIG. 5.
• the first service provider computer 104 and the second service provider computer 114 can agree on the values for an amount, a hash value, and an expiry time with which the second service provider computer 114 is to later reveal a secret where the hash of the secret (e.g., Hash(secret)) is equal to the hash value.
• the amount can be a value that is to be provided from one party to the other party.
• the expiry time can indicate when the interaction is set to expire (e.g., become void).
• the hash value can be obtained by hashing a secret known by the second service provider computer 114.
• the second service provider computer 114 can generate the hash value by inputting the secret into a hash function.
• the secret can be a value known by the second service provider computer 114 but not the hub computer 112 or the first service provider computer 104.
• the secret can act as a key that opens the hash time-lock contract.
• the secret can be a random value generated and stored by the second service provider computer 114 that is difficult for the first service provider computer 104 or the hub computer 112 to guess.
• the second service provider computer 114 can generate the secret to be a value, such as 1234567890000.
• a first interaction channel between the first service provider computer 104 and the hub computer 112 can be identified with a first channel identifier (e.g., cidA).
• a second interaction channel between the second service provider computer 114 and the hub computer 112 can be identified with a second channel identifier (e.g., cidB).
• the hub computer 112 can store both the first channel identifier and the second channel identifier.
• a promise contract can be known and accessible by the first service provider computer 104, the hub computer 112, and the second service provider computer 114.
• the promise contract can include functionality for revealing a secret and resolving the interaction.
• the promise contract can include additional data and functionality to perform different types of interactions.
• the promise contract can include computer code (e.g., bytecode) that, when executed by the hub computer 112, performs methods relating to the type of interaction being performed.
• the promise contract can be identified by a promise type created in a promise by the first service provider computer 104 along with the promise contract.
• the promise contract can be an HTLC smart contract, a smart contract that allows fractional payments, a smart contract that allows for cancelation, a smart contract that allows for matching payments with resource usage, a smart contract that allows for quality checks prior to finalization, a smart contract that allows for call/put options, a smart contract that allows for auctions, and any other type of smart contract that includes executable computer code.
• Table 3 includes an example of a promise contract that is a HTLC smart contract.
• the HTLC smart contract can be a smart contract that can be utilized to reveal and resolve the secret for the interaction.
• the HTLC smart contract can be initialized with the amount, the hash value, and the expiry time.
• the HTLC contract can be invoked to reveal the secret and to resolve the interaction.
• the second service provider computer 114 can call the HTLC contract’s reveal secret method by providing the secret to the HTLC contract.
• the HTLC contract can determine if the HTLC contract is expired using the expiry time.
• the HTLC contract can verify the hash the received secret to obtain a derived hash value, which can be compared to the hash value. If the derived hash value matches the hash value, then the HTLC contract can determine that the secret has been successfully revealed.
• the HTLC contract can also allow the second service provider computer 114 to resolve the interaction via a resolve function.
• the HTLC contract can verify that the secret has been successfully revealed and then return the amount to the second service provider computer 114.
• the HTLC contract may supplement the channel contract for HTLC type promises.
• the HTLC contract code (e.g., bytecode included in the promise) may be used by all parties to create and verify HTLC promises.
• the channel contract will deploy the HTLC contract for each of the HTLC promises (e.g., execute the promise contract’s bytecode).
• the HTLC contract can include an initialization function, a reveal secret function, and a resolve function.
• the initialization function may be a function which acts a constructor of the contract and initializes the contract variables.
• the values amount, hash, and expiry are given as input to the UPC contract.
• the reveal secret function RevealSecret(secret) may be a function which takes a secret value as input and checks two conditions. First, the reveal secret function checks that the current time is not beyond the expiry time of the contract. Second, the reveal secret function ensures that the cryptographic hash of the secret matches the hash value of the contract (e.g., the secret is the pre-image of the hash). If both of the verifications pass, then the contract’s secretRevealed variable will be set to True.
• the resolve function, ResolveQ may be a function that is called by the channel contract at the time of withdrawal to determine the amount of the promise that needs to be credited to the receiver.
• the secret was revealed successfully (e.g., secretRevealed is “True”)
• the full amount of the promise is returned to the channel contract. Otherwise, if the current time is less than the expiry value, an exception will be provided, indicating that there is still time for revealing the secret. If no secret is revealed and the expiry time has passed, a zero amount will be sent to the channel contract.
• Example HTLC contract as a promise contract [0139]
• the promise creation method can also be performed between the first service provider computer 104 that is operating on behalf of a user and the second service provider computer 114 that is operating on behalf of a hotel booking system.
• the user can attempt to book a particular room in a hotel offered by the hotel booking system.
• the first service provider computer 104 and the second service provider computer 114 can determine an amount for the hotel room (e.g., based on an amount charged by the hotel booking system) that is $500, a hash value that is 123456789, and an expiry time that is February 1 , 2023 (e.g., which may be a reservation date).
• the first service provider computer 104 and the second service provider computer 114 can decide to use a promise contract that includes computer code that, when executed, provides functionality for cancelling the hotel room booking under certain conditions (e.g., a cancellation smart contract).
• the cancellation smart contract can include computer code that includes conditions where the first service provider computer 104 can cancel the reservation prior to January 15, 2023 and receive a full refund (e.g., cancel the promise).
• the cancellation smart contract can further include computer code that includes conditions where the first service provider computer 104 can cancel the reservation between January 15, 2023 and February 1 , 2023, but may only receive a partial refund (e.g., the user provides $250 to the hotel booking system).
• the first service provider computer 104 and the hub computer 112 can verify that the first interaction channel is active as indicated in the first channel contract (e.g., a UPC contract as described in reference to FIG. 5) corresponding to the first interaction channel.
• the second service provider computer 114 and the hub computer 112 can verify that the second interaction channel is active as indicated in the second channel contract corresponding to the second interaction channel. If any computer determines that an interaction channel is not active, then that computer can terminate the interaction process.
• the first service provider computer 104 can create a first promise.
• the first promise can be a promise to provide an amount to the second service provider computer 114 via the hub computer 112 upon completion of the interaction according to rules indicated by executable computer code in the selected promise contract.
• the first service provider computer 104 can create the first promise based on the first channel contract as identified by the first contract identifier, a promise type, the promise contract, a plurality of parameters, a first service provider verification key, a first service provider secret key, and a hub computer verification key (e.g., P A ⁇ -
• the first service provider computer 104 can set the plurality of parameters to include the amount, the hash value, and the expiry time added with an elapsed time from the first interaction channel’s contract.
• the first service provider computer 104 can generate the first promise including a first channel identifier, a first latest receipt index (e.g., which may be null if no previous promises and receipts have taken place), a first salt, first computer code, a first promise address, a first digital signature, the first service provider verification key, and the hub computer verification key.
• the first service provider computer 104 can perform the following steps.
• the first service provider computer 104 can set the first channel identifier of the promise to be equal to the first channel identifier that identifies the first interaction channel.
• the first service provider computer 104 can set the first latest receipt index equal to the latest outgoing receipt index of the first channel contract.
• the first service provider computer 104 can set the first salt to a random value or predetermined pseudorandom value.
• the first service provider computer 104 can set the first computer code of the first promise equal to a concatenation of the promise contract’s computer code and the plurality of parameters.
• the service provider computer 104 can generate the first digital signature on the first contract identifier, first the latest receipt index, the first service provider computer verification key, the hub computer verification key, and the first promise address using a first service provider computer private key that corresponds to the first service provider computer verification key.
• the first service provider computer 104 can include the first digital signature into the first promise along with the aforementioned data.
• the first service provider computer 104 can add the first promise to a list of outgoing promises included in the first channel contract.
• the first service provider computer 104 can also add the first promise to the outgoing accumulator included in the first channel contract.
• the outgoing accumulator can accumulate promises that are to be processed and completed.
• the accumulator can provide proofs that a particular promise is included in the accumulator.
• the first service provider computer 104 can generate the promise to provide the $500 to the second service provider computer 114 for booking the agreed upon hotel room conditionally upon execution of the computer code in the promise contract with cancellation conditions.
• the first service provider computer 104 can generate the promise comprising the first channel identifier (e.g., 0001 ), the first latest receipt index (e.g., null), a first salt (e.g., 54321 ), the first computer code (e.g., the promise contract’s computer code concatenated with the plurality of parameters), the first promise address (e.g., an address created from the computer code and the salt), the first digital signature (e.g., created using the first service provider private key), the first service provider verification key, and the hub computer verification key.
• the first channel identifier e.g., 0001
• the first latest receipt index e.g., null
• a first salt e.g., 54321
• the first computer code e.g., the promise contract’s computer code con
• the first service provider computer 104 can generate a sender message comprising the first promise.
• the first service provider computer 104 provide the sender message to the hub computer 112.
• the sender message can also include an indication of the recipient of the amount.
• the sender message can include data that identifies the second service provider computer 114 (e.g., a second service provider computer verification key, a second service provider computer identifier, etc.).
• the hub computer 112 can evaluate the first promise. Evaluating the first promise can include verifying an expiry time of the first promise, verifying a promise type of the first promise, and/or verifying additional data included in the first promise.
• the hub computer 112 can verify that the claim expiry time indicated in the plurality of parameters included in the first promise is not greater than (e.g., after) the expiry of the first interaction channel between the first service provider computer 104 and the hub computer 112. If the claim expiry time is greater than the expiry of the first interaction channel, the hub computer 112 can abort the interaction process and can notify the first service provider computer 104 of the abortion reason. [0148] Prior to, or after, verifying the claim expiry time, the hub computer 112 can verify that the first promise type is a promise type that the hub computer 112 is capable of performing. For example, the hub computer 112 can process promise types that indicate particular promise contracts (e.g., HTLC, cancellation, etc.).
• promise types that indicate particular promise contracts (e.g., HTLC, cancellation, etc.).
• the hub computer 112 can verify that the promise type corresponds to a valid promise contract that the hub computer 112 can process.
• the hub computer 112 can store a lookup table of promise types that the hub computer 112 can process.
• the hub computer 112 can search the lookup table for the promise type. If the promise type is not in the lookup table, then the hub computer 112 can deny the promise and end the process. If the promise type is included in the lookup table, then the hub computer 112 can continue with the process.
• the hub computer 112 can verify the first promise.
• the hub computer 112 can verify the first promise using data included in the first promise.
• the hub computer 112 can verify the first promise using the first channel identifier, the promise contract, the plurality of parameters, the first service provider computer verification key, and the hub computer verification key (e.g., VerifyPromise C H [cid A ], P A , htlcContract, P A . params, vk A , vk H , vk A y).
• the hub computer 112 can verify that the first service provider computer 104 has sufficient funds to perform the first promise.
• the hub computer 112 can evaluate the first channel contract to determine if the first service provider computer 104 has sufficient funds.
• the hub computer 112 can determine if a total fund value equal to a sum of a deposit value and a credit out value is greater than a total owed value equal to a sum of a credit in value, a net promise in value, and the amount in the first promise (e.g., C. credit in + C. netProm in + P. amount ⁇ deposit + C. credit out ).
• the deposit value can be an amount of funds deposited by the first service provider computer 104 with the hub computer 112.
• the credit out value can be an amount of funds owed by the hub computer 112 to the first service provider computer 104.
• the credit in value can be an amount of funds owed by the first service provider computer 104 to the hub computer 112.
• the net promise in value can be an amount of funds promised by the first service provider computer 104 to the hub computer 112.
• the credit out value, the credit in value, and the net promise in value can be included in the first channel contract.
• the hub computer 112 can verify the digital signature.
• the hub computer 112 can verify the digital signature using the first service provider computer verification key that corresponds to the first service provider computer private key (an example of a first computer private key) used to form the digital signature.
• the hub computer 112 can add the first promise to a list of ingoing promises in the first channel contract.
• the hub computer 112 can update the net promise in value in the first channel contract to be equal to the net promise in value added with the amount included in the first promise.
• the hub computer 112 can add the first promise to the ingoing accumulator included in the second channel contract.
• the ingoing accumulator can accumulate promises that are to be processed and completed.
• the accumulator can provide proofs that a particular promise is included in the accumulator.
• the hub computer 112 can execute the computer code (e.g., bytecode) included in the first promise.
• the hub computer 112 can execute the computer code to initiate the performance of the transaction.
• the computer code can be code included in the promise contract.
• the hub computer 112 can deploy the computer code in the promise contract to the blockchain.
• the computer code can perform functionality that effects the outcome of the interaction.
• the computer code can include conditional rules that influence the interaction by altering how funds are provided, when funds are provided, if funding can be reversed, and/or any other type of change to the interaction flow.
• the computer code, once deployed, can automatically perform functionalities and/or perform functionalities upon request.
• the computer code of the promise contract can include public function calls that allow devices to call the functions to perform functionality.
• promise contract can be a reservation cancellation contract that allows a user to create a reservation and to conditionally cancel the reservation.
• the promise contract allows the user to cancel the reservation prior to January 15, 2023 and receive a full refund (e.g., cancel the promise).
• the cancellation smart contract can further include computer code that includes conditions where the first service provider computer 104 can cancel the reservation between January 15, 2023 and February 1 , 2023, but may only receive a partial refund (e.g., the user provides $250 to the hotel booking system). These conditions in the computer code can be validated/performed when the interaction channel between the first service provider computer 104 and the hub computer 112 closes.
• the channel contract when the interaction channel closes (e.g., as initiated by the user between January 15, 2023 and February 1 , 2023), the channel contract iterates through the list of unresolved promises and invokes a resolve function for each of the promise contracts.
• the promise contract can determine that the current date is between January 15, 2023 and February 1 , 2023.
• the promise contract can return a fulfilled amount to the channel contract of $250 due to the cancellation occurring during the partial refund period.
• the hub computer 112 can generate a second promise. Note that the execution of the computer code can be ongoing, even during the generation of the second promise.
• the hub computer 112 can generate the second promise in a similar manner to how the first service provider computer 104 generates the first promise.
• the hub computer 112 can generate the second promise using the second channel contract as identified by the second channel identifier, a second promise type, the promise contract, the plurality of parameters included in the first promise, the hub computer verification key, the hub computer private key, and the second service provider computer verification key (e.g., P H ⁇ -
• the hub computer 112 can generate the second promise including a second channel identifier, a second latest receipt index, a second salt, second computer code (e.g., second bytecode), a second promise address, a second digital signature, the second service provider verification key, and the hub computer verification key.
• the hub computer 112 can perform the following steps.
• the hub computer 112 can set the second channel identifier of the second promise to be equal to the second contract identifier that identifies the second interaction channel.
• the hub computer 112 can set the second latest receipt index equal to a latest outgoing receipt index of the second channel contract.
• the hub computer 112 can set the second salt to a random value or predetermined pseudorandom value.
• the hub computer 112 can set the second computer code of the second promise equal to a concatenation of the promise contract’s computer code and the plurality of parameters.
• the hub computer 112 can generate a second digital signature on the second contract identifier, the second latest receipt index, the second service provider computer verification key, the hub computer verification key, and the second promise address using a hub computer private key that corresponds to the hub computer verification key.
• the hub computer 112 can include the second digital signature into the second promise along with the aforementioned data.
• the hub computer 112 can add the second promise to a list of outgoing promises included in the second channel contract.
• the hub computer 112 can also add the second promise to an outgoing accumulator included in the second interaction channel.
• the hub computer 112 can create a promise mapping between the first promise and the second promise.
• the promise mapping can associate the two promises with one another to indicate that they are related.
• the hub computer 112 can use the promise mapping as a lookup table to switch between the first interaction channel and the second interaction channel.
• the hub computer 112 can generate the second promise to provide the $500 to the second service provider computer 114 for booking the agreed upon hotel room conditionally upon execution of the computer code in the promise contract with cancellation conditions.
• the hub computer 112 can generate the second promise comprising the second channel identifier (e.g., 0002), the second latest receipt index (e.g., null), a second salt (e.g., 41253), the second computer code (e.g., the promise contract’s computer code concatenated with the plurality of parameters), the second promise address (e.g., an address created from the computer code and the salt), the second digital signature (e.g., created using the hub computer private key), the second service provider verification key, and the hub computer verification key.
• the second channel identifier e.g., 0002
• the second latest receipt index e.g., null
• a second salt e.g., 41253
• the second computer code e.g., the promise contract’s computer code concatenated with the
• the hub computer 112 can provide the second promise to the second service provider computer 114.
• the second service provider computer 114 can verify that the claim expiry time indicated in the plurality of parameters included in the second promise is not greater than (e.g., after) the expiry of the second interaction channel between the second service provider computer 114 and the hub computer 112. If the claim expiry time is greater than the expiry of the second interaction channel, the second service provider computer 114 can abort the interaction process and can notify the hub computer 112 of the abortion reason.
• the second service provider computer 114 can verify that the second promise type is a promise type that the second service provider computer 114 is capable of performing.
• the second service provider computer 114 can verify the second promise.
• the second service provider computer 114 can verify the second promise using data included in the second promise.
• the second service provider computer 114 can verify the second promise using the second channel identifier, the promise contract, the plurality of parameters, the second service provider computer verification key, and the hub computer verification key (e.g. , VerifyPromise(C B [cid H ], P A , promiseContract, P H . params, vk H , vk B , vk H ⁇ )).
• the second service provider computer 114 can verify that the hub computer 112 has sufficient funds to perform the second promise.
• the second service provider computer 114 can evaluate the second channel contract to determine if the hub computer 112 has sufficient funds.
• the second service provider computer 114 can determine a total expenses value for the hub computer 112 that includes an ingoing credit value (e.g., funds owed by the hub computer 112 to the second service provider computer 114), a net promise value (e.g., funds promised by the hub computer 112 to the second service provider computer 114), and the amount of the second promise.
• the second service provider computer 114 can also determine a total funds value for the hub computer 112 that includes a hub computer deposit value and an outgoing credit value (e.g., funds owed by the second service provider computer 114 to the hub computer 112).
• the second service provider computer 114 can determine whether or not the total expenses value is less than the total funds value. For example, the second service provider computer 114 can determine C. credit in + C. netProm in + P. amount ⁇ deposit + C. credit out ).
• the second service provider computer 114 can verify the second digital signature.
• the second service provider computer 114 can verify the second digital signature using the hub computer verification key that corresponds to the hub computer private key used to form the second digital signature.
• the second service provider computer 114 can add the second promise to a list of promises in the second channel contract.
• the second service provider computer 114 can update net promise value (e.g., value promised by the hub computer 112 to the second service provider computer 114) with the amount of the second promise.
• the second service provider computer 114 can add the second promise to the ingoing accumulator.
• the second service provider computer 114 can execute the computer code included in the second promise.
• the second service provider computer 114 can execute the computer code to initiate the performance of the transaction.
• the computer code can be code included in the promise contract.
• the second service provider computer 114 can deploy the computer code in the promise contract to the blockchain.
• the computer code can perform functionality that effects the outcome of the interaction.
• the computer code can include conditional rules that influence the interaction by altering how funds are provided, when funds are provided, if funding can be reversed, and/or any other type of change to the interaction flow.
• the computer code once deployed, can automatically perform functionalities and/or perform functionalities upon request.
• the computer code of the promise contract can include public function calls that allow devices to call the functions to perform functionality.
• the creation of the promises can result in the first service provider computer 104 promising to provide the amount to the hub computer 112, which in turn has promised to provide the amount to the second service provider computer 114.
• FIG. 7 shows a flow diagram illustrating an interaction completion method according to embodiments.
• the method illustrated in FIG. 7 will be described in the context of the second service provider computer 114 generating a secret to claim the second promise’s amount (e.g., obtain a receipt).
• the method illustrated in FIG. 7 can illustrate completing the interaction initiated if FIG. 6.
• the method illustrated in FIG. 7 can be an example of a receipt generation process during interaction completion, where the promise type is a HTLC promise.
• the HTLC promise may indicate that the second service provider computer 114 needs to provide a secret in order to complete the interaction to generate receipts.
• any appropriate steps may occur in place of steps 702-708 depending on the promise type and the computer code included in the promise contract to generate the second receipt.
• any appropriate steps may occur in place of steps 712-716 depending on the promise type and the computer code included in the promise contract to generate the first receipt.
• a hotel reservation cancellation process described below, can include different steps that occur prior to providing receipts than steps 702-708 and 712-716.
• the second service provider computer 114 can obtain the secret that was utilized to determine the hash value for the interaction prior to step 602.
• the second service provider computer 114 can obtain the secret from memory.
• the second service provider computer 114 can retrieve the secret of 1234567890000 from memory.
• the second service provider computer 114 can provide the secret and the second promise to the hub computer 112 to claim the amount in the second promise.
• the secret can be included in the second promise.
• the hub computer 112 can evaluate the secret and the second promise. The hub computer 112 can evaluate the secret and the second promise as follows.
• the hub computer 112 can determine if the second promise received from the second service provider computer 114 is a valid promise and has not been maliciously altered. For example, the hub computer 112 can determine whether or not the second promise is included in the second interaction channel’s contract’s list of hub computer outgoing promises. If the second promise, received from the second service provider computer 114, is not included in the second channel contract, then the hub computer 112 cannot complete the claim for the second promise and can stop evaluating the received secret and second promise.
• the hub computer 112 can also evaluate the secret to determine if the secret is valid.
• the hub computer 112 can hash the secret using a hash function to obtain a derived hash value.
• the hub computer 112 can compare the derived hash value to the hash value included in the plurality of parameters included in the second promise. If the derived hash value matches the hash value, then the secret is valid. If the derived hash value does not match the hash value, then the hub computer 112 cannot complete the claim for the second promise and can stop evaluating the received secret and second promise.
• the hub computer 112 can receive the secret of 1234567890000 from the second service provider computer 114.
• the hub computer 112 can then compare the derived hash value of 15618913148 to the hash value included in the plurality of parameters included in the second promise of 15618913148. Since the two values match, the hub computer 112 can proceed with processing the interaction.
• the hub computer 112 can also evaluate the second promise to determine whether or not the second promise has expired based on the expiry time included in the plurality of parameters included in the second promise. [0180] At step 708, after evaluating the secret and the second promise, the hub computer 112 can generate a second receipt.
• the hub computer 112 can generate the second receipt based on the second channel contract, the second promise, the amount of the second promise, and the hub computer private key. For example, the hub computer 112 can generate the second receipt by performing the following steps.
• the hub computer 112 can increment the value of the latest receipt index of the second channel contract. For example, the hub computer 112 can increment the latest receipt index by 1 .
• the hub computer 112 can update the credit out value of the second channel contract.
• the credit out value can indicate the amount owed by the hub computer 112 to the second service provider computer 114.
• the hub computer 112 can update the credit out value based on the amount of the second promise. For example, the hub computer 112 can increase the current credit out value by the amount of the second promise.
• the hub computer 112 also can delete the second promise from the outgoing accumulator included in the second channel contract.
• the hub computer 112 can remove the second promise from the list of hub computer outgoing promises in the channel contract.
• the hub computer 112 can remove the second promise to indicate the second promise is, or is in the process of, being fulfilled.
• the hub computer 112 can obtain the second channel identifier, the latest receipt index, the credit out value, and the second accumulator.
• the hub computer 112 can form a digital signature on the second channel identifier, the latest receipt index, the credit out value, and the second accumulator using the hub computer private key.
• the digital signature can indicate proof that the second promise has been completed.
• the digital signature can be included in the second receipt.
• the hub computer 112 can provide the second receipt to the second service provider computer 114 to indicate completion of the second promise.
• the hub computer 112 and the second service provider computer 114 can close the second interaction channel and settle the amounts included in the second channel contract.
• the second service provider computer 114 can verify the second receipt, as described in step 722.
• the hub computer 112 can utilize the previously created promise mapping between the first promise and the second promise to determine which computer to communicate with regarding the first promise.
• the hub computer 112 can obtain the first promise from the promise mapping using the second promise.
• the hub computer 112 can provide the first promise and the secret to the first service provider computer 104.
• the secret can be included in the first promise.
• the first service provider computer 104 can evaluate the secret and the first promise.
• the first service provider computer 104 can evaluate the secret and the first promise as follows.
• the first service provider computer 104 can determine if the first promise received from the hub computer 112 is a valid promise and has not been maliciously altered. For example, the first service provider computer 104 can determine whether or not the first promise is included in the first interaction channel’s contract’s list of first service provider computer outgoing promises. If the first promise, received from the hub computer 112, is not included in the first channel contract, then the first service provider computer 104 cannot complete the claim for the first promise and can stop evaluating the received secret and first promise.
• the first service provider computer 104 can also evaluate the secret to determine if the secret is valid.
• the first service provider computer 104 can hash the secret using a hash function to obtain a derived hash value.
• the first service provider computer 104 can compare the derived hash value to the hash value included in the plurality of parameters included in the first promise. If the derived hash value matches the hash value, then the secret is valid. If the derived hash value does not match the hash value, then the first service provider computer 104 cannot complete the claim for the first promise and can stop evaluating the received secret and first promise.
• the first service provider computer 104 can receive the secret of 1234567890000 from the hub computer 112.
• the first service provider computer 104 can then compare the derived hash value of 15618913148 to the hash value included in the plurality of parameters included in the first promise of 15618913148. Since, the two values match, the first service provider computer 104 can proceed with processing the interaction.
• the first service provider computer 104 can also evaluate the first promise to determine whether or not the first promise has expired based on the expiry time included in the plurality of parameters included in the first promise.
• the first service provider computer 104 can generate a first receipt.
• the first service provider computer 104 can generate the first receipt based on the first channel contract, the first promise, the amount of the first promise, and the first service provider computer private key.
• the first service provider computer 104 can generate the first receipt by performing the following steps.
• the first service provider computer 104 can increment the value of the latest receipt index of the first channel contract. For example, the first service provider computer 104 can increment the latest receipt index by 1 .
• the first service provider computer 104 can update the credit out value of the first channel contract.
• the credit out value can indicate the amount owed by the first service provider computer 104 to the hub computer 112.
• the first service provider computer 104 can update the credit out value based on the amount of the first promise. For example, the first service provider computer 104 can increase the current credit out value by the amount of the first promise.
• the first service provider computer 104 can also delete the first promise from the outgoing accumulator included in the first channel contract.
• the first service provider computer 104 can remove the first promise from the list of first service provider computer outgoing promises in the first channel contract.
• the first service provider computer 104 can remove the first promise to indicate the first promise is, or is in the process of, being fulfilled.
• the first service provider computer 104 can obtain the first channel identifier, the latest receipt index, the credit out value, and the first accumulator.
• the first service provider computer 104 can form a digital signature on the first channel identifier, the latest receipt index, the credit out value, and the second accumulator using the first service provider computer private key.
• the digital signature can indicate proof that the first promise has been completed.
• the digital signature can be included in the first receipt.
• the first service provider computer 104 can provide the first receipt and the first promise to the hub computer 112.
• the hub computer 112 can verify the first receipt.
• the hub computer 112 can verify the first receipt using the first channel contract, the first receipt, the first promise, and the hub computer verification key.
• the hub computer 112 can verify the first receipt by performing the following steps.
• the hub computer 112 can verify the digital signature included in the first receipt.
• the hub computer 112 can verify the digital signature using the first service provider computer verification key that corresponds to the first service provider computer private key that was used to form the digital signature. If the digital signature is not valid, then the hub computer 112 can proceed to enforce the first channel contract by pushing the first channel contract to the blockchain network. If the digital signature is valid, then the hub computer 112 can proceed with verifying the first receipt. The hub computer 112 can also delete the first promise from the ingoing accumulator included in the first interaction channel. [0201] After verifying the digital signature, the hub computer 112 can add the first receipt to the first channel contract. The hub computer 112 can then increment the latest receipt index of the first channel contract by 1 . The hub computer 112 can also increase the hub computer credit in value by the amount included in the first promise.
• the hub computer 112 can remove the first promise from the hub computer list of ingoing promises included in the first channel contract.
• the hub computer 112 in conjunction with the first service provider computer 104 can close the first interaction channel and settle any credit values in the first interaction contract.
• the second service provider computer 114 can verify the second receipt.
• the second service provider computer 114 can verify the second receipt using the second channel contract, the second receipt, the second promise, and the second service provider computer verification key.
• the second service provider computer 114 can verify the second receipt by performing the following steps.
• the second service provider computer 114 can verify the digital signature included in the second receipt.
• the second service provider computer 114 can verify the digital signature using the hub computer verification key that corresponds to the hub computer private key that was used to form the digital signature. If the digital signature is not valid, then the second service provider computer 114 can proceed to enforce the second channel contract by pushing the second channel contract to the blockchain network. If the digital signature is valid, then the second service provider computer 114 can proceed with verifying the second receipt.
• the second service provider computer 114 can delete the second promise from the ingoing accumulator.
• the second service provider computer 114 can add the second receipt to the second channel contract.
• the second service provider computer 114 can then increment the latest receipt index of the second channel contract by 1 .
• the second service provider computer 114 can also increase the second service provider computer credit in value by the amount included in the second promise.
• the second service provider computer 114 can remove the second promise from the second service provider computer list of ingoing promises included in the second channel contract.
• the hub computer 112 in conjunction with the second service provider computer 114 can close the second interaction channel and settle any credit values in the second interaction contract.
• the channel contract When the interaction channel is closed, the channel contract iterates through the list of unresolved promises, if any, and invokes a resolve function for each of the promise contracts in the computer code.
• the computer code can include any programmed conditions that dictate the amount to be provided from the unresolved promise based on current conditions (e.g., current time, etc.).
• the conditions in the bytecode can be validated/performed when both the first interaction channel and the second interaction channel close.
• the first service provider computer 104 can initiate the closing of the first interaction channel on January 20, 2023 (e.g., because a first user associated with the first service provider computer 104 wishes to cancel their hotel reservation).
• the hub computer 112 can determine the second interaction channel that is associated with the first interaction channel using the promise mapping to initiate the closing of the second interaction channel.
• Each channel contract can execute the promise contract bytecode for each unresolved promise (e.g., including the first promise and the second promise). In this case, there can be two unresolved promises. The first unresolved promise would be for the first service provider computer 104 to pay the hub computer $500, while the second unresolved promise would be for the hub computer 112 to pay the second service provider computer 114 $500.
• the second promise is resolved by the second contract channel by having the hub computer 112 provide $250 to the second service provider computer 114 (e.g., via a deposit or a credit).
• the bytecode can contain logic to perform the messaging to accomplish the above-noted functions.
• Table 4 shows example functions that perform functionalities for the methods described in reference to FIG. 6 and FIG. 7.
• the create promise function CreatePromise(C, type, contract. params, amount, sender, receiver, sk)
• the create promise function may be a function used to create a promise given the following inputs: promise type, the promise contract, which includes contract code to be deployed when the promise is registered, a plurality of parameters (e.g., which can indicate the parameters of the promise needed at the time of the promise deployment), an amount, a sender address, and receiver address.
• the promise bytecode is derived by concatenating the promise contract’s bytecode with the initial inputs to the contract which are given by the plurality of parameters variable from the input.
• the address of the promise contract is derived by using the promise’s bytecode and salt.
• the promise object is created along with a signature on the promise variables by the calling device. Additionally, the created promise is added to a list of outgoing promises of the calling device and the address of the promise is added to the outgoing accumulator accout.
• the outgoing accumulator can be used to cryptographically keep track of promises and can be used to prove that a particular promise was created.
• a verify promise function VerifyPromise(C, P, contract, params, sender, receiver, vk) may be a function that is paired with the create promise function, which verifies a promise. Similar to the create promise function, the bytecode and the address of the promise is derived from the input values. The verify promise function can check that the counter-party has sufficient funds to cover for the amount of the promise. The verify promise function can also verify the signature of the counter-party on the promise variables. After the two verifications, the promise is added to the a list of ingoing promises and the promise’s address is inserted into the ingoing accumulator (acdn). Further, the aggregated ingoing pending promise amount (netProrriin) is updated such that the next promise amounts do not exceed the collateral and credits that the counter-party holds.
• Table 5 shows an example off-chain interaction protocol that includes pseudocode illustrating the methods described in reference to FIG. 6 and FIG. 7.
• FIG. 8 shows a block diagram of a universal payment channel system according to embodiments.
• the universal payment channel system may comprise the hub computer 112.
• the hub computer 112 may communicate with a variety of computers, and may allow the computers to perform transactions between each other.
• the first computer 804 may transmit payments to the second computer 806 via the hub computer 112.
• the hub computer 112 may facilitate payments between any two pairs of computers 804, 806, 808, 810, 812, 814 shown in FIG. 8 by establishing an interaction channel with each computer.
• Embodiments of the disclosure have a number of advantages. For example, embodiments allow a user to perform blockchain interactions using their user device. Standard user devices can install applications managed by service providers. The service providers may perform blockchain operations on behalf of the user device, reducing the burden of computation from the user. Embodiments provide for an off-chain and cross-chain interactions. Embodiments deploy a smart contract to a blockchain network that implements an interaction channel between a user device via a service provider computer and a hub computer. The interaction channel can be used to transfer amounts of digital currencies to a smart contract. The transfers performed by the interaction channel need not be written to the blockchain network.
• a promise and receipt scheme are used, where a promise includes parameters of the smart contract at the time of a proposed transfer, and a receipt includes parameters of the smart contract after a proposed transfer is completed off-chain.
• the promise or the receipt can be used to write a transfer on- chain to the blockchain network.
• the channel contract includes executable bytecode (or generically, computer code).
• the bytecode can be utilized to apply rules, conditions, and/or additional processing that can dictate how the interaction is performed.
• the bytecode can allow for the user device to both promise an amount, while being able to re-obtain the amount in the case of cancelling the interaction via the bytecode (e.g., the user is able to cancel a reservation at a hotel even though the funds have been promised).
• Embodiments provide for a number of additional advantages.
• the interaction channel does not need to be altered for use with new types of promise contracts.
• promise contracts can provide bytecode that executes new types of interactions and any type of conditional functionality.
• the interaction channel provides the benefit of being versatile by being able to execute any promise contract.
• Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques.
• the software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like.
• RAM random access memory
• ROM read only memory
• magnetic medium such as a hard-drive or a floppy disk
• an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like.
• the computer readable medium may be any combination of such storage or transmission devices.
• Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet.
• a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs.
• Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g. a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network.
• a computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Computer Security & Cryptography (AREA)
• General Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• General Physics & Mathematics (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• Finance (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Applications Claiming Priority (2)

Publications (2)

Family

ID=86731322

Family Applications (1)

Country Status (4)

Families Citing this family (3)

Family Cites Families (11)

• 2022
  • 2022-12-09 EP EP22905414.3A patent/EP4445321A4/de not_active Withdrawn
  • 2022-12-09 CN CN202280080809.2A patent/CN118355399A/zh active Pending
  • 2022-12-09 US US18/716,450 patent/US20250045751A1/en active Pending
  • 2022-12-09 WO PCT/US2022/081278 patent/WO2023108127A1/en not_active Ceased

Also Published As

Similar Documents

Legal Events