Wechat applet equity verification algorithm based on smart contract

Abstract

This invention relates to the fields of program code conversion and smart contract technology, and discloses a WeChat Mini Program rights verification algorithm based on smart contracts. The algorithm receives a verification request initiated by a WeChat Mini Program, extracts the bytecode of the verification function in the smart contract and decompiles it into an abstract syntax tree, stripping away the underlying blockchain dependency instructions. According to the syntax rules of the Mini Program view layer script engine, the processed abstract syntax tree is converted into view layer script proxy code, and the verification preconditions are extracted and constructed into data verification expressions. The WeChat Mini Program calls the proxy code in its local view layer to execute the data verification expressions to complete the precondition verification. This algorithm overcomes the bottleneck of incompatibility between contract bytecode and the Mini Program view layer script engine, pushing the verification calculation down to the local view layer, reducing redundant data transmission between the logic layer and the server.

Description

Technical Field

[0001] This invention relates to the fields of program code conversion and smart contract technology, and discloses a WeChat mini-program rights verification algorithm based on smart contracts. Background Technology

[0002] Existing WeChat Mini Program rights verification solutions based on smart contracts typically employ a data pass-through model. After a user triggers a rights verification operation on the WeChat Mini Program front-end interface, the Mini Program's logic layer sends verification parameters, including the user's identifier and rights identifier, to the back-end server. The back-end server receives these parameters and submits a transaction request to the blockchain node via a remote procedure call. Upon receiving the request, the blockchain node loads and runs the corresponding smart contract bytecode in its underlying virtual machine. During execution, the smart contract queries the on-chain state database to verify prerequisites such as whether the rights belong to the user and whether the verification time is within the validity period. After successful verification, the smart contract modifies the corresponding rights status field on the chain and returns the execution result to the WeChat Mini Program front-end along the original path to update the interface state. In this conventional architecture, all verification rule validation logic is encapsulated in the smart contract bytecode; the WeChat Mini Program front-end only serves as a data collection and display carrier and does not participate in any substantive logical operations.

[0003] Because WeChat Mini Programs operate in a closed sandbox architecture, their built-in view layer script engine cannot directly parse and execute the instruction set format specific to the underlying blockchain virtual machine. This prevents the verification logic in smart contracts from being executed locally within the Mini Program. All pre-verification conditions must rely on the backend server to call the on-chain smart contract across the network. This serial interaction across nodes results in a large amount of redundant data transmission between the view layer, the logic layer, and the server. Furthermore, the view layer's own computing power cannot be used to share the verification burden, leading to low response efficiency for pre-verification verification of equity. Summary of the Invention

[0004] The purpose of this invention is to provide a WeChat mini-program rights verification algorithm based on smart contracts, which can solve the problems mentioned in the background.

[0005] To achieve the above objectives, the technical solution adopted by the present invention is as follows: A WeChat Mini Program rights verification algorithm based on smart contracts includes: receiving a rights verification request initiated by a WeChat Mini Program and extracting the bytecode of the verification function in the corresponding smart contract; The server-side contract parsing engine decompiles the bytecode of the revocation function into an abstract syntax tree, and then extracts the underlying blockchain dependency instructions from the abstract syntax tree. According to the syntax rules of the WeChat Mini Program WXS script engine, the stripped abstract syntax tree is converted into a WXS proxy script, and the verification preconditions are extracted from the abstract syntax tree to construct a data validation expression. Send the WXS proxy script and the data validation expression to the WeChat mini program; The WeChat mini program calls the WXS proxy script in the local view layer to execute the data verification expression for precondition verification. After the verification is passed, the execution trajectory signature and reconciliation parameters are encapsulated into a standard transaction body and submitted to the on-chain smart contract. The smart contract compares the execution trajectory signature with its own pre-stored expected execution path to determine the validity of the write-off.

[0006] Preferably, the revocation function bytecode is decompiled into an abstract syntax tree by the server-side contract parsing engine, including: decoding the opcode of the revocation function bytecode and constructing a control flow graph containing stack operation instructions, jump instructions and local variable tables; Identify the external call instruction set and the state read / write instruction set that interact with the underlying blockchain environment from the control flow graph, and mark the external call instruction set and the state read / write instruction set as nodes to be stripped. Disconnect the directed edges between the node to be stripped and the other logical nodes in the control flow graph, and redirect the incoming and outgoing edges corresponding to the node to be stripped to the preset no-operation placeholder node to generate the abstract syntax tree that removes the underlying blockchain dependent instructions.

[0007] Preferably, according to the syntax rules of the WeChat Mini Program WXS script engine, the stripped abstract syntax tree is converted into a WXS proxy script, including: traversing the basic syntax nodes in the abstract syntax tree and mapping the smart contract native data types in the basic syntax nodes to the corresponding data structures supported by the WXS script engine. For the loop control node and conditional branch node in the abstract syntax tree, the stack top operation logic inside the loop control node and the conditional branch node is rewritten as a register assignment operation based on the corresponding data structure, and the rewritten node sequence is encapsulated according to the execution entry format of the WXS script engine to generate the WXS proxy script.

[0008] Preferably, extracting the verification preconditions from the abstract syntax tree to construct a data validation expression includes: locating the base block containing the Require assertion statement in the abstract syntax tree, and extracting the logical operation tree contained in the Require assertion statement; Replace the on-chain state query operation in the logical operation tree with key-value pair parameter variables passed from the WeChat Mini Program, and replace the block height timestamp operation in the logical operation tree with the local clock timestamp variable of the WeChat Mini Program. The replaced logic operation tree is converted into a string format data verification expression using a preset logic operator concatenation function.

[0009] Preferably, the WXS proxy script is called in the local view layer to execute the data validation expression for precondition validation, including: instantiating an isolated WXS script execution context in the WeChat Mini Program view layer, and injecting the data validation expression and the rights and interests verification parameters into the WXS script execution context; Record the instruction pointer traversal order of the WXS agent script in the WXS script execution context and the register state change sequence corresponding to each instruction step; The execution trajectory signature is generated by hashing the instruction pointer traversal order and the register state change sequence. The execution trajectory signature and the equity revocation parameters are then encapsulated into the standard transaction body according to the preset transaction body serialization rules.

[0010] Preferably, the smart contract compares the execution trajectory signature with its own pre-stored expected execution path to determine the validity of the write-off, including: after receiving the standard transaction body, the smart contract extracts the execution trajectory signature and the write-off parameters from the standard transaction body; The simulation execution environment inside the smart contract is invoked, the revocation parameters are input, and the original revocation function bytecode is executed. The simulation instruction pointer traversal path and simulation register change path output by the simulation execution environment are collected. The simulation signature is obtained by calculating the hash value of the simulation instruction pointer traversal path and the simulation register change path. The simulation signature is compared with the execution trajectory signature to see if they are consistent. Based on the comparison result, the verification validity judgment flag is output.

[0011] Preferably, redirecting the incoming and outgoing edges corresponding to the node to be stripped to a preset no-operation placeholder node includes: establishing a pool of no-operation placeholder nodes and assigning a unique no-operation placeholder node identifier to each external call instruction set marked as a node to be stripped. In the control flow graph, the endpoints of all predecessor directed edges pointing to the node to be stripped are modified to the corresponding assigned no-operation placeholder node identifiers, and the starting points of all successor directed edges pointing to the node to be stripped are modified to the corresponding assigned no-operation placeholder node identifiers. Configure a default return value constant corresponding to the identifier of the no-operation placeholder node in the no-operation placeholder node pool, and use the default return value constant as the data passed by the no-operation placeholder node to the subsequent directed edge.

[0012] Preferably, the stack top operation logic inside the loop control node and the condition branch node is rewritten as a register assignment operation based on the corresponding data structure, including: parsing the push and pop instructions inside the loop control node and the condition branch node, and determining the stack offset corresponding to the push and pop instructions. Allocate a virtual register address space mapped to the stack offset in the corresponding data structure supported by the WXS script engine; The push instruction is rewritten as an assignment instruction to write data to the virtual register address space, and the pop instruction is rewritten as a read instruction to read data from the virtual register address space. The assignment instruction and the read instruction are arranged in the order of instructions in the control flow graph.

[0013] Preferably, replacing the on-chain state query operation in the logic operation tree with key-value pair parameter variables passed from the WeChat mini program locally includes: identifying leaf nodes in the logic operation tree that contain storage key name read operations; Obtain the latest on-chain state key-value pair corresponding to the storage key name read operation from the server cache, use the key name of the latest on-chain state key-value pair as the local storage index of the WeChat Mini Program, and encapsulate the value of the latest on-chain state key-value pair as the key-value pair parameter variable; In the logical operation tree, the key-value pair parameter variable is used to replace the leaf node containing the storage key name read operation, and a calling channel between the key-value pair parameter variable and the WeChat mini program local storage index is established.

[0014] Preferably, instantiating an isolated WXS script execution context in the WeChat Mini Program view layer includes: allocating a WXS execution thread independent of the rendering thread in the thread pool of the WeChat Mini Program view layer, and initializing a WXS script engine instance in the WXS execution thread. Build a restricted global object access whitelist for the WXS script engine instance to block the WXS script engine instance's access permissions to the WeChat Mini Program's native network interface and file system interface; An independent memory stack area is allocated in the WXS script engine instance, and the data verification expression and the rights revocation parameters are loaded into the memory stack area, restricting the WXS agent script to read and write data only in the memory stack area.

[0015] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. This solution decompiles the bytecode of the smart contract's reconciliation function into an abstract syntax tree (AST) using a server-side contract parsing engine and removes the underlying blockchain-dependent instructions. Combining this with the syntax rules of the WeChat Mini Program's view layer script engine, the processed AST is converted into a proxy script, overcoming the technical bottleneck of incompatibility between the smart contract's underlying virtual machine instruction set and the WeChat Mini Program's view layer script engine. This solution transforms the reconciliation verification logic, which originally had to be executed on-chain, into a proxy script executed locally in the view layer. This allows the WeChat Mini Program to directly call the proxy script to perform precondition verifications in the local view layer, moving high-frequency verification calculations from the front-end logic layer and server-side to the local view layer, reducing redundant data transmission between the Mini Program's logic layer and the server.

[0016] 2. This solution instantiates and isolates the script execution context at the WeChat Mini Program view layer, constructs a restricted global object access whitelist to block access permissions to native network interfaces and file system interfaces, and allocates an independent memory stack area to limit the data read and write range of the proxy script, ensuring memory safety and execution isolation of the proxy script when it is executed at the view layer. During the conversion to a proxy script, the on-chain state query operation in the logic operation tree is replaced with key-value pair parameter variables passed from the WeChat Mini Program. Simultaneously, a simulation execution environment is set up at the smart contract side to compare the execution trajectory signature with the expected execution path. This achieves local verification at the view layer while maintaining consistency verification between the local verification trajectory and the on-chain contract execution logic. Attached Figure Description

[0017] Figure 1 This is a flowchart of the WeChat Mini Program rights verification algorithm based on smart contracts according to the present invention. Figure 2 This is a flowchart of the bytecode decompilation and dependent instruction stripping process for the revocation function of this invention; Figure 3 This is a flowchart illustrating the conversion of the abstract syntax tree of this invention into view layer script proxy code; Figure 4 This is a flowchart of the precondition extraction and local parameter variable replacement process for the reimbursement of the present invention. Figure 5 This is a flowchart of the view layer local verification and execution trajectory signature generation process of the present invention; Figure 6 This is a flowchart of the on-chain smart contract simulation verification and write-off validity determination process of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0019] Please refer to Figure 1 This embodiment provides a WeChat Mini Program rights verification algorithm based on smart contracts. The WeChat Mini Program uses smart contracts deployed in a consortium blockchain node cluster to implement user rights verification operations. These rights include, but are not limited to, merchant-issued electronic coupons, membership point redemption rights, and digital collectible usage vouchers. When a user triggers a rights verification operation control in the WeChat Mini Program's view layer interface, the WeChat Mini Program generates a rights verification request and sends it to the server. This request includes a user identity identifier, a unique rights identifier, a Mini Program application identifier, and a verification trigger timestamp. Upon receiving the rights verification request, the server retrieves the pre-stored mapping relationship between rights and smart contracts based on the unique rights identifier, obtains the on-chain deployment address of the corresponding smart contract, reads the runtime bytecode of the smart contract through the blockchain node's RPC interface, and locates and extracts the verification function bytecode from the runtime bytecode based on the function selector of the verification function. Specifically, the function selector is obtained by hashing the signature string of the verification function, using the following formula: in, The complete signature string for the reimbursement function. This is a hash function commonly used in the blockchain system. This indicates that the first 4 bytes of the hash operation result are used as the function selector. The server uses this function selector to match the corresponding function entry point in the runtime bytecode of the smart contract, and extracts the bytecode segment from the function entry point to the function return instruction as the write-off function bytecode.

[0020] The server invokes its built-in contract parsing engine to process the revocation function bytecode. The contract parsing engine decompiles the revocation function bytecode into an abstract syntax tree (AST), which is a tree-like data structure containing all the execution logic of the revocation function. Each tree node corresponds to one or a group of instructions in the revocation function. During the decompilation process, the contract parsing engine identifies instruction nodes in the AST that interact with the underlying blockchain environment, marks these nodes as blockchain-level dependent instructions, and extracts these blockchain-level dependent instructions from the AST to generate a stripped AST.

[0021] Furthermore, the contract parsing engine reads the syntax rule configuration file of the WeChat Mini Program WXS script engine. This configuration file contains the data types, syntax structures, execution entry formats, and reserved keyword constraints supported by the WXS script engine. Based on this configuration file, the contract parsing engine converts the stripped abstract syntax tree node by node into a WXS proxy script conforming to the WXS script engine syntax specification. Simultaneously, the contract parsing engine traverses the stripped abstract syntax tree, locates the assertion nodes used for verifying preconditions, extracts the logical operations within these assertion nodes, and constructs a data verification expression.

[0022] The server sends the generated WXS proxy script and data verification expression to the WeChat Mini Program that initiated the rights verification request via the official WeChat Mini Program interface. Upon receiving the WXS proxy script and data verification expression, the WeChat Mini Program loads the script and expression in its local view layer, calls the WXS proxy script, and executes the data verification expression in the WXS script runtime environment of the view layer to complete the verification of the preconditions for verification. If the verification passes, the WeChat Mini Program collects the instruction execution sequence and state change sequence during the execution of the WXS proxy script, performs hash calculations on the sequence to generate an execution trajectory signature, encapsulates the execution trajectory signature and verification parameters into a standard transaction body according to preset serialization rules, and submits the standard transaction body to the on-chain smart contract through the server.

[0023] After receiving the standard transaction body, the on-chain smart contract deserializes the transaction body and extracts the execution trajectory signature and revocation parameters. The smart contract calls its pre-configured simulation execution environment, taking the revocation parameters as input, and runs the original revocation function bytecode. It collects the expected execution path generated during the simulation execution, which includes the instruction sequence and state change sequence of the simulation execution. The smart contract performs a hash calculation on the expected execution path to obtain the expected signature, compares the execution trajectory signature with the expected signature, and generates a revocation validity determination identifier based on the comparison result. Specifically, the calculation formula for the revocation validity determination is: in, This is an indicator for determining the validity of the write-off; a value of 1 indicates that the write-off is valid, and a value of 0 indicates that the write-off is invalid. Signature of the execution trajectory submitted by the WeChat Mini Program; The expected signature generated for the simulated execution of the smart contract. The smart contract in... When the value is 1, an on-chain equity status change operation is performed, modifying the status of the corresponding equity to "redeemed" and returning the successful redemption result to the WeChat mini-program; the smart contract in When the value is 0, the verification process is terminated, and the verification failure result is returned to the WeChat mini program.

[0024] In this embodiment, to clarify the mapping relationship between the native data types of smart contracts and the data structures supported by the WXS script engine, and to ensure the consistency of data logic during the abstract syntax tree conversion process, type mapping rules as shown in Table 1 are set.

[0025] Table 1 Mapping Table of Native Data Types in Smart Contracts and Data Structures in WXS Scripts uint256 64-bit integer type The system directly maps decimal values; values ​​exceeding 64-bit precision are converted to string format for storage, and operations are performed using segmented calculations. The value 10000 of type uint256 is mapped to 10000 in WXS. address String type Remove the 0x prefix from the address, convert it to a 40-digit lowercase hexadecimal string for storage, and restore the prefix for matching during verification. The address type 0x1234abcd is mapped to "1234abcd" in WXS. bool Boolean type Direct mapping, true and false correspond to true and false in WXS respectively. The boolean type `true` is mapped to `true` in WXS. bytes String type The string is converted to Base64 encoding and stored; during computation, it is decoded back into a raw byte stream for processing. The bytes type 0x68656c6c6f is mapped to "aGVsbG8=" in WXS. mapping key-value pair objects Convert to a WXS Object, where the mapping key becomes the Object's property name, and the mapping value becomes the Object's property value. The key-value pair mapping(uint256=>address) is mapped to {1001:"1234abcd"} in WXS. The mapping rules defined in Table 1 cover all data types commonly used in smart contract reconciliation functions. Corresponding conversion methods are set for the storage characteristics and operation logic of different data types to avoid WXS proxy script execution errors caused by data type incompatibility and ensure the consistency of reconciliation logic before and after conversion.

[0026] This embodiment fully implements the entire process of receiving rights revocation requests, extracting and decompiling the bytecode of the revocation function, stripping the blockchain underlying dependent instructions, generating and distributing WXS proxy scripts and data verification expressions, local pre-verification of the view layer, generation and on-chain of execution trajectory signatures, and validity verification of on-chain smart contracts. It realizes the sinking of the revocation verification logic from the blockchain to the WeChat mini-program view layer, reducing cross-node data transmission in the revocation process.

[0027] In a preferred embodiment, reference Figure 2 When the server-side contract parsing engine decompiles the bytecode of the revocation function, it first decodes the opcode bytecode byte by byte, identifying the opcode and operands of each instruction contained in the bytecode, and constructing a control flow graph containing stack operation instructions, jump instructions, and a local variable table. The control flow graph is a directed graph structure, mathematically defined as follows: in, The completed control flow graph; It is a set of basic block nodes. Each basic block node corresponds to a set of continuous instructions without internal jumps. The execution of the instruction sequence starts from the first instruction and ends with the last jump or return instruction. It is a set of directed edges. Each directed edge corresponds to the execution jump relationship between two basic block nodes. The starting point of the directed edge is the predecessor basic block node, and the ending point is the successor basic block node. The entry node of the control flow graph corresponds to the first instruction of the cancellation function; The exit node of the control flow graph corresponds to the return instruction of the cancellation function.

[0028] After the contract parsing engine completes the construction of the control flow graph, it traverses all basic block nodes in the control flow graph, identifies the instructions contained in each basic block node that interact with the underlying blockchain environment, and divides these instructions into external call instruction sets and state read / write instruction sets. Basic block nodes containing both external call instruction sets and state read / write instruction sets are marked as nodes to be stripped. Specifically, the external call instruction sets include blockchain underlying system call instructions, cross-contract call instructions, and address balance query instructions; the state read / write instruction sets include read instructions, write instructions, and delete instructions for the on-chain state database.

[0029] Furthermore, the contract parsing engine disconnects the directed edges connecting the node to be stripped to the other logical nodes in the control flow graph, redirects the incoming and outgoing edges corresponding to the node to be stripped to preset no-operation placeholder nodes, and generates an abstract syntax tree that removes the underlying blockchain dependency instructions. Specifically, the contract parsing engine pre-establishes a pool of no-operation placeholder nodes, assigning a unique no-operation placeholder node identifier to each external call instruction set and state read / write instruction set marked as a node to be stripped. The return value of the no-operation placeholder node is defined by a preset default constant, and its calculation formula is as follows: in, The return value of the placeholder node for the null operation; A unique identifier for a placeholder node used for empty operations; This is the set of default constants corresponding to the no-operation placeholder node identifier. The values ​​of the default constants are determined based on the return value type of the original instruction of the corresponding node to be stripped.

[0030] During the control flow graph redirection process, the contract parsing engine modifies the endpoints of all preceding directed edges pointing to the node to be stripped to the corresponding assigned no-operation placeholder node identifiers, and modifies the starting points of all succeeding directed edges pointing to the node to be stripped to the corresponding assigned no-operation placeholder node identifiers. After completing the directed edge redirection, the node to be stripped is removed from the control flow graph. The contract parsing engine performs semantic analysis on the control flow graph after the redirection and node removal, generating a corresponding abstract syntax tree. This abstract syntax tree has removed all underlying blockchain dependency instructions, retaining only the core verification and computation logic of the revocation function.

[0031] In this embodiment, to clarify the classification, identification rules, and stripping processing methods of the underlying blockchain instructions, instruction stripping rules are set as shown in Table 2.

[0032] Table 2. Classification and Decoupling Rules of Blockchain Underlying Dependencies On-chain state read instructions SLOAD The instruction opcode is SLOAD, used to read data from the on-chain state database, and is a core blockchain dependency instruction. Allocate a placeholder node for no-operation tasks; the default return value is the local cache key-value pair data for the corresponding storage slot. On-chain state write instructions SSTORE The instruction opcode is SSTORE, used to write data to the on-chain state database, and is a core instruction required by the blockchain. Allocate a placeholder node for a no-operation event; the default return value is a boolean constant `true`. Cross-contract call instructions CALL The instruction opcode is CALL, used to call functions of other smart contracts, and is a core instruction required by the blockchain. Allocate a placeholder node for no-operation calls; the default return value is the static return constant of the corresponding cross-contract call. Block attribute read command TIMESTAMP, NUMBER The instruction opcodes are TIMESTAMP and NUMBER, used to read the block timestamp and block height, and are underlying blockchain dependency instructions. Assign a placeholder node for a no-operation task; the default return value is a local timestamp variable placeholder. Address Balance Inquiry Command BALANCE The instruction opcode is BALANCE, used to query the account balance at a specified address. It is a core instruction required by the blockchain. Allocate a placeholder node for a no-operation task; the default return value is a constant of 0. System call instructions SELFDESTRUCT The instruction opcode is SELFDESTRUCT, used for contract self-destruction, and is a core instruction required by the blockchain. Assign a placeholder node for no-operation tasks; if there is no return value, redirect directly to the control flow graph exit node. Table 2 provides a complete classification of commonly used instructions that interact with the underlying environment in the blockchain's underlying virtual machine. It clarifies the marking rules for each type of instruction and the corresponding redirection processing method, ensuring that all blockchain underlying dependent instructions are completely stripped away. At the same time, it maintains the structural integrity of the control flow graph by using no-operation placeholder nodes, avoiding the breakage of control flow logic due to node removal, and ensuring the accuracy of subsequent abstract syntax tree transformation.

[0033] This embodiment details the complete implementation process of decompiling the bytecode of the revocation function into an abstract syntax tree and stripping away the underlying blockchain dependency instructions. By constructing the control flow graph, identifying and marking the nodes to be stripped, and redirecting directed edges, the complete stripping of the underlying blockchain dependency instructions is achieved, while maintaining the integrity of the core logic of the revocation function. This provides an environment-independent abstract syntax tree foundation for the subsequent conversion of WXS proxy scripts.

[0034] In a preferred embodiment, reference Figure 3 and Figure 4 After the contract parsing engine generates an abstract syntax tree that extracts the underlying blockchain instructions, it traverses all basic syntax nodes in the abstract syntax tree and maps the native smart contract data types in the basic syntax nodes to the corresponding data structures supported by the WXS script engine. This data type mapping process is implemented through a preset mapping function, the mathematical definition of which is: in, To complete the abstract syntax tree after data type mapping; This is the original abstract syntax tree after stripping away the underlying dependent instructions of the blockchain; A pre-defined set of mapping rules between native smart contract data types and WXS script data structures; This is a depth-first traversal mapping function for the abstract syntax tree (AST). The function iterates through each node of the AST, based on... Complete the conversion of node data types.

[0035] Furthermore, the contract parsing engine identifies loop control nodes and conditional branch nodes in the abstract syntax tree, parses the stack operation logic within these nodes, and rewrites the stack top operation logic as register assignment operations based on the mapped data structure. Specifically, the contract parsing engine first parses the push and pop instructions within the loop control nodes and conditional branch nodes, determines the stack offset corresponding to each push and pop instruction, and allocates the corresponding virtual register address space based on the stack offset. The formula for calculating the virtual register address is: in, Offset within the stack The corresponding virtual register address; This is the base address of the virtual register address space; The length of a single data unit in the WXS script engine is fixed at 8 bytes. This is the stack offset corresponding to a push or pop instruction, expressed in words.

[0036] After allocating the virtual register address, the contract parsing engine rewrites the push instruction as an assignment instruction to write data to the corresponding virtual register address space. The mathematical expression for the assignment instruction is: in, This is the function for writing to the virtual register; This refers to the data value that needs to be pushed onto the top of the stack in the original push instruction.

[0037] The contract parsing engine rewrites the pop instruction as a read instruction to read data from the corresponding virtual register address space. The mathematical expression for the read instruction is: in, This is the function for reading virtual registers; This refers to the data value popped from the top of the stack in the original pop instruction.

[0038] The contract parsing engine arranges the rewritten assignment and read instructions according to the order of instructions in the control flow graph, completing the rewriting of the stack operation logic inside the loop control nodes and conditional branch nodes. After completing the transformation and rewriting of all nodes, the contract parsing engine encapsulates the rewritten node sequence according to the execution entry format of the WXS script engine to generate a WXS proxy script. The execution entry format conforms to the module export specification of the WeChat Mini Program WXS script engine, encapsulating the verification logic into an exported function that can be directly called by the view layer.

[0039] While generating the WXS proxy script, the contract parsing engine extracts the verification preconditions from the stripped abstract syntax tree and constructs data validation expressions. Specifically, the contract parsing engine locates the base block containing the Require assertion statement in the abstract syntax tree. The Require assertion statement is a native statement in the smart contract used to validate preconditions. When the logical expression in the assertion statement evaluates to false, contract execution will terminate and roll back. The contract parsing engine extracts the logical operation tree contained in the Require assertion statement. This logical operation tree is a tree structure with logical operators as non-leaf nodes and variables or constants as leaf nodes.

[0040] The contract parsing engine traverses the logic operation tree, replacing on-chain state query operations with key-value pair parameter variables passed from the WeChat Mini Program. Specifically, the contract parsing engine identifies leaf nodes in the logic operation tree containing storage key name read operations, obtains the latest on-chain state key-value pair corresponding to the storage key name read operation from the server cache, uses the key name of the latest on-chain state key-value pair as the WeChat Mini Program's local storage index, encapsulates the value of the latest on-chain state key-value pair as a key-value pair parameter variable, replaces the leaf nodes containing storage key name read operations in the logic operation tree with the key-value pair parameter variable, and establishes a calling channel between the key-value pair parameter variable and the WeChat Mini Program's local storage index. Simultaneously, the contract parsing engine replaces block height timestamp operations in the logic operation tree with WeChat Mini Program's local clock timestamp variables.

[0041] After replacing the nodes in the logic operation tree, the contract parsing engine uses a preset logic operator concatenation function to convert the replaced logic operation tree into a string-formatted data validation expression. The formula for constructing the data validation expression is as follows: in, A validation expression for the generated string format data; To complete the logical operation tree after node replacement; This is a predefined set of mapping rules between logical operators and string formats; This is a function for concatenating the post-order traversal of a logical operation tree. The function traverses all nodes of the logical operation tree in post-order traversal order, based on... Convert the nodes into corresponding string fragments and concatenate them into a complete data validation expression.

[0042] In this embodiment, to clarify the specific rules for converting the logical operation tree of the Require assertion statement into a data validation expression, the conversion rules shown in Table 3 are set.

[0043] Table 3. Rules for Transforming Logical Operation Trees of Require Assertion Statements Table 3 covers the commonly used logical operation nodes and underlying blockchain dependency nodes in the Require assertion statement, and clarifies the conversion rules and output format of each node. This ensures that the converted data verification expression fully conforms to the syntax specifications of the WXS script engine, while completely preserving all the verification logic of the original smart contract's reconciliation preconditions, avoiding the loss or change of verification logic due to conversion.

[0044] This embodiment details the complete implementation process of converting an abstract syntax tree into a WXS proxy script. By rewriting data type mapping and stack operation logic into register assignment operations, it achieves a compatible conversion between smart contract execution logic and WXS script. At the same time, it refines the extraction process of reconciliation preconditions and the construction process of data verification expressions. By replacing and concatenating nodes in the logic operation tree, it achieves the conversion between on-chain verification logic and view layer local verification logic, ensuring the consistency of pre-verification logic before and after the conversion.

[0045] In a preferred embodiment, reference Figure 5 and Figure 6 After receiving the WXS proxy script and data validation expression from the server, the WeChat Mini Program calls the WXS proxy script in the local view layer to execute the data validation expression for precondition verification. Specifically, the WeChat Mini Program allocates a WXS execution thread, independent of the rendering thread, in the view layer's thread pool. Within this WXS execution thread, a WXS script engine instance is initialized, and an isolated WXS script execution context is instantiated. To ensure memory safety during the execution of the WXS proxy script, memory access boundary verification rules are set in the WXS script engine instance, with the following mathematical expression: in, This refers to the memory address accessed during the execution of the WXS agent script; The base address of the independent memory stack region allocated for the WXS script engine instance; The size of the allocated memory stack region. The WXS script engine only allows the corresponding read and write operations if the accessed memory address is within the above range; otherwise, it will terminate script execution and throw an exception.

[0046] Furthermore, a restricted global object access whitelist is constructed for the WXS script engine instance. This whitelist only includes the basic data processing and mathematical operation functions built into the WXS script engine, blocking the WXS script engine instance's access to the WeChat Mini Program's native network and file system interfaces. An independent memory stack area is allocated within the WXS script engine instance, and data validation expressions and rights verification parameters are loaded into this memory stack area, restricting the WXS proxy script to data read and write operations only within this memory stack area.

[0047] After initializing the WXS script execution context, the WeChat Mini Program view layer calls the exported function of the WXS proxy script, taking the rights and benefits verification parameters as input, and executes the data validation expression to complete the verification of the preconditions for verification. During script execution, the WXS script engine records the instruction pointer traversal order and the register state change sequence corresponding to each instruction in real time. The instruction pointer traversal order is the execution sequence of each instruction during script execution, and the register state change sequence is the sequence of numerical changes in the virtual register address space after each instruction is executed.

[0048] After the script execution is complete and the preconditions are verified, the WeChat Mini Program performs a hash calculation on the recorded instruction pointer traversal order and register state change sequence to generate an execution trajectory signature. The formula for calculating the execution trajectory signature is as follows: in, The instruction pointer traversal sequence; For register state change sequence; For byte concatenation operations, byte stream and The byte streams are concatenated sequentially into a complete byte array; A hash function consistent with on-chain smart contracts.

[0049] The WeChat mini program encapsulates the generated execution trajectory signature and rights verification parameters into a standard transaction body according to preset transaction body serialization rules. These serialization rules employ the ABI encoding standard compatible with on-chain smart contracts, ensuring that the on-chain smart contract can correctly deserialize and read the data within the transaction body. The WeChat mini program then forwards the encapsulated standard transaction body to the blockchain node via the server, submitting it to the on-chain smart contract.

[0050] After receiving a standard transaction body, the on-chain smart contract deserializes it according to the preset ABI encoding standard, extracting the execution trace signature and revocation parameters. The smart contract calls the internally stored original revocation function bytecode, inputs the revocation parameters into the internal simulation execution environment, and runs the original revocation function bytecode, collecting the simulation instruction pointer traversal path and simulation register change path output by the simulation execution environment. The smart contract performs a hash calculation on the simulation instruction pointer traversal path and simulation register change path to obtain the simulation signature. The calculation formula for the simulation signature is: in, The path for traversing the simulation instruction pointer output by the simulation execution environment; This specifies the path for changing the simulation registers output by the simulation execution environment.

[0051] The smart contract compares the simulated signature with the received execution trajectory signature to determine if they match, and outputs a verification validity flag based on the comparison result. When the simulated signature and the execution trajectory signature match, the smart contract determines that the verification is valid, executes the on-chain equity status change operation, modifies the status of the corresponding equity to "verified," and returns the successful verification result to the WeChat mini-program through the server. The WeChat mini-program updates the equity status display information in the view layer. When the simulated signature and the execution trajectory signature do not match, the smart contract determines that the verification is invalid, terminates the verification process, does not execute any on-chain status change operation, and returns the failed verification result to the WeChat mini-program through the server. The WeChat mini-program displays the corresponding failure message in the view layer.

[0052] In this embodiment, to clarify the parameter definitions, data formats, and hash calculation rules in the trajectory signature generation process, signature generation rules as shown in Table 4 are set.

[0053] Table 4 Execution Trajectory Signature Generation Parameters and Hash Calculation Rules Table 4 clarifies the meaning, data format, and concatenation order of all input parameters during the execution trajectory signature generation process. This ensures that the execution trajectory signature generated by the WeChat Mini Program view layer and the simulation signature generated by the on-chain smart contract simulation execution use completely consistent hash calculation rules, avoiding signature comparison failures due to differences in parameter concatenation order or data format, and guaranteeing the accuracy of the verification validity determination.

[0054] This embodiment details the complete implementation process of pre-condition verification and execution trajectory signature generation in the WeChat Mini Program view layer. By using an isolated WXS script execution context, restricted access permissions, and an independent memory stack area, the security of script execution is ensured. At the same time, it details the implementation process of the on-chain smart contract comparing the execution trajectory signature and determining the validity of the revocation through a simulated execution environment. This ensures the consistency between the local verification logic of the view layer and the execution logic of the on-chain contract, achieving local pre-verification while ensuring the security and immutability of the revocation operation.

Claims

1. A WeChat applet rights-based smart contract algorithm, characterized in that, include: Receive the rights and interests verification request initiated by the WeChat mini program and extract the bytecode of the verification function in the corresponding smart contract; The server-side contract parsing engine decompiles the bytecode of the revocation function into an abstract syntax tree, and then extracts the underlying blockchain dependency instructions from the abstract syntax tree. According to the syntax rules of the WeChat Mini Program WXS script engine, the stripped abstract syntax tree is converted into a WXS proxy script, and the verification preconditions are extracted from the abstract syntax tree to construct a data validation expression. Send the WXS proxy script and the data validation expression to the WeChat mini program; The WeChat mini program calls the WXS proxy script in the local view layer to execute the data verification expression for precondition verification. After the verification is passed, the execution trajectory signature and reconciliation parameters are encapsulated into a standard transaction body and submitted to the on-chain smart contract. The smart contract compares the execution trajectory signature with its own pre-stored expected execution path to determine the validity of the write-off. 2.The smart contract-based WeChat mini-program right benefit cancellation algorithm according to claim 1, characterized in that, The server-side contract parsing engine decompiles the bytecode of the revocation function into an abstract syntax tree, including: decoding the opcode of the revocation function bytecode and constructing a control flow graph containing stack operation instructions, jump instructions and local variable tables; Identify the external call instruction set and the state read / write instruction set that interact with the underlying blockchain environment from the control flow graph, and mark the external call instruction set and the state read / write instruction set as nodes to be stripped. Disconnect the directed edges between the node to be stripped and the other logical nodes in the control flow graph, and redirect the incoming and outgoing edges corresponding to the node to be stripped to the preset no-operation placeholder node to generate the abstract syntax tree that removes the underlying blockchain dependent instructions.

3. The WeChat Mini Program rights verification algorithm based on smart contracts according to claim 1, characterized in that, According to the syntax rules of the WeChat Mini Program WXS script engine, the stripped abstract syntax tree is converted into a WXS proxy script, including: traversing the basic syntax nodes in the abstract syntax tree and mapping the smart contract native data types in the basic syntax nodes to the corresponding data structures supported by the WXS script engine. For the loop control node and conditional branch node in the abstract syntax tree, the stack top operation logic inside the loop control node and the conditional branch node is rewritten as a register assignment operation based on the corresponding data structure, and the rewritten node sequence is encapsulated according to the execution entry format of the WXS script engine to generate the WXS proxy script.

4. The WeChat Mini Program rights verification algorithm based on smart contracts according to claim 1, characterized in that, Extracting the verification preconditions from the abstract syntax tree to construct a data validation expression includes: locating the base block containing the Require assertion statement in the abstract syntax tree, and extracting the logical operation tree contained in the Require assertion statement; Replace the on-chain state query operation in the logical operation tree with key-value pair parameter variables passed from the WeChat Mini Program, and replace the block height timestamp operation in the logical operation tree with the local clock timestamp variable of the WeChat Mini Program. The replaced logic operation tree is converted into a string format data verification expression using a preset logic operator concatenation function.

5. The WeChat Mini Program rights verification algorithm based on smart contracts according to claim 1, characterized in that, The process of calling the WXS proxy script in the local view layer to execute the data validation expression for precondition validation includes: instantiating an isolated WXS script execution context in the WeChat Mini Program view layer, and injecting the data validation expression and the rights and interests verification parameters into the WXS script execution context. Record the instruction pointer traversal order of the WXS agent script in the WXS script execution context and the register state change sequence corresponding to each instruction step; The execution trajectory signature is generated by hashing the instruction pointer traversal order and the register state change sequence. The execution trajectory signature and the equity revocation parameters are then encapsulated into the standard transaction body according to the preset transaction body serialization rules.

6. The WeChat Mini Program rights verification algorithm based on smart contracts according to claim 1, characterized in that, The smart contract compares the execution trajectory signature with its own pre-stored expected execution path to determine the validity of the write-off, including: after receiving the standard transaction body, the smart contract extracts the execution trajectory signature and the write-off parameters from the standard transaction body; The simulation execution environment inside the smart contract is invoked, the revocation parameters are input, and the original revocation function bytecode is executed. The simulation instruction pointer traversal path and simulation register change path output by the simulation execution environment are collected. The simulation signature is obtained by calculating the hash value of the simulation instruction pointer traversal path and the simulation register change path. The simulation signature is compared with the execution trajectory signature to see if they are consistent. Based on the comparison result, the verification validity judgment flag is output.

7. The WeChat Mini Program rights verification algorithm based on smart contracts according to claim 2, characterized in that, Redirecting the incoming and outgoing edges corresponding to the node to be stripped to a preset no-operation placeholder node includes: establishing a pool of no-operation placeholder nodes and assigning a unique no-operation placeholder node identifier to each external call instruction set marked as a node to be stripped. In the control flow graph, the endpoints of all predecessor directed edges pointing to the node to be stripped are modified to the corresponding assigned no-operation placeholder node identifiers, and the starting points of all successor directed edges pointing to the node to be stripped are modified to the corresponding assigned no-operation placeholder node identifiers. Configure a default return value constant corresponding to the identifier of the no-operation placeholder node in the no-operation placeholder node pool, and use the default return value constant as the data passed by the no-operation placeholder node to the subsequent directed edge.

8. The WeChat Mini Program rights verification algorithm based on smart contracts according to claim 3, characterized in that, Rewrite the stack top operation logic inside the loop control node and the conditional branch node into a register assignment operation based on the corresponding data structure, including: parsing the push and pop instructions inside the loop control node and the conditional branch node, and determining the stack offset corresponding to the push and pop instructions. Allocate a virtual register address space mapped to the stack offset in the corresponding data structure supported by the WXS script engine; The push instruction is rewritten as an assignment instruction to write data to the virtual register address space, and the pop instruction is rewritten as a read instruction to read data from the virtual register address space. The assignment instruction and the read instruction are arranged in the order of instructions in the control flow graph.

9. The WeChat Mini Program rights verification algorithm based on smart contracts according to claim 4, characterized in that, The on-chain state query operation in the logical operation tree is replaced with key-value pair parameter variables passed from the WeChat Mini Program, including: identifying leaf nodes in the logical operation tree that contain storage key name read operations; Obtain the latest on-chain state key-value pair corresponding to the storage key name read operation from the server cache, use the key name of the latest on-chain state key-value pair as the local storage index of the WeChat Mini Program, and encapsulate the value of the latest on-chain state key-value pair as the key-value pair parameter variable; In the logical operation tree, the key-value pair parameter variable is used to replace the leaf node containing the storage key name read operation, and a calling channel between the key-value pair parameter variable and the WeChat mini program local storage index is established.

10. The WeChat Mini Program rights verification algorithm based on smart contracts according to claim 5, characterized in that, Instantiating an isolated WXS script execution context in the WeChat Mini Program view layer includes: allocating a WXS execution thread independent of the rendering thread in the thread pool of the WeChat Mini Program view layer, and initializing a WXS script engine instance in the WXS execution thread. Build a restricted global object access whitelist for the WXS script engine instance to block the WXS script engine instance's access permissions to the WeChat Mini Program's native network interface and file system interface; An independent memory stack area is allocated in the WXS script engine instance, and the data verification expression and the rights revocation parameters are loaded into the memory stack area, restricting the WXS agent script to read and write data only in the memory stack area.

Images