System and method for block chain interoperation platform

Abstract

The methods and systems described herein relate to an improved platform that provides support for the deposit and / or withdrawal of multi-network assets between two levels of a blockchain network. More specifically, the methods and systems provide such an improved platform by introducing additional flowability pools that allow transfer without having to bridge between two levels.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of priority of U.S. Patent Application No. 18 / 055,860, filed on November 16, 2022. The content of the foregoing application is incorporated herein by reference in its entirety.

[0003] Background

[0004] In recent years, the use of blockchain and blockchain technology has grown exponentially. A blockchain consists of a list of records called "blocks" that are "linked" together using cryptography. Each block can include data calculated using a one - way function of the previous block (e.g., a function that is practically impossible to reverse or back - calculate), a timestamp (e.g., indicating the creation and / or modification time), 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 their use for cryptocurrencies and smart contracts, blockchain and blockchain technology may be applicable to many technical avenues. A common theme among the technical avenues is the way blockchain and blockchain technology are decentralized, such that the facilitation, management, and / or verification of blockchain - based operations are governed or managed not by any one institution but by a community of users. Thus, a blockchain can remain distributed (e.g., on a computer network that communicates and coordinates its actions by passing messages to each other) and, in many cases, public, through a digital ledger that records a series of blocks forming a chain. Notably, because each block depends on the previous block, it may not be possible to edit an existing block in the chain without affecting subsequent blocks.

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

[0007] Summary

[0008] Novel uses and / or improved systems and methods for blockchain and blockchain technology are described herein. As an example, methods and systems for allowing a system to access multi - network assets otherwise known as the first and second layers of a blockchain are described.

[0009] Conventional systems are also unable to implement a platform where swaps can occur seamlessly from the first and second layers of blockchain technology. For example, due to the time requirements of the corresponding consensus mechanism for each bridge, traditional systems require users to wait up to five hours or more to move from one network to another. Additionally, conventional systems require users to use different wallets and perform multiple transactions / swaps, while current bridging platforms must use multiple bridges and pay gas fees at each stop.

[0010] To overcome these technical deficiencies in conventional systems, the systems and methods disclosed herein utilize a platform load balancer, where one side has a processing load and the other side has an available processing load. For example, conventional systems would have no choice but to utilize bridging to access the gap between the first and second layers of multi-network assets. There is no platform load balancer with an available liquidity pool. Thus, the systems and methods disclosed herein will allow users to immediately know whether funds are available for transfer and whether a bridge is available, thereby allowing transfers to occur more quickly.

[0011] In some aspects, systems and methods for managing blockchain processing loads for blockchain operations conducted across multiple blockchain networks are described. For example, a system can receive a first blockchain operation at a platform load balancer, the first blockchain operation involving a first processing request from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network. The system can determine a processing load for the first blockchain operation at the platform load balancer. The system can determine an available processing load at a first supplementary address for the second blockchain network at the platform load balancer. The system can compare the processing load with the available processing load. The system can generate a second blockchain operation from the first supplementary address to the second blockchain address, where the second blockchain operation has a processing load, in response to determining that the processing load is within the available processing load.

[0012] Various other aspects, features, and advantages of the present invention will be apparent from the detailed description and the drawings of the present invention. It should also be understood that the foregoing general description and the following detailed description are both exemplary and do not limit the scope of the present invention. As used in this specification and the claims, unless the context clearly dictates otherwise, the singular forms "a", "an", and "the" include plural referents. Additionally, as used in this specification and the claims, unless the context clearly dictates otherwise, the term "or" means "and / or". Further, as used in this specification, unless the context clearly dictates otherwise, "a portion" refers to a part or all (i.e., the entire part) of a given item (e.g., data). Brief Description of the Drawings

[0014] Figure 1 A schematic diagram is shown for managing blockchain processing loads for blockchain operations across multiple blockchain networks using a platform load balancer according to one or more embodiments.

[0015] Figure 2 A schematic diagram is shown for performing blockchain operations according to one or more embodiments.

[0016] Figure 3 A schematic diagram is shown for a decentralized application according to one or more embodiments.

[0017] Figure 4 A schematic diagram is shown for operating in a decentralized application using blockchain operations according to one or more embodiments.

[0018] Figure 5 A schematic diagram is shown for a blockchain indexer according to one or more embodiments.

[0019] Figure 6 A flowchart is shown for steps of generating a priority queue according to one or more embodiments.

[0020] Figure 7 A flowchart is shown for steps involved in receiving a first blockchain operation involving a first processing request according to one or more embodiments.

[0021] Detailed Description of the Drawings

[0022] In the following description, for purposes of explanation, numerous specific details are set forth to provide a thorough understanding of embodiments of the present invention. However, those skilled in the art will understand that embodiments of the present invention may be practiced without these specific details or with equivalent arrangements. In other instances, well-known structures and devices are shown in block diagram form to avoid unnecessarily obscuring embodiments of the present invention.

[0023] Figure 1 A schematic diagram is shown for managing blockchain processing loads for blockchain operations across multiple blockchain networks using a platform load balancer according to one or more embodiments. For example, the system can be instructed to allow users to easily access multi-network assets. For example, Figure 1 The utilization of a platform load balancer is shown, where one side has a processing load and the other side has available processing load. For example, a conventional system would have no choice but to use a bridge to access the gap between the first and second layers of multi-network assets. There is no platform load balancer with an available liquidity pool. Thus, the system will allow users to immediately know whether funds are available for transfer and whether the bridge is available, thereby allowing for faster transfers.

[0024] The system can use a platform load balancer. As mentioned herein, a "platform load balancer" can include software, hardware, and coordinators for hosting an application or service that uses a set of tools and instructions for a particular processor. In some embodiments, the platform load balancer can include software containing a set of tools to help maintain a certain amount of available processing load to balance both sides of the platform. In some embodiments, the platform load balancer can include software that invokes a cross-chain bridge.

[0025] The system can use a processing request. As described herein, a "processing request" can include instances such as an application programming interface (API) supplying a request structure to store an incoming request, and then the application processes the request and sends a response. In some embodiments, the processing request can include a quantity related to a blockchain operation or transaction. In some embodiments, the processing request can include the size of a blockchain operation.

[0026] The system can use available processing load. As described herein, "available processing load" can include the amount of available cryptocurrency within a liquidity pool. In some embodiments, the available processing load can include a liquidity pool within a hot wallet. In some embodiments, the available processing load can include a processing load compared to the platform balancer due to a processing request.

[0027] The system can use a supplementary address. As described herein, a "supplementary address" can include the address of a blockchain network where a blockchain operation occurs. In some embodiments, the supplementary address can include a liquidity pool that maintains a certain amount of liquidity for each supported asset on two networks. In some embodiments, the supplementary address can include an address where funds or digital wallets are found.

[0028] The system can use a platform load balancer. As described herein, a "platform load balancer" can include a liquidity balancer that directs the movement of available processing load between blockchain networks. In some embodiments, if the system determines that the available processing load at the supplementary address is greater than the processing load at the first blockchain address, the platform load balancer can generate a blockchain operation from the supplementary address to the first blockchain network, where the available processing load is transferred. In some embodiments, if the system determines that the available processing load at the supplementary address is less than the processing load at the first blockchain address, the platform load balancer can generate a blockchain operation from the first blockchain network to the supplementary address, where the processing load is transferred.

[0029] The system can use credit pausing. As mentioned herein, "credit pausing" can include the system pausing the transfer of funds credited to users if the liquidity pool becomes too deep until sufficient funds can be bridged to the cryptocurrency. In some embodiments, if the system receives multiple processing requests for a blockchain network, the system can determine not to generate blockchain operations from the replenishment address and return the processing load to the blockchain network. The system can determine to generate blockchain operations at a later time. By doing so, the system can protect the exchange rate of the second blockchain network.

[0030] For example, Figure 1 Platform 100 is shown. Platform 100 includes digital wallets 102, 104, and 110, and a physical device 106, which can correspond to the liquidity pool. As described herein, the liquidity pool can refer to the available processing load.

[0031] Platform 100 can receive a first blockchain operation at platform load balancer 108. The first blockchain operation involves a first processing request from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network. Platform load balancer 108 determines the processing load for the first blockchain operation from digital wallet 104. Platform load balancer 108 determines the available processing load at the first replenishment address for digital wallet 110. Platform load balancer 108 compares the processing load at digital wallet 104 with the available processing load at digital wallet 110. In response to determining that the processing load at digital wallet 104 is within the available processing load at digital wallet 110, platform load balancer 108 generates a second blockchain operation from the first replenishment address to the second blockchain address, where the second blockchain operation has a processing load.

[0032] In response to determining that the processing load is not within the available processing load, platform load balancer 108 generates a cross-chain bridge call. Cross-chain bridge 112 requests a wrapped token issued by the cross-chain bridge provider platform corresponding to the processing load and receives the wrapped token.

[0033] In response to determining that the processing load at digital wallet 104 is not within the available processing load at digital wallet 110, platform load balancer 108 generates a second blockchain operation from the first replenishment address to the second blockchain address, which further includes generating a fourth blockchain operation from a third replenishment address at digital wallet 102 to a fourth replenishment address, where both the third replenishment address and the fourth replenishment address correspond to platform load balancer 108, and where the fourth replenishment address is a repository at physical device 106.

[0034] Figure 2Shows a schematic diagram for performing blockchain operations according to one or more embodiments. For example, the figure presents various components of a blockchain processing load that can be used in some embodiments to manage blockchain operations across multiple blockchain networks using a platform load balancer.

[0035] Figure 2 Includes user device 202. The user device 202 may include a user interface. As mentioned herein, a "user interface" may include mechanisms for human-computer interaction and communication in a device, and may include a display screen, a keyboard, a mouse, and a desktop appearance. For example, the user interface may include the way a user interacts with an application or a website to manage the blockchain processing load of blockchain operations across multiple blockchain networks using a platform load balancer, and the user interface may display content related to managing the blockchain processing load of blockchain operations across multiple blockchain networks using a platform load balancer. As mentioned herein, "content" should be understood to mean a representation of electronic consumable user assets, goods, or services (including non-fungible tokens), Internet content (e.g., streaming content, downloadable content, webcasts, etc.), video data, audio data, image data, and / or text data, etc.

[0036] As Figure 2 shown, the system 200 may include multiple user devices (e.g., user device 202, user device 208, and / or user device 210). For example, the system 200 may include a distributed state machine, where Figure 2 each component therein acts as a client of the system 200. For example, the system 200 (and other systems described herein) may include a large data structure that not only stores all accounts and balances but also stores a state machine, which may change between blocks according to a predefined set of rules and may execute arbitrary machine code. The specific rules for changing the state between blocks may 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).

[0037] It should be noted that although in Figure 2are shown as a smart phone, a personal computer, and a server, but the user device can be any type of computing device, including but not limited to a laptop computer, a tablet computer, a handheld computer, and / or other computing devices (e.g., servers), including "smart", wireless, wearable, and / or mobile devices. It should be noted that the embodiments described for the system 200 performing blockchain operations can be equivalently applied to and correspond to individual user devices performing blockchain operations (e.g., user device 202, user device 208, and / or user device 210). That is, the system 200 can correspond to the user devices (e.g., user device 202, user device 208, and / or user device 210) uniformly or individually.

[0038] The system can use each user device to perform blockchain operations and / or help manage the blockchain processing load for blockchain operations across multiple blockchain networks using a platform load balancer. As mentioned herein, "blockchain operations" can include any operation that includes and / or involves blockchains and blockchain technology. For example, blockchain operations can include conducting transactions, querying a distributed ledger, generating additional blocks for a blockchain, transferring non-fungible tokens related to communications, performing encryption / decryption, exchanging public / private keys, and / or other operations involving blockchains 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., blockchain-specific digital assets), including non-fungible tokens. Non-fungible tokens can include tokens associated with goods, services, smart contracts, and / or other content that can be verified by and stored using blockchain technology.

[0039] In some embodiments, blockchain operations may also include actions related to mechanisms that facilitate other blockchain operations (e.g., actions related to the metering activity of blockchain operations on a given blockchain network). For example, Ethereum is an open-source, globally decentralized computing infrastructure that executes smart contracts and uses 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 called "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 terms of gas (e.g., as determined based on a predefined set of rules of the system). When a blockchain operation triggers the execution of a smart contract, the blockchain operation may include a certain amount of gas that sets an upper limit on the amount of gas that can be consumed when running the smart contract. If the amount of gas consumed by the computation exceeds the gas available in the blockchain operation, the system may terminate the execution of the smart contract. For example, in Ethereum, gas includes a mechanism that allows Turing-complete computation while limiting the resources that any smart contract and / or blockchain operation may consume.

[0040] In some embodiments, it may be possible to obtain gas as part of a blockchain operation (e.g., a purchase) using a network-specific cryptocurrency (e.g., ether in the case of Ethereum). The system may require gas (or the amount of network-specific cryptocurrency corresponding to the required amount of gas) to be transmitted together with the blockchain operation as an earmark of the blockchain operation. In some embodiments, if a certain amount remains unused after a computation has been performed, the gas that was the earmark of the blockchain operation may be refunded to the originator of the blockchain operation.

[0041] As Figure 2As shown, one or more user devices may include a cryptography-based storage application (e.g., digital wallet 204) for performing blockchain operations. The cryptography-based storage application may be used to perform multiple blockchain operations across a computer network. In some embodiments, the cryptography-based storage application may correspond to a digital wallet. For example, a digital wallet may include a repository that allows a user to store, manage, and trade their cryptocurrencies and assets, interact with a blockchain, and / or use one or more applications for blockchain operations. The digital wallet may be specific to a given blockchain protocol or may provide access to multiple blockchain protocols. In some embodiments, the system may 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. A digital wallet holder may hold both a hot wallet and a cold wallet. Hot wallets are most commonly used to perform blockchain operations, while cold wallets are typically used to manage user accounts and may not be connected to the Internet.

[0042] In some embodiments, the cryptography-based storage application may correspond to a key-based wallet or a smart contract wallet. For example, a key-based wallet may be characterized by a public key or a private key and may allow a user to control an account or receive transactions in an account. A smart contract wallet may include a blockchain program or digital contract that executes a transaction between parties once a predetermined condition is met. For example, a smart contract wallet may be managed by a smart contract (e.g., or smart contract code) rather than a private key. Thus, a smart contract wallet may improve speed, accuracy, trust, and / or transparency in blockchain operations. In some embodiments, the cryptography-based storage application may include or may have access to a key-based wallet or a smart contract wallet. For example, the cryptography-based storage application may include a digital construct or other construct (e.g., reference, pointer, text on a blockchain, address, etc.).

[0043] As Figure 2As shown, one or more user devices may include a private key (e.g., key 212) and / or a digital signature. For example, system 200 may use a cryptosystem for blockchain operations, such as managing the blockchain processing load for blockchain operations across multiple blockchain networks using a platform load balancer. For example, system 200 may use public-key cryptography, which is characterized by a pair of digital keys (e.g., which may include data strings). In this case, each pair includes a public key (e.g., which may be public) and a private key (e.g., which may remain private). System 200 may use a cryptographic algorithm (e.g., characterized by a one-way function) to generate the key pair. Then, system 200 may use the public key of the intended recipient to encrypt a message (or other blockchain operation) such that the encrypted message can be decrypted only using the corresponding private key of the recipient. In some embodiments, system 200 may combine a message with a private key to create a digital signature on the message. For example, the digital signature may be used to verify the authenticity of a blockchain operation. By way of illustration, when performing a blockchain operation, system 200 may use the digital signature to prove to each node in the system that system 200 is authorized to perform the blockchain operation.

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

[0045] For example, user device 208 may request a blockchain operation (e.g., conduct a transaction). The blockchain operation may be authenticated by user device 208 and / or another node (e.g., a user device in the community network of system 200). For example, using cryptographic keys, system 200 may identify users and grant access to their corresponding user accounts (e.g., corresponding digital wallets) within 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), system 200 may create a digital signature to authenticate the user.

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

[0047] To verify a blockchain operation, system 200 can use one or more verification protocols and / or verification mechanisms. For example, system 200 can use a proof-of-work mechanism, where a user device must provide evidence that the device has performed computational work to verify the blockchain operation, and thus this mechanism provides a way to achieve consensus in a decentralized manner and prevent fraudulent verification. For example, the proof-of-work mechanism can involve iterations of a hashing algorithm. The successful user device aggregates and records the blockchain operations from a storage pool (e.g., the collection of all valid blockchain operations waiting to be confirmed by the blockchain network) into the next block. Alternatively or additionally, system 200 can use a proof-of-stake mechanism, where a user account (e.g., corresponding to a node on the blockchain network) is required to have or "stake" a predetermined amount of tokens in order for system 200 to identify the user account as a validator in the blockchain network.

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

[0049] Figure 3A schematic diagram of a decentralized application according to one or more embodiments is shown. For example, in some embodiments, system 300 may utilize a platform load balancer within a decentralized application environment to manage the blockchain processing load of blockchain operations performed across multiple blockchain networks. A decentralized application may include applications that exist on a blockchain (e.g., blockchain 302) and / or a peer-to-peer network (e.g., network 306). That is, a decentralized application may include an application having a backend partially powered by a decentralized peer-to-peer network, such as a decentralized open-source blockchain with smart contract functionality.

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

[0051] In some embodiments, the user devices of system 300 may include one or more cloud components. For example, the cloud components may be implemented as a cloud computing system and may be characterized by one or more component devices. It should also be noted that system 300 is not limited to four devices. For example, a user may utilize one or more devices to interact with each other, with one or more servers, or with other components of system 300. It should be further noted that although one or more operations (e.g., blockchain operations) are described herein as being performed by a specific component of system 300 (e.g., user device 304), in some embodiments, those operations may be performed by other components of system 300. As an example, although one or more operations are described herein as being performed by components of user device 304, in some embodiments, those operations may be performed by one or more cloud components. In some embodiments, the various computers and systems described herein may include one or more computing devices programmed to perform the described functions. Additionally or alternatively, multiple users may 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 may 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) may 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).

[0052] Regarding the components of system 300, each of these devices can receive content and data via an input / output (hereinafter referred to as "I / O") path 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 path. 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 Figure 3 shown, both user device 308 and user device 310 include displays on which data (e.g., content related to one or more blockchain operations) is displayed.

[0053] 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 operations related to blockchain processing loads for managing blockchain operations across multiple blockchain networks using a platform load balancer within a decentralized application environment.

[0054] Each of these devices can also include an electronic storage device. The electronic storage device can include a non-transitory storage medium that stores information electronically. The electronic storage medium of the electronic storage device can include one or both of the following: (i) a system storage device provided integrally with the server or client device (e.g., substantially non-removable), or (ii) a removable storage device that can be removably connected to the server or 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 device can include one or more optically readable storage media (e.g., optical discs, etc.), magnetically readable storage media (e.g., magnetic tapes, magnetic hard disk drives, floppy disk drives, etc.), charge-based storage media (e.g., EEPROM, RAM, etc.), solid-state storage media (e.g., flash drives, etc.), and / or other electronically readable storage media. The electronic storage device can include one or more virtual storage resources (e.g., cloud storage devices, virtual private networks, and / or other virtual storage resources). The electronic storage device can store software algorithms, information determined by the processor, information obtained from the server, information obtained from the client device, or other information for implementing the functions described herein.

[0055] Figure 3It further includes a network 306, which may include communication paths between user devices. The communication paths may include the Internet, mobile phone networks, mobile voice or data networks (such as 5G or LTE networks), cable networks, public switched telephone networks, or other types of communication networks or combinations of communication networks. The communication paths may individually or collectively include one or more communication paths, such as satellite paths, fiber optic paths, cable paths, paths supporting Internet communication (such as IPTV), free space connections (such as for broadcasts or other wireless signals), or any other suitable wired or wireless communication paths or combinations of such paths. The computing device may include additional communication paths that link multiple hardware, software, and / or firmware components operating together. For example, the computing device may be implemented by a cloud that is a computing platform operating together as the computing device.

[0056] Figure 4 A schematic diagram for operating in a decentralized application using blockchain operations according to one or more embodiments is shown. For example, the system 400 may include a user device 402. Additionally, the user device 402 may include an application (such as application 404) implemented on and / or accessible by the user device 402. For example, the application 404 may interact with one or more other applications and / or APIs to manage the blockchain processing load of blockchain operations across multiple blockchain networks using a platform load balancer. For example, the application 404 may 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, and is capable of interacting with one or more decentralized applications.

[0057] The system 400 further includes an API layer 406. In some embodiments, the API layer 406 may be implemented on the user device 402. Alternatively or additionally, the API layer 406 may reside on one or more cloud components (such as server 408). For example, the API layer 406 may reside on the server 408 and include platform services for custody wallet services, decentralized applications, etc. The API layer 406 (which may be a Representational State Transfer (REST) or web service API layer) may provide a decoupled interface to data and / or functionality for one or more applications.

[0058] The API layer 406 can provide various low-level and / or blockchain-specific operations to facilitate managing the blockchain processing load of blockchain operations conducted across multiple blockchain networks by means of a platform load balancer. For example, the API layer 406 can provide blockchain operations such as blockchain writes. Additionally, the API layer 406 can perform transfer verification before forwarding a blockchain operation (e.g., a transaction) to another service (e.g., a cryptographic service). The API layer 406 can then record the result. For example, by recording to the blockchain before forwarding, the API layer 406 can maintain internal records and balances without relying on external verification (e.g., based on blockchain update activity, which may take up to ten minutes).

[0059] The API layer 406 can also provide information reading. For example, the API layer 406 (or a platform service powered by the API layer 406) can generate a blockchain operation log and write the result of the reading to an additional ledger (e.g., an internal record and / or an indexer service). If this is done, users accessing the information in other ways can see consistent information, enabling downstream users to ingest the same data points as the users.

[0060] The API layer 406 can also provide a unified API to access balances, transaction histories, and / or other records of blockchain operation activities between one or more decentralized applications and a custodial user account. By doing so, the system maintains the security of sensitive information (such as balances and transaction histories). Alternatively, the mechanism for maintaining such security would separate API access between the decentralized application and the custodial user account by using special logic. The introduction of special logic reduces the streamlining of the system, which may lead to system errors based on divergence and coordination.

[0061] 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 service API that provides a well-defined contract that describes the service in terms of the operations of the service and the data types used to exchange information. REST APIs generally do not have this contract; instead, they use client libraries in most common languages (including Ruby, Java, PHP, and JavaScript). Simple Object Access Protocol (SOAP) web services have traditionally been adopted in enterprises for publishing internal services and exchanging information with partners in business-to-business (B2B) transactions.

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

[0063] In some embodiments, the system architecture can use a microservices approach. Such a system can use two types of layers: a front-end layer and a back-end layer where microservices reside. In such an architecture, the role of the API layer 406 can be to provide integration between the front-end layer and the back-end layer. In such a case, the API layer 406 can use RESTful APIs (exposed for communication between the front-end or even between microservices). The API layer 406 can use the Advanced Message Queuing Protocol (AMQP), which is an open standard for passing business messages between applications or organizations. The API layer 406 can use an open-source, high-performance Remote Procedure Call (RPC) framework that can operate in a decentralized application environment. In some embodiments, the system architecture can use an open API approach. In such a case, the API layer 406 can use a commercial or open-source API platform and its modules. The API layer 406 can use a Developer Portal. The API layer 406 can use strong security constraints of an application web application firewall that protects the decentralized application and / or the API layer 406 from common web vulnerabilities, bots, and Distributed Denial of Service (DDoS) attacks. The API layer 406 can use RESTful APIs as the standard for external integration.

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

[0065] 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 to facilitate blockchain operations on websites, nodes, and / or other devices. In some embodiments, the wallet service may also provide access to an additional ledger (e.g., a second ledger). Additionally, as described above, this second ledger may receive updates directly from the API layer 406 rather than relying on data extracted directly from the blockchain 410.

[0066] For example, system 400 may maintain its records (e.g., real-time records and records for accounting purposes) in good order, separate from the balances on the blockchain 410. That is, system 400 may maintain an architecture characterized by a second ledger (on which balances are stored and updated) and a log of blockchain operations. While conventional systems may rely on directly referencing the blockchain 410, this reliance causes additional technical problems since the blockchain is the system's source of truth.

[0067] First, there is a high likelihood of an impedance mismatch between the format of the platform service and the API used to retrieve data from the blockchain (e.g., this may result in accounting imbalances). For example, system 400 may need to be able to generate accounting entries that reflect changes in the balance. However, while changes in the balance can be tracked by examining the blockchain 410, this requires additional processing and computational power.

[0068] Second, accounting changes in the 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., blockchain 410). By waiting for a variable number of confirmations, the likelihood of errors in the blockchain becomes infinitesimal. However, while blockchain services rely on this method, it is not an inherent rule of the blockchain itself. That is, the blockchain does not have an inherent authentication mechanism that relies on a large number of confirmations. Instead, the blockchain relies on an absolute system - either a blockchain operation is recorded on a particular node or it is not.

[0069] Therefore, forks in the blockchain are always possible. In the case of a fork, the system 400 may not follow the "right" fork for an indeterminate amount of time. If this occurs, and if for the purpose of custodial digital wallets, the system 400 decides to move from one fork to another, the system 400 may 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 a given blockchain. Additionally, in the case of a fork, the system 400 performs some internal remedies on the user account, which is achieved by the system 400 maintaining an isolation layer from the blockchain for blockchain operation remedies. For example, the system 400 may have a separate storage device protected by a second ledger (e.g., ledger service) for reading and by a transfer service for writing, which reflects the state of the blockchain relevant to the purpose of the system 400.

[0070] In some embodiments, the system may also use one or more application binary interfaces (ABIs). An ABI is an interface between two program modules (usually 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 deploying a smart contract, the bytecode is stored on the blockchain and associated with an address. To access functions defined in a high-level language, the system translates the name and arguments into a byte representation of the bytecode to work with the system. To interpret the bytes sent in a response, the system translates back to a tuple (e.g., a finite ordered list of elements) of return values defined in a high-level language. Languages compiled for the EVM maintain strict conventions regarding these translations, but to execute them, the system must maintain the exact names and types associated with the operations. The ABI precisely records these names and types in an easily parsable format to convert between method calls expected by humans and smart contract operations in a discoverable and reliable manner.

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

[0072] Figure 5A schematic diagram of a blockchain indexer according to one or more embodiments is shown. For example, in some embodiments, the system may use the indexer service 500 to manage the blockchain processing load of blockchain operations across multiple blockchain networks using a platform load balancer. The indexer service 500 may obtain raw data (e.g., data related to the current state and / or instance of the blockchain 502) (e.g., as described above) from nodes of the blockchain network. Then, the indexer service 500 may process the data and store the data in a database and / or data structure in an efficient manner to provide fast access to the data. For example, the indexer 504 may publish and / or record a subset of the blockchain operations that occur for the blockchain 502. Thus, for subsequent blockchain operations, the indexer service 500 may reference the index at the indexer 504 (instead of the nodes of the blockchain 502) to provide various services at the user device 506.

[0073] For example, the indexer 504 may store a predefined list of blockchain operations to monitor and / or record according to the index. These may include blockchain operations (e.g., "operation included", "operation removed", "operation completed") 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 subgroup, and / or other characteristics (e.g., "ETH", "ERC20", and / or "ERC721"). Additionally and / or alternatively, various blockchain operations and metadata related to those blockchain operations (e.g., block designation, user account, timestamp, etc.) and aggregations of multiple blockchain operations (e.g., total number of blockchain operations, rate of blockchain operations, rate of blockchain updates, etc.) may be monitored and / or recorded.

[0074] The indexer 504 may similarly provide navigation and search features (e.g., supporting boolean operations) for the indexed blockchain operations. In some embodiments, the indexer 504 may 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 may also mark the blockchain operations based on whether the blockchain operations originate 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 may determine whether a blockchain operation contains information related to a user of the indexer service 500 by storing information about whether the address is an internal address of the indexer service 500 or an address used in a digital wallet hosted by a predefined wallet service.

[0075] Figure 6A flowchart showing steps for generating a priority queue according to one or more embodiments is shown. For example, in some embodiments, the system may use process 600 (e.g., implemented on one or more of the system components described above) to generate a priority queue for blockchain processing loads for managing blockchain operations across multiple blockchain networks by using credit coordination.

[0076] The system may use credit coordination. As described herein, "credit coordination" may include the system maintaining a priority queue of incoming but uncredited transfers of a given asset from a cryptocurrency, where the system may first select incoming transfers that can be credited without depleting the liquidity pool. Second, the system may credit the asset to the user. Third, the system may repeat the process. In some embodiments, the system may determine whether an incoming processing request can be safely credited before generating a blockchain operation from a replenishment address to a first blockchain network, where the available processing load is transferred. By doing so, the system can avoid a situation where a single large deposit prevents the system from crediting the asset to all other users.

[0077] At step 602, process 600 may receive a plurality of processing requests from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network. As described herein, "incoming receipts from the blockchain" may include a plurality of processing requests.

[0078] At step 604, process 600 may generate a priority queue of the processing requests. As described herein, "priority queue" may include a process where the platform load balancer favors processing requests that can be immediately credited. In some embodiments, the priority queue may include a data structure that assigns priorities to each processing request within the queue. When generating the priority queue of the processing requests, the system may select processing requests from the plurality of processing requests.

[0079] At step 606, process 600 may determine whether the selected processing load can be safely credited. For example, the system may determine the selected processing load for the processing request. The system may determine the current available processing load at a first replenishment address for the second blockchain network. The system may compare the current available processing load with a threshold processing load for the first replenishment address.

[0080] At step 608, process 600 may credit the user. For example, the system may determine that the current available processing load is below the threshold processing load. The system may generate a blockchain operation from the first replenishment address to the second blockchain address, where the second blockchain operation has the selected processing load for the processing request. The system may repeat until there are no incoming processing requests remaining.

[0081] At step 610, process 600 can return the received item to the queue and wait for a state change. For example, the system can select an additional processing request in response to determining that the current available processing load is equal to the threshold processing load. The system can repeat until there are no incoming processing requests remaining.

[0082] Figure 7 A flowchart showing steps involved in managing blockchain processing loads for blockchain operations across multiple blockchain networks using a platform load balancer, according to one or more embodiments. For example, the system can use process 700 (e.g., implemented on one or more of the system components described above) to allow a user to easily access multi-network assets (first and second layers of blockchain technology).

[0083] At step 702, process 700 (e.g., using one or more of the components described above) receives a first blockchain operation involving a first processing request. For example, the system can receive the first blockchain operation at the platform load balancer, the first blockchain operation involving a first processing request from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network. For example, the system can receive a request from a user to exchange two different cryptocurrencies. By doing so, the system can significantly reduce latency and reduce the dependence on application-based server-side hardware and software dependencies.

[0084] At step 704, process 700 determines the load for the first blockchain operation. For example, the system can determine the processing load for the first blockchain operation at the platform load balancer. For example, the system can start processing the amount of the first blockchain operation. By doing so, the system can cancel the fuel fee.

[0085] At step 706, process 700 determines the load at a first supplementary address of the second blockchain network. For example, the system can determine the available processing load at the first supplementary address of the second blockchain network at the platform load balancer. For example, the system can process the amount of the second blockchain operation. By doing so, the system can eliminate long waiting times.

[0086] At step 708, process 700 compares the first processing load with the second processing load. For example, the system can compare the processing load with the available processing load. For example, the system can compare the values of different cryptocurrencies to ensure they are equal in value. By doing so, the system can eliminate the user's waiting time and can also provide the user with an option to know whether the exchange can be completed immediately.

[0087] At step 710, process 700 generates a second blockchain operation, where the second blockchain operation receives a first processing payload. For example, the system may generate a second blockchain operation from a first supplementary address to a second blockchain address in response to determining that the processing payload is within the available processing payloads, where the second blockchain operation has the processing payload. For example, the system may exchange two cryptocurrencies after ensuring that the liquidity pool has the necessary funds. By doing so, the system has a single seamless interface for the entire transaction.

[0088] At step 712 of process 700, the platform load balancer generates a cross-chain bridge call. For example, the system may generate a cross-chain bridge call in response to determining that the processing payload is not within the available processing payloads. For example, if the liquidity pool does not have the necessary funds, the system may exchange two cryptocurrencies through the cross-chain bridge. By doing so, the system has an alternative method for exchanging cryptocurrencies.

[0089] In some embodiments, the platform load balancer generates a cross-chain bridge call using wrapped tokens. For example, the system may request wrapped tokens corresponding to the processing payload issued by a cross-chain bridge provider platform, and the system may then receive the wrapped tokens. For example, the system may use several methods to utilize the cross-chain bridge to implement blockchain operations. In one method, the system may use wrapped tokens issued by a cross-chain bridge provider platform. For example, using wrapped tokens, the value of one token from a specific blockchain network can be encapsulated in another token. By doing so, the system can easily transfer tokens between different layers.

[0090] In some embodiments, the platform load balancer generates a cross-chain bridge call using an additional liquidity pool. For example, the system may request a third blockchain operation from a second supplementary address to a second blockchain address, and the system may then receive confirmation of the third blockchain operation from the second supplementary address. For example, the system may also use an additional liquidity pool provided by a third party (e.g., a cross-chain bridge provider platform) to implement cross-chain bridge blockchain operations. For example, the cross-chain bridge provider platform may use a liquidity pool that holds an inventory or pool of various coins, where one coin can be exchanged for another. By doing so, the system can easily transfer cryptocurrencies between different layers of the blockchain.

[0091] In some embodiments, the system may receive a notification due to an inoperable bridge. For example, the system may receive a notification that the cross-chain bridge is inoperable in response to a cross-chain bridge call; and in response to receiving the notification, the system may generate a message indicating that the first blockchain operation cannot be performed to a user account corresponding to the first blockchain address. For example, the system may provide a warning to users who wish to deposit funds into or withdraw funds from the network, where assets may be (temporarily) stranded due to an inoperable bridge.

[0092] In some embodiments, the system may compare the available processing load with a threshold processing load. For example, in response to determining that the processing load is within the available processing load, the system may compare the available processing load with the threshold processing load, and the system may determine to generate a second blockchain operation based on the available processing load being lower than the threshold processing load. For example, the system may monitor the available liquidity on either side and initiate a bridging transaction in the case where the liquidity on one side is insufficient to meet potential user withdrawals. Additionally or alternatively, the system may initiate a bridging transaction in the case where there is too much liquidity on the non-native side (e.g., an amount not covered by insurance).

[0093] In some embodiments, the system may send a confirmation that the processing load is within the available processing load. For example, the system may receive a first user request at a platform load balancer, where the first user request requests to verify that the processing load is within the available processing load, and the system may then send a confirmation that the processing load is within the available processing load. For example, the system may provide an endpoint where a service (such as a digital application) can query whether a particular blockchain operation can be "instantly" supported (e.g., without generating a cross-chain bridge call).

[0094] In some embodiments, the system may determine the amount of net processing load available for a first blockchain address. For example, the system may receive a second user request at a platform load balancer, where the second user request requests to determine the amount of net processing load available for the first blockchain address for multiple blockchain operations, and the system may then send the amount of net processing load to the user account corresponding to the first blockchain address. For example, the system may provide data on the total balance of the user's assets across all networks (e.g., how much Ethereum the user has in total available for withdrawal, rather than how much of what they have deposited happens to reside on the Ethereum native side and how much is on the Polygon side).

[0095] In some embodiments, the system may be stored in a digital repository. For example, the system may determine the available processing load at a first supplementary address, where the first supplementary address corresponds to the digital repository of the platform load balancer. For example, the system may use a separate hot pool created specifically for the service for the allocation of its liquidity to ensure isolation. By doing so, the system can ensure isolation between the liquidity pool and the user's funds.

[0096] In some embodiments, the system may generate a second blockchain operation from a first supplemental address to a second blockchain address in a manner that further includes generating a fourth blockchain operation from a third supplemental address, where both the third supplemental address and a fourth supplemental address correspond to a platform load balancer, and where the third supplemental address corresponds to a digital repository of the platform load balancer, and where the fourth supplemental address corresponds to a physical repository. For example, the system may generate a second blockchain operation from a first supplemental address to a second blockchain address, where generating the second blockchain operation from the first supplemental address to the second blockchain address further includes generating a fourth blockchain operation from the third supplemental address to the fourth supplemental address, where both the third supplemental address and the fourth supplemental address correspond to the platform load balancer, where the third supplemental address corresponds to the digital repository of the platform load balancer, and where the fourth supplemental address corresponds to the physical repository. For example, the main network will support cold storage, while the supplemental address does not. The system may need to manage hot storage and / or cold storage for the same assets on each additional network, where the system may add pools for a given asset (e.g., Polygon+WETH) on each alternative network. By doing so, the system can securely store the user's data.

[0097] In some embodiments, the system may return an aggregated processing load to a first blockchain network. For example, the system may receive, at a platform load balancer, multiple processing requests from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network. The system may determine, at the platform load balancer, an aggregated processing load of the multiple processing requests. The system may determine, at the platform load balancer, a current available processing load at a first supplemental address for the second blockchain network. The system may compare the current available processing load with a threshold processing load for the first supplemental address. The system may return the aggregated processing load to the first blockchain network in response to determining that the current available processing load is equal to the threshold processing load. For example, if the pool becomes too deep, the system may pause crediting funds transferred to the user until sufficient funds can be bridged to the cryptocurrency. By doing so, the system can prevent the user from losing funds in unstable cryptocurrencies.

[0098] In some embodiments, the system may generate a priority queue of processing requests. For example, the system may receive, at a platform load balancer, multiple processing requests from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network. The system may generate a priority queue of processing requests by selecting processing requests. The system may determine, at the platform load balancer, a selected processing load for a processing request. The system may determine, at the platform load balancer, a current available processing load at a first supplementary address for the second blockchain network. The system may compare the current available processing load with a threshold processing load for the first supplementary address. The system may determine that the current available processing load is below the threshold processing load. The system may generate a blockchain operation from the first supplementary address to the second blockchain address, where the second blockchain operation has the selected processing load for the processing request. The system may repeat until no processing requests remain. For example, the system may prioritize satisfying smaller requests first. By doing so, users do not need to wait for a long period of time for a request to be satisfied.

[0099] In some embodiments, the system may select additional processing requests. For example, the system may select additional processing requests in response to determining that the current available processing load is equal to the threshold processing load. For example, if the system determines that a request is too large and will deplete the liquidity pool, the system may select to satisfy another smaller processing request first. By doing so, the system is optimized such that users with smaller requests do not need to wait for a long period of time for a request to be satisfied.

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

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

[0102] The technical solution of the present invention will be better understood with reference to the following exemplary embodiments:

[0103] 1. A method, the method includes receiving a first blockchain operation at a platform load balancer, the first blockchain operation involves a first processing request from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network; determining a processing load for the first blockchain operation at the platform load balancer; determining an available processing load at a first supplementary address for the second blockchain network at the platform load balancer; comparing the processing load with the available processing load; in response to determining that the processing load is within the available processing load, generating a second blockchain operation from the first supplementary address to the second blockchain address, where the second blockchain operation has a processing load; and in response to determining that the processing load is not within the available processing load, generating a cross-chain bridge call.

[0104] 2. The method according to the previous embodiment, wherein generating a cross-chain bridge call includes: requesting an encapsulated token issued by a cross-chain bridge provider platform corresponding to the processing load; and receiving the encapsulated token.

[0105] 3. The method according to any one of the previous embodiments, wherein generating a cross-chain bridge call includes: requesting a third blockchain operation from a second supplementary address to the second blockchain address; and receiving a confirmation of the third blockchain operation executed by the second supplementary address.

[0106] 4. The method according to any one of the previous embodiments, includes: in response to a cross-chain bridge call, receiving a notification that the cross-chain bridge is inoperable; and in response to receiving the notification, generating a message to a user account corresponding to the first blockchain address, the message indicating that the first blockchain operation cannot be executed.

[0107] 5. The method according to any one of the previous embodiments, includes: in response to determining that the processing load is within the available processing load, comparing the available processing load with a threshold processing load; and determining to generate a second blockchain operation based on the available processing load being lower than the threshold processing load.

[0108] 6. The method according to any one of the previous embodiments, includes: receiving a first user request at the platform load balancer, where the first user request requests to verify that the processing load is within the available processing load; and sending a confirmation that the processing load is within the available processing load.

[0109] 7. The method according to any one of the previous embodiments, includes: receiving a second user request at the platform load balancer, where the second user request requests to determine the amount of net processing load available for multiple blockchain operations at the first blockchain address; and sending the amount of net processing load to a user account corresponding to the first blockchain address.

[0110] 8. The method according to any one of the foregoing embodiments, wherein the first supplementary address corresponds to a digital repository of a platform load balancer.

[0111] 9. The method according to any one of the foregoing embodiments, further comprising: receiving, at a platform load balancer, a plurality of processing requests from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network; determining, at the platform load balancer, an aggregated processing load of the plurality of processing requests; determining, at the platform load balancer, a current available processing load at a first supplementary address of the second blockchain network; comparing the current available processing load with a threshold processing load of the first supplementary address; and in response to determining that the current available processing load is equal to the threshold processing load, returning the aggregated processing load to the first blockchain network.

[0112] 10. The method according to any one of the foregoing embodiments, further comprising: receiving, at a platform load balancer, a plurality of processing requests from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network; and generating a priority queue of the processing requests by the following steps: selecting a processing request; determining, at the platform load balancer, a selected processing load for the processing request; determining, at the platform load balancer, a current available processing load at a first supplementary address of the second blockchain network; comparing the current available processing load with a threshold processing load of the first supplementary address; determining that the current available processing load is lower than the threshold processing load; generating a blockchain operation from the first supplementary address to the second blockchain address, wherein the second blockchain operation has the selected processing load for the processing request; and repeating until no incoming processing requests remain.

[0113] 11. 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 including those of any one of Embodiments 1-10.

[0114] 12. A system, comprising: one or more processors; and a memory storing instructions that, when executed by the processors, cause the processors to implement operations including those of any one of Embodiments 1-10.

[0115] 13. A system, comprising means for performing any one of Embodiments 1-10.

Claims

1. A system for managing a blockchain processing load for blockchain operations conducted across multiple blockchain networks, the system comprising: One or more processors; And A non-transitory computer-readable medium having instructions recorded thereon that, when executed by the one or more processors, cause operations including: Receiving, at a platform load balancer, a first blockchain operation that involves a first processing request from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network, wherein the first blockchain operation is received from a first user interface on a first user device, and wherein the first blockchain address corresponds to a first cryptography-based storage application, and wherein the first cryptography-based storage application corresponds to a first private key; Determining, at the platform load balancer, a processing load for the first blockchain operation; Determining, at the platform load balancer, an available processing load at a first supplementary address for the second blockchain network; Comparing the processing load with the available processing load; And In response to determining that the processing load is within the available processing load, generating a second blockchain operation from the first supplementary address to the second blockchain address, wherein the second blockchain operation has the processing load, and wherein the second blockchain address corresponds to a second cryptography-based storage application, and wherein the second cryptography-based storage application corresponds to a second private key.

2. A method for managing a blockchain processing load for blockchain operations conducted across multiple blockchain networks, the method comprising: Receiving, at a platform load balancer, a first blockchain operation that involves a first processing request from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network; Determining, at the platform load balancer, a processing load for the first blockchain operation; Determining, at the platform load balancer, an available processing load at a first supplementary address for the second blockchain network; Comparing the processing load with the available processing load; In response to determining, at the platform load balancer, that the processing load is within the available processing load, generating a second blockchain operation from the first supplementary address to the second blockchain address, wherein the second blockchain operation has the processing load; and In response to determining that the processing load is not within the available processing load, generating a cross-chain bridge call.

3. The method according to claim 2, wherein, Generating the cross-chain bridge call includes: Requesting a wrapped token issued by a cross-chain bridge provider platform corresponding to the processing load; and Receiving the wrapped token.

4. The method according to claim 2, wherein, Generating the cross-chain bridge call includes: Requesting a third blockchain operation from a second supplementary address to the second blockchain address; and Receiving an acknowledgement of the third blockchain operation executed by the second supplementary address.

5. The method according to claim 2, further comprising: Receiving a notification that the cross-chain bridge is inoperable in response to the cross-chain bridge call; And In response to receiving the notification, generate a message to the user account corresponding to the first blockchain address, the message indicating that the first blockchain operation cannot be executed.

6. The method according to claim 2, further comprising: In response to determining that the processing load is within the available processing load, compare the available processing load with a threshold processing load; and Based on the available processing load being lower than the threshold processing load, determine to generate the second blockchain operation.

7. The method according to claim 2, further comprising: Receive a first user request at the platform load balancer, wherein the first user request requests to verify that the processing load is within the available processing load; and Send a confirmation that the processing load is within the available processing load.

8. The method according to claim 2, further comprising: Receive a second user request at the platform load balancer, wherein the second user request requests to determine the amount of net processing load available for the first blockchain address for a plurality of blockchain operations; and Transmit the amount of the net processing load to the user account corresponding to the first blockchain address.

9. The method according to claim 2, wherein, The first supplementary address corresponds to the digital repository of the platform load balancer.

10. The method according to claim 2, further comprising: Receive a plurality of processing requests at the platform load balancer from the first blockchain address on the first blockchain network to the second blockchain address on the second blockchain network; Determine an aggregated processing load of the plurality of processing requests at the platform load balancer; Determine a currently available processing load at the first supplementary address for the second blockchain network at the platform load balancer; Compare the currently available processing load with a threshold processing load for the first supplementary address; and In response to determining that the currently available processing load is equal to the threshold processing load, return the aggregated processing load to the first blockchain network.

11. The method according to claim 2, further comprising: Receive a plurality of processing requests at the platform load balancer from the first blockchain address on the first blockchain network to the second blockchain address on the second blockchain network; and Generate a priority queue of processing requests by the following steps: Select a processing request; Determine a selected processing load for the processing request at the platform load balancer; Determine a currently available processing load at the first supplementary address for the second blockchain network at the platform load balancer; Compare the currently available processing load with a threshold processing load for the first supplementary address; Determine that the currently available processing load is lower than the threshold processing load; Generate a blockchain operation from the first supplementary address to the second blockchain address, wherein the second blockchain operation has the selected processing load for the processing request; and Repeat until there are no incoming processing requests remaining.

12. The method according to claim 11, wherein, Comparing the currently available processing load with the threshold processing load for the first supplementary address further comprises: In response to determining that the current available processing load is equal to the threshold processing load, select an additional processing request.

13. The system according to claim 1, wherein, Generating the second blockchain operation from the first supplementary address to the second blockchain address further includes generating a fourth blockchain operation from a third supplementary address to a fourth supplementary address, where both the third supplementary address and the fourth supplementary address correspond to the platform load balancer, where the third supplementary address corresponds to the digital repository of the platform load balancer, and where the fourth supplementary address corresponds to the physical repository.

14. A non-transitory computer-readable medium having instructions recorded thereon that, when executed by one or more processors, cause operations including the following: Receive, at a platform load balancer, a first blockchain operation that involves a first processing request from a first blockchain address on a first blockchain network to a second blockchain address on a second blockchain network; Determine, at the platform load balancer, a processing load for the first blockchain operation; Determine, at the platform load balancer, an available processing load at a first supplementary address for the second blockchain network; Compare the processing load with the available processing load; In response to determining, at the platform load balancer, that the processing load is within the available processing load, generate a second blockchain operation from the first supplementary address to the second blockchain address, where the second blockchain operation has the processing load; and In response to determining that the processing load is not within the available processing load, generate a cross-chain bridge call.

15. The non-transitory computer-readable medium according to claim 14, wherein, Generating the cross-chain bridge call includes: Requesting a third blockchain operation issued from a second supplementary address to the second blockchain address; and Receiving an acknowledgement of the third blockchain operation executed by the second supplementary address.

16. The non-transitory computer-readable medium according to claim 14, wherein, The instructions cause operations further including the following: In response to the cross-chain bridge call, receive a notification that the cross-chain bridge is inoperable; and In response to receiving the notification, generate a message to a user account corresponding to the first blockchain address, the message indicating that the first blockchain operation cannot be executed.

17. The non-transitory computer-readable medium according to claim 14, wherein, The instructions cause operations further including the following: In response to determining that the processing load is within the available processing load, compare the available processing load with a threshold processing load; and Determine to generate the second blockchain operation based on the available processing load being lower than the threshold processing load.

18. The non-transitory computer-readable medium according to claim 14, wherein, The instructions cause operations further including the following: Receive, at the platform load balancer, a first user request, where the first user request requests to verify that the processing load is within the available processing load; and Send an acknowledgement that the processing load is within the available processing load.

19. The non-transitory computer-readable medium according to claim 14, wherein, The instructions cause operations further including the following: Receive, at the platform load balancer, a second user request, where the second user request requests to determine an amount of net processing load available for multiple blockchain operations at the first blockchain address; and Transmit the amount of the net processing load to a user account corresponding to the first blockchain address.

20. The non-transitory computer-readable medium according to claim 14, wherein, Generating the second blockchain operation from the first supplementary address to the second blockchain address further includes generating a fourth blockchain operation from a third supplementary address to a fourth supplementary address, where both the third supplementary address and the fourth supplementary address correspond to the platform load balancer, where the third supplementary address corresponds to the digital repository of the platform load balancer, and where the fourth supplementary address corresponds to the physical repository.

Images