Systems and methods to mitigate network congestion on a blockchain network by supporting blockchain operations via off-chain interactions

Abstract

Systems and methods to mitigate network congestion on a blockchain network by supporting blockchain operations via off-chain interactions. For example, upon receiving a communication to initiate an off-chain event and / or a blockchain operation, the system can determine various characteristics about the addresses involved. In particular, the system can determine whether the addresses correspond to a cryptography-based storage application that shares a common platform service.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims priority to U.S. Patent Application No. 17 / 841,280, filed June 15, 2022. The contents of the foregoing application are incorporated herein by reference in their entirety.

[0003] BACKGROUND

[0004] In recent years, the use of blockchain and blockchain technology has grown exponentially. A blockchain includes a list of records, called “blocks,” that are “chained” together using cryptography. Each block can include data computed using a one-way function (e.g., a function that is virtually impossible to reverse or reverse compute) of the previous block, a timestamp (e.g., indicating a time of creation and / or modification), and additional data (e.g., transaction or operation data related to blockchain operations).

[0005] While the hype around blockchain and blockchain technology has focused on its use for cryptocurrencies and smart contracts, blockchain and blockchain technology can be applicable to many technical approaches. One common theme of technical approaches is the decentralized way in which blockchain and blockchain technology is such that the facilitation, management, and / or validation of blockchain-based operations is governed or managed not by any one institution but by a community of users. As such, a blockchain can be kept distributed (e.g., on a network of computers that communicate and coordinate their actions by passing messages to each other) by a digital ledger that records a chain of blocks, and in many cases is public. Notably, because each block relies on the previous block, it can not be possible to edit an existing block in the chain without affecting subsequent blocks.

[0006] Further, updates to a blockchain (e.g., adding new blocks) can include an incentive system that rewards community members for generating updates while also ensuring that the community reaches a consensus. By doing so, the proliferation of a blockchain can proceed indefinitely.

[0007] SUMMARY

[0008] Described herein are novel uses and / or improved systems and methods for blockchain and blockchain technology. As one example, described herein are systems and methods for mitigating network congestion on a blockchain network by enabling off-chain interactions between cryptography-based storage applications via a shared common platform. More specifically, systems and methods describe the use of a platform service that can facilitate the use of cryptocurrencies in everyday interactions between users. For example, while awareness of cryptocurrencies and their use in decentralized applications has increased in recent years, one fundamental problem with further adoption of cryptocurrencies is that they cannot be used for everyday commercial interactions between users. This fundamental problem is based on numerous technical challenges faced by blockchain networks. For example, in order for a blockchain network to function, the network relies on community members to mine new blocks so that new blockchain operations can be recorded in the blockchain. Thus, before any blockchain operation can be confirmed, the blockchain operation must wait for a new block to be mined. This delay can take several minutes or more (e.g., depending on how many blocks need to be mined). As the delay increases, the risk of bottlenecks related to serial blockchain operations also increases. Moreover, as more blockchain operations are submitted to the blockchain network, the delay and bottlenecks only intensify, leading to further network congestion.

[0009] To overcome these technical deficiencies in conventional systems, the systems and methods disclosed herein mitigate network congestion on a blockchain network by enabling blockchain operations via off-chain interactions. For example, upon receiving a communication that initiates an off-chain event and / or a blockchain operation, the system can determine various characteristics about the addresses involved. In particular, the system can determine whether the addresses correspond to cryptography-based storage applications that share a common platform service. If so, the system can avoid using on-chain events (e.g., submitting a blockchain operation to the blockchain network) by using an off-chain ledger. That is, the system can modify the off-chain ledger of the platform service to reflect the blockchain operation without performing a synchronous on-chain event between the first and second cryptography-based storage applications via the blockchain network. By doing so, the system can avoid causing further network congestion.

[0010] In some aspects, systems and methods are described for mitigating network congestion on a blockchain network by supporting off-chain interactions between cryptography-based storage applications via a shared common platform for blockchain operations. For example, a system can receive a communication initiating an off-chain response corresponding to a blockchain operation on a blockchain network, where the off-chain response corresponds to a first user. The system can determine, based on the communication, a first address of a first cryptography-based storage application for conducting the blockchain operation, where the first cryptography-based storage application corresponds to the first user, and where the first cryptography-based storage application is managed by a platform service. The system can determine, based on the communication, a second address of a second cryptography-based storage application for conducting the blockchain operation, where the second cryptography-based storage application corresponds to a second user. The system can determine whether the second cryptography-based storage application is managed by the platform service. In response to determining that the second cryptography-based storage application is managed by the platform service, the system can modify an off-chain ledger of the platform service to reflect the blockchain operation without performing a synchronous on-chain event between the first cryptography-based storage application and the second cryptography-based storage application over the blockchain network. The system can transmit the off-chain response from the platform service to the second user.

[0011] Various other aspects, features, and advantages of the present application will become apparent from the detailed description and drawings. It should be understood, however, that the detailed description and specific examples, while indicating preferred embodiments of the present application, are given by way of illustration only and are not intended to limit the scope of the present application. As used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise. Furthermore, as used in this specification and the appended claims, the term "or" means "and / or" unless the context clearly dictates otherwise. Additionally, as used in this specification and the appended claims, the term "part" refers to a portion or all (i.e., the entire portion) of a given item (e.g., data). BRIEF DESCRIPTION OF DRAWINGS

[0013] Figure 1 A schematic of a user interface for performing operations to mitigate network congestion is shown in accordance with one or more embodiments.

[0014] Figure 2 A schematic of a blockchain operation is shown in accordance with one or more embodiments.

[0015] Figure 3 A schematic of a decentralized application is shown in accordance with one or more embodiments.

[0016] Figure 4A diagram illustrating a user interface for performing operations to mitigate network congestion is shown in accordance with one or more embodiments.

[0017] Figure 5 A diagram illustrating a blockchain indexer in accordance with one or more embodiments is shown.

[0018] Figure 6 A flow diagram illustrating steps involved in mitigating network congestion on a blockchain network by supporting blockchain operations via off-chain interactions in accordance with one or more embodiments is shown.

[0019] DETAILED DESCRIPTION

[0020] In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of embodiments of the application. It can be apparent, however, to one skilled in the art that embodiments of the present application can be practiced without some or all of these specific details. In other instances, well known structures and devices are not shown in order to avoid obscuring embodiments of the present application.

[0021] Figure 1 A diagram illustrating a user interface for performing operations to mitigate network congestion is shown in accordance with one or more embodiments. For example, Figure 1 User interfaces 100 and 150 are shown. As referred to herein, a “user interface” can include mechanisms for the

[0022] The user interface 100 can correspond to a screen for creating a communication for initiating an off-chain response corresponding to a blockchain operation on a blockchain network, where the off-chain response corresponds to the first user. For example, while awareness of cryptocurrencies and their use in decentralized applications has increased in recent years, one fundamental problem with further adoption of cryptocurrencies is that they cannot be used for day-to-day commercial interactions between users. This fundamental problem presents a number of technical problems because there currently does not exist a mechanism for integrating blockchain-based transactions (e.g., communications, transactions, etc. performed on-chain via one or more smart contracts) and off-chain responses (e.g., communications, transactions, etc. performed off-chain via conventional means). For example, a merchant (e.g., a second user) can want to offer a cryptocurrency payment option to its customers (e.g., a first user).

[0023] The first user can use the user interface 100 to create a charge (e.g., a payment intent). The first user can create the charge via selecting an icon in the user interface 100. For example, the first user can select a “Pay with Coinbase” option as shown in the user interface 100, which can open an iframe for the user to log into a platform service and authenticate themselves in order to access their digital assets in a user account on the platform service.

[0024] In response to the selection, the system can generate a user interface 150. For example, the user interface 150 can generate content for facilitating the blockchain operation. For example, the system can generate a machine-readable optical label. The label can include a quick response (QR) code generated based on information related to the user, the platform service, and / or the current blockchain operation. For example, the second user can include a merchant that scans a quick response (QR) code displayed on the first user’s mobile device. The QR code can include information (e.g., off-chain characteristics) about the off-chain response, such as the entities involved, the price of the good or service in question, and so on. For example, the off-chain characteristics can include any characteristic that can distinguish one off-chain response from another. In some embodiments, the off-chain response can include an electronic payment. In this case, the off-chain characteristics can include an amount of the electronic payment.

[0025] For example, the user interface 150 can include a cryptographic communication for initiating an off-chain response corresponding to a blockchain operation on a blockchain network. Upon receipt of the communication by the platform service, the platform service can determine a secure user account hosted by the platform service corresponding to the first user based on the cryptographic communication. For example, the system can determine a first address of a first cryptography-based storage application to use to conduct the blockchain operation, where the first cryptography-based storage application corresponds to the first user.

[0026] Additionally or alternatively, the cryptography-based storage application can refer to a digital wallet or other cryptography-based digital repository. A digital wallet can include a software-based system that securely (and often in encrypted format) stores user, confidential information, personal information, payment information, and / or passwords for numerous payment methods and websites. By using a digital wallet, a user can easily and securely complete communications, purchases, and / or other blockchain operations without the risk of information becoming public or subject to cyber attacks.

[0027] For example, the first cryptography-based storage application can be a non-custodial cryptography-based storage application. That is, the first cryptography-based storage application can be a separate standalone application that allows a user to store their own passwords or maintain custody of their own passwords and explore the decentralized web with a decentralized application browser. The first cryptography-based storage application can be a standalone application that does not require interaction with a user account (e.g., an account from a blockchain service provider, a centralized brokerage, and / or an exchange). The first cryptography-based storage application can allow a user to manage their own private keys and store their cryptographic assets directly (without going through a centralized brokerage or exchange) on their device.

[0028] Alternatively, the first cryptography-based storage application can be a custodial or semi-custodial cryptography-based storage application. That is, the first cryptography-based storage application can be a separate standalone application that allows a user to store their own passwords or maintain custody of their own passwords and explore the decentralized web with a decentralized application browser through an application provided by a blockchain service provider, a centralized brokerage, and / or an exchange. The first cryptography-based storage application can be an application that requires interaction with a user account from a blockchain service provider, a centralized brokerage, and / or an exchange. The first cryptography-based storage application can allow a user to have their private keys managed by a blockchain service provider, a centralized brokerage, and / or an exchange without needing to store their own private keys (at least completely) and cryptographic assets directly on their device.

[0029] In generating the communication (e.g., as described above Figure 1After the fee for the creation is shown, the system can receive the wallet addresses of the first user and the second user. The system can then determine whether the first user and / or the second user share a common platform service. If the addresses correspond to a platform service, the system can perform an off-chain transaction. For example, if both addresses correspond to a platform service, the platform service can provide instant confirmation of blockchain operations, contactless transactions (e.g., by processing transactions off-chain), and / or other features. That is, if the system determines that a platform service is used, the system can process blockchain operations in an off-chain manner that avoids excessive network fees and processing costs. Conversely, if the addresses do not correspond to a platform service, the system can perform an on-chain transaction.

[0030] Figure 2 An illustration of a system for performing blockchain operations is shown in accordance with one or more embodiments. For example, in some embodiments, the illustration presents various components that can be used to mitigate network congestion on a blockchain network by supporting blockchain operations that occur via off-chain interactions.

[0031] Figure 2 The user device 202 can include a user interface. As shown, the system 200 can include a plurality of user devices (e.g., the user device 202, the user device 208, and / or the user device 210). For example, the system 200 can include a distributed state machine in which each component in Figure 2 Figure 2 For example, the system 200 (and other systems described herein) can include a large data structure that not only holds all accounts and balances but also holds the state machine, which can change between blocks according to a predefined set of rules and can execute arbitrary machine code. The specific rules that change the state between blocks can be maintained by a virtual machine of the system (e.g., a computer file implemented on and / or accessible by a user device that behaves like an actual computer).

[0032] It should be noted that while shown as a smartphone, a personal computer, and a server in Figure 2 It should be noted that while shown as a smartphone, a personal computer, and a server in

[0033] ​The system can use each of the user devices to conduct blockchain operations and / or to help mitigate network congestion. As referred to herein, “blockchain operations” can include any operations that include and / or involve blockchain and blockchain technology. For example, blockchain operations can include conducting transactions, querying a distributed ledger, generating additional blocks for a blockchain, transferring non-falsifiable tokens related to communications, performing encryption / decryption, exchanging public / private keys, and / or other operations involving blockchain and blockchain technology. In some embodiments, blockchain operations can include creating, modifying, detecting, and / or executing smart contracts or programs stored on a blockchain. For example, a smart contract can include a program stored on a blockchain that is executed (e.g., automatically, without any intermediary involvement or time loss) when one or more predetermined conditions are met. In some embodiments, blockchain operations can include creating, modifying, exchanging, and / or reviewing tokens (e.g., digital assets specific to a blockchain), including non-falsifiable tokens. Non-falsifiable tokens can include tokens associated with goods, services, smart contracts, and / or other content that can be verified by and stored using blockchain technology.

[0034] In some embodiments, blockchain operations can also include actions related to mechanisms that facilitate other blockchain operations (e.g., actions related to metering activity of blockchain operations on a given blockchain network). For example, Ethereum is an open-source, global, decentralized computing infrastructure that executes smart contracts using a blockchain to synchronize and store state changes of the system. Ethereum uses a network-specific cryptocurrency called ether to meter and constrain the cost of execution resources. The metering mechanism is referred to as “gas.” When the system executes a smart contract, the system considers each blockchain operation (e.g., computation, data access, transaction, etc.). Each blockchain operation has a predetermined cost in units of gas (e.g., as determined based on a predefined set of rules of the system). When a blockchain operation triggers execution of a smart contract, the blockchain operation can include an amount of gas that sets an upper limit on the amount of gas that can be consumed while running the smart contract. If the amount of gas consumed by the computation exceeds the gas available in the blockchain operation, the system can terminate execution of the smart contract. For example, in Ethereum, gas includes a mechanism for allowing Turing-complete computation while limiting the resources that any smart contract and / or blockchain operation can consume.

[0035] In some embodiments, fuel can be obtained using a network-specific cryptocurrency (e.g., in the case of Ethereum, Ether) as part of a blockchain operation (e.g., a purchase). The system can require fuel (or an amount of network-specific cryptocurrency corresponding to the amount of fuel required) to be transmitted with a blockchain operation as an earmark for the blockchain operation. In some embodiments, fuel earmarked for a blockchain operation can be refunded to the initiator of the blockchain operation if a certain amount remains unused after the computation is performed.

[0036] As shown in Figure 2 one or more user devices can include a digital wallet (e.g., digital wallet 204) for performing blockchain operations. For example, a digital wallet can include a storage library that allows a user to store, manage, and trade their cryptocurrencies and assets, interact with a blockchain, and / or perform blockchain operations using one or more applications. A digital wallet can be specific to a given blockchain protocol or can provide access to multiple blockchain protocols. In some embodiments, the system can use various types of wallets, such as hot wallets and cold wallets. A hot wallet is connected to the internet, while a cold wallet is not connected to the internet. Most digital wallet holders hold both hot and cold wallets. Hot wallets are most commonly used to perform blockchain operations, while cold wallets are typically used to manage user accounts and can not have an internet connection.

[0037] As shown in Figure 2 one or more user devices can include a private key (e.g., key 212) and / or a digital signature. For example, the system 200 can use a cryptographic system to perform blockchain operations and mitigate network congestion on a blockchain network by supporting blockchain operations via off-chain interactions. For example, the system 200 can use public-key cryptography, which features a pair of digital keys (e.g., which can include a string of data). In this case, each pair includes a public key (e.g., which can be public) and a private key (e.g., which can remain private). The system 200 can use an encryption algorithm (e.g., featuring a one-way function) to generate a key pair. The system 200 can then use the public key of the intended recipient to encrypt a message (or other blockchain operation) so that the encrypted message can only be decrypted with the corresponding private key of the recipient. In some embodiments, the system 200 can combine a message with a private key to create a digital signature on the message. For example, a digital signature can be used to verify the authenticity of a blockchain operation. To illustrate, when performing a blockchain operation, the system 200 can use a digital signature to prove to each node in the system that it is authorized to perform the blockchain operation.

[0038] For example, the system 200 can include a plurality of nodes for a blockchain network. Each node can correspond to a user device (e.g., the user device 208). The nodes of the blockchain network can include an application or other software that records and / or monitors peer-to-peer connections to other nodes and / or miners of the blockchain network. For example, a miner includes a node in the blockchain network that facilitates blockchain operations on the blockchain by verifying blockchain operations on the blockchain, adding new blocks to the existing chain, and / or ensuring that these additions are accurate. The nodes can continuously record the state of the blockchain and respond to remote process requests for information about the blockchain.

[0039] For example, the user device 208 can request a blockchain operation (e.g., make a transaction). The blockchain operation can be authenticated by the user device 208 and / or another node (e.g., a user device in the community network of the system 200). For example, using cryptographic keys, the system 200 can identify the user and give access to their corresponding user account (e.g., a corresponding digital wallet) within the system 200. Using a private key (e.g., known only to the corresponding user) and a public key (e.g., known to the community network), the system 200 can create a digital signature to authenticate the user.

[0040] After the blockchain operation is authenticated (e.g., using the key 212), the blockchain operation can be authorized. For example, after the blockchain operation is authenticated between users, the system 200 can authorize the blockchain operation before adding the blockchain operation to the blockchain. The system 200 can add the blockchain operation to the blockchain 206. The system 200 can perform this operation based on consensus of the user devices within the system 200. For example, the system 200 can rely on a majority (or other metric) of the nodes (e.g., the user device 202, the user device 208, and / or the user device 210) in the community network to determine that the blockchain operation is valid. In response to the validation of the block, the node user devices (e.g., the user device 202, the user device 208, and / or the user device 210) in the community network (e.g., miners) can receive a reward (e.g., a given cryptocurrency) as an incentive for validating the block.

[0041] To validate blockchain operations, the system 200 can use one or more validation protocols and / or validation mechanisms. For example, the system 200 can use a proof-of-work mechanism, in which user devices must provide proof that they performed computational work to validate blockchain operations, and thus this mechanism provides a way to achieve consensus in a decentralized manner and prevent fraudulent validation. For example, the proof-of-work mechanism can involve iterations of a hash algorithm. A successful user device aggregates and records blockchain operations from a pool of storage (e.g., a collection of all valid blockchain operations waiting to be confirmed by the blockchain network) into the next block. Alternatively or additionally, the system 200 can use a proof-of-stake mechanism, in which user accounts (e.g., corresponding to nodes on the blockchain network) are required to have or “stake” a predetermined amount of tokens in order for the system 200 to identify that user account as a validator in the blockchain network.

[0042] In response to validation of the block, the block is added to the blockchain 206, and the blockchain operation is completed. For example, to add the blockchain operation to the blockchain 206, a successful node (e.g., a successful miner) encapsulates the blockchain operation in a new block before transmitting the block throughout the system 200.

[0043] Figure 3 A schematic diagram of a decentralized application is shown, in accordance with one or more embodiments. For example, in some embodiments, the system 300 can perform blockchain operations within a decentralized application environment. The decentralized application can include an application that exists on a blockchain (e.g., the blockchain 302) and / or a peer-to-peer network (e.g., the network 306). That is, the decentralized application can include an application that has a backend powered in part by a decentralized peer-to-peer network, such as a decentralized open-source blockchain with smart contract functionality.

[0044] For example, the network 306 can allow user devices (e.g., the user device 304) within the network 306 to share files and access. In particular, the peer-to-peer architecture of the network 306 allows for blockchain operations (e.g., corresponding to the blockchain 302) between user devices in the network without the need for any intermediaries or central authorities.

[0045] In some embodiments, the user devices of system 300 can include one or more cloud components. For example, a cloud component can be implemented as a cloud computing system and can feature one or more component devices. It should also be noted that system 300 is not limited to four devices. For example, a user can utilize one or more devices to interact with each other, with one or more servers, or with other components of system 300. It should further be noted that while one or more operations (e.g., blockchain operations) are described herein as being performed by a particular component of system 300 (e.g., user device 304), in some embodiments those operations can be performed by other components of system 300. As an example, while one or more operations are described herein as being performed by a component of user device 304, in some embodiments those operations can be performed by one or more cloud components. In some embodiments, the various computers and systems described herein can include one or more computing devices programmed to perform the described functions. Additionally or alternatively, multiple users can interact with system 300 and / or one or more components of system 300. For example, in one embodiment, a first user and a second user can interact with system 300 using two different components (e.g., user device 304 and user device 308, respectively). Additionally or alternatively, a single user (and / or a user account linked to a single user) can interact with system 300 and / or one or more components of system 300 using two different components (e.g., user device 304 and user device 308, respectively).

[0046] With respect to the components of system 300, each of these devices can receive content and data via input / output (hereinafter “I / O”) paths using I / O circuitry. Each of these devices can also include a processor and / or control circuitry to send and receive commands, requests, and other suitable data using the I / O paths. The control circuitry can include any suitable processing, storage, and / or I / O circuitry. Each of these devices can also include a user input interface and / or a user output interface (e.g., a display) for receiving and displaying data. For example, as shown, user device 308 and user device 310 both include a display on which data (e.g., content related to one or more blockchain operations) is displayed. Figure 3 As shown, user device 308 and user device 310 both include a display on which data (e.g., content related to one or more blockchain operations) is displayed.

[0047] Additionally, the devices in system 300 can run an application (or another suitable program). The application can cause the processor and / or control circuitry to perform relevant operations to mitigate network congestion on a blockchain network by supporting blockchain operations via off-chain interactions within a decentralized application environment.

[0048] Each of these devices can also include electronic storage. The electronic storage can include a non-transitory storage medium that electronically stores information. The electronic storage medium of an electronic storage can include one or both of (i) system storage that is provided integrally (e.g., substantially cannot be removed) with servers or client devices such as an operating system, driver software and the like, and / or (ii) removable storage that can be removably connected to a server or a client device via, for example, a port (e.g., a USB port, a firewire port, etc.) or a drive (e.g., a disk drive, etc.). The electronic storage can include one or more of optically readable storage media (e.g., optical disks, etc.), magnetically readable storage media (e.g., magnetic tape, magnetic hard drive, floppy drive, etc.), electrical charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drive, etc.), and / or other electronically readable storage media. The electronic storage can include one or more virtual storage resources (e.g., cloud storage, virtual private networks, and / or other virtual storage resources). The electronic storage can store software algorithms, information determined by the processors, information obtained from servers, information obtained from client devices, or other information that implements the functionality as described herein.

[0049] Figure 3 Also included is a network 306, which can include communication paths between user devices. The communication paths can include the Internet, mobile phone networks, mobile voice or data networks (e.g., 5G or LTE networks), cable networks, public switched telephone networks, or other types of communication networks or combinations of communication networks. The communication paths can individually or collectively include one or more communication paths such as satellite paths, fiber optic paths, cable paths, paths that support Internet communications (e.g., IPTV), free-space connections (e.g., for broadcast or other wireless signals), or any other suitable wired or wireless communication paths or combinations of such paths. Computing devices can include additional communication paths that link together multiple hardware, software, and / or firmware components that operate together. For example, a computing device can be implemented by a cloud of computing platforms that operate together as a computing device.

[0050] Figure 4A diagram is shown for operating in a decentralized application using blockchain operations, in accordance with one or more embodiments. For example, system 400 can include a user device 402. Further, user device 402 can include an application (e.g., application 404) implemented on user device 402 and / or accessible by user device 402. For example, application 404 can interact with one or more other applications and / or application programming interfaces (APIs) in order to mitigate network congestion. For example, application 404 can include a decentralized application digital wallet and / or wallet service that is capable of signing and sending transactions to transfer tokens and / or perform other blockchain operations, as well as interacting with one or more decentralized applications.

[0051] System 400 also includes an API layer 406. In some embodiments, API layer 406 can be implemented on user device 402. Alternatively or additionally, API layer 406 can reside on one or more cloud components (e.g., server 408). For example, API layer 406 can reside on server 408 and include a platform service for custodial wallet services, decentralized applications, etc. API layer 406 (which can be a REST or web service API layer) can provide a decoupled interface to data and / or functionality of one or more applications.

[0052] API layer 406 can provide various low-level and / or blockchain-specific operations in order to mitigate network congestion on a blockchain network by supporting blockchain operations via off-chain interactions. For example, API layer 406 can provide blockchain operations such as blockchain writes. Further, API layer 406 can perform transfer validation before forwarding a blockchain operation (e.g., a transaction) to another service (e.g., a cryptography service). API layer 406 can then record the result. For example, by recording to the blockchain before forwarding, API layer 406 can maintain an internal record and balance without relying on external validation (e.g., based on blockchain update activity, which can take up to ten minutes).

[0053] API layer 406 can also provide information reading. For example, API layer 406 (or a platform service powered by API layer 406) can generate a blockchain operation log and write the result of the read to an additional ledger (e.g., an internal record and / or indexer service). If this is done, a user accessing information by other means can see consistent information such that downstream user ingestion takes the same data points as the user.

[0054] The API layer 406 can also provide a uniform API to access balances, transaction histories, and / or other records of blockchain operational activity between one or more decentralized applications and custodian user accounts. By doing so, the system maintains the security of sensitive information such as balances and transaction histories. Alternatively, the mechanism for maintaining this security would be separated between the decentralized applications and custodian user accounts by using special logic for API access. The introduction of special logic reduces the streamlining of the system, which can result in system errors based on divergence and coordination.

[0055] The API layer 406 can provide a common, language-agnostic way to interact with applications. In some embodiments, the API layer 406 can include a web services API that provides well-defined contracts that describe services in terms of the operations of the service and the data types used to exchange information. REST APIs typically do not have this contract; instead, they use client libraries in most common languages, including Ruby, Java, PHP, and JavaScript. SOAP web services are traditionally employed in enterprises for publishing internal services and for exchanging information with partners in business-to-business (B2B) transactions.

[0056] The API layer 406 can use various architectural arrangements. For example, the system 400 can be based in part on the API layer 406 such that there is strong adoption of SOAP and RESTful web services, use of resources such as a Service Repository and Developer Portal, but with low governance, standardization, and separation of concerns. Alternatively, the system 400 can be based entirely on the API layer 406 such that the separation of concerns between layers such as the API layer 406, services, and applications is in place.

[0057] In some embodiments, the system architecture may use a microservices approach. Such a system may use two types of layers: a front-end layer and a back-end layer where microservices reside. In this architecture, the role of API layer 406 may be to provide integration between the front-end and back-end layers. In such a case, API layer 406 may use RESTful APIs (exposed to communication between the front-end or even microservices). API layer 406 may use the Advanced Message Queuing Protocol (AMQP), an open standard for delivering business messages between applications or organizations. API layer 406 may use an open-source, high-performance Remote Procedure Call (RPC) framework that can run in a decentralized application environment. In some embodiments, the system architecture may use an open API approach. In this case, API layer 406 may use commercial or open-source API platforms and their modules. API layer 406 may use a developer portal. API layer 406 may use strong security constraints from an application web application firewall that protects decentralized applications and / or API layer 406 from common web vulnerabilities, bots, and denial-of-service (DoS) attacks. API layer 406 may use RESTful APIs as a standard for external integration.

[0058] like Figure 4 As shown, system 400 can use API layer 406 to communicate with server 408 and / or facilitate blockchain operations on server 408. For example, server 408 may represent a custodian platform for blockchain operations. The custodian platform may manage private keys stored by a centralized service provider (e.g., server 408). In this case, server 408 may communicate with blockchain 410, a wallet service for blockchain 410, an indexer service for blockchain 410 (e.g., such as...). Figure 5 Interactions with (as described in the document) and / or other platform services.

[0059] For example, a wallet service may include an application and / or software-based system that securely stores a user's payment information, private keys, and / or passwords, thereby facilitating blockchain operations on websites, nodes, and / or other devices. In some embodiments, the wallet service may also provide additional ledger access (e.g., a second ledger). Furthermore, as mentioned above, this second ledger may receive updates directly from API layer 406, rather than relying on data extracted directly from blockchain 410.

[0060] For example, the system 400 can maintain its records (e.g., real-time records and records for bookkeeping) in good order, separate from the balances on the blockchain 410. That is, the system 400 can maintain an architecture featuring a second ledger (on which balances are stored and updated) and a log of blockchain operations. Conventional systems can rely on direct references to the blockchain 410, but because the blockchain is the system’s source of truth, such reliance leads to additional technical problems.

[0061] First, there is likely to be an impedance mismatch between the format of the platform services and the API used to retrieve data from the blockchain (e.g., this can lead to bookkeeping imbalances). For example, the system 400 can need to be able to generate bookkeeping entries that reflect changes in balances. However, while changes in balances can be tracked by inspecting the blockchain 410, this requires additional processing and computing power.

[0062] Second, bookkeeping changes in a blockchain architecture should be irreversible. In practice, this is achieved for current blockchain operations by waiting for a variable number of confirmations from the blockchain (e.g., the blockchain 410). By waiting for a variable number of confirmations, the likelihood of an error in the blockchain becomes infinitely small. However, while this approach is relied on by blockchain services, it is not a rule inherent to the blockchain itself. That is, the blockchain does not have an inherent authentication mechanism that relies on a large number of confirmations. Rather, the blockchain relies on an absolute system - a blockchain operation is either recorded on a particular node or it is not.

[0063] Accordingly, forks in the blockchain are always possible. In the case of a fork, the system 400 can not follow the “right” fork for an indeterminate amount of time. If this happens, and if the system 400 decides to move from one fork to the other for the purpose of custodizing a digital wallet, the system 400 can have a more straightforward mechanism to maintain an accurate history of the user account location if the system 400 stores the user account location independently of the given blockchain. Moreover, in the case of a fork, the system 400 performs some internal remediation on the user account, which is achieved by the system 400 maintaining an insulation layer from the blockchain for remedying blockchain operations. For example, the system 400 can have separate storage protected by the second ledger (e.g., the ledger service) for reading and by the transfer service for writing, which reflects the state of the blockchain relevant to the system 400 purposes.

[0064] In some embodiments, the system can also use one or more application binary interfaces (ABIs). An ABI is an interface between two program modules, typically between an operating system and a user program. An ABI can be specific to a blockchain protocol. For example, the Ethereum Virtual Machine (EVM) is a core component of the Ethereum network, and a smart contract can be a piece of code stored on the Ethereum blockchain that executes on the EVM. A smart contract written in a high-level language such as Solidity or Vyper can be compiled by the system into EVM executable bytecode. When a smart contract is deployed, the bytecode is stored on the blockchain and associated with an address. To access a function defined in a high-level language, the system translates the name and arguments into a byte representation of the bytecode to use it for work. To interpret the bytes sent in a response, the system converts back to a tuple of return values defined in a high-level language (e.g., a finite, ordered list of elements). The language compiled for the EVM maintains strict conventions about these conversions, but to perform them, the system must maintain the precise names and types associated with operations. The ABI precisely records these names and types in a format that is easy to parse, translating between human-expected method calls and discoverable and reliable smart contract operations.

[0065] For example, an ABI defines methods and structures for interacting with binary contracts similar to APIs, but at a lower level. The ABI instructs a caller of a function to encode (e.g., ABI-encode) information needed like function signatures and variable declarations in a format that the EVM can understand to call the function in bytecode. ABI-encoding can be done automatically by the system using a compiler or a wallet that interacts with the blockchain.

[0066] Figure 5 A diagram illustrating a blockchain indexer at a platform service is shown in accordance with one or more embodiments. For example, in some embodiments, the system can use an indexer service 500 to mitigate network congestion. The indexer service 500 can obtain raw data (e.g., data related to the current state and / or instance of the blockchain 502) from nodes of the blockchain network (e.g., as described above). The indexer service 500 can then process the data and store the data in an efficient manner in a database and / or data structure to provide fast access to the data. For example, an indexer 504 can publish and / or record a subset of blockchain operations that occurred for the blockchain 502. Thus, for subsequent blockchain operations, the indexer service 500 can reference the index at the indexer 504 (rather than a node of the blockchain 502) to provide various services at a platform service 506.

[0067] In some embodiments, the indexer 504 can be used as an off-chain ledger to mitigate network congestion during blockchain operations. For example, the system can modify records, values, and / or entries in the indexer 504 to reflect blockchain operations without the need to perform a synchronous on-chain event through the blockchain network. By doing so, the indexer 504 can avoid network fees and processing costs. For example, the indexer 504 can receive a communication (e.g., a fee) based on an interaction of the user device 508 and the user device 510. In some embodiments, the user device 508 and the user device 510 can correspond to the user interface 100 Figure 1 and the user interface 150 Figure 1 , respectively.

[0068] For example, the system (e.g., the indexer 504 located at the platform service 506) can receive a communication (e.g., from the user device 508) to initiate an off-chain response corresponding to a blockchain operation (e.g., the blockchain 502) on a blockchain network. The platform service can then determine whether a recipient of the blockchain operation (e.g., corresponding to the user device 510) uses an account managed by the platform service 506.

[0069] For example, the indexer 504 can store a predetermined list of blockchain operations to monitor for and / or record by index. These can include blockchain operations related to a given type of blockchain operation (e.g., “transaction,” “external transfer,” “internal transfer,” “new contract metadata,” “ownership change,” etc.) and blockchain operations related to a given protocol, protocol sub-group, and / or other characteristic (e.g., “ETH,” “ERC20,” and / or “ERC721”). Additionally and / or alternatively, various blockchain operations and metadata related to those blockchain operations (e.g., block designations, user accounts, timestamps, etc.) and aggregations of multiple blockchain operations (e.g., total blockchain operation quantity, rate of blockchain operations, rate of blockchain updates, etc.) can be monitored and / or recorded.

[0070] The indexer 504 can also provide navigation and search features (e.g., support Boolean operations) for the indexed blockchain operations. In some embodiments, the indexer 504 can apply one or more formatting protocols to generate a representation of the indexed blockchain operations in a human-readable format. In some embodiments, the indexer 504 can also tag the blockchain operations based on whether the blockchain operations originated from a local user account (e.g., a user account corresponding to a custodial account) and / or a locally-hosted digital wallet. The indexer service 500 can determine whether a blockchain operation contains relevant information for a user of the indexer service 500 by storing information about whether an address is an internal address of the indexer service 500 or an address used in a digital wallet hosted by a predetermined wallet service. For example, the indexer 504 can allow the platform service 506 to facilitate off-chain blockchain operations between users by modifying entries in its off-chain ledger.

[0071] Figure 6 A flowchart illustrating steps involved in mitigating network congestion is shown in accordance with one or more embodiments. For example, a system can use the process 600 (e.g., as implemented on one or more of the system components described above) in order to mitigate network congestion on a blockchain network by supporting blockchain operations via off-chain interactions. For example, the system can be used to conduct a payment between a point-of-sale terminal or other electronic payment system involving a merchant and a user, where the payment is made in cryptocurrency and / or has some other blockchain dependency. In turn, the system can generate an off-chain response. For example, the off-chain response can be a payment (e.g., in fiat currency). Additionally or alternatively, the off-chain response can include an electronic payment (or e-payment). The electronic payment can include any non-cash payment (e.g., credit card, debit card, and / or use of the ACH (Automated Clearing House) network) that does not involve a paper check.

[0072] At step 602, the process 600 (e.g., using one or more of the components described above) receives a communication. For example, the system can receive a communication to initiate an off-chain response corresponding to a blockchain operation on a blockchain network, where the off-chain response corresponds to a first user. For example, the system can receive a communication from a merchant (e.g., the first user) requesting authorization for a transaction involving cryptocurrency. The merchant can be a self-managed merchant (e.g., having an account that is not managed by a platform service) or a managed managed merchant (e.g., having an account that is managed by a platform service).

[0073] The communication can be received and / or generated in a variety of ways. For example, the system can receive, in a user interface, a first user input from a first user, where the first user input corresponds to accessing a web page of a second user. The system can receive, in the user interface, a second user input from the first user, where the second user input corresponds to a selection of an icon in the web page, and where the icon corresponds to generating the communication. For example, the user can select a “use encrypted payment” option that exists on a hosted web page and / or checkout screen. This option can open an iframe for the user to log in to a platform service and authenticate in order to use their digital asset funds to pay for a product at checkout (e.g., as described in Figure 1

[0074] Additionally or alternatively, the system can receive, in a user interface, a first user input from a first user, where the first user input corresponds to a web application for a platform service. Then, the system can generate a machine-readable optical label that indicates a first address, a second address, and an off-chain characteristic. For example, the user can select a “use encrypted payment” option that exists on a hosted web page and / or checkout screen. Then, this option can generate a QR code for conducting a blockchain operation. For example, the second user can include a merchant that scans the QR code displayed on the first user’s mobile device. The QR code can include information about an off-chain response (e.g., an electronic payment), such as the entities involved, the price of the good or service in question, and the like. The QR code can include several off-chain characteristics. For example, the off-chain characteristics can include any characteristic that can distinguish one off-chain response from another. In some embodiments, the off-chain response can include an electronic payment. In this case, the off-chain characteristics can include the amount of the electronic payment.

[0075] In some embodiments, the system can determine the first address based on a user account. For example, the system can determine a user account that corresponds to the first user. Then, the system can retrieve a first cryptography-based storage application based on the user account. For example, the system can receive user identifier information (e.g., a user account number) and other transaction details (e.g., an identity of an off-chain entity, an account corresponding to the off-chain entity, a time period, a good or service related to the transaction, a price related to the transaction, and / or other information related to the transaction).

[0076] ​In some embodiments, the communication can be encrypted. The system can perform decryption of the communication by retrieving a portion of an encryption key pair and verifying the communication based on the portion. For example, in response to receiving the communication from the user, the system can verify the authenticity of the communication. In some embodiments, the system can need to decrypt and / or otherwise process encryption on the communication (e.g., off-chain entities can use encryption to make it difficult for intruders to intercept confidential information). In some embodiments, the system can use Secure Sockets Layer (“SSL”) technology to encrypt data. The system can then utilize software that verifies the user’s electronic payment information (e.g., which is received at a secure server). In this case, the system can retrieve an SSL certificate (also known as a TLS or SSL / TLS certificate), which is a digital document that binds the identity of a website to a cryptographic key pair consisting of a public and private key. The public key included in the certificate allows a merchant to initiate an encrypted communication session with the platform service via the TLS and HTTPS protocols. For example, the private key can remain secure on the merchant’s server and is used to digitally sign communications.

[0077] At step 604, process 600 (e.g., using one or more components described above) determines a first address for conducting a blockchain operation. For example, the system can determine, based on the communication, a first address of a first cryptography-based storage application for conducting a blockchain operation, where the first cryptography-based storage application corresponds to the first user, and where the first cryptography-based storage application is managed by the platform service. For example, the first address can correspond to a custodial or non-custodial cryptography-based storage application assigned by a blockchain. The wallet can correspond to a private key and / or public key that allows for performing a blockchain operation using funds and / or information in the wallet.

[0078] For example, the first cryptography-based storage application can be a non-custodial cryptography-based storage application. That is, the first cryptography-based storage application can be a separate standalone application that allows a user to store their own passwords or maintain custody of their own passwords and explore the decentralized web with a decentralized application browser. The first cryptography-based storage application can be a standalone application that does not require interaction with a user account (e.g., an account from a blockchain service provider, a centralized brokerage firm, and / or an exchange). The first cryptography-based storage application can allow a user to manage their own private keys and store their cryptographic assets directly (without going through a centralized brokerage firm or exchange) on their device.

[0079] Alternatively, the first cryptography-based storage application can be a custodial or semi-custodial cryptography-based storage application. That is, the first cryptography-based storage application can be a separate standalone application that allows users to store their own passwords or maintain custody of their own passwords and explore the decentralized web with a decentralized application browser through an application provided by the blockchain service provider, the centralized brokerage firm, and / or the exchange. The first cryptography-based storage application can be an application that requires interaction with a user account from the blockchain service provider, the centralized brokerage firm, and / or the exchange. The first cryptography-based storage application can allow users to have their private keys managed by the blockchain service provider, the centralized brokerage firm, and / or the exchange without storing their own private keys (at least in full) and cryptographic assets directly on their devices.

[0080] At step 606, the process 600 (e.g., using one or more components described above) determines a second address for conducting a blockchain operation. For example, the system can determine, based on the communication, a second address of a second cryptography-based storage application for conducting a blockchain operation, where the second cryptography-based storage application corresponds to a second user. For example, the second cryptography-based storage application can be a custodial or semi-custodial cryptography-based storage application. That is, the second cryptography-based storage application can be a separate standalone application that allows users to store their own passwords or maintain custody of their own passwords and explore the decentralized web with a decentralized application browser through an application provided by the blockchain service provider, the centralized brokerage firm, and / or the exchange. The second cryptography-based storage application can be an application that requires interaction with a user account from the blockchain service provider, the centralized brokerage firm, and / or the exchange. The second cryptography-based storage application can allow users (e.g., merchants) to have their private keys managed by the blockchain service provider, the centralized brokerage firm, and / or the exchange without storing their own private keys (at least in full) and cryptographic assets directly on their devices (or to their accounts).

[0081] At step 608, the process 600 (e.g., using one or more components described above) determines, based on the first address and the second address, whether there is a common platform service. For example, the system can determine whether the second cryptography-based storage application is managed by a platform service.

[0082] In some embodiments, the system can compare the properties of the addresses to known addresses of the platform service. For example, the system can retrieve the second address from the communication. Then, the system can compare the second address to a list of addresses of cryptography-based storage applications managed by the platform service.

[0083] At step 610, process 600 (e.g., using one or more components described above) determines a type of off-chain response based on the common platform service. For example, in response to determining that the second cryptography-based storage application is managed by the platform service, the system can modify the off-chain ledger of the platform service to reflect the blockchain operation without performing a synchronous on-chain event over the blockchain network between the first cryptography-based storage application and the second cryptography-based storage application.

[0084] The system can determine the type of off-chain response based on whether the second digital wallet is managed by the common platform service. For example, if the second digital wallet is managed by the common platform service, the platform service can provide additional options and features for the off-chain response. These options and features can include types of assets transferred (e.g., fiat assets, digital assets, and / or specific payment formats), information provided (e.g., party identifiers, contract information, transaction details), etc. For example, the type of off-chain response can be based on any characteristic that distinguishes one off-chain response from another. The system can use these characteristics to determine a processing workflow for generating the off-chain response.

[0085] In some embodiments, the system can determine the type of off-chain response based on determining that the second cryptography-based storage application is managed by the platform service. In response to determining the type, the system can modify the off-chain ledger of the platform service to reflect the blockchain operation without performing a synchronous on-chain event over the blockchain network between the first cryptography-based storage application and the second cryptography-based storage application.

[0086] For example, if the system determines that both the first cryptography-based storage application and the second cryptography-based storage application are managed by the platform service, the system can process the blockchain operation in an off-chain manner to avoid excessive network fees and processing costs.

[0087] Alternatively, in response to determining that the second cryptography-based storage application is not managed by the platform service, the system can use a third cryptography-based storage application to perform the blockchain operation on the blockchain network, where the third cryptography-based storage application includes a consolidated account of the platform service.

[0088] For example, the third cryptography-based storage application can be a custodial or semi-custodial cryptography-based storage application associated with the platform service. In some embodiments, the third cryptography-based storage application can include a consolidated account. The consolidated account can include a pass-through funding account created for incoming payments to collect custody fees.

[0089] At step 612, process 600 (e.g., using one or more components described above) transmits an off-chain response. For example, the system can transmit the off-chain response from the platform service to the second user. For example, after completing the blockchain operation, the platform service can transmit an amount (e.g., a portion of the amount corresponding to the electronic payment) to the merchant.

[0090] In some embodiments, the off-chain response (or a characteristic of the off-chain response) can be influenced by network conditions, current exchange rates, platform fees, and the like. For example, the system can determine a processing metric, where the processing metric is used to account for changes in processing characteristics that occur during the blockchain operation. For example, the system can determine a hedging spread that can absorb exchange rate fluctuations based on a conversion of a digital asset involved in the blockchain operation to a fiat currency used for the off-chain response. The system can then determine a first blockchain operation characteristic based on user input. For example, the blockchain operation characteristic can include any characteristic that can distinguish one blockchain operation from another. In some embodiments, the off-chain response can include an electronic payment. In this case, the blockchain operation characteristic can include an amount of cryptocurrency corresponding to an amount of the electronic payment (e.g., based on the exchange rate). The system can then determine a second blockchain operation characteristic based on a sum of the processing metric and the first blockchain operation characteristic. The second blockchain characteristic can be a total amount of the electronic payment (e.g., converted to cryptocurrency) and the hedging spread.

[0091] In some embodiments, the system can perform the blockchain operation using a digital key signing ceremony. For example, the system can retrieve a first portion of a private key from a secure user account. The system can query a first user device to perform the blockchain operation using a second portion of the private key. The system can generate a first digital signature based on the first portion of the private key and the second portion of the private key, and perform the blockchain operation based on the digital signature. For example, in some embodiments, the system can use a multi-computation signature system that includes multiple private keys.

[0092] For example, the system can use a multi-party computation (“MPC”) system. MPC involves the use of multiple parties, each holding respective private data that can be used to evaluate a computation without ever exposing any of the private data held by each party. For example, each party in the multi-party can have private data (e.g., d1, d2, …, d N ). The parties can together use their respective private data to compute a value of a public function: (e.g., F ((d1, d2, …, d N ). The private data remains private in this process when it is used to compute a value based on the function.

[0093] The use of MPC-based keys reduces the risk involved with private key loss and / or private key access by unauthorized parties. For example, traditional key sharing systems rely on a public-private key configuration, where the security of the system is tied to the private key remaining private. In some cases, these keys are stored in various cryptography-based digital repositories (or digital wallets). These digital wallets can have a variety of configurations, often categorized based on whether the private key is held online or offline. For example, hot storage wallets have private keys held online. Cold storage wallets have private keys held offline, and hardware wallets have private keys held offline and on a physical device (e.g., a thumb drive). While holding private keys offline and / or binding private keys to a physical device is beneficial from a security perspective, it creates practical problems when trying to operate using the digital wallet. For example, to operate, a user must be able to access the private key from its offline location and / or physical device. This is particularly burdensome for MPC-based key operations, as it requires each user (e.g., corresponding to a respective private key) to be available at a given time.

[0094] Furthermore, the use of private keys stored at offline locations and / or physical devices increases the risk of the offline location becoming inaccessible and / or the physical device being lost. In this case, the digital wallet and any digital assets therein can also be lost. This creates a key deficiency in MPC-based key operations, as the loss of any one key can result in the loss of digital assets for all parties. The methods and systems described herein overcome this problem by using threshold signature requirements, separate approvals and signing strategies, independent key recovery mechanisms, and group / group key creation. More specifically, the methods and systems described herein mitigate the deficiency in MPC-based key operations by creating MPC-based key operations where the MPC relies on partial private keys. In this case, one partial private key remains online (e.g., in a hot wallet), while the other partial private keys can remain offline. Furthermore, due to the use of partial private keys, the exposure of the online partial private key does not itself create a security risk (e.g., because multiple partial private keys, including offline partial keys, are required to conduct blockchain operations), and the loss of an offline partial private key (e.g., stored on a user device) does not create a risk of digital asset loss (e.g., because the online partial private key can be used to recover the offline partial private key).

[0095] MPC-based key operations preserve the flexibility in the algorithms used. For example, the system can use online MPC algorithms, such as the Gennaro and Goldfeder MPC algorithm and the Lindell et al. MPC algorithm. Online MPC algorithms have two limitations that constrain their use in traditional systems. First, they require users to wait for a blockchain operation to go through up to eight to twelve rounds of signing, which can create latency issues. Second, they require the use of online storage for private keys. Because of the use of partial private keys (e.g., including online and offline pairs), the system can use online MPC algorithms. Moreover, assuming that the online partial private keys satisfy the online requirements of the online MPC algorithms, the system can use online MPC algorithms while keeping offline partial private keys (e.g., increasing overall security).

[0096] Additionally, the MPC-based key operations used by the system can include offline and / or online hybrid MPC algorithms. For example, the system can use MPC algorithms that include dynamic key refreshes (e.g., private key shares can be dynamically updated / modified at given intervals) and / or dynamic approval and / or signing policies. The online partial private keys make these dynamic policies possible. Thus, the system introduces enhanced security for dynamic systems while still maintaining the security of offline systems (e.g., through the use of offline partial private keys).

[0097] Finally, the MPC-based key operations can use threshold key signing policies, where only a threshold number of users (e.g., corresponding to partial private keys of users) are needed. Upon the system determining that the threshold is met, the system can allow subsequent users (e.g., online users) to complete and perform the blockchain operation. Thus, the system allows for the use of MPC-based key operations without requiring all parties to be online and / or available at the same time.

[0098] In some embodiments, querying the first user device to use the second partial private key can include the system establishing a key signing session between the first user device and the first remote device, where during the key signing session, a random nonce value is generated based on the first partial private key and the second partial private key, and where the random nonce value is not shared with the first user device or the first remote device. For example, the key signing session can involve the setup of one or more parameters and a hash function. The system can also select a nonce. A nonce can be an arbitrary value that can be used once in a cryptographic communication. The system can determine the nonce as a random or pseudo-random value. The nonce value can be selected by the system based on an authentication protocol to ensure that previous blockchain operations (and / or communications containing them) cannot be reused. The system can also use the nonce value to initialize a vector of the hash function. For example, the system can select a nonce value to adjust a difficulty level (e.g., an amount of work required) in a proof-of-work system.

[0099] In some embodiments, the system can select a signature scheme based on characteristics of the user device. For example, the system can determine characteristics of the first user device and select a signature scheme for the first digital signature based on the characteristics. In some embodiments, the system can select a signature scheme based on processing power and / or geographic location of the first user device. For example, some devices can experience issues with low processing power and / or low connectivity. As such, the system can determine characteristics of the user device and select a signature scheme based on the characteristics. For example, the system can select a Flexible Round Optimized Schnorr Threshold Signature (FROST) protocol, which can use a two-round Distributed Key Generation (DKG) protocol to generate random numbers required for the signature.

[0100] It is contemplated that, Figure 6 the steps or descriptions can be used with any other embodiment of the present disclosure. Additionally, with respect to Figure 6 the steps and descriptions described can be performed in alternative orders or in parallel to facilitate the purposes of the present disclosure. For example, each of these steps can be performed in any order or in parallel or simultaneously to reduce latency or increase speed of the system or method. Furthermore, it should be noted that any component, device, or equipment discussed above with respect to the figures can be used to perform one or more steps in Figure 6 the above-described embodiments.

[0101] The above-described embodiments of the present disclosure are presented for purposes of illustration and not of limitation, and the present disclosure is limited only by the claims which follow. Additionally, it should be noted that features described in any one embodiment can be applied to any other embodiment, and flowcharts or examples relating to one embodiment can be combined in a suitable manner with any other embodiment, completed in a different order, or completed in parallel, as appropriate. Furthermore, the systems and methods described herein can be performed in real-time. It should also be noted that the above-described systems and / or methods can be applied to or used in accordance with other systems and / or methods.

[0102] The present technology will be better understood with reference to the following enumerated embodiments:

[0103] 1. A method comprising: receiving a communication that initiates an off-chain response corresponding to a blockchain operation on a blockchain network, wherein the off-chain response corresponds to a first user; determining, based on the communication, a first address of a first cryptography-based storage application for conducting the blockchain operation, wherein the first cryptography-based storage application corresponds to the first user, and wherein the first cryptography-based storage application is managed by a platform service; determining, based on the communication, a second address of a second cryptography-based storage application for conducting the blockchain operation, wherein the second cryptography-based storage application corresponds to a second user; determining whether the second cryptography-based storage application is managed by the platform service; in response to determining that the second cryptography-based storage application is managed by the platform service, modifying an off-chain ledger of the platform service to reflect the blockchain operation without performing a synchronous on-chain event between the first cryptography-based storage application and the second cryptography-based storage application over the blockchain network; and transmitting the off-chain response from the platform service to the second user.

[0104] 2. The method of any of the preceding embodiments, wherein the method is used to mitigate network congestion on a blockchain network by supporting blockchain operations conducted via off-chain interactions between cryptography-based storage applications that share a common platform.

[0105] 3. The method of any of the preceding embodiments, wherein receiving the communication is based on: receiving, in a user interface, a first user input from the first user, wherein the first user input corresponds to accessing a web page of the second user; and receiving, in the user interface, a second user input from the first user, wherein the second user input corresponds to a selection of an icon in the web page, and wherein the icon corresponds to generating the communication.

[0106] 4. The method of any of the preceding embodiments, wherein receiving the communication is based on: receiving, in a user interface, a first user input from the first user, wherein the first user input corresponds to a web application for the platform service; generating a machine-readable optical label that indicates the first address, the second address, and off-chain characteristics.

[0107] 5. The method of any of the preceding embodiments, further comprising: in response to determining that the second cryptography-based storage application is not managed by the platform service, using a third cryptography-based storage application to perform the blockchain operation on the blockchain network, wherein the third cryptography-based storage application comprises a consolidated account of the platform service.

[0108] 6. The method of any of the preceding embodiments, further comprising: determining a processing metric, wherein the processing metric is used to account for a change in processing characteristics that occurs during the blockchain operation; determining a first blockchain operation characteristic based on a user input; and determining a second blockchain operation characteristic based on a sum of the processing metric and the first blockchain operation characteristic.

[0109] 7. The method of any of the preceding embodiments, wherein determining the first address based on the communication further comprises determining a user account corresponding to the first user, and retrieving the first cryptography-based storage application based on the user account.

[0110] 8. The method of any of the preceding embodiments, further comprising retrieving a portion of an encryption key pair, and verifying the communication based on the portion.

[0111] 9. The method of any of the preceding embodiments, further comprising retrieving a first portion of a private key from a first user device corresponding to the first user, querying a second user device to perform a blockchain operation using a second portion of the private key, and generating the first digital signature based on the first portion of the private key and the second portion of the private key.

[0112] 10. The method of any of the preceding embodiments, wherein querying the second user device to use the second portion of the private key comprises establishing a key signing session between the first user device and the second user device, wherein during the key signing session, a random nonce value is generated based on the first portion of the private key and the second portion of the private key, and wherein the random nonce value is not shared with the first user device or the second user device.

[0113] 11. The method of any of the preceding embodiments, further comprising determining a characteristic of the first user device, and selecting a signing scheme for the first digital signature based on the characteristic.

[0114] 12. The method of any of the preceding embodiments, wherein determining whether the second cryptography-based storage application is managed by the platform service comprises retrieving a second address from the communication, and comparing the second address to a list of addresses of cryptography-based storage applications managed by the platform service.

[0115] 13. A tangible, non-transitory machine-readable medium storing instructions that, when executed by a data processing apparatus, cause the data processing apparatus to perform operations comprising those of any of embodiments 1-12.

[0116] 14. A system comprising: one or more processors; and memory storing instructions that, when executed by the processors, cause the processors to perform operations comprising those of any of embodiments 1-12.

[0117] 15. A system comprising means for performing any of embodiments 1-12.

Claims

1. A system for mitigating network congestion on a blockchain network by supporting off-chain interactions for blockchain operations conducted via cryptography-based storage applications that share a common platform, the system comprising: one or more processors; and one or more non-transitory media comprising instructions recorded thereon that, when executed by the one or more processors, cause performance of operations comprising: receiving an encrypted communication that initiates an off-chain response corresponding to a blockchain operation on a blockchain network, wherein the off-chain response corresponds to a first user; determining, based on the encrypted communication, a secure user account hosted by a platform service that corresponds to the first user; determining, based on the secure user account, a first address of a first cryptography-based storage application for conducting the blockchain operation, wherein the first cryptography-based storage application corresponds to the first user, and wherein the first cryptography-based storage application is managed by the platform service; determining, based on the encrypted communication, a second address of a second cryptography-based storage application for conducting the blockchain operation, wherein the second cryptography-based storage application corresponds to a second user; determining whether the second cryptography-based storage application is managed by the platform service; determining a type of the off-chain response based on determining that the second cryptography-based storage application is managed by the platform service; in response to determining the type, modifying an off-chain ledger of the platform service to reflect the blockchain operation without requiring a synchronous on-chain event to be performed between the first cryptography-based storage application and the second cryptography-based storage application via the blockchain network; and transmitting the off-chain response from the platform service to the second user.

2. A method for mitigating network congestion on a blockchain network by supporting off-chain interactions for blockchain operations conducted via cryptography-based storage applications that share a common platform, the method comprising: receiving a communication that initiates an off-chain response corresponding to a blockchain operation on a blockchain network, wherein the off-chain response corresponds to a first user; determining, based on the communication, a first address of a first cryptography-based storage application for conducting the blockchain operation, wherein the first cryptography-based storage application corresponds to the first user, and wherein the first cryptography-based storage application is managed by a platform service; determining, based on the communication, a second address of a second cryptography-based storage application for conducting the blockchain operation, wherein the second cryptography-based storage application corresponds to a second user; determining whether the second cryptography-based storage application is managed by the platform service; in response to determining that the second cryptography-based storage application is managed by the platform service, modifying an off-chain ledger of the platform service to reflect the blockchain operation without requiring a synchronous on-chain event to be performed between the first cryptography-based storage application and the second cryptography-based storage application via the blockchain network; and transmitting the off-chain response from the platform service to the second user. ​ ​ ​ 3. The method of claim 2, wherein, receiving the communication is based on: receiving, in a user interface, a first user input from the first user, wherein the first user input corresponds to accessing a web page of the second user; and receiving, in the user interface, a second user input from the first user, wherein the second user input corresponds to a selection of an icon in the web page, and wherein the icon corresponds to generating the communication.

4. The method of claim 2, wherein, receiving the communication is based on: receiving, in a user interface, a first user input from the first user, wherein the first user input corresponds to a web application for the platform service; and generating a machine-readable optical label that indicates the first address, the second address, and an off-chain characteristic.

5. The method of claim 2, further comprising: in response to determining that the second cryptography-based storage application is not managed by the platform service, performing the blockchain operation on the blockchain network using a third cryptography-based storage application, wherein the third cryptography-based storage application comprises a consolidated account for the platform service.

6. The method of claim 2, further comprising: determining a processing metric, wherein the processing metric is used to account for changes in processing characteristics that occur during a blockchain operation; determining a first blockchain operation characteristic based on a user input; and determining a second blockchain operation characteristic based on a sum of the processing metric and the first blockchain operation characteristic.

7. The method of claim 2, wherein, determining the first address based on the communication further comprises: determining a user account corresponding to the first user; and retrieving the first cryptography-based storage application based on the user account.

8. The method of claim 2, further comprising: retrieving a portion of an encryption key pair; and verifying the communication based on the portion.

9. The method of claim 2, further comprising: retrieving a first partial private key from a first user device corresponding to the first user; querying a second user device to perform the blockchain operation using a second partial private key; and generating a first digital signature based on the first partial private key and the second partial private key. querying the second user device to perform the blockchain operation using the second partial private key comprises establishing a key signing session between the first user device and the second user device, wherein during the key signing session, a random nonce is generated based on the first partial private key and the second partial private key, and wherein the random nonce is not shared with the first user device or the second user device.

10. The method of claim 9, wherein, 11. The method of claim 9, further comprising: determining a characteristic of the first user device; and selecting a signing scheme for the first digital signature based on the characteristic. determining whether the second cryptography-based storage application is managed by the platform service comprises: retrieving the second address from the communication; and 12. The method of claim 2, wherein, comparing the second address to a list of addresses of cryptography-based storage applications managed by the platform service.

13. A non-transitory computer-readable medium comprising instructions recorded thereon that, when executed by one or more processors, cause operations comprising: ​ ​ receiving a communication that initiates an off-chain response corresponding to a blockchain operation on a blockchain network, wherein the off-chain response corresponds to a first user; determining, based on the communication, a first address of a first cryptography-based storage application to conduct the blockchain operation, wherein the first cryptography-based storage application corresponds to the first user, and wherein the first cryptography-based storage application is managed by a platform service; determining, based on the communication, a second address of a second cryptography-based storage application to conduct the blockchain operation, wherein the second cryptography-based storage application corresponds to a second user; determining whether the second cryptography-based storage application is managed by the platform service; in response to determining that the second cryptography-based storage application is managed by the platform service, modifying an off-chain ledger of the platform service to reflect the blockchain operation without performing a synchronous on-chain event between the first cryptography-based storage application and the second cryptography-based storage application over the blockchain network; and transmitting, from the platform service to the second user, the off-chain response.

14. The non-transitory computer-readable medium of claim 13, wherein, receiving the communication is based on: receiving, from the first user in a user interface, a first user input, wherein the first user input corresponds to accessing a web page of the second user; and receiving, from the first user in the user interface, a second user input, wherein the second user input corresponds to a selection of an icon in the web page, and wherein the icon corresponds to generating the communication.

15. The non-transitory computer-readable medium of claim 13, wherein, receiving the communication is based on: receiving, from the first user in a user interface, a first user input, wherein the first user input corresponds to a web application for the platform service; and generating a machine-readable optical label that indicates the first address, the second address, and an off-chain characteristic.

16. The non-transitory computer-readable medium of claim 13, further comprising: in response to determining that the second cryptography-based storage application is not managed by the platform service, executing the blockchain operation on the blockchain network using a third cryptography-based storage application, wherein the third cryptography-based storage application comprises a consolidated account for the platform service.

17. The non-transitory computer-readable medium of claim 13, further comprising: determining a processing metric, wherein the processing metric is used to account for a change in a processing characteristic that occurs during a blockchain operation; determining a first blockchain operation characteristic based on a user input; and determining a second blockchain operation characteristic based on a sum of the processing metric and the first blockchain operation characteristic.

18. The non-transitory computer-readable medium of claim 13, wherein, determining, based on the communication, the first address further comprises: determining a user account corresponding to the first user; and retrieving the first cryptography-based storage application based on the user account.

19. The non-transitory computer-readable medium of claim 13, further comprising: retrieving a portion of an encryption key pair; and verifying the communication based on the portion.

20. The non-transitory computer-readable medium of claim 13, further comprising: determining that the second cryptography-based storage application is managed by the platform service; and determining a type of the off-chain response based on determining that the second cryptography-based storage application is managed by the platform service.

Images