Preventing denial-of-service of peeling members in licensed blockchain networks

Abstract

The present invention includes a system and method for preventing denial of service attacks using endorsement request metrics in a licensed blockchain network. Implementations of the present invention may track the number of endorsement requests sent from a client associated with an entity and to which blockchain nodes are sent. When the sending rate of the endorsement request far exceeds the proportion of the endorsement request authorized by the associated entity, or when the endorsement request is selected to be sent to which nodes with obvious deviation, the endorsement request can be rejected.

Description

Background Art

[0001] Some embodiments described herein relate to distributed ledger management, and more particularly, but not limited to, preventing denial of service (DoS) in permissioned blockchain networks.

[0002] Consortium blockchain (CBC) networks, often referred to as federated or permissioned blockchains, manage distributed ledgers where nodes are pre-selected and appropriately privileged, working together to achieve common goals and develop cooperative schemes based on reliable, reliably verifiable workflows and accountability. In many CBCs, participants are adopting unified standards such as shared records and / or smart contracts to enable more efficient cross-domain data processing. Most CBCs are based on the assumption that all participants are pre-verified before registration and excluded in the event of malicious behavior. Current CBC trends and challenges are related to the willingness to adopt CBC in business areas where multi-party interoperability and comprehensive security are difficult to achieve.

[0003] Due to the decentralized nature of blockchain networks, each participating organization has its own set of blockchain nodes. As part of the blockchain protocol, there are usually no mandatory regulations for the hardware profile of the nodes or the quality of service for accessing the nodes.

[0004] Transaction gas and fees are used in the Ethereum blockchain, thus mitigating the denial of service (DoS) problem by placing a price tag on every transaction triggered on the blockchain, thereby incentivizing people to invest allocated resources to collect fees associated with transaction execution.

[0005] For example, cryptocurrency mining is used in the Bitcoin and Ethereum blockchains. Cryptocurrency mining incentivizes various participants in a public blockchain network to invest allocated resources.

[0006] Hyperledger Fabric documentation recommends monitoring resource consumption to mitigate DoS threats. Summary of the invention

[0007] The present invention aims to describe a system and method for preventing denial of service attacks using endorsement request metrics in a permissioned blockchain network.

[0008] The above and other objects are achieved by the features of the independent claims. Other implementations are apparent from the dependent claims, the description and the drawings.

[0009] According to an aspect of some embodiments of the present invention, there is provided a node in a permissioned blockchain network, comprising:

[0010] at least one processing circuit configured to:

[0011] receiving a request from at least one client to endorse a transaction for registration in the ledger;

[0012] Verify compliance of the transaction with the blockchain protocol requirements and compliance with the fair usage function of the endorsement request metric;

[0013] When the compliance is verified, sending an endorsement to the at least one client;

[0014] receiving a block including the transaction;

[0015] The endorsement request indicator is updated based on data associated with the transaction of the block.

[0016] According to an aspect of some embodiments of the present invention, there is provided a method for denial of service resilience in a blockchain network having nodes, the method comprising:

[0017] receiving a request from at least one client to endorse a transaction for registration in the ledger;

[0018] Verify compliance of the transaction with the blockchain protocol requirements and compliance with the fair usage function of the endorsement request metric;

[0019] When the compliance is verified, sending an endorsement to the at least one client;

[0020] receiving a block including the transaction;

[0021] The endorsement request indicator is updated based on data associated with the transaction of the block.

[0022] According to an aspect of some embodiments of the present invention, one or more computer program products are provided, including instructions for denial of service resilience in a blockchain network, and one or more processors of a computing system executing the instructions cause the computing system to:

[0023] Receive a request from another node to endorse the transaction for registration in the ledger;

[0024] Verify compliance of the transaction with the blockchain consensus protocol requirements and compliance with a fair usage threshold calculated as a function of the endorsement request metric;

[0025] When the compliance is verified, sending a reply to the other node;

[0026] receiving a block including the transaction;

[0027] The endorsement request indicator is updated based on data associated with the transaction of the block.

[0028] Optionally, the method further includes: rejecting the request when the transaction does not comply with the fair usage function.

[0029] Optionally, the fair usage function is based on a ratio between endorsements sent by at least one node associated with the entity and endorsements received by a plurality of clients including the client and associated with the entity.

[0030] Optionally, the verification further comprises: checking whether an endorsement request indicator associated with the at least one client node request satisfies at least one fairness criterion with respect to at least one second node.

[0031] Optionally, the at least one fairness criterion is a proof of verifiable randomness of the node to which the client sends a request to endorse each transaction, the data associated with the transaction in the block includes the proof, and the at least one processing circuit is also used to verify the proof.

[0032] Optionally, the endorsement request indicator is based on the number of recent blocks.

[0033] Optionally, the method further includes: when the first node exceeds the fair usage threshold, rejecting the request.

[0034] Optionally, the method further includes: when the first node exceeds the fair usage threshold, rejecting the request with a dedicated error code.

[0035] Optionally, the fair usage threshold is based on the number of nodes that need to endorse the transaction and a grace factor.

[0036] Other systems, methods, features and advantages of the present invention will be or become apparent to those skilled in the art after studying the following drawings and detailed description. It is intended that all such other systems, methods, features and advantages be included in this description, within the scope of the present invention, and protected by the accompanying claims.

[0037] Unless otherwise defined, all technical and / or scientific terms used herein have the same meaning as those known to those of ordinary skill in the art to which the embodiments belong. Although methods and materials similar or equivalent to the methods and materials described herein can be used in the practice or testing of the embodiments, exemplary methods and / or materials are described below. In the event of a conflict, this patent specification (including definitions) shall prevail. In addition, these materials, methods and examples are merely illustrative and are not necessarily restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] Some embodiments are described herein by way of example only in conjunction with the accompanying drawings. The following detailed descriptions with specific reference to the accompanying drawings emphasize that the details shown are only examples and are for illustrative purposes only in discussing the embodiments. Thus, it will be apparent to those skilled in the art how to practice the embodiments based on the accompanying drawings.

[0039] In the attached picture:

[0040] Figure 1 is a schematic diagram of an exemplary system for a node in a permissioned blockchain network according to some embodiments of the present invention;

[0041] Figure 2A is a schematic block diagram of an exemplary permissioned blockchain network performing exemplary operations for adding a new block to a blockchain according to some prior art;

[0042] Figure 2B is a schematic block diagram of an exemplary permissioned blockchain network performing exemplary operations for adding a new block to a blockchain according to some embodiments of the present invention;

[0043] Figure 3 is a flow chart of an exemplary process for transaction endorsement for adding new blocks to a blockchain while preventing denial of service (DoS) in a permissioned blockchain network according to some embodiments of the present invention. DETAILED DESCRIPTION

[0044] Some embodiments described herein relate to distributed ledger management, and more particularly, but not limited to, preventing denial of service (DoS) in permissioned blockchain networks.

[0045] Exploitative use of blockchains can lead to DoS. An exploitative alliance member (also known as an entity or organization) may generate a large number of endorsement requests for its transactions on endorsing nodes on a large scale, which may cause other entities' transactions to fail to be processed and endorsed.

[0046] Furthermore, there is no inherent incentive for entities using and promoting CBC to invest in their BC deployment. Since transaction processing may primarily use the resources of other entities, an entity can achieve good performance as long as a sufficient number of other entities have invested in good BC deployment.

[0047] There is also no inherent incentive in the known CBC methods to endorse endorsement requests issued by other entities. In addition, the applicant has not found a generally accepted quantifiable metric to illustrate the amount of use of the alliance BC resources by any particular alliance member entity, nor has it found a confirmed method to quantify the "fair use" of these resources.

[0048] An approach based on transaction gas and fees does not limit transaction requests from exploitative members. Furthermore, this concept does not apply to consortium BCs. Consortium blockchains are not based on monetary incentives, so introducing fees can be problematic.

[0049] Furthermore, the fuel or fee concepts do not provide a definition of “usage” or “fair usage”, which is irrelevant in public BCs but is required in CBCs.

[0050] The concept of cryptocurrency mining may not apply to consortium blockchains. There is no cryptocurrency on the basis of the consortium, nor is there any value associated with any tokens minted as part of the block creation protocol.

[0051] Since resource consumption may peak when all alliance members propose benign, fair, and load-balanced transactions, monitoring resource consumption metrics may result in false positives with a high probability.

[0052] Even in the case of an imbalanced load, it is difficult to find the root cause and determine which organization is abusing system resources. Since there is no formal definition of "usage" / "fair usage", entities may deny responsibility.

[0053] The "usage" metric for an entity can be defined as follows:

[0054] Usage = #<endorsements collected by entity X> / #<endorsements provided by entity X>

[0055] "Fair usage" can be defined by the consortium as a normal number that sets an upper limit on the "usage" quotient:

[0056] Usage ≤ Fair Usage

[0057] Obviously, other functions such as additive ratios can be used to calculate the usage metric. The usage of an entity can be calculated over the last N blocks, where N is defined by the federation. Alternatively, the memory can decay exponentially, for example, by assigning a weight of 0.1 or 0.4 to the last block and assigning the one's complement of the weight to the previous usage metric.

[0058] Optionally, only valid transactions may be counted when calculating the "usage" metric.

[0059] Endorsing nodes will calculate the usage metric of the requesting organization and refuse to provide endorsement if the organization's usage is greater than fair usage.

[0060] Optionally, depending on the rules of the endorsement policy, the client may be required to use verifiable randomness to prove that all entities have an equal chance of providing an endorsement. This requirement can prevent boycotts against a particular entity, thereby depriving that entity of the ability to propose transactions.

[0061] The randomness proof can be added to the transaction proposal and included in the block so that it can be verified during the confirmation phase (i.e. block submission) or at review time. It should be noted that the verification performed during block registration is not related to time, and methods that include time measurement may not be applicable to decentralized systems.

[0062] Clients associated with an entity may need to collect endorsements for their transaction proposals. When a verifiable random function is used to select which organizations to collect these endorsements from, the selection of which entities to collect endorsements from depends on the endorsement policy. Some endorsement policies point to specific organizations (e.g., orgA & orgB), in which case the above requirement does not matter.

[0063] However, endorsement policies often allow for flexible selection of endorsing organizations, for example, entities orgA|orgB, or a majority of (orgA, orgB, orgC), i.e. 2. In such examples, verifiable random functions can be used to select organizations while complying with the endorsement policy.

[0064] A verifiable random function is a function that produces a deterministic and unique "randomness" that can be independently verified later. One benefit of verifiable randomness is that it prevents clients from being biased in the selection process. The source of randomness may be external to the client itself, i.e. from a source that the client does not fully control. For example, the randomness may be based on the hash of the last committed block.

[0065] A. Barger, Y. Manevich, and H. Meir, "Hardening Permissioned Blockchains with Verifiable Randomness" published at the 2020 IEEE International Conference on Blockchain and Cryptocurrency (ICBC) (2020, pp. 1-5, doi: 10.1109 / ICBC48266.2020.9169471) discloses an exemplary method of verifiable randomness. Alternatively, other verifiable random functions (VRFs) or similar methods may also be used.

[0066] In some implementations of the invention, block submission includes: each endorsing node calculates a usage metric for each organization based on metadata of valid transactions in the received block and optionally the previous N-1 blocks in an equal-weighted window or decaying weight manner. The usage metric can be defined as the number of endorsements collected by a particular entity divided by the number of endorsements provided by the entity. The calculation can be based on the most recent block, between the last N blocks, and / or weighted between the last block and storage, etc.

[0067] When a client requests an endorsing node to endorse a transaction, the node may check whether the entity associated with the requesting client requesting usage has exceeded a fair usage function or threshold configured by the federation, etc., and if so, the endorsement request may be rejected.

[0068] Each client can send a randomness proof as part of a transaction proposal to prove that endorser selection was based on random selection and was not biased to exclude any specific entity.

[0069] The present invention proposes a method for the alliance to set an explicit "usage" metric to use when defining "fair usage". In addition, the present invention can be used to prevent DoS by restricting exploitative alliance members and by providing a method to identify exploitative alliance members in manual post-analysis.

[0070] In addition, the present invention also proposes a method for incentivizing all alliance members to endorse transactions and invest in computing and communication hardware resources for their blockchain nodes.

[0071] Before describing at least one embodiment in detail, it should be understood that the embodiments are not necessarily limited to the details of the construction and arrangement of the components and / or methods described in the following description and / or drawings and / or examples. The implementations described herein support other embodiments or support being practiced or executed in various ways.

[0072] The embodiments may be a system, method and / or computer program product. The computer program product may include a computer program product such as one or more readable storage media having computer-readable program instructions that cause a processor to perform various aspects of the embodiments.

[0073] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device, or downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, transmission optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions to be stored in a computer-readable storage medium in the corresponding computing / processing device.

[0074] The computer-readable program instructions for performing the operation in the embodiment can be assembler instructions, instruction set architecture (instruction-set-architecture, ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages. These programming languages ​​include object-oriented programming languages, such as Smalltalk, C++, etc., and traditional procedural programming languages, such as, "C" programming language or similar programming languages. The computer-readable program instructions can be executed completely on the user's computer, partly on the user's computer, as an independent software package partly on the user's computer and partly on a remote computer, or completely on a remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, and these networks include a local area network (local area network, LAN) or a wide area network (wide area network, WAN), and can also (for example, by using the Internet of an Internet service provider) be connected to an external computer. In some embodiments, electronic circuits including programmable logic circuits, field-programmable gate arrays (FPGAs) or programmable logic arrays (PLAs) can execute computer-readable program instructions to customize the electronic circuits by using state information of the computer-readable program instructions, thereby performing various aspects of the embodiments.

[0075] The present invention relates to various aspects of the embodiments of the present invention in conjunction with flowchart illustrations and / or block diagrams of the methods, devices (systems) and computer program products provided by the embodiments. It should be understood that each box in the flowchart illustration and / or block diagram and the combination of boxes in the flowchart illustration and / or block diagram can be implemented by computer-readable program instructions.

[0076] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a manner for implementing the functions / actions detailed in the flowchart and / or block diagram blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, which can instruct a computer, a programmable data processing device, and / or other equipment to operate in a specific manner, so that a computer-readable storage medium having instructions stored therein includes an article of manufacture containing instructions, which are used to implement various aspects of the functions / actions detailed in the flowchart and / or block diagram blocks.

[0077] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operating steps are executed on the computer, other programmable apparatus, or other device to produce a computer-implemented process, so that the instructions executed on the computer, other programmable apparatus, or other device may implement the functions / actions detailed in the flowchart and / or block diagram blocks.

[0078] The flow chart and block diagram in the figure show the architecture, function and operation of the possible implementation of the system, method and computer program product provided by each embodiment. In this regard, each square box in the flow chart or block diagram can represent a module, a section or a partial instruction, and the partial instruction includes one or more executable instructions for realizing one or more specified logical functions. In some alternative implementations, the function described in the square box may not be implemented in the order described in the figure. For example, in fact, the two square boxes shown in succession can be executed almost at the same time, or sometimes the square box can be executed in the opposite order, depending on the function involved. It should also be noted that each square box in the block diagram and / or flow chart and the combination of the square boxes in the block diagram and / or flow chart can be implemented by a system based on special hardware, which performs specific functions or actions, or performs a combination of special hardware and computer instructions.

[0079] Various aspects of the present invention are described by narrative text, flow charts, computer system block diagrams, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. For any flow chart, depending on the technology involved, the order in which the operations are performed may be different from the order shown in a given flow chart. For example, also depending on the technology involved, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0080] Computer program product embodiments ("CPP embodiments" or "CPP") are used herein to describe any collection of one or more storage media (also referred to as "media") collectively included in a collection of one or more storage devices, wherein the storage devices collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. A computer-readable storage medium may be, but is not limited to, an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices including these media include: floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encoding device (e.g., punched cards or pits / land formed in the major surface of the disk), or any suitable combination of the foregoing. The term computer readable storage medium used in the present invention should not be interpreted as storing in the form of transient signals themselves (e.g., radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses propagating through fiber optic cables, electrical signals sent through wires, and / or other transmission media). Those skilled in the art will appreciate that during normal operation of a storage device, such as during access, defragmentation, or garbage collection, data will typically be moved at some occasional point in time, but this does not make the storage device instantaneous because data is not instantaneous when stored.

[0081] Referring to the accompanying drawings, Figure 1 1 is a schematic diagram of an exemplary system for a node in a permissioned blockchain network according to some embodiments of the present invention. An exemplary client computer system 100 may be used to perform execution processes such as 300. Further details about these exemplary processes are as follows: Figure 3 Described as shown.

[0082] The computing environment 100 includes an example of an execution environment for at least some of the computer codes involved in executing the described method, for example, a blockchain node module 180 suitable for preventing DoS. In addition to the blockchain node module 180 box, the computing environment 100 also includes a computer 102, a wide area network (WAN) 108, an end user device (EUD) 132, a remote server 104, a public cloud 150, and a private cloud 106. In this embodiment, the computer 102 includes a processor set 110 (including a processing circuit 120 and a cache 134), a communication structure 160, a volatile memory 112, a persistent storage 116 (including an operating system 122 and a blockchain node module 180, as described above), a peripheral device set 114 (including a user interface (UI), a device set 126, a storage 124, and an Internet of Things (IoT) sensor set 128) and a network module 118. The remote server 104 includes a remote database 130.

[0083] Node computer 102 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smart watch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device currently known or to be developed in the future that is capable of running programs, accessing a network, or querying a database such as remote database 130. As is well known in the art of computer technology, the performance of computer-implemented methods may be distributed among multiple computers and / or among multiple locations, depending on the technology. On the other hand, in this introduction to computing environment 100, the detailed discussion focuses on a single computer, particularly node computer 102, to keep the introduction as simple as possible. Although not discussed in detail, the present invention provides a method for implementing a computer system in a manner that is not limited to a single computer, a node computer, or a computer that is not a computer system. Figure 1 Node computer 102 is shown in the cloud of , but it can be located in the cloud. On the other hand, node computer 102 does not need to be located in the cloud unless there is a clear indication.

[0084] The processor set 110 includes one or more computer processors of any type currently known or to be developed in the future. For example, the processor set may include one or more of the following: a central processing unit (CPU), a microcontroller, a digital signal processing (DSP) unit, a graphics processing unit (GPU) module, and other parallel processors that support multiple data, as well as an optical processor, a quantum processor, and a processing unit based on a technology that may be developed in the future. The processing circuit 120 can be distributed on multiple packages, for example, on multiple collaborative integrated circuit chips. The processing circuit 120 can implement multiple processor threads and / or multiple processor cores. The cache 134 is a memory located in one or more processor chip packages, and is generally used for data or code, which should be available for fast access by threads or cores running on the processor set 110. Cache memory is generally organized into multiple levels according to the relative proximity to the processing circuit. Alternatively, some or all of the caches of the processor set may be located "off-chip". In some computing environments, the processor set 110 may be designed to process quantum bits and perform quantum computing.

[0085] Computer-readable program instructions are typically loaded onto the node computer 102 to cause the processor set 110 of the node computer 102 to perform a series of operating steps to implement a computer-implemented method, and the instructions so executed will instantiate the method specified in the flowchart and / or the narrative description of the computer-implemented method (collectively referred to as the "described method") included in this document. These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 134 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 110 to control and direct the performance of the described method. In the computing environment 100, at least some instructions for performing the described method can be stored in the blockchain node module 180 in the persistent storage 116.

[0086] The communication fabric 160 is a signaling path that enables the various components of the node computer 102 to communicate with each other. Typically, such a fabric is composed of switches and conductive paths, such as switches and conductive paths that make up a bus, a bridge, physical input / output ports, etc. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[0087] The volatile memory 112 is any type of volatile memory currently known or to be developed in the future. Examples include dynamic type random access memory (RAM) or static type RAM. Typically, volatile memory is characterized by random access, but this is not required unless explicitly indicated. In the node computer 102, the volatile memory 112 is located in a single package and is internal to the node computer 102, but, alternatively or additionally, the volatile memory can be distributed over multiple packages and / or located externally relative to the node computer 102.

[0088] Persistent storage 116 is any form of non-volatile storage for computers currently known or to be developed in the future. The non-volatility of the storage means that the stored data will be maintained regardless of whether power is supplied to the node computer 102 and / or directly to the persistent storage 116. Persistent storage 116 can be a read-only memory (ROM), but typically at least a portion of the persistent storage allows data to be written, deleted, and rewritten. Some common forms of persistent storage include disks and solid-state storage devices. Operating system 122 can take several forms, such as various known proprietary operating systems or operating systems of open source portable operating system interface types using a kernel. The code included in box 180 typically includes at least some computer code involved in executing the described method.

[0089] The peripheral device set 114 includes a set of peripheral devices of the node computer 102. The data communication connection between the peripheral devices and other components of the node computer 102 can be implemented in various ways, such as a Bluetooth connection, a Near-Field Communication (NFC) connection, a connection formed by a cable (e.g., a universal serial bus (USB) type cable), a plug-in connection (e.g., a secure digital (SD) card), a connection through a local area communication network, or even a connection through a wide area network such as the Internet. In various embodiments, the UI device set 126 may include components such as a display screen, a speaker, a microphone, a wearable device (e.g., goggles and smart watches), a keyboard, a mouse, a printer, a touchpad, a game controller, and a tactile device. The storage 124 is an external storage such as an external hard drive, or a pluggable storage such as an SD card. The storage 124 can be persistent and / or volatile. In some embodiments, the storage 124 can take the form of a quantum computing storage device for storing data in the form of quantum bits. In embodiments where the node computer 102 needs to have a large amount of storage (e.g., where the node computer 102 locally stores and manages a large database), the storage can be provided by a peripheral storage device designed to store very large amounts of data (e.g., a storage area network (SAN) shared by multiple geographically distributed computers). The IoT sensor set 128 consists of sensors that can be used in IoT applications. For example, one sensor can be a thermometer and another sensor can be a motion detector.

[0090] The network module 118 is a collection of computer software, hardware and firmware that enables the node computer 102 to communicate with other computers through the WAN 108. The network module 118 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packaging and / or unpacking data for communication network transmission, and / or web browser software for sending data on the Internet. In some embodiments, the network control function and network forwarding function of the network module 118 are executed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software-defined networking (SDN)), the control function and forwarding function of the network module 118 are executed on physically separated devices, so that the control function manages several different network hardware devices. Computer-readable program instructions for executing the described method can usually be downloaded to the node computer 102 from an external computer or an external storage device through a network adapter card or a network interface included in the network module 118.

[0091] WAN 108 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances by any technology currently known or to be developed in the future for transmitting computer data. In some embodiments, the WAN may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area, such as a Wi-Fi network. A WAN and / or a LAN typically includes computer hardware, such as copper transmission cables, transmission optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0092] An end user device (EUD) 132 is any computer system used and controlled by an end user (e.g., a customer of an enterprise operating the node computer 102), and may take any of the forms discussed above in connection with the node computer 102. The EUD 132 typically receives useful and useful data from the operation of the node computer 102. For example, in the hypothetical case where the node computer 102 is designed to provide recommendations to the end user, the recommendations would typically be sent from the network module 118 of the node computer 102 to the EUD 132 via the WAN 108. In this way, the EUD 132 may display or otherwise present the recommendations to the end user. In some embodiments, the EUD 132 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

[0093] Remote server 104 is any computer system that provides at least some data and / or functionality to node computer 102. Remote server 104 may be controlled and used by the same entity that operates node computer 102. Remote server 104 represents one or more machines that collect and store beneficial and useful data for use by other computers (e.g., node computer 102). For example, in the hypothetical case where node computer 102 is designed and programmed to provide recommendations based on historical data, the historical data may be provided to computer 102 from remote database 130 of remote server 104.

[0094] The public cloud 150 is any computer system that can be used by multiple entities, providing on-demand availability of computer system resources and / or other computer capabilities (particularly data storage (cloud storage) and computing capabilities) without the need for direct active management by users. Cloud computing typically uses resource sharing to achieve consistency and economies of scale. Direct active management of the computing resources of the public cloud 150 is performed by computer hardware and / or software of the cloud orchestration module 146. The computing resources provided by the public cloud 150 are typically implemented by virtual computing environments running on various computers that constitute a host physical machine set, which is a full set of physical computers in and / or available for the public cloud 150. A virtual computing environment (VCE) typically takes the form of a virtual machine in a virtual machine set and / or a container in a container set. It should be understood that these VCEs can be stored as images and can be transmitted between various physical machine hosts as images or after VCE instantiation. The cloud orchestration module can manage the transmission and storage of images, deploy new instantiations of VCEs, and manage active instantiations of VCE deployments. Some further explanation about virtualized computing environments (VCEs) is provided below. A VCE can be stored as an "image". A new active instance of a VCE can be instantiated from an image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user space instances called containers. From the perspective of the programs running in them, these isolated user space instances typically act like a real computer. Computer programs running on a normal operating system can utilize all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0095] The private cloud 106 is similar to the public cloud 150, except that the computing resources are only available to a single enterprise. Although the private cloud 106 is shown as communicating with the WAN 108, in other embodiments, the private cloud can be completely disconnected from the Internet and can only be accessed through a local / private network. A hybrid cloud consists of multiple clouds of different types (e.g., private, community, or public cloud types), typically implemented separately by different vendors. Each of the multiple clouds remains an independent, discrete entity, but the larger hybrid cloud architecture is combined together through standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple component clouds. In this embodiment, the public cloud 150 and the private cloud 106 are both part of a larger hybrid cloud.

[0096] Client node 140 is an exemplary node that is similar from a hardware perspective and optionally in most software aspects to a node computer, remote server, or end-user device, intended to function as one or more clients of one or more nodes of a permissioned blockchain network.

[0097] Another node 142 is an exemplary node on a permissioned blockchain, which may be similar to a node computer, and it is contemplated that it may be associated with different entities.

[0098] Reference below Figure 2A , Figure 2A is a schematic block diagram of an exemplary permissioned blockchain network performing exemplary operations for adding a new block to a blockchain according to some prior art.

[0099] When a client wants to submit a new transaction to the blockchain, it needs to create a transaction proposal, indicating the smart contract method it initiates and the parameters used. To make the transaction proposal valid, the client needs to collect endorsements.

[0100] To do this, an endorsement request is sent to a node (1). Providing an endorsement involves executing the smart contract code to determine the output of the transaction and optionally determining that the transaction meets certain requirements (2). This requires computing time and HW resources. In some examples, a single proposal requires multiple endorsements (3). Endorsements are provided by nodes of federated entities.

[0101] A transaction proposal must include endorsements that comply with the smart contract’s endorsement policy before it can be sent to the ordering service (4), which can include the transaction in a new block (5) for nodes to confirm (6) and commit.

[0102] Also refer to Figure 2B , Figure 2B is a schematic block diagram of an exemplary permissioned blockchain network performing exemplary operations for adding a new block to a blockchain according to some embodiments of the present invention.

[0103] Smart contracts have an endorsement policy, which defines the organizations that must endorse and approve the execution of a proposal for it to be considered valid.

[0104] When submitting the content of a new block, each node can ensure that the transaction contains the appropriate number of endorsements and that the content comes from the expected source. The strategy can be different in different alliances, transaction types, and implementations. For example, when the entities are orgA, orgB, and orgC, some exemplary strategies include: orgA&orgB&orgC, orgA|orgB, orgA|(orgB&orgC), and 2 of (orgA, orgB, orgC).

[0105] An exemplary process of registering a transaction in a distributed ledger may be performed as follows, wherein an endorsing node may Figure 1 As shown in 102 in the implementation, the client can Figure 1 140 is shown in the implementation:

[0106] A client of a particular entity (e.g., orgA) requests one or more nodes to endorse a transaction proposal. In cases where the policy allows for dynamic selection, the nodes can be selected in a verifiably random manner according to the endorsement policy (1). Alternatively, the randomness can be reviewed from time to time.

[0107] Of course, each endorsing node can confirm that orgA usage does not exceed the fair usage threshold. The usage of a particular entity can be calculated by retrieving the usage metric for each of the last N blocks from the node's local state and aggregating it using a gradually decaying memory, etc.

[0108] If exceeded, the endorsement request may optionally be rejected with a dedicated error code. Some alternative implementations may also have warning thresholds to notify system administrators, reduce priority, or otherwise delay the transaction when an associated threshold or other condition is met. (2)

[0109] When the fair usage confirmation requirements are met, the endorsing node can send its endorsement to the client node. (3)

[0110] The client can package the endorsement with a proof of randomness chosen by the node, allowing the blockchain node to perform a verifiable randomness check, and can send the endorsement transaction to the ordering service. (4)

[0111] The ordering service can create a subscription service that can be accessed over the network (e.g. Figure 1 108) new blocks propagated to the nodes. (5)

[0112] During the submission process of a newly received block, each transaction may be validated. Validation may include signature checks, endorsement policy compliance, node selection verification, etc. In addition, each node may calculate updated usage metrics for each entity of the block and save them to the node's local state. For example, the amount of endorsements collected and the amount of endorsements provided based on valid transactions in the block. Alternative implementations may perform fair usage validation and / or apply variations of the metrics at other stages, etc. (6)

[0113] Reference below Figure 3 , Figure 3300 is a flow chart of an exemplary process for adding new blocks to a blockchain while preventing denial of service (DoS) in a permissioned blockchain network according to some embodiments of the present invention. The processing circuit 120 may perform the exemplary process 300 to register blocks in a ledger for various purposes (e.g., financial, logistical, and / or voting, etc.). Alternatively, the process 300 or portions thereof may be performed using private and / or public cloud services, etc.

[0114] As shown at 302, example process 300 begins by receiving a request from at least one client node (e.g., 140) to endorse a transaction for registration in a ledger.

[0115] In some implementations, the request may include transaction data, smart contracts, parameters, and proof of verifiable randomness of the selected endorsing nodes. Figure 1 The network module 118 is shown receiving the WAN 108. The request may be sent in different formats (eg, plain text, integer, or encrypted).

[0116] The example process 300 continues, as shown at 304, by verifying compliance of the transaction with blockchain protocol requirements and compliance with a fair usage function of an endorsement request metric.

[0117] The requirements may include logic, consistency, compliance with smart contracts, time, fair usage requirements, and / or regulations, etc. Fair usage requirements may be observed through metrics such as endorsement requests by clients or associated entities and endorsements provided or authorized by nodes associated with the entity.

[0118] The fair usage function can be based on a ratio between endorsements sent by at least one node associated with an entity and endorsements received by multiple clients including the client and associated with the entity. The at least one node can refer to a specific node, all nodes associated with the entity, or a subset thereof. Similarly, the multiple clients can refer to a specific client node, all clients associated with the entity, or a subset thereof. Alternative implementations can use other comparison methods (e.g., additive difference) instead of ratios. The target ratio can be adjusted based on the number of endorsements required for the transaction and / or a grace factor, etc. Other variations and adjustments of the fair usage function can be applied in some implementations.

[0119] Optionally, exemplary process 300 may proceed, as shown at 306, by rejecting the request when the transaction does not comply with the fair usage function, rather than continuing with the following steps. For example, noncompliance may refer to a situation where an entity associated with the client exceeds a fair usage threshold. The fair usage threshold is based on the number of nodes that need to endorse the transaction and a grace factor. For a policy such as orgA|orgB, the number may be one, and for (orgA&orgD)|(orgB&orgC), the number may be two. Rejection may be characterized by a dedicated error code.

[0120] The example process 300 continues, as indicated at 308 , by sending an endorsement to at least one client when compliance is verified.

[0121] Endorsement can be made through Figure 1 The network module 118 and WAN 108 are shown transmitted to the client node 140. Implementations generally apply an assumption that nodes will authorize endorsement requests as long as the requirements are met, however, some alternative implementations may have exceptions.

[0122] The exemplary process 300 continues with receiving a block including transactions, as shown at 310. The block may be Figure 1 The network module 118 and WAN 108 are shown receiving from the subscription service.

[0123] A block may include multiple transactions, each initiated by a client associated with an entity. A block may include endorsements of transactions authorized by nodes associated with multiple entities. A block may also include endorsement rules and documentation of the nodes or entities to which the endorsement request is sent.

[0124] The example process 300 may continue, as shown at 312, by performing validation of the transactions in the block.

[0125] Validation may include checks of known blockchain characteristics, such as signatures and endorsements, etc. Validation may be performed by every node that has a copy of the blockchain.

[0126] Optionally, the system performing process 300 may proceed, as shown at 314, to check whether the endorsement request metric associated with the at least one client node request satisfies at least one fairness criterion with respect to at least one second node.

[0127] In addition to the validation described in block 312, validation may also include node selection fairness. When the fairness validation of the node is based on verifiable randomness, the match between the selection and the source of randomness of the verifiable randomness may be 1. When validation is done by counting endorsement requests in one or more blocks of transactions associated with a specified client or a specified entity, only valid transactions included in the registered blocks are considered, however, alternative implementations may also take invalid transactions into account.

[0128] Checking whether the endorsement request metric associated with at least one client node request satisfies at least one fairness criterion with respect to at least one second node may be accomplished by verifiable randomness, in which case the at least one fairness criterion may be a proof of verifiable randomness of the node to which the client sends the request to endorse each transaction. Furthermore, the data associated with the transactions of the block may include the proof, and the process may verify the proof at the block commit stage.

[0129] However, alternative implementations could use this proof to verify randomness during the transaction endorsement phase, or to count the endorsement requests recorded in the block through other methods.

[0130] Process 300 may then continue, as shown at 316, by updating the endorsement request indicator based on data associated with the transactions of the block.

[0131] The purpose is to determine fair usage of an entity and / or clients associated therewith. Metrics may be maintained and / or calculated. Each node may calculate updated usage metrics for each entity for the block and may save them to the node's local state. For example, the amount of endorsements collected and the amount of endorsements provided based on valid transactions for the block. Alternatively, an endorsement request metric may be calculated for a client or group of clients within an entity.

[0132] In some implementations, the metric may be relative to the most recent block, minimizing the need to store statistics or review old blocks. In some implementations, the statistics or endorsement request metric may be based on the number of recent blocks (N), which may be predetermined, dynamically agreed upon, or randomized subject to some constraints. Some implementations may give equal weight to blocks, adjust block weights by age, and / or store aggregate statistics that may decay exponentially or otherwise over time and / or block counts.

[0133] The descriptions of various embodiments are for illustrative purposes only, but these descriptions are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles, practical applications, or technological advances of the embodiments, or to enable other persons skilled in the art to understand the embodiments disclosed herein, as compared to existing technologies on the market.

[0134] It is expected that during the life of the patent expiring on this application, many related distributed ledgers will be developed, and the scope of the term "blockchain network" is intended a priori to include all such new technologies.

[0135] As used herein, the term "about" refers to ± 10%.

[0136] The terms "including," "having," and variations thereof mean "including but not limited to." This term encompasses the terms "consisting of" and "consisting essentially of.

[0137] The phrase "consisting essentially of" means that the composition or method may include additional ingredients and / or steps, but only if the additional ingredients and / or steps do not materially alter the basic and novel characteristics of the claimed composition or method.

[0138] As used herein, the singular forms "a", "an" and "the" include plural references unless the context clearly indicates otherwise. For example, the term "a compound" or "at least one compound" may include a plurality of compounds, including mixtures thereof.

[0139] The word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and / or to exclude the incorporation of features of other embodiments.

[0140] The word “optionally” is used herein to mean “provided in some embodiments and not provided in other embodiments.” Any particular embodiment may include multiple “optional” features, unless such features are in conflict.

[0141] In the present application, various embodiments can be presented in range format. It should be understood that the description of range format is only for convenience and brevity, and should not be interpreted as a fixed limitation on the scope of the embodiments. Therefore, the description of the range should be considered to have specifically disclosed all possible sub-ranges and individual numerical values ​​within the range. For example, the description of the range such as from 1 to 6 should be considered to have specifically disclosed sub-ranges from 1 to 3, from 1 to 4, from 1 to 5, from 2 to 4, from 2 to 6, from 3 to 6, etc. and individual numbers within the range, such as 1, 2, 3, 4, 5 and 6. No matter how wide the scope is, this applies.

[0142] When a numerical range is indicated herein, it is meant to include any listed numerals (fractional or integer) within the indicated range. The phrases "range between a first indicated number and a second indicated number" and "range from a first indicated number to a second indicated number" are used interchangeably herein to include the first indicated number and the second indicated number and all fractions and integers between the two.

[0143] It should be understood that certain features of the embodiments described in the context of separate embodiments for the sake of brevity may also be provided in a single embodiment by combination. Conversely, individual features of the embodiments described in the context of a single embodiment for the sake of brevity may also be provided in any other described embodiment individually or by any suitable sub-combination or as appropriate. Certain features described in the context of individual embodiments are not considered essential features of these embodiments, unless the embodiments are inoperable without these elements.

[0144] Although the embodiments have been described in conjunction with their specific embodiments, it is apparent that many alternatives, modifications and variations are apparent to those skilled in the art. Therefore, it is intended to encompass all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

[0145] It is the applicant's intention that all publications, patents and patent applications mentioned in this specification are incorporated herein by reference in their entirety, as if each individual publication, patent or patent application were specifically and individually indicated when mentioned to be incorporated herein by reference. In addition, the reference or identification of any reference of the present application cannot be regarded as allowing such reference to take precedence over the present invention in the prior art. With respect to the use of section headings, section headings should not be interpreted as necessary limitations. In addition, the entire contents of any one or more priority documents of the present application are incorporated into the present application by reference.

Claims

1. A node in a permissioned blockchain network, characterized in that: include: at least one processing circuit configured to: receiving a request from at least one client to endorse a transaction for registration in the ledger; Verify compliance of the transaction with the blockchain protocol requirements and compliance with the fair usage function of the endorsement request metric; When the compliance is verified, sending an endorsement to the at least one client; receiving a block including the transaction; The endorsement request indicator is updated based on data associated with the transaction of the block.

2. The node according to claim 1, characterized in that Also includes: When the transaction does not comply with the fair usage function, the request is rejected.

3. The node according to claim 1, characterized in that The fair usage function is based on a ratio between endorsements sent by at least one node associated with an entity and endorsements received by a plurality of clients including the client and associated with the entity.

4. The node according to claim 1, characterized in that The verification further includes checking whether an endorsement request indicator associated with the at least one client node request satisfies at least one fairness criterion with respect to at least one second node.

5. The node according to claim 4, characterized in that: The at least one fairness criterion is a proof of verifiable randomness of the node to which the client sends a request to endorse each transaction, the data associated with the transaction of the block includes the proof, and the at least one processing circuit is also used to verify the proof.

6. The node according to claim 1, characterized in that The endorsement request metric is based on the number of recent blocks.

7. A method for denial of service resilience in a blockchain network having nodes, characterized in that The method comprises: receiving a request from at least one client to endorse a transaction for registration in the ledger; Verify compliance of the transaction with the blockchain protocol requirements and compliance with the fair usage function of the endorsement request metric; When the compliance is verified, sending an endorsement to the at least one client; receiving a block including the transaction; The endorsement request indicator is updated based on data associated with the transaction of the block.

8. The method according to claim 7, characterized in that Also includes: When the transaction does not comply with the fair usage function, the request is rejected.

9. The method according to claim 7, characterized in that: The fair usage function is based on a ratio between endorsements sent by at least one node associated with an entity and endorsements received by a plurality of clients including the client and associated with the entity.

10. The method according to claim 7, characterized in that The verification further includes checking whether an endorsement request indicator associated with the at least one client node request satisfies at least one fairness criterion with respect to at least one second node.

11. The method according to claim 10, characterized in that The at least one fairness criterion is a proof of verifiable randomness of the node to which the client sends a request to endorse each transaction, the data related to the transaction of the block includes the proof, and the method further includes: verifying the proof.

12. The method according to claim 7, characterized in that The endorsement request metric is based on the number of recent blocks.

13. One or more computer program products, characterized in that The invention includes instructions for denial of service resilience in a blockchain network, which execution of the instructions by one or more processors of a computing system causes the computing system to: Receive a request from another node to endorse the transaction for registration in the ledger; Verify compliance of the transaction with the blockchain consensus protocol requirements and compliance with a fair usage threshold calculated as a function of the endorsement request metric; When the compliance is verified, sending a reply to the other node; receiving a block including the transaction; The endorsement request indicator is updated based on data associated with the transaction of the block.

Images