DESC:RESERVATION OF RIGHTS
A portion of the disclosure of this patent document contains material, which is subject to intellectual property rights such as, but are not limited to, copyright, design, trademark, IC layout design, and/or trade dress protection, belonging to Jio Platforms Limited (JPL) or its affiliates (herein after referred as owner). The owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights whatsoever. All rights to such intellectual property are fully reserved by the owner. The present disclosure may pertain to 3GPP specifications such as for example, 3GPP TS 29.198-04-5, version 9.0.0, Release 9.

TECHNICAL FIELD
[001] The present disclosure relates to a method and a system for providing support for digital signature verification and consensus capability in a blockchain platform, and more particularly, to method and system for digital signature verification and consensus in a permissioned private blockchain platform.

BACKGROUND
[002] Computing systems are often at risk of malware attack by applications that intend to steal or destroy data, or run destructive or intrusive programs thus compromising confidentiality, integrity, availability of user data, applications, or operating system. Most of the threats are malware-based that attempt to infect hosts by installing their malicious code and executing functions to steal their data or perform other harmful activities. Other than this, unauthorized application besides malware, if not dealt with, can introduce un-managed vulnerable software in the system, which can then be used by attackers to exploit hosts and further compromise them.
[003] Known methods in the art, to resolve these concerns, replicated the work across nodes, to independently make a determination, and record in a ledger. Blockchain systems provide support for processing endorsements across stakeholders, with the ability to process transactions at high throughput for such Internet of Things (IoT) data streams, in addition to supporting immutability with hash chaining, and recording information across stakeholders in a shared ledger.
[004] A blockchain system also needs to provide support for consensus across participating nodes before transaction data information is committed to each node’s respective ledgers. Consensus-based processing systems in blockchain system realizations may typically utilize the Practical Byzantine Fault Tolerant (PBFT) consensus algorithm across N participating nodes or variations of the same that can typically handle at most f system faults or f malicious nodes where N=3f+1. Different consensus algorithms are used in different types of blockchain networks such as Proof of Work (PoW) algorithm in Bitcoin where miners attempt to solve a cryptographic problem followed by validation of a proposed solution by participating nodes, or Proof of Stake (PoS) algorithm in Ethereum that leverages validators that have adequate stake in the system.
[005] Hyperledger Fabric platform (version 1.0 and later) has adopted a simulate-order-validate & commit model for blockchain transaction processing, with endorsement processing, and transaction ordering, followed by peers validating transactions and committing transactions to their respective ledgers. Hyperledger Fabric platform attempts at fast probabilistic consensus across nodes to add new transactions to a directed acyclic graph of transactions. The more recent Ocean protocol utilizes a Proof of Authority (PoA) consensus protocol across a known set of validators in a permissioned context. In all of these approaches, a set of nodes participate in validating a transaction and arriving at a consensus in the blockchain system.
[006] A large number of IoT devices are expected to be supported thereby leveraging massive Machine Type Communications (mMTC) in 5G networks. Most IoT data streams are delay-tolerant with small-sized packet data. Data from wearable sensors may be only a few bytes in length, whereas smart meter readings could be a few tens of bytes to a few hundreds of bytes in length. Infrequently transmitted healthcare data for remote telehealth, such as a Magnetic Resonance Imaging (MRI), may be as large as 8 GB. On the other hand, data-sizes for video sensors may vary significantly depending on the resolution of the sensors and the video frame rate. For such devices, one will require secure automated processing of data streams to take fast decisions that meet a desired policy, where such a policy can be governed by multiple stakeholders.
[007] Healthcare and wearable sensors may require automated processing to determine a change in the vitals associated with a patient thereby triggering a need for immediate care. Video surveillance data may require immediate processing to determine any anomalous behaviour at a location for security, or to assist in law enforcement to identify a lost child or vehicle, or to monitor the wearing of masks. Privacy regulations such as General Data Protection Regulation (GDPR) would need to be considered when processing user data. Tracing affected patients during a pandemic can have an impact on user privacy although it can help with providing additional safety in communities.
[008] Existing systems do not have a neutral entity that serves all nodes to perform tasks and hence there is no delay-tolerant transaction pre-processing at such a neutral node operating in a Virtual Machine (VM) or a container in a virtualized deployment scenario. Depending on the context in which IoT data is generated, existing systems also do not have automatic process policies associated with the data, along with endorsements from different stakeholders such as consent from users, verification by a regulatory authority, or endorsements from service providers. As IoT data streams traverse emerging virtualized infrastructure, the existing systems do not have capabilities to provide secure automated data processing such that relevant microservices may be dynamically instantiated as needed.
[009] There is no system with submission of a ready transaction to a transaction processing layer in a vDLT (virtual Digital Ledger Technology) / blockchain platform. In addition, the systems do not support hierarchical user-level signed consensus processing. Neither do the systems support a node-level signed consensus processing prior to submission to the blockchain platform for recording in a blockchain/vDLT ledger. The consensus applied is similar at different levels. There is no multi-level processing along with multi-level sharing and load balancing. Traditionally distributed consensus processing is performed across all N nodes in a blockchain network However N can be large so that the replicated processing may consume a lot of energy.
[0010] Hence, there is a need in the art, to provide for a multistage consensus processing system followed by transaction preparation and signature authorization.

OBJECTS OF THE PRESENT DISCLOSURE
[0011] It is an object of the present disclosure to provide for a neutral-entity-based processing for digital signatures, policy verification, and consensus processing.
[0012] It is an object of the present disclosure to provide digital signature verification for transactions across stakeholders.
[0013] It is an object of the present disclosure to provide a consensus performed on decrypted signed data across endorsers – this provides greater trusted consensus.
[0014] It is an object of the present disclosure to provide simple, custom, hybrid policy support with a policy expression language.
[0015] It is an object of the present disclosure to provide support for hierarchical processing for user-level processing followed by node-level processing.
[0016] It is an object of the present disclosure to provide a system that enables layered delay tolerant Transaction pre-processing prior to transaction submission for recording to a blockchain / vDLT ledger.
[0017] It is an object of the present disclosure to provide a system that creates and manages digital certificates for stakeholders and users.
[0018] It is an object of the present disclosure to provide cached digital certificates, IP addresses, transaction policies.
[0019] It is an object of the present disclosure to provide concurrent processing for faster processing.
[0020] It is an object of the present disclosure to provide energy optimized processing by utilizing a common central entity relative to replicated processing across nodes in a blockchain/DLT platform.
[0021] It is an object of the present disclosure to provide delay tolerant processing.
[0022] It is an object of the present disclosure to provide multi-stage transaction processing with routing/sharding/load-balancing followed by transaction preparation followed by single PrimaryDSA (Primary Digital Signature Authorization) consensus processing or multiDSA (Multiple Digital Signature Authorization) consensus processing.
[0023] It is an object of the present disclosure to provide an overall transactions authorization and signed consensus processing can be utilized recursively for user level processing followed by node level processing in a vDLT/blockchain system.

SUMMARY
[0024] This section is provided to introduce certain objects and aspects of the present invention in a simplified form that are further described below in the detailed description. This summary is not intended to identify the key features or the scope of the claimed subject matter.
[0025] In an aspect, the present disclosure provides a system for signature-based verification of an executable set of instructions prior to execution. The system receives, from one or more devices, the executable set of instructions comprising an encrypted signature corresponding to a policy data and obtained from a first hash value of a code segment data of the executable set of instructions. Further, the system decrypts the encrypted signature of the executable set of instructions to recover the first hash value. Further, the system computes a second hash value corresponding to the code segment data of the executable set of instructions. Further, the system compares the recovered first hash value and the computed second hash value. Furthermore, the system verifies the decrypted signature against the policy data and executes the executable set of instructions, wherein the verification of the decrypted signature against the policy data and the execution of the executable instructions are based on the comparison of the recovered first hash value and the computed second hash value.
[0026] In an aspect, the present disclosure provides a method for signature-based verification of an executable set of instructions prior to execution. The method includes receiving, by a processor, from one or more devices, the executable set of instructions comprising an encrypted signature corresponding to a policy data and obtained from a first hash value of a code segment data of the executable set of instructions. Further, the method includes decrypting, by the processor, the encrypted signature of the executable set of instructions to recover the first hash value. Further, the method includes computing, by the processor, a second hash value corresponding to the code segment data of the executable set of instructions. Further, the method includes comparing, by the processor, the recovered first hash value and the computed second hash value. Furthermore, the method includes verifying the decrypted signature against the policy data and executing the executable set of instructions, by the processor, wherein the verification of the decrypted signature against the policy data and the execution of the executable instructions are based on the comparison of the recovered first hash value and the computed second hash value.

BRIEF DESCRIPTION OF THE DRAWINGS
[0027] The accompanying drawings are included to provide a further understanding of the present disclosure, and are incorporated in and constitute a part of this specification. The drawings illustrate exemplary embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The diagrams are for illustration only, which thus is not a limitation of the present disclosure.
[0028] In the figures, similar components and/or features may have the same reference label. Further, various components of the same type may be distinguished by following the reference label with a second label that distinguishes among the similar components. If only the first reference label is used in the specification, the description is applicable to any one of the similar components having the same first reference label irrespective of the second reference label.
[0029] The diagrams are for illustration only, which thus is not a limitation of the present disclosure, and wherein:
[0030] FIG. 1A illustrates exemplary architecture (100) in which or with which proposed system may be implemented, in accordance with an embodiment of the present disclosure.
[0031] FIG. 1B illustrates exemplary network architecture (109) in which or with which proposed system may be implemented, in accordance with an embodiment of the present disclosure.
[0032] FIG. 2 illustrates an exemplary representation (200) of a computing device (102) for signature-based verification of an executable set of instructions, in accordance with an embodiment of the present disclosure.
[0033] FIG. 3A-3D illustrate exemplary representation (300) of key features associated with the system, in accordance with an embodiment of the present disclosure.
[0034] FIG. 4A-4D illustrate exemplary representations (400) of components involved to achieve a distributed consensus state that enables a one or more nodes in a blockchain network to reach an agreement related to the validity of a transaction information being processed in accordance with an embodiment of the present disclosure.
[0035] FIG. 5 illustrate exemplary representation (500) of the Transaction Authorization and Signed Consensus Processor (TASCP) module (106), in accordance with an embodiment of the present disclosure.
[0036] FIG. 6A-6D illustrates exemplary representation of signature verification overview in accordance with an embodiment of the present disclosure.
[0037] FIG. 7 illustrates an exemplary representation (700) of signature verification in Hyperledger fabric platform for comparison in accordance with an embodiment of the present disclosure.
[0038] FIG. 8 illustrates an exemplary computer system (800) in which or with which embodiments of the present disclosure may be utilized in accordance with embodiments of the present disclosure.
[0039] FIG. 9 illustrates exemplary method flow chart (900) depicting a method for signature-based verification of an executable set of instructions prior to execution, in accordance with an embodiment of the present disclosure.

DETAILED DESCRIPTION
[0040] In the following description, for the purposes of explanation, various specific details are set forth in order to provide a thorough understanding of embodiments of the present disclosure. It will be apparent, however, that embodiments of the present disclosure may be practiced without these specific details. Several features described hereafter can each be used independently of one another or with any combination of other features. An individual feature may not address all of the problems discussed above or might address only some of the problems discussed above. Some of the problems discussed above might not be fully addressed by any of the features described herein.
[0041] The ensuing description provides exemplary embodiments only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the exemplary embodiments will provide those skilled in the art with an enabling description for implementing an exemplary embodiment. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth.
[0042] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood by one of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.
[0043] Also, it is noted that individual embodiments may be described as a process which is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be re-arranged. A process is terminated when its operations are completed but could have additional steps not included in a figure. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination can correspond to a return of the function to the calling function or the main function.
[0044] The word “exemplary” and/or “demonstrative” is used herein to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited by such examples. In addition, any aspect or design described herein as “exemplary” and/or “demonstrative” is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to preclude equivalent exemplary structures and techniques known to those of ordinary skill in the art. Furthermore, to the extent that the terms “includes,” “has,” “contains,” and other similar words are used in either the detailed description or the claims, such terms are intended to be inclusive—in a manner similar to the term “comprising” as an open transition word—without precluding any additional or other elements.
[0045] Reference throughout this specification to “one embodiment” or “an embodiment” or “an instance” or “one instance” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrases “in one embodiment” or “in an embodiment” in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
[0046] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items.
[0047] The present disclosure relates to a method and system for signature-based verification of an executable set of instructions prior to execution at a computing device.
[0048] The disclosed embodiments allow a trusted entity to reach out to stakeholders to seek endorsements, validate the endorsements based on a policy, and also determine a consensus associated with the data. Further, the disclosed embodiments cache digital certificates, IP addresses of stakeholders, and policy associated with transactions to enable faster processing. Further, the disclosed embodiments also perform concurrent processing using available processors to accomplish the tasks. By relying on a single trusted entity to do the work in a permissioned private blockchain setting, the processing costs may be reduced relative to distributed processing and replicated processing across multiple nodes in a blockchain system. The disclosed embodiments may also allow recursive utilization of the suggested system for Transaction Authorization and Signed Consensus Processing (TASCP) across users followed by TASCP across nodes. The system may enable quantum-safe consensus processing for utilization in virtualized deployments, particularly for IoT transaction streams.
[0049] In an embodiment, the trusted entity may be any individual, group of individuals or an organization that may offer one or more facilities or services related to, without limitation, to consumer products, telecom services, facility renting services, administrative services, and any other provider of facilities/services. Various other facilities and/or services may be included. The user may be an individual, group of individuals or an organization that may be recipient of any or a combination of above-mentioned facilities and/or services, such that the user may be liable to make a transaction through a set of instructions and that transaction needs to be verified.
[0050] In an embodiment, a distributed ledger may be implemented in a blockchain network. The distributed ledger may be integrated with an implementation of endorsements. The endorsements may be generated and updated for ease of reference of the service providing entity and the stake holder. The term “endorsements” may refer to a digital transaction which may be accessed via computing or electronic devices and automatically generated and/or updated based on information received from, for example, the user, entity, one or more nodes associated the distributed ledger and other such sources.
[0051] FIG. 1A illustrates an exemplary architecture (100) in which or with which proposed system can be implemented in accordance with an embodiment of the present disclosure. As illustrated in FIG. 1, a computing device (102) may be used for verification and validation of an executable set of instructions prior to execution. Based on the successful verification, the set of instructions may be allowed to be executed, wherein the verification can happen at a Transaction Authorization and Signed Consensus Processing (TASCP) module (104) of the computing device (102). The computing device (102) is a part of a blockchain network that comprises a plurality of nodes one of which may be the computing device (102).
[0052] In an aspect of the present disclosure, a signature (162) may be added to an executable set of instructions (160) at one or more devices (150) against a predefined set of instructions (interchangeably referred to as policy number). The computing device (102) may receive the executable set of instructions (160) including the signature (162) from the one or more external device. Upon receipt, the computing device (102) may perform one or more functions at a TASCP module (104) and distribute the executable set of instructions across a plurality of processing modules (interchangeably referred to as nodes) associated with the TASCP module (104). In an embodiment, each node may conduct verification of the signature against the policy number. Upon successful verification, the executable set of instructions (160) may be the forwarded to a consensus processing module of the TASCP module (104) for further verification and endorsement.
[0053] In an embodiment, the computing device (102) may receive the executable set of instructions (160) from the one or more external devices (150) in form of data packets over a communication network. In another embodiment, the computing device (102) may receive the executable set of instructions (160) from the external device (150) via a hardware that can transfer the set of instructions to the computing device (102) by one or more known means. In an embodiment, the external device (150) may perform the addition of signature (162) to the executable set of instructions (160) by generating a first hash value of the code segment of the executable set of instructions (160) through a private key. In an embodiment, the signature can be added to the executable set of instructions (160) using an offline set of instructions associated with the external device (150).
[0054] In an embodiment, an endorsed first set of data packets may be transmitted to the computing device (102) via the nodes through a second set of data packets to allow executable set of instructions to be executed on the computing device (102).
[0055] In an embodiment, the signature (162) may be verified at the TASCP module (104) by decrypting the signature (162) wherein the hash value associated with the signature and the policy number may be stored in a secure memory associated with the TASCP module. In an embodiment, the term “set of instructions” may refer to any application running on any operating system of the computing device (102). The term executable “set of instructions” may refer to any executable application running on operating system of the computing device.
[0056] FIG. 1B illustrates exemplary network architecture (109) in which or with which proposed system may be implemented, in accordance with an embodiment of the present disclosure. As illustrated in the figure, the exemplary architecture (109) may be equipped with a computing device (102) operatively coupled to a one or more external devices (150) associated with a user (110). The user (110) may include a company, a university, a lab facility, a business enterprise, a defence facility, or any other secured facility.
[0057] The computing device (102) may be coupled to a quantum safe crypto server (106). The quantum safe crypto server (106) may also be operatively coupled to the one or more external devices (150) through a communication network (108).
[0058] In an exemplary embodiment, a communication network (108) may include, by way of example but not limitation, at least a portion of one or more networks having one or more nodes that transmit, receive, forward, generate, buffer, store, route, switch, process, or a combination thereof, etc. one or more messages, packets, signals, waves, voltage or current levels, some combination thereof, or so forth. A network may comprise by way of example but not limitation, one or more of: a wireless network, a wired network, an internet, an intranet, a public network, a private network, a packet-switched network, a circuit-switched network, an ad hoc network, an infrastructure network, a Public-Switched Telephone Network (PSTN), a cable network, a cellular network, a satellite network, a fiber optic network, some combination thereof.
[0059] In another exemplary embodiment, the quantum safe crypto server (106) may include or comprise, by way of example but not limitation, one or more of: a stand-alone server, a server blade, a server rack, a bank of servers, a server farm, hardware supporting a part of a cloud service or system, a home server, hardware running a virtualized server, one or more processors executing code to function as a server, one or more machines performing server-side functionality as described herein, at least a portion of any of the above, some combination thereof.
[0060] In an embodiment, and as shown in the block diagram 200 in FIG. 2, the computing device (102) can include one or more processors (202) coupled with a memory (204). The memory may store instructions which when executed by the one or more processors (202), may cause the computing device (102) to perform one or more functions. The TASCP module (104) receives, from one or more devices, the executable set of instructions comprising an encrypted signature corresponding to a policy data, and obtained from a first hash value of a code segment data of the executable set of instructions. The encrypted signature may be added to the executable set of instructions by generating the first hash value of the code segment data of the executable set of instructions through a private key or by using an offline set of instructions associated with the one or more devices. Then the TASCP module (104) decrypts the encrypted signature of the executable set of instructions to recover the first hash value. Next, the TASCP module (104) computes a second hash value corresponding to the code segment data of the executable set of instructions and then compares the recovered first hash value and the computed second hash value. Thereafter, the TASCP module (104) verifies the decrypted signature against the policy data and execute the executable set of instructions, wherein the verification of the decrypted signature against the policy data and the execution of the executable instructions are based on the comparison of the recovered first hash value and the computed second hash value. The verification of the decrypted signature against the policy data and the execution of the executable set of instructions occurs if the recovered first hash value matches with the computed second hash value.
[0061] In an embodiment, if there is a mismatch between the first hash value and the second hash value, the executable set of instructions may not be allowed to be executed.
[0062] In an embodiment, a neutral-entity-based processing for digital signatures, policy verification, and consensus processing for transactions across stakeholders is described. The computing device (102) may support a combination of hierarchical processing for user-level processing through the TASCP module (104) and node-level processing via a plurality of nodes associated with the TASCP module (104). In an embodiment, the TASCP module (104) may create and manage digital certificates for stakeholders and users and may store the digital certificates, IP addresses, transaction policies and the like. Further, the TASCP module (104) may enable concurrent processing for faster processing. Further, the TASCP module (104) may also enable energy optimized processing by utilizing a common central entity relative to replicated processing across nodes in a blockchain/DLT platform.
[0063] In an embodiment, the TASCP module (104) may allow delay tolerant processing and multi-stage transaction processing. The multi-stage transaction processing may be executed by routing or sharding or load-balancing followed by transaction preparation and single PrimaryDSA or multiDSA consensus processing. The sharding may be performed across shard groups followed by load-balancing across DSA (Digital Signature Authorization) instances that is performed within a shard group.
[0064] In an embodiment, the TASCP module (104) may be utilized recursively for user level processing and node level processing in a vDLT/blockchain platform.
[0065] The one or more processors (202) may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, logic circuitries, and/or any devices that manipulate data based on operational instructions. Among other capabilities, the one or more processor(s) (202) may be configured to fetch and execute computer-readable instructions stored in a memory (204) of the computing device (102). The memory (204) may store one or more computer-readable instructions or routines, which may be fetched and executed to create or share the data units over a network service. The memory (204) may comprise any non-transitory storage device including, for example, volatile memory such as RAM, or non-volatile memory such as EPROM, flash memory, and the like.
[0066] The computing device (102) may also comprise an interface(s) (206). The interface(s) (206) may comprise a variety of interfaces, for example, interfaces for data input and output devices, referred to as I/O devices, storage devices, SCADA, Sensors and the like. The interface(s) (206) may facilitate communication of the computing device (102) with various devices coupled to it. The interface(s) (206) may also provide a communication pathway for one or more components of the computing device (102). Examples of such components include, but are not limited to, processing engine(s) (202) and database (210).
[0067] The one or more processors (202) may be implemented as a combination of hardware and programming (for example, programmable instructions) to implement one or more functionalities of the one or more processors (202). In examples described herein, such combinations of hardware and programming may be implemented in several different ways. For example, the programming for the one or more processors (202) may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the one or more processors (202) may comprise a processing resource (for example, one or more processors), to execute such instructions. In the present examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement the one or more processors (202). In such examples, the computing device (102) may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to the computing device (102) and the processing resource. In other examples, the one or more processors (202) may be implemented by electronic circuitry. In an aspect, the database (210) may comprise data that may be either stored or generated as a result of functionalities implemented by any of the components of the processor (202) or the processing engines (208).
[0068] In an exemplary embodiment, the processing engine(s) (208) of the computing device (102) may include endorsement phase module (212), Dynamic Consensus Phase module (214), ordering phase module (216), verification and commit phase module (218) and other engines (220), wherein the other engines (220) may further include, without limitation, data receiving engine, storage engine, computing engine, or signal generation engine. The computing device (102) may be implemented using any or a combination of hardware components and software components.
[0069] In an implementation, the computing device (102) may be accessed by applications residing on any operating system, including but not limited to, AndroidTM, iOSTM, and the like. Examples of the computing devices (102) may include but are not limited to, a portable computer, a laptop, a personal digital assistant, a handheld device, and a workstation. The computing device (102) can include one or more input devices connected thereto, wherein the input device can include a touch pad, touch enabled screen of a computing device that may form a part of the computing device such that it forms part of the computing device (104). In another embodiment, the input device connected to the computing device (104) can be in the form of an externally connected device or peripheral device including, but not limited to, a keyboard, a mouse and the like. The computing device (102) may include an interface, which may have a display.
[0070] In an embodiment, transaction policy to gather and verify endorsements, IP addresses, Digital Certificates required for signature verification to reach out to different node endorsers are cached at DSA instances which may help with faster processing. In an embodiment, all transactions may be processed by the primary DSA microservice. Alternatively, a plurality of instances of the primaryDSA may be used to scale the availability of the microservice. Transactions may be prepared by the Primary DSA if not already prepared.
[0071] In an embodiment, a signed consensus across the nodes may be performed by the primaryDSA. Faster cached processing with cached digital signatures, cached transaction policies, cached node IP addresses may be enabled at the primaryDSA. In an embodiment, a secondaryDSA microservice may serve as an active standby for fault tolerance. A plurality of primaryDSA instances may be created if required with transaction sharding (partitioning) across the plurality of primaryDSA instances. Sharding may be performed based on the use cases/tenants supported by the primaryDSA, so that the caching requirements may be distributed and only use-case/tenant specific information may be cached at the primaryDSA instance.
[0072] In an embodiment, sharding may be performed by a blockchain router, that may be a node in the blockchain network. Alternatively, a hierarchical consensus with consensus across the DSA instances may be invoked if desired by the blockchain router.
[0073] In an exemplary embodiment, the blockchain router may perform at least two-levels of transaction partitioning. In an embodiment, a first-level blockchain router shards transactions across the shard groups of the DSA instances based on a transaction sharding policy across any or a combination of tenants, use-cases, sharding-contexts and the like.
[0074] In an embodiment, a second-level load blockchain router may balance and partition transactions across the DSA instances within a shard group for a given any or a combination of tenant, use-case, sharding-context and the like. Traditionally, a distributed consensus processing may be performed across all N nodes in a blockchain network. However, N may be large so that the replicated processing may consume a lot of energy. The DSA microservice instances may be used to enable fault-tolerant and replicated consensus processing where k < N, where N is the number of participating nodes. This enables low energy consensus processing across DSA microservice instances in a vDLT / virtualized deployment scenario while enabling distributed consensus.
[0075] FIG. 3A illustrates exemplary representation (300) of key features associated with the TASCP module (104), in accordance with an embodiment of the present disclosure.
[0076] As illustrated in the figure, the TASCP module (104) may first ensure that a user signs a certificate signing request and issues a digital certificate (302). The signed digital certificates may be verified (304) with a configured policy and may then ensure data consensus (306) by verifying all signatures related to the configured policy through a policy expression language module that may include operators, operands and logical operators. If the signatures are not verified through the consensus, then the issued certificate may be revoked (308).
[0077] FIG. 3B illustrates a block diagram 309 that depicts three phases in a TASCP module (104). The three phases may include an endorsement phase (310), an ordering phase (312), and a validation and commit phase (314). The endorsement phase (310) may endorse a peer node execution of a smart contract independently after receiving a transaction from an external application (316) coupled to a blockchain client application (318) and generate read-write sets for the transaction. The ordering phase (312) may arrange the transaction into well-defined sequence to generate a block (312a) and save it to a ledger (312b) of an orderer (312c). The orderer (312c) may share the block (312a) with a peer (314a). The peer (314a) may then perform a validation check to verify the endorsements (VSCC) (314b) and read-write sets conflicts (MVCC) (314c) before committing to a ledger (314d).
[0078] The TASCP module (104) may further include, in an aspect (319), a dynamic consensus phase (320) between the ordering phase (312) and the validation and commit phase (314) that may perform a consensus and policy verification. Alternatively, in an embodiment, as illustrated in Fig. 3D (321), a dynamic consensus phase (320) between the endorsement phase (310) and the ordering phase (312) is depicted. The consensus as depicted in FIGs. 3B and 3C may be performed across a network of nodes that may be referred to as DistC (Distributed Consensus) nodes in the TASCP module (104).
[0079] FIG. 4A-4D illustrate exemplary representations (400,) of components involved to achieve a distributed consensus state that enables the nodes in the blockchain network to reach an agreement related to validity of a transaction information being processed in accordance with an embodiment of the present disclosure.
[0080] As illustrated in FIG. 4A, in an embodiment, the TASCP module (104) may include a single node server instance (also referred to as a DistCNode) that may run a local intra-node consensus algorithm. The local intra-node consensus algorithm may ensure that a transaction has enough endorsements to be committed based on a configured policy. If required, the local intra-node consensus algorithm may be executed to request the required endorsers for their endorsements based on a transaction type according to the configured policy before starting a consensus verification. Such a node instance may be hosted in a container or a virtual machine in virtualized data centre environments. The TASCP module (104) may also include a first participating node (402) (interchangeably referred to as a proposer node) in the blockchain network which initiates the transaction by signing a payload using a private key. Any one amongst the N participating nodes (404) in the blockchain network may propose the transaction. The transactions may be submitted in the blockchain network by a plurality of application layer nodes that interact with the participating nodes in the blockchain network.
[0081] In an embodiment, the TASCP module (104) may also include a second participating node (404) (interchangeably referred to as an endorser node) in the blockchain network. The endorser node (404) may sign the requested endorsement using the private key. The endorser node (404) corresponds to a configured policy. A transaction may have one or more endorsers. The endorser node (404) may also be the proposer node (402) and vice-versa.
[0082] In another embodiment, a DistC-Node may have a third node (406) (interchangeably referred to as a digital signature verifier) that may verify a quantum-safe digital signature efficiently. In an embodiment, a policy expression analyser (408) may be coupled to the TASCP module (104) to analyse the configured policy for a transaction to confirm whether an endorsement or a plurality of endorsements for a transaction meets the configured policy criteria for the transaction.
[0083] In an embodiment, the TASCP module (104) may further include a DistC Consensus Node List (CNL) (410). A DistC-Node server may be configured with the DistC CNL which may be a plurality of DistC-Node servers (K). The plurality of DistC-Node servers (K) may be utilized for a distributed inter-node consensus in the TASCP module (104). With respect to the CNL (410), a DistC system may have a dynamically configurable number (k) of instances that may be utilized for a consensus where . The number k may vary depending on the degree of fault-tolerance and trust required in the TASCP module (104).
[0084] In an embodiment, a primary requirement in a blockchain network is to validate endorsements associated with a transaction, and any policy or constraints associated with the transaction. Validation of the transaction may be performed by the nodes in the TASCP module (104) independently. The validation of the transaction by the nodes independently reflects a first level of intra-node validation checking across transaction endorsers. This may be performed by computing a hash associated with the transaction data for a particular transaction . The hash may be compared with a decrypted hash obtained by decrypting the digital signature provided by an endorser m using a public key of an endorser for the endorser m. Then the TASCP module (104) may verify that all endorsers may be signatories to the same hash. A comparator function may be utilized across the endorsers to verify that the decrypted hash ) may be the same across the endorsers and matches the hash associated with the transaction data , where ) may be the endorsers required for a transaction . Let this be a verified hash at a single DistC-Node as .
[0085] The TASCP module (104) may perform a distributed consensus-based validation across k DistC-Node nodes. The distributed consensus-based validation across k DistC-Node nodes may be a k-DistC consensus where . The distributed consensus-based validation across k DistC-Node nodes may perform a second-level of consensus in the TASCP module (104) to verify that the k DistC-Node nodes may have agreed to the same hash by performing a comparison across where . If the DistC-Node capability is supported directly by just the N participating nodes in the blockchain network, then
[0086] In an example embodiment, k may be equal to the number of participating nodes in the TASCP module (104). However, there may also be a smaller value of where , or when is large. The k nodes that perform the k-DistC consensus may be a pre-defined subset of the participating nodes, where such a subset may be varied over time. Alternatively, the k nodes may be dynamically selected amongst the participating nodes. One may also choose the k DistC-Node nodes to be neutral and different from the blockchain participating nodes so that such an operation may be performed by independent neutral entities that may be entrusted to perform such a consensus-based validation task by the participating nodes. If k is small, then one may conserve the energy that is consumed for virtualized processing in a data center, where a value of k is chosen large enough such that it promotes greater trust and fault-tolerance in the system as needed, and yet, small enough so that unnecessary energy is not wasted for such processing while providing adequate trust and reliability in the execution. The design of such a DistC component for a blockchain system may be discussed in the subsequent section to help with distributed consensus for transaction validation. The k-DistC consensus may provide fault tolerance to the degree where faults could be byzantine in nature to handle malicious nodes or to handle hardware faults for high-availability in virtualized environments. Consensus may be derived in a hierarchical decentralized manner, where each of a set of k DistC-Node nodes perform the validation checking code independently and then share the results of their execution. These results may be verified to confirm that consensus is achieved across these k verifying DistC-Node nodes.
[0087] In an embodiment, as depicted in Fig. 4B (411) a digital signature authorizer (412) may have three main components that may be a Policy Verification module (412a), and a Signature Verification module (412b) and a Consensus Verification module (412c) for distributed consensus processing across a Trusted DistC Nodes List. As illustrated in FIG. 4C (413). The Proposer Node (402) and the Endorser Nodes (404) may interact with a Request Router (414) of the blockchain network to submit a proposed transactions or an endorsement to the DistC Node, for a distributed consensus.
[0088] In an embodiment, the Policy Expression Analyzer (408) handles policy-related processing aspects that may include a policy creation, a policy expression verification and an endorsement verification against a policy. A transaction policy may be configured using a Policy Expression Language (PEL) which may support a combination of Boolean logical operators to specify filters required for the endorsement verification.
[0089] In an example implementation, an Elastic Search database (416) may serve to store a configured policy as well as a digital certificate. The Signature Verifier (406) may use the digital certificate to verify an endorsement from an endorser against the configured policy. An LRU (Least Recently Used) cache may be used to cache the digital certificate and the configured policy for avoiding frequent reads from the Elastic Search database (416). A constraint may be specified as a policy to validate a signature for a specific transaction type. The DistC-Node instance may verify that the transaction has a valid digital signature from a configured endorsers based on a configured policy of the transaction. A simple policy merely specifies the number e of endorser digital signatures that may be required relative to a maximum number E of endorser digital signatures to validate the message. For a simplistic default policy, all e = E endorsements would be required for successful transaction processing in the blockchain network. Complex and custom policies may be configured in the TASCP module (104).
[0090] In addition to the Policy Verification module (412a), in an embodiment a DistC-Node may perform a quantum-safe intra-node validation processing with a signature verifier verification module (412b) to ensure that the data is consistent for all endorsements from endorsers. In this regard, the DistC-Node may use a comparator module such that collected endorsements may be sent to the comparator which compares the data hash of all the endorsements, ensuring that all the endorsers have endorsed (by signing) the same transaction data and to ensure that the data validation is achieved across endorsers as illustrated in FIG. 4C. For quantum safety, the DistC-Node may support different hashing algorithms with increasing dimensional complexity. Using a principle of superposition, a quantum computer with q qubits may perform concurrent quantum operations of the order 2q , that may allow it to explore different possible solutions to a given complex problem such as prime-factorization or to compute the discrete logarithm over large finite groups.
[0091] At present, quantum computers support around 49-72 qubits, and such computational capacity continues to increase over time. For example, quantum computers from Intel, IBM, and Google, support, 49 qubits, 53 qubits, and 53-72 qubits respectively. A quantum computer can target a d-bit hash system with one-third of the qubits with a “birthday” attack. A 256-bit hash may be targeted with 85? ˜ 86 qubits, whereas a 384-bit hash may be targeted with 128 qubits, and a 512-bit hash may be targeted with 170? ˜ 171 qubits. Longer hash sizes increase quantum safety in a blockchain system. In that regard, different elliptic curve cryptographic algorithms are supported in the DistC-Node system, namely, ECDSA elliptic curves secp256r1, secp384r1, and secp521r1. The secp256r1 ECDSA elliptic curve uses a SHA 256 hash, with an elliptic curve private key of size 256 bits. The secp384r1 ECDSA elliptic curve uses a SHA 384 hash, with an elliptic curve private key of size 384 bits. The secp521r1 ECDSA elliptic curve uses a SHA 512 hash, with an elliptic curve private key of size 521 bits. The ECDSA digital signature that is generated is twice the size of the corresponding elliptic curve private key, so that the digital signatures for the curves secp256r1, secp384r1, and secp521r1, have sizes 512 bits, 768 bits, and 1042 bits respectively but not limited to the like.
[0092] FIG. 4D illustrates a block diagram representation (417) of a multi-DSA three-stage transaction processing that may include a first stage of load balanced distribution. The request router may function as a load balancer across the DSA microservice instances to balance the transaction processing load across the DSA instances (418). A second stage of processing may include a transaction preparation where a transaction is prepared with endorsements gathered based on transaction policy by an owning node (420). A third stage of processing may include hierarchical signed consensus that involves a first-level signed consensus performed within each DSA microservice instance (422). This may check if the transaction hash in the digital signature is the same across all the endorsements. To enable fault-tolerance/ replicated consensus across DSA microservice instances, a second-level consensus may be performed across the different DSA microservice instances (422). This may check that the transaction hash that was checked in the first-level consensus is the same across all DSA instances (424). Different techniques may be utilized to share information across nodes such as a direct broadcast to all nodes, or a tree-based broadcast or a multi-state gossip-based local broadcast with neighboring nodes. Communications between nodes may be performed in a synchronous or asynchronous fashion. Asynchronous communications may provide better performance as it may enable interleaving of computation and communication across the nodes. For example, while communications for consensus processing may be in progress asynchronously in the network across the nodes, these nodes may perform signature verification computational tasks for other more recently arrived tasks in the system. Thus, interleaving computations with communications may enable to obtain greater performance in the system.
[0093] FIG. 5 illustrates exemplary representation (500) of the transaction Authorization and Signed Consensus Processor (TASCP) module, in accordance with an embodiment of the present disclosure.
[0094] As illustrated, in an aspect, the DistC-Node (502) capability may be integrated with the capabilities of each of the participating blockchain nodes in a blockchain network (504) if desired. Alternatively, the DistC Node (502) may be utilized as an independent neutral entity for consensus processing in a blockchain network (504). The blockchain network (504) may receive inputs from different blockchain application sources that submit transactions via one or more participating nodes into the blockchain network (504). A request router (414) microservice within the DistC-Node may receive a one or more submitted transactions, load-balance the one or more submitted transaction processing tasks across the DistC-Node instances, and forward the one or more submitted transactions to one of the DistC-Node instances in the system that may serve as a primary node for processing the transaction. If an inter-node consensus is triggered, then an intra-node consensus may be processed on each of the k DistC-Node instances participating in a distributed consensus. The intra-node consensus outcome may be determined based on the required endorsements for a transaction type that meet the requirements of a configured policy for that transaction type. Subsequently, the outcome of intra-node consensus processing at each of the k DistC-Node instances may be exchanged in the system to determine at an inter-node consensus outcome. Based on the of the inter-node-consensus outcome, the transaction may be submitted for further processing in the blockchain network (504). Subsequently, the transaction may be appended to corresponding ledgers (506) on each of the blockchain nodes in the blockchain network (504).
[0095] In an embodiment, as soon as selected primary DistC-Node (404) for a submitted transaction has received required endorsements for the transaction, it may use the Consensus Node List (CNL) (410) and select a random set or a pre-configured set of k available servers to reach out for distributed consensus. Independent threads may be used to make parallel calls to each of the remaining (k - 1) DistC-Nodes (404) to initiate intra-node consensus processing in these (k - 1) DistC-Nodes. The main execution thread in the primary DistC-Node may not be blocked for consensus responses from the remaining (k – 1) DistC-Node instances. As other k DistC-Node (404) instances may be processing the endorsements, the execution thread in the primary DistC-Node (404) may use the Signature Verifier (406) (that runs locally on a DistC-Node) to concurrently verify that all endorsements ensuring the configured policy is met for all signatures. It may compute its own consensus result, so that intra-node consensus may be completed by the primary DistC-Node (404) that initiated the inter-node consensus processing. Concurrent or multithreaded execution may be utilized across different cores in a single DistC-Node (404) so that each of the cores processes different signature verification tasks concurrently to enable faster processing of signatures. Once the intra-node validation processing is completed by all k DistC-Nodes (404) independently, then these nodes (404) may share the outcome of their respective local processing, to enable a consensus to be reached across these k DistC-Node (404) instances. Each of the k DistC-Node (404) instances may attach their respective signatures, to allow any authorized entity to verify the realized k-DistC consensus at some future time if desired. FIGs. 6A-6D illustrate exemplary representations of signature verification overview in accordance with an embodiment of the present disclosure.
[0096] As illustrated in FIG. 6A, in an embodiment (600), different variants of the TASCP module (104) may be deployed. For example, a scalable primaryDSA may be utilized for a user-level TASCP processing with a DistC node to process a one or more user-level signatures. A distributedDSA with a network of DistC-nodes may be utilized for node-level TASCP processing but not limited to the like.
[0097] In an embodiment, as illustrated in FIG. 6A, the DistC nodes (404) in a network of DistC nodes may support a combination of verification of the one or more user-level signatures, followed by a node-level consensus. The DistC-nodes (404) may represent one or more organizations in a blockchain network. Alternatively, the DistC-nodes (404) may represent a neutral set of nodes that perform a consensus on behalf of the neutral set of nodes participating in a blockchain network (504). The one or more user-level signatures may be signatures of entities that may not directly participate in the blockchain network (504), but the signatures or endorsements may be required based on a transaction policy, where the signatures need to be verified.
[0098] Additionally, for a transaction authorization, the node-level signatures or endorsements may also be required to be gathered and verified followed by an inter-node consensus. A single node 1-DistC may verify the user-level signatures or a multi-node k-DistC may verify the signatures with the inter-node consensus. For example, a TASCP cluster (104) may be created across the nodes in a blockchain network (504) that may have a leader and one or more followers. The leader verifies a signature forwarded by the one or more followers. Alternatively, any form of a distributed synchronous or asynchronous consensus mechanism may be adopted by the TASCP cluster (104). The TASCP module (104) representing the TASCP cluster (104) of one or more consensus nodes may send one or more signed and verified transactions to an ordering node or an ordering network of nodes (604), which subsequently may send an ordered sequence of transactions to the blockchain network (504) to be committed to a shared ledger (504a). The blockchain network (504) may comprise a plurality of blockchain nodes that may share one or more distributed shared ledgers (504a) in the blockchain network (504).
[0099] In an embodiment, the node-level processing may be performed regardless of whether the user-level signature has been processed. A user-level signature processing may be optional and may be utilized if required for a given transaction. A node-level signature verification may involve gathering of endorsements of different participating nodes in the blockchain network, with verification of signatures. In a 1-DistC mode of operation, only signatures may be verified using an intra-node signature verification on a single DistC node. In a k-DistC mode of operation, signatures may be verified by k-DistC nodes that each perform the intra-node signature verification followed by the inter-node consensus across nodes. The k DistC nodes that may be selected for the inter-node consensus may be different from the nodes in the blockchain network, thus serving as a neutral entity that independently performs consensus on behalf of the blockchain network of nodes.
[00100] Alternately, the k DistC nodes (404) for the consensus processing may be selected from the participating nodes in the blockchain network. A hybrid selection may also be possible where some nodes that may be engaged in consensus may be selected from the participating nodes (404) in the blockchain network (504). Additional nodes (404) that may also be engaged in consensus may be selected from the neutral set of DistC nodes (404). The nodes (404) may engage in a synchronous or an asynchronous communication with one other to arrive at a consensus across nodes. A one or more consensus algorithms may be attempted by the nodes such as a PBFT (Practical Byzantine Fault Tolerance) algorithm, or a majority voting scheme, or based on the fraction of nodes in agreement, or a PoW scheme, or a PoS scheme, or a delegated PoS scheme, or a Raft-based consensus.
[00101] As illustrated, in an embodiment, the TASCP module (104) may include a signature verification, a data consensus, and a Raft-based TASCP cluster. For a Raft-based scheme, a leader may be elected using a randomized election process with majority voting for consensus. In an example, with a greater than 2/3rd majority for a byzantine consensus guarantee (N > 3f + 1, where N nodes engage in a consensus can manage f faults or less).
[00102] Additionally, N nodes may be one or more leaders concurrently for different transactions based on an allocation of a one or more arriving transactions by a load balancer. Thus, the TASCP module (104) may support the one or more leaders concurrently based on a set of transactions allocated to the node in the DistC-Node network. Also, different blockchain networks may be supported concurrently by a single neutral TASCP module (104) comprising a network of DistC processing nodes. Once the consensus may be achieved, then the transactions may be submitted for ordering before committing the transactions to a shared ledger to an ordering node or an ordering network of nodes. Different technologies may be possible for ordering such as a Kafka or Raft, or any alternate realization. Here the ordering node or the ordering network of nodes may receive the transactions after the consensus from the leader nodes for transactions in the TASCP module (104). Then the ordering node or the ordering network of nodes may produce a serial order for recording in a blockchain ledger. The orderer may process the transactions for multiple ledgers concurrently for different blockchain networks. If there is only one leader in the blockchain network always, then the leader may determine the ordering, so that an additional ordering network may not be required. In addition, a subset of nodes in the DistC network of nodes may function as the ordering network nodes as well, in which case the separate ordering network of nodes is not required. During an intra-node validation, all signatures that need to be verified for a transaction may be processed in a single batch of signatures submitted for verification to a signature verification thread in the system.
[00103] Additionally, all signatures for a group of transactions may be processed in a batch of tasks. Batch processing may help in improving performance by reducing the number of communications involved in assigning an overall task (in this case a batch of tasks) to a signature processing thread. Similarly, an inter-node consensus may be triggered for a batch of transactions to reduce the number of communications required for the consensus. In general, batch processing may be useful when an arrival rate of the transactions is high to extract the best performance in the system. It may also be useful to keep the arrival rate of transactions (?) lower than the service rate (µ) in the TASCP module (104) to reduce queueing delay.
[00104] The TASCP module (104) was implemented, and its performance was analyzed for both intra-node validation and inter-node consensus. Intra-node quantum-safe signature processing was studied at a single DistC-Node instance for an endorsement and policy verification based on one or more endorsements from a plurality of participating nodes in the blockchain network.
[00105] Concurrent processing across different cores on a single node was utilized to speed up processing of digital signatures at each DistC-Node instance. Subsequently, the inter-node distributed consensus across multiple DistC-Node instances was performed as well. Since a digital signature verification is one of the most critical and CPU intensive tasks in consensus verification, the performance of the system was studied and optimized with different elliptic curves secp256r1, secp384r1, and secp521r1.
[00106] A processing time for the digital signature verification was studied for different programming environments (Java, Golang and Node.js). Initial attempts for digital signature processing were performed using Java libraries for cryptographic operations, and optimizations for parallel processing and multithreading were also attempted. The results for all elliptic curves were low with the Java libraries at this time. Golang supports light-weight threads (goroutines) that are tuned for good concurrency. This performed quite well relatively to a corresponding Java-based implementation for the secp256r1 elliptic curve. However, the performance for the secp384r1, and secp521r1 elliptic curves was low with Golang digital signature verification libraries for these curves may not yet been optimized relative to the more popular secp256r1 curve. Node.js programming environment was found to be a good fit to process all three signature algorithms efficiently, as its cryptographic library (and that of OpenSSL which also performed well) appeared to be well-optimized for all three curves. At the time of testing the TASCP module (104), the crypto libraries of Node.js had served as a highly optimized environment. However, it may be noted that, the TASCP module (104) is compatible with the crypto libraries of other emerging software environments as well. Nonetheless, the TASCP module (104) is ideally compatible with JAVA Enterprise server that may be a microservices-based environment designed to provide quantum-safe crypto support. While elliptic curves of higher dimensions may have been used in the present disclosure, it may be noted that new cryptographic algorithms such as lattice-based algorithms mat be applied as well to study the processing time of the digital signature verification.
[00107] Table I shows performance and speedup results for digital signature verification with three elliptic curves as the number of cores was varied from 1 to 64 on a 64-core dedicated server machine with 2.4 GHz cores. Digital signature verification was performed using the Node.js-based cryptographic libraries for the 3 elliptic curves, secp256r1, secp384r1, and secp521r1. Performance in terms of transactions per second (TPS) decreases when the computation complexity associated with the elliptic curve cryptographic processing is increased. Performance (TPS) also increases with a number of cores used for a concurrent verification of digital signatures, with each core running a Node.js server that receives tasks for verifying digital signatures. An external load client was used to submit transactions into a node in the DistC-Node system.
[00108] Table II shows results for a similar study on a 64-core virtual machine in a cloud data center with similar cores. The performance results are slightly reduced which could be attributed to a lower vCPU core/system performance and/or due to shared resource (network/compute/memory) utilization in the cloud data center. The efficiency of utilization of cores appeared to diminish beyond 32 or 64 cores in both cases in Table I that shows the signature verification performance (TPS) and speedup results for three elliptic curves on a dedicated 64 core machine and table ii that shows signature verification performance (TPS) and speedup results for 3 elliptic curves on a 64-core cloud VM.
TABLE I
secp256r1 secp384r1 secp521r1
Cores TPS Speedup TPS Speedup TPS Speedup
1 3921 1.00 900 1.00 517 1.00
2 7802 1.99 1599 1.78 999 1.93
4 15588 3.98 3000 3.33 1787 3.46
8 25995 6.63 5987 6.65 3290 6.36
16 39922 10.18 11787 13.10 6321 12.23
32 59984 15.30 22951 25.50 12567 24.31
64 65983 16.83 25877 28.75 14995 29.00

TABLE II
secp256r1 secp384r1 secp521r1
Cores TPS Speedup TPS Speedup TPS Speedup
1 2999 1.00 799 1.00 504 1.00
2 4997 1.67 1499 1.88 800 1.59
4 8996 3.00 2999 3.75 1501 2.98
8 16993 5.67 5998 7.51 2999 5.95
16 29992 10.00 11495 14.39 5998 11.90
32 44072 14.70 18492 23.14 11782 23.38
64 48257 16.09 23975 30.01 14496 28.76

[00109] The performance with an end-to-end integration of different capabilities in a DistC-Node including the signature and policy verification was implemented in multiple instances of DistC nodes, along with support for inter-node consensus across such instances. The DistC node was realized using a 64-core virtual machine (VM) in a cloud data center. Different tests were run on a network of such VMs by varying different parameters. When considering k = 3 f + 1 to manage f faults in the system, one can see that the system can handle f =1 for k = 4, f =2 for k =7, and f = 3 for k =10. In a permissioned private blockchain system, the likelihood of concurrent hardware system failure occurring can be low, or the expected number of malicious nodes can be low, so that one can consider using only a small number of DistC-Nodes to realize distributed consensus in the system. This helps in reducing the energy utilization by not engaging all the nodes in a blockchain system to participate in consensus.
[00110] FIG. 6B illustrates an exemplary representation (601) of a network of DistC nodes (404) serving multiple vDLT/blockchain networks (504) concurrently. This is possible when the DistC network is realized as a neutral network of nodes (404) separate from the participating nodes in a blockchain network (504), so that one DistC network can serve multiple vDLT/blockchain networks at the same time. This also helps in sharing DistC network resources across multiple use-cases or vDLT/blockchain networks. Thus, better utilization of the computational/storage/networking resources of the nodes (404) in the DistC network may be achieved. It may also allow the DistC network to function relatively agnostic to use-case specific processing that may be accomplished by executing use-case specific smart contracts in the participating nodes in the blockchain networks (504). The DistC network (404) merely may require a digital signature after smart contract processing at a blockchain network node, so that the DistC network (404) may be agnostic to the actual use-case specific processing required, thus allowing it to serve multiple vDLT/blockchain networks (504) concurrently.
[00111] FIG. 6C shows the performance results obtained by studying the transactions per second obtained by varying the elliptic curve utilized for the digital signature processing with a given transaction (602). The transaction may include only one endorsement (digital signature) that needs to be verified. The TASCP module (104) provides superior performance in general for different number of nodes, with better performance if a lower number of nodes are used for distributed consensus. The performance also improves if a lower-dimensional elliptic curve is utilized. If a throughput delivered by a DistC-Node module is equivalent or better than other stages in a pipelined secure IoT data processing service chain in virtualized environments, then it may help in obtaining superior performance when a DistC-Node is instantiated. Based on these results, one may make an informed decision regarding a selection of the degree of quantum-safety required (based on a choice of the elliptic curve) or a degree of the fault tolerance required with an adequate choice of (k) DistC-Node instances for distributed consensus processing.
[00112] FIG. 6D illustrates a performance impact when a number of endorsements (E) per transaction is increased for k =7, and k =10 (603). It was observed that the performance decreases due to increased complexity of tasks per transaction with an increase in a number of endorsements that needed to be verified for a transaction. Similar trends were observed for other values of k as well as when the number of endorsements per transaction was varied.
[00113] FIG. 7 illustrates an exemplary representation (700) of signature verification in the Hyperledger fabric platform for comparison in accordance with an embodiment of the present disclosure. As illustrated, every peer node (702) verifies signatures independently after they receive transactions. Since all participating nodes (702) perform signature verifications, many signature verifications may be redundant and hence expensive which may be optimised in a permissioned network. In addition, the peer nodes (702) may not engage in any inter-node consensus after signature verification. Each peer node (702) may merely proceed to commit transactions to its corresponding ledger after it performs signature verification processing.
[00114] Thus, embodiments above describe batch processing across signatures for a transaction, and across transactions, benefits of asynchronous processing, interleaving of asynchronous communications for consensus with computations for digital signature processing, load balancing, ordering but not limited to the like.
[00115] FIG. 8 illustrates an exemplary computer system (800) in which or with which embodiments of the TASCP module (104) may be utilized in accordance with embodiments of the present disclosure. As shown in FIG. 8, computer system (800) can include an external storage device (810), a bus (820), a main memory (830), a read only memory (840), a mass storage device (850), communication port (860), and a processor (870). A person skilled in the art will appreciate that the computer system may include more than one processor and communication ports. Examples of processor (870) include, but are not limited to, an Intel® Itanium® or Itanium 2 processor(s), or AMD® Opteron® or Athlon MP® processor(s), Motorola® lines of processors, FortiSOC™ system on chip processors or other future processors. The processor (870) may include various modules associated with embodiments of the present invention. The communication port (880) may be any of an RS-232 port for use with a modem-based dialup connection, a 10/100 Ethernet port, a Gigabit or 10 Gigabit port using copper or fiber, a serial port, a parallel port, or other existing or future ports. Communication port (880 may be chosen depending on a network, such a Local Area Network (LAN), Wide Area Network (WAN), or any network to which computer system connects. Memory 830 can be Random Access Memory (RAM), or any other dynamic storage device commonly known in the art. Read-only memory (840) can be any static storage device(s) e.g., but not limited to, a Programmable Read Only Memory (PROM) chips for storing static information e.g., start-up or BIOS instructions for the processor (870). The mass storage (850) may be any current or future mass storage solution, which may be used to store information and/or instructions. Exemplary mass storage solutions include, but are not limited to, Parallel Advanced Technology Attachment (PATA) or Serial Advanced Technology Attachment (SATA) hard disk drives or solid-state drives (internal or external, e.g., having Universal Serial Bus (USB) and/or Firewire interfaces), e.g. those available from Seagate (e.g., the Seagate Barracuda 7102 family) or Hitachi (e.g., the Hitachi Deskstar 7K1000), one or more optical discs, Redundant Array of Independent Disks (RAID) storage, e.g. an array of disks (e.g., SATA arrays), available from various vendors including Dot Hill Systems Corp., LaCie, Nexsan Technologies, Inc. and Enhance Technology, Inc.
[00116] The Bus (820) communicatively couples processor(s) (870) with the other memory, storage and communication blocks. The Bus (820) can be, e.g., a Peripheral Component Interconnect (PCI) / PCI Extended (PCI-X) bus, Small Computer System Interface (SCSI), USB or the like, for connecting expansion cards, drives and other subsystems as well as other buses, such a front side bus (FSB), which connects the processor (870) to software system.
[00117] Optionally, operator and administrative interfaces, e.g., a display, keyboard, joystick and a cursor control device, may also be coupled to bus (820) to support direct operator interaction with a computer system. Other operator and administrative interfaces can be provided through network connections connected through the communication port (860). The external storage device (810) can be any kind of external hard-drives, floppy drives, IOMEGA® Zip Drives, Compact Disc - Read Only Memory (CD-ROM), Compact Disc-Re-Writable (CD-RW), Digital Video Disk-Read Only Memory (DVD-ROM). Components described above are meant only to exemplify various possibilities. In no way should the aforementioned exemplary computer system limit the scope of the present disclosure.
[00118] FIG. 9 illustrates exemplary method flow chart (900) depicting a method for signature-based verification of an executable set of instructions prior to execution, in accordance with an embodiment of the present disclosure. The method (900) may be described in the general context of computer-executable instructions. Generally, computer-executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform functions or implement abstract data types.
[00119] The order in which the method (900) is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method (900). Additionally, individual blocks may be deleted from the methods without departing from the scope of the subject matter described herein. Furthermore, the method (900) can be implemented in any suitable hardware, software, firmware, or combination thereof.
[00120] At block (902), the method (900) may include receiving, by a processor, from one or more devices, the executable set of instructions comprising an encrypted signature corresponding to a policy data, and obtained from a first hash value of a code segment data of the executable set of instructions.
[00121] At block (904), the method (900) may include decrypting, by the processor, the encrypted signature of the executable set of instructions to recover the first hash value.
[00122] At block (906), the method (900) may include computing, by the processor, a second hash value corresponding to the code segment data of the executable set of instructions.
[00123] At block (908), the method (900) may include comparing, by the processor, the recovered first hash value and the computed second hash value.
[00124] At block (910), the method (900) may include verifying the decrypted signature against the policy data and executing the executable set of instructions, by the processor, wherein the verification of the decrypted signature against the policy data and the execution of the executable instructions are based on the comparison of the recovered first hash value and the computed second hash value.
[00125] While the foregoing describes various embodiments of the invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof. The scope of the invention is determined by the claims that follow. The invention is not limited to the described embodiments, versions or examples, which are included to enable a person having ordinary skill in the art to make and use the invention when combined with information and knowledge available to the person having ordinary skill in the art.

ADVANTAGES OF THE PRESENT DISCLOSURE
[00126] The present disclosure provides for a neutral-entity-based processing for digital signatures, policy verification, and consensus processing.
[00127] The present disclosure provides for a digital signature verification for transactions across stakeholders.
[00128] The present disclosure provides for a consensus performed on decrypted signed data across endorsers – this provides greater trusted consensus.
[00129] The present disclosure provides for a simple, custom, hybrid policy support with a policy expression language.
[00130] The present disclosure provides for a support for hierarchical processing for user-level processing followed by node-level processing.
[00131] The present disclosure provides for a system that enables layered delay tolerant Transaction pre-processing prior to transaction submission for recording to a blockchain / vDLT ledger.
[00132] The present disclosure provides for a system that creates and manages digital certificates for stakeholders and users.
[00133] The present disclosure provides for cached digital certificates, IP addresses, transaction policies.
[00134] The present disclosure provides for concurrent processing for faster processing.
[00135] The present disclosure provides for energy optimized processing by utilizing a common central entity relative to replicated processing across nodes in a blockchain/DLT platform.
[00136] The present disclosure provides for delay tolerant processing.
[00137] The present disclosure provides for multi-stage transaction processing with routing/sharding/load-balancing followed by transaction preparation followed by single PrimaryDSA or multiDSA consensus processing.
[00138] The present disclosure provides for an overall transactions authorization and signed consensus processing can be utilized recursively for user level processing followed by node level processing in a vDLT/blockchain system.

,CLAIMS:1. A system for signature-based verification of an executable set of instructions prior to execution, the system comprising:
a processor;
a memory coupled to the processor, wherein the memory comprises processor executable instructions, which on execution, causes the processor to:
receive, from one or more devices, the executable set of instructions comprising an encrypted signature corresponding to a policy data, and obtained from a first hash value of a code segment data of the executable set of instructions;
decrypt the encrypted signature of the executable set of instructions to recover the first hash value;
compute a second hash value corresponding to the code segment data of the executable set of instructions;
compare the recovered first hash value and the computed second hash value; and
verify the decrypted signature against the policy data and execute the executable set of instructions, wherein the verification of the decrypted signature against the policy data and the execution of the executable instructions are based on the comparison of the recovered first hash value and the computed second hash value;
2. The system as claimed in claim 1, wherein the executable set of instructions is any executable application operating on any operating system.
3. The system as claimed in claim 1, wherein the executable set of instructions is received as one or more data packets over a communication network from the one or more devices.
4. The system as claimed in claim 1, wherein the encrypted signature may be added to the executable set of instructions by generating the first hash value of the code segment data of the executable set of instructions through a private key or by using an offline set of instructions associated with the one or more devices.
5. The system as claimed in claim 1, wherein the recovered first hash value and the computed second hash value are stored in the memory for the comparison.
6. The system as claimed in claim 1, wherein the comparison of the recovered first hash value and the computed second hash value is performed by a comparator.
7. The system as claimed in claim 1, wherein the verification of the decrypted signature against the policy data and the execution of the executable set of instructions occurs if the recovered first hash value matches with the computed second hash value.
8. The system as claimed in claim 1, wherein a digital certificate is issued if the verification of the decrypted signature against the policy data and the execution of the executable set of instructions is successful.
9. A method for signature-based verification of an executable set of instructions prior to execution, the method comprising:
receiving, by a processor, from one or more devices, the executable set of instructions comprising an encrypted signature corresponding to a policy data, and obtained from a first hash value of a code segment data of the executable set of instructions;
decrypting, by the processor, the encrypted signature of the executable set of instructions to recover the first hash value;
computing, by the processor, a second hash value corresponding to the code segment data of the executable set of instructions;
comparing, by the processor, the recovered first hash value and the computed second hash value; and
verifying the decrypted signature against the policy data and executing the executable set of instructions, by the processor, wherein the verification of the decrypted signature against the policy data and the execution of the executable instructions are based on the comparison of the recovered first hash value and the computed second hash value.
10. The method as claimed in claim 9, wherein the executable set of instructions is any executable application operating on any operating system.
11. The method as claimed in claim 9, wherein the executable set of instructions is received as one or more data packets over a communication network from the one or more devices.
12. The method as claimed in claim 9, wherein the encrypted signature may be added to the executable set of instructions by generating the first hash value of the code segment data of the executable set of instructions through a private key or by using an offline set of instructions associated with the one or more devices.
13. The method as claimed in claim 9, wherein the recovered first hash value and the computed second hash value are stored in the memory for the comparison.
14. The method as claimed in claim 9, wherein the comparison of the recovered first hash value and the computed second hash value is performed by a comparator.
15. The method as claimed in claim 9, wherein the verification of the decrypted signature against the policy data and the execution of the executable set of instructions occurs if the recovered first hash value matches with the computed second hash value.
16. The method as claimed in claim 9, wherein a digital certificate is issued if the verification of the decrypted signature against the policy data and the execution of the executable set of instructions is successful.