Information management in distributed databases including fast path services

Abstract

Example operations may include one or more of: determining that data at a first node satisfies a condition, obtaining a pointer to a shared storage area for the data, controlling generation of a block including the pointer, and appending the block to a blockchain without the data, wherein the first node corresponds to a first virtual node hosted by a blockchain as a service (Baas) provider, and wherein the first virtual node receives the data from a network coupled to the Baas provider.

Description

Technical Field

[0001] The present application relates generally to database storage systems and, more particularly, to information management in a distributed database including fast path services. Background Art

[0002] A centralized database stores and maintains data in a single database (e.g., a database server) located in one location. This location is typically a central computer, such as a desktop central processing unit (CPU), a server CPU, or a mainframe computer. Information stored in a centralized database can usually be accessed from multiple different points. For example, based on a client / server configuration, multiple users or client workstations can work on a centralized database simultaneously. A centralized database is easy to manage, maintain, and control, especially for security purposes, because it is located in a single location. In a centralized database, data redundancy is minimized because a single storage location for all data also implies that a given set of data has only one master record.

[0003] However, centralized databases suffer from significant drawbacks. For example, centralized databases need to be operated by a universally trusted entity. In addition, centralized databases have a single point of failure. In particular, if there is no consideration of fault tolerance and a hardware failure (e.g., hardware, firmware, and / or software failure) occurs, all data in the database will be lost and the work of all users will be interrupted. In addition, centralized databases are highly dependent on network connections. As a result, the slower the connection, the amount of time required for each database access will increase. Another disadvantage is that when the centralized database encounters high traffic due to a single location, a bottleneck will occur. In addition, since the database maintains only one copy of the data, the centralized database provides limited access to the data. As a result, multiple devices cannot access the same data at the same time without causing serious problems or creating the risk of overwriting the stored data. In addition, since the database storage system has little or no data redundancy, it is difficult to recover accidentally lost data except by restoring from backup storage through manual operations. Summary of the invention

[0004] An example embodiment provides a system including a blockchain as a service (Baas) provider and a first virtual node hosted by the Baas provider. The Baas provider includes a manager for determining that data at the first virtual node satisfies a condition, obtaining a pointer to a shared storage area where the data is to be stored, controlling the generation of a block including the pointer, and attaching the block to a blockchain without the data. The condition may be whether the data exceeds a predetermined size. The first virtual node includes blockchain software that receives the data from a blockchain application in the same node or outside the Baas provider. A second virtual node may receive the pointer for accessing data at a shared file location. The second virtual node may receive the pointer, for example, by querying the blockchain for a block storing the pointer or based on information transmitted within the Baas provider.

[0005] Another example embodiment provides a method comprising one or more of the following: determining that data at a first node satisfies a condition, obtaining a pointer to a shared storage area for the data, controlling the generation of a block including the pointer, and attaching the block to a blockchain without the data. The first node corresponds to a first virtual node hosted by a blockchain as a service (Baas) provider, and the first virtual node receives the data from a network coupled to the Baas provider. The condition may be whether the data exceeds a predetermined size. The first virtual node includes blockchain software that receives the data from a blockchain application in the same node or outside the Baas provider. The second virtual node may receive the pointer for accessing the data at a shared file location. The second virtual node may receive the pointer, for example, by querying the blockchain for a block storing the pointer or based on information transmitted within the Baas provider.

[0006] Another example embodiment provides a non-transitory computer-readable medium including instructions, which, when read by a manager of a blockchain as a service (Baas) provider, causes the manager to perform one or more of the following: determining that data received by a first virtual node hosted by the Baas provider satisfies a condition, obtaining a pointer to a shared storage area where the data is to be stored, controlling the generation of a block including the pointer, and adding the block to a blockchain without the data.

[0007] Another example embodiment provides a system comprising a first virtual node, a second virtual node, and a manager for controlling the transmission of information between the first virtual node and the second virtual node. The first and second virtual nodes are hosted by a blockchain as a service (Baas) provider. The information is transmitted along an internal signal path of the Baas provider and corresponds to a block in the blockchain that includes entries for the first and second virtual nodes. The Baas provider may include a first server and a second server, wherein the first server manages the first virtual node and the second server manages the second virtual node.

[0008] Another example embodiment provides a method comprising one or more of: hosting a first virtual node in a blockchain as a service (Baas) provider; hosting a second virtual node in the Baas provider; and controlling transmission of information between the first virtual node and the second virtual node along an internal signal path of the Baas provider. The information corresponds to a block in a blockchain that includes entries for the first and second virtual nodes. The Baas provider may include a first server and a second server, wherein the first server manages the first virtual node and the second server manages the second virtual node.

[0009] Another example embodiment provides a non-transitory computer-readable medium including instructions that, when read by logic of a blockchain as a service (Baas) provider, cause the logic to perform one or more of: hosting a first virtual node in the Baas provider, hosting a second virtual node in the Baas provider, and controlling transmission of information between the first virtual node and the second virtual node on an internal signal path of the Baas provider, wherein the information corresponds to a block in a blockchain including entries of the first and second virtual nodes. The Baas provider may include a first server and a second server, wherein the first server manages the first virtual node and the second server manages the second virtual node.

[0010] Another example embodiment provides a system, the system includes a first queue, a second queue, and a manager of a blockchain as a service (Baas) provider. When a first set of policies is satisfied, the manager controls placing entries into the first queue, and when the first set of policies is not satisfied, the manager controls placing entries into the second queue. The first queue is used to store confirmed entries that will be submitted for consensus without validation; the second queue is used to store pending entries that require validation before consensus.

[0011] Another example embodiment provides a method, the method comprising one or more of the following: receiving an entry at a blockchain as a service (Baas) provider, determining whether the entry satisfies a first set of policies, and when the first set of policies is satisfied, controlling to place the entry into a first queue, and when the first set of policies is not satisfied, controlling to place the entry into a second queue. The first queue stores confirmed entries to be submitted for consensus without validation; the second queue stores pending entries that require validation before consensus.

[0012] Another example embodiment provides a non-transitory computer-readable medium including instructions, which when read by a manager of a blockchain as a service (Baas) provider, causes the manager to perform one or more of the following: receiving an entry, determining whether the entry satisfies a first set of policies, controlling the entry to be placed in a first queue when the first set of policies is satisfied, and controlling the entry to be placed in a second queue when the first set of policies is not satisfied. The first queue stores confirmed entries to be submitted for consensus without validation, and the second queue stores pending entries that require validation before consensus. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 An embodiment of a blockchain architecture configuration is shown.

[0014] Figure 2 An embodiment illustrating transaction flow between nodes of a blockchain.

[0015] Figure 3 An example of a permissioned blockchain network is shown.

[0016] Figure 4 An embodiment of message passing in a blockchain network is shown.

[0017] Figure 5 An embodiment of a system for performing operations in a blockchain is shown.

[0018] Figure 6 Another embodiment of a system for performing operations in a blockchain is shown.

[0019] Figure 7 An embodiment of a smart contract configuration for a blockchain is shown.

[0020] Figure 8 An embodiment of an application programming interface (API) gateway for accessing a blockchain and / or associated elements is shown.

[0021] Fig. 9A An embodiment of a process for adding a new block to a distributed ledger of a blockchain is shown, Fig. 9B Showing an example of a block structure for a blockchain.

[0022] Fig.10 An embodiment of a compute node is shown.

[0023] Fig.11 An example of a blockchain network is shown.

[0024] Fig.12 An example showing the process of adding a new block to a blockchain.

[0025] Fig.13 A Blockchain as a Service (Baas) embodiment is shown.

[0026] Fig.14 A Baas provider including a fast path service is shown.

[0027] Fig.15 A fast path service according to an embodiment is shown.

[0028] Fig.16 A fast path service according to an embodiment is shown.

[0029] Fig.17 A fast path service according to an embodiment is shown.

[0030] Fig.18 A fast path service according to an embodiment is shown.

[0031] Fig.19 A fast path service according to an embodiment is shown.

[0032] Fig. 20 A fast path service according to an embodiment is shown.

[0033] Fig.21 A fast path service according to an embodiment is shown. DETAILED DESCRIPTION

[0034] It is readily understood that the example components as generally described and illustrated in the figures herein may be arranged and designed in a variety of different configurations. Therefore, the following detailed description of embodiments of at least one of the methods, devices, non-transitory computer-readable media, and systems as shown in the figures is not intended to limit the scope of the claimed application, but is merely representative of selected embodiments.

[0035] The example features, structures, or characteristics described throughout this specification may be combined in any suitable manner in one or more embodiments. For example, throughout this specification, the use of the phrases "example embodiments," "some embodiments," or other similar language refers to the fact that a particular feature, structure, or characteristic described in conjunction with that embodiment may be included in at least one embodiment. Thus, the phrases "example embodiments," "some embodiments," "in other embodiments," or other similar language appearing throughout this specification do not necessarily refer to the same set of embodiments, and the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0036] In addition, although the term "message" may have been used in the description of the embodiments, the present application is applicable to many types of network data, such as packets, frames, datagrams, etc. The term "message" also includes packets, frames, datagrams, and their equivalents. In addition, although certain types of messages and signaling may be depicted in exemplary embodiments, they are not limited to specific types of messages, and the present application is not limited to specific types of signaling.

[0037] A decentralized database (e.g., blockchain) is a distributed storage system that includes multiple nodes that communicate with each other. Blockchain is an example of a decentralized database that includes an append-only, non-tamperable data structure similar to a distributed ledger that can maintain records between mutually untrusted parties. Untrusted parties are referred to as peers or peer nodes in this article. Each peer maintains a copy of the database record, and no single peer can modify the database record without reaching a consensus between the distributed peers. For example, peers can execute a consensus protocol to validate blockchain storage transactions, group storage transactions into blocks, and build hash chains on these blocks. In order to maintain consistency, this process forms an account book by sorting storage transactions. In a public or permissionless blockchain, anyone can participate without a specific identity. Public blockchains typically involve native cryptocurrencies and use consensus based on various protocols (e.g., proof of work (PoW)). On the other hand, permissioned blockchain databases provide a system of guaranteed interactions between a group of entities that share a common goal but do not fully trust each other (e.g. businesses exchanging funds, goods, information, etc.).

[0038] Blockchain operations are arbitrary programmable logic tailored for decentralized storage solutions and called "smart contracts" or "chaincodes". In some cases, there may be dedicated chaincodes for managing functions and parameters, which are called system chaincodes. Smart contracts are trusted distributed applications that take advantage of the tamper-proof properties of the blockchain database and a basic protocol between nodes called endorsements or endorsement policies. In general, blockchain transactions must usually be "endorsed" before being committed to the blockchain, while unendorsed transactions are ignored. Typical endorsement policies allow chaincodes to specify endorsers of transactions in the form of a set of peer nodes for endorsement. When a client sends a transaction to the peers specified in the endorsement policy, the transaction is executed to make the transaction effective. After effectiveness, the transaction enters the sorting phase, in which a consensus protocol is used to generate an ordered sequence of endorsed transactions grouped into blocks.

[0039] A node is a communication entity in a blockchain system. A "node" can perform a logical function in the sense that multiple nodes of different types can run on the same physical server. Nodes are grouped in trust domains and are associated with logical entities that control them in various ways. Nodes may include different types, such as client or submission client nodes, which submit transaction calls to endorsers (e.g., peers) and broadcast transaction proposals to the sorting service (e.g., sorting nodes). Another type of node is a peer node, which can receive transactions submitted by clients, submit transactions, and maintain the state and copy of the ledger of blockchain transactions. Peers can also play the role of endorsers, although this is not required. The sorting service node or sorter is a node that runs a communication service for all nodes, and the node implements delivery guarantees, such as broadcasts to each peer node in the system when submitting transactions and modifying the world state of the blockchain, which is another name for the initial blockchain transaction, which typically includes control and setup information.

[0040] The ledger is an ordered, tamper-proof record of all state transitions of the blockchain. State transitions can be generated by chaincode invocations (i.e., transactions) submitted by participating parties (e.g., client nodes, sorting nodes, endorser nodes, peer nodes, etc.). Transactions can result in a set of asset key-value pairs being submitted to the ledger as one or more operands, such as create, update, delete, etc. The ledger includes a blockchain (also called a chain), which is used to store an unalterable, ordered record in units of blocks. The ledger also includes a state database, which maintains the current state of the blockchain. Each channel typically has one ledger. Each peer node maintains a copy of the ledger for each channel it belongs to.

[0041] A chain is a transaction log that is structured as hash-linked blocks, and each block contains a sequence of N transactions, where N is equal to or greater than 1. The block header includes the hash of the transactions of the block, as well as the hash of the header of the previous block. In this way, all transactions on the ledger can be ordered and cryptographically linked together. Therefore, it is impossible to tamper with the ledger data without breaking the hash link. The hash of the most recently added blockchain block represents every transaction on the chain before it, so that all peer nodes can be ensured to be in a consistent and trusted state. The chain can be stored on the peer node file system (i.e., local, attached storage, cloud, etc.), effectively supporting the append-only nature of blockchain workloads.

[0042] The current state of the immutable ledger represents the latest values ​​of all keys included in the chain transaction log. Because the current state represents the latest key values ​​known to the channel, it is sometimes called the world state. Chaincode calls execute transactions against the current state data of the ledger. In order for these chaincode interactions to be effective, the latest values ​​of the keys can be stored in the state database. The state database can be just an indexed view of the chain's transaction log, so it can be regenerated from the chain at any time. The state database can be automatically restored (or generated if needed) after the peer node starts and before accepting transactions.

[0043] Blockchain differs from traditional databases in that blockchain is not a central storage, but a decentralized, immutable and secure storage where nodes must share changes to the records in the storage. Some properties inherent to and contributing to blockchain include but are not limited to immutable ledgers, smart contracts, security, privacy, decentralization, consensus, endorsement, accessibility, etc., which will be further described in this article.

[0044] Figure 1 A blockchain architecture configuration 100 is shown according to an example embodiment. Figure 1, the blockchain architecture 100 may include certain blockchain elements, for example, a set of blockchain nodes 102. The blockchain nodes 102 may include one or more nodes 104-110 (only four nodes are described by way of example). These nodes participate in multiple activities, such as blockchain transaction addition and validation processes (consensus). One or more of the blockchain nodes 104-110 may endorse transactions based on endorsement policies and may provide ordering services for all blockchain nodes in the architecture 100. The blockchain node may initiate blockchain authentication and seek to write to the blockchain immutable ledger stored in the blockchain layer 116, a copy of which may also be stored on the underlying physical infrastructure 114. The blockchain configuration may include one or more applications 124 that are linked to an application programming interface (API) 122 to access and execute stored program / application code 120 (e.g., chain code, smart contracts, etc.), which may be created according to the customized configuration sought by the participants and may maintain their own state, control their own assets, and receive external information. This may be deployed as a transaction and installed on all blockchain nodes 104-110 by attaching to the distributed ledger.

[0045] The blockchain foundation or platform 112 may include various layers of blockchain data, services (e.g., cryptographic trust services, virtual execution environments, etc.), and an underlying physical computer infrastructure that may be used to receive and store new transactions and provide access to auditors seeking access to data entries. The blockchain layer 116 may expose an interface that provides access to the virtual execution environment to process program code and engage the physical infrastructure 114. Cryptographic trust services 118 may be used to verify transactions such as asset exchange transactions and keep the information private.

[0046] Figure 1The blockchain architecture configuration of the blockchain platform 112 can process and execute program / application code 120 via one or more interfaces exposed by the blockchain platform 112 and services provided by the blockchain platform 112. The code 120 can control blockchain assets. For example, the code 120 can store and transmit data and can be executed by the nodes 104-110 in the form of smart contracts and chain codes associated with conditions or other code elements executed therewith. As a non-limiting example, smart contracts can be created to perform reminders, updates, and / or other notifications of changes, updates, etc. The smart contracts themselves can be used to identify rules associated with authorization and access requirements and the use of the ledger. For example, the information 126 may include data, metadata, key information, messages, events, or other information that can be processed by one or more processing entities (e.g., virtual machines) included in the blockchain layer 116. The results 128 may include accessing, querying, adding one or more new blocks to the blockchain, and then updating and outputting the blockchain ledger to the node. The physical infrastructure 114 can be used to obtain any data or information described herein.

[0047] Within chaincode, smart contracts can be created via high-level applications and programming languages, and then written to blocks in a blockchain. A smart contract may include executable code that is registered, stored, and / or replicated with a blockchain (e.g., a distributed network of blockchain peers). A transaction is the execution of smart contract code, which may be executed in response to a condition associated with the smart contract being satisfied. The execution of a smart contract may trigger a trusted modification to the state of a digital blockchain ledger. Modifications to the blockchain ledger resulting from the execution of a smart contract may be automatically replicated throughout a distributed network of blockchain peers via one or more consensus protocols.

[0048] Smart contracts can write data to the blockchain in the format of key-value pairs. In addition, smart contract code can read values ​​stored in the blockchain and use them in application operations. Smart contract code can write the output of various logical operations to the blockchain. The code can be used to create temporary data structures in a virtual machine or other computing platform. The data written to the blockchain can be public and / or can be encrypted and maintained as private. Temporary data used / generated by the smart contract is saved in memory by the provided execution environment and then deleted after the data required by the blockchain is identified.

[0049] The chaincode may include a code interpretation of a smart contract with additional features. As described herein, a chaincode may be a program code deployed on a computing network where it is executed and validated by chain validators together during a consensus process. The chaincode receives a hash and fetches a hash from the blockchain associated with a data template created by using a previously stored feature extractor. If the hash of the hashed identifier and the hash created from the stored identifier template data match, the chaincode sends an authorization key to the requested service. The chaincode may write blockchain data associated with encryption details.

[0050] Figure 2 An example of a transaction flow 250 between nodes of a blockchain according to an example embodiment is shown. Figure 2 , the transaction flow may include a transaction proposal 291 sent by the application client node 260 to the endorsing peer node 281. The endorsing peer 281 may verify the client signature and execute the chaincode function to initiate the transaction. The output may include a chaincode result, a set of key / value versions read in the chaincode (read set), and a set of key / values ​​written to the chaincode (write set). If the transaction proposal is approved, the proposal response 292 is sent back to the client 260 along with the endorsement signature. The client 260 assembles the endorsement into a transaction payload 293 and broadcasts it to the sorting service node 284. The sorting service node 284 then delivers the sorted transaction as a block to all peers 281-283 on the channel. Each peer 281-283 may validate the transaction before committing to the blockchain. For example, a peer may check the endorsement policy to ensure that the correct allocation of the specified peer has signed the result and authenticated the signature for the transaction payload 293.

[0051] Reference again Figure 2 , the client node 260 initiates a transaction 291 by constructing and sending a request to the peer node 281 as an endorser. The client 260 may include an application utilizing a supported software development kit (SDK) such as NODE, JAVA, PYTHON, etc., which utilizes the available API to generate a transaction proposal. The proposal is a request to invoke a chaincode function so that data can be read and / or written to the ledger (i.e., write a new key-value pair for an asset). The SDK can be used as a shim to package the transaction proposal into an appropriate architecture format (e.g., protocol buffers over remote procedure calls (RPCs)) and obtain the client's cryptographic certificate to generate a unique signature for the transaction proposal.

[0052] In response, the endorsing peer 281 may verify that: (a) the transaction proposal is well-formed, (b) no transaction has been submitted in the past (replay-attack protection), (c) the signature is valid, and (d) the submitter (client 260 in this example) is properly authorized to perform the proposed operation on the channel. The endorsing peer 281 may input the transaction proposal as a parameter to the invoked chaincode function. The chaincode is then executed against the current state database to produce a transaction result including a response value, a read set, and a write set. However, no updates are made to the ledger at this time. In 292, this set of values ​​is passed back to the SDK of the client 260 along with the signature of the endorsing peer 281 as a proposal response 292, which parses the payload for use by the application.

[0053] In response, the client 260 application checks / verifies the signature of the endorsing peer and compares the proposal response to determine if the proposal responses are the same. If the chaincode only queries the ledger, the application will check the query response and generally will not submit the transaction to the sorting node service 284. If the client application intends to submit the transaction to the sorting node service 284 to update the ledger, the application determines whether the endorsement policy specified before submission has been satisfied (e.g., whether all peer nodes required for the transaction endorse the transaction). Here, the client may include only one of the multiple parties to the transaction. In this case, each client may have its own endorsing node, and each endorsing node needs to endorse the transaction. The architecture enables the endorsement policy to be enforced by the peer and maintained during the commit validation phase even if the application chooses not to check the response or otherwise forward an unendorsed transaction.

[0054] After successful checks, in step 293, client 260 assembles the endorsement into a transaction and broadcasts the transaction proposal and response within the transaction message to ordering node 284. The transaction may contain a read / write set, an endorsing peer signature, and a channel ID. Ordering node 284 does not need to examine the entire contents of the transaction in order to perform its operations, but rather ordering node 284 may simply receive transactions from all channels in the network, sort them by channel in chronological order, and create a transaction block by channel.

[0055] The transaction block is passed from the ordering node 284 to all peer nodes 281-283 on the channel. Transactions 294 within the block are validated to ensure that any endorsement policies are satisfied and that there is no change in the ledger state of the read set variables, as the read set is generated by the transaction execution. The transactions in the block are marked as valid or invalid. In addition, in step 295, each peer node 281-283 appends the block to the channel's chain and, for each valid transaction, commits the write set to the current state database. Events are emitted to notify the client application that the transaction (call) has been immutably attached to the chain, and whether the transaction has been validated or invalidated.

[0056] Figure 3 An example of a permissioned blockchain network 300 is shown, which features a distributed, decentralized peer-to-peer architecture, and a certificate authority 318 that manages user roles and permissions. In this example, a blockchain user 302 can submit transactions to a permissioned blockchain network 310. In this example, the transaction can be a deployment, call, or query, and can be issued directly through a REST API or the like through a client-side application utilizing an SDK. The trusted enterprise network can provide access to a regulator system 314 such as an auditor (e.g., the Securities and Exchange Commission in the U.S. securities market). At the same time, the blockchain network operator system 308 of the node manages member permissions, such as registering the regulator system 310 as an "auditor" and registering the blockchain user 302 as a "client." Auditors can be limited to querying the ledger, while clients can be authorized to deploy, call, and query specific types of chaincodes.

[0057] The blockchain developer system 316 can write chaincodes and client-side applications. The blockchain developer system 316 can deploy chaincodes directly to the network through a REST interface. In order to include certificates from traditional data sources 330 in the chaincode, the developer system 316 can use an out-of-band connection to access the data. In this example, the blockchain user 302 is connected to the blockchain network processor 332 through the peer node 312. Before proceeding with any transactions, the peer node 312 obtains the user's registration and transaction certificates from the certificate authority 318. In some cases, blockchain users must have these digital certificates in order to conduct transactions on the permissioned blockchain network 310. At the same time, users attempting to drive chaincodes may be required to verify their certificates on the traditional data source 330. In order to confirm the user's authorization, the chaincode can use an out-of-band connection to the data through the traditional processing platform 320.

[0058] Figure 4An embodiment of messaging 400 is shown, which may occur between participants or entities / users 410 and 420 of a blockchain network and a blockchain 430. At 412, entity 410 stores a new asset to be added to a block of blockchain 430 (e.g., a form of evidence that is protected by the blockchain). The transaction payload is then released to blockchain 430 at 413. The smart contract published with the world state of the blockchain is then stored at 416. The acquisition of the smart contract from the world state is then implemented at 418. The certificate of entity 2 is then verified at 422, and a check is performed at 423 to verify that the expiration date of the certificate that has not expired is still valid, for example. Then, access to the blockchain network or other action attempted by entity 2 is granted at 426, and the asset requested by entity 2 (e.g., evidence) is then obtained from the blockchain network at 428 and made accessible to entity 2. The messaging operations may be performed, for example, in association with a processor or management entity / software of the blockchain network through one or more appropriate interfaces.

[0059] Figure 5 An embodiment of a system 500 is shown, which includes a physical infrastructure 510 configured to perform various operations on a blockchain. The physical infrastructure 510 includes a module 512 and a module 514. The module 514 includes a blockchain 520 and a smart contract 530 (which may reside on the blockchain 520), which may perform any operation 508 (in the module 512) included in any example embodiment. The operation 508 may include one or more of the embodiments described or depicted, and may represent output or written information written or read from one or more smart contracts 530 and / or blockchain 520. The physical infrastructure 510, the module 512, and the module 514 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, the module 512 and the module 514 may be the same module.

[0060] Figure 6 Another system 600 configured to perform various operations according to an example embodiment is shown. Figure 6, system 600 includes module 612 and module 614. Module 614 includes blockchain 620 and smart contract 630 (which may reside on blockchain 620), which may perform any of the operation steps in operation step 608 (in module 612) included in any example embodiment. Operation 608 may include one or more of the embodiments described or depicted, and may represent output or written information written or read from one or more smart contracts 630 and / or blockchain 620. Physical infrastructure 610, module 612, and module 614 may include one or more computers, servers, processors, memories, and / or wireless communication devices. In addition, module 612 and module 614 may be the same module.

[0061] Figure 7 An embodiment of a smart contract configuration 750 between parties and an intermediary server configured to implement smart contract rules / terms on a blockchain is shown. Configuration 750 may represent a communication session, an asset transfer session, or a process or procedure driven by a smart contract 730 that explicitly identifies one or more user devices 752 and / or 756. Execution, operations, and results in smart contract execution may be managed by a server 754. The content of the smart contract 730 may require digital signatures by one or more of the entities 752 and 756 that are parties to the smart contract transaction. The results of the smart contract execution may be written to the blockchain 720 as a blockchain transaction. The smart contract 730 resides on the blockchain 720, which may reside on one or more computers, servers, processors, memories, and / or wireless communication devices. The blockchain 720 may include digital evidence as discussed herein.

[0062] Figure 8 A system 860 is shown that includes an application programming interface (API) gateway 862 that provides a public interface for accessing blockchain logic (e.g., smart contracts 830 or other chaincodes) and data (e.g., distributed ledgers, etc.). In this example, the API gateway 862 is a public interface for executing transactions (calls, queries, etc.) on the blockchain by connecting one or more entities 852 and 856 to blockchain peers (e.g., server 854). The server 854 can be a blockchain network peer component that holds a copy of the world state and the distributed ledger, allowing clients 852 and 856 to query data about the world state and submit transactions to the blockchain network, where, depending on the smart contract 830 and the endorsement policy, the endorsing peer will run the smart contract 830. Figure 5-8The smart contracts shown in the examples may be the same or different. In one embodiment, each participant in the blockchain network may store a copy of the distributed ledger and blockchain with an immutable history of all transactions on the blockchain that have occurred in the network.

[0063] The embodiments described herein may be implemented in hardware, in a computer program executed by a processor, in firmware, or a combination thereof. The computer program may be embodied on a computer-readable medium, such as a storage medium. For example, the computer program may reside in a random access memory ("RAM"), flash memory, read-only memory ("ROM"), erasable programmable read-only memory ("EPROM"), electrically erasable programmable read-only memory ("EEPROM"), registers, a hard disk, a removable disk, a compact disk read-only memory ("CD-ROM"), or any other form of storage medium.

[0064] An exemplary storage medium may be coupled to a processor so that the processor can read information from and write information to the storage medium. In one embodiment, the storage medium may be an integral part of the processor. The processor and the storage medium may reside in an application specific integrated circuit ("ASIC"). In one embodiment, the processor and the storage medium may reside as discrete components.

[0065] Fig. 9A An embodiment of a process 900 for adding a new block to a distributed ledger 930 of a blockchain is shown, Fig. 9B An example of a block structure 950 for a blockchain is shown.

[0066] refer to Fig. 9A , a client may submit a transaction to blockchain nodes 921, 922, and / or 923. A client may be an instruction received from any source to enact an activity on blockchain 930. As an example, a client may be an application acting on behalf of a requester, such as a device, person, or entity that proposes a transaction for a blockchain. Multiple blockchain peers (e.g., blockchain nodes 921, 922, and 923) may maintain the state of a blockchain network and a copy of a distributed ledger 930. Different types of blockchain nodes / peers may exist in a blockchain network, including endorsement peers and submission peers, where endorsement peers simulate and endorse transactions proposed by clients, and submission peers verify endorsements, make transactions valid, and submit transactions to distributed ledger 930. In this example, blockchain nodes 921, 922, and 923 may act as endorser nodes, submitter nodes, or both.

[0067] The distributed ledger 930 includes a blockchain 932 that stores an unalterable, ordered record in units of blocks, and a state database 934 (current world state) that maintains the current state of the blockchain 932. There may be one distributed ledger 930 per channel, and each peer maintains its own copy of the distributed ledger 930 for each channel of which they are a member. The blockchain 932 is a transaction log structured as hash-linked blocks, where each block includes a sequence of N transactions. A block may include various components, such as Fig. 9B As shown. The link of the block can be generated by adding the hash of the previous block header in the header of the current block. In this way, all transactions on the blockchain 932 are ordered and cryptographically linked together to prevent tampering of the blockchain data without breaking the hash link. In addition, due to the link, the latest block in the blockchain 932 represents every transaction before it. The blockchain 932 can be stored on a peer-to-peer file system (local or attached storage) that supports append-only blockchain workloads.

[0068] The current state of the blockchain 932 and the distributed ledger 932 may be stored in the state database 934. The current state data may, for example, represent the latest values ​​of all keys ever included in the chain transaction log of the blockchain 932. Chaincode invocations execute transactions against the current state in the state database 934. In order to make these chaincode interactions very efficient, the latest values ​​of all keys are stored in the state database 934. The state database 934 may include an indexed view into the transaction log of the blockchain 932, so the state database 934 can be regenerated from the chain at any time. The state database 934 may be automatically restored (or generated when needed) before a transaction is accepted, for example, at peer startup.

[0069] The endorsing node receives the transaction from the client and endorses the transaction based on the simulation results. The endorsing node holds the smart contract proposed by the simulated transaction. When the endorsing node endorses the transaction, the endorsing node creates a transaction endorsement, which is a signed response from the endorsing node to the client application indicating the endorsement of the simulated transaction. The method of endorsing the transaction depends on the endorsement policy that can be specified in the chaincode. An example of an endorsement policy is "a majority of endorsing peers must endorse the transaction". Different channels can have different endorsement policies. The client application forwards the endorsed transaction to the sorting service 910.

[0070] The ordering service 910 accepts endorsed transactions, orders them into blocks, and delivers the blocks to the submitting peers. For example, when a threshold of transactions has been reached, a timer has expired, or other conditions, the ordering service 910 may initiate a new block. Fig. 9A In the example of , blockchain node 922 is a submitting peer that has received a new data block 950 to store on blockchain 930.

[0071] The sorting service 910 may consist of a cluster of sorters. The sorting service 910 does not process transactions, smart contracts, or maintain a shared ledger. Instead, the sorting service 910 may accept endorsed transactions and specify the order in which those transactions are submitted to the distributed ledger 930. The architecture of the blockchain network may be designed to make a specific implementation of "sorting" (e.g., Solo, Kafka, BFT, etc.) a pluggable component.

[0072] Transactions are written to the distributed ledger 930 in a consistent order. The order of transactions is formulated to ensure that updates to the state database 934 are valid when they are submitted to the network. According to one or more embodiments, participants in the distributed ledger 930 can choose the ordering mechanism that best suits the network.

[0073] When the ordering service 910 initializes a new block 950, the new block 950 may be broadcast to the committing peers (e.g., blockchain nodes 921, 922, and 923). In response, each committing peer validates the transactions in the new block 950 by checking to ensure that the read set and the write set still match the current world state in the state database 934. Specifically, the committing peer may determine whether the read data that existed when the endorser simulated the transaction is the same as the current world state in the state database 934. When the committing peer validates the transaction, the transaction is written to the blockchain 932 on the distributed ledger 930, and the state database 934 is updated with the write data from the read-write set. If the transaction fails, that is, if the committing peer finds that the read-write set does not match the current world state in the state database 934, the transaction ordered into the block will still be included in the block, but it will be marked as invalid, and the state database 934 will not be updated.

[0074] refer to Fig. 9B , a block 950 (also referred to as a data block) stored on a blockchain 932 of a distributed ledger 930 may include multiple data segments, such as a block header 960, block data 970, and block metadata 980. It should be understood that the various blocks and their contents (e.g., Fig. 9B The block 950 and its contents shown are for example purposes only and are not intended to limit the scope of the example embodiments. In some cases, both the block header 960 and the block metadata 980 may be smaller than the block data 970 storing the transaction data, but this is not required. The block 950 may store transaction information for N transactions within the block data 970. The new block 950 may also include: a link to the previous block (e.g., Fig. 9A932 in the blockchain). For example, the block header 960 may include a hash of the header of the previous block. The block header 960 may also include a unique block number, a hash of the block data 970 of the current block 950, etc. The block number of the block 950 may be unique and may be assigned in an increasing / sequential order starting from zero. The first block in the blockchain may be called a genesis block, which includes information about the blockchain, its members, the data stored therein, etc.

[0075] The block data 970 may store transaction information for each transaction recorded in the block 950. For example, the transaction data may include one or more of the following: transaction type, version, timestamp, channel ID of the distributed ledger 930, transaction ID, epoch, payload visibility, chaincode path (deploy tx), chaincode name, chaincode version, input (chaincode and function), client (creator) identity (such as public key and certificate), client signature, endorser identity, endorser signature, proposed hash, chaincode event, response status, namespace, read set (a list of keys and versions read by the transaction, etc.), write set (a list of keys and values, etc.), start key, end key, key list, Merkel tree query summary, etc. The transaction data may be stored for each of the N transactions.

[0076] In some embodiments, block data 970 may also store data 972 that adds additional information to the hash-linked chain of blocks in blockchain 932. Thus, data 972 may be stored in an immutable log of blocks on distributed ledger 930. Some benefits of storing such data 972 are reflected in the various embodiments disclosed and described herein.

[0077] Block metadata 980 may store multiple fields of metadata (e.g., as a byte array, etc.). The metadata fields may include a signature at the time of block creation, a reference to the last configuration block, a transaction filter that identifies valid and invalid transactions within the block, the last offset of the sorting service that sorts the block, etc. The signature, the last configuration block, and the sorter metadata may be added by the sorting service 910. At the same time, the submitter of the block (e.g., blockchain node 922) may add validity / invalidity information based on endorsement policies, verification of read / write sets, etc. The transaction filter may include a byte array of size equal to the number of transactions in the block data 970 and a verification code that identifies whether the transaction is valid / invalid.

[0078] Fig.10 An embodiment of a computing node 1000 capable of implementing and / or performing any of the functions set forth above is shown. Fig.10The arrangements shown in are not intended to suggest any limitation as to the scope of use or functionality of embodiments of the applications described herein).

[0079] In computing node 1000 there is a computer system / server 1002, which can operate with numerous other general or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with computer system / server 1002 include, but are not limited to, personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems or devices, etc.

[0080] Computer system / server 1002 may be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Generally, program modules may include routines, programs, object programs, components, logic, data structures, etc. that perform specific tasks or implement specific abstract data types. Computer system / server 1002 may be practiced in a distributed cloud computing environment, where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media, including memory storage devices.

[0081] like Fig.10 As shown, the computer system / server 1002 of the cloud computing node 1000 is in the form of a general-purpose computing device. The components of the computer system / server 1002 may include, but are not limited to: one or more processors or processing units 1004, a system memory 1006, and a bus connecting different system components (including the system memory 1006 and the processing unit 1004).

[0082] The term "bus" refers to one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processor or a local bus using any of a variety of bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0083] The computer system / server 1002 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by the computer system / server 1002, including volatile and non-volatile media, removable and non-removable media. In one embodiment, the system memory 1006 is implemented as a flowchart of other figures. The system memory 1006 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 1010 and / or cache memory 1012. The computer system / server 1002 may further include other removable / non-removable, volatile / non-volatile computer system storage media.

[0084] By way of example only, storage system 1014 may be used to read and write to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk"), and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical medium) may be provided. In these cases, each drive may be connected to the bus via one or more data medium interfaces. Memory 1006 may include at least one program product having a set (e.g., at least one) of program modules that are configured to perform the functions of the various embodiments of the present invention.

[0085] A program / utility 1016 having a set (at least one) of program modules 1018 may be stored, for example, in the memory 1006. Such program modules 1018 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data, each of which or some combination may include an implementation of a network environment. The program modules 1018 generally perform the functions and / or methods of the embodiments described herein.

[0086] As will be appreciated by those skilled in the art, aspects of the present application may be embodied as a system, method, or computer program product. Thus, aspects of the present application may take the form of a complete hardware embodiment, a complete software embodiment (including firmware, resident software, microcode, etc.), or a combination of software and hardware embodiments, which may generally be referred to herein as a "circuit," "module," or "system." Here, aspects of the present application may take the form of a computer program product embodied in one or more computer-readable media having a computer-readable program code embodied therein.

[0087] The computer system / server 1002 may also communicate with one or more external devices 1020 (e.g., keyboards, pointing devices, displays 1022, etc.), may communicate with one or more devices that enable a user to interact with the computer system / server 1002, and / or may communicate with any device that enables the computer system / server 1002 to communicate with one or more other computing devices (e.g., network cards, modems, etc.). Such communication may be performed via an input / output (I / O) interface 1024. Furthermore, the computer system / server 1002 may also communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via a network adapter 1026. As shown, the network adapter 1026 communicates with other modules of the computer system / server 1002 via a bus. It should be understood that, although not shown in the figure, other hardware and / or software modules may be used in conjunction with the computer system / server 1002, including, but not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0088] Blockchain as a Service

[0089] The processing required to implement blockchain can be significant in terms of cost and complexity. As a result, it can be difficult to find software engineers and developers who are technically proficient in this area. These challenges and others may prevent companies from using blockchain in their business plans. This would be unfortunate given the advantages that blockchain offers over competing technologies.

[0090] One or more embodiments described herein provide solutions to the above problems by providing blockchain as a service (Baas). According to one embodiment, in return for a fee, a software company can provide customers with the generation, configuration, and management of blockchains. Providing such services will save customers from spending expensive technical equipment and reduce expenses by alleviating the need to hire a large number of internal software engineers to manage blockchains. Therefore, customers can focus on what they are best at, thereby serving their own customer base by providing excellent products and services.

[0091] Fig.11 An example of a blockchain network 1100 implemented outside the context of blockchain as a service is shown. In this example, the blockchain network 1100 includes a plurality of nodes (Node 1 to Node K) connected to a communication network 1110, which may be, for example, the Internet. The nodes may be peer nodes, each of which manages a copy of a distributed ledger corresponding to a blockchain. The communication network 1110 may be the Internet, a cloud network, or any other type of public or private network.

[0092] Each of the plurality of nodes (Node 1 to Node K) may include, for example, a server, a computer, or other terminal implementing a blockchain application 1120 and a blockchain software 1130. The blockchain application 1120 in each node may be an application of the same type, for example, may correspond to a particular type of business or information associated with an entry in a block of the blockchain. For example, when the blockchain protects an entry including financial information, the blockchain application 1120 may generate transaction data to be stored in an associated block of the blockchain. When the blockchain protects an entry including another type of client data (e.g., image data, medical records, retail data, etc.), the blockchain application 1120 in each node may generate or otherwise organize the client data to be stored in an associated block of the blockchain.

[0093] In order to store data in the blockchain, the blockchain application 1120 may be written to include various software interfaces for organizing, formatting, and handing over data for storage. For example, consider the case where the blockchain stores data related to car sales. Each node may correspond to a different dealer of the car manufacturer. Throughout the predetermined stages of the sales process of each car, the blockchain application 1120 in each node may generate and send data to be stored on the blockchain. When the sales assistant enters information identifying the purchase of the car in the dealer computer terminal, the terminal may send information to the dealer server (e.g., node 1). The blockchain application 1120 at node 1 may organize and send data indicating the vehicle identification number, the sales price, and the buyer's information to be stored in the block of the blockchain. Then, the blockchain application of node 1 may organize and send data indicating the financing obtained by the buyer for the car to be stored in the subsequent block of the blockchain, and so on. The blockchain application 1120 may reside only on the server, or may be divided into different modules stored in the sales joint dealer terminal and the server of node 1.

[0094] The software applications 1120 on the other nodes (Node 2 to Node K) may perform similar operations for their respective dealerships. For example, this may be achieved by each node in the blockchain network storing the same blockchain software (e.g., smart contracts (or chain codes), etc.). In one case, the blockchain applications 1120 at one or more nodes may be different, for example, depending on the way the client (e.g., car dealership) at each node conducts business.

[0095] The blockchain software 1130 serves as an interface between the software application 1120 and the blockchain. In one case, the blockchain software 1130 at each node may include a copy of the shared ledger, an application programming interface (API), and a smart contract (or chain code) responsible for processing data from the corresponding blockchain application of the node. The smart contract (or chain code) may perform operations including, for example, generating a request to add a new block to the blockchain, processing responses to the request from other nodes, generating a new block, validating data to be included in the new block, executing consensus protocols with other nodes, generating and transmitting events between nodes in the network, querying the blockchain for data, and / or other operations described herein. The API, smart contracts (or chain codes), and other features included in the blockchain software may correspond, for example, to the previously discussed Figures 1 to 10 In this process, the communication between nodes by each node is shown by a dotted line, for example, the dotted line represents a predetermined blockchain protocol.

[0096] The shared ledger of the blockchain (including the new block) is then stored on other nodes so that each node stores or otherwise has access to the latest copy of the shared distributed ledger. Each node in the blockchain network may store the same blockchain software (e.g., smart contracts (or chain codes), etc.), or may store different changes, for example, depending on the differences in the blockchain applications 1120 at those nodes. In one case, two or more of the nodes (node ​​1 to node K) may store multiple smart contracts and corresponding chain codes for the same blockchain or different blockchains. Since the ledger is immutable, the data stored in the blockchain is protected in terms of its validity and integrity.

[0097] Fig.12 Shows how to pass Fig.11 1200 of each node in a network of nodes adding a block to a blockchain. In example 1200, a node's blockchain application 1120 submits an entry 1210 to a corresponding blockchain software 1130. The entry 1210 may include or be in the form of a request to add a block based on data or other information related to an operation performed by the blockchain application 1120 (e.g., a car sale in the previously discussed example). In one case, the request may include or prompt a post (POST) of a transaction in a Hyperledger API.

[0098] The blockchain software 1130 may maintain two types of entries: pending and confirmed. When an entry 1220 is received, the blockchain software 1130 may add the entry to other pending entries 1220 that have not yet received consensus from other peer nodes in the network. These entries may be stored in a sequential queue that may be referred to as proposed blocks 1230 to be added to the blockchain. The pending entries may be input into a consensus protocol 1240 involving other peer nodes. The pending entries may be input one by one for consensus, or the entire proposed block 1230 may be input for consensus. After consensus has been received among all peer nodes in the blockchain network (e.g., through proof of work, proof of state, etc.), the blockchain software 1130 may form a new block 1250 that includes entries 1260 corresponding to all or part of the pending entries. The new block 1250 is then appended to the previous block in the shared ledger 1270 maintained by all peer nodes. Blocks in a blockchain may include a pointer to a previous block (e.g., a hash value of the previous block) and be cryptographically signed to maintain integrity.

[0099] like Fig.11 and 12 As shown, the process of managing a blockchain may, at least in some cases, cause substantial delays or include inefficiencies. For example, in order to receive consensus, each pending entry will be sent to all participating peer nodes for confirmation. This process can be time consuming. Furthermore, even without other reasons, such as network conditions at the geographical location of the nodes (which in some cases may be scattered around the world), it takes a considerable amount of time for the peer nodes to respond. As a result, the process of adding blocks to the blockchain and maintaining the ledger can be complex and slow.

[0100] Fig.13 A blockchain as a service (Baas) embodiment 1300 is shown, which can overcome the problems associated with Fig.11 and 12 The example shown in Figure 1 shows the delays and other inefficiencies associated with the example shown. In this Baas embodiment, one or more nodes are different from one or more other nodes in the network. For example, each of nodes 1 and K may include a blockchain application 1120, but not blockchain software 1130. The blockchain software 1130 for these nodes may be stored in corresponding virtual nodes 1310 and 1320 maintained by a hosted Baas provider 1340, which may be a software company that provides Baas services, for example.

[0101] Virtual nodes 1310 and 1320 allow the Baas provider to perform operations of blockchain software 1130 on behalf of blockchain participants (e.g., clients) who own or operate nodes 1 and K. This eliminates the processing burden and its associated costs for blockchain participants of nodes 1 and K, allowing them to focus on their respective businesses while paying for Baas services. This also alleviates the need for blockchain participants of nodes 1 and K to hire additional software engineers to manage their blockchain nodes, thereby saving additional costs and providing time efficiency for these participants.

[0102] To implement this Baas embodiment, the blockchain applications of nodes 1 and K must be written to communicate with virtual nodes 1310 and 1320, respectively. For example, this can be achieved by incorporating appropriate communication interfaces in the blockchain application or coupling to the blockchain application, which exchanges entries, messages, and other information to manage the shared ledger and submit blocks to the blockchain, etc. The communication path between nodes 1 and K and their respective virtual nodes 1310 and 1320 can be carried out through the communication network 1110 or through different (e.g., peer-to-peer) paths, such as Fig.13 As shown by the dotted line in .

[0103] The Baas provider 1340 may include additional virtual nodes 1330 for other nodes in the blockchain network or for other nodes in different blockchain networks for the same or different blockchain participants to manage different blockchains. Thus, in the latter case, the Baas provider can provide services to various customers of their respective businesses, for example, these businesses can be independent of each other. The Baas provider 1340 can implement smart contracts, network policies and / or other management information to prevent information from one client or customer network from being accidentally combined with other clients or customers receiving services from the Baas provider.

[0104] In one embodiment, the Baas provider 1340 may include one or more virtual nodes 1330, which include both the blockchain application 1120 and the blockchain software 1130. In this case, in addition to the role of the blockchain service provider, the Baas provider 1340 may perform hosting services for the client or owner of the virtual node 1330. For example, the Baas provider 1340 may act as a website host and perform operations corresponding to the operations of the blockchain application 1120 and the blockchain software 1130 of the virtual node 3. In one embodiment, the virtual node of the Baas provider can communicate with other nodes that are not virtual nodes (e.g., node 4, node 2, etc.) and other virtual nodes through the blockchain communication protocol (e.g., see the dotted line). Fig.13In the example, box 1340 may represent a single server of a Baas provider. In another embodiment, a Baas provider may manage multiple servers, and the same blockchain may be managed by the Baas server for virtual nodes across its multiple servers.

[0105] Fig.14 Another embodiment 1400 is shown, which includes one or more servers 1410 implementing blockchain as a service. Fig.13 Unlike the embodiments of the present invention, the Baas embodiment 1400 includes a manager 1450 that performs a fast path service for communicating with non-virtual and / or virtual nodes of the blockchain network. Although the fast path service is shown as an operation performed by the Baas manager, in other embodiments, the fast path service may be performed by the blockchain software of one or more virtual nodes in the Baas provider, or the fast path service may be performed by both the Baas manager 1450 and the blockchain software in one or more virtual nodes.

[0106] In such a network, many agents may use the Baas server 1410 simultaneously with respect to the same blockchain or multiple blockchains. An agent may be a node in the blockchain network that has a virtual node in the Baas provider, a client connected to the node, a user of the client, or other devices coupled to submit, receive, or manage information related to the blockchain network. Without fast path services, bottlenecks and other processing delays will undoubtedly occur, which will adversely affect the efficiency and responsiveness of blockchain operations. Some of these delays may occur transparently to the user. However, delays often undermine the performance of nodes and applications.

[0107] The fast path service 1450 can reduce latency and otherwise improve processing efficiency relative to nodes and virtual nodes in the blockchain network. In one embodiment, the fast path service 1450 can ensure that entries in the distributed shared ledger of the blockchain are available to other agents without significant delay. This can be achieved by implementing logic (e.g., software, hardware, or a combination) for improving processing performance efficiency in one or more of the following ways:

[0108] a) Perform a single information transfer from the agent to the Baas provider's hosting server, rather than multiple information transfers between multiple agents,

[0109] b) replace agent-to-agent communication with server-to-server communication,

[0110] c) store large files in a single location and use simple pointers to them, and

[0111] d) Transferring confirmed blocks of entries to one or more new blocks without storing the entries in a pending queue.

[0112] One-time information transfer

[0113] Fig.15 An embodiment of a method 1500 that may be performed by the fast path service 1450 to implement approach a) for one or more nodes co-hosted by a Baas provider (which may be the server 1410) is shown. Fig.16 show when Fig.15 An example of a process flow 1600 that may be performed when the method is executed.

[0114] refer to Fig.15 and Fig.16 At 1510, the blockchain application 1120 in the node 1610 of the blockchain network sends a file, data, or other information (generally referred to as data) to the corresponding virtual node 1310 in the Baas server 1410. The blockchain software 1130 in the virtual node receives the data, but does not place the entry in the pending queue or block of the blockchain (e.g., Fig.12 Instead, at 1520, the blockchain software 1130 of the virtual node determines that a fast path service operation is to be performed on the data.

[0115] Determining that a fast path service operation is to be performed may be based on one or more predetermined conditions. In one embodiment, the blockchain application 1120 of the node may detect the size of the data to be sent to the virtual node of the Baas provider. If the data exceeds the predetermined size, the blockchain application 1120 may provide information to the blockchain software 1130 in the corresponding virtual node that a specific fast path service operation is to be performed. For example, the information may be sent by setting a flag in a field of a packet sent with the data, including an identifier in a packet header, or sending an event or message to the blockchain software 1130 in the virtual node. In one embodiment, the blockchain software 1130 may determine the size of the data received from the blockchain application 1120 and notify the fast path service accordingly.

[0116] After having determined that a fast path service operation is to be performed, the blockchain software 1130 may send the data and / or a notification signal 1620 to the fast path service 1450. The notification signal may notify the fast path service 1450 that the data has been received at the virtual node and that a fast path service operation is to be performed. For example, when the fast path service is capable of performing multiple types of operations, the notification signal may also include one or more bits indicating the type of fast path service operation to be performed. Based on the notification signal, the fast path service 1450 may perform one or more operations for reducing latency in connection with obtaining consensus for an entry to be included in a new block to be appended to the blockchain for the received data and / or otherwise managing operations performed in connection with the blockchain.

[0117] At 1530, the fast path service operation may involve the fast path service 1450 instructing the blockchain software 1130 to store the received data in a memory, a database, or some other storage area 1630. In one embodiment, the fast path service 1450 may receive and store the data in the area 1630. After the data has been stored, at 1540, the fast path service 1450 receives a pointer (not the data itself), for example, from the storage area itself, the blockchain software 1130, or from another type of manager that manages data storage operations of the Baas provider. In one embodiment, the blockchain software 1130 of the virtual node may receive the pointer. The pointer may include, for example, an address corresponding to a location in the memory, database, or storage area where the data is stored. In one embodiment, the pointer may include a website address or other information that identifies where the data has been stored.

[0118] If the fast path service 1450 receives the pointer, then at 1550, the fast path service 1450 sends the pointer to the blockchain software 1130 at the virtual node. Otherwise, the blockchain software 1130 (which receives the pointer) adds an entry corresponding to the pointer, rather than the data, to a pending queue. The blockchain software may perform these operations based on instructions from the fast path service or based on instructions programmed into its own software at the virtual node. Then, at 1560, the entry (alone or with other entries) may be submitted for consensus. When consensus is confirmed at 1570, a new block including the entry may be appended to the blockchain. In one embodiment, the fast path service 1450 may manage the addition of entries to the pending queue, consensus, and the generation of new blocks.

[0119] When the data is to be obtained by the node or a different node, the blockchain may be queried to recover the pointer at 1580. The pointer may then be used to access the data at the storage location identified by the pointer.

[0120] Thus, the fast path service 1450 allows only a single data transfer to be performed so that a block corresponding to the data received from the node is appended to the blockchain and the data is obtained when it is later queried. In other types of methods, data is transferred between nodes through the blockchain network as new blocks are added.

[0121] Furthermore, by storing the data and generating entries corresponding only to pointers, the efficiency of appending new blocks to the blockchain can be greatly increased. This is particularly beneficial because the delays that would otherwise be associated with storing data (especially large amounts of data) in a new block (or associated with processing that data to create a hash for that data) are reduced or eliminated. Of course, the fast path service can do this for data of any size, not just large files.

[0122] Another benefit is the reduction in the amount of data to be stored in the distributed shared ledger. Because new blocks include entries corresponding to pointers, rather than actual data, the storage requirements for implementing this approach to the fast path service can be drastically reduced for all nodes storing a copy of the ledger in the blockchain network. In addition, when data is stored locally on the node, the actual data is not transmitted, which reduces network traffic and frees up available bandwidth. Thus, the fast path service improves the way computers operate with respect to managing, accessing, and protecting information stored on the blockchain.

[0123] The communication between the blockchain application in the node and the blockchain software in the virtual node can be performed, for example, through an optimized REST interface. The same interface can support communication between nodes using a blockchain communication protocol, or another type of interface can be used for this purpose.

[0124] If the blockchain software 1130 in the virtual node receives data from the blockchain application 1120 without information indicating that the fast path service should be performed, the blockchain software 1130 may perform the fast path service in a manner that is consistent with the consensus and the purpose of adding a new block to the blockchain. Fig.12 and 13 Operate as described in .

[0125] In one embodiment, the blockchain application 1120 in the node may not send data to the virtual node. In this case, the blockchain application 1120 may store the data in a local database or other storage area 1640, and then send a pointer indicating the location or address in the local database or other storage area to the blockchain software in the virtual node. The fast path service 1450 can then operate on the indicated above to add a new block to the blockchain including an entry corresponding to the pointer.

[0126] The fast path service 1450 can implement method a in a number of other scenarios. For example, consider a transaction between node 1 and node 3. Further assume that node 1 and node 3 are hosted on the same server of the Baas provider. In the case of node 1, the blockchain application is located on the node, while the blockchain software is hosted in the virtual node of the Baas provider. In the case of node 3, the Baas provider hosts the blockchain application and the blockchain software in the virtual node.

[0127] When a transaction occurs between node 1 and node 3, since both nodes have virtual nodes in the Baas provider, the fast path service 1450 can improve the efficiency of blockchain management related to the transaction. For example, the fast path service 1450 can store data corresponding to the transaction in a file shared by virtual nodes 1 and 3, and can merge a pointer to the shared file in the storage device accessible by the two virtual nodes into the entry of the new block to be added to the blockchain. An example of a storage device storing a shared file is shown as Fig.16 Database 1630 in.

[0128] When the fast path service 1450 invokes this shared file approach, other nodes or virtual nodes maintained by the Baas provider (in the same server or a different Baas server) can access the data corresponding to the transaction simply by linking to the shared file. For example, this can be performed by querying the blockchain to locate a block with an entry that has a pointer to the location of the shared file in the Baas provider.

[0129] The shared file approach adopted by the fast path service 1450 can preserve network resources because the communication between transaction nodes 1 and 3 is carried out through the virtual node inside a server (or multiple servers) of the Baas provider, rather than through the blockchain network. The use of a shared file approach is also more efficient because it prevents the transfer of large amounts of information between virtual nodes in the Baas provider. Because the use of the network is avoided, this shared file approach can also improve the efficiency of submitting new blocks to the blockchain and subsequently accessing transaction data in the shared file.

[0130] Fig.16 The shared files in are located in the database 1630 within the Baas provider. In one embodiment, the shared files may be stored in a storage area that is external to the Baas provider but in communication with it. In this case, the storage area may be located in another location, for example, an independent storage network or a storage device attached to a network.

[0131] Server-to-Server Communication

[0132] Fig.17An embodiment of a method 1700 is shown that can be performed by the fast path service 1450 to implement approach b) for multiple agents or nodes having virtual nodes located on different servers of a Baas provider. This scenario includes, but is not limited to, a group of nodes having virtual nodes co-located in one server and working with another group of nodes having virtual nodes hosted on another server of the Baas provider. Fig.18 show when Fig.17 An example of a process flow 1800 that may be performed when the method is implemented.

[0133] refer to Fig.17 and 18 , the Baas provider includes a first server 1710 and a second server 1720. The first server 1710 hosts M virtual nodes and the second server 1720 hosts N virtual nodes, where M and N can be the same number or different numbers. Because the M and N virtual nodes are hosted by the same Baas provider, the M virtual nodes in the Baas server 1710 can communicate with the N virtual nodes of the Baas server 1720 within the Baas provider domain. This alleviates the need for agents or nodes to communicate with each other through the blockchain network 1110 outside the Baas provider.

[0134] In one example implementation, the first node 1730 wants to communicate with the second node 1740 in the blockchain network. At 1810, the blockchain application 1120 in the first node does not communicate with the second node through the blockchain network (e.g., the communication network 1110). Instead, the blockchain application 1120 of the first node sends information to be delivered to its virtual node M in the server 1710 of the Baas provider. The information may include a request to deliver the information to the virtual node N of the second node located in another server 1720 of the Baas provider.

[0135] At 1820, the blockchain software 1130 submits a notification to the fast path service logic 1450 indicating that the information is to be sent to a second node in another server.

[0136] At 1830, the fast path service logic 1450 notifies the first node that the information will be sent to the second node via an internal signal path 1750 located within the domain of the Baas provider. In one embodiment, an instruction (or notification) to send information from virtual node M to virtual node N via signal path 1750 may be programmed into the blockchain software 1130 of virtual node M. The blockchain software 1130 may perform this function by referring to a list of nodes and / or virtual nodes included in the server of the Baas provider. The list may be stored at each virtual node, or may be maintained by a manager of the Baas provider (e.g., the same manager that includes the fast path service logic).

[0137] At 1840 , when notified by the fast path service logic 1450 , the blockchain software of virtual node M sends the information to be delivered to the blockchain software of virtual node N via the internal signal path 1750 .

[0138] At 1850 , if warranted, virtual node N may communicate the information received from virtual node M to a second node via signal path 1750 .

[0139] Because the internal communication occurring between the servers of the Baas provider is not hindered by the latency of the blockchain network 1100, the internal data paths of the Baas provider can be used to pass information between nodes (through its virtual nodes). Therefore, communication can be performed faster and more efficiently.

[0140] Information transmitted between virtual nodes may include, but is not limited to, data and / or other information associated with transactions or entries corresponding to new blocks to be added to the blockchain, consensus and validation information, events, messages, and other types of messages that occur between nodes of a blockchain network. Fig.18 The method may include the following operations: determining that one or more virtual nodes of the M virtual nodes are involved in a transaction with one or more of the N virtual nodes, and then sending information between the servers of the Baas provider as described above. In the case where the first server 1710 includes M virtual nodes and the second server 1720 includes N virtual nodes, MN types of information exchanges can be performed between the agents through a single exchange path 1750 between the two servers of the Baas provider.

[0141] File storage with pointers

[0142] Fig.19An embodiment of a method 1900 that can be performed by a fast path service 1450 to implement approach c) for any type of node is shown. The method includes, at 1910, receiving a file at a virtual node of a Baas provider. The file can be received by a blockchain application 1120 at a corresponding node in the blockchain network or from a blockchain application 1120 also hosted by the Baas provider.

[0143] At 1920, the blockchain software 1130 of the virtual node determines that the size of the file exceeds a predetermined size, e.g., is a large file.

[0144] At 1930, the blockchain software 1130 notifies the fast path service 1450 that the file will be shared by different virtual nodes managed by the same server of the Baas provider. The different virtual nodes can be determined by the blockchain software 1130, for example, by the transaction information received from the corresponding blockchain application 1120.

[0145] At 1940, the fast path service 1450 stores the large file in a storage area of ​​the virtual node or a storage area accessible to the virtual node. Subsequently, the large file (or a pointer to the storage area location storing the file) may be stored in a block of the blockchain.

[0146] At 1950, the fast path service 1450 performs a storage-level mirroring operation involving mirroring the file between other nodes that will share the file in the same server of the Baas provider. In one embodiment, one or more blocks on the blockchain corresponding to the file may be mirrored to other virtual nodes in the same server of the Baas provider. This will alleviate the need to use peer-to-peer communication between all agents of the nodes hosted by the same server.

[0147] Transfer from pending queue to confirmed block

[0148] Fig. 20 An embodiment of method 2000 that can be performed by fast path service 1450 to implement method d) for improving the effective time of consensus between different agents with virtual nodes co-hosted by the same Baas provider is shown. This can be achieved by controlling the transfer of information from the pending queue to the confirmed block in a manner that reduces the time consensus time. Fig.21 An example of a possible scenario 2100 is shown, where: Fig. 20 The method can be implemented.

[0149] refer to Fig. 20 and 21At 2010, the blockchain software 1130 may receive one or more entries 2110 to be added to a new block of the blockchain from the blockchain application 1120. The blockchain application 1120 may be located at a node, and the blockchain software 1130 may be located on a corresponding virtual node hosted by a Baas provider. In one embodiment, both the blockchain application 1120 and the blockchain software 1130 may be hosted by a Baas provider.

[0150] Each entry 2110 may include information to be incorporated into a new block of the blockchain, or otherwise associated with the blockchain and / or its companion nodes and virtual nodes. For example, each entry may include information corresponding to one or more transactions with a client and / or between nodes, data, files, public and / or private key information, digital certificates, permissions, policies, chaincode information, events, or messages.

[0151] At 2020, the blockchain software 1130 processes the entry in a manner compatible with blockchain submission and submits the entry 2110 to the policy-based module 2120 of the fast path service 1450.

[0152] At 2030, the policy-based module 2120 checks each entry it receives against a first set of policies stored in a virtual node having blockchain software 1130 or otherwise accessible to the virtual node. In one embodiment, the first set of policies may be stored in a chain code associated with the virtual node or in a Baas manager 1450, which may be included in the logic of a fast path service, for example. For illustrative purposes only, the policy-based module 2120 checks each entry it receives against a first set of policies stored in a virtual node having blockchain software 1130 or otherwise accessible to the virtual node. In one embodiment, the first set of policies may be stored in a chain code associated with the virtual node or in a Baas manager 1450, which may be included in the logic of a fast path service, for example. Fig.21 is shown as being included in the logic of the fast path service.

[0153] At 2040, each entry that satisfies the set of policies is not placed in the pending queue 2130 with other pending entries that do not satisfy the first set of policies. Instead, the policy-based module 2120 places the entries that satisfy the first set of policies in the confirmed queue 2140.

[0154] At 2050, the entries in the confirmed queue 2140 are submitted to the consensus protocol without performing validation and / or other pre-consensus processes that would normally be performed on pending entries. Therefore, the entries in buffer 2140 do not have a pending status, but are instead treated as if they have been validated, confirmed, and satisfied all other blockchain processes that may occur before consensus on the pending entries. The reason that the entries in the confirmed queue can be processed in this manner is because they satisfy the first set of policies, thereby eliminating the need for validation, confirmation, etc. Therefore, the entries in buffer 2140 are given a higher priority status than the pending status of the entries in pending queue 2130.

[0155] Due to their higher priority status, the entries in the buffer 2140 are submitted to the consensus protocol 2150, which may involve, for example, proof of work, proof of state, or one or more other types of consensus protocols. For at least those nodes in the blockchain network that are hosted by a Baas provider (e.g., having a virtual node therein), consensus may be performed based on internal communications occurring within the domain of the Baas provider. For nodes that are not hosted by a Baas provider, consensus may be performed based on communications through the network 1110.

[0156] At 2060, after consensus is obtained for the entry subject to fast path servicing, the entry is included with other confirmed entries in a new block 2160, which is appended to the last previous block 2170 of the blockchain.

[0157] At 2070, if consensus is not obtained for one or more entries output from buffer 2140, a second set of policies (different from the first set of policies) may be used to determine whether the entries that did not receive consensus should be retained in buffer 2140 or placed in pending queue 2130. Each of the first set of policies and the second set of policies may include one or more policies.

[0158] At 2080, if the entries that did not receive consensus satisfy the second set of policies, the entries may be returned to the fast path service 1450. The policy-based module 2120 in the fast path service may then place the entries back into the confirmed queue 2140 where they will be resubmitted for consensus.

[0159] At 2090, if the entry that has not received consensus does not satisfy the second set of policies, the consensus protocol 2150 returns the entry to the fast path service. Then, the policy-based module 2120 in the fast path service places the entry in the pending queue 2130.

[0160] To further illustrate the fast path service of this embodiment, consider the case where a transaction occurs between nodes in a blockchain network. The first set of policies governing the operation of the fast path service may include the following policies: Is the transaction only between virtual nodes on the same Baas server? If the answer is yes, then in this example the set of applicable policies is satisfied, and the fast path service places an entry corresponding to the transaction in the confirmed queue 1240. This operation can be performed because the node on another server of the Baas provider is not involved in the consensus for the entry corresponding to the transaction.

[0161] The entries in the confirmed queue 1240 are submitted for consensus. If consensus is achieved, the entries that have achieved consensus are included in a new block that will be appended to the blockchain. If consensus is not achieved, the entries are returned to the Baas manager that implements the fast path service, which can be separate from or incorporated into the blockchain software of the virtual node.

[0162] At this point, the Baas manager determines whether the entry satisfies the second set of policies. The second set of policies may include, for example, whether the transaction is only between virtual nodes in different servers hosted by the Baas provider. If so, the Baas manager may put the entry back into the confirmed queue for consensus and subsequent inclusion in the new block. If not, the Baas manager may place the entry in the pending queue 2130.

[0163] If the transaction is not only between virtual nodes on the same Baas server, the fast path service implemented on the Baas manager places the entry into the pending queue 2130 so that it can undergo validation and other blockchain processing that occurs before consensus. Other types of strategies for determining when an entry or transaction can be assumed to be confirmed may be applied in other embodiments. Therefore, the fast path service of this embodiment can be used to improve and improve the performance of computer operations as it relates to transactions managed by the Baas provider in a hosted environment.

[0164] In other embodiments, the set of policies governing the operation of the fast path service 1450 may include whether transactions are only between virtual nodes hosted by the same Baas provider, even if the virtual nodes are on different servers of the provider. In this case, inter-server communication within the Baas provider domain may still provide the advantage of improved performance relative to the operation and access of information by the virtual nodes and the management of the blockchain. In one or more embodiments, the first and / or second set of policies may take into account, for example, the location of the blockchain software hosting the node, the size of the message to be transferred between the node or virtual node, and / or the number of agents involved in the blockchain transaction. In one embodiment, the consensus algorithm may determine the policy.

[0165] According to one or more other embodiments, a non-transitory computer-readable medium is provided, which includes instructions for controlling logic to perform operations corresponding to any system and method embodiments disclosed herein. As with other embodiments described herein, the logic can be implemented in hardware, software, or both. Such logic may, for example, correspond to the processor, manager, controller, fast path service, application, software, and other processing and control features of the disclosed embodiments. Examples of such computer-readable media are shown in the drawings referenced herein, including but not limited to the Baas manager and fast path service shown in these drawings.

[0166] According to one or more embodiments described herein, a Baas provider includes a manager that implements a fast path service to control the transfer, storage, or other processing of information relative to one or more virtual nodes, and also generates blocks and performs other blockchain processing operations related to the information. By using such a Baas provider, peer-to-peer communication between different nodes can be avoided, thereby improving blockchain management efficiency.

[0167] For example, in one or more embodiments, the fast path service can allow large amounts of server data to be quickly transferred, and only small pointers can be provided to different virtual nodes / block change software systems to access large data. Moreover, in one or more embodiments, the fast path service can be used as a fast path interface to all nodes connected to it. Therefore, the fast path service can allow a faster way to upload information from an agent to a server, and allow locally existing agents to share information about content in the same server.

[0168] Additionally, in one or more embodiments, blockchain software in nodes that do not have a virtual node in a Baas provider may use fast path services, e.g. Fig.14 In one embodiment, the system can use the blockchain protocol to communicate with any node that does not have the updated blockchain software, such as Fig.14 Node 4 in.

[0169] In addition, in one or more embodiments, a set of policies may be used to determine when to use a protocol (e.g., a fast path protocol or a standard blockchain protocol). These policies may take into account, for example, the location of the hosting node blockchain software, the size of the message to be transferred, and the number of agents in the blockchain transaction. In one embodiment, the consensus algorithm may determine the policy. According to one or more embodiments, the fast path service and / or the Baas manager may additionally or alternatively be executed by the blockchain software of one or more virtual nodes of the Baas provider.

[0170] Although exemplary embodiments of at least one of the systems, methods, and non-transitory computer-readable media are shown in the accompanying drawings and described in the foregoing detailed description, it should be understood that the present application is not limited to the disclosed embodiments, but is capable of many rearrangements, modifications, and substitutions as described and defined in the following claims. For example, the capabilities of the systems in the various drawings may be performed by one or more modules or components described herein or in a distributed architecture, and may include a transmitter, a receiver, or a pair of both. For example, all or part of the functions performed by each module may be performed by one or more of these modules. In addition, the functions described herein may be performed at different times and in relation to various events inside or outside the module or component. In addition, the information sent between the modules may be sent between the modules via at least one of the following: a data network, the Internet, a voice network, an Internet protocol network, a wireless device, a wired device, and / or multiple protocols. In addition, messages sent or received by any module may be sent or received directly and / or via one or more other modules.

[0171] Those skilled in the art will appreciate that a "system" may be embodied as a personal computer, server, console, personal digital assistant (PDA), cellular telephone, tablet computing device, smart phone, or any other suitable computing device, or combination of devices. Presenting the above functions as being performed by a "system" is not intended to limit the scope of the present application in any way, but is intended to provide an example of many embodiments. In fact, the methods, systems, and apparatus disclosed herein may be implemented in localized and distributed forms consistent with computing technology.

[0172] It should be noted that some of the system features described in this specification have been presented as modules in order to more specifically emphasize their implementation independence. For example, a module may be implemented as a hardware circuit comprising: a custom very large scale integration (VLSI) circuit or gate array, an off-the-shelf semiconductor such as a logic chip, a transistor, or other discrete components. A module may also be implemented in a programmable hardware device such as a field programmable gate array, programmable array logic, a programmable logic device, a graphics processing unit, etc.

[0173] Modules may also be implemented at least in part in software to be executed by various types of processors. The identified executable code unit may, for example, include one or more physical or logical blocks of computer instructions, which may, for example, be organized as objects, processes, or functions. However, the executable file of the identified module does not need to be physically located in one place, but may include different instructions stored in different locations, which, when logically connected together, include the module and achieve the purpose for the module. In addition, the module may be stored on a computer-readable medium, which may be, for example, a hard drive, a flash memory device, a random access memory (RAM), a magnetic tape, or any other such medium for storing data.

[0174] The methods, processes, computer-readable media, and / or operations described herein may be performed by code or instructions to be executed by a computer, processor, controller, or other signal processing device. The computer, processor, controller, or other signal processing device may be those described herein, or one other than the elements described herein. Because the algorithms underlying the methods (or operations of the computers, processors, controllers, or other signal processing devices) are described in detail, the code or instructions for implementing the operations of the method embodiments may convert the computer, processor, controller, or other signal processing device into a dedicated processor to perform the methods described herein.

[0175] Moreover, as previously explained, another embodiment may include a computer-readable medium, such as a non-transitory computer-readable medium, for storing the above-mentioned code or instructions. The computer-readable medium may be a volatile or non-volatile memory or other storage device, which may be removably or fixedly coupled to a computer, processor, controller, or other signal processing device that will execute the code or instructions for performing the method embodiments herein.

[0176] The processors, controllers, managers, fast path services, devices, modules or other processing features of the embodiments disclosed herein may be implemented in logic that may include hardware, software or both, for example. When implemented at least partially in hardware, the processor, controller, manager, fast path service device, module, or other processing feature may be, for example, any of a number of integrated circuits, including but not limited to an application specific integrated circuit, a field programmable gate array, a combination of logic gates, a system on a chip, a microprocessor, or other type of processing or control circuit.

[0177] When implemented at least in part in software, a processor, controller, manager, fast path service logic, device, module, or other processing feature may include, for example, a memory or other storage device for storing, for example, code or instructions that can be executed by a computer, processor, microprocessor, controller, or other signal processing device. The computer, processor, microprocessor, controller, or other signal processing device may be those described herein or an element other than the elements described herein. Because the algorithms that form the basis of the method (or the operation of the computer, processor, microprocessor, controller, or other signal processing device) are described in detail, the code or instructions for implementing the operation of the method embodiment can convert the computer, processor, controller, or other signal processing device into a dedicated processor to perform the method described herein. The term "device unit data" may be or include card-only data or other types of unique device-specific data.

[0178] It is easy to understand that the components of the present application can be arranged and designed in a variety of different configurations, as generally described and illustrated in the drawings herein. Therefore, the detailed description of the embodiments is not intended to limit the scope of the claimed application, but only represents the selected embodiments of the present application.

[0179] Those skilled in the art will readily appreciate that the above content can be practiced in different orders of steps and / or using hardware elements in configurations different from the disclosed configurations. Therefore, although the present application has been described based on these preferred embodiments, it is apparent to those skilled in the art that certain modifications, variations, and alternative configurations will be apparent.

[0180] Although preferred embodiments of the present application have been described, it should be understood that the described embodiments are merely illustrative and that the scope of the present application is limited solely by the appended claims when considered in light of the full range of equivalents and modifications (e.g., protocols, hardware devices, software platforms, etc.) of the appended claims.

Claims

1. A system for implementing blockchain as a service, comprising: A distributed database as a blockchain-as-a-service provider; as well as a first virtual node hosted by the blockchain-as-a-service provider, the first virtual node comprising blockchain software; Wherein, the blockchain as a service provider includes a manager to: Determining that data at the first virtual node satisfies a condition requiring execution of a fast path service operation; obtaining a pointer to a shared memory area where the data is to be stored; controlling generation of data including the pointer; and The data is appended to the distributed database.

2. The system according to claim 1, wherein: The manager is used to control the generation of the data by generating blocks in the blockchain.

3. The system of claim 2, wherein: The blockchain software is coupled to a blockchain application external to the blockchain-as-a-service provider.

4. The system of claim 2, wherein: The first virtual node also includes a blockchain application; and The blockchain application is configured to receive the data from a network coupled to the blockchain-as-a-service provider.

5. The system according to claim 1, wherein: The manager is configured to provide the pointer to a second virtual node hosted by the blockchain-as-a-service provider.

6. The system according to claim 5, wherein: The manager is configured to provide the pointer to the second virtual node when the distributed database is queried by the second virtual node.

7. The system according to claim 5, wherein: The first virtual node and the second virtual node are managed by a same server of the blockchain-as-a-service provider.

8. The system according to claim 1, wherein: The condition is that the data exceeds a predetermined size.

9. A method for implementing blockchain as a service, comprising: Determining that the data at the first node satisfies a condition requiring execution of a fast path service operation; Obtaining a pointer to a shared storage area for the data; controlling the generation of a block including the pointer; as well as The block is appended to a blockchain without the data, wherein the first node corresponds to a first virtual node hosted by a blockchain-as-a-service provider, the first virtual node includes blockchain software, and wherein the first virtual node receives the data from a network coupled to the blockchain-as-a-service provider.

10. The method according to claim 9, wherein: The condition is that the data exceeds a predetermined size.

11. The method according to claim 9, wherein: The blockchain software receives the data from a blockchain application external to the blockchain-as-a-service provider.

12. The method according to claim 9, wherein: The first virtual node also includes a blockchain application; and The blockchain application receives the data from the network.

13. The method according to claim 9, further comprising: The pointer in the block is provided to a second node, the second node corresponding to a second virtual node hosted by the blockchain-as-a-service provider.

14. The method according to claim 13, wherein: When the blockchain is queried by the second virtual node, the pointer is provided to the second virtual node.

15. The method according to claim 13, wherein: The first virtual node and the second virtual node are managed by a same server of the blockchain-as-a-service provider.

16. A non-transitory computer-readable medium comprising instructions, which, when read by a manager of a blockchain-as-a-service provider, cause the manager to implement the steps in the method according to any one of claims 9-15.

17. A system for implementing blockchain as a service, comprising: First cohort; The second cohort; as well as A manager of a blockchain-as-a-service provider, the manager controlling the placement of entries into a first queue when a first set of policies is satisfied, and controlling the placement of the entries into a second queue when the first set of policies is not satisfied, wherein the first queue is used to store confirmed entries to be submitted for consensus without validation, and the second queue is used to store pending entries that are required to be validated before consensus.

18. The system of claim 17, wherein: The first set of policies includes: the entry is based on a transaction between a first virtual node and an agent of a second virtual node hosted by the blockchain-as-a-service provider.

19. The system of claim 17, wherein: The first set of policies includes: the entry is based on a transaction between agents of a first virtual node and a second virtual node hosted by a same server of the blockchain-as-a-service provider.

20. The system of claim 17, wherein: The manager is configured to determine whether the entry satisfies a second set of policies when the first set of policies is satisfied and the entry is denied consensus.

21. The system of claim 20, wherein: The manager is used to: placing the entry in the first queue when the second set of policies is satisfied; as well as When the second set of policies is not satisfied, the entry is placed in the second queue.

22. The system of claim 17, wherein: The entry corresponds to information received from a virtual node hosted by the blockchain-as-a-service provider.

23. The system of claim 17, wherein: When consensus is obtained, the blockchain-as-a-service provider controls the generation of a new block including the entry.

24. A method for implementing blockchain as a service, comprising: receiving an entry at a blockchain-as-a-service provider; determining whether the entry satisfies a first set of policies; as well as When the first set of policies is satisfied, the control places the entry into a first queue, and when the first set of policies is not satisfied, the control places the entry into a second queue, wherein the first queue is used to store confirmed entries that will be submitted for consensus without taking effect, and the second queue is used to store pending entries that are required to take effect before consensus.

25. The method according to claim 24, wherein: The first set of policies includes: the entry is based on a transaction between a first virtual node and an agent of a second virtual node hosted by the blockchain-as-a-service provider.

26. The method according to claim 24, wherein: The first set of policies includes: the entry is based on a transaction between agents of a first virtual node and a second virtual node hosted by a same server of the blockchain-as-a-service provider.

27. The method of claim 24, further comprising: When the first set of policies is satisfied and the entry is denied consensus, it is determined whether the entry satisfies a second set of policies.

28. The method according to claim 27, further comprising: placing the entry in the first queue when the second set of policies is satisfied; as well as When the second set of policies is not satisfied, the entry is placed in the second queue.

29. The method of claim 24, wherein: The entry corresponds to information received from a virtual node hosted by the blockchain-as-a-service provider.

30. The method of claim 24, further comprising: When consensus is achieved, a new block is generated including the entry.

31. A non-transitory computer-readable medium comprising instructions, which, when read by a manager of a blockchain-as-a-service provider, cause the manager to implement the steps in the method according to any one of claims 24-30.

32. A system for implementing blockchain as a service, comprising: A first virtual node, which includes a first blockchain software; A second virtual node, which includes a second blockchain software; as well as A manager for controlling the transmission of information between the first virtual node and the second virtual node, wherein the first virtual node and the second virtual node are hosted by a blockchain-as-a-service provider, and wherein the information is transmitted along an internal signal path of the blockchain-as-a-service provider and corresponds to a block in a blockchain that includes entries for the first virtual node and the second virtual node.

33. The system of claim 32, wherein: The blockchain-as-a-service provider includes a first server and a second server; The first server manages the first virtual node; and The second server manages the second virtual node.

34. The system of claim 33, wherein: The internal signal path is coupled between the first server and the second server.

35. The system of claim 32, wherein: The first blockchain software is coupled to a blockchain application at a first node external to the blockchain-as-a-service provider; as well as The second blockchain software is coupled to a blockchain application at a second node external to the blockchain-as-a-service provider.

36. The system of claim 35, wherein: The first blockchain software is used to receive the information from the blockchain application at the first node.

37. The system of claim 32, wherein: The first virtual node also includes a blockchain application; and The blockchain application is configured to receive the information from a network coupled to the blockchain-as-a-service provider.

38. The system of claim 32, wherein: The manager is used to control the transmission of additional information that is not included in the block of the blockchain between the first virtual node and the second virtual node.

39. A method for implementing blockchain as a service, comprising: Hosting a first virtual node in a blockchain-as-a-service provider, which includes a first blockchain software; hosting a second virtual node in the blockchain-as-a-service provider, which includes a second blockchain software; as well as Control the transmission of information between the first virtual node and the second virtual node along an internal signal path of the blockchain-as-a-service provider, wherein the information corresponds to a block in a blockchain that includes entries for the first virtual node and the second virtual node.

40. The method of claim 39, wherein: The blockchain-as-a-service provider includes a first server and a second server; The first server manages the first virtual node; and The second server manages the second virtual node.

41. The method of claim 40, wherein: The internal signal path is coupled between the first server and the second server.

42. The method of claim 39, wherein: The first blockchain software is coupled to a blockchain application at a first node external to the blockchain-as-a-service provider; as well as The second blockchain software is coupled to a blockchain application at a second node external to the blockchain-as-a-service provider.

43. The method of claim 42, wherein: The first blockchain software receives the information from the blockchain application at the first node.

44. The method of claim 39, wherein: The first virtual node also includes a blockchain application; and The blockchain application is configured to receive the information from a network coupled to the blockchain-as-a-service provider.

45. The method of claim 39, further comprising: Controlling transmission of additional information not included in a block of the blockchain between the first virtual node and the second virtual node.

46. ​​A non-transitory computer-readable medium comprising instructions that, when read by logic of a blockchain-as-a-service provider, cause the logic to implement the steps of the method according to any one of claims 39-45.

Images