Automated smart contract hot update

Abstract

The present invention relates to a method and system that implements a solution that can automatically handle all aspects of smart contract code updates in a manner that does not interfere completely and does not require the system to shut down. The present invention comprises: a new transaction, wherein a header indication transaction comprises a bytecode to be inserted into a chain code JVM through a shim API as disclosed; a new shim API that can accept a byte slice, the byte slice being a serialized byte code of a chain code to be loaded into the JVM; and a JVM insertion agent and an agent for detection and repair.

Description

Background Art

[0001] Some embodiments described herein relate to decentralized ledger management, and more particularly, but not exclusively, to methods for hot-fixing ledger code.

[0002] While the most well-known use of distributed ledgers is probably digital currencies, which do not require trust in any particular single entity, the technology is useful in many other areas, and a great deal of effort has gone into the research, development, and deployment of decentralized ledgers. Decentralized ledger management may include smart contracts that can be applied and / or implemented using code, which may be called chaincode, particularly when the ledger is based on a blockchain.

[0003] Smart contracts typically contain complex business rules that can be expressed in a programming language or using a domain specific language (DSL).

[0004] Smart contract implementations are often subject to programming errors due to human error and the inherent complexity of blockchain systems. The syntax choice of DSL or programming language can mislead contract developers and be the root cause of many errors.

[0005] Various techniques have been developed to help programmers reduce the potential risk of introducing errors or ambiguous error-prone logic, and these techniques can also be used for smart contracts, which can allow coding in a way that uses verification techniques such as formal verification that analyzes the code and detects potential problems with the logic. Some formal verification tools are also able to generate fixed versions of the code.

[0006] A static code analysis tool that prompts users of logical erroneous behaviors of smart contracts. For example, the upgrade process in a permissioned blockchain may include the following steps: according to the upgrade strategy, solicit the consent of a sufficient number of consortium organizations; distribute the updated smart contract to all required consortium organizations; deploy the smart contract by organization, usually on multiple blockchain nodes; upgrade the smart contract to an updated version.

[0007] Once all required organizations have completed the upgrade, the smart contracts will be available to blockchain clients.

[0008] During the upgrade process, transactions submitted to this smart contract are likely to fail due to inconsistent logic across multiple organizations. This may compromise the service level agreement (SLA) of the system. Note that the upgrade process spans multiple organizations, prolonging the upgrade process and making it more difficult to coordinate.

[0009] Dynamic code loading and code insertion have been developed to enable zero downtime code replacement for centralized applications. For example, JRebel integrates with the Java virtual machine (JVM) and application servers at the classloader level, wrapping the classloader around the class and allowing Java classes to be dynamically reloaded through insertion. Summary of the invention

[0010] The purpose of the present invention is to describe a system and method for performing hot code replacement in a blockchain network using transaction types included by the blockchain in the present invention.

[0011] 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.

[0012] According to an aspect of some embodiments of the present invention, there is provided a peer node in a blockchain network, the device comprising: at least one processing circuit for:

[0013] Receive a code fix transaction proposal for a hot fix of a smart contract chaincode from an external validation entity;

[0014] Proposing to apply a trust enforcement model to the code repair transaction;

[0015] In response to confirmation of the trust enforcement model, receiving from the external verification entity a block including a transaction implementing the code repair transaction proposal;

[0016] Applying a validation strategy to each transaction in the block;

[0017] When the block including the transaction implementing the code repair transaction proposal satisfies the verification policy:

[0018] appending the block to a ledger associated with the channel identifier;

[0019] updating a state based on the transaction;

[0020] Hot code replacement is applied using the smart contract chaincode associated with the channel identifier.

[0021] According to an aspect of some embodiments of the present invention, there is provided a hot code replacement method in a blockchain network, the method comprising:

[0022] Receive a code fix transaction proposal for a hot fix of a smart contract chaincode from an external validation entity;

[0023] Proposing to apply a trust enforcement model to the code repair transaction;

[0024] In response to confirmation of the trust enforcement model, receiving from the external verification entity a block including a transaction implementing the code repair transaction proposal;

[0025] Applying a validation strategy to each transaction in the block;

[0026] When the block including the transaction implementing the code repair transaction proposal satisfies the verification policy:

[0027] appending the block to a ledger associated with the channel identifier;

[0028] updating a state based on the transaction;

[0029] Hot code replacement is applied using the smart contract chaincode associated with the channel identifier.

[0030] According to an aspect of some embodiments of the present invention, one or more computer program products are provided, comprising instructions for hot code replacement in a blockchain network, wherein execution of the instructions by one or more processors of a computing system causes the computing system to:

[0031] Receive a code fix transaction proposal for a hot fix of a smart contract chaincode from an external validation entity;

[0032] Proposing to apply a trust enforcement model to the code repair transaction;

[0033] In response to confirmation of the trust enforcement model, receiving from the external verification entity a block including a transaction implementing the code repair transaction proposal;

[0034] Applying a validation strategy to each transaction in the block;

[0035] When the block including the transaction implementing the code repair transaction proposal satisfies the verification policy:

[0036] appending the block to a ledger associated with the channel identifier;

[0037] updating a state based on the transaction;

[0038] Hot code replacement is applied using the smart contract chaincode associated with the channel identifier.

[0039] Optionally, the external verification entity includes a detection agent that executes code for automatically detecting potential property violations in the smart contract.

[0040] Optionally, said detection of potential property violations comprises performing a method selected from the group consisting of formal verification, dynamic insertion of smart contract code, logical compliance checking, and static code analysis.

[0041] Optionally, the trust enforcement model comprises a number of peer nodes that received an endorsement from an operator, each peer node cryptographically verifying that the number of peer nodes received the endorsement.

[0042] Optionally, the hot code replacement is performed by a chaincode virtual machine agent.

[0043] Optionally, the hot code replacement is performed by a method selected from the group consisting of dynamic class loading, code insertion and dynamic code replacement.

[0044] Optionally, the transaction implementing the code repair transaction proposal is characterized by a type identifier indicating a policy modification.

[0045] 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, be within the scope of the present invention, and be protected by the accompanying claims.

[0046] 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 field described in the embodiments. 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, the patent specification including the definition shall prevail. In addition, these materials, methods and examples are only illustrative and not necessarily restrictive. BRIEF DESCRIPTION OF THE DRAWINGS

[0047] 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.

[0048] In the attached picture:

[0049] Figure 1 A schematic diagram of an exemplary system configured as a peer node in a blockchain network according to some embodiments of the present invention;

[0050] Figure 2 A schematic diagram of an exemplary system of a blockchain network according to some embodiments of the present invention;

[0051] Figure 3 A flowchart of an example of hot code replacement in a blockchain network according to some embodiments of the present invention;

[0052] Figure 4A flowchart of an example of hot code replacement in a blockchain network according to some embodiments of the present invention;

[0053] Figure 5 A schematic diagram of an exemplary blockchain network with an exemplary external verification entity for some embodiments of the present invention. DETAILED DESCRIPTION

[0054] Some embodiments described herein relate to decentralized ledger management, and more particularly, but not exclusively, to methods for hot-fixing ledger code.

[0055] There can be a lot of downtime when a fixed version of a smart contract is automatically or manually generated and needs to be applied across the entire blockchain cluster. The upgrade process is known to be complex and cumbersome, often resulting in invalid transactions during the upgrade process.

[0056] For example, JRebel, which integrates with the JVM and application server at the classloader level, does not support collected endorsements, nor does it support the synchronization process of continuing with updated code across a distributed network.

[0057] Furthermore, cross-organizational coordination of the upgrade process does not suggest a repair mechanism for smart contract logic, so providing a way to fix smart contract logic and dynamically replace code requires downtime of smart contract-based applications.

[0058] The present invention includes hot code replacement in an alternative decentralized permissioned blockchain network design for the proposed scheme. Although some drawings are based on Hyperledger Fabric, those skilled in the art may apply the disclosed design to other networks, and the present invention should not be interpreted as being limited to or constrained to Hyperledger Fabric applications.

[0059] Some networks may implement containerization to execute smart contracts or chaincode logic, essentially, the chaincode is packaged and instantiated in a container where a shim is provided that handles the communication from the chaincode to peers in order to access world state information.

[0060] The present invention involves the introduction of an end-to-end solution that automatically handles all aspects of smart contract code updates in a completely hands-off manner that requires no system downtime.

[0061] The present invention also includes new transactions, wherein a header indicates that the transaction includes bytecode to be inserted into the chaincode JVM via a shim API as disclosed.

[0062] The present invention also includes a new shim API that can accept byte slices as serialized bytecode of the chaincode to be loaded into the JVM.

[0063] The present invention also includes a JVM insertion agent and an agent for detection and repair.

[0064] Agents that utilize hot code replacement methods can apply dynamic class loading, code insertion, dynamic code replacement, etc. to smart contract code.

[0065] New transaction types added to the blockchain framework handle upgrade transactions regarding smart contract code verification and upgrade policy validation.

[0066] The present invention can distribute new smart contract code versions based on leveraging the built-in block propagation mechanism of blockchain. Smart contract repair can be fully automatic end-to-end, so the business logic update of the smart contract or the chain code upgrade policy update can be done without downtime. In addition, solving the need to coordinate the propagation of update files among all consortium organizations can achieve faster logic updates in the consortium.

[0067] Before explaining 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.

[0068] The embodiments may be systems, methods and / or computer program products. The computer program product may include one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to perform various aspects of the embodiments.

[0069] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above devices. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, and any suitable combination of the above. The computer-readable storage medium used herein should not be interpreted as a transient signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated through a waveguide or other transmission medium (e.g., a light pulse through a fiber optic cable), or an electrical signal transmitted through a wire.

[0070] The computer-readable program instructions described herein may 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, optical transmission 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 for storage in a computer-readable storage medium within the corresponding computing / processing device.

[0071] The computer-readable program instructions for performing the operations in the embodiment can be assembler instructions, instruction set architecture (instruction-set-architecture, ISA) instructions, machine instructions, machine-related 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, partially on the user's computer, executed as an independent software package, partially on the user's computer and partially on a remote computer, or completely on a remote computer or server. In the last scenario, the remote computer can be connected to the user's computer through any type of network, and any type of network includes a local area network (localarea network, LAN) or a wide area network (wide area network, WAN); or connected to an external computer (for example, by using the Internet of an Internet service provider). In some embodiments, an electronic circuit including a programmable logic circuit, a field-programmable gate array (FPGA) or a programmable logic array (PLA) can execute computer-readable program instructions using state information of the computer-readable program instructions to customize the electronic circuit so as to perform various aspects of the embodiments.

[0072] Various aspects of the embodiments are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to the embodiments. It should be understood that each box of the flowchart 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.

[0073] These computer-readable program instructions may 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 can form a device for implementing the functions / actions specified in the flowchart and / or block diagram blocks. These computer-readable program instructions may also be stored in a computer-readable storage medium, which may instruct a computer, a programmable data processing device, and / or other devices to operate in a specific manner, so that the computer-readable storage medium storing the instructions includes an article containing the instructions, which are used to implement various aspects of the functions / actions specified in the flowchart and / or block diagram blocks.

[0074] 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 performed 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 implement the functions / behaviors specified in the flowchart and / or block diagram blocks.

[0075] The flow chart and block diagram in the figure illustrate the architecture, function and operation of the possible implementation of the system, method and computer program product according to various embodiments. In this regard, each square block in the flow chart or block diagram can represent the part of a module, section or instruction, including one or more executable instructions for realizing a specified logical function. In some alternative implementations, the function described in the square block may not be performed in the order described in the figure. For example, in fact, the two square blocks shown in succession can be performed almost simultaneously, or sometimes, the square blocks can be performed in the opposite order, determined according to the functions involved. It should also be noted that each square block in the block diagram and / or flow chart and the combination of square blocks in the block diagram and / or flow chart can be implemented by a system based on special-purpose hardware, which performs a specific function or action, or performs a combination of special-purpose hardware and computer instructions.

[0076] Now referring to the accompanying drawings, Figure 1 Schematic diagram of an exemplary system configured as a peer node in a blockchain network for some embodiments of the present invention. The exemplary blockchain node system 100 may perform processes such as 300 to implement code hotfixes in a blockchain network and / or use the system for other tasks that may or may not be related to the blockchain network. More details about these exemplary processes are as follows Figure 3 shown.

[0077] The blockchain node system 110 may include a set of interfaces to the network, as well as other devices and tools. These interfaces may include an input interface 112 and an output interface 114. The blockchain node system may also include one or more processors 122 and a memory 116 for executing a process such as 300, the storage device including a portion for storing code (program code storage device 126) and / or a memory for data such as device and / or machine parameters, control scenarios, etc. The blockchain node system may be physically located on a site, implemented on a mobile device, implemented as a distributed system, virtually implemented on a cloud service, implemented on a machine that is also used for other functions, and / or implemented through several options. Alternatively, the system or a portion thereof may be implemented on dedicated hardware, FPGA, and / or the like. Alternatively, the system or a portion thereof may be implemented on a server, a computer farm, a cloud, and / or the like. For example, the storage device 116 may include a local cache on the device, and some less commonly used data and code portions may be stored remotely.

[0078] The input interface 112 and the output interface 114 may include one or more wired and / or wireless network interfaces for connecting to one or more networks, such as a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a cellular network, the Internet, a combination thereof, and the like. The input interface 112 and the output interface 114 may also include one or more buses 130. The bus may include a wired and / or wireless interconnect interface, such as a universal serial bus (USB) interface, a serial port, and the like. In addition, the output interface 114 may include one or more wireless interfaces for receiving user requests and instructions about blockchain and / or other functions of the system, and the input interface 112 may include one or more wireless interfaces for receiving information from one or more devices. In addition, the input interface 112 may include specific means for communicating with one or more sensor devices, such as cameras, microphones, medical sensors, and the like. Similarly, the output interface 114 may include specific means for communicating with one or more display devices, such as speakers, displays, and the like.

[0079] The one or more processors 122, which may be homogeneous or heterogeneous, may include one or more processing nodes arranged for parallel processing, as a cluster and / or as one or more multi-core one or more processors. The processor may include a unit optimized for large number and matrix calculations, such as a Graphic Processing Unit (GPU). The storage device 116 may include one or more non-transient persistent storage devices, such as a hard disk, a flash memory array, etc. The storage device 116 may also include one or more volatile memory devices, such as random access memory (RAM) components, enhanced bandwidth memory such as video RAM (VRAM), etc. The storage device 116 may also include one or more network storage resources, such as a storage server, a network attached storage device (NAS), a network drive, etc., which may be accessed through one or more networks via the input interface 112 and the output interface 114.

[0080] The one or more processors 122 may execute one or more software modules, such as processes, scripts, applications, agents, utilities, tools, operating systems (OS), etc. A software module may include a plurality of program instructions stored in a non-transitory medium within a program code 126, which may reside on a storage medium 116. For example, the one or more processors 122 may execute a process including communication in a decentralized permissioned blockchain network, such as 300, etc. The processor may, for example, generate and / or maintain a copy of a data blockchain within the storage medium 116.

[0081] Reference now Figure 2 , which is a schematic diagram of an exemplary system of a blockchain network according to some embodiments of the present invention.

[0082] The network can be used to host one or more nodes in a blockchain network for managing medical, security or maintenance data, sensitive logs of financial transactions, etc. The network can support communication with virtual machines used as computing nodes as shown in 210, 212, 214, 216, 236, 238 and 240. The correspondence between virtual machines and physical machines can be any positive rational number. For example, the physical machine shown in 230 hosts virtual machines 236 and 238 at the same time, however, virtual machine 240 is implemented by physical machines 242 and 244.

[0083] The network may interface with external networks such as the Internet through gateways such as 224 and 222. The gateway may include functions such as routing, security, load management, billing, etc., however, some or all of these functions may also be handled by other computers within or outside the network.

[0084] Reference now Figure 3 , which is a flowchart of an example of hot code replacement in a blockchain network of some embodiments of the present invention; the processor 122 can execute the exemplary process 300 for various purposes, such as healthcare, real estate, energy, finance, supply chain, retail, automobiles, travel, insurance, voting, and network security management. Alternatively, the process 300 or part thereof can be performed using a remote system, an auxiliary system, etc.

[0085] The exemplary process 300 begins by receiving a code fix transaction proposal for a hot-fixed smart contract chaincode from an external validation entity, as shown at 302. The external validation entity may issue a code fix transaction proposal due to detection using formal property verification, static code checking, simulation that may use assertions derived from a DSL, dynamic insertion of smart contract code, logical compliance checking, etc., as well as due to manually managed update instructions.

[0086] The mechanism for notifying peers about a proposed code fix transaction may vary and may be outside the blockchain governance envelope.

[0087] As indicated at 304 , the example process 300 continues by applying a trust enforcement model to the code repair transaction proposal.

[0088] Trust enforcement models may differ between organizations participating in a blockchain network, which may be permissioned where trust is distributed, and each organization may have a different endorsement policy. For example, one organization may have a group of security and validation engineers performing static code analysis, while other organizations may apply their own formal verification and dynamic testing checklists, or a combination of both.

[0089] The exemplary process may begin by creating an empty endorsement set labeled ec, and while the size of ec is less than or equal to a threshold n, where n is the amount of endorsements required for an upgrade transaction, the set may select organization o from the consortium—which was not selected in a previous iteration—and a peer p of organization o, submit an upgrade transaction to peer p using the updated smart contract bytecode, and receive n case endorsements from peer p to add to the endorsement set ec.

[0090] When enough participants of the distributed trust network agree, or in response to confirmation of the trust enforcement mode, such as by collecting attestations from multiple network participants, the exemplary process 300 continues with receiving a block including a transaction implementing the code fix transaction proposal from an external verification entity, as shown at 306. This may be caused by the external verification entity publishing the code fix to the blockchain ordering service.

[0091] The block including the transaction implementing the code fix transaction proposal may be part of the blockchain, either as a separate block, or as a transaction in a block including one or more transactions received from a client or user.

[0092] The latter may occur, for example, after one or more peer nodes perform the following operations: receive a transaction proposal from a client node, the transaction proposal including a channel identifier and a chaincode identifier; generate a versioned read-write set by simulating the transaction proposal using a chaincode associated with the chaincode identifier; sign the versioned read-write set; and send the versioned read-write set to the client node.

[0093] The exemplary process 300 continues to apply the verification policy to each transaction in the block, as shown at 308. The exemplary verification policy may verify the validity of the provided bytecode by verifying that it is signed by an automated repair tool, or send the bytecode to an external service that performs formal verification or static code analysis to verify that the interests of the organization are maintained.

[0094] As shown at 310 , the example process 300 continues to check when a block including a transaction implementing a code repair transaction proposal satisfies a verification policy.

[0095] The trust enforcement model may include cryptographic verification of the number of peers that received the endorsement, or an alternative method agreed upon by the organizations participating in the blockchain network. This verifies the number of peers that received the endorsement from the operator for each peer.

[0096] Exemplary validation may include performing regular block and transaction validation and persistence logic. Once completed, for each valid transaction of the code update transaction type, the updated bytecode may be obtained from the ledger and sent to the JVM agent of the matching chaincode container.

[0097] The exemplary process 300 continues by appending the block to the ledger associated with the channel identifier, as shown at 312. The appending may be performed like appending a normal block in the ledger, and a special marking of the block including the code fix may be optional.

[0098] As indicated at 314 , the example process 300 continues to update the state based on the transaction so that subsequent transactions may be processed according to the fixed code.

[0099] Subsequently, as shown at 316, the example process 300 continues by applying hot code replacement using the smart contract chaincode associated with the channel identifier.

[0100] In an exemplary embodiment based on Java, the JVM agent can utilize the insertion API provided by the JVM to change the existing bytecode loaded in the JVM. Subsequently, each chaincode process can be started using static or dynamic agent loading and the JVM agent can be connected to the process. When the peer sends the updated bytecode of the smart contract, the agent can perform a "hot replacement" of the smart contract bytecode through the JVM's bytecode insertion API.

[0101] Also refer to Figure 4 , which is a schematic diagram of exemplary peer nodes according to some embodiments of the present invention.

[0102] Hyperledger Fabric is used herein as an exemplary decentralized ledger, however, it would be obvious to one skilled in the art to apply the present invention to other decentralized ledgers and such implementations are within the scope of the claims. Hyperledger Fabric uses containerization to execute smart contracts or chaincode logic, essentially, chaincodes are packaged and instantiated in chaincode containers, where chaincodes are provided with a shim that can handle the communication from the chaincode with the smart code logic to peers that may be in different containers in order to access world state information.

[0103] Hyperledger Fabric supports three programming languages ​​for chaincode: Java, NodeJS, and Golang. The disclosed solution can generally be used with smart contracts, running on programming languages ​​that support dynamic code updates. Dynamic code updates or hot code replacement can be performed through code insertion, dynamic class loading, dynamic code replacement, and / or other developable methods. Figure 4 An example deployment of a chaincode is described.

[0104] Also refer to Figure 5 , which is a schematic diagram of an exemplary blockchain network with an exemplary external verification entity according to some embodiments of the present invention.

[0105] It should be noted that the invention is described using Hyperledger Fabric permissioned blockchain as an exemplary embodiment, but those skilled in the art may apply the invention to other decentralized ledgers, and such implementations are within the scope of the claims. The invention introduces an end-to-end solution that automatically handles many aspects of smart contract code updates in a completely hands-off manner that does not require system downtime.

[0106] The present invention may include a new transaction type that supports hot code replacement, which transaction type may be marked as HeaderType_CHAINCODE_UPDATE. Using the disclosed transaction type, the header may indicate that the transaction includes a chaincode update, such as bytecode, to be inserted into the chaincode JVM through the new shim API. This is an exemplary method of implementing a transaction proposed by a code repair transaction characterized by a type identifier indicating a policy modification.

[0107] The present invention may include a new shim API that may be marked as Update([]byte) and may accept a byte slice that is the serialized bytecode of the chaincode to be loaded into the JVM.

[0108] The present invention may include a JVM agent or a JVM insertion agent to track the bytecode of the chaincode and communicate with an external verification entity, such as performing formal verification, for verification. Hot code replacement may be performed by a chaincode virtual machine agent such as a JVM agent executed by at least one processing circuit such as processor 122.

[0109] The present invention may include an external validation entity including a detection agent and a repair agent that can detect problems in the chaincode and suggest patches with fixes. Detection of potential property violations may include executing one or more methods such as formal verification, dynamic insertion of smart contract code, logical compliance checking, and static code analysis. Thus, the external validation entity may include a detection agent that executes code for automatically detecting potential property violations in smart contracts.

[0110] In order to maintain an appropriate level of decentralization for ledger integrity and possible incorporation of blockchain access policies, an update transaction policy needs to be introduced to indicate the threshold of eligible network participants that consent to a chaincode bytecode update.

[0111] This policy rule can be taken into account by the repair mechanism and can also be enforced by the peer during the verification phase.

[0112] Therefore, during the commit phase, the peer can transmit bytecode to the shim for update if and only if the update transaction successfully verifies. Figure 5 represents a suggested flow that details the process step by step.

[0113] First, in phase 1, the detection agent can publish patches including fixes for the bytecode. The detection agent can collect endorsements for chaincode update transactions according to the defined policies.

[0114] Each peer can then perform the endorsement phase of the new transaction in a customized manner in Phase 2. Peers can perform checks to ensure that the fixed code complies with organizational policies and internal compliance procedures, and then the transaction can be endorsed.

[0115] Later, in phase 3, once sufficient endorsements have been collected, the update chaincode transaction can be submitted to the blockchain’s ordering service for ordering.

[0116] Subsequently, in phase 4, each peer may verify the chaincode update transaction and store the bytecode in the ledger. For example, the trust enforcement model includes the number of peer nodes that received the endorsement from the operator, and each peer node cryptographically verifies that the number of peer nodes received the endorsement.

[0117] Then, in stage 5, once the transaction is verified, the update bytecode can be sent to the JVM agent.

[0118] Finally, in stage 6, the JVM agent may inject the update, for example, via a custom class loader.

[0119] An example code of peer verification logic could be:

[0120]

[0121]

[0122] Example code for shim accepting updates could be:

[0123]

[0124] The description of various embodiments is 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 better explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the market, or to enable other persons skilled in the art to understand the embodiments disclosed herein.

[0125] It is expected that during the life of the patent expiring on this application, many related decentralized ledger management code frameworks will be developed, and the scope of the term chaincode is intended to include a priori all such new technologies.

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

[0127] The terms "including", "comprising" and their conjugations mean "including but not limited to". This term encompasses the terms "consisting of" and "consisting essentially of.

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

[0129] 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.

[0130] 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.

[0131] When a numerical range is indicated herein, it is intended to include any number (fractional or integer) listed within the indicated range. The phrases "within the range of the first indicated number and the second indicated number" and "from the first indicated number to the second indicated number" are used interchangeably herein to include the first and second indicated numbers and all fractions and integers therebetween.

[0132] 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 various embodiments should not be considered essential features of these embodiments, unless the embodiments are inoperable without these elements.

[0133] 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, the present invention is intended to cover all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

[0134] The purpose of the applicant is that all publications, patents and patent applications mentioned in this specification are incorporated into this specification by reference in their entirety, just as each individual publication, patent or patent application is specifically and individually indicated when it is mentioned to be incorporated by reference in this article. In addition, the reference or identification of any reference of the application cannot be regarded as allowing such reference to take precedence over the present invention in the prior art. For section headings, they should not be interpreted as necessary limitations. In addition, one or more of any priority documents of the application are incorporated into this article by reference in their entirety.

Claims

1. A peer node in a blockchain network, characterized in that: The device comprises: at least one processing circuit configured to: Receive a code fix transaction proposal for a hot fix of a smart contract chaincode from an external validation entity; Proposing to apply a trust enforcement model to the code repair transaction; In response to confirmation of the trust enforcement model, receiving from the external verification entity a block including a transaction implementing the code repair transaction proposal; Applying a validation strategy to each transaction in the block; When the block including the transaction implementing the code repair transaction proposal satisfies the verification policy: appending the block to a ledger associated with the channel identifier; updating a state based on the transaction; Hot code replacement is applied using the smart contract chaincode associated with the channel identifier.

2. The peer node according to claim 1, characterized in that The external verification entity includes a detection agent that executes code for automatically detecting potential property violations in the smart contract.

3. The peer node according to claim 2, characterized in that The detection of potential property violations includes performing a method selected from the group consisting of formal verification, dynamic insertion of smart contract code, logical compliance checking, and static code analysis.

4. The peer node according to claim 1, characterized in that The trust enforcement model includes a number of the peer nodes receiving an endorsement from an operator, each peer node cryptographically verifying that the number of the peer nodes received the endorsement.

5. The peer node according to claim 1, characterized in that The hot code replacement is performed by a chaincode virtual machine agent executed by the at least one processing circuit.

6. The peer node according to claim 5, characterized in that The hot code replacement is performed by a method selected from the group consisting of dynamic class loading, code insertion, and dynamic code replacement.

7. The peer node according to claim 1, characterized in that The transaction implementing the code repair transaction proposal is characterized by a type identifier indicating a policy modification.

8. A method for hot code replacement in a blockchain network, characterized in that: The method comprises: Receive a code fix transaction proposal for a hot fix of a smart contract chaincode from an external validation entity; Proposing to apply a trust enforcement model to the code repair transaction; In response to confirmation of the trust enforcement model, receiving from the external verification entity a block including a transaction implementing the code repair transaction proposal; Applying a validation strategy to each transaction in the block; When the block including the transaction implementing the code repair transaction proposal satisfies the verification policy: appending the block to a ledger associated with the channel identifier; updating a state based on the transaction; Hot code replacement is applied using the smart contract chaincode associated with the channel identifier.

9. The method according to claim 8, characterized in that The external verification entity includes a detection agent that executes code for automatically detecting potential property violations in the smart contract.

10. The method according to claim 9, characterized in that The detection of potential property violations includes performing a method selected from the group consisting of formal verification, dynamic insertion of smart contract code, logical compliance checking, and static code analysis.

11. The method according to claim 8, characterized in that The trust enforcement model includes a number of peer nodes receiving an endorsement from an operator, each peer node cryptographically verifying that the number of peer nodes received the endorsement.

12. The method according to claim 8, characterized in that The hot code replacement is performed by the chaincode virtual machine agent.

13. The method according to claim 12, characterized in that The hot code replacement is performed by a method selected from the group consisting of dynamic class loading, code insertion, and dynamic code replacement.

14. The method according to claim 8, characterized in that The transaction implementing the code repair transaction proposal is characterized by a type identifier indicating a policy modification.

15. One or more computer program products comprising instructions for hot code replacement in a blockchain network, characterized in that: Execution of the instructions by one or more processors of a computing system will cause the computing system to: Receive a code fix transaction proposal for a hot fix of a smart contract chaincode from an external validation entity; Proposing to apply a trust enforcement model to the code repair transaction; In response to confirmation of the trust enforcement model, receiving from the external verification entity a block including a transaction implementing the code repair transaction proposal; Applying a validation strategy to each transaction in the block; When the block including the transaction implementing the code repair transaction proposal satisfies the verification policy: appending the block to a ledger associated with the channel identifier; updating a state based on the transaction; Hot code replacement is applied using the smart contract chaincode associated with the channel identifier.

Images