Distributed ledger technology network provisioner

A system for intelligently provisioning a distributed ledger technology (DLT) network may be configured to receive requests from authorized users to provision a DLT network based on a plurality of preset parameters. The system may further be configured to generate a script, using machine learning or other artificial intelligence algorithms, for provisioning the DLT network according to the preset parameters. One or more nodes in the DLT network can then execute the intelligently generated script to provision the DLT network as requested.

FIELD OF THE INVENTION

The present disclosure embraces a system, computer program product, and computer-implemented method for provisioning a distributed ledger technology (DLT) network on one or more designated nodes.

BACKGROUND

Within an enterprise, authorized users of the enterprise's systems frequently require use of customized DLT network in order to test, deploy, or otherwise implement various applications on individual nodes or across the given DLT network. At present, authorized users have to request certain resources in order to provision the DLT network required to test, deploy or implement the applications. Indeed, depending on the particular requirements for the DLT network, it may take several weeks in order to provision a DLT network according to the user's specifications. Therefore, a need exists for a system that can intelligently provision a DLT network according to the requirements provided by an authorized user. The present invention is directed at accomplishing this aim.

BRIEF SUMMARY

Embodiments of the present invention relate to systems, computer program products, and methods for provisioning distributed ledger technology (DLT) networks. Embodiments of the present invention comprise one or more processor components, one or more memory components operatively coupled to the one or more processor components, and computer-readable instructions stored on the one or more memory components configured to cause the one or more processor components to receive a request from an authorized user to provision a DLT network, identify, based on the request received from an authorized user, a set of parameters required to provision the DLT network; generate a script to provision the DLT network, wherein the script comprises a series of executable instructions based on the identified set of parameters instructing one or more nodes to provision a DLT network, transmit, to one or more nodes, the generated script to provision the DLT network, and executing the generated script to provision the DLT network.

In additional or alternative embodiments of the invention as described herein, the parameters comprise at least one of a number of nodes in the provisioned DLT network, a network infrastructure, a ledger type, a programming language, or a database.

In additional or alternative embodiments of the invention as described herein, generating as script to provision the DLT network further comprises sequencing the series of executable instructions.

In embodiments where the executable instructions are sequenced as described above, transmitting the generated script to provision the DLT network may comprise receiving an indication from a node when an executable instruction has been completed by the node and transmitting the next executable instruction in the sequenced series of executable instructions.

In additional or alternative embodiments, transmitting the generated script to one or more nodes may comprise communicating over a network with a network provisioning adapter located at the one or more nodes.

In additional or alternative embodiments of the invention, identifying a set of parameters required to provision the DLT network may further comprise receiving, via the request from the authorized user, a partial set of parameters for the DLT network, comparing the partial set of parameters to the parameters of existing DLT networks, wherein the parameters of existing DLT networks are stored in a database/configuration communicatively coupled to the system, and determining one or more missing parameters based on the comparison of the partial set of parameters to the parameters of existing DLT networks.

In additional or alternative embodiments, the system may further store the identified set of parameters in a database/configuration communicatively coupled to the system.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

“Entity” as used herein may refer to an individual or an organization that owns and/or operates an online system of networked computing devices, systems, and/or peripheral devices on which the extended recognition system described herein is implemented. The entity may be a business organization, a non-profit organization, a government organization, and the like.

“Entity system” as used herein may refer to the computing systems and/or other resources used by the entity to execute DLT and non-DLT functions.

“User” as used herein may refer to an individual who may interact with the entity system. Accordingly, the user may be an employee, associate, contractor, or other authorized party who may access, use, administrate, maintain, and/or manage the computing systems within the entity system.

“Computing system” or “computing device” as used herein may refer to a networked computing device within the entity system. The computing system may include a processor, a non-transitory storage medium, a communications device, and a display. The computing system may support user logins and inputs from any combination of similar or disparate devices. Accordingly, the computing system may be a portable electronic device such as a smartphone, tablet, single board computer, smart device, or laptop, or the computing system may be a stationary unit such as a personal desktop computer or networked terminal within an entity's premises. In some embodiments, the computing system may be a local or remote server which is configured to send and/or receive inputs from other computing systems on the network.

“Distributed ledger” or “distributed electronic ledger” as used herein may refer to a structured list of data records that is decentralized and distributed amongst a plurality of computing systems and devices. In some embodiments, the distributed ledger may be a blockchain ledger. “Node” as used herein may refer to a computing system on which the distributed ledger is hosted. Typically, each node maintains a full copy of the distributed ledger.

“Distributed ledger technology network” or “DLT network” as used herein may refer to a network of servers, computer systems or other computing devices configured to perform at least some DLT-functions.

“Consensus,” “consensus algorithm,” or “consensus mechanism” as used herein may refer to the process or processes by which nodes come to an agreement with respect to the contents of the distributed ledger. Typically, changes to the ledger (e.g., addition of data records) may require consensus to be reached by the nodes in order to become a part of the authentic version of the ledger. The nodes may use various different mechanisms or algorithms to obtain consensus, such as proof-of-work (“PoW”), proof-of-stake (“PoS”), practical byzantine fault tolerance (“PBFT”), or the like.

“Resource” as used herein may refer an object which is typically transferred between the third party and the entity. The object may be tangible or intangible objects such as computing resources, data files, documents, funds, and the like.

Embodiments of the present disclosure provide a system, computer program product, and method for intelligently provisioning a DLT network based upon a set of parameters provided by an authorized user. In particular, the system may be configured to provide a DLT network on the private/public cloud infrastructure (e.g., Docker, Kubernetes, Openshift, etc.). In certain instances, an authorized user may request a particular DLT network with certain parameters, including the number of DLT nodes, the network infrastructure, ledger type, programming language, and database. Upon receipt of these parameters from an authorized user, the intelligent DLT provisioning system has all of the information necessary in order to provision a DLT network according to the authorized user's requirements.

In general, the DLT networks as described herein are comprised of a number of nodes connected of a network. The nodes may be a server or other computing device that is capable of performing DLT functions, including communication with other nodes on the DLT network, executing consensus algorithms to determine contents of a distributed ledger (e.g., validating data records and/or approving or rejecting additional data records), forming smart contracts, or the like. In a DLT network, some nodes may be permissioned, while other nodes are not—in other words, only a subset of all of the nodes in a DLT network may be able to participate in the performing the consensus algorithm or other DLT-functions affecting the distributed ledger. In DLT networks as described herein, the nodes may exist on a variety of commercially available private/public cloud infrastructures, including Docker, Kubernets, Openshift, and the like. The various infrastructures may be established to serve different uses, depending on the needs of the authorized user. Further, a user may require different ledger types to establish the distributed ledger on the DLT network. For example, different use case may be well suited for Corda, while other use cases may require Hyperledger Fabric, Ethereum, or some other commercially available distributed ledger. Lastly, the DLT networks provisioned according to embodiments of the present invention may use specific programming languages to perform the DLT-functions (e.g., node.js) and require access to specific relational or memory databases.

FIG. 1is a system diagram of the intelligent DLT network provisioning system. As shown inFIG. 1, the system comprises an intelligent DLT network provisioning engine110, an enterprise source control application set120, and one or more provisioned DLT networks130. As further shown inFIG. 1, the intelligent DLT network provisioning engine110is comprised of several sub-components, namely a script generator112, an application programming interface (API) layer113, a DLT identifier/handler114, an interface handler115, a status collator116, and a command sequencer117. Collectively, these components handle all of the tasks necessary to receive an authorized user's requirements and provision one or more DLT networks according to such requirements. A more detailed description of each component of the intelligent DLT network provisioning engine110is set forth below.

The script generator112enables the intelligent DLT network provisioning engine110to generate DLT and operating system specific instruction which are orchestrated to create a DLT node and/or network. The script generator112leverages industry-standard markup languages (e.g., raml, swagger, yaml, and the like) in order to communicate with the respective operating system and related technology.

The application programming interface (API) layer113is responsible for communicating with the enterprise DLT network provisioning adapters (EDPAs) which are described in more detail below. The API layer also allows the intelligent DLT network provisioning engine110to communicate with a web interface or other interfacing platform for receiving the authorized user's requirements to establish and provision the DLT network.

The DLT identifier/handler114is a software component of the intelligent DLT network provisioning engine110that is used to maintain the information related to the respective provisioned DLT networks130. For example, the DLT identifier/handler may store information such as the tech stack (i.e., the combination of programming languages, tools and frameworks) for the applicable DLT network and the dependency information for the same. The DLT identifier/handler114is configured to maintain both front-end and back-end information for the respective DLT networks. Further, the DLT identifier/handler includes functionality to identify information (e.g., tech stack and dependency information) for a provisioned DLT network, whether or not such information was already stored in the DLT identifier/handler114. Indeed, the DLT identifier/handler may leverage machine learning (e.g., neural networks and the like) algorithms to identify DLT network information for a given DLT network based upon the stored information on DLT networks already on the DLT identifier/handler114.

The interface handler115is an additional software component of intelligent DLT network provisioning engine110that is responsible for giving the provisioning mechanism a means for interacting with required interfaces. For example, the provisioning mechanism may need to interact with one or more code repositories, operating system calls, external APIs, external libraries, and the like. The interface handler115provides the means for the intelligent DLT network provisioning engine110to interact with the foregoing.

The status collator116is responsible for enabling the servicing of multiple types of requests and orchestrating such requests based on order of precedence. The status collator116must understand the requirements for setting up the requested DLT network according to the authorized user's parameters in order to orchestrate the DLT setup. Further, the status collator116must be able to determine the current status of the network provisioning and respond to additional requests in order to determine the next steps in the provisioning process.

Lastly, the intelligent DLT network provisioning engine110comprises a command sequencer117. The command sequencer117provides a dynamic sequencing mechanism of commands to be executed on the respective nodes in order to provision the DLT network according to the authorized user's requirements. Specifically, the command sequencer117interfaces directly with the Enterprise DLT Network Provisioning Adapter (EDPA) on a particular network or node in order to arrange for the specific commands to be executed on that network or node.

The EDPAs1310,1320, and1330work in connection with the command sequencer117, but as opposed to existing on the intelligent DLT network provisioning engine110, are installed in the private/public cloud servers that receive the commands from the DLT network provisioning engine in accordance with the processes described herein. Along with the provisioning components from the Enterprise source Control Toolset described in more detail below, the EDPA executes the commands received from the intelligent DLT network provisioning engine110(and specifically, the command sequencer117). In addition, the EDPAs are responsible for relaying status updates for execution of the commands back to the intelligent DLT network provisioning engine110, allowing the status collator116and the command sequencer117to determine and issue the next set of commands in the provisioning process, respectively.

In some embodiments, the system may further comprise a configuration interface. The configuration interface may be hosted on the local computing device of an authorized user and permit the authorized user to request the provisioning services of the intelligent DLT network provisioning engine110and input requirements for the same.

As also shown inFIG. 1, the intelligent DLT network provisioning engine110is in operative communication with the enterprise source control application set120. The enterprise source control application set may comprise a suite of applications necessary for use by the various components of the intelligent DLT network provisioning engine110in order to successfully provision the DLT network according to the authorized user's requirements. For example, the enterprise source control application set may include Bitbucket, Artifactory, SCCM, and the like. The application suites comprising the enterprise source control application set120may be stored remotely and be accessible to computing systems across the entire enterprise, or may be available locally to the intelligent DLT network provisioning engine110.

Also shown inFIG. 1are provisioned DLT networks S1, S2, and S3. As shown inFIG. 1, the intelligent DLT network provisioning engine110is capable of provisioning DLT network S1, S2, and S3according to the authorized user's requirements. Each DLT network S1, S2as shown inFIG. 1has four nodes (N1, N2, N3, and N4for DLT network S1; A1A2, A3and A4for S2). Alternatively, the DLT networks may be comprised of multiple DLT networks, as shown with DLT networks S3, S4, S5, and S6, which respectively comprise nodes A, B, C, and D. Each DLT Network also has an EDPA, as described above.

FIG. 2depicts a more detailed system diagram of a fully provisioned DLT network200according to embodiments of the invention as described herein. As shown inFIG. 2, the DLT network200is comprised of one or more nodes (specifically, the DLT network200inFIG. 2has 4 nodes, but it is understood that the DLT networks provisioned according to embodiments described herein may have any number of nodes). Each node in the DLT network200is in operative communication with the other nodes in the DLT network200, in order to facilitate necessary DLT functionality. The DLT network200may be a global area network (GAN) such as the Internet, a wide area network (WAN), a local area network (LAN) or any other type of network or combination of networks in accordance with the requirements provided by the authorized user. The network may provide for wireline, wireless or a combination of wireline and wireless communication between devices on the network.

As shown, the DLT network200ofFIG. 2is comprised of a first DLT node201, a second DLT node202, a third DLT node203, and a fourth DLT node204. Each node also has a copy of a distributed ledger250, which should be the same on each node. In order to conduct transactions on the DLT network200, each node needs to append its copy of the distributed ledger250with the same information as the other nodes on the DLT network200. Embodiments of the present invention as described herein can configured the DLT network200(and the corresponding nodes comprising the DLT network200) to perform these functions in any manner, including by consensus algorithm, smart contract logic, or the like.

It should be understood by those having ordinary skill in the art that although the first DLT node201, second DLT node202, third DLT node203, and fourth DLT node204are depicted as single units, each of the depicted components, or sub-components therein, may represent multiple units. In some embodiments, a given computing system as depicted inFIG. 2may represent multiple systems configured to operate in a distributed fashion. For instance, the first DLT node201may represent a plurality of computing system operating in a distributed fashion. In other embodiments, the functions of multiple computing systems may be accomplished by a single system. For instance, the functions of the second DLT node202may, in some embodiments, be executed on a single computing system according to the authorized user's need to efficiently distribute computing workloads.

FIG. 3is a process flow depicting a typical process by which embodiments of the present invention may operate. In that regard, the process flow depicted inFIG. 3is conducted by elements of the system as described in more detail with respect toFIGS. 1 and 2above in order to intelligently provision a DLT Network.

As shown inFIG. 3, a typical process begins at block301, where an authorized user submits a request to provision a DLT network. In some embodiments, an entity may limit the number of authorized users who may use the entity's resources to provision DLT networks and prohibit users without such authorization from provisioning DLT networks on the system as described herein.

In addition, an authorized user may access a request portal or other means of submitting a request to provision a DLT network through a configuration interface, as described above. The configuration interface may allow the authorized user to submit requests to the DLT network provisioning system from a graphical user interface hosted on the authorized user's computer that is in operative communication with the intelligent DLT network provisioning engine110. In other embodiments, users may simply submit requests to provision DLT network through a command line type interface or the like.

Typically, an authorized user's request to provision a DLT network will specify one or more parameters that the user requires for the provisioned DLT network. The one or more parameters may include a number of nodes to be included in the DLT network (including if there will be any permissioned or non-permissioned nodes), a network infrastructure, a ledger type, a programming language, and/or a database. In some embodiments, the authorized user may be able to select the one or more parameters from a drop down menu in the configuration interface. In still other embodiments, and as described in more detail below, the user may provide only portion of the parameters required to provision the DLT network, allowing the system to determine the remaining parameters as necessary.

At block302, the system will identify a set of parameters required to provision the DLT network requested by the authorized user. If the user has input all of the requested parameters, identifying the requested parameters may be as simple as parsing the user's request to identify the requested parameters—e.g., the number of nodes, ledger type, and the like. However, in some instances, an authorized user may not enter a request that the system immediately recognizes, in which case the DLT Identifier/Handler114may have to perform additional tasks to identify the parameters of the requested DLT network.

As noted above, the DLT identifier/handler114is a software component that maintains information relating to provisioned DLT networks. For example, the DLT identifier/handler may store information such as the tech stack (i.e., the combination of programming languages, tools and frameworks) for the applicable DLT network and the dependency information for the same. Thus, if the DLT identifier/handler is able to identify the authorized user's request without any further work, the other elements of the intelligent DLT network provisioning engine110described herein can begin the tasks associated with provisioning the requested DLT network.

In some instances, however, the DLT identifier/handler114may not be able to immediately identify the parameters associated with the authorized user's request, and additional steps must be performed before the DLT network can be provisioned. Such additional steps may be required if, for example, the authorized user's request contains an incomplete set of parameters, or if the authorized user requests a combination of parameters that are incompatible with one another, or if for any other reason the DLT identifier/handler is unable to recognize one or more of the requested parameters. In such an instance, the DLT identifier/handler steps will proceed to block302a.

As depicted at block302a, the system (typically via the DLT identifier/handler114) compares the set of parameters requested from the authorized user to the sets of parameters for DLT networks the system has previously provisioned or otherwise has parameter level information on. As noted above, the DLT identifier/handler stores and has access to the parameters used in existing or previously provisioned DLT networks. In many cases, the stored parameter data is stored by the system itself when it provisions a DLT network, though it should be understood that certain parameter data for some DLT networks may be input to the DLT identifier/handler114by another source, such as by manual entry. Further, the DLT identifier/handler may store such information in a separate server communicatively coupled to the DLT identifier/handler114and accessible over a public or private network.

To perform the comparison as depicted in block302a, the DLT identifier/handler114may use any commonly available comparison algorithm to compare the requested parameters and known parameters. At block302b, the DLT identifier/handler determines any missing parameters in the requested set of parameters based on the results of the comparison performed at block302a. For example, the authorized user may a DLT network with only two parameters (e.g., the number of nodes and the infrastructure type). The DLT identifier/handler114may then compare the requested parameters with other DLT networks that had the same two parameters, and determine that most such DLT networks were requested with a specific ledger type. The DLT identifier/handler114may then use this comparison result to determine that the requested parameters should include the specific ledger type.

As the DLT provisioner system is used more often, the system may employ machine learning algorithms at the DLT identifier/handler to better predict missing and/or incorrect parameters. After the DLT identifier/handler114has been adequately “trained” according to the machine learning algorithm, the system will then accurately be able to provision DLT networks based on fewer parameters/information, thereby improving the accuracy of the system and reducing the amount of time required to provision new DLT networks according to the processes described herein.

At block302c, the system then adds the missing parameters identified at block302bto the request received at block301. In effect, the requested parameters are now include any of the missing parameters identified through the comparison process described above, and the provision of the DLT network according to embodiments of the invention as described herein can proceed.

Once all of the parameters have been accurately determined (either at block302or by the comparison process described at blocks302athrough302c), the system next generates a script to provision the DLT network as depicted at block303. Typically this step is performed by the script generator112described above. As discussed, the script generator112is responsible for generating DLT and operating system specific instructions which are orchestrated by the components of the DLT provisioning system to provision the requested DLT network. In particular, the script generator uses industry-standard markup language (e.g., raml, swagger, yaml and the like) in order to generate instructions for provisioning a DLT network according to the authorized user's requested parameters. In many cases, the specific industry-standard markup language used by the script generator112may be determined by the specified parameters from the authorized user.

Specifically, the generated script will comprise a series executable instructions to be performed at the specified node or nodes to comprise the DLT network. As discussed in more detail above, the script generator112and the command sequencer117will communicate with one another in order to take the generated script from the script generator112and sequence the executable instructions to accurately and efficient provision the DLT network as requested. Certain DLT implementations may require that different executable instructions be performed (or not performed) and in some instances, be performed in a different sequence. The script generator112and the command sequencer coordinate these responsibilities.

Further, the script generator112may interact with the interface handler115to communicate with other required interfaces and gain access to code repositories, operating system calls, external APIs, libraries, and the like. The script generator112requires access to other interfaces in order to generate the scripts according to the parameters provided by the authorized user.

Once the script generator112has completed generating the script as depicted at block303, the DLT network provision engine110progress to block304, where it begins transmitting the executable instructions generated by the script generator112. As alluded to above, the executable instructions are sequenced by the command sequencer117, which also is responsible for transmitting the sequenced executable instruction to the enterprise DLT network provisioning adapters (1310,1320, and1330) located on the DLT network(s) and/or node(s).

Transmitting the executable instructions to the DLT networks(s) and/or nodes(s) also comprises receiving status updates from the network(s) and/or node(s) as to their respective progress on implementing the executables. Such communication is necessary so that instructions are not transmitted before they can be completed. In order to monitor such status, the status collator116is also in operative communication with the other modules discussed herein to receive and track the status of a network provisioning job, and to determine when executable instructions need to be delivered to the respective enterprise DLT network provisioning adapters for the DLT network(s) and/or nodes being provisioned.

At the completion of block304(and once all of the executable instructions have been successfully executed by the respective DLT network(s) and/or nodes(s)), the requested DLT network should be fully provisioned according to the requested parameters received from the authorized user. Once such steps have been successfully completed, the intelligent DLT network provisioning engine110may communicate back to the user that the requested DLT network is fully provisioned, thereby allowing the user to utilize the DLT network for its intended purpose. Alternatively, the system may be configured to perform further tests to ensure that the provisioned DLT network is operable in accordance with all of the user's requested provisions.