Abstract: A task scheduling method and system, and a hardware task scheduler are disclosed, and pertain to the field of computer technologies. The hardware task scheduler provides task scheduling for a central processing unit CPU core to select a candidate task. After selecting the candidate task, the CPU core actively sends metadata of the candidate task to a first storage area, and actively sends a context of the candidate task to a cache, where the first storage area is located in storage space whose access speed is higher than that of a memory. When performing task switching, the CPU core reads the metadata of the candidate task from the first storage area, and reads the context of the candidate task from the cache. In this way, latency of obtaining the metadata and the context of the candidate task by the CPU core is reduced, and low-latency task switching is implemented.

Abstract: The technologies described herein are generally directed to deploying network equipment. For example, a method described herein can include facilitating receiving a first request to deploy first network equipment at a deployment location, with the first request including a first deployment parameter for the first network equipment. The method further includes, based on the first network equipment and the first deployment parameter, generating a deployment template. Further, the method can facilitate receiving a second request to deploy second network equipment at the deployment location, with the second request including a second deployment parameter for the second network equipment. The method can further include, based on the deployment template and the second deployment parameter, deploying the second network equipment.

Abstract: The technologies described herein are generally directed to deploying network equipment. For example, a method described herein can include facilitating receiving a first request to deploy first network equipment at a deployment location, with the first request including a first deployment parameter for the first network equipment. The method further includes, based on the first network equipment and the first deployment parameter, generating a deployment template. Further, the method can facilitate receiving a second request to deploy second network equipment at the deployment location, with the second request including a second deployment parameter for the second network equipment. The method can further include, based on the deployment template and the second deployment parameter, deploying the second network equipment.

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: 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 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: The technologies described herein are generally directed to deploying network equipment. For example, a method described herein can include facilitating receiving a first request to deploy first network equipment at a deployment location, with the first request including a first deployment parameter for the first network equipment. The method further includes, based on the first network equipment and the first deployment parameter, generating a deployment template. Further, the method can facilitate receiving a second request to deploy second network equipment at the deployment location, with the second request including a second deployment parameter for the second network equipment. The method can further include, based on the deployment template and the second deployment parameter, deploying the second network equipment.

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: A target transaction initiated by a member node device in a blockchain is received, where the target transaction include a reference time parameter, and where the target transaction indicates a transfer of an asset and associated data released by the member node device to the blockchain for transfer to a candidate block. Based on the reference time parameter, a determination is performed as to whether the target transaction is a valid transaction within a transaction validity period. In response to determining that the target transaction is a valid transaction within the transaction validity period, the target transaction is recorded to the candidate block.

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: Aspects of the subject disclosure may include, for example, providing a graphical user interface on a display device for interaction with operations personnel associated with a process to be performed; receiving, from the operations personnel, information defining one or more tasks to perform the process; receiving, from technical personnel associated with respective task of the one or more tasks, respective rulesets associated with the respective tasks, each respective ruleset defining procedures to complete a respective task, one or more of the respective rulesets implementing a machine learning algorithm to complete the respective task; displaying information about the one or more tasks on the graphical user interface during performance of the process; estimating, with an artificial intelligence process, a current status of the process, producing a current status estimate, wherein the estimating comprises estimating a status of the machine learning algorithm; and displaying process status information on th

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 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: The technologies described herein are generally directed to deploying network equipment. For example, a method described herein can include facilitating receiving a first request to deploy first network equipment at a deployment location, with the first request including a first deployment parameter for the first network equipment. The method further includes, based on the first network equipment and the first deployment parameter, generating a deployment template. Further, the method can facilitate receiving a second request to deploy second network equipment at the deployment location, with the second request including a second deployment parameter for the second network equipment. The method can further include, based on the deployment template and the second deployment parameter, deploying the second network equipment.

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: 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: Methods, systems and computer readable media for self-configuration of virtual network functions based on user intent are provided. In a network, a destination with an initial offering having a set of initial offering attributes is provided. A first virtual network function is connected to the destination that is capable of advertising the initial offering. A source having a set of need attributes defined by a user is also provided. The initial offering is advertised, and the source is connected to the first virtual network function. A second virtual network function with an added value is added and a modified offering having a set of modified attributes based on the set of initial offering attributes and the added value is created. The initial offering and the modified offering is advertised to the source.

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.