Abstract: A computer-implemented method includes retrieving, by a bridge device communicatively linked to a blockchain network node of a blockchain network, a first set of blockchain blocks from the blockchain network node using a first set of threads of the bridge device; storing, by the bridge device, the first set of blockchain blocks in the bridge device; and verifying, by the bridge device, a second set of blockchain blocks that are stored in the bridge device using a second set of threads of the bridge device; and wherein retrieving the first set of blockchain blocks and verifying the second set of blockchain blocks are performed asynchronously using the first set of threads and the second set of threads.

Abstract: A method for managing systems with interrelated microservices with self-assembling and self-configuring microservices includes receiving at a first micro service a service request from a client. A determination is the made whether the first micro service is capable of processing the service request. If the first micro service is capable of processing the service requests, then processing the service request; if the first micro service cannot process the service request then routing the service request to a first stem service. The first stem service determines whether there is a second micro service that can process the service request. If the second micro service that can process the service requests exists, then forwarding the service request to the second micro service for processing. If there is no second micro service that can service the service requests then morphing the first stem service into a micro service that can service the service request.

Abstract: A system for managing systems with interrelated microservices with self-assembling and self-configuring microservices includes a plurality of host resource services microservices, a plurality of directory services microservices and a plurality of tenant microservices. Each of the microservices is provided with an API with a standard way to identify the API and its components, which together identify the functionality of the API in a common way. The host resources service microservice are started up in a host. A determination is made whether there is a directory service microservice running in the host and, if there is none, then spinning up a directory service microservice. A plurality of tenant microservices are installed and a determination is made whether all tenant microservices are running, If not, then copies of the tenant microservices that are not running are spun up.

Abstract: A method for managing systems with interrelated microservices with self-assembling and self-configuring microservices includes receiving at a first micro service a service request from a client. A determination is the made whether the first micro service is capable of processing the service request. If the first micro service is capable of processing the service requests, then processing the service request; if the first micro service cannot process the service request then routing the service request to a first stem service. The first stem service determines whether there is a second micro service that can process the service request. If the second micro service that can process the service requests exists, then forwarding the service request to the second micro service for processing. If there is no second micro service that can service the service requests then morphing the first stem service into a micro service that can service the service request.

Abstract: A computer-implemented method for processing blockchain-based transactions, the computer-implemented method including: receiving a target transaction initiated by a member node device in a blockchain, wherein the target transaction comprises a unique identifier of the target transaction; querying a transaction idempotent table on the block chain to determine whether the transaction idempotent table has stored a transaction idempotent record corresponding to the unique identifier of the target transaction; and in response to determining that the transaction idempotent table has not stored the transaction idempotent record corresponding to the unique identifier of the target transaction, recording the target transaction in a candidate block on the blockchain.

Abstract: Implementations of the present specification include receiving a request to perform a private transaction associated with at least one account; in response to receiving the request, performing, by a workflow node, the private transaction; in response to performing the private transaction, generating, by the workflow node, a representation of the private transaction configured to be accessible only to entities that are authorized to access the private transaction; storing, in a private blockchain, the representation of the private transaction; generating, by the workflow node, an account record for the at least one account associated with the private transaction based at least in part on the private transaction, wherein the account record is configured to be accessible to at least one entity that is not authorized to access the representation of the private transaction in the private blockchain; and storing, in a public blockchain, the account record.

Abstract: This specification describes techniques for blockchain-based smart contract call. One example method includes receiving a target transaction initiated by a client device of a blockchain, wherein the target transaction is preconfigured for a call rule used to initiate a call for a smart contract; obtaining the call rule preconfigured for the target transaction; executing the call rule to initiate a call for a target smart contract; and providing a call result to the client device when the call for the target smart contract is completed.

Abstract: A computer-implemented method includes retrieving, by a bridge device communicatively linked to a blockchain network node of a blockchain network, a first set of blockchain blocks from the blockchain network node using a first set of threads of the bridge device; storing, by the bridge device, the first set of blockchain blocks in the bridge device; and verifying, by the bridge device, a second set of blockchain blocks that are stored in the bridge device using a second set of threads of the bridge device; and wherein retrieving the first set of blockchain blocks and verifying the second set of blockchain blocks are performed asynchronously using the first set of threads and the second set of threads.

Abstract: A method for processing blockchain-based transactions, comprising: acquiring a Nonce record from a Nonce list for a transaction initiated by a user account, wherein the Nonce list is maintained in a blockchain and is associated with the user account, the Nonce list comprises a plurality of Nonce records, and a Nonce record comprises a Nonce value; adding the acquired Nonce record to the transaction; and submitting the transaction to the blockchain, for a node in the blockchain to compare the Nonce record in the transaction with the plurality of Nonce records in the Nonce list, and to accept the transaction in response to the Nonce record matching any Nonce record in the Nonce list, wherein the Nonce value in the matching Nonce record in the Nonce list is monotonically increased based on a preset increment in response to that the transaction is accepted.

Abstract: Implementations of the present specification include receiving a request to perform a private transaction associated with at least one account; in response to receiving the request, performing, by a workflow node, the private transaction; in response to performing the private transaction, generating, by the workflow node, a representation of the private transaction configured to be accessible only to entities that are authorized to access the private transaction; storing, in a private blockchain, the representation of the private transaction; generating, by the workflow node, an account record for the at least one account associated with the private transaction based at least in part on the private transaction, wherein the account record is configured to be accessible to at least one entity that is not authorized to access the representation of the private transaction in the private blockchain; and storing, in a public blockchain, the account record.

Abstract: A computer-implemented method for processing blockchain-based transactions, the computer-implemented method including: receiving a target transaction initiated by a member node device in a blockchain, wherein the target transaction comprises a unique identifier of the target transaction; querying a transaction idempotent table on the block chain to determine whether the transaction idempotent table has stored a transaction idempotent record corresponding to the unique identifier of the target transaction; and in response to determining that the transaction idempotent table has not stored the transaction idempotent record corresponding to the unique identifier of the target transaction, recording the target transaction in a candidate block on the blockchain.

Abstract: A computer-implemented method includes retrieving, by a bridge device communicatively linked to a blockchain network node of a blockchain network, a first set of blockchain blocks from the blockchain network node using a first set of threads of the bridge device; storing, by the bridge device, the first set of blockchain blocks in the bridge device; and verifying, by the bridge device, a second set of blockchain blocks that are stored in the bridge device using a second set of threads of the bridge device; and wherein retrieving the first set of blockchain blocks and verifying the second set of blockchain blocks are performed asynchronously using the first set of threads and the second set of threads.

Abstract: Embodiments of the present specification provide example blockchain-based data processing methods, mediums, and systems. One example method includes obtaining an available Nonce record for a target transaction from a Nonce list. The Nonce list comprises Nonce records, and each Nonce record comprises a version identifier of the Nonce list and a Nonce value. The available Nonce record to the target transaction is added. The target transaction in a blockchain is published. Prompt information indicating that the target transaction is an invalid transaction is received when a version identifier in the available Nonce record does not match the version identifier of the Nonce list; or a notification message indicating that the target transaction is processed is received when the version identifier in the available Nonce record matches the version identifier of the Nonce list and a replay attack detection is successfully performed by matching the available Nonce record with a Nonce record in the Nonce list.

Abstract: One or more embodiments of the present specification provide blockchain-based transaction methods, apparatuses, and electronic devices. A target transaction sent by a node device of a transaction initiator is received. An account of the transaction initiator corresponds to a plurality of public keys, and the target transaction includes transaction content and a digital signature. The digital signature is created by using one or more private keys corresponding to the plurality of public keys of the account and is created based on at least a part of the transaction content. The target transaction is verified, including verifying whether the digital signature is valid. In response to a successful verification, the target transaction is recorded to a distributed database of a blockchain based on a consensus rule of the blockchain.

Abstract: A blockchain-based transaction processing method is disclosed, and includes a client device determining that a plurality of transactions initiated by a user through a user account need to be executed in parallel; in response to determining the plurality of transactions need to be executed in parallel, adding a group identifier to the plurality of transactions so that each transaction in the plurality of transaction has the group identifier and the group identifier for the plurality of transactions is the same; and publishing the plurality of transactions in a blockchain, wherein a node device in the blockchain executes a plurality of transactions with a same group identifier in parallel after processing the transaction published by the client device.

Abstract: A plurality of transactions initiated by a user through a user account and need to be concurrently executed is received. A Nonce list corresponding to the user account and maintained in a blockchain is accessed. The Nonce list includes a plurality of Nonce records, and each Nonce record includes a group identifier and a Nonce value. Available Nonce records are obtained for the plurality of transactions from the Nonce list. The available Nonce records are respectively added to the plurality of transactions. The plurality of transactions are published in the blockchain, so that a node device in the blockchain matches the available Nonce record in a transaction published by the client device with the Nonce records in the Nonce list. When the available Nonce record matches a target Nonce record in the Nonce list, the node device processes the transaction, and concurrently executes a plurality of the processed transactions.

Abstract: This specification describes techniques for blockchain-based smart contract call. One example method includes receiving a target transaction initiated by a client device of a blockchain, wherein the target transaction is preconfigured for a call rule used to initiate a call for a smart contract; obtaining the call rule preconfigured for the target transaction; executing the call rule to initiate a call for a target smart contract; and providing a call result to the client device when the call for the target smart contract is completed.

Abstract: Implementations of the present specification include receiving a request to perform a private transaction associated with at least one account; in response to receiving the request, performing, by a workflow node, the private transaction; in response to performing the private transaction, generating, by the workflow node, a representation of the private transaction configured to be accessible only to entities that are authorized to access the private transaction; storing, in a private blockchain, the representation of the private transaction; generating, by the workflow node, an account record for the at least one account associated with the private transaction based at least in part on the private transaction, wherein the account record is configured to be accessible to at least one entity that is not authorized to access the representation of the private transaction in the private blockchain; and storing, in a public blockchain, the account record.

Abstract: One or more implementations of the present specification provide a blockchain-based data processing method and device. Block data in a blockchain is synchronized by a data center to a local database of the data center. The data center is connect to the blockchain and a target application. A data usage request sent by the target application is received by the data center. In response to the data usage request, the local database is queried, by the data center, for requested data corresponding to the data usage request. The requested data is returned, by the data center, to the target application.

Abstract: A method for managing systems with interrelated microservices with self-assembling and self-configuring microservices includes receiving at a first micro service a service request from a client. A determination is the made whether the first micro service is capable of processing the service request. If the first micro service is capable of processing the service requests, then processing the service request; if the first micro service cannot process the service request then routing the service request to a first stem service. The first stem service determines whether there is a second micro service that can process the service request. If the second micro service that can process the service requests exists, then forwarding the service request to the second micro service for processing. If there is no second micro service that can service the service requests then morphing the first stem service into a micro service that can service the service request.