CROSS-REFERENCE

[0001] This application claims priority to U.S. Provisional Patent Application No.

62/862,086, filed on June 16, 2019, which is incorporated herein by reference in its entirety.

BACKGROUND

[0002] A blockchain is a list of data blocks that are linked together using cryptography. Each block may contain a hash of the previous block, a timestamp, and transaction data. In order to alter data in a particular block, all subsequent blocks in the blockchain may need to be altered, which may require a consensus of such subsequent blocks. For this reason, blockchains may be a desirable medium in which to securely store data.

[0003] Service providers on the World Wide Web (“WWW”) may authenticate users and deliver relevant content to such users in various ways, e.g., through the use of cookies, sessions, authentication tokens, and the like. In general, resource providers may authenticate users by checking a private user database on a central server. The private user database may store user credentials to facilitate the checking. Generally, each service provider maintains its own user database. When a client transmits a request to a server operated by a service provider, depending on the permission structure determined by a request filter, the request is either forwarded to the desired application programming interface (“API”) service endpoint which then returns the expected response, or it returns an error response.

SUMMARY

[0004] The present disclosure provides systems, methods, and computer program products that use a blockchain to manage authentication and routing for an application programming interface (“API”). For example, the blockchain-based authentication described herein can authenticate a request by a user to use a web service. The system can receive a blockchain transaction. The blockchain transaction may follow the protocol of a particular blockchain (i.e., have the format and structure of typical transactions in that blockchain). The blockchain transaction may have a request payload and a digital signature. The request payload may specify a service or content that a user of a client device seeks to access. The request payload may additionally contain user-identifying data. The system can generate, based at least in part on the request payload, a query of an indexed database corresponding to the blockchain. The system can obtain, using the query, data about the user from the indexed database. The data about the user may comprise transaction data and a public key associated with the user. The system can determine, using the public key, that the digital signature is associated with the user; and authenticate the request by the user to use the web service if the transaction data satisfies a condition.

[0005] The blockchain-based authentication system described above may provide advantages over conventional authentication systems. In conventional authentication systems, user databases that store sensitive user data may be centralized and privately owned. Such user databases may be vulnerable to hacks, and service providers may have to take expensive precautions to ensure the security of such user data. Additionally, applications relying on authentication through a private database may not be easily portable. That is, users of such applications may be locked into the service provider’s server because the user data exists only on that server. With the exception of companies that deliberately generate revenue by selling user data to third parties, many service providers may prefer to not store and secure sensitive user data, instead focusing on their core businesses.

[0006] The blockchain-based authentication system described above may permit such service providers to outsource authentication to a blockchain system instead of storing user data in a private database and do it without compromising security. This may allow service providers to use less storage capacity and perform less authentication-based processing, instead allowing them to focus on their core competencies.

[0007] In one aspect, the present disclosure provides a method for authenticating a request by a user to use a web service. The method may comprise (a) receiving a blockchain transaction at a computer server that provides the web service. The blockchain transaction may follow a protocol of a blockchain. The blockchain transaction may comprise a request payload and a digital signature. The method may further comprise (b) generating, based at least in part on the request payload, a query of an indexed database corresponding to the blockchain; (c) obtaining transaction data from the indexed database using the query; and (d) authenticating the request by the user to use the web service if the transaction data satisfies a condition and not authenticating the request by the user to use the web service if the transaction data does not satisfy the condition.

[0008] In some embodiments, the request payload comprises data that identifies the user and the web service.

[0009] In some embodiments, the request payload comprises data corresponding to a financial transaction between the user and the web service. In some embodiments, the method further comprises broadcasting the data corresponding to the financial transaction to the blockchain.

[0010] In some embodiments, the query comprises one or more financial transaction attributes selected from the group consisting of a sender address, a recipient address, a transaction amount, and a transaction time.

[0011] In some embodiments, the query comprises a blockchain block height.

[0012] In some embodiments, the method further comprises, prior to (d), verifying that the digital signature is associated with the user using a public key. In some embodiments, the digital signature is generated using a private key associated with the public key. In some embodiments, the blockchain transaction comprises the public key. In some embodiments, the computer server stores the public key. In some embodiments, (c) further comprises obtaining the public key from the indexed database. In some embodiments, the private key and the public key have been cryptographically derived from a seed.

[0013] In some embodiments, the indexed database is not operated by the web service.

[0014] In some embodiments, the method further comprises, prior to (b), decoding the blockchain transaction using the blockchain protocol.

[0015] In some embodiments, the method further comprises, upon authenticating the request in (d), routing the request to an application programming interface that implements the web service.

[0016] In some embodiments, the method further comprises, upon not authenticating the request in (d), transmitting a notification to the user indicative of the request not being authenticated.

[0017] In some embodiments, the indexed database is a document database, a relational database, or a graph database.

[0018] In some embodiments, the indexed database is a file system.

[0019] In some embodiments, the transaction data corresponds to a transaction between the user and the web service, and wherein the condition is whether the transaction occurred within a specified period time.

[0020] In some embodiments, the request is a Hypertext Transfer Protocol (HTTP) request.

[0021] In some embodiments, the transaction data comprises information for routing the request to the web service.

[0022] In some embodiments, the indexed database is constructed by crawling the blockchain. [0023] In some embodiments, the request payload comprises the query.

[0024] In some embodiments, the condition comprises the transaction data matching a pattern.

[0025] Another aspect of the present disclosure provides a non-transitory computer readable medium comprising machine executable code that, upon execution by one or more computer processors, implements any of the methods above or elsewhere herein.

[0026] Another aspect of the present disclosure provides a system comprising one or more computer processors and computer memory coupled thereto. The computer memory comprises machine executable code that, upon execution by the one or more computer processors, implements any of the methods above or elsewhere herein.

[0027] Additional aspects and advantages of the present disclosure will become readily apparent to those skilled in this art from the following detailed description, wherein only illustrative embodiments of the present disclosure are shown and described. As will be realized, the present disclosure is capable of other and different embodiments, and its several details are capable of modifications in various obvious respects, all without departing from the disclosure. Accordingly, the drawings and description are to be regarded as illustrative in nature, and not as restrictive.

INCORPORATION BY REFERENCE

[0028] All publications, patents, and patent applications mentioned in this specification are herein incorporated by reference to the same extent as if each individual publication, patent, or patent application was specifically and individually indicated to be incorporated by reference. To the extent publications and patents or patent applications incorporated by reference contradict the disclosure contained in the specification, the specification is intended to supersede and/or take precedence over any such contradictory material.

BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The novel features of the invention are set forth with particularity in the appended claims. A better understanding of the features and advantages of the present invention will be obtained by reference to the following detailed description that sets forth illustrative embodiments, in which the principles of the invention are utilized, and the accompanying drawings (also“Figure” and“FIG.” herein), of which:

[0030] FIG. 1 schematically illustrates a centralized authentication system;

[0031] FIG. 2 schematically illustrates a blockchain-based authentication system; [0032] FIG. 3 is a flow chart of an example process for authenticating a request using a blockchain;

[0033] FIG. 4 shows an example blockchain transaction;

[0034] FIG. 5 shows examples of a queries of a blockchain index;

[0035] FIG. 6 shows how data can be embedded in a blockchain transaction;

[0036] FIG. 7 is a flow chart of an example process for crawling a blockchain;

[0037] FIG. 8 is a flow chart of an example process for listening to a blockchain;

[0038] FIG. 9 shows how an HTTP request may be encapsulated in a blockchain transaction;

[0039] FIG. 10 shows a plurality of blockchain transactions that can be used to encapsulate HTTP requests;

[0040] FIG. 11 schematically illustrates a computer system that is programmed or otherwise configured to implement methods provided herein; and

[0041] FIG. 12 schematically illustrates an alternative embodiment of the blockchain- based authentication system of FIG. 2.

DETAILED DESCRIPTION

[0042] While various embodiments of the invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. Numerous variations, changes, and substitutions may occur to those skilled in the art without departing from the invention. It should be understood that various alternatives to the embodiments of the invention described herein may be employed.

[0043] Whenever the term“at least,”“greater than,” or“greater than or equal to” precedes the first numerical value in a series of two or more numerical values, the term“at least,”“greater than” or“greater than or equal to” applies to each of the numerical values in that series of numerical values. For example, greater than or equal to 1, 2, or 3 is equivalent to greater than or equal to 1, greater than or equal to 2, or greater than or equal to 3.

[0044] Whenever the term“no more than,”“less than,” or“less than or equal to” precedes the first numerical value in a series of two or more numerical values, the term“no more than,”“less than,” or“less than or equal to” applies to each of the numerical values in that series of numerical values. For example, less than or equal to 3, 2, or 1 is equivalent to less than or equal to 3, less than or equal to 2, or less than or equal to 1.

[0045] FIG. 1 schematically illustrates a centralized authentication system. The centralized authentication system may include a client 100 and a server 101. The client 100 may have a request manager 102 and a session manager 103. The server 101 may have a request filter 104, a user data database 105, and an application programming interface (“API”) service 106.

[0046] The client 100 may transmit a request to the server 101. The request may be, for example, a request to access data or use a service provided by the server 101. The request may be a Hyper Text Transfer Protocol (“HTTP”) request that defines what the client 100 expects to get from the server 101. The request manager 102 can construct the HTTP request. Then, the request manager 102 can pass the constructed request to the session manager 103. The session manager 103 can attach user identifying data to the request, including cookies or locally-stored authentication tokens. The client 100 can send the resulting request to the server 101.

[0047] The request filter 104 of the server 101 can process the request to determine if the client 101 is permitted to access the API service 106. The request filter 104 can process various parts of the request such as the HTTP header, which may include the cookies or authentication tokens attached by the session manager 103. In some cases, the request filer 104 may additionally process the content of the request to determine whether the request should be forwarded to the API service 106 in the first instance.

[0048] The request filter 104 can query the user database 105. The query may include the user-identifying data extracted from the HTTP header. Once the corresponding user is found in the user database 105, the request filter 104 can check the user’s permission status. And according to this information, the request filter 104 can decide whether to forward it to the API service 106 or respond with an error message back to the client 100. If the request passes the filter, the request is forwarded to the relevant API service 106. And the API service does its job, such as querying its own database or running computations, after which it returns the response back to the client 100. If not, it immediately returns with an error response.

[0049] In some cases, the service provider that operates the server 101 may prefer to outsource authentication and allocate more memory and processing power to business functions.

[0050] FIG. 2 schematically illustrates a blockchain-based authentication system. The system may have a client 200, a server 201, a blockchain query engine 202, and a blockchain 209. The client 200 may have a request manager 203 and a wallet 204. The server 201 may have a request filter 205 and an API service 206 but notably, not a user database. The blockchain query engine 202 may have a blockchain index 207 and a crawler 208. [0051] When the client 200 transmits a request to the server 201, the server 201 can query the blockchain query engine 202 instead of its own user database for authentication. Consequently, the server 101 need not store sensitive user data. The blockchain query engine 202 may or may not be operated by the same service provider who operates the server 201. The benefit of using the blockchain query engine 202 and the blockchain 209 for

authentication is that the service provider that operates the server 201 is free from the worry of getting hacked because the blockchain index 207, which may store sensitive user data, can always be deterministically derived from the blockchain 209 with a fixed algorithm executed by the crawler 208. In other words, the sensitive data is backed up on the blockchain 209.

[0052] User permission can be determined by combining the blockchain query to the blockchain index 207 along with a digital signature from the wallet 204 of the client 200. In order to hack the blockchain query engine 202, a hacker would need to take over the blockchain first, which may be significantly more difficult than hacking a single server due to the inherent security of the blockchain 209. Unless the blockchain 209 itself is taken over by a hacker, the blockchain query engine 202 can always reconstruct the blockchain index 207 from scratch by allowing the crawler 208 to read from the blockchain 209 and update the database at blockchain index 207.

[0053] The request manager 203 of the client 200 may serve the same function as the request manager 102 in FIG. 1. However, the client 200 may additionally have a blockchain wallet 204 that locally stores a public/private key pair for a user. The blockchain wallet 204 may use asymmetric cryptography (e.g., Elliptic Curve Digital Signature Algorithm

(“ECDSA”)) to generate the public/private key pair. The blockchain wallet 204 may use the same protocol as the blockchain 209. In this way, authentication can be performed without any user identifying data from the server 201. This is because the public/private key pair generated locally by the wallet 204 may be in synchronization with the blockchain 209, and the blockchain query engine 202 may be deterministically derived from the blockchain 209. Due to the cryptography that powers the blockchain 209 and the wallet 204, an intermediary database is not required to prove the ownership of the identity. Rather, it is possible to prove identity by signing a message with a private key and validating it against a public key that is publicly available. The blockchain 209 can store transactions that publicly display the public key, while only the wallet 204 has the knowledge of the private key which can be used to prove the user’s identity. A public key or an address generated by the wallet 204 may be shared publicly to identify the user. However, the private key may be kept privately on the wallet 204 and only used for signing messages or transactions. To prove the authenticity of the message or transaction (i.e., that the message or transaction is actually from the user), the system can utilize blockchain’ s own protocol. The wallet 204 can wrap a request from the request manager 203 into a blockchain transaction, sign the blockchain transaction, and send it to the request filter 205 of the server 201. The request filter 205 can decode the transaction to determine various attributes of the request from the request manager 203 as well as additional pieces of information added to the transaction itself by wallet 204. Such additional information may include instructions for monetary transactions over the blockchain 209.

[0054] When the request filter 205 receives a transaction from wallet 204, it can decode the transaction using the same protocol that governs the blockchain 209. The request filter 205 can use any of the information it extracted to query the blockchain query engine 202 to determine what to do next.

[0055] As mentioned above, the blockchain query engine 202 may have a crawler 208 and blockchain index 207. The crawler 208 can read the latest state of the blockchain 209, parse the transactions it discovers, and update the blockchain index 207. The blockchain index 207 may be implemented as a database, a file system, or any other persistence scheme that may be queried. Based on the response to the query from the blockchain index 207, the request filter 205 can determine whether the request from the client 200 was valid. If the request filter 205 determines that the request is valid based on its program, it can route the original request to the API service 206, which may be a backend system with its own logic. The API service 206 can generate a response to the original request and return the response to the client 200. However, if the request filter 205 determines that the request is not valid, it can immediately return an error response (or other notification) to the client 200, bypassing the API serve 206. In some cases, there may be many API service endpoints, and the request filter 205 can determine the particular API service endpoint to which the request should be forwarded. This authentication model does not require a centralized user database because the wallet 204 of the client 200 may use the same blockchain protocol as the blockchain 209 to generate its key pairs. And thanks to asymmetric cryptography, authenticity can be validated without an intermediary.

[0056] The components of FIG. 2 may be implemented on one or more computing devices in one or more locations. The computing devices can be servers, desktop or laptop computers, electronic tablets, mobile devices, or the like. The computing devices can be located in one or more locations. The computing devices can have general-purpose processors, graphics processing units (GPU), application-specific integrated circuits (ASIC), field-programmable gate-arrays (FPGA), or the like. The computing devices can additionally have memory, e.g., dynamic or static random-access memory, read-only memory, flash memory, hard drives, or the like. The memory can be configured to store instructions that, upon execution, cause the computing devices to implement the functionality of the subsystems. The computing devices can additionally have network communication devices. The network communication devices can enable the computing devices to communicate with each other and with any number of user devices, over a network. The network can be a wired or wireless network. For example, the network can be a fiber optic network, Ethernet® network, a satellite network, a cellular network, a Wi-Fi® network, a Bluetooth® network, or the like. In other implementations, the computing devices can be several distributed computing devices that are accessible through the Internet. Such computing devices may be considered cloud computing devices.

[0057] FIG. 3 is a flowchart of an example process for authenticating a request using a blockchain. The process can be performed by the various components of the blockchain- based authentication system described in reference to FIG. 1. The flowchart follows the lifecycle of a single network request.

[0058] The request manager 203 can construct a request payload (300). The request payload may be any typical HTTP request payload, including a request to POST a key/value pair or file, or a GET request.

[0059] The wallet 204 of the request manager 203 can attach user identifying attributes to the payload by wrapping the payload inside a blockchain transaction (301). The transaction may be a transaction with an opcode that enables data embedding such as, but not limited to, Bitcoin’s OP RETURN. The wallet 204 can create the transaction and sign it with its private key. Then the wallet can send the resulting signed transaction as an HTTP request. The transaction may not be broadcast to the blockchain 209. Instead, it may only be used as a wrapper that authenticates the actual request payload created by the request manager 203.

[0060] The request filter 205 can decode the transaction by following the blockchain protocol (302). Decoding the transaction may give the request filter 205 enough information to identify the blockchain wallet address that signed the transaction. The request filter 205 can additionally extract the original payload back from the blockchain transaction. The payload may contain various types of data, such as files, key/value pairs, or an entire query language to be passed to the API service 206.

[0061] Using this decoded information, the request filter 205 can query to the blockchain query engine 202 (303). The query may take different forms. The blockchain query engine 202 is assumed to have indexed every aspect of all or a subset of all historical blockchain transactions in an easily query-able manner, and also provides a flexible query interface to query exactly the information needed.

[0062] After querying the blockchain index 207, the request filter 205 can determine whether the address associated with the blockchain transaction sent by the wallet 204 is permitted to access the API service 206 (304). For example, the wallet address may have made a payment in the last 30 days to an address owned by the API service 206. Or the query may look for any historical transactions that match certain conditions derived from the incoming API service request from client 200. This process is described in more detail in reference to other figures.

[0063] If the query results indicate that the user is permitted to access the API service

206, the request filter 205 can forward the original request to it (306). The API service 206 may process the request and return a response to the client 200 (307). On the other hand, if the query results indicate that the user is not permitted to access the API service 206, the request filter 205 can return an error response to the client 200 (305).

[0064] FIG. 9 illustrates one example of how an HTTP request payload may be encapsulated in a blockchain transaction. Although the example in FIG. 9 uses a Bitcoin transaction, any blockchain that allows embedding of arbitrary data into transactions may be used. This diagram only shows one Bitcoin script output of a transaction, but it is possible to attach many other Bitcoin script outputs to a single transaction. For example, the API service 206 may be a paid service and may only allow requests that are encapsulated within a blockchain transaction that also make a payment to a blockchain wallet address owned by the API service 206. Since any data can be embedded in transactions, the request manager 203 can encapsulate any HTTP request inside a data embedding transaction, such as GET request (900), or a POST request, or a POST request that uploads a whole file over multipart scheme (902). However this is just one example, and there are many other ways to embed API request information in a transaction. API route paths may be embedded as a string, a query language, or any other data that the request filter 205 will be able to understand and forward to the API service 206.

[0065] While FIG. 9 describes how the request manager 203 embeds a request in a blockchain transaction, embedding on its own does not authenticate the blockchain transaction. The wallet 204 may additionally sign the transaction in order to prove authenticity. The wallet 204 can sign the transaction using its private key (301) and send it to the server 201. Normally, blockchain wallets create transactions and broadcast those transaction to the blockchain network immediately. In this case, however, the transaction can be used as an encapsulation for a regular HTTP request to be sent to a third-party server 201. The request filter 205 on the server side can then inspect the signed blockchain transaction. By inspecting the signature and the rest of the transaction (302), the request filter 205 may decode the corresponding blockchain wallet address from which the original request payload originated. Also, since the transaction contains not just the payload embedding Bitcoin output script but may contain many other sources of information such as all of its Bitcoin input scripts and the rest of the Bitcoin output scripts, it can take all of this information into account when deciding whether or not to forward the request to the expected API service 206.

[0066] One example job of the request filter 205 may be to determine the permission level of a request. It may also include a routing feature which directs the request to a relevant API service endpoint (206) depending on its judgment. To achieve this, the request filter 205 may make a query to the blockchain index 207 of the blockchain query engine 202 (303).

The blockchain query engine 202 and the server 201 are simply logical representations of each module and the diagram does not imply they exist on remote machines. They may exist on the same network or on a different network. The blockchain index 207 may be a database system constructed by processing blockchain transactions to break them down into indexable pieces and storing them in a database. The crawler 208 of the blockchain query engine 202 may continually read each block and the mempool of the blockchain 209. Crawling may involve reading the blockchain transactions, breaking them down into pieces, and indexing them as columns of a database table (relational database), or as attributes of a database collection (in the case of document databases), or as a node or an edge (in the case of graph database). The blockchain index 207 may be any type of indexable and query-able database. One example of such a database instance is BitDB, which can break down every aspect of a bitcoin transaction into meaningful pieces and stores them as attributes of a collection.

However there can be many other approaches of indexing blockchain transactions. Once the blockchain index 207 is constructed, the blockchain query engine 202 can expose an API for use by the server 201. The server 201 can query the blockchain query engine 202 to fetch various pieces of information relevant to the incoming request the server 210 received from the client 200. The incoming request may contain data corresponding to the sender address, the sender signature, the recipient address, and the API request itself constructed by the request manager 203. The request filter 205 may have a pre-defmed ruleset that determines whether the request should be provided to the API service 206. The request filter 205 can programmatically query the blockchain query service 202 using all of the information extracted from the request it received from the client 200 (303). If the query satisfies a condition (304), the request filer 205 can forward the request to the relevant API service endpoint 206 (306). Otherwise, it can send an error response to the client 200 (305). Even routing information may be stored on the blockchain as a transaction through the data- embedding opcodes mentioned above (e.g., OP RETURN in Bitcoin, or the like). The API service 206 can then process the request as it normally would and send a response to the client 200.

[0067] The blockchain query engine 202 may be a service that constructs database systems for storing data derived from the blockchain 209. While blockchains may be optimized for security, they may not be optimized for querying because of their fixed data structure. However, changing the blockchain data structure itself may compromise its performance and security. Additionally, changing the blockchain data structure itself may be an inflexible solution. On the other hand, a mechanism that continually reads from the blockchain and indexes it to various powerful database systems optimized for querying achieves performance and flexibility without compromising existing properties of the blockchain.

[0068] The blockchain query engine 202 can implement such a mechanism. The blockchain query engine 202 can continually synchronize with the blockchain 209 to parse blockchain transactions, store such transactions in a database, and provide an API that enables developers to access the database and build custom state machines. The core of the blockchain query engine 202 may be the crawler 208. The crawler 208 may have two operational modes: crawl mode (FIG. 7) and listen mode (FIG. 8). When the blockchain query engine 202 first starts, it may be in crawl mode. After the initial crawl is complete, the crawler 208 may enter listen mode to continue synchronizing in real-time.

[0069] FIG. 7 is a flow chart of an example process for crawling a blockchain. The crawler 208 can perform the crawl process depicted in FIG. 7. The crawler 208 can select a height“i” (700). Thereafter, the crawler 208 can read the block content at height“i”, extracting raw data for all the transactions in the block (702). The crawler 208 can decode the data into a structured format that can be easily indexed and later queried (704). Using this structured data, the crawler 208 can update the blockchain index 207 which may take the form of a database but may be any form of storage (706). The crawler 208 can then determine if“i” corresponds to the current tip of the blockchain (i.e., if“i” is greater than or equal to the blockchain’s current height). If so, the crawler 208 can enter listen mode (712). If not, the crawler 208 can continue to crawl by incrementing“i” (710) and continuing from operation 702.

[0070] FIG. 8 is a flow chart of an example process for listening to the blockchain. The crawler 208 can perform the process depicted in FIG. 8. When the crawler exits crawl mode (FIG. 7), it may go into standby and listen to the blockchain peer-to-peer (“P2P”) network (800). The crawler 208 may listen directly to the P2P network through the blockchain protocol, or it may utilize a push API built into the blockchain software (e.g., a ZeroMQ message queue).

[0071] When the crawler 208 discovers a new transaction or a new block (802), the crawler can make an additional request to fetch the raw data from the blockchain (804).

Alternatively, this information may be included in the emitted event itself, in which case there is no need for an additional fetch step. Fetching the raw data may alternatively be achieved through directly querying the P2P network, or through the built-in blockchain API such as JSON-RPC.

[0072] After the crawler fetches all the raw data for the new transaction or all the transactions in a new block, it can decode them into a structured format (806), in the same way it did during the crawl phase 704. Then the crawler 208 can update the database for the blockchain index 207 (808). After this, the crawler 208 can continue to listen for new events.

[0073] Using the crawl mode and the listen mode, the crawler 208 can build a blockchain index 207 that indexes every chunk of blockchain transaction push data as separate query- able attributes (blockchain transactions are collections of sequences of chunks of“push data”). One example of such system is BitDB.

[0074] FIG. 4 shows an example blockchain transaction that may be stored in the blockchain index 207. The database structure in the example of FIG. 4 may be BitDB, but as explained elsewhere herein, other database structures are possible. In this example, the blockchain crawler 208 may read from the blockchain 209 in crawl mode or listen mode, parse each Bitcoin transaction into input scripts and output scripts and each input script and output script into chunks of push data, and store each transaction as a MongoDB® document database collection item. Each item of push data, transaction id, block height, block hash, block time, and various other extracted items may be indexed as attributes. The top-level attributes in FIG. 4 are“tx,”“in,”“out,” and“blk.”“Tx” may represent transaction metadata, including a transaction hash“h” and other attributes.“In” may represent transaction input scripts, including sender data. A transaction may have multiple inputs. Each input may have multiple attributes. The“i” attribute may represent the order of the inputs within the transaction.“bO,”“bl,”“b2,”“b3,” etc., may represent base64 encoded representations of each push data item in a transaction (with the exception of cases in which the push data is not buffer data but an opcode).“sO,”“si,”“s2,” etc. may be UTF8 representations of each push data item.“hO,”“hi,”“h2,” etc. may be hex representations of each push data item. The“in” attribute may also contain a child attribute called“e,” which may in turn have sub-attributes “h,”“I,” and“a.” The“h” sub-attribute may represent the previous transaction hash to which this input is linked. The“i” sub-attribute may refer to the previous transaction index, and the “a” sub-attribute may refer to the address of the previous transaction (i.e., the sender of this transaction).

[0075] The“out” attribute may represent transaction output scripts. Push data may be stored in individual attributes. The“e” attribute may represent outgoing edge information. Outgoing edge information may comprise the quantity of coins to be transferred to the recipient, the transfer condition of the coins, and the like. The amount of coins transferred may be represented by“v,” the receiver address may be represented by“a,” and the“i” attribute may represent the index of the output within the transaction. All of this information can be extracted from a single signed transaction. This is just one example to demonstrate how it is possible to break down a blockchain transaction into small structured pieces and insert them into database systems. There are many other ways of extracting and representing blockchain data and storing them, such as into a graph database, relational database, time series database, key -value database, or the like. And there are many ways to represent each attribute. Also, instead of indexing with a transaction as a unit, the crawler 208 may index the data with a block as a unit. There are many possibilities. Once the transactions are stored into the database in such a structured manner, it may be easy to query them with flexible query languages.

[0076] FIG. 5 shows examples of queries of the blockchain index 207. In this example, assume that blockchain transaction data is stored in a MongoDB® instance as described in reference to FIG. 4. The request filter 205 may run“find” queries using all of the indexed attributes. In the example illustrated in FIG. 5, the queries use a specific query language that wraps a MongoDB® query, but the specific syntax can be ignored.

[0077] Query 500 is a“find” query to the MongoDB®, looking for“in.e.a” that matches a blockchain address“12wqWB2QATXxWzEzQqizkxtrkUoy3nGf6A.” Note that“in” represents input, and“in.e.a” represents the sender address in this example. So this query expression means“find all transactions sent from the address

12wqWB2QATXxWzEzQqizkxtrkUoy3nGf6A.” [0078] Query 502 has additional parameters“out.e.a” means“output address,” and “out.e.v” means“output spend amount.” So this query means“Find all transactions from sender 12wqWB2QATXxWzEzQqizkxtrkUoy3nGf6A and receiver

18x4myKZfFMP379sVwXLpUVDhVneZTJu6K with an amount of 100000.” This type of query may be used by services who provide a one-time purchase for online content. If there is a record of a transaction between the sender and the receiver in the amount of 100000, the request filter 205 may determine that the request is valid and forward the request to the API service 206.

[0079] Query 504 builds upon the query from 502, with an additional attribute“blk.i.” “blk.i” means“block height,” so query 504 specifies that the block height must be greater than 560000. This type of query may be useful for subscription services where the API service provider wants to only serve the response if the sender has made a payment to a certain blockchain address since block X.

[0080] Queries of the blockchain index 207 may not contain sender and recipient information. For example, they may instead specify inclusion or exclusion of certain patterns of push data (each chunk of data in blockchain transactions).

[0081] FIG. 6 illustrates an example in which a blockchain’ s data-embedding feature is utilized to embed a certain pattern of data into a transaction. It uses an opcode called

OP RETURN to embed arbitrary data. By using opcodes that embed arbitrary data into a transaction, it may be possible to create a virtual protocol on top of the blockchain. In FIG.

6, the protocol has a convention that dictates that every transaction that contains an

OP RETURN as the first push data (index 0) and

“19HxigV4QyBv3tHpQVcUEQyqlpzZVdoAut” as the second push data (index 1) be interpreted as a file upload. The output pattern is followed by third push data which is the raw file data to be uploaded, fourth push data specifying to the media type, fifth push data specifying the encoding of the raw data, and sixth push data specifying the filename. This entire sequence may be stored as a transaction and broadcast to the blockchain network. Because the blockchain query engine 202 is able to parse all of these attributes in a structured manner and store them as attributes, the request filter 205 can easily query whether a transaction follows a certain ruleset and filer for transactions that follow the ruleset. The blockchain query engine 202 may interpret incoming transactions and when it detects this exact pattern it may store them in the desired manner (e.g., in a database or file system).

[0082] In this way, the blockchain index 207 can implement a whole new layer of virtual data structure encoded into blockchain transactions. This scheme may be referred to as a “blockchain application protocol.” The blockchain application protocol may enable the request filter 205 to make queries other than sender and recipient-related queries. These queries can be used to determine whether to forward the request coming from client 200 or not. For example, query 506 of FIG. 5 may query for the blockchain application protocol from FIG. 6. The“out.bO” means the first push data of an output, and“out. si” means the second push data of an output in UTF8 encoding. Combining those attributes, this query may be interpreted to mean“Find all transactions sent by

12wqWB2QATXxWzEzQqizkxtrkUoy3nGf6A that contain an output whose first push data has an opcode of 106 (OP RETURN), and whose second push data is

19HxigV4QyBv3tHpQVcUEQyqlpzZVdoAut.” This type of query may be used to filter combinations of blockchain application protocols to determine permission and routing of incoming requests from clients. With this context, the query 506 can be interpreted to mean “check if this address has made any file uploads in the past, along with the rest of the conditions. And only if it passes the test, forward the original request to the API service 206.” As demonstrated, this specific part of the query had nothing to do with transfer of funds, but rather was a query purely about embedded data.

[0083] More sophisticated queries such as“has this address uploaded a file using X protocol in the past, and also made a payment to an address Y, within the time period Z?” are possible. One such query is query 508 of FIG. 5. The query 508 combines all the attributes discussed in previous examples. The query 508 can be interpreted to mean“find transactions sent by the address 12wqWB2QATXxWzEzQqizkxtrkUoy3nGf6A that also contains a data embed output that uploads a file (out.sl is 19HxigV4QyBv3tHpQVcUEQyqlpzZVdoAut), but also has made a payment larger than 100000 after block height 560000.” The request filter 205 can make various queries like this to determine the permission and routing information of the incoming service request from wallet 204. Furthermore, this is just one of the many opcodes provided by various blockchains. Most blockchains have various opcodes and various ways of combining them to create transactions, such as multisig (i.e., multiple people must sign together to make the transaction valid) or time-locked transactions (i.e., the transaction is valid after certain time). So the request filter 205 can be configured to detect the existence of these various transaction types and requests to the API service 206 only when they match a specified pattern. This can provide many flexible ways for the API service providers to monetize their API. [0084] FIG. 10 illustrates examples of how various opcode combinations can express various types of transactions in Bitcoin. All blockchains have low-level opcode mechanisms like Bitcoin, so these examples are applicable to all other blockchains as well.

[0085] Example 1000 is an example of a data embedding transaction that starts with an OP RETURN opcode followed by a combination of arbitrary push data. Example 1002 is an example of a money transfer transaction between two addresses. The“pubKeyHash” is the wallet address. OP_DUP is the first push data, OP HASH160 is the second push data, pubKeyHash is the third push data, OP EQUAL VERIFY is the fourth push data, and OP CHECKSIG is the fifth push data.

[0086] Example 1004 of FIG. 10 is a transaction that is locked until a future time.

Example 1004 follows the same blockchain protocol as the previous examples, so the transaction is made up of inputs and outputs and each input and output contains multiple chunks (push data) which can be decoded by the request filter 205 following the blockchain protocol. The wallet 204 can encapsulate the request from request manager 203 with many different transaction patterns instead of just a single data-embedding transaction with a single signature. When the wallet 204 sends this encoded transaction to the server’s request filter 205, the request filter can decode the entire transaction into multiple inputs and multiple outputs and use all of the decoded pieces of information to query the blockchain query engine 202 in order to decide where to redirect the request.

[0087] In some cases, the sender information determined by the request filter 205 may not be used. The request filter 205 may only be interested in whether the transaction includes a payment, which it can then broadcast to the blockchain network to generate revenue for providing its service to the client 200. To achieve this, the request filter 205 may look at the rest of the outputs in the transaction which specify payment-related details. This can be used to implement conditions such as“If a service request from client 200 is wrapped in a blockchain transaction that also sends me X amount of coins simultaneously, I will forward the request to the API service 206. 1 do not care who sent the request.” Another potential condition is“If the client 200 sends a request that is wrapped in a time locked transaction that sends money to X address at Y time, let this request through.” Or“If the client 200 sends a request that is wrapped in a multisig transaction sent from three addresses A, B, and C, which sends X amount to address D, forward this API request to the API service 206.”

[0088] Because the blockchain query engine 202 is assumed to have indexed every aspect of the blockchain 209 into its blockchain index 207, it may be possible to make such flexible queries to make the decision at request filter 205. The end result is that, since many blockchain opcodes allow for powerful programming of transfer of funds using various combinations of the opcodes, the request filter 205 can decode the service request encapsulated in a blockchain transaction, and provide service only when the wrapper transaction pattern matches the condition it is looking for, such as making payment to the service operator’s blockchain wallet address, or making scheduled transactions in the future, or making multisig transactions (a type of transaction that only goes through when multiple parties sign simultaneously). This can enable service providers to monetize their existing service or content.

[0089] In some embodiments, the client 200 may be a web browser that wraps every HTTP request in a blockchain transaction. Alternatively, the client 200 may be a JavaScript library that wraps HTTP requests in a Bitcoin transaction before sending to the intended server 201. The blockchain transaction may or may not include payment. If it includes payment, the API service 206 may monetize every request. If it does not include a payment, the API service 206 may monetize with a subscription mechanism by querying the blockchain query engine 202, for example to decide if the request sender has made a payment in the last 30 days, or if the request sender has made transactions that match certain precise patterns in the past, or both. This way, the provider of the API service 206 may be able to get rid of its user database and instead implement a blockchain query engine or connect to a public trusted blockchain query engine to parse their user data in real-time, and then implement access control this way. The result is the service provider has a leaner backend system that only stores their content or service. Additionally, the user need not store his credentials because the credentials are stored locally on the wallet in the form of private key and public key pair.

[0090] In some embodiments, the request filter 205 may make multiple queries simultaneously or aggregate or join queries to make the forwarding judgment. The request filter 205 may also implement more sophisticated logic. For example, instead of simply inspecting the address of the signer who sent the transaction, the request filter 205 may look up all transactions that originate from the signer’s address which follow a certain application protocol, which can be queried by specifying the exact sequence of push data attributes in the query. Such a hypothetical application protocol may include a reference to another blockchain wallet address, which may imply that the two addresses are associated according to the application protocol rule. By associating the two addresses, the address used by the wallet 204 to sign transactions can be used to vouch for the other associated wallet address. This way, the client 200 can prove that the user made a payment in the past to the service provider’s wallet address using a different wallet address.

[0091] For example, it may be risky to use a wallet with a lot of money to encapsulate every API request when these transactions are used in a browser context because there may be JavaScript hacking attempts embedded in web pages. To mitigate this problem, the user of the client 200 may use a wallet address that contains only a minimal amount of funds, but also make an application protocol transaction from another address that connects it with the wallet 204’s address. For example, a subscription service may inspect the incoming transaction from the wallet 204, and using the address detected by decoding the transaction, the request filter 205 may make a query to the blockchain index 207 to discover all the application protocol transactions associated with the address. And among those transactions it may find a specific application protocol which is designed to connect two addresses together. The protocol may be an OP RETURN transaction which declares another address associated with the transaction’s signer address. If such a transaction is found, the request filter 205 may make another request to the blockchain index 207 to determine if this other connected address has made a payment to the API service provider’s address in the last 30 days, for example.

[0092] In some embodiments, the wallet 204 may merely sign requests instead of encapsulating them inside a full-fledged blockchain transactions. The wallet 204 may take a request it receives from request manager 203, sign the request with its private key, and send the signature, the original request, and the public key to the server 201. The request filter 205 can verify the authenticity of the request by checking the public key and the original payload against the signature. If they match, the request filer 205 can query the blockchain query engine 202 as previously described in this disclosure. In some cases, the service provider may already have knowledge of the public key (e.g., because the user registered with the service provider prior to making requests to the server). In such a case, the wallet 204 can take the request from the request manager 203, sign the request, and send only the signature and the original request payload, along with other user identifying information such as cookies or authentication tokens. Another difference in this case is that the server 201 may contain a user database as in FIG. 1 to store the public key. In still other cases, the public key may be stored in the blockchain 209 (and thus, the blockchain index 207), completely eliminating the need for a user database on the server 201.

[0093] In some embodiments, the request filter 205 may not have hard coded program logic that determines the routing to API service 206. This routing information itself may be stored as a blockchain transaction prior to the communication between the client 200 and the server 201. For example, the user may have previously made an application protocol transaction that embeds logic that dictates how the request filter 205 may route the future API requests it will make through its client 200. In this case, when the request filter 205 makes a query to the blockchain query engine 202, the result may directly include the routing instructions inside the transaction itself. And the request filter 205 can simply follow that logic to decide which API service 206 to route the request to. Furthermore, the request itself may contain the exact blockchain query to be run by the request filter 205. This way, the request filter 205 may not even require any program logic. It may receive a request from the client 200, which directly contains the blockchain query to be made to the blockchain query engine 202. And when the request filter 205 makes the query, the blockchain query engine 202 can return a result that includes the exact routing information previously stored as another application protocol transaction, which the request filter 205 may interpret to automatically route to a relevant API service 206. Using this method, the request filter 205 of the server 201 may simply act as a proxy.

[0094] In some embodiments, the request encapsulating blockchain transactions may include money transfers. The server 201 may accept the transaction, verify that the pattern is what it is looking for, and then broadcast the transaction to the blockchain network, thereby accepting the payment. Then the request filter 205 may forward the encapsulated request to the corresponding API service 206.

[0095] In one embodiment, the wallet 204 may have not only one private key and public key pair but maintain a deterministic wallet. A deterministic wallet may be a system of cryptographically derived keys from a single starting point known as a seed. The seed may allow a user to easily backup and restore a wallet without needing any other information and can in some cases allow the creation of public addresses without the knowledge of the private key. An example of such a system is the BIP 0032 standard for Hierarchical Deterministic wallets. A powerful property of deterministic wallets is that they may allow the private key holder to share a derived private key or derived public key from its seed without

compromising the keys that exist on a higher level in the hierarchy. Using the deterministic derivation mechanism, the wallet 204 may generate a new key for every request it makes to the server 201, minimizing security risk.

[0096] In some embodiments, the deterministic wallet described above can be combined with the signature-only method. Instead of encapsulating the request inside a blockchain transaction, the wallet 204 can use the private key to merely sign the request and send the signature along with the request. The wallet 204 may only send a public key once in the beginning to the server 201, which the server 201 can store in its user database. Then, all subsequent requests may involve the wallet 204 deriving a next private key from the parent key, signing the request with the new derived private key, and sending it over to the server 201. The request filter 205 of the server 201 can fetch the previously stored public key from the user database, derive the next public key from the stored public key, and verify the incoming signature and the request with the newly derived public key. Since the private key which signed the request this time was deterministically derived cryptographically from the previous private key, and the current public key was derived in the same deterministic way from the previous generation public key, these two private keys and public keys are a match, and the newly derived public key will be able to verify the signature from the new private key. This way, the wallet 204 may only need to send the public key once in the beginning, minimizing security risk. Additionally , the wallet may share a subtree of the entire deterministic wallet, allowing for more fine-grained permission management.

[0097] In some embodiments, the service request may not be HTTP based. For example, while the API service 206 may still be an HTTP endpoint, and the request manager 203 may create an HTTP request and the wallet 204 may wrap it in a blockchain transaction, the wallet 204 may use a different protocol such as WebRTC to send the transaction. In another variation, the wallet 204 and the request filter 205 may communicate over HTTP, but the API service 206 may use other protocols such as WebRTC to respond to the request. Note that any data transfer protocol may be used to transfer the request, since the API request is embedded inside a self-contained blockchain transaction.

[0098] In some embodiments, the request filter 205 may forward not only the original request it has decoded, which originated from the request manager 203, but also the entire transaction constructed from the wallet 204. This way, the request filter 205 may simply act as a routing system. The API service 206 may also implement a request filter 205 of its own which may make another query to the blockchain index 207 to run through yet another filter. This is possible in this scenario because the request filter 205 forwards the entire transaction it received from the wallet 204, instead of only the original request from the request manager 203. For example, the API service 206 and the request filter 205 may be a separate business entity, where the request filter simply acts as the router, and the API service 206 has its own business but plugs into the request filter 205 for service. In this case the owner of the API service 206 may want to take care of the next steps on its own. This may involve

broadcasting the transaction to the network to claim revenue, running another request filter 205 of its own, using the full transaction signed by the wallet 204, or subsequent communication with the client 200 through transaction malleation. Transaction malleation is a blockchain feature which allows multiple parties continually update a single transaction and send it back and forth. By forwarding the entire transaction to the API service provider, this system may allow the API service 206 to malleate the transaction and send it back to the client.

[0099] In one embodiment, the blockchain 209 of FIG. 2 may be replaced by an off chain transaction storage. Instead of the crawler 208 of the blockchain query engine 202 crawling the peer-to-peer blockchain network 209 directly to populate the blockchain index 207, the crawler 208 of FIG. 12 can crawl an off chain blockchain transaction storage 1200 to populate the blockchain index 207. The offchain blockchain transaction storage 1200 may be a storage system that stores a collection of transactions which follow the same protocol of the blockchain network 209, and the transactions stored on the offchain blockchain transaction storagel200 may or may not be on the blockchain 209. The transactions are valid ones following the same blockchain protocol. This may be useful for various scenarios. For example, the service provider for the blockchain query engine 202 may base their permission decision on transactions that have not been broadcasted to the blockchain yet but are still valid and will be broadcast to the blockchain later. As another example, the blockchain query engine 202 may not want to constantly filter every incoming transaction on the blockchain network 209, but instead only store the transactions that matter to them by storing them directly in the offchain blockchain transaction storage 1200. The offchain blockchain transaction storage may be populated in various ways. For example, it may be downloaded from the Internet, or the transactions may be programmatically or manually injected into the storage.

Computer systems

[00100] The present disclosure provides computer systems that are programmed to implement methods of the disclosure. FIG. 11 shows a computer system 1101 that is programmed or otherwise configured to implement the server 201 and the blockchain query engine 202 of FIG. 2, or perform the processes of FIGs. 7-8.

[00101] The computer system 1101 includes a central processing unit (CPU, also “processor” and“computer processor” herein) 1105, which can be a single core or multi core processor, or a plurality of processors for parallel processing. The computer system 1101 also includes memory or memory location 1110 (e.g., random-access memory, read-only memory, flash memory), electronic storage unit 1115 (e.g., hard disk), communication interface 1120 (e.g., network adapter) for communicating with one or more other systems, and peripheral devices 1125, such as cache, other memory, data storage and/or electronic display adapters. The memory 1110, storage unit 1115, interface 1120 and peripheral devices 1125 are in communication with the CPU 1105 through a communication bus (solid lines), such as a motherboard. The storage unit 1115 can be a data storage unit (or data repository) for storing data. The computer system 1101 can be operatively coupled to a computer network (“network”) 1130 with the aid of the communication interface 1120. The network 1130 can be the Internet, an internet and/or extranet, or an intranet and/or extranet that is in communication with the Internet. The network 1130 in some cases is a

telecommunication and/or data network. The network 1130 can include one or more computer servers, which can enable distributed computing, such as cloud computing. The network 1130, in some cases with the aid of the computer system 1101, can implement a peer-to-peer network, which may enable devices coupled to the computer system 1101 to behave as a client or a server.

[00102] The CPU 1105 can execute a sequence of machine-readable instructions, which can be embodied in a program or software. The instructions may be stored in a memory location, such as the memory 1110. The instructions can be directed to the CPU 1105, which can subsequently program or otherwise configure the CPU 1105 to implement methods of the present disclosure. Examples of operations performed by the CPU 1105 can include fetch, decode, execute, and writeback.

[00103] The CPU 1105 can be part of a circuit, such as an integrated circuit. One or more other components of the system 1101 can be included in the circuit. In some cases, the circuit is an application specific integrated circuit (ASIC).

[00104] The storage unit 1115 can store files, such as drivers, libraries and saved programs. The storage unit 1115 can store user data, e.g., user preferences and user programs. The computer system 1101 in some cases can include one or more additional data storage units that are external to the computer system 1101, such as located on a remote server that is in communication with the computer system 1101 through an intranet or the Internet.

[00105] The computer system 1101 can communicate with one or more remote computer systems through the network 1130. For instance, the computer system 1101 can

communicate with a remote computer system of a user (e.g., a computer on which the application 116 is implemented). Examples of remote computer systems include personal computers (e.g., portable PC), slate or tablet PC’s (e.g., Apple® iPad, Samsung® Galaxy Tab), telephones, Smart phones (e.g., Apple® iPhone, Android-enabled device,

Blackberry®), or personal digital assistants. The user can access the computer system 1101 via the network 1130.

[00106] Methods as described herein can be implemented by way of machine (e.g., computer processor) executable code stored on an electronic storage location of the computer system 1101, such as, for example, on the memory 1110 or electronic storage unit 1115. The machine executable or machine-readable code can be provided in the form of software. During use, the code can be executed by the processor 1105. In some cases, the code can be retrieved from the storage unit 1115 and stored on the memory 1110 for ready access by the processor 1105. In some situations, the electronic storage unit 1115 can be precluded, and machine-executable instructions are stored on memory 1110.

[00107] The code can be pre-compiled and configured for use with a machine having a processer adapted to execute the code or can be compiled during runtime. The code can be supplied in a programming language that can be selected to enable the code to execute in a pre-compiled or as-compiled fashion.

[00108] Aspects of the systems and methods provided herein, such as the computer system 1101, can be embodied in programming. Various aspects of the technology may be thought of as“products” or“articles of manufacture” typically in the form of machine (or processor) executable code and/or associated data that is carried on or embodied in a type of machine readable medium. Machine-executable code can be stored on an electronic storage unit, such as memory (e.g., read-only memory, random-access memory, flash memory) or a hard disk. “Storage” type media can include any or all of the tangible memory of the computers, processors or the like, or associated modules thereof, such as various semiconductor memories, tape drives, disk drives and the like, which may provide non-transitory storage at any time for the software programming. All or portions of the software may at times be communicated through the Internet or various other telecommunication networks. Such communications, for example, may enable loading of the software from one computer or processor into another, for example, from a management server or host computer into the computer platform of an application server. Thus, another type of media that may bear the software elements includes optical, electrical and electromagnetic waves, such as used across physical interfaces between local devices, through wired and optical landline networks and over various air-links. The physical elements that carry such waves, such as wired or wireless links, optical links or the like, also may be considered as media bearing the software. As used herein, unless restricted to non-transitory, tangible“storage” media, terms such as computer or machine“readable medium” refer to any medium that participates in providing instructions to a processor for execution.

[00109] Hence, a machine readable medium, such as computer-executable code, may take many forms, including but not limited to, a tangible storage medium, a carrier wave medium or physical transmission medium. Non-volatile storage media include, for example, optical or magnetic disks, such as any of the storage devices in any computer(s) or the like, such as may be used to implement the databases, etc. shown in the drawings. Volatile storage media include dynamic memory, such as main memory of such a computer platform. Tangible transmission media include coaxial cables; copper wire and fiber optics, including the wires that comprise a bus within a computer system. Carrier-wave transmission media may take the form of electric or electromagnetic signals, or acoustic or light waves such as those generated during radio frequency (RF) and infrared (IR) data communications. Common forms of computer-readable media therefore include for example: a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD or DVD- ROM, any other optical medium, punch cards paper tape, any other physical storage medium with patterns of holes, a RAM, a ROM, a PROM and EPROM, a FLASH-EPROM, any other memory chip or cartridge, a carrier wave transporting data or instructions, cables or links transporting such a carrier wave, or any other medium from which a computer may read programming code and/or data. Many of these forms of computer readable media may be involved in carrying one or more sequences of one or more instructions to a processor for execution.

[00110] The computer system 1101 can include or be in communication with an electronic display 1135 that comprises a user interface (EΊ) 1140 for providing, for example, any of the APIs or applications (e.g., application 116) described herein. Examples of UFs include, without limitation, a graphical user interface (GUI) and web-based user interface.

[00111] Methods and systems of the present disclosure can be implemented by way of one or more algorithms. An algorithm can be implemented by way of software upon execution by the central processing unit 1105. The algorithm can, for example, an algorithm that implements a blockchain crawl mode as in FIG. 7 or a blockchain listening mode as in FIG. 8

[00112] While preferred embodiments of the present invention have been shown and described herein, it will be obvious to those skilled in the art that such embodiments are provided by way of example only. It is not intended that the invention be limited by the specific examples provided within the specification. While the invention has been described with reference to the aforementioned specification, the descriptions and illustrations of the embodiments herein are not meant to be construed in a limiting sense. Numerous variations, changes, and substitutions will now occur to those skilled in the art without departing from the invention. Furthermore, it shall be understood that all aspects of the invention are not limited to the specific depictions, configurations or relative proportions set forth herein which depend upon a variety of conditions and variables. It should be understood that various alternatives to the embodiments of the invention described herein may be employed in practicing the invention. It is therefore contemplated that the invention shall also cover any such alternatives, modifications, variations or equivalents. It is intended that the following claims define the scope of the invention and that methods and structures within the scope of these claims and their equivalents be covered thereby.