Patent Description:
The disclosure herein generally relates to the field of blockchain and, more particular, to a method and system for weight based slotted synchronous blockchain client network for collision free transaction broadcast.

Blockchain is a method of recording information that makes it impossible or difficult for the system to be changed, hacked, or manipulated. A blockchain is a distributed ledger that duplicates and distributes transactions across the network of computers participating in the blockchain. Blockchains are mainly used in applications in a decentralized setting like digital transactions where delay is not acceptable. Hence in order to enable good Quality of Service (QoS) for the customers, these transactions executions/commits need to be fast, robust and secure and thus calls for minimal latency in transaction commits. For example, cryptographic currencies such as Bitcoin can enable new applications, such as smart contracts and fair protocols to simplify currency conversions, and to avoid trusted centralized authorities that regulate transactions.

However, conventional approaches suffer from a trade-off between latency and confidence in a transaction. For example, achieving a high confidence that a transaction has been confirmed in Bitcoin requires about an hour long wait. On the other hand, applications that require low latency cannot be certain that their transaction will be confirmed and must trust the payer to not double-spend. Conventional blockchain consensus protocols heavily rely on synchrony assumptions of the underlying network. However, little attention has so far been given to similar assumptions on blockchain client networks. Such assumptions would be useful in deriving bounds on confirmation times of transactions through the blockchain protocol.

NPL document<NPL>) discloses a slotted client network for a blockchain that is used to have bounded validation delays. Clients send transaction requests only in one slot at a time.

NPL document <NPL>) discloses further details on the proof of stake scheme used in AHUJA ADITYA ET AL.

Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one embodiment, a method for weight based slotted synchronous blockchain client network for collision free transaction broadcast is provided. The method includes receiving, via an interface associated with a source client node, a blockchain transaction request from a user associated with a source client node from among a plurality of client nodes associated with a blockchain client network, wherein the blockchain client network is a weight based slotted synchronous network, and wherein the blockchain client network comprises the plurality of client nodes, a plurality of consensus nodes and a plurality of routers. Further, the method includes obtaining, by one or more hardware processors of the source client node, a network-level information associated with the blockchain transaction request using a network data extraction technique. Furthermore, the method includes obtaining, by the one or more hardware processors of the source client node, a plurality of delays associated with each of a plurality of path routers placed between the source client node and the destination consensus node based on the network-level information using delay detection techniques. Furthermore, the method includes obtaining, by the one or more hardware processors of the source client node, a transmission slot associated with the source client node only if a sum of the plurality of delays associated with plurality of path routers is less than or equal to a slot epoch length, wherein the transmission slot associated with the source client node is generated using a dynamic slot allocation technique, wherein the dynamic slot allocation technique is one of, (a) an uniform client slot allocation and (b) a Stake based client slot allocation. Finally, the method includes broadcasting, by the one or more hardware processors of the source client node, the blockchain transaction request from the source client node into the plurality of consensus nodes simultaneously based on the obtained transmission slot, wherein the blockchain transaction request is signed using a private key of the user prior to broadcasting and, wherein the broadcasted blockchain transaction request is received by the plurality of consensus nodes.

In another aspect, a system for weight based slotted synchronous blockchain client network for collision free transaction broadcast is provided. The system includes a client network comprising a plurality of clients, a blockchain network comprising a plurality of consensus nodes, wherein a source client node from the client network comprises at least one memory storing programmed instructions; one or more Input /Output (I/O) interfaces; and one or more hardware processors operatively coupled to the at least one memory, wherein the one or more hardware processors of the source client node is configured by the programmed instructions to receive a blockchain transaction request from a user associated with a source client node from among a plurality of client nodes associated with a blockchain client network, wherein the blockchain client network is a weight based slotted synchronous network, and wherein the blockchain client network comprises the plurality of client nodes, a plurality of consensus nodes and a plurality of routers. Further, the one or more hardware processors of the source client node is configured by the programmed instructions to obtain a network-level information associated with the blockchain transaction request using a network data extraction technique. Furthermore, the one or more hardware processors of the source client node is configured by the programmed instructions to obtain a plurality of delays associated with each of a plurality of path routers placed between the source client node and the destination consensus node based on the network-level information using delay detection techniques. Furthermore, the one or more hardware processors of the source client node is configured by the programmed instructions to obtain a transmission slot associated with the source client node only if a sum of the plurality of delays associated with plurality of path routers is less than or equal to a slot epoch length, wherein the transmission slot associated with the source client node is generated using a dynamic slot allocation technique, wherein the dynamic slot allocation technique is one of, (a) an uniform client slot allocation and (b) a Stake based client slot allocation. Finally, the one or more hardware processors of the source client node is configured by the programmed instructions to broadcast the blockchain transaction request from the source client node into the plurality of consensus nodes simultaneously based on the obtained transmission slot, wherein the blockchain transaction request is signed using a private key of the user prior to broadcasting and, wherein the broadcasted blockchain transaction request is received by the plurality of consensus nodes.

In yet another aspect, a computer program product including a non-transitory computer-readable medium having embodied therein a computer program for weight based slotted synchronous blockchain client network for collision free transaction broadcast is provided. The computer readable program, when executed on a computing device, causes the computing device to receive a blockchain transaction request from a user associated with a source client node from among a plurality of client nodes associated with a blockchain client network, wherein the blockchain client network is a weight based slotted synchronous network, and wherein the blockchain client network comprises the plurality of client nodes, a plurality of consensus nodes and a plurality of routers. Further, the computer readable program, when executed on a computing device, causes the computing device to obtain a network-level information associated with the blockchain transaction request using a network data extraction technique. Furthermore, the computer readable program, when executed on a computing device, causes the computing device to obtain a plurality of delays associated with each of a plurality of path routers placed between the source client node and the destination consensus node based on the network-level information using delay detection techniques. Furthermore, the computer readable program, when executed on a computing device, causes the computing device to obtain a transmission slot associated with the source client node only if a sum of the plurality of delays associated with plurality of path routers is less than or equal to a slot epoch length, wherein the transmission slot associated with the source client node is generated using a dynamic slot allocation technique, wherein the dynamic slot allocation technique is one of, (a) an uniform client slot allocation and (b) a Stake based client slot allocation. Finally, the computer readable program, when executed on a computing device, causes the computing device to broadcast the blockchain transaction request from the source client node into the plurality of consensus nodes simultaneously based on the obtained transmission slot, wherein the blockchain transaction request is signed using a private key of the user prior to broadcasting and, wherein the broadcasted blockchain transaction request is received by the plurality of consensus nodes.

While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the spirit and scope of the disclosed embodiments.

Blockchains are mainly used in applications like digital transactions where delay is not acceptable. Hence in order to enable good Quality of Service (QoS) for the customers, these transactions executions/commits need to be fast, robust and secure and thus calls for minimal latency in transaction commits. For example, cryptographic currencies such as Bitcoin can enable new applications, such as smart contracts and fair protocols to simplify currency conversions, and to avoid trusted centralized authorities that regulate transactions.

Conventional blockchain consensus protocols heavily rely on synchrony assumptions of the underlying network. However, little attention has so far been given to similar assumptions on blockchain client networks. Such assumptions would be useful in deriving bounds on confirmation times of transactions through the blockchain protocol.

To overcome the challenges of the conventional approaches, embodiments herein provide a weight based slotted synchronous blockchain client network. The blockchain client network of the present disclosure is slotted, wherein at most one transaction is submitted in each slot by one of the client nodes. Further, there exists a notion of synchrony in the peering between the client nodes and the blockchain nodes. In an embodiment, for each submitted transaction, there is an upper-bound on the number of slots on the reception of the said transaction at an arbitrary blockchain node.

<FIG> is a networking architecture for a system <NUM> for weight based slotted synchronous blockchain client network for collision free transaction broadcast, in accordance with some embodiments of the present disclosure. The architecture of system <NUM> includes a client network <NUM> comprising a plurality of client nodes, a blockchain network <NUM> comprising a plurality of blockchain/consensus nodes and a plurality of routers <NUM>. The blockchain network further includes a distributed ledger, consensus algorithms, proof of work and proof of stake. The plurality of blockchain/consensus nodes honestly follows a specified blockchain consensus algorithm. A blockchain consensus algorithm is a protocol through which all peers of a blockchain network reach a common agreement about the present state of the distributed ledger. Essentially, the consensus protocol makes sure that every new block that is added to the blockchain is the one and only version of the truth that is agreed upon by all the nodes in the blockchain. The blockchain consensus protocol includes some specific objectives such as coming to an agreement, collaboration, cooperation, equal rights to every node, and participation of each node in the consensus process. Each router is an air traffic controller which directs data packets between the client network <NUM> and the blockchain network <NUM>. To direct packets effectively, the router uses an internal dynamic routing table (a list of paths to various network destinations). The router reads a packet's header to determine where it is going, then consults the routing table to figure out the most efficient path to that destination. It then forwards the packet to the next network in the path.

The client network <NUM>, the blockchain network <NUM> and the plurality of routers <NUM> are connected via network connections <NUM> and <NUM>. In an embodiment, the network connections <NUM> and <NUM> is a wired communication network or a wireless communication network. In an embodiment, each of the plurality of client nodes of the client network <NUM> are connected to each other via respective networking interfaces. Each of the plurality of consensus nodes of the blockchain network <NUM> are connected to each other via respective networking interfaces and each of the plurality of routers <NUM> are connected to each other via respective networking interfaces.

<FIG> is a functional block diagram <NUM> of client nodes, consensus nodes and routers of the system <NUM> for weight based slotted synchronous blockchain client network for collision free transaction broadcast, implemented by the architecture of <FIG>, in accordance with some embodiments of the present disclosure. The system <NUM> includes or is otherwise in communication with hardware processors <NUM>, at least one memory such as a memory <NUM>, an I/O interface <NUM>. The hardware processors <NUM>, memory <NUM>, and the Input /Output (I/O) interface <NUM> may be coupled by a system bus such as a system bus <NUM> or a similar mechanism. In an embodiment, the hardware processors <NUM> can be one or more hardware processors.

The I/O interface <NUM> may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface <NUM> may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a printer and the like. Further, the I/O interface <NUM> may enable the system <NUM> to communicate with other devices, such as web servers, and external databases.

The I/O interface <NUM> can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the I/O interface <NUM> may include one or more ports for connecting several computing systems with one another or to another server computer. The I/O interface <NUM> may include one or more ports for connecting several devices to one another or to other devices such as the client nodes of the client network, routers and the consensus nodes of the blockchain network.

The one or more hardware processors <NUM> may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, node machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors <NUM> is configured to fetch and execute computer-readable instructions stored in the memory <NUM>.

The memory <NUM> may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an embodiment, the memory <NUM> includes a plurality of modules <NUM>. The memory <NUM> also includes a data repository (or repository) <NUM> for storing data processed, received, and generated by the plurality of modules <NUM>.

The plurality of modules <NUM> include programs or coded instructions that supplement applications or functions performed by the system <NUM> for weight based slotted synchronous blockchain client network for collision free transaction broadcast. The plurality of modules <NUM>, amongst other things, can include routines, programs, objects, components, and data structures, which performs particular tasks or implement particular abstract data types. The plurality of modules <NUM> may also be used as, signal processor(s), node machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the plurality of modules <NUM> can be used by hardware, by computer-readable instructions executed by the one or more hardware processors <NUM>, or by a combination thereof. The plurality of modules <NUM> can include various sub-modules (not shown). The plurality of modules <NUM> may include computer-readable instructions that supplement applications or functions performed by the system <NUM> for weight based slotted synchronous blockchain client network for collision free transaction broadcast.

The data repository (or repository) <NUM> may include a plurality of abstracted piece of code for refinement and data that is processed, received, or generated as a result of the execution of the plurality of modules in the module(s) <NUM>.

Although the data repository <NUM> is shown internal to the system <NUM>, it will be noted that, in alternate embodiments, the data repository <NUM> can also be implemented external to the system <NUM>, where the data repository <NUM> may be stored within a database (repository <NUM>) communicatively coupled to the system <NUM>. The data contained within such external database may be periodically updated. For example, new data may be added into the database (not shown in <FIG>) and/or existing data may be modified and/or non-useful data may be deleted from the database. In one example, the data may be stored in an external system, such as a Lightweight Directory Access Protocol (LDAP) directory and a Relational Database Management System (RDBMS).

<FIG> is an exemplary flow diagram illustrating the processor implemented method <NUM> for weight based slotted synchronous blockchain client network for collision free transaction broadcast implemented by a client node of <FIG>, in accordance with some embodiments of the present disclosure.

In an embodiment, the system <NUM> includes one or more data storage devices or the memory <NUM> operatively coupled to the one or more hardware processor(s) <NUM> and is configured to store instructions for execution of steps of the method <NUM> by the one or more hardware processors <NUM>. The steps of the method <NUM> of the present disclosure will now be explained with reference to the components or blocks of the system <NUM> and the system <NUM> as depicted in <FIG> and <FIG> and the steps of flow diagram as depicted in <FIG>. The method <NUM> may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, functions, etc., that perform particular functions or implement particular abstract data types. The method <NUM> may also be practiced in a distributed computing environment where functions are performed by remote processing devices that are linked through a communication network. The order in which the method <NUM> is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method <NUM>, or an alternative method. Furthermore, the method <NUM> can be implemented in any suitable hardware, software, firmware, or combination thereof.

At step <NUM> of the method <NUM>, the one or more hardware processors <NUM> of a source client node, are configured by the programmed instructions to receiving a blockchain transaction request from a user via an interface associated with a source client node from among a plurality of client nodes associated with a blockchain client network.

In an embodiment, the blockchain client network is a weight based slotted synchronous network, wherein the blockchain client network comprises the plurality of client nodes [m] := { <NUM>,<NUM>,. , m }, a plurality of consensus nodes [n] : = { <NUM>,<NUM>,. , n} and a plurality of routers. Each of the plurality of client nodes are associated with a plurality of weights. The plurality of weights includes a slot weight and a transmission weight. Peering between each of the plurality of client nodes and each of the plurality of consensus nodes in the blockchain client network is performed based on the plurality of weights. The blockchain client network is associated with a Collision Resistant Hash Function (CRHF) and a signature scheme S. For example, SHA-<NUM> is used as CRHF and the ElGamal/RSA is used as the signature scheme.

In an embodiment, each client i ∈ [m] has a slot allocation weight <MAT> a transmission delay weight <MAT> (both positive integers). There exists positive integer ΔC such that <MAT>. B(k; p, W) denote a binomial distribution. Here, B is a Binomial distribution as part of cryptographic sortition, k; p, W are distribution parameters. Slot epochs will be denoted by e. The slot delay for a client i ∈ [m]will be denoted by Δi≤ [Δc, 2Δc-<NUM>]. The slot delay is a bound on the number of slots any transaction by client i is delayed. The finalized blockchain at slot e is denoted by Chaine. Finally, N denote the network administrator. The finalized blockchain is a part of the blockchain for which the transactions are considered as final.

At step <NUM> of the method <NUM>, the one or more hardware processors <NUM> of the source client node are configured by the programmed instructions to obtain a network-level information associated with the blockchain transaction request using a network data extraction technique/tool. For example, the network data extraction technique/tool includes "ping", "traceroute" and the like. In an embodiment, the network-level information includes Internet Protocol (IP) address of the source client node, IP address of a destination consensus node from among the plurality of consensus nodes, number of routers placed between the source client node and the destination consensus node, and number of router hops between the source client node and the destination consensus node.

At step <NUM> of the method <NUM>, the one or more hardware processors <NUM> of the source client node are configured by the programmed instructions to obtain a plurality of delays associated with each of a plurality of path routers placed between the source client node and the destination consensus node based on the network-level information using delay detection techniques. For example, the plurality of delays comprises a transmission delay, a propagation delay, and a queuing delay. Transmission delay is the time it takes for the network interface adapter to push the transaction packet on the physical link. The propagation delay is the time it takes for the transaction packet to travel over the physical link and the queuing delay is a the time that the transaction packet is delayed at the queues of one or more routers.

At step <NUM> of the method <NUM>, the one or more hardware processors <NUM> of the source client node are configured by the programmed instructions to obtain a transmission slot associated with the source client node only if a sum of the plurality of delays associated with plurality of path routers is less than or equal to a slot epoch length. The transmission slot associated with the source client node is generated using a dynamic slot allocation technique, wherein the dynamic slot allocation technique is one of, (a) uniform client slot allocation and (b) Stake based client slot allocation.

In an embodiment, the process implemented by the method of uniform client slot allocation selects a client for slot allocation by computing a modulus based on a plurality of parameters comprising the slot epoch , the CRHF, current state of the blockchain, number of client nodes as shown in the following pseudocode <NUM>. For example, if the number of clients is <NUM>, the last hex digit of SHA-<NUM> is "C" (decimal value is <NUM>). If mod is computed, then (<NUM> mod <NUM>) +<NUM> = <NUM>. Hence client <NUM> is selected here.

Pseudocode <NUM> achieves uniform distribution over the clients for slot allocation.

In an embodiment, the method of stake based client slot allocation includes the following steps. Initially, a plurality of stake parameters are received. I an embodiment, the plurality of stake parameters includes the current state of the blockchain, the slot epoch, a signature, a probability distribution value and a weight associated with each of the plurality of client nodes. After receiving the plurality of stake parameters, a vote is computed for each of the plurality of client node based on the plurality of stake parameters. Finally, the client node with a maximum vote from among the plurality of client nodes for a corresponding epoch based on the vote associated with each of the plurality of client nodes is selected. In an embodiment, a pseudocode <NUM> explains the stake based client allocation.

Given a slot weight <MAT> associated with each client $ i ∈ [m], Pseudocode <NUM> achieves a stake (proportional to) <MAT> based slot allocation for clients. <IMG>
<IMG>.

For example, considering <NUM> clients with weights <MAT> and <MAT>, in expectation, client <NUM> will get higher vote for slot allocation.

At step <NUM> of the method <NUM>, the one or more hardware processors <NUM> of the source client node are configured by the programmed instructions to broadcast the blockchain transaction request from the source client node into the plurality of consensus nodes simultaneously based on the obtained transmission slot, wherein the blockchain transaction request is signed using a private key of the user prior to broadcasting and, wherein the broadcasted blockchain transaction request is received by the plurality of consensus nodes.

In an embodiment, the overall pseudocode is given as pseudocode <NUM>. The present weighted slotted synchronous client network NC specification is given below. Every transaction transmitted by a client i ∈ [m] is positioned in an arbitrary consensus node's mempool by no more than Δi slots. The network requires synchronized clocks across clients using Network Time Protocol (NTP). Slots are represented as epochs, and slot duration is set by the network administrator N. For each transaction submitted over NC, at any two arbitrary blockchain nodes, the maximum relative gap of the said transaction's location in the two blockchain nodes' mempool is no greater than 4ΔC. Here, 4ΔC was identified as the maximum possible delay during transactions. For example, transactions from the previous 2ΔC slots and future 2ΔC slots can be queued before a specific transaction in some network execution, resulting in a 4ΔC relative position gap. <IMG>
<IMG>.

The embodiments of present disclosure herein address the unresolved problem of developing a blockchain client network design directed towards the interfacing between transacting clients and mempools of consensus nodes which are part of a single blockchain network. A mempool/memory pool is an organized queue where transactions are stored and sorted before being added to a newly created block. The memory pool holds "fresh" or unconfirmed transactions (stored as individual transactions). The blockchain holds "archived" or confirmed transactions (packaged in "blocks"). Further, the present disclosure provides a slotted system for non-colliding transaction broadcast by clients, and synchronous time bound on the reception of each transaction by the blockchain nodes over the network.

It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein such computer-readable storage means contain program-code means for implementation of one or more steps of the method when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs, GPUs and edge computing devices.

The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various modules described herein may be implemented in other modules or combinations of other modules. Alternatives (including extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.

The term "computer-readable medium" should be understood to include tangible items and exclude carrier waves and transient signals, i.e. non-transitory.

Claim 1:
A processor implemented method (<NUM>), the method comprising:
receiving (<NUM>), via an interface associated with a source client node, a blockchain transaction request from a user associated with a source client node from among a plurality of client nodes associated with a blockchain client network, wherein the blockchain client network is a weight based slotted synchronous network, and wherein the blockchain client network comprises the plurality of client nodes, a plurality of consensus nodes and a plurality of routers;
obtaining (<NUM>), by one or more hardware processors of the source client node, a network-level information associated with the blockchain transaction request using a network data extraction technique;
obtaining (<NUM>), by the one or more hardware processors of the source client node, a plurality of delays associated with each of a plurality of path routers placed between the source client node and the destination consensus node based on the network-level information using delay detection techniques;
obtaining (<NUM>), by the one or more hardware processors of the source client node, a transmission slot associated with the source client node only if a sum of the plurality of delays associated with plurality of path routers is less than or equal to a slot epoch length, wherein the transmission slot associated with the source client node is generated using a dynamic slot allocation technique, wherein the dynamic slot allocation technique is one of, (a) an uniform client slot allocation and (b) a Stake based client slot allocation; and
broadcasting (<NUM>), by the one or more hardware processors of the source client node, the blockchain transaction request from the source client node into the plurality of consensus nodes simultaneously based on the obtained transmission slot, wherein the blockchain transaction request is signed using a private key of the user prior to broadcasting and, wherein the broadcasted blockchain transaction request is received by the plurality of consensus nodes.