A low-energy block resource certification method, device and electronic device
By deploying proof retention releasers in the blockchain, block nodes generate and accumulate resource proof information, and business demanders perform combined verification, which solves the problem of high energy consumption in the blockchain consensus protocol and realizes low-energy resource proof.
Patent Information
- Application Number
- CN202210372968.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2022-04-08
- Publication Date
- 2025-09-16
- Estimated Expiration
- 2042-04-08
AI Technical Summary
In existing blockchain consensus protocols, nodes consume a lot of computing resources in terms of time computing power and space storage, resulting in high energy consumption, which is particularly unsuitable for businesses with small demands.
By creating a proof retention releaser and deploying it in the blockchain, the block node generates resource proof information and releases it to the blockchain for publication when the preset conditions are met. The business demander performs combined verification, reducing the number of program creation times and the amount of calculation.
By accumulating multiple resource proof information for combined verification, the amount of calculation is reduced, energy consumption is reduced, and the efficiency of resource proof is improved.
Smart Images

Figure CN114661477B_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of computers, and in particular to a low-energy block resource certification method, device, and electronic device. Background Art
[0002] Blockchain consensus protocols typically require nodes to expend significant computing power (CPU, GPU) and storage space to prove that they have spent several cycles. Generally speaking, the greater the effective computing power and the higher its share of the total network computing power, the greater the authority to package blocks, and thus the greater the block rewards. A typical example is the PoW consensus mechanism, where the prover expends work to generate a hash value; the Proof of Space algorithm, where the prover consumes its own storage space, uses a complex algorithm that consumes CPU / GPU and hard drive performance, and provides duplicate proofs to other nodes.
[0003] However, the currently commonly used methods are computationally intensive and energy intensive, which is undoubtedly a burden for businesses with smaller demands. Therefore, it is necessary to provide a low-energy block resource proof method. Summary of the Invention
[0004] The embodiments of this specification provide a low-energy block resource certification method, device, and electronic device to reduce energy consumption.
[0005] The embodiments of this specification provide a low-energy block resource certification method, including:
[0006] Create a proof-of-lien releaser and deploy it on the blockchain;
[0007] The block node generates resource proof information, the proof retention releaser receives and retains the resource proof information generated by the block node, and releases the retained multiple resource proof information to the blockchain for publication when the state of the object retention releaser meets the preset conditions;
[0008] The business demander verifies the resource status of the block node based on the combined verification of multiple published resource proof information.
[0009] Optionally, the block node generates resource certification information, including:
[0010] The object used to trigger the block node to generate a certificate is received through the certificate retention releaser, and when the state of the object retention releaser meets the preset conditions, the retained multiple objects are released to the corresponding block node, so that the multiple objects share the certificate generation task created by the block node to generate multiple certificates.
[0011] Optionally, it also includes:
[0012] Determine the initial block height and current block height recorded by the proof retention releaser, calculate the height difference, and determine whether the state of the object retention releaser meets the conditions based on whether the height difference reaches a threshold.
[0013] Optionally, the resources include: at least one of time computing resources and space storage resources.
[0014] Optionally, the block node generates resource certification information, including:
[0015] Deploy the extension engine in the block's built-in instruction space;
[0016] The extension engine calls an external contract to create a proof generation task, executes the proof generation task to generate multiple proofs, and returns the generated multiple proofs to the stack of the block node.
[0017] Optionally, the block node generates resource certification information, including:
[0018] Receive an asynchronous transaction request, generate a leaf node based on the hash information of the previous resource, build a Merkle hash tree, and generate resource proof information based on the root path of the Merkle hash tree.
[0019] Optionally, the combined verification based on multiple published resource certification information includes:
[0020] Different block nodes create verification tasks based on the published multiple resource proof information, conduct verification and consensus voting, and obtain verification results.
[0021] The embodiments of this specification also provide a low-energy consumption block resource certification device, including:
[0022] The lien releaser module creates a proof lien releaser and deploys it in the blockchain;
[0023] The proof information module generates resource proof information from the block node. The proof retention releaser receives and retains the resource proof information generated by the block node, and releases the retained multiple resource proof information to the blockchain for publication when the status of the object retention releaser meets the preset conditions.
[0024] The verification module is used by the business demander to verify the resource status of the block node based on the published multiple resource proof information.
[0025] An embodiment of this specification further provides an electronic device, wherein the electronic device includes:
[0026] processor; and,
[0027] A memory storing a computer executable program, wherein when the executable program is executed, the processor is caused to perform any one of the above methods.
[0028] An embodiment of this specification further provides a computer-readable storage medium, wherein the computer-readable storage medium stores one or more programs, and when the one or more programs are executed by a processor, any of the above methods is implemented.
[0029] The various technical solutions provided in the embodiments of this specification create a proof retention releaser and deploy it on the blockchain. Block nodes generate resource proof information. The proof retention releaser receives and retains the resource proof information generated by the block node. When the status of the object retention releaser meets preset conditions, the retained multiple resource proof information is released to the blockchain for publication. The business demander then performs combined verification based on the multiple published resource proof information to obtain the resource status verification result of the block node. By accumulating multiple resource proof information and then releasing them, combined verification can be performed. Resource proof information can be shared by the program, reducing the number of program creation times, thereby reducing the amount of computation and energy consumption. BRIEF DESCRIPTION OF THE DRAWINGS
[0030] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:
[0031] Figure 1 A schematic diagram illustrating the principle of a low-energy block resource certification method provided in an embodiment of this specification;
[0032] Figure 2 A schematic diagram illustrating the principle of a low-energy block resource certification method provided in an embodiment of this specification;
[0033] Figure 3 A schematic diagram of the structure of a low-energy block resource certification device provided in an embodiment of this specification;
[0034] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of this specification;
[0035] Figure 5 A schematic diagram of a computer-readable medium provided in accordance with an embodiment of this specification. DETAILED DESCRIPTION
[0036] Exemplary embodiments of the present invention will now be described more fully with reference to the accompanying drawings. However, exemplary embodiments can be implemented in various forms, and it should not be understood that the present invention is limited to the embodiments set forth herein. On the contrary, providing these exemplary embodiments enables the present invention to be more comprehensive and complete, making it easier to fully convey the inventive concept to those skilled in the art. In the figures, the same reference numerals represent the same or similar elements, components or parts, and thus their repeated description will be omitted.
[0037] Under the premise of being consistent with the technical concept of the present invention, the features, structures, characteristics or other details described in a specific embodiment do not exclude that they can be combined in one or more other embodiments in a suitable manner.
[0038] In the description of specific embodiments, the features, structures, characteristics, or other details of the present invention are described to enable those skilled in the art to fully understand the embodiments. However, this does not preclude those skilled in the art from practicing the technical solutions of the present invention without one or more of the specific features, structures, characteristics, or other details.
[0039] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all contents and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.
[0040] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically separate entities. That is, these functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different networks and / or processor devices and / or microcontroller devices.
[0041] The term "and / or" or "and / or" includes all combinations of any one or more of the associated listed items.
[0042] The existing technology for resource verification is to temporarily create a program task (such as a thread or process) whenever a resource proof information is received. Sometimes queuing is required, which results in the queuing time sometimes even being longer than the time consumed by the verification itself. Therefore, the execution consumes a lot of computing power. If multiple proof information can be processed at one time, the number of program creation times and the amount of computing power can be reduced.
[0043] Figure 1 A schematic diagram of the principle of a low-energy block resource certification method provided in an embodiment of this specification, the method may include:
[0044] S101: Create a proof-of-lien releaser and deploy it in the blockchain.
[0045] Specifically, the proof retention releaser can be in the form of a stack or a queue, and the retention of resource proof information is achieved by setting up a stack or a queue. The retention here means staying for a period of time before issuing it.
[0046] It can be deployed into smart contracts on the blockchain.
[0047] S102: The block node generates resource proof information, the proof retention releaser receives and retains the resource proof information generated by the block node, and releases the retained multiple resource proof information to the blockchain for publication when the status of the object retention releaser meets the preset conditions.
[0048] In the embodiment of this specification, the resources include: at least one of time computing resources and space storage resources.
[0049] Resource proof information may include time proof and space proof. Time proof and space proof themselves belong to the existing technology and will not be elaborated here.
[0050] The conditions for release can be determined based on the proof of retention releaser. For example, if the proof of retention releaser can store 10 contents, then it can be released when it is full.
[0051] It is also possible to directly determine whether to release based on the block height. For example, the resource proof information is released every time 10 blocks are received.
[0052] Therefore, in the embodiments of this specification, the following may also be included:
[0053] Determine the initial block height and current block height recorded by the proof retention releaser, calculate the height difference, and determine whether the state of the object retention releaser meets the conditions based on whether the height difference reaches a threshold.
[0054] Of course, some transaction requests can also be retained to delay the time of generating proof. These transaction requests are used to trigger the block node to generate proof. However, the object used to trigger the block node to generate proof can also be a timed event, etc., which is not specifically elaborated and limited here.
[0055] Therefore, in the embodiment of this specification, the block node generates resource certification information, which may include:
[0056] The object used to trigger the block node to generate a certificate is received through the certificate retention releaser, and when the state of the object retention releaser meets the preset conditions, the retained multiple objects are released to the corresponding block node, so that the multiple objects share the certificate generation task created by the block node to generate multiple certificates.
[0057] Considering the priority of the number of blockchain contracts and the inability to expand built-in contracts, we can expand external contracts through a proxy engine to improve scalability.
[0058] Therefore, in the embodiment of this specification, the block node generates resource certification information, including:
[0059] Deploy the extension engine in the block's built-in instruction space;
[0060] The extension engine calls an external contract to create a proof generation task, executes the proof generation task to generate multiple proofs, and returns the generated multiple proofs to the stack of the block node.
[0061] In the embodiment of this specification, the block node generates resource certification information, including:
[0062] Receive an asynchronous transaction request, generate a leaf node based on the hash information of the previous resource, build a Merkle hash tree, and generate resource proof information based on the root path of the Merkle hash tree.
[0063] S103: The business demander verifies based on the published multiple resource certification information to obtain the resource status verification result of the block node.
[0064] This method creates a proof retention releaser and deploys it on the blockchain. Blockchain nodes generate resource proof information, which the proof retention releaser receives and retains. When the state of the object retention releaser meets preset conditions, the retained multiple resource proofs are released to the blockchain for publication. Business demanders then perform combined verification based on the published multiple resource proofs to obtain the resource status verification result for the block node. By accumulating multiple resource proofs and then releasing them, combined verification can be performed. Resource proof information can be shared across programs, reducing the number of program creations, thereby reducing computational complexity and lowering energy consumption.
[0065] In the embodiment of this specification, the combined verification based on the published multiple resource certification information includes:
[0066] Different block nodes create verification tasks based on the published multiple resource proof information, conduct verification and consensus voting, and obtain verification results.
[0067] When implementing and deploying a blockchain, the main modules that can be deployed include: blockchain main chain cluster and smart contract expansion engine, deployment of zero-knowledge proof contracts and consensus verification contracts.
[0068] Among them, the blockchain main chain cluster is used to run the blockchain system of the PoS consensus protocol. The block nodes under the cluster are used to provide the block height H, block hash BlockHashi and beacon hash BeaconHashi of the system input;
[0069] The smart contract extension engine is responsible for executing smart contract instructions. The extension engine supports the zkSnark zero-knowledge proof library, including the complete Merkle Tree structure, the root hash RootHash, the random node RandLeafID, the input Beaconhash, and the output path zero-knowledge proof π(path); upload πblock_hash, root_hash and random proof, recorded as verify_hash.
[0070] Among them, verify_hash=sha3(block_hash,beaconHash).
[0071] Among them, sha3 is a hash function.
[0072] The zero-knowledge proof contract is a smart contract running on the blockchain, responsible for calling the smart contract extension engine to determine whether the resource proof information meets the conditions;
[0073] The consensus verification contract is responsible for the final stage of VDF (delayed verification) and the public beacon hash.
[0074] The specific process is as follows:
[0075] During the registration phase, the main chain begins at block height H and requests a VDF calculation. If it's a proof-of-time calculation, the chain cluster provides a number (denoted as N) of block hashes (preliminary resources) BlockHash{HN,H-N+1…H}. If it's a proof-of-space calculation, the byte content of the hard drive sector, Data, is obtained, denoted as B, based on the size of the sector, and SectorHashi = sha256(data). A Merkle hash tree is generated, using the aforementioned hash as the leaf node. Then, using a zero-knowledge proof to calculate the root hash root_hash and a path proof to a random leaf node, the current node generates a random number σ and calculates the content to be verified, verify_hash = sha3(block_hash). σ is uploaded to the chain, marking the start of VDF-Step 1 registration. After registration, other nodes cannot generate a unique ID.
[0076] In the consensus phase, when the main chain block height becomes H+T, it means that a certain amount of time has passed. The node publicly announces σ and calculates whether it is consistent in the consensus verification contract.
[0077] During implementation, starting from block H, an asynchronous transaction request is executed: if it is a POW computing power proof, the hash of the previous N blocks is obtained starting from the height H;
[0078] If it is POC or POST space proof, the byte content of each sector of the hard disk is obtained with B sectors as the size, and hash calculation is performed to obtain multiple hash results.
[0079] The hash result is used as the leaf node to generate a Merkle hash tree. The root hash of the tree is calculated and obtained. The zero-knowledge proof library is called and the input is the Merkle hash tree to generate a tree path proof. The block node signs the tree path proof and obtains the signed data. A random number is generated based on the block hash, signed data, timestamp, and random factor. The proof information is then generated based on the block hash, signed data, timestamp, and random factor. The tree path hash and block hash are combined and hashed to obtain the content to be verified and uploaded to the chain. The uploaded parameters are the content to be verified and the proof information.
[0080] The main chain extension contract engine executes the consensus contract, determines whether the proof information is unique, and calls the zero-knowledge proof program to verify whether the tree path proof is correct; if both of the above conditions are met, the next step is executed, otherwise the process ends.
[0081] After the main chain height of the blockchain reaches H+T, a verification transaction is initiated for combined verification. The input parameters are the random factor and the content to be verified. The verification node verifies whether the random factor and the content to be verified are the same as the content to be verified calculated by the verification node. If they are the same, the verification passes, otherwise it ends.
[0082] Figure 2 A schematic diagram of the principle of a low-energy block resource certification method provided in an embodiment of this specification, the method includes:
[0083] Starting from block H, calculate the block hash, generate a Merkle hash tree, calculate the root node, select a random leaf node, generate and upload the proof of the root node. During verification, after accumulating multiple (T) proofs, obtain the hidden factor of the public proof algorithm and perform combined verification.
[0084] Figure 3 A schematic diagram of the structure of a low-energy block resource certification device provided in an embodiment of this specification, the device may include:
[0085] Lien Releaser module 301, creates a proof lien releaser and deploys it in the blockchain;
[0086] Proof information module 302: The block node generates resource proof information. The proof retention releaser receives and retains the resource proof information generated by the block node, and releases the retained multiple resource proof information to the blockchain for publication when the status of the object retention releaser meets the preset conditions.
[0087] Verification module 303: The business demander verifies based on the published multiple resource certification information to obtain the resource status verification result of the block node.
[0088] The device creates a proof retention releaser and deploys it on the blockchain. Blockchain nodes generate resource proof information, which the proof retention releaser receives and retains. When the status of the object retention releaser meets preset conditions, the retained multiple resource proofs are released to the blockchain for publication. Business demanders then perform combined verification based on the published multiple resource proofs to obtain the resource status verification result for the block node. By accumulating multiple resource proofs and then releasing them, combined verification can be performed. Resource proof information can be shared across programs, reducing the number of program creations, thereby reducing computational complexity and lowering energy consumption.
[0089] Based on the same inventive concept, an embodiment of this specification also provides an electronic device.
[0090] The following describes an electronic device embodiment of the present invention, which can be considered a specific physical implementation of the method and apparatus embodiments of the present invention described above. Details described in the electronic device embodiment of the present invention should be considered supplementary to the above-mentioned method or apparatus embodiments; details not disclosed in the electronic device embodiment of the present invention can be implemented with reference to the above-mentioned method or apparatus embodiments.
[0091] Figure 4 This is a schematic diagram of the structure of an electronic device provided in the embodiment of this specification. Figure 4 The electronic device 400 according to this embodiment of the present invention will be described. Figure 4 The electronic device 400 shown is merely an example and should not limit the functions and scope of use of the embodiments of the present invention.
[0092] like Figure 4 As shown, electronic device 400 is implemented as a general-purpose computing device. Components of electronic device 400 may include, but are not limited to, at least one processing unit 410, at least one storage unit 420, a bus 430 connecting various system components (including storage unit 420 and processing unit 410), a display unit 440, and the like.
[0093] The storage unit stores program code that can be executed by the processing unit 410, so that the processing unit 410 performs the steps according to various exemplary embodiments of the present invention described in the above processing method section of this specification. For example, the processing unit 410 can perform the steps shown in Figure 1.
[0094] The storage unit 420 may include a readable medium in the form of a volatile storage unit, such as a random access memory unit (RAM) 4201 and / or a cache memory unit 4202 , and may further include a read-only memory unit (ROM) 4203 .
[0095] The storage unit 420 may also include a program / utility 4204 having a set (at least one) of program modules 4205, such program modules 4205 including but not limited to: an operating system, one or more application programs, other program modules and program data, each of which or some combination may include an implementation of a network environment.
[0096] Bus 430 may represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, a processing unit, or a local bus using any of a variety of bus architectures.
[0097] The electronic device 400 may also communicate with one or more external devices 500 (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable a user to interact with the electronic device 400, and / or any device that enables the electronic device 400 to communicate with one or more other computing devices (e.g., routers, modems, etc.). Such communication may be performed through an input / output (I / O) interface 450. Furthermore, the electronic device 400 may also communicate with one or more networks (e.g., a local area network (LAN), a wide area network (WAN), and / or a public network, such as the Internet) through a network adapter 460. The network adapter 460 may communicate with other modules of the electronic device 400 through the bus 430. It should be understood that although Figure 4 Not shown, other hardware and / or software modules may be used in conjunction with electronic device 400, including but not limited to microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.
[0098] Through the description of the above embodiments, it is easy for those skilled in the art to understand that the exemplary embodiments described in the present invention can be implemented by software, or by combining software with necessary hardware. Therefore, the technical solution according to the embodiment of the present invention can be embodied in the form of a software product, which can be stored in a computer-readable storage medium (which can be a CD-ROM, a USB flash drive, a mobile hard disk, etc.) or on a network, and includes a number of instructions to enable a computing device (which can be a personal computer, a server, or a network device, etc.) to execute the above method according to the present invention. When the computer program is executed by a data processing device, the computer-readable medium is enabled to implement the above method of the present invention, that is: Figure 1 The method shown.
[0099] Figure 5 A schematic diagram of a computer-readable medium provided in accordance with an embodiment of this specification.
[0100] accomplish Figure 1 The computer program of the method shown can be stored on one or more computer-readable media. The computer-readable medium can be a readable signal medium or a readable storage medium. The readable storage medium can be, for example, but not limited to, a system, device or component of electricity, magnetism, light, electromagnetic, infrared, or semiconductor, or any combination thereof. More specific examples (non-exhaustive list) of readable storage media include: an electrical connection with one or more wires, a portable disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof.
[0101] The computer-readable storage medium may include a data signal propagated in baseband or as part of a carrier wave, wherein the readable program code is carried. The data signal propagated may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The readable storage medium may also be any readable medium other than a readable storage medium, which may send, propagate, or transmit a program for use by or in conjunction with an instruction execution system, device, or component. The program code contained on the readable storage medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical cable, RF, etc., or any suitable combination thereof.
[0102] Program code for performing the operations of the present invention may be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, C++, and the like, as well as conventional procedural programming languages such as "C" or similar programming languages. The program code may be executed entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computing device (e.g., via the Internet using an Internet service provider).
[0103] In summary, the present invention can be implemented in hardware, or in a software module running on one or more processors, or in a combination thereof. It will be appreciated by those skilled in the art that general data processing equipment such as a microprocessor or a digital signal processor (DSP) can be used in practice to implement some or all of the functions of some or all of the components in the embodiments of the present invention. The present invention can also be implemented as a device or apparatus program (e.g., a computer program and a computer program product) for executing a part or all of the methods described herein. Such a program for implementing the present invention can be stored on a computer-readable medium, or can have the form of one or more signals. Such a signal can be downloaded from an Internet website, or provided on a carrier signal, or provided in any other form.
[0104] The specific embodiments described above further illustrate the objectives, technical solutions, and beneficial effects of the present invention. It should be understood that the present invention is not inherently related to any specific computer, virtual device, or electronic device, and various general-purpose devices can also implement the present invention. The above description is only a specific embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present invention shall be included in the scope of protection of the present invention.
[0105] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on the differences from other embodiments.
[0106] The foregoing is merely an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present application should all be included within the scope of the claims of the present application.
Claims
1. A low-energy block resource certification method, characterized in that: include: Create a proof-of-lien releaser and deploy it on the blockchain; The proof retention releaser receives an object for triggering the block node to generate a proof, and when the state of the proof retention releaser meets the preset conditions, releases multiple retained objects to the corresponding block node, so that the multiple objects share the proof generation task created by the block node, receives an asynchronous transaction request, generates a leaf node according to the hash information of the previous resource, constructs a Merkle hash tree, and generates multiple resource proof information according to the root path of the Merkle hash tree. The proof retention releaser receives and retains the resource proof information generated by the block node, determines the initial block height and the current block height recorded by the proof retention releaser, calculates the height difference, and determines whether the state of the proof retention releaser meets the preset conditions based on whether the height difference reaches a threshold. When the state of the proof retention releaser meets the preset conditions, the retained multiple resource proof information is released together on the blockchain for publication, wherein the resource proof information includes time proof and space proof; Different block nodes of the business demand side create verification tasks based on the published multiple resource proof information for verification and consensus voting, including: Call the contract extension engine deployed in the blockchain to execute the consensus contract, determine whether the resource proof information is unique, and call the zero-knowledge proof program to verify whether the tree path proof in the Merkle hash tree is correct. If the resource proof information is unique and the path proof is correct, proceed to the next step, otherwise end; After waiting for a period of time, when the current block height and the initial block height of the blockchain main chain reach the threshold, a verification transaction is initiated for combined verification. The input parameters are a random factor and the content to be verified; the content to be verified is compared with the content to be verified calculated by the verification node to determine whether they are the same. If they are the same, it passes; otherwise, it ends and the resource status verification result of the block node is obtained.
2. The method according to claim 1, characterized in that The resources include: at least one of time computing resources and space storage resources.
3. The method according to claim 1, characterized in that The block node generates resource certification information, including: Deploy the extension engine in the block's built-in instruction space; The extension engine calls an external contract to create a proof generation task, executes the proof generation task to generate multiple proofs, and returns the generated multiple proofs to the stack of the block node.
4. A low-energy block resource certification device, characterized in that: include: The lien releaser module creates a proof lien releaser and deploys it on the blockchain; A proof information module receives an object used to trigger a block node to generate a proof through the proof retention releaser, releases multiple retained objects to the corresponding block node when the state of the proof retention releaser meets a preset condition, so that the multiple objects share the proof generation task created by the block node, receives an asynchronous transaction request, generates a leaf node based on the hash information of the previous resource, constructs a Merkle hash tree, and generates multiple resource proof information based on the root path of the Merkle hash tree. The proof retention releaser receives and retains the resource proof information generated by the block node, determines the initial block height and the current block height recorded by the proof retention releaser, calculates the height difference, determines whether the state of the proof retention releaser meets the preset condition based on whether the height difference reaches a threshold, and releases the retained multiple resource proof information to the blockchain for publication when the state of the proof retention releaser meets the preset condition, wherein the resource proof information includes time proof and space proof; In the verification module, different block nodes of the business demand side create verification tasks based on the published multiple resource proof information for verification and consensus voting, including: Call the contract extension engine deployed in the blockchain to execute the consensus contract, determine whether the resource proof information is unique, and call the zero-knowledge proof program to verify whether the tree path proof in the Merkle hash tree is correct. If the resource proof information is unique and the path proof is correct, proceed to the next step, otherwise end; After waiting for a period of time, when the current block height and the initial block height of the blockchain main chain reach the threshold, a verification transaction is initiated for combined verification. The input parameters are a random factor and the content to be verified; the content to be verified is compared with the content to be verified calculated by the verification node to determine whether they are the same. If they are the same, it passes; otherwise, it ends and the resource status verification result of the block node is obtained.
5. An electronic device, wherein: The electronic device includes: processor; and, A memory storing a computer executable program which, when executed, causes the processor to perform the method according to any one of claims 1 to 3.
6. A computer-readable storage medium, wherein: The computer-readable storage medium stores one or more programs, and when the one or more programs are executed by a processor, the method of any one of claims 1 to 3 is implemented.
Citation Information
Patent Citations
Contract scheduling method and device for asynchronous trusted computing and electronic equipment
CN113689296A
Block chain-based data processing method, device, apparatus and system
CN113821817A