FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENT RULES, 2003
COMPLETE SPECIFICATION (See Section 10 and Rule 13)
Title of invention:
METHODS AND SYSTEMS FOR LIFECYCLE GOVERNANCE OF
BLOCKCHAIN
Applicant
Tata Consultancy Services Limited A company Incorporated in India under the Companies Act, 1956
Having address:
Nirmal Building, 9th floor,
Nariman point, Mumbai 400021,
Maharashtra, India
Preamble to the description:
The following specification particularly describes the invention and the manner in which it is to be performed.

CROSS-REFERENCE TO RELATED APPLICATIONS AND PRIORITY
[001] The present application claims priority from Indian provisional application no. 201921037036, filed on September 13, 2019. The entire contents of the aforementioned application are incorporated herein by reference.
TECHNICAL FIELD [002] The disclosure herein generally relates to the field of blockchain technology, and, more particularly, to methods and systems for life-cycle governance of blockchain networks.
BACKGROUND
[003] Blockchain as a robust technology is rapidly entering into different industry segments such as banks, insurance, supply chain, logistic, travel and hospitality, manufacturing and so on. Many organizations are understanding potential benefits of blockchain technology and finding ways to deploy the blockchain technology irrespective of their industry segments.
[004] As more and more organizations start using the blockchain technology or join a consortium, maintaining a lifecycle of the blockchain network may become an important aspect. Maintaining the lifecycle of the blockchain network may include functionalities such as adding or decommissioning a node, changing the blockchain network from one platform to another platform, sharding, forking, monitoring health of the blockchain network and so on. Conventional blockchain lifecycle management tools are limited to fewer functionalities and are platform dependent.
SUMMARY [005] Embodiments of the present disclosure present technological improvements as solutions to one or more of the above-mentioned technical problems recognized by the inventors in conventional systems. For example, in one aspect, a processor-implemented method for lifecycle governance of a blockchain network having one or more nodes is provided. The method comprises performing

one or more of: receiving a request for change from one or more nodes, wherein the change is associated with at least one of request types comprising (i) adding a new node in the blockchain network (ii) adding a new functionality to the one or more nodes, (iii) adding a functionality enhancement to the one or more nodes, and (iv) a change in the blockchain network; managing the change based on the request type and a consensus mechanism; allowing the nodes of the blockchain network to move from a current blockchain platform to one of a blockchain platform present in a predefined list of blockchain platforms; allowing a forking operation on the blockchain network based on the consensus mechanism, wherein the forking operation is one among a predefined forking operation types comprising (i) forking on the blockchain network and (ii) forking on contract, the forking on contract comprises a hard forking and a soft forking; allowing a sharding operation on the blockchain network using a sharding algorithm; decommissioning the blockchain network, upon receiving a decommissioning request, based on an authorization criteria; and continuously monitoring a health status of the blockchain network and automatically performing auto-healing.
[006] In another aspect, a system for lifecycle governance of a blockchain network having one or more nodes is provided. The system comprises: a memory storing instructions; one or more Input/Output (I/O) interfaces; and one or more hardware processors coupled to the memory via the one or more I/O interfaces, wherein the one or more hardware processors are configured by the instructions to perform one of more of: receive a request for change from one or more nodes, wherein the change is associated with at least one of request types comprising (i) adding a new node in the blockchain network (ii) adding a new functionality to the one or more nodes, (iii) adding a functionality enhancement to the one or more nodes, and (iv) a change in the blockchain network; manage the change based on the request type and a consensus mechanism; allow the nodes of the blockchain network to move from a current blockchain platform to one of a blockchain platform present in a predefined list of blockchain platforms; allow a forking operation on the blockchain network based on the consensus mechanism, wherein the forking operation is one among a predefined forking operation types comprising

(i) forking on the blockchain network and (ii) forking on contract, the forking on contract comprises a hard forking and a soft forking; allow a sharding operation on the blockchain network using a sharding algorithm; decommission the blockchain network, upon receiving a decommissioning request, based on an authorization criteria; and continuously monitor a health status of the blockchain network and automatically performing auto-healing.
[007] In yet another aspect, there is provided a computer program product comprising a non-transitory computer readable medium having a computer readable program embodied therein, wherein the computer readable program, when executed on a computing device, causes the computing device to: receive a request for change from one or more nodes, wherein the change is associated with at least one of request types comprising (i) adding a new node in the blockchain network (ii) adding a new functionality to the one or more nodes, (iii) adding a functionality enhancement to the one or more nodes, and (iv) a change in the blockchain network; manage the change based on the request type and a consensus mechanism; allow the nodes of the blockchain network to move from a current blockchain platform to one of a blockchain platform present in a predefined list of blockchain platforms; allow a forking operation on the blockchain network based on the consensus mechanism, wherein the forking operation is one among a predefined forking operation types comprising (i) forking on the blockchain network and (ii) forking on contract, the forking on contract comprises a hard forking and a soft forking; allow a sharding operation on the blockchain network using a sharding algorithm; decommission the blockchain network, upon receiving a decommissioning request, based on an authorization criteria; and continuously monitor a health status of the blockchain network and automatically performing auto-healing.
[008] It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention, as claimed.
BRIEF DESCRIPTION OF THE DRAWINGS

[009] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, serve to explain the disclosed principles:
[010] FIG.1 is an exemplary functional block diagram of a system for life-cycle governance of blockchain network, according to some embodiments of the present disclosure.
[011] FIG.2 is an example block diagram illustrating modules of a system of FIG.1 for life-cycle governance of blockchain network, according to some embodiments of the present disclosure.
[012] FIG.3 is an exemplary flow diagram of a processor-implemented method for life-cycle governance of blockchain network, according to some embodiments of the present disclosure.
DETAILED DESCRIPTION OF EMBODIMENTS [013] Exemplary embodiments are described with reference to the accompanying drawings. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. Wherever convenient, the same reference numbers are used throughout the drawings to refer to the same or like parts. While examples and features of disclosed principles are described herein, modifications, adaptations, and other implementations are possible without departing from the scope of the disclosed embodiments. It is intended that the following detailed description be considered as exemplary only, with the true scope being indicated by the following claims.
[014] Blockchain technology is maturing the Gartner’s hype cycle as per one of the recent analysis report. Spending by various industry giants and financial technology organizations has grown enormously. Blockchain as a robust technology is entering into different industries irrespective of business segments such as banking, insurance, supply chain, logistics, travel, hospitality, manufacturing and so on. More and more organizations are started deploying the blockchain technologies in sandboxes to realize potential of the technology and experimenting on how it would help their businesses decisively. International data

corporation (IDC) has indicated that by 2021 at least 25% of the Global 2000 organizations may use the blockchain technology services.
[015] New blockchain platforms are emerging regularly. Also, the existing blockchain platforms are undergoing significant changes bringing in new capabilities. In such a dynamic environment, organizations will experience a need to be able to upgrade the blockchain implementation they have already invested in or in some cases move to entirely a new blockchain platform. In general, due to dynamic and fast evolving technology landscape, organizations will need to manage the entire life cycle of the blockchain implementation right through the inception, build, operate and evolve.
[016] The lifecycle of the blockchain implementation may be broadly visualized into 3 different phases including: implementation phase, maintenance phase and enhance phase. The implementation phase may include right choice of blockchain platform, auto deployment, user/participant creation, capacity creation, application onboarding, and so on. The maintenance phase may include user management, application management, data management, capacity management, performance management, security management, regulatory compliance management, and so on. The enhance phase may include change management, blockchain platform version upgrade, blockchain platform change (re-platforming), data migration/transformation, replacing existing use-case, and creating a new use-case, and so on. Hence, overall governance of the blockchain implementation include network management, user management, data management, security management, capacity management, performance management, regulatory compliance management, change management, and so on.
[017] Managing a blockchain network over a period of time is a challenging task, when multiple organizations or stakeholders are part of the blockchain network. All or most of the organizations or stakeholders have to provide their consensus before making any changes in the blockchain network to achieve consistency of the blockchain networks. In a consortium blockchain network having a plurality of nodes associated with a plurality of organizations, sometimes, one of the organization or the associated node has to act as master or a

superior node in order to provide privileges for making the changes across the network. But there may be ambiguity in deciding which organization or the node to act as a master or superior. All the nodes should be aware of the changes requested by all other nodes. Also, the organizations may use different platforms for implementing the blockchain network and hence there may a complexity in allowing the changes to happen across different blockchain platforms.
[018] So, maintaining a consistent blockchain network is an important aspect while making the changes and the functionalities such as adding or decommissioning a node, decommissioning the blockchain network, changing the blockchain network from one platform to another platform, sharding, forking, monitoring health of the blockchain network and so on. Managing such scenarios may be achieved by introducing a block chain manager to responsible for the changes to be made in entire lifecycle of the blockchain network.
[019] Conventional blockchain lifecycle management tools are limited to fewer functionalities and limited to a single blockchain platform. As the blockchain technology matures & organizations discover applicability, there is a need to re-look at the choice of blockchain platform. For example, Ethereum based Blockchain implementation needs to be migrated to R3 Corda based implementation. Each blockchain platform has unique architecture, implementation need, etc. There may be complex challenges with respect to users, data, applications, logs, etc, while migration of existing blockchain platform to new platform. Also migrating to the new platform has to be carried out without impacting the business use-case and integration needs to internal and external entities, and comply with applicable security and regulatory compliance. Currently there is no tool or mechanism for re-platforming the blockchain network.
[020] Performance and scalability of the blockchain network is a critical aspect and needs to be analyzed as the network grows. Blockchain network needs machine intelligence to dynamically allocate resources in real time to optimize the performance of the blockchain network. However, current tools or mechanisms are limited with the machine intelligence for optimizing the performance of the blockchain network. Inter-shard communication is practically challengeable for

blockchain network, irrespective of the blockchain platform in use. This may put constraints on scale-out and scale-in needs, at sporadic time-slots. Forking is another infrastructure requirement for the blockchain network. Changes in the code and design is an integral part of blockchain network. However, the present tools lack in tracing and avoiding redundant way of managing soft-forking or hard-forking.
[021] Transactions in the blockchain network goes through the consensus process, for any infrastructure changes or architectural changes. Threshold for consensus should be configurable beyond 51% of participants’ agreement. No such mechanism is available for the blockchain platform available in the market for the infrastructural changes. Decommission is an important and critical functionality for the blockchain network. Enterprise may need to decommission the blockchain network entirely at times. No realistic approach is available in market to help enterprise decommission the entire blockchain network in one go. Further, there is no tool available in the art for end-to-end lifecycle governance and management of the blockchain network.
[022] In accordance with an embodiment of the present disclosure, the methods and systems for life-cycle governance of blockchain networks provides a lifecycle governor which is responsible for ensuring consistency across the blockchain network while making the changes and implementing the functionalities, irrespective of the blockchain platform. The lifecycle governor ensures for management of the aspects specified in the 3 phases: the implementation phase, the maintenance phase and the enhance phase.
[023] Referring now to the drawings, and more particularly to FIG.1 through FIG.3, where similar reference characters denote corresponding features consistently throughout the figures, there are shown preferred embodiments and these embodiments are described in the context of the following exemplary systems and/or methods.
[024] FIG.1 is an exemplary functional block diagram of a system for life-cycle governance of blockchain network, according to some embodiments of the present disclosure. In an embodiment, the system 100 includes or is otherwise in

communication with one or more hardware processors 104, communication interface device(s) or input/output (I/O) interface(s) 106, and one or more data storage devices or memory 102 operatively coupled to the one or more hardware processors 104. The one or more hardware processors 104, the memory 102, and the I/O interface(s) 106 may be coupled to a system bus 108 or a similar mechanism.
[025] The I/O interface(s) 106 may include a variety of software and hardware interfaces, for example, a web interface, a graphical user interface, and the like. The I/O interface(s) 106 may include a variety of software and hardware interfaces, for example, interfaces for peripheral device(s), such as a keyboard, a mouse, an external memory, a plurality of sensor devices, a printer and the like. Further, the I/O interface(s) 106 may enable the system 100 to communicate with other devices, such as web servers and external databases.
[026] The I/O interface(s) 106 can facilitate multiple communications within a wide variety of networks and protocol types, including wired networks, for example, local area network (LAN), cable, etc., and wireless networks, such as Wireless LAN (WLAN), cellular, or satellite. For the purpose, the I/O interface(s) 106 may include one or more ports for connecting a number of computing systems with one another or to another server computer. Further, the I/O interface(s) 106 may include one or more ports for connecting a number of devices to one another or to another server.
[027] The one or more hardware processors 104 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the one or more hardware processors 104 are configured to fetch and execute computer-readable instructions stored in the memory 102.
[028] The memory 102 may include any computer-readable medium known in the art including, for example, volatile memory, such as static random access memory (SRAM) and dynamic random access memory (DRAM), and/or non-volatile memory, such as read only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes. In an

embodiment, the memory 102 includes a plurality of modules 102A and a repository 102B for storing data processed, received, and generated by one or more of the plurality of modules 102A. The plurality of modules 102A may include routines, programs, objects, components, data structures, and so on, which perform particular tasks or implement particular abstract data types.
[029] The plurality of modules 102A may include programs or computer-readable instructions or coded instructions that supplement applications or functions performed by the system 100. The plurality of modules 102A may also be used as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions. Further, the plurality of modules 102A can be used by hardware, by computer-readable instructions executed by the one or more hardware processors 104, or by a combination thereof. In an embodiment, the plurality of modules 102A can include various sub-modules (not shown in FIG.1).
[030] The repository 102B may include a database or a data engine. Further, the repository 102B amongst other things, may serve as a database for storing the data that is processed, received, or generated as a result of the execution of the plurality of modules 102A. Although the repository 102B is shown internal to the system 100, it will be noted that, in alternate embodiments, the repository 102B can also be implemented external to the system 100, where the repository 102B may be stored within an external database (not shown in FIG. 1) communicatively coupled to the system 100. The data contained within such external database may be periodically updated. For example, new data may be added into the external database and/or existing data may be modified and/or non-useful data may be deleted from the external database. In one example, the data may be stored in an external system, such as a Lightweight Directory Access Protocol (LDAP) directory and a Relational Database Management System (RDBMS). In another embodiment, the data stored in the repository 102B may be distributed between the system 100 and the external database.
[031] In an embodiment, the system 100 may be present inside the blockchain network. In another embodiment, the system 100 may be coupled to the

blockchain network through the I/O interface(s) 106 either with a physical connection or with a wireless connection. In an embodiment, the blockchain network may be a public blockchain network, a private blockchain network, a consortium including at least one public blockchain network, a consortium including at least one private blockchain network, or a consortium including at least one public blockchain network and at least one private blockchain network, or a combination thereof.
[032] The blockchain network may include at least one node. Each node or a plurality of nodes may belong to an organizations, stake holders, entities and alike. The public blockchain network may include at least one node belonging to public based organizations, stake holders, entities and alike. Similarly, the private blockchain network may include at least one node belongs to private organizations, stake holders, entities and alike. So, the ‘node’ or the ‘organization’ or ‘entity’ and so on may be used interchangeably depending on the context. The person skilled in the art may understand that the owner or authorized person of the organization or entity or stake holder may have access to their node (s) in the blockchain network for initiating the changes. In the context of the present disclosure, the terms such as a ‘user’, ‘administrator’ and a ‘participant’ are used interchangeably based on the context. The user is a person who uses the blockchain network. The administrator is the owner of the blockchain network or for one or more nodes present in the blockchain network. The participant may be a user, administrator, a node and a like who actually participant during the changes in the blockchain network. Also, the participant may initiate the changes in the blockchain network. The components and functionalities of the system 100 are described further in detail with reference to FIG.2 and FIG.3.
[033] Referring collectively to FIG.2 and FIG.3, components and functionalities of the system 100 are described in accordance with an example embodiment of the present disclosure. For example, FIG.2 is an example block diagram 200 illustrating modules of a system 100 for life-cycle governance of blockchain network, according to some embodiments of the present disclosure. As shown in FIG.2, the modules including a life cycle governor 202, shell scripts 206,

a set of tools 204, and an infrastructure service bench (ISB) database 208. In an embodiment, the life cycle governor 202 comprises sub-modules (not shown in FIG.2) including a governance manager 202A, re-platform manager 202B, a forking manager 202C, a sharding controller 202D, a network decommissioner 202E and a network health monitor 202F.
[034] In an embodiment, the life cycle governor 202 further comprises sub-modules (not shown in FIG.2) including but are not limited to change management orchestrator, node manager, consensus engine, scheduler, deployment manager, platform manager, rules engine, event controller, configuration manager, network controller, and authorization engine.
[035] The governance manager 202A monitors and governs the request for any change and delegates to the change management orchestrator for further processing. The change management orchestrator is responsible to manage the change management in the blockchain network. The change management orchestrator monitors and control all change requests from different process and delegates to the respective module for further processing. The node manager deploys and manages the nodes present in the blockchain network. The consensus engine is responsible for the consensus process and tracking. The consensus engine has ability to add and configure new consensus algorithm. The scheduler schedules and tracks all the change requests in the blockchain network.
[036] The re-platform manager 202B manages and controls the re-platform process. The deployment manager enables deployment in the node and contains customized deployment scripts to deploy changes in the node. The platform manager is responsible to validate, store and share platform related details. The rules engine manages and executes the rules that are being created or uploaded by the participant.
[037] The forking manager 202C is responsible for forking operations carried out in the blockchain network. The sharding controller 202D manages and controls sharding process in the entire blockchain network. The event controller controls and manages different events and incidents generated in the blockchain network. The configuration manager maintains participant customized templates,

standard templates and the changes made to the templates. The network controller monitors the entire blockchain network for any request coming from different sources and delegates to the respective module for fulfilment. The authorization engine is responsible to validate and authenticate the node details and credentials.
[038] In an embodiment, the modules and the sub-modules of FIG.2 may be stored in the plurality of modules 102A comprised in the memory 102 of the system 100. The infrastructure service bench (ISB) database 208 may be a part of the repository 102B comprised in the memory 102 of the system 100. FIG.3 is an exemplary flow diagram of a processor-implemented method 300 for life-cycle governance of blockchain network, according to some embodiments of the present disclosure.
[039] Although steps of the method 300 including process steps, method steps, techniques or the like may be described in a sequential order, such processes, methods, and techniques may be configured to work in alternate orders. In other words, any sequence or order of steps that may be described does not necessarily indicate a requirement that the steps be performed in that order. The steps of processes described herein may be performed in any order practical. Further, some steps may be performed simultaneously, or some steps may be performed alone independently.
[040] At step 302 of the method 300, the one or more hardware processors 104 of the system 100 are configured to receive a request for change from one or more nodes (user or administrator) comprised in the blockchain network. In an embodiment, the change is associated with at least one of request types comprising (i) adding a new node in the blockchain network (ii) adding a new functionality to the one or more nodes, (iii) adding a functionality enhancement to the one or more nodes, and (iv) a change in the blockchain network. In an embodiment, the change may be an immediate change or a change to be performed at a predefined schedule.
[041] At step 304 of the method 300, the one or more hardware processors 104 of the system 100 are configured to manage the change based on the request type and a consensus mechanism. In an embodiment, the governance manager 202A (FIG.2) of the lifecycle governor 202 (FIG.2) is configured via the one or

more hardware processors 104 of the system 100 to receive the request for the change and delegates to the change management orchestrator.
[042] The change management orchestrator is responsible for validating the change request and input details including node details such as the node that has initiated the change request has privileges to initiate the change or not, a time frame specified for consensus mechanism and so on. Also, the change management orchestrator invokes the consensus engine for requesting a vote from each of the plurality of nodes (termed as participants from hereon, other than the node that has initiated the change request) for initiating the change. The type of votes include a positive vote, negative vote. Also, the participants may delegate the vote to other participant or abstain. The consensus engine includes one or more consensus mechanisms. Upon receiving votes from the participants, the consensus engine then calculate a voting percentage for initiating the change. The consensus engine may have an ability to record the vote received from the participants for the associated change within the specified time frame, by using a consensus mechanism such as a proof of stake or may be configured with consensus plug-in to record the votes based on associated consensus mechanisms.
[043] In an embodiment, the change management orchestrator is connected to the plurality of nodes comprised in the blockchain network via the node manager to receive respective the votes within the specified time frame, for the associated change. The received voting details are stored in a change request recorder (not shown in FIG.2) for future reference. In an embodiment, the change may be initiated based on the request across the plurality of nodes, if the voting percentage is at least 51%. If the change is marked as immediate, then the change management orchestrator sends a request to a deployment manager (not shown in FIG.2) to deploy the change in the associated nodes of the plurality of nodes. Also, the change is stored in the change request recorder so that the change may be picked up by the scheduler based on a later time specified in the request. In an embodiment, the change request recorder may be present inside the infrastructure service bench (ISB) database 208 (FIG.2) which is communicative coupled to the governance manager 202A.

[044] In an embodiment, any change(s) across the nodes in the blockchain network is tracked before deployment. The change may be enabled (deployed) only for the corresponding nodes that have provided the associated vote during the voting process. If the change is related to a change in software code as part of functionality enhancement, then the software code of present version (before the change is deployed) and the software code of the latest version (after the change is deployed) are stored in the change request recorder along with an associated storage location. In an embodiment, the details related to the change may be traced till the origin with help of hash keys. In an embodiment, the change management orchestrator may be responsible for verifying and validating the software code as part of the change, before being deployed. In another embodiment, the associated node may verify and validate the software code as part of the change, before being deployed in the respective node. In an embodiment, the governance manager 202A is configured to obtain necessary scripts from the shell scripts 206 (FIG.2) and necessary tools from a set of tools 204 (FIG.2) for initiating and executing the change request.
[045] The participants verify the changes and provide their concurrence. If any specific information is required before performing the change, then a query may be sent to the node requested for the change for the further action. The governance manager 202A updates the status of the request for change during the process.
[046] At step 306 of the method 300, the one or more hardware processors 104 of the system 100 are configured to allow the nodes of the blockchain network to move from current blockchain platform to one of a blockchain platform present in a predefined list of blockchain platforms. In an embodiment, the predefined list of blockchain platforms include but not limited to the blockchain platforms available in the market such as Ethereum, Hyperledger Fabric, R3 Corda, Quorum, and Coco, and also the blockchain platforms that may come in future.
[047] In an embodiment, the re-platform manager 202B of the lifecycle governor 202, is configured via the one or more hardware processors 104 of the system 100 to receive a platform change request (from user or administrator) and

delegates to the change management orchestrator. The change management orchestrator is responsible for validating the platform change request and inputs including node details such as the node that has initiated the platform change request. Then, the change management orchestrator after validation, the change management orchestrator allow the node that has initiated the platform change request to select a desired platform from a set of platforms, and check whether the selected platform is compatible platform or not (support platform) and also meeting the regulatory compliance. The technical gaps are identified while checking the compatibility. The technical gaps are given criticality level as 1,2,3, the highest criticality being 1. More the number of high criticality gaps, more complex would be the re-platforming process. The regulatory compliance define regulatory requirements of the organization on the blockchain network. A set of regulatory requirements is available in the form of templates which may be used and also may be customized. Also, the data retention policy is also available in the form of templates which may be used and also may be customized.
[048] If the selected platform is a compatible platform and meeting the regulatory compliance, then the change management orchestrator stores a set of data related to the node that has initiated the platform change request. The set of data includes node details, user profiles, application profiles, data profiles, participant profiles, configuration files and a set of keys present in the node, and a file system of the node. Once the set of details are stored then the change management orchestrator removes unwanted files present in the associated node and frees up the storage space.
[049] After pre-requisite for the selected platform is completed, the change management orchestrator sends a request to the deployment manager to deploy the selected platform. In the process, the deployment manager extract a required installer and associated configuration files and deploy the selected platform by installing the required installer and the associated configuration files using a set of deployment scripts. The set of data related to the node that has stored before the platform change, is restored in the associated node. The re-platform manager 202B is responsible for performing roll back operation on the associated node to retain

the previous platform and previous configuration files, in case of any issue at any stage while deploying to the selected platform. If the deployment process to the selected platform is successful, then the change management orchestrator sends a success flag to the re-platform manager 202B. The re-platform manager 202B stores the current platform details of the associated node in the change request recorder for future reference.
[050] In an embodiment, the re-platforming process may be carried out at as a worst-case scenario, intermediate scenario or as best-case scenario. In worst-case scenario, existing implementation (current blockchain platform) may be kept as-is for future reference and also start with the new implementation (new blockchain platform after re-platforming) as a fresh. In the intermediate scenario, the existing implementation (current blockchain platform) may be kept as-is for future reference and establish interoperability with new implementation (new blockchain platform after re-platforming). In the best-case scenario, migrate everything from existing implementation (current blockchain platform) to the new implementation (new blockchain platform after re-platforming).
[051] The new blockchain platform may be implemented for near-term and long-term requirements. After migrating to the new blockchain platform, restoration of user profiles, the data along with time-stamps, transaction log along with the time-stamps and the applications along with the states may be carried out automatically. Also, testing (for example, smoke tests) of the new implementation is carried out after migration and the old implementation is de-coupled after successful migration and based on the test results.
[052] At step 308 of the method 300, the one or more hardware processors 104 of the system 100 are configured to allow the forking operation on the blockchain network. In an embodiment, a type of the forking operation includes forking the blockchain network and forking a contract. In an embodiment, forking the contract further includes a hard forking or a soft forking. In an embodiment, the forking manager 202C of the lifecycle governor 202 is configured via the one or more hardware processors 104 of the system 100 to receive a forking operation request and delegates to the change management orchestrator (not shown in FIG.2).

[053] The change management orchestrator is responsible for validating the forking operation request and inputs including the type of forking operation, a creator address, network type, a destination network on which the forking operation to be performed, a time frame specified for consensus mechanism and so on. Also, the change management orchestrator invokes a consensus engine for requesting a vote from each of the plurality of nodes comprised in the blockchain network, within a predefined timeline. Upon receiving votes from the plurality of votes, the consensus engine then calculate a positive voting percentage and a negative voting percentage for initiating the forking operation. The consensus engine may have an ability to record the vote received from the participants, by using the consensus algorithm.
[054] Also, a set of forking parameters are calculated by using the forking operation request. The set of forking parameters include (i) total lines of code, (ii) an estimated time taken for the one or more changes and (iii) frequency of change. A weighted forking percentage is calculated by assigning predefined weights to the positive voting percentage, the negative voting percentage and the set of forking parameters. In an embodiment, the predefined weights are assigned by the user or the administrator based on the forking operation request. The deployment of the forking operation on the blockchain network is carried out, if the calculated weighted forking percentage is greater than a predefined weighted forking percentage. For example, the predefined weighted forking percentage is 90%. A successful flag is sent by the change management orchestrator to the platform manager once the forking operation is successfully completed. The platform manager stores the forking operation related details for future use.
[055] While initiating the forking operation, the change management orchestrator checks for an associated record comprising the forking operation details. If a matching record is found in the change management orchestrator, then the change management orchestrator upon receiving a request from the forking manager 202C, invokes the deployment manager to deploy the forking operation. The deployment manager selects appropriate deployment scripts based on the input

details. In an embodiment, the deployment manager is connected with a third party tools and auto deployment scripts to deploy the changes in the blockchain network.
[056] In an embodiment, the forking process may be performed on the nodes that have participated in providing the votes based on the consensus mechanism. After performing the forking operation, a forked blockchain network is created with the nodes that have participated in providing the votes based on the consensus mechanism. The one or more nodes that have not participated in providing the votes based on the consensus mechanism to perform the forking operation, may continue to work on the old blockchain network (the blockchain network before the forking operation is performed).
[057] In an embodiments, a inter network bridge (not shown in FIG.2) may be created for establishing a communication between the nodes present in two different forked blockchain networks or establishing the communication between the nodes present in the forked blockchain networks and the old blockchain network (the blockchain network before the forking operation is performed). A node present in first forked network may initiate a transaction request with a node present in second forked network through the inter network bridge. The inter network bridge then sends the request to a rule engine (not shown in FIG.2) that is responsible for managing and executing the rules that are created or uploaded by the node that has initiated the transaction request. Based on a type of the transaction request, the rule engine then decides whether to invoke third party tools for processing the transaction request or to invoke the node manager to further processing the transaction request. The decision is made based on a set of rules comprised in the rule engine.
[058] In an embodiment, the rule engine has a capability of configuring new rules or new actions. The configuration of the new rules or the new actions may help for customizing the rules in the rule engine. Once the transaction request is processed by the node present in the second forked network, a result set may be created by the in the second forked network and sends the created result set to the node present in the first forked network through the inter network bridge.

[059] At step 310 of the method 300, the one or more hardware processors 104 of the system 100 are configured to allow a sharding operation on the blockchain network using a sharding algorithm. In an embodiment, the sharding controller 202D (FIG.2) of the lifecycle governor 202 is configured via the one or more hardware processors 104 of the system 100 to receive a sharding operation request via the node manager from the user or the administrator. The nodes may perform various transactions in the blockchain network. If a scenario of parallel transactions initiated by the plurality of nodes occurs, then a processors usage may breach a threshold limit as number of transaction increase. When such scenario to deal with processing the number of transactions, an alert may be recorded in the node. Based on the alerts received and type of transactions, the node manager then sends a request to the sharding controller 202D to scale up to provide a performance boost to the node to handle with number of such transactions.
[060] In an embodiment, the sharding controller 202D is configured with a machine intelligence to determine a type of sharding operation to be performed on the blockchain network based on one or more sharding parameters. The one or more sharding parameters include : (i) a type of transactions to be performed, (ii) a level of scaling is required, (iii) one or more resources of the blockchain network. A sharding algorithm that best suits the determined type of sharding operation, is selected from a set of sharding algorithms. The set of sharding algorithms include but are not limited to beanstalk sharding, quadratic sharding, etc. Also, the set of tools may be configured in the sharding controller 202D to perform and manage the sharding operations, using the selected sharding algorithm.
[061] In an embodiment, the sharding controller 202D is configured to obtain necessary scripts from the shell scripts 206 (FIG.2) and necessary tools from a set of tools 204 (FIG.2) for to manage the sharding operations. In an embodiment, the sharding controller 202D sends a request to the set of tools or the node manager to perform distributed actions. In an embodiment, the sharding operations may be performed based on sharding rules, a sharding algorithm and associated configuration files. The sharding rules and different versions of the sharding rules may be available to the plurality of the nodes across the blockchain network. In an

embodiment, the sharding operation may be auto-tuned by using machine intelligence, based on the sharding algorithm.
[062] At step 312 of the method 300, the one or more hardware processors 104 of the system 100 are configured to decommission the blockchain network, upon receiving a decommissioning request, based on an authorization criteria. In an embodiment, decommissioning of the blockchain network includes decommission of the one or more nodes or decommission of the entire in the blockchain network. In an embodiment, the network decommissioner 202E of the lifecycle governor 202 is configured via the one or more hardware processors 104 of the system 100 to receive the node decommission request. The authorization criteria of the one or more nodes to be decommissioned is validated by the network decommissioner 202E.
[063] In an embodiment, node decommission request may be performed by employing one of a manual decommission and an automatic decommission. In the automatic decommission, the network decommissioner 202E is responsible to perform automatic backup operation to take a backup of: (i) the data associated with the one or more nodes to be decommissioned, (ii) user profiles, and (iii) configuration files, after validation and before decommissioning the blockchain network. In the manual decommission, the user has to select the data files manually for the backup before decommissioning the blockchain network.
[064] The network decommissioner 202E is responsible for sending the node decommission request to the deployment manager. The deployment manager in turn invokes the node manager with required details to proceed with data and files backup process. The authorization engine is connected to the deployment manager to validate the authorization criteria and authenticate the node and node credentials. The deployment manager upon receiving the response from the node manager and the authorization engine, decides on third party engine invocation. That is if any node specific external storage is configured in such node, then the third party engine may be invoked by the deployment manager during the backup process. Once the data and files backup is done, the network decommissioner 202E marks the node which is selected to be decommissioned as an inactive node.

[065] At step 314 of the method 300, the one or more hardware processors 104 of the system 100 are configured to continuously monitor a health status of the blockchain network and automatically perform auto-healing. In an embodiment, the network health monitor 202F of the lifecycle governor 202 is configured via the one or more hardware processors 104 of the system 100 to monitor health of the blockchain network continuously and to perform auto healing by taking corrective action automatically to avoid disruptions at any stage of transaction flow in the blockchain network.
[066] The network health monitor 202E is configured to receive one or more system incidents or a one or more events raised by an event monitoring engine, from the node manager. In an embodiment, the one or incidents and the one or more events are associated with one or more resource requirements and one or more security breaches of the blockchain network. The one or more incidents or the one or more events may be raised during the changes to the one or more nodes or the blockchain network itself. The changes include re-platforming, sharding, forking, decommissioning, version upgrade, feature enhancement and so on.
[067] The node manager keeps continuous checks on blockchain network resources and the network health monitor 202E fetches the event details related to continuous checks periodically. Upon fetching, the network health monitor sends the event details to a rule engine. The rule engine look for matching records and retrieve associated actions to be executed. The network health monitor 202E may trigger the action request either to the node manager or to the set of tools 204. The network health monitor may provide recommendation to act on these actions based on the rules provided in the rule engine. The node manager or the set of tools may initiate the recommendations in the blockchain network. Results related to the recommendations are stored for future reference in the infrastructure service bench (ISB) database 208.
[068] In accordance with an embodiment of the present disclosure, the lifecycle governor 202 of FIG.2 is not confined to any specific platform as it is platform agnostic. Hence the lifecycle governor 202 of FIG.2 can be deployed across different blockchain platforms and blockchain technologies. So, if any

organization need to use a different platform in future, then the lifecycle governor 202 of FIG.2 allow the organization to move the associated node (blockchain network) from the present platform to a desired platform without any major changes. In an embodiment, the lifecycle governor 202 of FIG.2 allow the organization to choose the desired platform from a set of platforms that are available in the market. These set of platforms may be upgraded from time to time and new platforms can be part of the set of platforms as and when they are available in the market. The lifecycle governor 202 can deploy, manage and support heterogeneous blockchain networks and platforms.
[069] The lifecycle governor 202 allow the organization to enter the data into the associated node (s) for only one time during setup. The data is available either in extensible markup language (XML) format or in JavaScript Object Notation (JSON) format and may be exported in the mentioned formats across the nodes in the blockchain network. So, the lifecycle governor 202 ensures data integrity among all the nodes in the blockchain network. The lifecycle governor 202 is responsible for versioning of the metadata of each node so that the associated organization may know past and present values of the metadata.
[070] The present disclosure maintain the configurable templates and workflows in a common repository, which can be customized based on the requirement and use case scenarios. The present disclosure also allows the user to define and store new configurable templates and workflows. Also, the system 100 is capable enough to accept new configuration key–value pair during the creation of the configurable templates and the workflows.
[071] In accordance with an embodiment of the present disclosure, the system 100 can be deployed in any blockchain network with ease and no further installation is required to access the functionalities of the lifecycle governor 202. The system 100 can be deployed in variety of computing devices not limited to laptop, desktop computer, portable computers, and mobile phones. The shell scripts 206 allow the organization to deploy the agreed changes on the associated node (s). The changes are to be agreed after consensus is sought from majority of other nodes. The system 100 maintains common configuration files and deployable installers

which ensures the deployment process is complete and consistent across the nodes in the blockchain network. In case of any issues during the deployment process, the system 100 is configured to generate the alerts. Based on the generated alerts, rollback of the deployment process is possible to move the node back to the previous state.
[072] The network health monitor 202E ensures the self-diagnosis of the blockchain network. The network health monitor 202E is responsible for monitoring the blockchain network and to perform healing operations in case of any issues in the network. The issues includes processor threshold breach, insufficient memory, alerts due to inconsistent changes in some nodes and so on. The rules engine keeps monitoring the incidents and the events in the blockchain network, and generate actions, alerts for the user or the administrator to act on it. The system 100 is capable of adding new mapping rules based on events and alerts.
[073] As part of the change management, the lifecycle governor 202 has the ability to record audit trail of each action performed in the blockchain network. Security and Regulatory compliance would certainly benefit from such audit-trail of the blockchain networks. The system 100 provides well established templates for managing the blockchain network archival. It incorporates the industry vertical dimension and use case dimension, which may help in in Regulatory compliance as well. The lifecycle governor 202 provides pragmatic approach to ensure inter-operability across versions (n and n-1) as well as across different blockchain platforms, which supports homogenous and heterogenous environments with equal effectiveness.
[074] The present disclosure provides the framework for end-to-end lifecycle management of the blockchain network, which include change management, re-platforming of the blockchain network, auto scaling of the nodes, decommissioning of entire blockchain network, automatic forking and sharding operations management with machine intelligence, self-diagnosis of the blockchain network and so on. Hence the end-to-end lifecycle management of the blockchain network is simple, robust, multi-functional and effective.

[075] The written description describes the subject matter herein to enable any person skilled in the art to make and use the embodiments. The scope of the subject matter embodiments is defined herein and may include other modifications that occur to those skilled in the art. Such other modifications are intended to be within the scope of the present disclosure if they have similar elements that do not differ from the literal language of the embodiments or if they include equivalent elements with insubstantial differences from the literal language of the embodiments described herein.
[076] In accordance with an embodiments of the present disclosure, the system 100 enable multiple functionalities including governing the changes, auto deployment of major and minor changes across the network, automatic forking and shading operations, adding the new node and automatic decommissioning of the existing node and network health management via the lifecycle governor 202 irrespective of the block chain platform. Moreover, the lifecycle governor 202 allows the node to move from one blockchain platform network to another blockchain platform network with ease and without drastic changes. In addition, inter shard communication may be achieved through the inter network bridge.
[077] It is to be understood that the scope of the protection is extended to such a program and in addition to a computer-readable means having a message therein; such computer-readable storage means contain program-code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof. The device may also include means which could be e.g. hardware means like e.g. an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software processing components located therein. Thus, the means can include both hardware means and software means. The method embodiments described herein could be implemented in hardware and software. The device may also include software

means. Alternatively, the embodiments may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[078] The embodiments herein can comprise hardware and software elements. The embodiments that are implemented in software include but are not limited to, firmware, resident software, microcode, etc. The functions performed by various components described herein may be implemented in other components or combinations of other components. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can comprise, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
[079] The illustrated steps are set out to explain the exemplary embodiments shown, and it should be anticipated that ongoing technological development will change the manner in which particular functions are performed. These examples are presented herein for purposes of illustration, and not limitation. Further, the boundaries of the functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternative boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. Alternatives (including equivalents, extensions, variations, deviations, etc., of those described herein) will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein. Such alternatives fall within the scope of the disclosed embodiments. Also, the words “comprising,” “having,” “containing,” and “including,” and other similar forms are intended to be equivalent in meaning and be open ended in that an item or items following any one of these words is not meant to be an exhaustive listing of such item or items, or meant to be limited to only the listed item or items. It must also be noted that as used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context clearly dictates otherwise.
[080] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present disclosure. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-

readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., be non-transitory. Examples include random access memory (RAM), read-only memory (ROM), volatile memory, nonvolatile memory, hard drives, CD ROMs, DVDs, flash drives, disks, and any other known physical storage media.
[081] It is intended that the disclosure and examples be considered as exemplary only, with a true scope of disclosed embodiments being indicated by the following claims.

We Claim:
1. A processor-implemented method (300) for lifecycle governance of a
blockchain network having one or more nodes, the method (300) comprises performing one or more of:
receiving, via one or more hardware processors, a request for change from the one or more nodes, wherein the change is associated with at least one of request types comprising (i) adding a new node in the blockchain network (ii) adding a new functionality to the one or more nodes, (iii) adding a functionality enhancement to the one or more nodes, and (iv) a change in the blockchain network (302);
managing, via the one or more hardware processors, the change based on the request type and a consensus mechanism (304);
allowing, via the one or more hardware processors, the nodes of the blockchain network to move from a current blockchain platform to one of a blockchain platform present in a predefined list of blockchain platforms (306);
allowing, via the one or more hardware processors, a forking operation on the blockchain network based on the consensus mechanism, wherein the forking operation is one among a predefined forking operation types comprising (i) forking on the blockchain network and (ii) forking on contract, the forking on contract comprises a hard forking and a soft forking (308);
allowing, via the one or more hardware processors, a sharding operation on the blockchain network using a sharding algorithm(310);
decommissioning, via the one or more hardware processors, the blockchain network, upon receiving a decommissioning request, based on an authorization criteria (312); and
continuously monitoring, via the one or more hardware processors, a health status of the blockchain network and automatically performing auto-healing (314).

2. The method as claimed in claim 1, wherein managing the change based on
the request type and the consensus mechanism, further comprises:
initiating a change to receive a consensus from the one or more nodes participating in the change, within a predefined timeline, after validating the request;
calculating a voting percentage based on the consensus received from the one or more nodes participating in the change; and
performing the change to the one or more nodes participating in the change, based on the voting percentage.
3. The method as claimed in claim 1, wherein the change is one among: (i) an immediate change and (ii) a change with a predefined schedule.
4. The method as claimed in claim 1, wherein allowing the nodes of the blockchain network to move from the current blockchain platform to one of the blockchain platform present in the predefined list of blockchain platforms, further comprises:
validating one or more credentials associated with the nodes requested to move from the current blockchain platform;
allowing the nodes of the blockchain network to move from the current blockchain platform to select a desired blockchain platform present in the predefined list of blockchain platforms;
validating a compatibility and a regulatory compliance of the desired blockchain platform with the current blockchain platform;
deploying the desired blockchain platform in the nodes of the blockchain network based on validation and after transferring a set of data associated the one or more nodes that are moving to the desired blockchain platform, wherein the set of data comprises one or more of: node details, user profiles, application profiles, data profiles, participant profiles, configuration files and a set of keys present in the node, and a file system of the node; and

restoring the set of data in one or more destination nodes, after deploying the desired blockchain platform, wherein the one or more destination nodes are the one or more nodes present in the deployed blockchain network.
5. The method as claimed in claim 1, wherein allowing the forking operation
on the blockchain network based on the consensus mechanism, further
comprises:
allowing to select the forking operation from the predefined forking operation types;
validating one or more characteristics comprising a creator address, a creator network type, a destination network type and a destination address;
initiating a forking request to receive a consensus from the one or more nodes associated with the forking operation, within a predefined timeline, after validating the one or more characteristics;
calculating a positive voting percentage and a negative voting percentage, based on the consensus received from the one or more nodes participating in the forking operation;
calculating a set of forking parameters comprising (i) total lines of code, (ii) an estimated time taken for the one or more changes, and (iii) frequency of change; and
deploying the forking operation on the blockchain network based on a weighted forking percentage, wherein the weighted forking percentage is calculated based on the set of forking parameters, the positive voting percentage and the negative voting percentage.
6. The method as claimed in claim 1, wherein the allowing a sharding
operation on the blockchain network using a sharding algorithm, further
comprises:
determining a type of sharding operation to be performed on the blockchain network based on one or more sharding parameters, wherein the

one or more sharding parameters comprises : (i) a type of transactions to be performed,(ii) a required level of scaling, (iii) one or more resources of the blockchain network;
selecting the sharding algorithm from a set of sharding algorithms, based on the type of sharding operation; and
allowing the sharding operation on the blockchain network based on a set of sharding rules present in the selected sharding algorithm.
7. The method as claimed in claim 1, wherein decommissioning the
blockchain network, upon receiving a decommissioning request, based on
an authorization criteria, further comprises:
allowing to select a decommissioning operation type, from a list of decommissioning operation types comprising (i) an automatic decommissioning operation and (ii) a manual decommissioning;
validating the authorization criteria of the one or more nodes to be decommissioned;
backing up a set of decommission data present in the one or more nodes to be decommissioned, wherein the set of decommission data comprises: (i) the data associated with the one or more nodes to be decommissioned, (ii) user profiles, and (iii) configuration files, based on the validation; and
decommissioning the blockchain network, after backing up the set of decommission data.
8. The method as claimed in claim 1, wherein continuously monitoring the
health status of the blockchain network, further comprises auto-healing of
one or incidents and one or more events raised in the blockchain network,
the one or incidents and the one or more events are associated with one or
more resources and one or more security breaches of the blockchain
network.

9. A system (100) for lifecycle governance of a blockchain network having one or more nodes, the system (100) comprising: a memory (102) storing instructions;
one or more Input/Output (I/O) interfaces (106); and
one or more hardware processors (104) coupled to the memory (102) via the one or more I/O interfaces (106), wherein the one or more hardware processors (104) are configured by the instructions to perform one of more of:
receive a request for change from the one or more nodes, wherein the change is associated with at least one of request types comprising (i) adding a new node in the blockchain network (ii) adding a new functionality to the one or more nodes, (iii) adding a functionality enhancement to the one or more nodes, and (iv) a change in the blockchain network;
manage the change based on the request type and a consensus mechanism;
allow the nodes of the blockchain network to move from a current blockchain platform to one of a blockchain platform present in a predefined list of blockchain platforms;
allow a forking operation on the blockchain network based on the consensus mechanism, wherein the forking operation is one among a predefined forking operation types comprising (i) forking on the blockchain network and (ii) forking on contract, the forking on contract comprises a hard forking and a soft forking;
allow a sharding operation on the blockchain network using a sharding algorithm;
decommission the blockchain network, upon receiving a decommissioning request, based on an authorization criteria; and
continuously monitor a health status of the blockchain network and automatically performing auto-healing.

10. The system as claimed in claim 9, wherein the one or more hardware
processors (104) are further configured to manage the change based on the
request type and the consensus mechanism, by:
initiating a change to receive a consensus from the one or more nodes participating in the change, within a predefined timeline, after validating the request;
calculating a voting percentage based on the consensus received from the one or more nodes participating in the change; and
performing the change to the one or more nodes participating in the change, based on the voting percentage.
11. The system as claimed in claim 9, wherein the change is one among: (i) an immediate change and (ii) a change with a predefined schedule.
12. The system as claimed in claim 9, wherein the one or more hardware processors (104) are further configured to allow the nodes of the blockchain network to move from the current blockchain platform to one of the blockchain platform present in the predefined list of blockchain platforms, by:
validating one or more credentials associated with the nodes requested to move from the current blockchain platform;
allowing the nodes of the blockchain network to move from the current blockchain platform to select a desired blockchain platform present in the predefined list of blockchain platforms;
validating a compatibility and a regulatory compliance of the desired blockchain platform with the current blockchain platform;
deploying the desired blockchain platform in the nodes of the blockchain network based on validation and after transferring a set of data associated the one or more nodes that are moving to the desired blockchain platform, wherein the set of data comprises one or more of: node details, user profiles, application profiles, data profiles, participant profiles,

configuration files and a set of keys present in the node, and a file system of the node; and
restoring the set of data in one or more destination nodes, after deploying the desired blockchain platform, wherein the one or more destination nodes are the one or more nodes present in the deployed blockchain network.
13. The system as claimed in claim 9, wherein the one or more hardware
processors (104) are further configured to allow the forking operation on
the blockchain network based on the consensus mechanism, by:
allowing to select the forking operation from the predefined forking operation types;
validating one or more characteristics comprising a creator address, a creator network type, a destination network type and a destination address;
initiating a forking request to receive a consensus from the one or more nodes associated with the forking operation, within a predefined timeline, after validating the one or more characteristics;
calculating a positive voting percentage and a negative voting percentage, based on the consensus received from the one or more nodes participating in the forking operation;
calculating a set of forking parameters comprising (i) total lines of code, (ii) an estimated time taken for the one or more changes, and (iii) frequency of change; and
deploying the forking operation on the blockchain network based on a weighted forking percentage, wherein the weighted forking percentage is calculated based on the set of forking parameters, the positive voting percentage and the negative voting percentage.
14. The system as claimed in claim 9, wherein the one or more hardware
processors (104) are further configured to allow a sharding operation on the
blockchain network using a sharding algorithm, by:

determining a type of sharding operation to be performed on the blockchain network based on one or more sharding parameters, wherein the one or more sharding parameters comprises : (i) a type of transactions to be performed,(ii) a required level of scaling, (iii) one or more resources of the blockchain network;
selecting the sharding algorithm from a set of sharding algorithms, based on the type of sharding operation; and
allowing the sharding operation on the blockchain network based on a set of sharding rules present in the selected sharding algorithm.
15. The system as claimed in claim 9, wherein the one or more hardware
processors (104) are further configured to decommission the blockchain
network, upon receiving a decommissioning request, based on an
authorization criteria, by:
allowing to select a decommissioning operation type, from a list of decommissioning operation types comprising (i) an automatic decommissioning operation and (ii) a manual decommissioning;
validating the authorization criteria of the one or more nodes to be decommissioned;
backing up a set of decommission data present in the one or more nodes to be decommissioned, wherein the set of decommission data comprises: (i) the data associated with the one or more nodes to be decommissioned, (ii) user profiles, and (iii) configuration files, based on the validation; and
decommissioning the blockchain network, after backing up the set of decommission data.
16. The system as claimed in claim 9, wherein the one or more hardware
processors (104) are further configured to continuously monitor the health
status of the blockchain network, by auto-healing of one or incidents and
one or more events raised in the blockchain network, the one or incidents

and the one or more events are associated with one or more resources and one or more security breaches of the blockchain network.