International Business Machines Corporation

Senthilnathan Natarajan

Balaji Viswanathan

Praveen Jayachandran

Krishnasuri Narayanam

Vinayaka D Pandit

Chander Govindarajan

Manish Sethi

Adarsh Saraf

Angelo De Caro

Artem Barger

Alessandro Sorniotti

Yacov Manevich

Venkatraman Ramakrishna

Emanuele Ragnoli

Yoav Tock

Yohei Ueda

Marko Vukolić

Gennady Laventman

Chun Hui Suen

Methods, systems, and computer program products for distributed scheduling in container orchestration engines are provided herein. A computer-implemented method includes: configuring a plurality of entities of a container-based computing environment to perform a distributed scoring process, wherein, for a given one of the entities, the distributed scoring process comprises: (i) obtaining information corresponding to a plurality of workloads from a database that is accessible to the other entities, (ii) generating, based on the information, respective scores for at least a portion of the plurality of workloads, and (iii) publishing the generated scores to the database; and selecting, by a centralized scheduler of the container-based computing environment, at least one of the entities to host at least a given one of workloads based at least in part on the generated scores in the database.

Distributed scheduling in container orchestration engines

A processor may store a write set of a transaction in a cache. The cache may include state information, and the cache may be uncommitted to a blockchain. The processor may identify a subsequent transaction. The subsequent transaction may read from the cache when a requested key is present in the cache. The processor may order the transaction and the subsequent transaction based on what is read from the cache. Ordering the transaction and the subsequent transaction may avoid an abort of the subsequent transaction.

Reducing transaction aborts in execute-order-validate blockchain models

An example operation may include one or more of connecting, by a lead peer, to a blockchain network of an organization configured to store assets, receiving, by the lead peer, from an ordering server, a block that contains a plurality of chaincode transactions belonging to plurality of peers of the blockchain network, applying, by the lead peer, a filter to the block, determining, by the lead peer, a recipient peer of the block in response to the application of the filter, receiving, by the lead peer, a validation result of the block from the recipient peer, and committing, by the lead peer, the block to the blockchain network.

Sparse peer with transient participation

An example operation may include one or more of connecting, by a sparse peer, to a blockchain network of a plurality of peers controlled by orderers, selecting, by the sparse peer, a subset of data to be replicated, specifying, by the sparse peer, data selection filters based on the selected subset of the data, providing, by the sparse peer, the selection filters to the plurality of the peers, receiving, by the sparse peer, blocks matching the selection filters over a gossip protocol from the plurality of the peers, constructing, by the sparse peer, a local ledger of the sparse peer from the received blocks, and bootstrapping the sparse peer based on the local ledger.

An example operation may include one or more of connecting, by a lead peer, to a blockchain network of an organization configured to store assets, receiving, by the lead peer, a block from an ordering server, that contains a plurality of chaincode transactions belonging to a plurality of peers of the blockchain, applying, by the lead peer, a filter to the block, determining, by the lead peer, a recipient peer of the block in response to the application of the filter, and receiving, by the lead peer, a notification of validation and commitment of the block to the blockchain by the recipient peer.

Maintaining, for each target key in a key-value computer database, a signature policy; creating a transaction candidate in the database based on a transaction context submitted to the database by a first user, the transaction candidate comprising: a key, a value comprising a transaction content and a signature of the first user, and a signors list of additional one or more users who are required to co-sign the transaction candidate before the transaction candidate is committed in the database as a transaction, wherein the signors list is automatically computed based on the signature policies of the one or more target keys; collecting a signature for the transaction candidate from at least one of the additional one or more users, according to the signors list; verifying that all signatures required by the signors list have been collected; and in response to the verification, committing the transaction content of the transaction candidate.

Multi-party transactions in a computerized database

An example operation may include one or more of receiving, via a network, a blockchain request from a client device, simulating a transaction of the blockchain request to generate a read set of data being read by the transaction and a write set of data being written by the transaction, determining whether to endorse the transaction with respect to a distributed ledger by executing customizable endorsement logic of the blockchain node, wherein the executing customizable endorsement logic receives, as input, the generated read and write sets and determines whether or not the transaction should be committed to a data block of the distributed ledger based on the generated read and write sets, and transmitting information about a result of the customized endorsement logic determination to the client device.

Customized endorsement logic for blockchain

An example operation may include one or more of retrieving, into a new node to be instantiated in a blockchain network, a state database checkpoint of a state database created at a block number of a blockchain of the blockchain network, retrieving, into the new node, blocks of the blockchain from the checkpoint block number to a current block number, constructing an initial state database from the received state database checkpoint, and executing, at the new node, the transactions of the retrieved blocks on the initial state database to generate a current state database.

Checkpointing for increasing efficiency of a blockchain

An example operation may include one or more of a processor configured to receive a database command from a client system, the database command comprising a database function and parameters to be used by the database function, and to execute the database command on database data, and an interface configured to transmit the database command to one or more other databases that are within a decentralized database system in which each database node is controlled by a different entity, wherein in response to receiving a request from an ordering node of the decentralized database system, the processor may commit results of executing the database command to a database and store information about the database command in an append-only immutable database log.

Distributed database having blockchain attributes

An example operation may include one or more of connecting, by a sparse peer, to a blockchain network of a plurality of peers controlled by orderers, configuring the sparse peer to operate with a partial state of a chain to reduce a bootstrap time of the sparse peer, specifying, by the sparse peer, data selection filters based on the partial state of the chain, receiving, by the sparse peer, blocks that match the selection filters from the plurality of the peers via a gossip, storing, by the sparse peer, the blocks in a ledger of the sparse peer, determining, by the sparse peer, if the ledger of the sparse peer is up-to-date based on the partial state of the chain, and in response to the determination that the ledger of the sparse peer is up-to-date, bootstrapping the sparse peer.

An example operation may include one or more of in one or more peer nodes of a plurality of peer nodes of a blockchain network that stores a blockchain and a state database, periodically generating a state database checkpoint, obtaining a consensus on the state database checkpoint from one or more of the one or more peer nodes, and storing the consensus state database checkpoint.

An example operation may include one or more of retrieving, into a corrupted node in a blockchain network that is at least one corrupted or forked, a state database checkpoint of a state database created at a block number of a blockchain of the blockchain network, wherein the retrieved state database checkpoint comprises a last known non-corrupted or non-forked checkpoint state, retrieving, into the corrupted node, blocks of the blockchain from the checkpoint block number to a current block number, constructing an initial state database from the retrieved state database checkpoint, and executing, at the corrupted node, the transactions of the retrieved blocks on the initial state database to generate a current state database.

An example operation may include one or more of identifying endorsement requests to perform blockchain transaction endorsements, transmitting the endorsement requests to an ordering node, monitoring performance metrics of endorsement blockchain peers, assigning the endorsement requests to the endorsement blockchain peers based on the performance metrics, and receiving endorsed blockchain transactions.

Secure consensus-based endorsement for self-monitoring blockchain

An example operation may include one or more of receiving a request comprising a file segmented into a plurality of segments corresponding to a plurality of storage nodes, identifying a segment from among the plurality of segments which is designated for the storage node from among remaining segments designated for other storage nodes, storing the identified segment in a local storage of the storage node, hashing the identified segment, and transmitting a response to a client system which includes the hashed identified segment.

Growing community of inventors

Bengaluru, India

Senthilnathan Natarajan