WO2024002468A1

WO2024002468A1 - Automated smart contract hot updates

Info

Publication number: WO2024002468A1
Application number: PCT/EP2022/067736
Authority: WO
Inventors: Artem Barger; Avigail Oron
Original assignee: Huawei Cloud Computing Technologies Co., Ltd.
Priority date: 2022-06-28
Filing date: 2022-06-28
Publication date: 2024-01-04

Abstract

A method and a system implementing a solution that can automatically handle all aspects of smart contract code updates in a way that is completely hands-off and requires no downtime of the system. The disclosure comprises a new transaction wherein the header indicates that transaction comprises byte code to be instrumented into chaincode JVM via a shim API as disclosed, a new shim API which may accept slices of bytes which are serialized byte code of the chaincode to be loaded into JVM., and a JVM instrumentation agent and an agent for detection and repair.

Description

AUTOMATED SMART CONTRACT HOT UPDATES

BACKGROUND

Some embodiments described in the present disclosure relate to a decentralized ledger management and, more specifically, but not exclusively, to a ledger code hot fix method.

While digital currency may be the best known use for distributed ledgers, characterized by no need to trust any specific single entity, the technology is useful for many other fields, and much effort is spent on research, development, and deployment of decentralized ledgers. Decentralized ledger management may comprise smart contracts, which may be applied and/or enforced using code, which may be referred to as chaincode, particularly when the ledger is blockchain based.

The smart contracts often embody complex business rules which may be expressed in either programming language or using a domain specific language (DSL).

Smart contracts’ implementation are often subject to the programming errors due to human mistakes and the inherent complexity of the blockchain system. Syntax choices of DSL or programing language may mislead contract developers and becoming root cause of many bugs.

There are variety of technique developed to assist programmers to mitigate potential risk of introducing bugs or ambiguous and error prone logic that can also be used for smart contracts, which may be coded in a manner enabling use of verification techniques, such as formal verification that analyzes the code and detects potential issues with the logic. Some formal verification tools are also able to generate a repaired version of the code.

Static code analysis tools that hint the user of erroneous behavior of the smart contract logic, for example, the upgrade process in a permissioned blockchain may include the following steps: Collect consent from a sufficient amount of the consortium organizations, according to upgrade policy. Distribute the updated smart contract to all required consortium organizations. Per organization - deploy the smart contract, usually on multiple blockchain nodes. And upgrade the smart contract to the newer version. Once all required organizations have completed the upgrade, the smart contract is available for the blockchain clients.

During the upgrade process, transactions submitted to this smart contract are likely to fail due to misalignment of the logic cross the multiple organizations. This may compromise the service level agreement (SLA) of the system. Note that the upgrade process spans multiple organizations prolongs it and thus harder to orchestrate.

Dynamic code loading and code instrumentation to enable code replacement with zero down time for centralized applications have been developed. For example, JRebel integrates with the java virtual machine (JVM) and application servers on a class loader level, it wraps class loaders around classes and enables to dynamically reload Java classes via instrumentation.

SUMMARY

It is an object of the present disclosure to describe a system and a method for hot code replacement in a blockchain network, using a type of a transaction comprised by the blockchain which is comprised in the disclosure.

The foregoing and other objects are achieved by the features of the independent claims. Further implementation forms are apparent from the dependent claims, the description and the figures.

According to an aspect of some embodiments of the present disclosure, there is provided a peer node in a blockchain network, the device comprising: at least one processing circuitry configured to: receive a code fix transaction proposal for a smart contract chaincode adapted for hot fix from an external validation entity; apply a trust enforcement model on the code fix transaction proposal; in response to confirmation of the trust enforcement model, receive a block comprising a transaction implementing the code fix transaction proposal from the external validation entity; apply a validation policy on each transaction in the block; and when the validation policy is met for the block comprising a transaction implementing the code fix transaction proposal: append the block to a ledger associated with a channel identifier; update the state based in the transaction; and apply a hot code replacement using the on the smart contract chaincode associated with the channel identifier.

According to an aspect of some embodiments of the present disclosure, there is provided a method for hot code replacement in a blockchain network, the method comprising: receiving a code fix transaction proposal for a smart contract chaincode adapted for hot fix from an external validation entity; applying a trust enforcement model on the code fix transaction proposal; in response to confirmation of the trust enforcement model, receiving a block comprising a transaction implementing the code fix transaction proposal from the external validation entity; applying a validation policy on each transaction in the block; and when the validation policy is met for the block comprising a transaction implementing the code fix transaction proposal: appending the block to a ledger associated with a channel identifier; updating the state based in the transaction; and applying a hot code replacement using the on the smart contract chaincode associated with the channel identifier.

According to an aspect of some embodiments of the present disclosure, there is provided one or more computer program products comprising instructions for hot code replacement in a blockchain network, wherein execution of the instructions by one or more processors of a computing system is to cause a computing system to: receive a code fix transaction proposal for a smart contract chaincode adapted for hot fix from an external validation entity; apply a trust enforcement model on the code fix transaction proposal; in response to confirmation of the trust enforcement model, receive a block comprising a transaction implementing the code fix transaction proposal from the external validation entity; apply a validation policy on each transaction in the block; and when the validation policy is met for the block comprising a transaction implementing the code fix transaction proposal: append the block to a ledger associated with a channel identifier; update the state based in the transaction; and apply a hot code replacement using the on the smart contract chaincode associated with the channel identifier.

Optionally, the external validation entity comprises a detection agent, executing code for automatic detection of potential property violations in the smart contract.

Optionally, the detection of potential property violations comprises execution of a method selected from a group consisting of formal verification, dynamic instrumentation of the smart contract code, logic compliance checks and static code analysis.

Optionally, the trust enforcement model comprising a number of the peer nodes receiving an endorsement from an operator and each peer node cryptographically validates that the number of the peer nodes received the endorsement.

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

Optionally ,the hot code replacement is executed by a method selected from a group consisting of dynamic class loading, code instrumentation, and dynamic code replacement.

Optionally, the transaction implementing the code fix transaction proposal is characterized by a type identifier indication policy modification. Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.

Unless otherwise defined, all technical and/or scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which embodiments. Although methods and materials similar or equivalent to those described herein can be used in the practice or testing of embodiments, exemplary methods and/or materials are described below. In case of conflict, the patent specification, including definitions, will control. In addition, the materials, methods, and examples are illustrative only and are not intended to be necessarily limiting.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGIS)

Some embodiments are herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of embodiments. In this regard, the description taken with the drawings makes apparent to those skilled in the art how embodiments may be practiced.

In the drawings:

FIG. 1 is a schematic illustration of an exemplary system configured as a peer node in a blockchain network, according to some embodiments of the present disclosure;

FIG. 2 is a schematic illustration of an exemplary system of a blockchain network, according to some embodiments of the present disclosure;

FIG. 3 is a flowchart of an exemplary for hot code replacement in a blockchain network, according to some embodiments of the present disclosure;

FIG. 4 is a flowchart of an exemplary for hot code replacement in a blockchain network, according to some embodiments of the present disclosure; and FIG. 5 is a schematic illustration of an exemplary blockchain network with an exemplary external validation entity, according to some embodiments of the present disclosure.

DETAILED DESCRIPTION

The problem of substantial downtime may arise when a fixed version of the smart contract is produced, either automatically or manually, and the need to apply the fixed version all across the blockchain cluster. The known upgrade processes are complex, cumbersome and it usually results in transaction invalidation during the upgrade process.

JRebel for example, which integrates with the JVM and application servers on the class loader level, does not support a collected endorsement, or a synchronous process of proceeding with updated code across distributed networks.

Additionally, the cross-org orchestration of the upgrade process doesn’t suggest repair mechanism for smart contract logic, thus providing a repair to fix the smart contract logic and also to dynamically replace code requires downtime of the application based on the smart contract.

The disclosure comprises a hot code replacement in an optionally decentralized permissioned blockchain network design for a suggested solution. Though some of the figures are based on a Hyperledger Fabric, a person skilled in the art may apply the disclosed design on other networks, and the disclosure should not be construed limited or scoped to Hyperledger Fabric application only.

Some networks may implement containerization to execute smart contracts or chaincode logic, basically the chaincode may be packed and instantiated within container, where it’s provided with the shim capable to handle communication from chaincode to peer in order to access the world state information. The disclosure comprises introducing an end to end solution that can automatically handle all aspects of smart contract code updates in a way that is completely hands-off and requires no downtime of the system.

The disclosure further comprises a new transaction wherein the header indicates that transaction comprises byte code to be instrumented into chaincode JVM via a shim API as disclosed.

The disclosure also comprises anew shim API which may accept slices of bytes which are serialized byte code of the chaincode to be loaded into JVM.

The disclosure further comprises a JVM instrumentation agent and an agent for detection and repair.

The agent that leverages hot code replacement method may apply dynamic class loading, code instrumentation, dynamic code replacement and/or the like for smart contract code.

The new transaction type added to the blockchain framework may handle upgrade transactions regarding smart contract code verification, and upgrade policy verification.

The disclosure may be based on leveraging the built-in block propagation mechanism of blockchain for the distribution of new smart contract code versions. Smart contract repair may be fully automated end-to-end, thus no downtime may be required for business logic updates of smart contracts or updates of chaincode upgrade policy. Furthermore, resolving the need to orchestrate propagation of updated files cross all consortium organizations may enable aster logic updates cross the consortium.

Before explaining at least one embodiment in detail, it is to be understood that embodiments are not necessarily limited in its application to the details of construction and the arrangement of the components and/or methods set forth in the following description and/or illustrated in the drawings and/or the Examples. Implementations described herein are capable of other embodiments or of being practiced or carried out in various ways.

Embodiments may be a system, a method, and/or a computer program product. The computer program product may include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the embodiments. The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is 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 foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, 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 foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of embodiments may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of embodiments.

Aspects of embodiments are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks. The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardwarebased systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

Referring now to the drawings, FIG. 1 is a schematic illustration of an exemplary system configured as a peer node in a blockchain network, according to some embodiments of the present disclosure. An exemplary blockchain node system 100 may execute processes such as 300 for implementing code hot fixes in the blockchain network, and/or using the system for other tasks, which may or may not be related to the blockchain network. Further details about these exemplary processes follow as FIG. 3 is described.

The blockchain node system 110 may include a set of interfaces to a network, as well as other devices and instruments. The interfaces may comprise an input interface 112, and an output interface 114. The blockchain node system may also comprise one or more processors 122 for executing processes such as 300, and storage 116, comprising a portion for storing code (program code storage 126) and/or memory for data, such as device and/or machine parameters, control scenarios, and/or the like. The blockchain node system may be physically located on a site, implemented on a mobile device, implemented as distributed system, implemented virtually on a cloud service, on machines also used for other functions, and/or by several options. Alternatively, the system, or parts thereof, may be implemented on dedicated hardware, FPGA and/or the likes. Further alternatively, the system, or parts thereof, may be implemented on a server, a computer farm, the cloud, and/or the likes. For example, the storage 116 may comprise a local cache on the device, and some of the less frequently used data and code parts may be stored remotely. The input interface 112, and the output interface 114 may comprise one or more wired and/or wireless network interfaces for connecting to one or more networks, for example, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a cellular network, the internet, a combination thereof, and/or the like. The input interface 112, and the output interface 114 may further include one or more buses 130. The buses may comprise wired and/or wireless interconnection interfaces, for example, a universal serial bus (USB) interface, a serial port, and/or the like. Furthermore, the output interface 114 may include one or more wireless interfaces for receiving user requests and instructions regarding the 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. Additionally, the input interface 112 may include specific means for communication with one or more sensor devices such as a camera, microphone, medical sensor and/or the like. And similarly, the output interface 114 may include specific means for communication with one or more display devices such as a loudspeaker, display and/or the like.

The one or more processors 122, homogenous or heterogeneous, may include one or more processing nodes arranged for parallel processing, as clusters and/or as one or more multi core one or more processors. The processor may comprise units optimized for large numbers and matrices computations such as Graphic Processing Units (GPU). The storage 116 may include one or more non-transitory persistent storage devices, for example, a hard drive, a Flash array and/or the like. The storage 116 may also include one or more volatile memory devices, for example, a random access memory (RAM) component, enhanced bandwidth memory such as video RAM (VRAM), and/or the like. The storage 116 may further include one or more network storage resources, for example, a storage server, a network attached storage (NAS), a network drive, and/or the like accessible via one or more networks through the input interface 112, and the output interface 114.

The one or more processors 122 may execute one or more software modules such as, for example, a process, a script, an application, an agent, a utility, a tool, an operating system (OS) and/or the like. The software modules may comprise a plurality of program instructions stored in a non-transitory medium within the program code 126, which may reside on the storage medium 116. For example, the one or more processors 122 may execute a process, comprising communication in a decentralized permissioned blockchain network such as 300 and/or the like. This processor may generate and/or maintain a copy of a d blockchain, for example within the storage medium 116. Referring now to, FIG. 2 which is a schematic illustration of an exemplary system of a blockchain network, according to some embodiments of the present disclosure.

The network may be used for hosting one or more nodes in a blockchain network for managing sensitive logs of medical, security, or maintenance data, financial transactions, and/or the like. The network may allow communication with virtual machines functioning as computing nodes, as shown in 210,212,214,216,236,238 and 240. The correspondence between virtual machines and physical machines may be of any positive rational number. For example, the physical machine shown in 230 hosts both virtual machines 236 and 238, however, the virtual machine 240 is implemented by both physical machines 242 and 244.

The network may interface the outside network, e.g. the internet, through gateways such as 224 and 222. Gateways may comprise features such as routing, security, load management, billing, and/or the like however some, or all of these features may also be otherwise handled by other machines in or outside the network.

Referring now to FIG. 3, which is a flowchart of an exemplary for hot code replacement in a blockchain network, according to some embodiments of the present disclosure. The processor 122 may execute the exemplary process 300 for a variety of purposes such as healthcare, real estate, energy, finance, supply chain, retail, automotive, travel, insurance, voting and cybersecurity management and/or the like. Alternatively, the process 300 or parts thereof may be executing using a remote system, an auxiliary system, and/or the like.

The exemplary process 300 starts, as shown in 302, with receiving a code fix transaction proposal for a smart contract chaincode adapted for hot fix from an external validation entity. The external validation entity may issue a receiving a code fix transaction proposal due to detection using formal property verification, static code checking, simulations, possibly using assertion derived from DSL, dynamic instrumentation of the smart contract code, logic compliance checks, and/or the likes, and also due to manually administered update instruction.

The mechanism to inform peer nodes about the code fix transaction proposal may vary, and may be external to the blockchain management envelope.

The exemplary process 300 continues, as shown in 304, with applying a trust enforcement model on the code fix transaction proposal. The trust enforcement model may vary between organization participating in the blockchain network, which may be decentralized permissioned wherein the trust is distributed, and each may have a different endorsement policy. For example, one organization may have a group of security and verification engineers performing static code analysis, others may apply their own formal verification and dynamic test checklist, or both.

An exemplary process may start with creating an empty endorsement collection marked ec, and while size of ec is smaller or equal to a threshold n, n being the amount of endorsements required for upgrade transactions it may select an organization o from the consortium, o was not selected in previous iterations, and a peer p of org o, submit upgrade transaction to peer p with the updated smart contract bytecode, and n case endorsement was received from peer p, add to endorsement collection ec.

When enough of the participants of the distributed trust network agree, or in response to confirmation of the trust enforcement mode, for example by collecting attestation from a plurality of network participants, the exemplary process 300 continues, as shown in 306, with receiving a block comprising a transaction implementing the code fix transaction proposal from the external validation entity. This may result from the external validation entity issuing the code fix to the blockchain ordering service.

The block comprising a transaction implementing the code fix transaction proposal may be a part of the blockchain, either as a separate block or as a transaction in a block comprising one or more transactions received form clients or users.

The latter may occur, for example following one or more peer nodes receiving a transaction proposal from a client node, the transaction proposal comprising a channel identifier and a chaincode identifier, producing a versioned read-write set by simulating the transaction proposal using a chaincode associated with the chaincode identifier, signing the versioned read- write set;, and sending the versioned read-write set to the client node.

The exemplary process 300 continues, as shown in 308, with applying a validation policy on each transaction in the block. An exemplary validation policy may verify that the supplied bytecode is valid by verifying it is signed by the automatic repair tool, or send it to an external service that performs formal verification or static code analysis to verify that this organization’s interests are kept. The exemplary process 300 continues, as shown in 310, with checking when the validation policy is met for the block comprising a transaction implementing the code fix transaction proposal.

The trust enforcement model may comprise cryptographically validating that the number of the peer nodes received the endorsement, or an alternative method agreed by the organizations participating in the blockchain network. This the number of the peer nodes receiving an endorsement from an operator in each peer node may be validated.

An exemplary validation may comprise perform the regular block and transaction validation and persistence logic. Once completed, for every valid transaction of code update transaction type, the updated bytecode may be taken from ledger and send to the JVM Agent of the matching chaincode container.

The exemplary process 300 continues, as shown in 312, with appending the block to a ledger associated with a channel identifier. The appending may be done as ordinary blocks in the ledger are appended, and special marking of blocks comprising code fixes may be optional.

The exemplary process 300 continues, as shown in 314 updating the state based in the transaction, so following transactions may be processed according to the fixed code.

And subsequently, the exemplary process 300 continues, as shown in 316 applying a hot code replacement using the on the smart contract chaincode associated with the channel identifier.

In an exemplary Java based embodiment, the JVM Agent may utilizes the Instrumentation API that the JVM provides to alter existing byte-code that is loaded in a JVM. Followingly each chaincode process may be launched with a JVM Agent attached to it, using either static or dynamic agent loading. And when the peer sends the updated bytecode for a smart contract, the agent may perform a “hot replacement” of the smart contract bytecode via the JVM’s bytecode instrumentation API.

Reference is also made to FIG. 4, which is a schematic illustration of an exemplary peer node, according to some embodiments of the present disclosure.

Hyperledger Fabric serves herein as an exemplary decentralized ledger, however it is obvious to a person skilled in the art to apply the disclosure 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, basically the chaincode is packed and instantiated within the chaincode container, where it’s provided with the shim capable to handle communication from chaincode, having smart code logic, to a peer, which may be in a different container, in order to access the world state information.

Hyperledger Fabric support three programming languages for chaincodes: Java, NodeJS and Golang. The disclosed solution may be used with smart contract in general, running on programming languages which support dynamic update of the code. The dynamic update of the code, or the hot code replacement, may be executed through code instrumentation, by dynamic class loading, dynamic code replacement, and/or other methods which may be developed. FIG 4. Depicts an exemplary deployment of the chaincode.

Reference is also made to FIG. 5, which is a schematic illustration of an exemplary blockchain network with an exemplary external validation entity, according to some embodiments of the present disclosure.

It should be noted that the disclosure leverage Hyperledger Fabric permissioned blockchain as an exemplary embodiment to describe the design of disclosure, though a person skilled in the art may apply the disclosure to other decentralized ledgers, and such implementations are within the scope of the claims. The disclosure introduces an end to end solution that may automatically handle many aspects of smart contract code updates in a way that is completely hands-off and requires no downtime of the system.

The disclosure may comprise a new transaction type to support hot code replacement, which may be labelled as HeaderType CHAINCODE UPDATE. Using the disclosed transaction type, the header may indicate that transaction includes chaincode update, for example byte code, to be instrumented into chaincode JVM via new shim API. This is an exemplary method for a transaction implementing the code fix transaction proposal, characterized by a type identifier indication policy modification.

The disclosure may comprise anew shim API which may be labelled as Update([]byte), and may accept slices of bytes which may be serialized byte code of the chaincode to be loaded into JVM.

The disclosure may comprise a JVM agent or a JVM instrumentation agent to keep track of chaincode’s byte code and communicates to the external validation entity, performing for example formal verification, for validation. The hot code replacement may be performed by a chaincode virtual machine agent such as the JVM agent, executed by the at least one processing circuitry such as the processor 122.

The disclosure may comprise an external validation entity, comprising a detection agent and a repair agents which may detect issues within chaincode and suggest patches with fixes. The detection of potential property violations may comprise execution of one or more methods such as formal verification, dynamic instrumentation of the smart contract code, logic compliance checks and static code analysis. Thereby, the external validation entity may comprise a detection agent, executing code for automatic detection of potential property violations in the smart contract.

In order to maintain ledger integrity and proper level of decentralization that may incorporate blockchain access policies, there is a need to introduce policy for update transaction, for indicating a threshold of eligible network participants agreeing on chaincode byte code update.

The repair mechanism may take into the account this policy rules, and peers may also enforce it during validation phase.

Therefore, during commit phase a peer may communicate to the shim the byte code for update if and only if the update transaction is successfully validated. FIG. 5 represent a suggested flow step by step to elaborate on the process.

First, in stage 1, The Detection Agent may issue a patch for the byte code that includes the fix. The Detection Agent may collect endorsement for chaincode update transaction based on the defined policies.

Followingly, in stage 2, each peer may perform the endorsement phase for the new transaction in a customized manner. The peers may perform checks to ensure the repaired code conforms to the organization politics and internal compliance procedure, and followingly the transaction may be endorsed.

Followingly, in stage 3, when enough endorsements are collected, the update chaincode transaction may be submitted to the ordering service of the blockchain for ordering.

Followingly, in stage 4, each peer may validate the chaincode update transactions and store the byte code into the ledger. For example, the trust enforcement model may comprise a number of the peer nodes receiving an endorsement from an operator, and each peer node cryptographically validates that the number of the peer nodes received the endorsement.

Followingly, in stage 5, once the transaction is validated the update byte code may be sent to the JVM agent.

And finally, in stage 6, the JVM agent may instrument the update, for example via a custom class loader.

An exemplary code for peer side validation logic may be: for each tx in Block. Data() { tx hdr = extractHeader(tx) if tx hdr == ChaincodeUpdate { if hasEnoughSignatures(tx) { byteCode = readByteCode(tx) channellD = tx.ChannellD ccName = tx.ChaincodeName sendToCC(channelID, ccName, byteCode)

An exemplary code for shim accepting update may be: byteCode = byteCodeFromPeer() if valid(byteCode) { getClassLoader().UpdateByteCode(byteCode)

The descriptions of the various embodiments have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

It is expected that during the life of a patent maturing from this application many relevant decentralized ledger management code frameworks will be developed and the scope of the term chaincode is intended to include all such new technologies a priori.

As used herein the term “about” refers to ± 10 %.

The terms "comprises", "comprising", "includes", "including", “having” and their conjugates mean "including but not limited to". This term encompasses the terms "consisting of and "consisting essentially of.

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

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 from other embodiments.

The word “optionally” is used herein to mean “is provided in some embodiments and not provided in other embodiments”. Any particular embodiment may include a plurality of “optional” features unless such features conflict.

Whenever a numerical range is indicated herein, it is meant to include any cited numeral (fractional or integral) within the indicated range. The phrases “ranging/ranges between” a first indicate number and a second indicate number and “ranging/ranges from” a first indicate number “to” a second indicate number are used herein interchangeably and are meant to include the first and second indicated numbers and all the fractional and integral numerals therebetween.

It is appreciated that certain features of embodiments, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of embodiments, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination or as suitable in any other described embodiment. Certain features described in the context of various embodiments are not to be considered essential features of those embodiments, unless the embodiment is inoperative without those elements.

Although embodiments have been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims.

It is the intent of the applicant(s) that all publications, patents and patent applications referred to in this specification are to be incorporated in their entirety by reference into the specification, as if each individual publication, patent or patent application was specifically and individually noted when referenced that it is to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present disclosure. To the extent that section headings are used, they should not be construed as necessarily limiting. In addition, any priority document(s) of this application is/are hereby incorporated herein by reference in its/their entirety.

Claims

1. A peer node in a blockchain network, the device comprising: at least one processing circuitry configured to: receive a code fix transaction proposal for a smart contract chaincode adapted for hot fix from an external validation entity; apply a trust enforcement model on the code fix transaction proposal; in response to confirmation of the trust enforcement model, receive a block comprising a transaction implementing the code fix transaction proposal from the external validation entity; apply a validation policy on each transaction in the block; and when the validation policy is met for the block comprising a transaction implementing the code fix transaction proposal: append the block to a ledger associated with a channel identifier; update the state based in the transaction; and apply a hot code replacement using the on the smart contract chaincode associated with the channel identifier.

2. The peer node of claim 1, wherein the external validation entity comprises a detection agent, executing code for automatic detection of potential property violations in the smart contract.

3. The peer node of claim 2, wherein the detection of potential property violations comprises execution of a method selected from a group consisting of formal verification, dynamic instrumentation of the smart contract code, logic compliance checks and static code analysis.

4. The peer node of claim 1 , wherein the trust enforcement model comprising a number of the peer nodes receiving an endorsement from an operator and each peer node cryptographically validates that the number of the peer nodes received the endorsement.

5. The peer node of claim 1, wherein the hot code replacement is performed by a chaincode virtual machine agent executed by the at least one processing circuitry.

6. The peer node of claim 5, wherein the hot code replacement is executed by a method selected from a group consisting of dynamic class loading, code instrumentation, and dynamic code replacement.

7. The peer node of claim 1, wherein the transaction implementing the code fix transaction proposal is characterized by a type identifier indication policy modification.

8. A method for hot code replacement in a blockchain network, the method comprising: receiving a code fix transaction proposal for a smart contract chaincode adapted for hot fix from an external validation entity; applying a trust enforcement model on the code fix transaction proposal; in response to confirmation of the trust enforcement model, receiving a block comprising a transaction implementing the code fix transaction proposal from the external validation entity; applying a validation policy on each transaction in the block; and when the validation policy is met for the block comprising a transaction implementing the code fix transaction proposal: appending the block to a ledger associated with a channel identifier; updating the state based in the transaction; and applying a hot code replacement using the on the smart contract chaincode associated with the channel identifier.

9.The method of claim 8, wherein the external validation entity comprises a detection agent, executing code for automatic detection of potential property violations in the smart contract.

10. The method of claim 9, wherein the detection of potential property violations comprises execution of a method selected from a group consisting of formal verification, dynamic instrumentation of the smart contract code, logic compliance checks and static code analysis.

11. The method of claim 8, wherein the trust enforcement model comprising a number of the peer nodes receiving an endorsement from an operator and each peer node cryptographically validates that the number of the peer nodes received the endorsement.

12. The method of claim 8, wherein the hot code replacement is performed by a chaincode virtual machine agent.

13. The method of claim 12 wherein the hot code replacement is executed by a method selected from a group consisting of dynamic class loading, code instrumentation, and dynamic code replacement.

14. The method of claim 8, wherein the transaction implementing the code fix transaction proposal is characterized by a type identifier indication policy modification.

15. One or more computer program products comprising instructions for hot code replacement in a blockchain network, wherein execution of the instructions by one or more processors of a computing system is to cause a computing system to: receive a code fix transaction proposal for a smart contract chaincode adapted for hot fix from an external validation entity; apply a trust enforcement model on the code fix transaction proposal; in response to confirmation of the trust enforcement model, receive a block comprising a transaction implementing the code fix transaction proposal from the external validation entity; apply a validation policy on each transaction in the block; and when the validation policy is met for the block comprising a transaction implementing the code fix transaction proposal: append the block to a ledger associated with a channel identifier; update the state based in the transaction; and apply a hot code replacement using the on the smart contract chaincode associated with the channel identifier.