[go: up one dir, main page]

WO2020257123A1 - Systèmes et procédés d'authentification reposant sur une chaîne de blocs - Google Patents

Systèmes et procédés d'authentification reposant sur une chaîne de blocs Download PDF

Info

Publication number
WO2020257123A1
WO2020257123A1 PCT/US2020/037803 US2020037803W WO2020257123A1 WO 2020257123 A1 WO2020257123 A1 WO 2020257123A1 US 2020037803 W US2020037803 W US 2020037803W WO 2020257123 A1 WO2020257123 A1 WO 2020257123A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
blockchain
transaction
user
web service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/US2020/037803
Other languages
English (en)
Inventor
Changu Kang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Planaria Corp
Original Assignee
Planaria Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Planaria Corp filed Critical Planaria Corp
Publication of WO2020257123A1 publication Critical patent/WO2020257123A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/33—User authentication using certificates
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3297—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • 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.
  • Service providers on the World Wide Web 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.
  • 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.
  • each service provider maintains its own user database.
  • API application programming interface
  • 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”).
  • API application programming interface
  • 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.
  • the blockchain-based authentication system described above may provide advantages over 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.
  • 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.
  • service providers may prefer to not store and secure sensitive user data, instead focusing on their core businesses.
  • 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.
  • 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.
  • the request payload comprises data that identifies the user and the web service.
  • the request payload comprises data corresponding to a financial transaction between the user and the web service.
  • the method further comprises broadcasting the data corresponding to the financial transaction to the blockchain.
  • 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.
  • the query comprises a blockchain block height.
  • the method further comprises, prior to (d), verifying that the digital signature is associated with the user using a public key.
  • the digital signature is generated using a private key associated with the public key.
  • the blockchain transaction comprises the public key.
  • the computer server stores the public key.
  • (c) further comprises obtaining the public key from the indexed database.
  • the private key and the public key have been cryptographically derived from a seed.
  • the indexed database is not operated by the web service.
  • the method further comprises, prior to (b), decoding the blockchain transaction using the blockchain protocol.
  • the method further comprises, upon authenticating the request in (d), routing the request to an application programming interface that implements the web service.
  • the method further comprises, upon not authenticating the request in (d), transmitting a notification to the user indicative of the request not being authenticated.
  • the indexed database is a document database, a relational database, or a graph database.
  • the indexed database is a file system.
  • 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.
  • the request is a Hypertext Transfer Protocol (HTTP) request.
  • HTTP Hypertext Transfer Protocol
  • the transaction data comprises information for routing the request to the web service.
  • the indexed database is constructed by crawling the blockchain.
  • the request payload comprises the query.
  • the condition comprises the transaction data matching a pattern.
  • 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.
  • 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.
  • FIG. 1 schematically illustrates a centralized authentication system
  • FIG. 2 schematically illustrates a blockchain-based authentication system
  • FIG. 3 is a flow chart of an example process for authenticating a request using a blockchain
  • FIG. 4 shows an example blockchain transaction
  • FIG. 5 shows examples of a queries of a blockchain index
  • FIG. 6 shows how data can be embedded in a blockchain transaction
  • FIG. 7 is a flow chart of an example process for crawling a blockchain
  • FIG. 8 is a flow chart of an example process for listening to a blockchain
  • FIG. 9 shows how an HTTP request may be encapsulated in a blockchain transaction
  • FIG. 10 shows a plurality of blockchain transactions that can be used to encapsulate HTTP requests
  • FIG. 11 schematically illustrates a computer system that is programmed or otherwise configured to implement methods provided herein;
  • FIG. 12 schematically illustrates an alternative embodiment of the blockchain- based authentication system of FIG. 2.
  • 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.
  • API application programming interface
  • 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.
  • HTTP Hyper Text Transfer Protocol
  • 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.
  • 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.
  • 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.
  • 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.
  • the service provider that operates the server 101 may prefer to outsource authentication and allocate more memory and processing power to business functions.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • EDSA (“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.
  • 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.
  • the request filter 205 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the computing devices can be several distributed computing devices that are accessible through the Internet. Such computing devices may be considered cloud computing devices.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • the request filter 205 can return an error response to the client 200 (305).
  • FIG. 9 illustrates one example of how an HTTP request payload may be encapsulated in a blockchain transaction.
  • 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.
  • 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.
  • 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).
  • GET request 900
  • POST request a POST request
  • POST request a POST request that uploads a whole file over multipart scheme
  • 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.
  • FIG. 9 describes how the request manager 203 embeds a request in a 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.
  • blockchain wallets create transactions and broadcast those transaction to the blockchain network immediately.
  • 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.
  • 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.
  • 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.
  • BitDB which can break down every aspect of a bitcoin transaction into meaningful pieces and stores them as attributes of a collection.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the crawler 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).
  • the crawler 208 can make an additional request to fetch the raw data from the blockchain (804).
  • 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.
  • the crawler 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.
  • 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”).
  • blockchain transactions are collections of sequences of chunks of“push data”.
  • BitDB BitDB
  • 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.
  • 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.
  • “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“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).
  • 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.
  • 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.
  • FIG. 5 shows examples of queries of the blockchain index 207.
  • the request filter 205 may run“find” queries using all of the indexed attributes.
  • the queries use a specific query language that wraps a MongoDB® query, but the specific syntax can be ignored.
  • 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
  • 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
  • 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.
  • 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.
  • 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).
  • 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
  • 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).
  • 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.
  • 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
  • “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
  • This type of query may be used to filter combinations of blockchain application protocols to determine permission and routing of incoming requests from clients.
  • 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.
  • 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.
  • 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.
  • 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
  • OP CHECKSIG is the fifth push data.
  • 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.
  • 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.
  • 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.
  • 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.”
  • 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.
  • the client 200 may be a web browser that wraps every HTTP request in a blockchain transaction.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the server 201 may contain a user database as in FIG. 1 to store the public key.
  • 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.
  • 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.
  • 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.
  • 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.
  • the request itself may contain the exact blockchain query to be run by the request filter 205.
  • 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.
  • 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.
  • 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
  • the wallet 204 may generate a new key for every request it makes to the server 201, minimizing security risk.
  • the deterministic wallet described above can be combined with the signature-only method.
  • 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.
  • the service request may not be HTTP based.
  • 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.
  • 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.
  • any data transfer protocol may be used to transfer the request, since the API request is embedded inside a self-contained blockchain transaction.
  • 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.
  • 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
  • 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.
  • the blockchain 209 of FIG. 2 may be replaced by an off chain transaction storage.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • the CPU 1105 can be part of a circuit, such as an integrated circuit.
  • a circuit such as an integrated circuit.
  • One or more other components of the system 1101 can be included in the circuit.
  • the circuit is an application specific integrated circuit (ASIC).
  • ASIC application specific integrated circuit
  • 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.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • the computer system 1101 can communicate with one or more remote computer systems through the network 1130.
  • remote computer system of a user
  • a remote computer system of a user e.g., a computer on which the application 116 is implemented.
  • 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.
  • 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.
  • the code can be executed by the processor 1105.
  • the code can be retrieved from the storage unit 1115 and stored on the memory 1110 for ready access by the processor 1105.
  • the electronic storage unit 1115 can be precluded, and machine-executable instructions are stored on memory 1110.
  • 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.
  • aspects of the systems and methods provided herein 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.
  • 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.
  • a machine readable medium such as computer-executable code
  • a tangible storage medium such as computer-executable code
  • 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.
  • RF radio frequency
  • IR infrared
  • 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.
  • 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.
  • E ⁇ user interface
  • Examples of UFs include, without limitation, a graphical user interface (GUI) and web-based user interface.
  • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

La présente invention concerne des systèmes, des procédés et des produits programmes d'ordinateur destinés à authentifier une demande formulée par un utilisateur en vue d'utiliser un service web. Un procédé exemplaire de la présente invention peut comprendre les étapes consistant à : (a) recevoir une transaction de chaîne de blocs au niveau d'un serveur qui fournit le service web, la transaction de chaîne de blocs suivant un protocole d'une chaîne de blocs et comprenant une charge utile de demande ainsi qu'une signature numérique ; (b) générer, en se basant au moins partiellement sur la charge utile de demande, une requête de base de données indexée correspondant à la chaîne de blocs ; (c) obtenir des données de transaction à partir de la base de données indexée à l'aide de la requête ; et (d) authentifier la demande formulée par l'utilisateur en vue d'utiliser le service web si les données de transaction satisfont une condition ou ne pas authentifier la demande formulée par l'utilisateur en vue d'utiliser le service web si les données de transaction ne satisfont pas la condition.
PCT/US2020/037803 2019-06-16 2020-06-15 Systèmes et procédés d'authentification reposant sur une chaîne de blocs Ceased WO2020257123A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201962862086P 2019-06-16 2019-06-16
US62/862,086 2019-06-16

Publications (1)

Publication Number Publication Date
WO2020257123A1 true WO2020257123A1 (fr) 2020-12-24

Family

ID=74040092

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2020/037803 Ceased WO2020257123A1 (fr) 2019-06-16 2020-06-15 Systèmes et procédés d'authentification reposant sur une chaîne de blocs

Country Status (1)

Country Link
WO (1) WO2020257123A1 (fr)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113094395A (zh) * 2021-03-19 2021-07-09 杭州复杂美科技有限公司 数据查询方法、计算机设备和存储介质
CN113239395A (zh) * 2021-05-10 2021-08-10 深圳前海微众银行股份有限公司 数据查询方法、装置、设备、存储介质及程序产品
CN114092292A (zh) * 2021-11-05 2022-02-25 杭州溪塔科技有限公司 一种基于区块链以及去中心化身份的政务处理系统及方法
WO2022255151A1 (fr) * 2021-05-31 2022-12-08 株式会社日立製作所 Système de gestion de données, procédé de gestion de données et support d'enregistrement non transitoire
US20240015030A1 (en) * 2022-07-05 2024-01-11 Shopify Inc. Methods and systems for authorizing transactions based on a derived public key

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170048234A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US20170091756A1 (en) * 2015-07-14 2017-03-30 Fmr Llc Point-to-Point Transaction Guidance Apparatuses, Methods and Systems
US20180083927A1 (en) * 1998-10-30 2018-03-22 Virnetx, Inc. System and method employing an agile network protocol for secure communications using secure domain names
US20180367509A1 (en) * 2004-10-25 2018-12-20 Security First Corp. Secure data parser method and system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20180083927A1 (en) * 1998-10-30 2018-03-22 Virnetx, Inc. System and method employing an agile network protocol for secure communications using secure domain names
US20190166108A1 (en) * 1998-10-30 2019-05-30 Vimetx, Inc. System and method employing an agile network protocol for secure communications using secure domain names
US20180367509A1 (en) * 2004-10-25 2018-12-20 Security First Corp. Secure data parser method and system
US20170048234A1 (en) * 2015-07-14 2017-02-16 Fmr Llc Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US20170091756A1 (en) * 2015-07-14 2017-03-30 Fmr Llc Point-to-Point Transaction Guidance Apparatuses, Methods and Systems

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113094395A (zh) * 2021-03-19 2021-07-09 杭州复杂美科技有限公司 数据查询方法、计算机设备和存储介质
CN113239395A (zh) * 2021-05-10 2021-08-10 深圳前海微众银行股份有限公司 数据查询方法、装置、设备、存储介质及程序产品
WO2022255151A1 (fr) * 2021-05-31 2022-12-08 株式会社日立製作所 Système de gestion de données, procédé de gestion de données et support d'enregistrement non transitoire
JP2022183562A (ja) * 2021-05-31 2022-12-13 株式会社日立製作所 データ管理システム、データ管理方法、及びデータ管理プログラム
JP7565868B2 (ja) 2021-05-31 2024-10-11 株式会社日立製作所 データ管理システム、データ管理方法、及びデータ管理プログラム
CN114092292A (zh) * 2021-11-05 2022-02-25 杭州溪塔科技有限公司 一种基于区块链以及去中心化身份的政务处理系统及方法
US20240015030A1 (en) * 2022-07-05 2024-01-11 Shopify Inc. Methods and systems for authorizing transactions based on a derived public key
US12088736B2 (en) * 2022-07-05 2024-09-10 Shopify Inc. Methods and systems for authorizing transactions based on a derived public key

Similar Documents

Publication Publication Date Title
US10574770B2 (en) Managing notifications across multiple devices
WO2020257123A1 (fr) Systèmes et procédés d'authentification reposant sur une chaîne de blocs
CN111373400A (zh) 用于实现用于去中心化标识的解析器服务的系统和方法
CN111213128A (zh) 实现基于区块链的web服务
CN113271311B (zh) 一种跨链网络中的数字身份管理方法及系统
WO2020142603A1 (fr) Identité hybride en tant que service pour portefeuilles basés sur un navigateur décentralisé
CN113422733B (zh) 区块链的业务处理方法、装置、计算机设备及存储介质
US12267436B2 (en) Data protection on distributed data storage (DDS) protection networks
US12278804B2 (en) Systems and methods for generating secure, encrypted communications using multi-party computations in order to perform blockchain operations in decentralized applications
US12306983B2 (en) Systems and methods for using secure, encrypted communications across distributed computer networks to provide variable resiliency when indexing blockchain states for performing blockchain operations in decentralized applications using cryptography-based digital repositories
JP2018152893A (ja) ネットワーク・ベースのストレージの内部のファイルのセキュリティ保護された転送
US12256027B2 (en) Systems and methods for performing two-tiered multi-party computation signing procedures to perform blockchain operations
US12244743B2 (en) Systems and methods for performing blockchain operations using multi-party computation cohort management groupings
CN111984616B (zh) 一种更新共享文件的方法、装置和系统
CN115118426A (zh) 区块链系统的数据处理方法、装置、设备及存储介质
US12079183B2 (en) Systems and methods for a stateless blockchain overlay layer
CN115829692A (zh) 基于区块链的产品推荐方法、装置及系统
WO2021216612A1 (fr) Journal de réponse api de chaîne de blocs
AU2023254054B2 (en) Data protection on distributed data storage (dds) protection networks
CN111984613A (zh) 一种共享文件的方法、装置和系统
US11757985B1 (en) Systems and methods for a blockchain interoperability platform
HK40032709B (zh) 用於实现用於去中心化标识的解析器服务的系统和方法
CN118540696A (zh) 一种数据传输方法及相关装置
HK40028814B (zh) 用於创建去中心化标识的系统和方法
HK40029520B (zh) 用於验证可验证声明的系统和方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 20826897

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 01/04/2022)

122 Ep: pct application non-entry in european phase

Ref document number: 20826897

Country of ref document: EP

Kind code of ref document: A1