| CPC G06F 16/2379 (2019.01) [G06F 16/2365 (2019.01)] | 13 Claims |
|
1. A method for processing transactions in a blockchain network, the method comprising:
receiving, by one or more hardware processors via a client among plurality of clients in a blockchain network, a request for processing a transaction from an end user;
generating, by the one or more hardware processors via the client, a first set of transaction proposals for the transaction;
forwarding, by the one or more hardware processors via the client, the first set of transaction proposals to one or more proving peers, identified from among a plurality of endorsing peers in the blockchain network in accordance with an endorsement policy;
executing, by the one or more hardware processors via each of the one or more proving peers, a vericontract corresponding to the first set of transaction proposals, wherein the vericontract is a smart contract associated with a proof of correctness of execution of the smart contract by each of the one or more proving peers during an endorsement phase of a blockchain process, and wherein the vericontract is executed to generate an output and the proof using one of a) Verifiable Computing (VC) approach, b) a Trusted Execution Environment (TEE) approach, and c) a hybrid approach comprising combination of the VC approach and the TEE approach, wherein executing the vericontract by each of the one or more proving peers to generate the output of the smart contract computation and the proof of the computation using the hybrid approach comprises:
partitioning the smart contract into a plurality of modules using a scheduler, wherein the scheduler includes a scheduler component for maintaining information about the one or more proving peers and information on whether the VC approach or the TEE approach or the hybrid approach is supported, wherein the scheduler schedules high risk operations to the VC approach and low risk operations to the TEE approach, and wherein the scheduler schedules:
a) a first set of modules among the plurality of modules having dependency on each other to run in sequential manner, wherein each of the first set of modules are assigned a unique name and tagged with a sequence type as sequential, and
b) a second set of modules among the plurality of modules that are independent to be run in parallel, wherein each of the second set of modules are assigned a unique name and tagged with the sequence type as parallel;
identifying a proof type for each of the first set of modules and the second set of modules based on a set of parameters associated with each of the plurality of modules, wherein
c) modules, among the first set of modules and the second set of modules, satisfying a first parameter criteria are run using the VC approach, and
d) modules, among the first set of modules and the second set of modules, satisfying a second parameter criteria are run using TEE approach;
generating the proof and storing the proof in a template, wherein the template comprising ModuleName:<Name>, ProofType:<VCE/TEE>, SequenceType: <Sequential/Parallel>, and Proof Data, wherein the scheduler generates and consolidates the proof from proofs generated using the VC approach and the TEE approach; and
aggregating the proof from the first set of modules and the second set of modules generated using the VC approach and the TEE approach by concatenating, wherein the aggregated proof along with the output is sent as the verification data for verification to the set of verifying peers;
sending a first set of proposal responses to the client, wherein the first set of proposal responses are generated in terms of a set of verification data, by the one or more hardware processors via each of the one or more proving peers to the client, wherein each verification data among the set of verification data comprises the output accompanied with the proof generated during execution of the vericontract by each of the one or more proving peers; and
processing, by the one or more hardware processors via the client, the first set of proposal responses for executing the transaction in the blockchain network based on one of a) a endorser-verify model and b) a committer-verify model, wherein processing the first set of transaction proposal responses in accordance with the endorser-verify model comprises:
creating and sharing by the client, a second set of transaction proposals to a set of verifying peers, wherein the second set of transaction proposals are generated for the received first set of proposal responses and comprises the set of verification data, and wherein the set of verifying peers are a set of endorsing verifiers identified among the plurality of endorsing peers in accordance with the endorsement policy for the endorser-verify model;
processing the second set of transaction proposals, by the set of endorsing verifiers to verify the executed vericontract based on the set of verification data received in the second set of transaction proposals during the endorsement phase, wherein the verification is performed in accordance with a) the VC approach, b) the TEE approach and c) the hybrid approach used during execution of the vericontract;
sending a second set of proposal responses generated by each of the set of endorsing verifiers, indicating endorsed transactions to the client in response to the processed second set of transaction proposals;
broadcasting by the client to an orderer the endorsed transactions;
ordering by the orderer, the endorsed transactions into a block and broadcasting the block to a plurality of committing peers of the blockchain network, wherein the plurality of committing peers comprise participating peers in the blockchain network; and
committing the transaction to the blockchain network by the plurality of committing peers after verifying the endorsed transactions and validating results of the endorsed transactions.
|