Software Technology for “Blockchain micro-services framework”

Blockchain Fintech – Dante J. PACELLA, Ashish Sardesai, Mani Tadayon, Saravanan Mallesan, Sonit Mahey, Lee E. Sattler, Venkata Josyula, Jean M. McManus, Verizon Patent and Licensing Inc

Abstract for “Blockchain micro-services framework”

“A network device receives the first application programming interface call (API) from an application. A micro-service is requested by the first API call. Blockchain-based technology uses a shared ledger between participating nodes in a distributed consensus network. The micro-service is a function that the application uses. In response to the first API request, the network device sends a second API calling to one of its participating nodes. The second API call initiates the framework module of multiple framework modules within the participating nodes. The network device receives from one of the participating Nodes a response to second API call. This response indicates consensus among the participating Nodes. Based on the second API response, the network device generates a reply to first API call.

Background for “Blockchain micro-services framework”

“Connected devices, which can include any device connected to the Internet, have almost limitless applications that could be used to create new and useful services. These services are managed and distributed by many control points, which users can access in various ways. These services are increasingly being offered with blockchain as an authentication and verification option. Blockchain is a distributed, secure transaction database that can be shared between nodes in a network of computers. Blockchain technology relies on an ever-growing proof of work chain to validate information blocks that are added to the transaction leadger. Blockchain technology is still in its infancy and rapidly evolving. It has many offshoots with their own strengths and weaknesses.

The following description is for the accompanying drawings. Different drawings might have the same reference numbers. This could identify similar or identical elements.

“The implementations described herein provide a framework to provide blockchain-based microservices in distributed environments. A service using blockchain technology could include a collection of micro-services. Micro-service architecture allows for targeted development and risk management. As different blockchain concepts become more popular, the cryptography behind them may change. This could lead to new versions or technologies being introduced. These new technologies could be faster, more CPU-intensive, less memory-intensive, offload more processing onto side chains, provide greater privacy, transparency, and/or offer more intelligence. These changes could have a greater impact on one micro-service than the other. Additionally, you can offer blockchain micro-services to existing platforms to replace or augment less reliable services with more reliable functions.

According to one implementation, a network devices may receive the first application programming interface call (API call) from an application on a client or another network device. A micro-service is requested by the first API call. Blockchain-based technology uses a shared ledger between participating nodes in a distributed consensus network. The micro-service is a function that provides an application with a specific function. In response to the first API request, the network device can send a second API calling to one of the participating nosdes. The second API call triggers a framework module from a number of framework modules that are available in the participating devices. A response to the second API request may be received by the network device from one of the participating Nodes. This response will indicate consensus among the participating Nodes. Based on the response to second API call, the network device might generate a reply to first API call.

“FIG. “FIG. Environment 100 can include an access network 110 and a provider network 120. Service nodes 130-1 through 130-1 are also included (collectively referred to as?service nos 130?). either individually or collectively as?service number 130? In a distributed consensus network 140 and client devices 150-1 to 150-Y (also known collectively as ‘client devices 150?). and as?client devices 150 ?).”

“Access network 110”, provider network 120 and service nodes 130 are examples of network elements. Client devices 150 can also include network elements. For example, provider network 120 may contain multiple elements such as an administration server 122, and a microservices platform 124. An element of a network can be implemented using a centralized computing or distributed computing architecture. A cloud computing architecture is also possible (e.g. an elastic cloud, private cloud, public cloud, virtual cloud, etc.). A network element can also be implemented using one or more network architectures (e.g. a client device and a server device as well as a peer device and a proxy device and/or cloud device).

“As illustrated further, environment 100 contains communication links 170 between network elements and networks (although only three of these are referenced in FIG. 1, 170-2, 170-3, and 170-3. An element of a network may transmit or receive data over a link 170. Environment 100 can be used to implement wireless and/or wired (e.g. optical, electrical, etc.) networks. Links 170. An indirect or direct communication link may exist between network elements. An intermediary device, network element, or intermediary network may be used to establish an indirect link. 1. The number and type (e.g. wired, wireless, etc.) are also indicated. The arrangement of links 170 in environment 100 is an example.

Access network 110 could include one or more networks of the same or different types. Access network 110 could include a terrestrial network or a satellite network. It may also include a wired network and/or a wireless network. Access network 110 can include other networks in some instances, such as a backhaul or core network.

“Provider network 120 can include one or more networks of one type or several. Provider network 120 could include, for example, an Internet Protocol Multimedia Subsystem (IP) network, a cloud network or a metropolitan area network network (MAN), a service network, a private IP, some other backend network, etc. An exemplary embodiment of provider network 120 contains administration server 122, micro-services platform 124, and so forth. Other exemplary embodiments include administration server 122 and micro-services platform 124, respectively, which may be combined or distributed in one device.

“Administration server 122 includes one or more network devices which provide administrative functions to client devices 150 in order to access the blockchain micro-services. For example, administration server 122 may provide configuration/provisioning for customers to set up applications that will access blockchain micro-services. Administration server 122 can manage permissions for client devices 150 and/or users thereof to access services from provider networks 120 and/or distributed consensus networks 140.

“Microservices platform 124 contains one or more network devices that offer blockchain micro-services. Client devices 150 can access them, including client devices that run applications or other solutions. Micro-services platform number 124 could include an index of micro-service options, a registration component that allows access to certain micro-services and handling communications. A set of APIs may be used by applications to access micro-services. An API can use a set of software functions and procedures (referred to as API calls) that can be executed using other software applications. As an example, micro-services platform124 can receive API calls from applications (e.g. an application running on client device 150) and initiate one or several blockchain micro-services performed by service nodes 130 within distributed consensus network 140. Administration server 122 and micro-services platform may have logic that validates an API call from client 150 before performing the microservice.

“Service node 130” includes one or more network devices that offer storage and/or computing resources to blockchain micro-services. Service node 130, in one example, may contain a third party-owned network device, which is located in a different domain than provider network 120. Service node 130 could be part of another network that is associated to provider network 120. An implementation shown herein shows that each service node 130 can leverage a shared ledger in order to provide a specific micro-service to applications 150.

“Distributed consensus networks 140” may include devices that are part of blockchain-based technology, such as validation of shared ledger entries. Distributed consensus network 140 could include all or some of the service nodes 130 in one implementation. Distributed consensus network 140 could also include nodes not shown, other than 130 service nodes. To reduce the burden on 130 service nodes, it is possible to leverage multiple servers and proxy nodes that are running in edge or cloud computing clusters/farms as a consensus network. Alternatively, distributed consensus network 140 may include service nodes 130 in different private domains. Every participant in distributed consensus network 140 keeps a constantly-growing list records, referred to as a “shared ledger”. Each participating node in the distributed consensus network 140 maintains a continuously-growing list of records referred to herein as a?shared ledger,? All updates received from trusted nodes will be included in the shared ledger. Each shared ledger version contains a timestamp as well as a link to the previous version. Each participant service node 130 in the distributed consensus network 140 receives the shared ledger as a cryptographically secure block. The authorization is then added chronologically to the shared leger. To increase efficiency, each entry in the shared ledger can be considered a node within a hash tree structure. This ensures that trusted nodes receive their blocks intact and unaltered. It also allows distributed consensus network 140 (distributed consensus network 140) to verify that nodes within the network are not storing fraudulent or incorrect blocks.

“Client device 150” may contain a connected device, computing device, or device that is operated by or on behalf of the user. Client device 150 can request items and services that require blockchain services from one or more administration servers 122, microservices platform 124, or service node 130. Client device 150 can request a service from micro-services platform 124. For example, the request could use an API call to access the micro-service. Micro-services platform 124-6 may initiate a distributed consensus network 140 blockchain activity through an API call.

“Links 170 allow communication between network elements and/or networks in environment 100. Links 170 could have specific characteristics such as bandwidth capacity or transmission data rate.

“The arrangement of environment 100 is exemplary in terms of the number of network elements and the number of networks. Other embodiments may add additional network elements, less network elements and/or arrange network elements differently than the ones shown in FIG. 1. One example is that there could be multiple administration servers (122), micro-services platforms (124), and so on. Other embodiments also allow multiple network elements to be implemented on one device. Conversely, a network component can be implemented on multiple devices. A service node 130 may include all or parts of the micro-services platforms, 124. Another way to combine networks in environments 100 and 130 is to use another network.

“FIG. “FIG. Device 200 could correspond to any of the network elements. This includes administration server 122 and micro-services platform 124, service nodes 130, client devices 150, and network environment 100. Device 200 could include a bus, a processor 220 and a memory 235, with software 235. An input component 240, 250 and 250 may be included. A communication interface 260 is also possible.

“Bus 220 may contain a path that allows communication between components of device 200. The processor 220 could include a microprocessor or a processor that can interpret and execute instructions. Memory 230 can include any type or non-volatile storage device, which may be used by processor 220 to store instructions and information.

Software 235 refers to an application or program that performs a function or performs a process. Software 235 could also include firmware, middleware and microcode. These network elements, which include logic to provide micro-services on blockchain, may include software 235. Client device 150 could also include software 235, such as an application that communicates with micro-services platform 130, service node 130, and so forth. to perform tasks as described herein.”

“Input component 244 may contain a mechanism that allows a person input information to device 200. This could include a keyboard, keypad, button, switch, or other mechanisms. Output component 250 could include a mechanism that sends information to the person. This may include a display, speaker, or one or more light emitting devices (LEDs).

“Communication interface 262 may include a transceiver which allows device 200 to communicate wirelessly with other devices or systems, wired, or a combination thereof. Communication interface 260, for example, may contain mechanisms to communicate with another device or system over a network. An antenna assembly may be included in communication interface 260 for the transmission and/or reception radio frequency (RFS) signals. Communication interface 260, in one example, may be used to communicate with devices and networks. Communication interface 260, which may also be used as an alternative or additional component, could include input and out ports, input systems and/or other input components that enable data transmission to other devices.

“Device 200 can execute certain operations in response processor 220 executing software instructions (e.g. software 235) contained on a computer-readable media, such as memory.230. A computer-readable medium can be described as a non-transitory storage device. Non-transitory memories devices can include memory space in one physical memory device, or spread across multiple physical storage devices. Software instructions can be read from another computer-readable medium, or from another device into memory 230. Processor 220 may be able to execute the software instructions in memory 230. Alternately, you can use hardwired circuitry to implement the processes described in this document. Implementations described herein do not limit to a particular combination of hardware and software.

“Device 200 could contain fewer, more, or different components and/or be arranged differently than the components shown in FIG. 2. In some cases, however, a display might not be included in device 200. Device 200 could be considered a “headless” device in these cases. Device that does not contain input component 240. Device 200 could also include one or more switches fabrics in place of or in addition to bus 210. Alternately, one component of device 200 could perform one or several tasks that are described as being performed in device 200.

“FIG. “FIG. FIG. FIG. 3 shows how a collection of applications and solutions 310 leverage microservices 320 which leverage an underlying platform 330. Applications/solutions 310 may reside, for example, on client devices 150. Micro-services 320 could be found on micro-services platform 124, and/or service nodes 135. Examples of applications/solutions 310 may include payment applications, digital marketplace applications, rental equipment applications, and numerous other types of applications. A micro-service 320 could include authentication and authorization, repudiation, chain of custody (validating a transaction), multi-party settlement, and digital coins. In one implementation, a micro-service 320 may be initiated by one of applications/solutions 310 using an API 340 for the particular micro-service. Multiple applications/solutions 310 may use the same microservice 320. Each application/solution 310 may call as many micro-services 322 as it needs.

“Microservices 320 can use modules from framework 330 in order to perform a specific micro-service. One micro-service 320 could use multiple modules from framework330 to complete the micro-service. Each module of framework 330 can be invoked using either an application binary interface 350 (ABI) or a different API 360 depending on the specific framework item. An API call for one micro-service could cause it to make multiple API calls and/or ABI request to different framework modules. Execution API calls can result in an ephemeral execution or perpetual execution of a number of blockchain functions (e.g. micro-service(s), framework service(s), etc.).

“FIG. “FIG. FIG. FIG. 4 shows that framework 330 could include a virtual consensus module 405, an anti-collusion program module 410 and a block anomaly detector module 415. A smart contracts module 422, an API/ABI template 425. A discovery module 450. An analytics module 460. A development operations (devops) tools module 465. The modules discussed in connection to FIG. 4 can be performed by any one or more of the service nodes 130. The modules discussed in connection with FIG. Services nodes may perform the 4 modules in conjunction with FIG. 122 and 124. Any or all of FIG. 4. may be included in an application (e.g. software), stored in memory 220 and executed by processor 220.

“Virtual consensus module 405 is a consensus and mining node that can be added as required to expand the distributed consensus network 140. The virtual consensus network module 405 can be used by devices only from one cloud provider or multiple cloud providers with their own pool. Users may also join existing pools or create their own. Virtual consensus network module 405 can be used in multiple cloud providers arrangements. Virtual consensus network module 405 can include a pluggable module. This means that each Application creator has the option to create pluggable modules or use pre-built modules from the framework.

Anti-collusion module410 may prevent the overtake of distributed consensus networks 140 by a cartel. (e.g. consensus network 51% cartel prevention, where an unauthorized group attempts to provide sham consensus. Anti-collusion module410 may provide historical reporting for each node (e.g. service node 130), per network (e.g. collection of service nodes 130), or across the entire network. Anti-collusion module410 can monitor orphan/uncles, transaction fees, block count, time to solve, and transaction fees. If compute imbalances are detected, Anti-Collusion Module 410 may request additional nodes.

Block anomaly detection module 415 can determine the rate of block creation, number of transactions per blocks, transaction fees per transaction, and uncles/uncles blocks. Block anomaly detection module 415 can establish a baseline, alert or take action on any deviations.

Smart contract module 420 stores smart contracts and manages them for clients using 150 devices. Smart contract module420 can also be used to provide a development environment that allows smart contracts. It includes templates for different types/classes and input variables. Smart contracts can be applied to multiple users. Smart contracts can be signed by third parties, such as regulatory or legal entities. Smart contracts can also be constructed as sub-routines that can be called by smart contracts (as an appendices). A sub-routine could be used to compensate initial rights holders (e.g. producers of content/goods) through a microtransaction of a percentage of resale/lease/rental. This would require an initial rights holder subroutine to be called using a smart contract for resale.

“API/ABI Module 425 controls external interfaces with smart contracts of smart contract 420, for example. API/ABI module 25, according to one implementation, may allow read/write operations to trusted nodes (e.g. within a private group) and restrict certain nodes (e.g. service nodes 130), to read-only operations. API/ABI module 425 offers a standard set APIs (backend and frontend as well as data flow and endpoint) for both base micro-service templates or smart contract templates. It also provides ABIs and APIs for contracts.

“Blockchain Node Template 430 allows aggregation and clustering of different distributed storage mounts, local or clustered computing (via central processor (CPU), general processor (GPU), and/or both as well as an application-specific integrated circuit(ASIC) or numeric processing units (NPU-based hardware driven via CPU operations), as backup facilities, microservices, scheduling, resource rules and developer operations tools. One implementation of blockchain node template430 can assemble features as a part of a single “compute node”. Running in one or more containers. As a virtual aggregation micro-services, features can run on multiple nodes in another implementation.

Key managers module 435 can implement security algorithms. This includes algorithm selection amongst the set of cipher suites by the developer, its associated key management, distribution and subsequent invocation (during the run-time for encryption, obfuscation and pseudonymization. Or any other security-related operations during a blockchain-based microservice or service execution. Key managers module 435 might also be able to add new cipher suites quickly to an existing set. Key managers module 435 can register and distribute ID pairings and public keys. According to one implementation, key managers module 435 may an also associate IDs and keys with context (conditional/environment/application).”

“Identification (ID), services module 440 may generate IDs for any device or service that is not capable of self-generating IDs. Services index module 480 may interface with ID service module 444. This module can arbitrate between detected collisions.

“State channels module 445” allows messaging over state channels between two nodes (e.g. service nodes 130 or a pair on client devices 150), or any other peer constructs off the chain (e.g. not written to blockchain if both sides agree on the zero sum transaction). State channels can be used between micro-service instances or services, regardless if the physical node instantiation is not. State channels can be found between data centers in some cases.

“Discovery module 45 may find new nodes and announce new information to other members of the community of interests (e.g. distributed consensus network 140). Discovery module 450 in a permissioned environment may not be active as a registration process would allow propagation of information regarding the new host, ID and network attachment information. A discovery process, implemented through discovery modules 450, can uncover new nodes and promote this information to other members of the community.

“Client Management Module 455 allows management of wallets and accounts (e.g. accessed through client devices 150). It leverages blockchain services.

Analytics module 460 can collect and analyze data such block rate, uncles/orphans rates, transaction fees trends and other statistical analyses on the blockchain networks and data. Analytics module 460 could provide data to be used in anti-collusion and anomaly detection.

“Development operation tools module 465 can provide software modules, templates and services for developers to create and maintain micro-services. Module 465 could include, for instance, blockchain Node health monitors and blockchain micro-service monitoring (e.g. per service/per instance), smart contract validators.

Multi-language module 470 could support multiple languages of development (inside or outside of the blockchain technology). Multi-language module (470) may support multiple languages for client dialogue (e.g. written and spoken).

“Resource manager module 475 can schedule, monitor and manage resources for service nodes 130 or distributed consensus network 140. Resource manager module 475, for example, may monitor storage resources, computing resources (CPU or GPU), clients and connections, as well as bandwidth. To determine if scaling is necessary for one or more resources.

“Services index module480 may advertise the location of services (e.g. a network address) or provide?gossip?” “Services index module 480 may advertise where services are hosted (e.g., a network address) and provide?gossip?

“Message broker module 485 could provide secure communications between nodes (e.g. service nodes 130), between the data centers and with outside agents/clients. The message broker module 485 can also offer non-blocking messaging among micro-services. It may provide well-known queues, allow for adding, altering, and removing services without code changes or the operation with other services. It can also handle service failures and other aberrant state transitions.

“The FIG. These are not limited examples. Framework 330 may contain different modules or more in other implementations. In some cases, one or more framework modules 405-485 can be broken down into multiple modules, or combined with other framework modules.

“FIG. “FIG. Part 500 of the network may contain micro-services platform 124, distributed consensus network 140, client device 150, and portion 500 of network environment 100.

“As shown at FIG. 5. An application 310 running on client device 150 could submit a microservice API call510 for a specific micro-service that is accessible through microservices platform.124. Micro-service API call 511 may identify a specific micro-service that uses blockchain. Micro-service API call510, for example, may request transaction authentication, authorization, new ledger entry, and other services as part of a larger service. Application 310 can invoke any number of relevant blockchain functions (e.g. micro-service(s), framework service(s), etc.) but does not have to invoke all of the functions. Micro-service platform 122.4 may respond to microservice API call 501. It may also identify multiple framework modules (e.g. any of the modules 405-485 mentioned above) that are required to answer to microservice API call 501.

“Microservices platform 124% may send one or more API calls to service nodes 130 or conduct ABI exchanges to obtain and/or provide the requested micro-service. Micro-services platform 124, for example, may submit a micro-services API call 520 to a specific instance of a component on a service 130. Micro-services platform 122.4 may submit multiple framework API calls 525 to a particular instance of a component on a service node 130. Micro-services platform 122.4 may submit an ABI request 525 simultaneously with or sequentially to framework API call 520. Each service node 130 may use a distributed architecture, and this architecture allows for an entity (e.g., application 310, micro-services platform 124, or another service node 130) deploying a service node 130 to pick and choose from an array of blockchain functions/micro-services resulting in deployment of dependent blockchain functions/micro-services as well (i.e., the dependency list is inherent to the micro-service and need not be specified by the entity deploying the service node).”

“Service node 130 might receive ABI request 525 or framework API call 522, and may implement blockchain protocols in response to requests from microservices platform 124. FIG. 6 describes blockchain activity 530. 6 is a diagram that illustrates exemplary logical elements for managing a block chain transaction. These logical components can be found in a service node 130. They may be implemented as either a single network device, or a distributed one. FIG. Referring to FIG. 6, data from API call 525 and/or ABI request 525 can be registered as transactions in distributed consensus network 140. Each active service node 130 in the distributed consensus network 140 collects a transaction queue. Block processing units 610 at each service node 130 can group transactions into blocks. A mining unit 615 may also perform operations such as linking new blocks to cryptographic hashes of previous blocks, or calculating proof-of-work with complex algorithms. required for record-keeping and verification.

“Still referring back to FIG. 6. The first service node 130 will find the answer to a new block and publish it (e.g. using block publisher620) to the 130 other service nodes. Each of the 130 other service nodes will validate (using transaction validity unit 625), store locally (in ledger storage630) and provide consensus (using consensus manger 635) to accept/reject the new block. FIG. FIG. 6. shows the logical components of service 130. However, other implementations may have fewer, more or different components. All service 130 may not contain an identical set.

“Returning at FIG. “Returning to FIG. A consensus among the 130 participating nodes may be indicated by framework API response 540 or ABI response 545, according to blockchain activity 530. Micro-services platform 12 may be able to receive both framework API response540 and ABI reply 545. Micro-services platform 124.1 may use framework API response540 and ABI reply 545 to generate micro-service API response 555. This is sent to client device 150 as application 310.

“FIG. “FIG.7″ is a diagram that illustrates the interactions of an application that accesses multiple micro-services using different framework items. Each micro-service (320) may use different modules of framework 330. Additionally, each application 310 could use different microservices 320, as well as a different number 320 of each microservice 320. FIG. 7 is an example. 7 shows one application 310-1 in relation to three of the micro-services, 320. Three micro-services (320) use items from framework 333. Application 310-1 uses one instance of microservice?A? 320-1 and microservice?C? 320-3 when using three instances micro-service?B? 320-2. Micro-service ?A? 320-1 uses smart contract 420 and blockchain APIs/ABIs 450. Each micro-service?B instance? 320-2 uses services index 480, smart contract 420, blockchain APIs/ABIs 450, and state channels 445. Micro-service ?C? Micro-service?C?320-3 uses smart contract 420 and key mangers 435.”

“The micro-service architecture allows each micro-service 320, to scale independently by creating new instances of the micro-service. Each micro-service can create as many instances as it needs. One micro-service 320 instance can fail and not affect other instances or services. Each micro-service 320 might use memory isolation/failure prevention technologies such as virtualization, protected memory, containerization, and others.

“FIG. “FIG.8″ is a diagram that illustrates the interactions between an application and multiple micro-services. A micro-service 320 may use another microservice to input its process. For example, micro-service ?A? As input to micro-service?C?, 320-1 is shown. FIG. 8. Application 310-2 in this case does not use microservice?A? 320-1 directly.”

“Also, in the example FIG. 8, micro-service ?D? 8, micro-service?D? 320-4 has 100 instances, while micro-service?B? has three. Hyperscale scenarios such as FIG. 8 may be limited by the availability of resources and the ability to track and manage them. Each micro-service 320 can be scaled as required using the micro-service architecture. A micro-service 320, for example, can be scaled down and up as the demand increases or decreases. Service nodes 130 of the distributed consensus network 140 can scale memory, storage and GPU as well as the number or instances.

“FIG. 9. This flow diagram shows an example process 900 to implement blockchain micro-services. Process 900 can be executed by micro-services platform 124. Another implementation may use some or all the process 900 by another device, or group of devices. This includes or excludes devices in provider network 120.

“Process 900 could include receiving a microservices API call from an application that requests a service of a blockchain-based tech (block 910). Application 310 may result in micro-service API calls 510. Micro-service API Call 510 can be received at microservices platform 124. A framework module 330 may be required to execute the requested micro-service.

“Process 900 could also include the sending of a framework API request to initiate a module in the participating nodes (block 920) Micro-service API call 515 may result in micro-service platform 124 sending one or more framework API requests 520 to 130 to execute a module. (e.g. one or more modules 405-485 of framework 330). A framework module can include an activity, transaction or other information that requires consensus from all 130 service nodes 140 in distributed consensus network 140 who are participating in the micro-service.

“Process 900 could also include one or more responses to framework API calls (block 930) from participating nodes. Service nodes 130 might perform a blockchain activity (530) in response to API call 522. A transaction may be published and the consensus of all 130 service nodes to complete the blockchain activity 530. One or more service nodes 130 may provide the result of blockchain activity 53 to micro-services platform 124.

“Process 900 could also include generating, based upon the responses to the framework API callings, a reply (block 940) to the first API call. Micro-services platform 12 may, for example, compile microservice response 55 and send it to application 310. The process 900 can be repeated for multiple microservice API calls from different applications 310 and 310.

“A blockchain micro-services framework provides multiple microservices that are based on blockchain technology for a variety different first-party, hosted and development applications. The micro-services platform also has attributes that allow for distributed, hosted, and built blockchain technologies. These micro-services are customizable and can be used to build additional micro-services or foundations for other applications.

The blockchain micro-services framework permits fundamental changes to blockchain technology for one module (e.g. one of modules 405-485), rather than changes across the entire system and corresponding apps. The blockchain micro-services framework encourages developers to create code that is more interoperable, transparent, and modular. Implementing micro-services-based blockchain functions may make it easier to create new services that can be assembled from micro-services that are loosely connected. An index of microservices libraries can be accessed by any existing or new application in one implementation.

“The above description of implementations is intended to provide illustration and description but not to be exhaustive nor to limit the invention to its specific form. You can make modifications and vary the teachings. These modifications are also possible based on the practice of the invention. A series of blocks has been shown in FIG. 9), the order of the blocks can be changed in other embodiments. Non-dependent blocks can be executed in parallel.

“Certain of the features discussed above can be implemented as?logic?” Or a ‘unit? One or more functions. This logic/unit may contain hardware such as processors, microprocessors or application-specific integrated circuits. It could also include software or a combination thereof.

“The aforementioned embodiments may collect, store, or employ personal data provided by individuals. It should be understood that such information will be used in accordance to all applicable laws regarding protection of personal data. The individual may consent to the collection, storage, and use of such information, such as through well-known?opt in?. You can also opt-out or opt-in to such information. Processes that may be applicable to the specific situation and type of information. Personal information can be stored and used in a secure manner that is appropriate for the information. This could include anonymization and encryption techniques for sensitive information.

“Use ordinal terms such?first? ?second,? ?third,? The claim element to be modified is referred to as “third”.

“No element, act or instruction in the present application description should be considered critical or essential to an invention, unless it is explicitly stated as such. The article?a? is also used herein. The article?a? soll also include at least one item. The phrase “based on” also means “based on?” Further, the phrase?based on? is meant to be?based at least in part? Unless otherwise stated.

“Various preferred embodiments have been described in the preceding specification with reference to the accompanying illustrations. However, it will be apparent that modifications and additions can be made to the specification. Additional embodiments could also be implemented without departing from its wider scope as described in the claims. Accordingly, the specification and drawings should be considered in an illustrative not restrictive sense.

Summary for “Blockchain micro-services framework”

“Connected devices, which can include any device connected to the Internet, have almost limitless applications that could be used to create new and useful services. These services are managed and distributed by many control points, which users can access in various ways. These services are increasingly being offered with blockchain as an authentication and verification option. Blockchain is a distributed, secure transaction database that can be shared between nodes in a network of computers. Blockchain technology relies on an ever-growing proof of work chain to validate information blocks that are added to the transaction leadger. Blockchain technology is still in its infancy and rapidly evolving. It has many offshoots with their own strengths and weaknesses.

The following description is for the accompanying drawings. Different drawings might have the same reference numbers. This could identify similar or identical elements.

“The implementations described herein provide a framework to provide blockchain-based microservices in distributed environments. A service using blockchain technology could include a collection of micro-services. Micro-service architecture allows for targeted development and risk management. As different blockchain concepts become more popular, the cryptography behind them may change. This could lead to new versions or technologies being introduced. These new technologies could be faster, more CPU-intensive, less memory-intensive, offload more processing onto side chains, provide greater privacy, transparency, and/or offer more intelligence. These changes could have a greater impact on one micro-service than the other. Additionally, you can offer blockchain micro-services to existing platforms to replace or augment less reliable services with more reliable functions.

According to one implementation, a network devices may receive the first application programming interface call (API call) from an application on a client or another network device. A micro-service is requested by the first API call. Blockchain-based technology uses a shared ledger between participating nodes in a distributed consensus network. The micro-service is a function that provides an application with a specific function. In response to the first API request, the network device can send a second API calling to one of the participating nosdes. The second API call triggers a framework module from a number of framework modules that are available in the participating devices. A response to the second API request may be received by the network device from one of the participating Nodes. This response will indicate consensus among the participating Nodes. Based on the response to second API call, the network device might generate a reply to first API call.

“FIG. “FIG. Environment 100 can include an access network 110 and a provider network 120. Service nodes 130-1 through 130-1 are also included (collectively referred to as?service nos 130?). either individually or collectively as?service number 130? In a distributed consensus network 140 and client devices 150-1 to 150-Y (also known collectively as ‘client devices 150?). and as?client devices 150 ?).”

“Access network 110”, provider network 120 and service nodes 130 are examples of network elements. Client devices 150 can also include network elements. For example, provider network 120 may contain multiple elements such as an administration server 122, and a microservices platform 124. An element of a network can be implemented using a centralized computing or distributed computing architecture. A cloud computing architecture is also possible (e.g. an elastic cloud, private cloud, public cloud, virtual cloud, etc.). A network element can also be implemented using one or more network architectures (e.g. a client device and a server device as well as a peer device and a proxy device and/or cloud device).

“As illustrated further, environment 100 contains communication links 170 between network elements and networks (although only three of these are referenced in FIG. 1, 170-2, 170-3, and 170-3. An element of a network may transmit or receive data over a link 170. Environment 100 can be used to implement wireless and/or wired (e.g. optical, electrical, etc.) networks. Links 170. An indirect or direct communication link may exist between network elements. An intermediary device, network element, or intermediary network may be used to establish an indirect link. 1. The number and type (e.g. wired, wireless, etc.) are also indicated. The arrangement of links 170 in environment 100 is an example.

Access network 110 could include one or more networks of the same or different types. Access network 110 could include a terrestrial network or a satellite network. It may also include a wired network and/or a wireless network. Access network 110 can include other networks in some instances, such as a backhaul or core network.

“Provider network 120 can include one or more networks of one type or several. Provider network 120 could include, for example, an Internet Protocol Multimedia Subsystem (IP) network, a cloud network or a metropolitan area network network (MAN), a service network, a private IP, some other backend network, etc. An exemplary embodiment of provider network 120 contains administration server 122, micro-services platform 124, and so forth. Other exemplary embodiments include administration server 122 and micro-services platform 124, respectively, which may be combined or distributed in one device.

“Administration server 122 includes one or more network devices which provide administrative functions to client devices 150 in order to access the blockchain micro-services. For example, administration server 122 may provide configuration/provisioning for customers to set up applications that will access blockchain micro-services. Administration server 122 can manage permissions for client devices 150 and/or users thereof to access services from provider networks 120 and/or distributed consensus networks 140.

“Microservices platform 124 contains one or more network devices that offer blockchain micro-services. Client devices 150 can access them, including client devices that run applications or other solutions. Micro-services platform number 124 could include an index of micro-service options, a registration component that allows access to certain micro-services and handling communications. A set of APIs may be used by applications to access micro-services. An API can use a set of software functions and procedures (referred to as API calls) that can be executed using other software applications. As an example, micro-services platform124 can receive API calls from applications (e.g. an application running on client device 150) and initiate one or several blockchain micro-services performed by service nodes 130 within distributed consensus network 140. Administration server 122 and micro-services platform may have logic that validates an API call from client 150 before performing the microservice.

“Service node 130” includes one or more network devices that offer storage and/or computing resources to blockchain micro-services. Service node 130, in one example, may contain a third party-owned network device, which is located in a different domain than provider network 120. Service node 130 could be part of another network that is associated to provider network 120. An implementation shown herein shows that each service node 130 can leverage a shared ledger in order to provide a specific micro-service to applications 150.

“Distributed consensus networks 140” may include devices that are part of blockchain-based technology, such as validation of shared ledger entries. Distributed consensus network 140 could include all or some of the service nodes 130 in one implementation. Distributed consensus network 140 could also include nodes not shown, other than 130 service nodes. To reduce the burden on 130 service nodes, it is possible to leverage multiple servers and proxy nodes that are running in edge or cloud computing clusters/farms as a consensus network. Alternatively, distributed consensus network 140 may include service nodes 130 in different private domains. Every participant in distributed consensus network 140 keeps a constantly-growing list records, referred to as a “shared ledger”. Each participating node in the distributed consensus network 140 maintains a continuously-growing list of records referred to herein as a?shared ledger,? All updates received from trusted nodes will be included in the shared ledger. Each shared ledger version contains a timestamp as well as a link to the previous version. Each participant service node 130 in the distributed consensus network 140 receives the shared ledger as a cryptographically secure block. The authorization is then added chronologically to the shared leger. To increase efficiency, each entry in the shared ledger can be considered a node within a hash tree structure. This ensures that trusted nodes receive their blocks intact and unaltered. It also allows distributed consensus network 140 (distributed consensus network 140) to verify that nodes within the network are not storing fraudulent or incorrect blocks.

“Client device 150” may contain a connected device, computing device, or device that is operated by or on behalf of the user. Client device 150 can request items and services that require blockchain services from one or more administration servers 122, microservices platform 124, or service node 130. Client device 150 can request a service from micro-services platform 124. For example, the request could use an API call to access the micro-service. Micro-services platform 124-6 may initiate a distributed consensus network 140 blockchain activity through an API call.

“Links 170 allow communication between network elements and/or networks in environment 100. Links 170 could have specific characteristics such as bandwidth capacity or transmission data rate.

“The arrangement of environment 100 is exemplary in terms of the number of network elements and the number of networks. Other embodiments may add additional network elements, less network elements and/or arrange network elements differently than the ones shown in FIG. 1. One example is that there could be multiple administration servers (122), micro-services platforms (124), and so on. Other embodiments also allow multiple network elements to be implemented on one device. Conversely, a network component can be implemented on multiple devices. A service node 130 may include all or parts of the micro-services platforms, 124. Another way to combine networks in environments 100 and 130 is to use another network.

“FIG. “FIG. Device 200 could correspond to any of the network elements. This includes administration server 122 and micro-services platform 124, service nodes 130, client devices 150, and network environment 100. Device 200 could include a bus, a processor 220 and a memory 235, with software 235. An input component 240, 250 and 250 may be included. A communication interface 260 is also possible.

“Bus 220 may contain a path that allows communication between components of device 200. The processor 220 could include a microprocessor or a processor that can interpret and execute instructions. Memory 230 can include any type or non-volatile storage device, which may be used by processor 220 to store instructions and information.

Software 235 refers to an application or program that performs a function or performs a process. Software 235 could also include firmware, middleware and microcode. These network elements, which include logic to provide micro-services on blockchain, may include software 235. Client device 150 could also include software 235, such as an application that communicates with micro-services platform 130, service node 130, and so forth. to perform tasks as described herein.”

“Input component 244 may contain a mechanism that allows a person input information to device 200. This could include a keyboard, keypad, button, switch, or other mechanisms. Output component 250 could include a mechanism that sends information to the person. This may include a display, speaker, or one or more light emitting devices (LEDs).

“Communication interface 262 may include a transceiver which allows device 200 to communicate wirelessly with other devices or systems, wired, or a combination thereof. Communication interface 260, for example, may contain mechanisms to communicate with another device or system over a network. An antenna assembly may be included in communication interface 260 for the transmission and/or reception radio frequency (RFS) signals. Communication interface 260, in one example, may be used to communicate with devices and networks. Communication interface 260, which may also be used as an alternative or additional component, could include input and out ports, input systems and/or other input components that enable data transmission to other devices.

“Device 200 can execute certain operations in response processor 220 executing software instructions (e.g. software 235) contained on a computer-readable media, such as memory.230. A computer-readable medium can be described as a non-transitory storage device. Non-transitory memories devices can include memory space in one physical memory device, or spread across multiple physical storage devices. Software instructions can be read from another computer-readable medium, or from another device into memory 230. Processor 220 may be able to execute the software instructions in memory 230. Alternately, you can use hardwired circuitry to implement the processes described in this document. Implementations described herein do not limit to a particular combination of hardware and software.

“Device 200 could contain fewer, more, or different components and/or be arranged differently than the components shown in FIG. 2. In some cases, however, a display might not be included in device 200. Device 200 could be considered a “headless” device in these cases. Device that does not contain input component 240. Device 200 could also include one or more switches fabrics in place of or in addition to bus 210. Alternately, one component of device 200 could perform one or several tasks that are described as being performed in device 200.

“FIG. “FIG. FIG. FIG. 3 shows how a collection of applications and solutions 310 leverage microservices 320 which leverage an underlying platform 330. Applications/solutions 310 may reside, for example, on client devices 150. Micro-services 320 could be found on micro-services platform 124, and/or service nodes 135. Examples of applications/solutions 310 may include payment applications, digital marketplace applications, rental equipment applications, and numerous other types of applications. A micro-service 320 could include authentication and authorization, repudiation, chain of custody (validating a transaction), multi-party settlement, and digital coins. In one implementation, a micro-service 320 may be initiated by one of applications/solutions 310 using an API 340 for the particular micro-service. Multiple applications/solutions 310 may use the same microservice 320. Each application/solution 310 may call as many micro-services 322 as it needs.

“Microservices 320 can use modules from framework 330 in order to perform a specific micro-service. One micro-service 320 could use multiple modules from framework330 to complete the micro-service. Each module of framework 330 can be invoked using either an application binary interface 350 (ABI) or a different API 360 depending on the specific framework item. An API call for one micro-service could cause it to make multiple API calls and/or ABI request to different framework modules. Execution API calls can result in an ephemeral execution or perpetual execution of a number of blockchain functions (e.g. micro-service(s), framework service(s), etc.).

“FIG. “FIG. FIG. FIG. 4 shows that framework 330 could include a virtual consensus module 405, an anti-collusion program module 410 and a block anomaly detector module 415. A smart contracts module 422, an API/ABI template 425. A discovery module 450. An analytics module 460. A development operations (devops) tools module 465. The modules discussed in connection to FIG. 4 can be performed by any one or more of the service nodes 130. The modules discussed in connection with FIG. Services nodes may perform the 4 modules in conjunction with FIG. 122 and 124. Any or all of FIG. 4. may be included in an application (e.g. software), stored in memory 220 and executed by processor 220.

“Virtual consensus module 405 is a consensus and mining node that can be added as required to expand the distributed consensus network 140. The virtual consensus network module 405 can be used by devices only from one cloud provider or multiple cloud providers with their own pool. Users may also join existing pools or create their own. Virtual consensus network module 405 can be used in multiple cloud providers arrangements. Virtual consensus network module 405 can include a pluggable module. This means that each Application creator has the option to create pluggable modules or use pre-built modules from the framework.

Anti-collusion module410 may prevent the overtake of distributed consensus networks 140 by a cartel. (e.g. consensus network 51% cartel prevention, where an unauthorized group attempts to provide sham consensus. Anti-collusion module410 may provide historical reporting for each node (e.g. service node 130), per network (e.g. collection of service nodes 130), or across the entire network. Anti-collusion module410 can monitor orphan/uncles, transaction fees, block count, time to solve, and transaction fees. If compute imbalances are detected, Anti-Collusion Module 410 may request additional nodes.

Block anomaly detection module 415 can determine the rate of block creation, number of transactions per blocks, transaction fees per transaction, and uncles/uncles blocks. Block anomaly detection module 415 can establish a baseline, alert or take action on any deviations.

Smart contract module 420 stores smart contracts and manages them for clients using 150 devices. Smart contract module420 can also be used to provide a development environment that allows smart contracts. It includes templates for different types/classes and input variables. Smart contracts can be applied to multiple users. Smart contracts can be signed by third parties, such as regulatory or legal entities. Smart contracts can also be constructed as sub-routines that can be called by smart contracts (as an appendices). A sub-routine could be used to compensate initial rights holders (e.g. producers of content/goods) through a microtransaction of a percentage of resale/lease/rental. This would require an initial rights holder subroutine to be called using a smart contract for resale.

“API/ABI Module 425 controls external interfaces with smart contracts of smart contract 420, for example. API/ABI module 25, according to one implementation, may allow read/write operations to trusted nodes (e.g. within a private group) and restrict certain nodes (e.g. service nodes 130), to read-only operations. API/ABI module 425 offers a standard set APIs (backend and frontend as well as data flow and endpoint) for both base micro-service templates or smart contract templates. It also provides ABIs and APIs for contracts.

“Blockchain Node Template 430 allows aggregation and clustering of different distributed storage mounts, local or clustered computing (via central processor (CPU), general processor (GPU), and/or both as well as an application-specific integrated circuit(ASIC) or numeric processing units (NPU-based hardware driven via CPU operations), as backup facilities, microservices, scheduling, resource rules and developer operations tools. One implementation of blockchain node template430 can assemble features as a part of a single “compute node”. Running in one or more containers. As a virtual aggregation micro-services, features can run on multiple nodes in another implementation.

Key managers module 435 can implement security algorithms. This includes algorithm selection amongst the set of cipher suites by the developer, its associated key management, distribution and subsequent invocation (during the run-time for encryption, obfuscation and pseudonymization. Or any other security-related operations during a blockchain-based microservice or service execution. Key managers module 435 might also be able to add new cipher suites quickly to an existing set. Key managers module 435 can register and distribute ID pairings and public keys. According to one implementation, key managers module 435 may an also associate IDs and keys with context (conditional/environment/application).”

“Identification (ID), services module 440 may generate IDs for any device or service that is not capable of self-generating IDs. Services index module 480 may interface with ID service module 444. This module can arbitrate between detected collisions.

“State channels module 445” allows messaging over state channels between two nodes (e.g. service nodes 130 or a pair on client devices 150), or any other peer constructs off the chain (e.g. not written to blockchain if both sides agree on the zero sum transaction). State channels can be used between micro-service instances or services, regardless if the physical node instantiation is not. State channels can be found between data centers in some cases.

“Discovery module 45 may find new nodes and announce new information to other members of the community of interests (e.g. distributed consensus network 140). Discovery module 450 in a permissioned environment may not be active as a registration process would allow propagation of information regarding the new host, ID and network attachment information. A discovery process, implemented through discovery modules 450, can uncover new nodes and promote this information to other members of the community.

“Client Management Module 455 allows management of wallets and accounts (e.g. accessed through client devices 150). It leverages blockchain services.

Analytics module 460 can collect and analyze data such block rate, uncles/orphans rates, transaction fees trends and other statistical analyses on the blockchain networks and data. Analytics module 460 could provide data to be used in anti-collusion and anomaly detection.

“Development operation tools module 465 can provide software modules, templates and services for developers to create and maintain micro-services. Module 465 could include, for instance, blockchain Node health monitors and blockchain micro-service monitoring (e.g. per service/per instance), smart contract validators.

Multi-language module 470 could support multiple languages of development (inside or outside of the blockchain technology). Multi-language module (470) may support multiple languages for client dialogue (e.g. written and spoken).

“Resource manager module 475 can schedule, monitor and manage resources for service nodes 130 or distributed consensus network 140. Resource manager module 475, for example, may monitor storage resources, computing resources (CPU or GPU), clients and connections, as well as bandwidth. To determine if scaling is necessary for one or more resources.

“Services index module480 may advertise the location of services (e.g. a network address) or provide?gossip?” “Services index module 480 may advertise where services are hosted (e.g., a network address) and provide?gossip?

“Message broker module 485 could provide secure communications between nodes (e.g. service nodes 130), between the data centers and with outside agents/clients. The message broker module 485 can also offer non-blocking messaging among micro-services. It may provide well-known queues, allow for adding, altering, and removing services without code changes or the operation with other services. It can also handle service failures and other aberrant state transitions.

“The FIG. These are not limited examples. Framework 330 may contain different modules or more in other implementations. In some cases, one or more framework modules 405-485 can be broken down into multiple modules, or combined with other framework modules.

“FIG. “FIG. Part 500 of the network may contain micro-services platform 124, distributed consensus network 140, client device 150, and portion 500 of network environment 100.

“As shown at FIG. 5. An application 310 running on client device 150 could submit a microservice API call510 for a specific micro-service that is accessible through microservices platform.124. Micro-service API call 511 may identify a specific micro-service that uses blockchain. Micro-service API call510, for example, may request transaction authentication, authorization, new ledger entry, and other services as part of a larger service. Application 310 can invoke any number of relevant blockchain functions (e.g. micro-service(s), framework service(s), etc.) but does not have to invoke all of the functions. Micro-service platform 122.4 may respond to microservice API call 501. It may also identify multiple framework modules (e.g. any of the modules 405-485 mentioned above) that are required to answer to microservice API call 501.

“Microservices platform 124% may send one or more API calls to service nodes 130 or conduct ABI exchanges to obtain and/or provide the requested micro-service. Micro-services platform 124, for example, may submit a micro-services API call 520 to a specific instance of a component on a service 130. Micro-services platform 122.4 may submit multiple framework API calls 525 to a particular instance of a component on a service node 130. Micro-services platform 122.4 may submit an ABI request 525 simultaneously with or sequentially to framework API call 520. Each service node 130 may use a distributed architecture, and this architecture allows for an entity (e.g., application 310, micro-services platform 124, or another service node 130) deploying a service node 130 to pick and choose from an array of blockchain functions/micro-services resulting in deployment of dependent blockchain functions/micro-services as well (i.e., the dependency list is inherent to the micro-service and need not be specified by the entity deploying the service node).”

“Service node 130 might receive ABI request 525 or framework API call 522, and may implement blockchain protocols in response to requests from microservices platform 124. FIG. 6 describes blockchain activity 530. 6 is a diagram that illustrates exemplary logical elements for managing a block chain transaction. These logical components can be found in a service node 130. They may be implemented as either a single network device, or a distributed one. FIG. Referring to FIG. 6, data from API call 525 and/or ABI request 525 can be registered as transactions in distributed consensus network 140. Each active service node 130 in the distributed consensus network 140 collects a transaction queue. Block processing units 610 at each service node 130 can group transactions into blocks. A mining unit 615 may also perform operations such as linking new blocks to cryptographic hashes of previous blocks, or calculating proof-of-work with complex algorithms. required for record-keeping and verification.

“Still referring back to FIG. 6. The first service node 130 will find the answer to a new block and publish it (e.g. using block publisher620) to the 130 other service nodes. Each of the 130 other service nodes will validate (using transaction validity unit 625), store locally (in ledger storage630) and provide consensus (using consensus manger 635) to accept/reject the new block. FIG. FIG. 6. shows the logical components of service 130. However, other implementations may have fewer, more or different components. All service 130 may not contain an identical set.

“Returning at FIG. “Returning to FIG. A consensus among the 130 participating nodes may be indicated by framework API response 540 or ABI response 545, according to blockchain activity 530. Micro-services platform 12 may be able to receive both framework API response540 and ABI reply 545. Micro-services platform 124.1 may use framework API response540 and ABI reply 545 to generate micro-service API response 555. This is sent to client device 150 as application 310.

“FIG. “FIG.7″ is a diagram that illustrates the interactions of an application that accesses multiple micro-services using different framework items. Each micro-service (320) may use different modules of framework 330. Additionally, each application 310 could use different microservices 320, as well as a different number 320 of each microservice 320. FIG. 7 is an example. 7 shows one application 310-1 in relation to three of the micro-services, 320. Three micro-services (320) use items from framework 333. Application 310-1 uses one instance of microservice?A? 320-1 and microservice?C? 320-3 when using three instances micro-service?B? 320-2. Micro-service ?A? 320-1 uses smart contract 420 and blockchain APIs/ABIs 450. Each micro-service?B instance? 320-2 uses services index 480, smart contract 420, blockchain APIs/ABIs 450, and state channels 445. Micro-service ?C? Micro-service?C?320-3 uses smart contract 420 and key mangers 435.”

“The micro-service architecture allows each micro-service 320, to scale independently by creating new instances of the micro-service. Each micro-service can create as many instances as it needs. One micro-service 320 instance can fail and not affect other instances or services. Each micro-service 320 might use memory isolation/failure prevention technologies such as virtualization, protected memory, containerization, and others.

“FIG. “FIG.8″ is a diagram that illustrates the interactions between an application and multiple micro-services. A micro-service 320 may use another microservice to input its process. For example, micro-service ?A? As input to micro-service?C?, 320-1 is shown. FIG. 8. Application 310-2 in this case does not use microservice?A? 320-1 directly.”

“Also, in the example FIG. 8, micro-service ?D? 8, micro-service?D? 320-4 has 100 instances, while micro-service?B? has three. Hyperscale scenarios such as FIG. 8 may be limited by the availability of resources and the ability to track and manage them. Each micro-service 320 can be scaled as required using the micro-service architecture. A micro-service 320, for example, can be scaled down and up as the demand increases or decreases. Service nodes 130 of the distributed consensus network 140 can scale memory, storage and GPU as well as the number or instances.

“FIG. 9. This flow diagram shows an example process 900 to implement blockchain micro-services. Process 900 can be executed by micro-services platform 124. Another implementation may use some or all the process 900 by another device, or group of devices. This includes or excludes devices in provider network 120.

“Process 900 could include receiving a microservices API call from an application that requests a service of a blockchain-based tech (block 910). Application 310 may result in micro-service API calls 510. Micro-service API Call 510 can be received at microservices platform 124. A framework module 330 may be required to execute the requested micro-service.

“Process 900 could also include the sending of a framework API request to initiate a module in the participating nodes (block 920) Micro-service API call 515 may result in micro-service platform 124 sending one or more framework API requests 520 to 130 to execute a module. (e.g. one or more modules 405-485 of framework 330). A framework module can include an activity, transaction or other information that requires consensus from all 130 service nodes 140 in distributed consensus network 140 who are participating in the micro-service.

“Process 900 could also include one or more responses to framework API calls (block 930) from participating nodes. Service nodes 130 might perform a blockchain activity (530) in response to API call 522. A transaction may be published and the consensus of all 130 service nodes to complete the blockchain activity 530. One or more service nodes 130 may provide the result of blockchain activity 53 to micro-services platform 124.

“Process 900 could also include generating, based upon the responses to the framework API callings, a reply (block 940) to the first API call. Micro-services platform 12 may, for example, compile microservice response 55 and send it to application 310. The process 900 can be repeated for multiple microservice API calls from different applications 310 and 310.

“A blockchain micro-services framework provides multiple microservices that are based on blockchain technology for a variety different first-party, hosted and development applications. The micro-services platform also has attributes that allow for distributed, hosted, and built blockchain technologies. These micro-services are customizable and can be used to build additional micro-services or foundations for other applications.

The blockchain micro-services framework permits fundamental changes to blockchain technology for one module (e.g. one of modules 405-485), rather than changes across the entire system and corresponding apps. The blockchain micro-services framework encourages developers to create code that is more interoperable, transparent, and modular. Implementing micro-services-based blockchain functions may make it easier to create new services that can be assembled from micro-services that are loosely connected. An index of microservices libraries can be accessed by any existing or new application in one implementation.

“The above description of implementations is intended to provide illustration and description but not to be exhaustive nor to limit the invention to its specific form. You can make modifications and vary the teachings. These modifications are also possible based on the practice of the invention. A series of blocks has been shown in FIG. 9), the order of the blocks can be changed in other embodiments. Non-dependent blocks can be executed in parallel.

“Certain of the features discussed above can be implemented as?logic?” Or a ‘unit? One or more functions. This logic/unit may contain hardware such as processors, microprocessors or application-specific integrated circuits. It could also include software or a combination thereof.

“The aforementioned embodiments may collect, store, or employ personal data provided by individuals. It should be understood that such information will be used in accordance to all applicable laws regarding protection of personal data. The individual may consent to the collection, storage, and use of such information, such as through well-known?opt in?. You can also opt-out or opt-in to such information. Processes that may be applicable to the specific situation and type of information. Personal information can be stored and used in a secure manner that is appropriate for the information. This could include anonymization and encryption techniques for sensitive information.

“Use ordinal terms such?first? ?second,? ?third,? The claim element to be modified is referred to as “third”.

“No element, act or instruction in the present application description should be considered critical or essential to an invention, unless it is explicitly stated as such. The article?a? is also used herein. The article?a? soll also include at least one item. The phrase “based on” also means “based on?” Further, the phrase?based on? is meant to be?based at least in part? Unless otherwise stated.

“Various preferred embodiments have been described in the preceding specification with reference to the accompanying illustrations. However, it will be apparent that modifications and additions can be made to the specification. Additional embodiments could also be implemented without departing from its wider scope as described in the claims. Accordingly, the specification and drawings should be considered in an illustrative not restrictive sense.

Click here to view the patent on Google Patents.