Intelligent contract service platform based on double-layer architecture and red envelope hierarchical management method

Abstract

The application relates to the technical field of blockchains and smart contracts, and discloses a smart contract service platform based on a double-layer architecture and a red envelope hierarchical management and control method, which comprises an off-chain management layer and an on-chain execution layer. An off-chain object-level permission control module queries an access control list to verify the permission of an operation request; after verification, a key escrow service module uses an enterprise administrator private key to sign a transaction load to generate a blockchain transaction task; a task scheduling module sends the task to the on-chain execution layer to call a business smart contract, and combines a sponsorship white list to control the contract to automatically deduct a service charge from an enterprise account; a cross-layer data synchronization module captures on-chain events, and performs bottom-layer database state backwriting based on an epoch number and a transaction hash. The application decouples business logic from blockchain authorization, realizes enterprise-level strong management and control through pre-authentication and private key proxy signing, exempts users from service charges and automatically recovers and pays funds, simultaneously uses an anti-rollback mechanism to deal with block reorganization, and guarantees cross-layer data consistency.

Description

Technical Field

[0001] This invention relates to the field of blockchain and smart contract technology, specifically to a smart contract service platform based on a two-tier architecture and a method for hierarchical management of red envelopes. Background Technology

[0002] With the development of blockchain technology, smart contracts are widely used in the execution of various business data and the transfer of assets. However, the development of existing smart contract applications generally has a high barrier to entry. Developers need to master the underlying contract programming language and complex on-chain interaction logic, and often hardcode complex business rules into smart contracts, resulting in high coupling in the system architecture and long business launch cycles.

[0003] In enterprise-level application scenarios, native blockchain systems lack robust access control mechanisms, making it difficult to meet fine-grained operational authorization and auditing requirements. In existing solutions, the management logic of business rules and the execution logic of on-chain contracts are often independent, lacking a unified integration framework, leading to a disconnect between the system's management layer and the underlying execution layer. Furthermore, due to the low efficiency of on-chain data queries, off-chain systems struggle to obtain and synchronize on-chain transaction states in real time and accurately, easily resulting in poor data consistency between off-chain business databases and on-chain states.

[0004] Existing technologies contain numerous attempts at blockchain business interaction architecture. For example, patent document CN110363512B discloses a method, device, medium, and computer program for processing, creating, and receiving blockchain red envelopes. This method generates temporary keys off-chain and has the user directly sign them onto the blockchain. However, this lacks a pre-approval and interception mechanism, failing to achieve strong enterprise-level business control. Patent document CN114612087A proposes a blockchain-based anonymous red envelope receiving method; patent document CN116452200B discloses a method, device, electronic device, and storage medium for sending and receiving red envelopes. While these existing technologies improve the internal storage structure and privacy protection of smart contracts, they still require end-users to hold native tokens to pay underlying transaction fees, and none of these solutions provide an effective cross-layer data synchronization mechanism. When facing high concurrency of blockchain underlying network nodes or block reorganization, existing technologies lack robust anti-fork and deduplication mechanisms, failing to guarantee the eventual consistency between off-chain business systems and on-chain ledger data.

[0005] Therefore, this invention proposes a smart contract service platform based on a two-tier architecture and a hierarchical management method for red envelopes to address the shortcomings of existing technologies. Summary of the Invention

[0006] To address the shortcomings of existing technologies, this invention provides a smart contract service platform based on a two-layer architecture and a layered management method for red envelopes. This solves the problems in existing blockchain applications, such as the disconnect between business management and underlying execution, the lack of enterprise-level fine-grained permission control, the transaction fee threshold for end-user interaction, and the difficulty in maintaining eventual consistency of on-chain and off-chain business data when facing block reorganization and high concurrency.

[0007] To achieve the above objectives, the present invention provides the following technical solution: a smart contract service platform based on a two-tier architecture and a method for hierarchical management of red envelopes, comprising:

[0008] The off-chain management layer includes an object-level access control module, a key escrow service module, a task scheduling module, and a cross-layer data synchronization module;

[0009] The on-chain execution layer runs in the underlying network nodes of the blockchain and includes business smart contracts and sponsorship whitelist control contracts.

[0010] The object-level permission control module is used to extract the target object identifier and target operation type from the operation request, and query the access control list record table based on the target object identifier to verify whether the session identifier of the currently logged-in user has execution permission;

[0011] The key escrow service module is used to digitally sign the transaction payload corresponding to the operation request using the escrowed enterprise administrator's private key after the object-level permission control module has passed the verification, thereby generating a blockchain transaction task.

[0012] The task scheduling module is used to send blockchain transaction tasks to the on-chain execution layer and call the business smart contract to execute business logic; the business smart contract interacts with the sponsor whitelist control contract, and the sponsor account corresponding to the enterprise administrator's private key automatically deducts transaction fees and storage collateral fees;

[0013] The cross-layer data synchronization module is used to capture on-chain events triggered by business smart contracts and perform state write-back operations on the underlying database based on the epoch number and transaction hash of the block where the on-chain event is located.

[0014] Preferably, querying the access control list record table based on the target object identifier to verify whether the session identifier of the currently logged-in user has execution permissions includes:

[0015] Search the access control list record table for the user permission bitmask corresponding to the session identifier;

[0016] Perform a bitwise AND operation between the user permission bitmask and the target permission bitmask required to execute the target operation type to obtain the permission verification result value;

[0017] If the permission verification result is exactly equal to the target permission bitmask, the verification is deemed successful.

[0018] If the permission verification result is not equal to the target permission bitmask, an access denial exception is thrown and the operation request is terminated.

[0019] Preferably, the key escrow service module stores the enterprise administrator's private key through a hardware security module or a threshold signature algorithm;

[0020] The transaction payload corresponding to the operation request is digitally signed using the private key of the managed enterprise administrator, including:

[0021] The elliptic curve digital signature algorithm is invoked, and the hash digest of the transaction payload is cryptographically calculated using the private key of the enterprise administrator to generate a signature result containing a recovery identifier and an integer component. The signature result is then appended to the transaction payload to constitute the blockchain transaction task.

[0022] Preferably, the off-chain management layer further includes a contract factory module;

[0023] The contract factory module is used to perform encoding operations on the business parameter set according to the preset application binary interface data specification, and append the encoded data to the end of the smart contract bytecode to assemble and generate the contract deployment payload, so as to instantiate and deploy the business smart contract at the on-chain execution layer.

[0024] The sponsorship whitelist control contract is used to receive payment binding call instructions after the business smart contract is deployed, set the transaction fee payer and storage collateral fee payer of the business smart contract to the enterprise administrator account corresponding to the enterprise administrator's private key, and add the zero address to the call whitelist of the business smart contract to realize passwordless payment for external account address calls.

[0025] Preferably, the sponsorship whitelist control contract is also used to verify whether the signing entity of the fund withdrawal instruction is the enterprise administrator account corresponding to the enterprise administrator's private key when receiving the fund withdrawal instruction sent by the off-chain system.

[0026] If the verification is successful, the sponsorship whitelist control contract will execute the payment unbinding and refund operation. Based on the state accounting model of the underlying blockchain network nodes, the total amount of the initial deposited payment deposit will be deducted from the total amount of transaction fees and storage collateral fees consumed during the event period to calculate the remaining unconsumed payment deposit to be recovered, and the remaining unconsumed payment deposit will be returned to the enterprise administrator account corresponding to the enterprise administrator's private key.

[0027] Preferably, the underlying database state write-back operation is performed based on the epoch number and transaction hash of the block where the on-chain event is located, including:

[0028] Extract the epoch number of the original block from the metadata of the on-chain event, and obtain the latest epoch height of the underlying network node of the blockchain;

[0029] Calculate the difference between the latest epoch height and the epoch number, and use it as the number of consensus cycles that the on-chain event has gone through;

[0030] Verify whether the number of consensus cycles is greater than or equal to the preset anti-rollback confirmation threshold;

[0031] If the consensus cycle number is greater than or equal to the anti-rollback confirmation number threshold, then query the underlying blockchain network node for the transaction receipt corresponding to the on-chain event, and enter the state write-back operation after the transaction receipt is verified.

[0032] Preferably, the state write-back operation includes:

[0033] Extract the transaction hash carried in the on-chain event and map the transaction hash to a unique key in the underlying database business table structure;

[0034] The on-chain event parameters with the unique key are constructed into a state update request and sent to the database engine layer;

[0035] The unique indexing mechanism of the database engine layer is used to verify whether the transaction hash is duplicated in the business table structure.

[0036] If no duplicates are detected, the business data status of the underlying database is updated based on the on-chain event parameters.

[0037] Preferably, the task scheduling module uses a buffer queue of the memory database to receive and cache concurrent operation requests;

[0038] Before converting the operation request into a standard request object and pushing it into the buffer queue, the number of unprocessed requests is counted, and it is determined whether the number of unprocessed requests has reached the upper limit threshold of the queue length.

[0039] The upper limit threshold for queue length is calculated by dividing the maximum available memory capacity allocated to the memory database by the average number of bytes occupied by a single standard request object, and multiplying by a preset safety buffer coefficient.

[0040] Preferably, the off-chain management layer further includes a dual-logging audit module; the dual-logging audit module is used to perform dual-logging audit traceability operations, including:

[0041] Using a time window as a constraint, extract the transaction details of the red envelope objects recorded in the underlying database, and obtain the historical transaction records of the corresponding business smart contract in the on-chain execution layer;

[0042] Based on the transaction hash, the red packet object transaction details in the underlying database are aligned with the historical transaction records of the on-chain execution layer;

[0043] The first total amount is obtained by summing the recorded amounts of all red packet object transaction details in the underlying database, and the second total amount is obtained by summing the recorded amounts of historical transactions in the on-chain execution layer.

[0044] Calculate the ledger deviation value between the first total amount and the second total amount, and trigger an alarm work order when the ledger deviation value is not equal to zero.

[0045] This invention also provides a two-tier architecture-based method for hierarchical management of red envelopes, comprising the following steps:

[0046] The object-level permission control module of the off-chain management layer extracts the red packet object identifier and target operation type from the red packet distribution operation request. Based on the red packet object identifier, the access control list record table is queried to verify whether the session identifier of the currently logged-in user has execution permission.

[0047] After the object-level permission control module passes the verification, the key escrow service module uses the escrow enterprise administrator's private key to digitally sign the transaction payload corresponding to the red packet distribution operation request, generating a blockchain transaction task.

[0048] The task scheduling module sends the blockchain transaction task to the on-chain execution layer, calls the business smart contract to execute the business logic, and interacts with the sponsor whitelist control contract during the execution. The transaction fee and storage collateral fee are automatically deducted by the sponsor account corresponding to the enterprise administrator's private key.

[0049] The cross-layer data synchronization module captures on-chain events triggered by the business smart contract and performs a state write-back operation on the underlying database based on the epoch number and transaction hash of the block where the on-chain event is located.

[0050] The smart contract service platform and red envelope hierarchical management method based on a two-tier architecture provided by this invention have the following beneficial effects:

[0051] This invention constructs a two-layer architecture comprising an off-chain management layer and an on-chain execution layer. The off-chain management layer handles business judgments and task scheduling for operation requests, while the on-chain execution layer uses smart contracts to handle core asset and state settlement. This architecture separates complex business rule management from the underlying blockchain data ownership confirmation, preserving the immutability of blockchain data while overcoming the limitation of smart contracts in directly handling complex business logic such as multi-level approvals.

[0052] This invention uses an object-level permission control module to compare and verify operation requests against the access control list record table. Upon successful verification, it triggers a key escrow service module to digitally sign the transaction payload using the enterprise administrator's private key. This mechanism changes the conventional method of users directly signing to initiate blockchain transactions, placing the verification of operation permissions off-chain. This achieves permission interception of invalid requests with zero transaction fee (Gas) loss; it ensures that only legitimate requests authorized by the enterprise can generate blockchain transaction tasks, thereby enabling the enterprise to enforce control over operational behavior at the underlying blockchain network nodes.

[0053] This invention uses a sponsorship whitelist control contract to set the payment party for transaction fees and storage deposit fees of business smart contracts to the account corresponding to the enterprise administrator's private key. Upon receiving a fund withdrawal instruction, it automatically calculates and returns any remaining unused deposit. This solution allows ordinary users to access smart contracts without incurring various transaction fees from the underlying blockchain network nodes, achieving a seamless interactive experience. Furthermore, by dynamically calculating the difference between the initial deposited funds and the accumulated consumed funds, it automatically recovers any remaining deposited funds after the transaction ends, preventing the ineffective accumulation and occupation of enterprise funds in the blockchain account.

[0054] This invention extracts the epoch number of on-chain events through a cross-layer data synchronization module to calculate the number of consensus cycles. When the number of consensus cycles reaches the anti-rollback confirmation threshold, it utilizes the unique index mechanism of the underlying database engine to perform a state writeback based on the transaction hash. This solution effectively addresses the potential block reorganization phenomenon in the underlying blockchain network nodes by introducing delayed confirmation judgment and hash unique key deduplication operations. It achieves idempotent anti-collision updates in high-concurrency scenarios and completely solves the technical problem of inconsistent data between the underlying database and on-chain business data. Attached Figure Description

[0055] Figure 1 This is an architecture diagram of a smart contract service platform based on a two-tier architecture, according to an embodiment of the present invention.

[0056] Figure 2 This is a schematic diagram of the macro-interaction sequence of on-chain automated deployment and payment configuration in an embodiment of the present invention;

[0057] Figure 3 This is a detailed execution timing diagram of the on-chain automated deployment and payment configuration in an embodiment of the present invention;

[0058] Figure 4 This is a schematic diagram of the object-level permission control and signature submission process according to an embodiment of the present invention;

[0059] Figure 5 This is a schematic diagram of the entire lifecycle process of hierarchical management of red envelope distribution according to an embodiment of the present invention.

[0060] Among them, 100 is the off-chain management layer; 110 is the unified identity authentication module; 120 is the object-level permission control module; 130 is the key escrow service module; 140 is the task scheduling module; 150 is the contract factory module; 160 is the cross-layer data synchronization module; 200 is the on-chain execution layer; 210 is the business smart contract; and 220 is the sponsor whitelist control contract. Detailed Implementation

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

[0062] See Figure 1 This invention provides a smart contract service platform based on a two-layer architecture. This platform, as the concrete implementation carrier of the core SCaaS (Smart Contract as a Service) service, can include an off-chain management layer 100 and an on-chain execution layer 200. The SCaaS core service aims to encapsulate the complex interactions between underlying blockchain network nodes, smart contract lifecycle management, and enterprise-level pre-approval of permissions into standardized middleware capabilities, thereby shielding the application side from the technical complexity of the underlying blockchain network nodes.

[0063] The off-chain management layer 100 is deployed on a private cloud or independent server. As the off-chain scheduling hub of the core SCaaS service, the off-chain management layer 100 is used to handle business logic judgment, permission verification, identity authentication and task scheduling.

[0064] The off-chain management layer 100 includes a unified identity authentication module 110, an object-level access control module 120, a key escrow service module 130, a task scheduling module 140, a contract factory module 150, and a cross-layer data synchronization module 160.

[0065] The unified identity authentication module 110 is used to manage enterprise employee accounts and assign operation tokens after employees log in. The unified identity authentication module 110 does not directly store and manage blockchain private keys.

[0066] The object-level permission control module 120 is used to intercept user-initiated operation requests and perform object-based execution permission verification.

[0067] The Contract Factory module 150 is used to store and manage pre-built smart contract templates.

[0068] The key escrow service module 130 is used to escrow the private key of the enterprise administrator using a hardware security module or threshold signature technology. After receiving a verification pass instruction from the object-level access control module 120, the key escrow service module 130 signs the transaction payload.

[0069] The task scheduling module 140 is used to receive operation requests based on a queue mechanism, serialize the operation requests into standard request objects, and construct asynchronous blockchain transaction tasks to be signed; after receiving the signature result returned by the key custody service module 130, it forms a signed asynchronous blockchain transaction task and sends it to the underlying blockchain network node.

[0070] The cross-layer data synchronization module 160 is used to establish a connection with the underlying network nodes of the blockchain, subscribe to or receive the underlying block logs / events pushed by the underlying network nodes of the blockchain, and trigger event notifications.

[0071] The on-chain execution layer 200 runs within the underlying network nodes of the public blockchain. It includes a business smart contract 210 and a sponsor whitelist control contract 220. The business smart contract 210 contains the execution code for core asset transfers and state changes. The sponsor whitelist control contract 220 belongs to the blockchain's underlying network node protocol layer and is used to manage the automated payment of transaction fees and storage collateral fees.

[0072] This invention provides a management and control method for a smart contract service platform based on a two-tier architecture, comprising the following steps:

[0073] S100, the off-chain management layer 100 obtains the operation request initiated by the user in the front-end interface, which includes the target object identifier and the target operation type, and first intercepts the operation request through aspects of Aspect-Oriented Programming (AOP);

[0074] S200, in the off-chain management layer 100, the target object identifier in the operation request is extracted through the object-level permission control module 120, the preset access control list record table is queried, the session identifier of the current logged-in user is compared with the permission bitmask associated in the access control list record table, and the session identifier of the current logged-in user is verified to have the execution permission of the target object.

[0075] S300: If the verification fails, the system will directly throw an access denial exception, refuse to build the blockchain transaction task, and will not send any data to the underlying blockchain network nodes, thus achieving zero transaction fee (Gas) loss in permission interception.

[0076] S400, if the verification passes, the task scheduling module 140 constructs a blockchain transaction task to be signed based on the operation request and calls the key custody service module 130; the key custody service module 130 uses the private key of the custodian enterprise administrator to sign the transaction payload corresponding to the blockchain transaction task and returns the signature result or signed transaction data to the task scheduling module 140.

[0077] S500, the task scheduling module 140 broadcasts the signed blockchain transaction task to the underlying blockchain network node in the on-chain execution layer 200, and the underlying blockchain network node calls the business smart contract 210 to execute the core logic; during the execution, the business smart contract 210 interacts with the sponsor whitelist control contract 220 based on the pre-completed payment configuration, thereby triggering the sponsor account corresponding to the enterprise administrator account to pay the transaction fee (Gas) and storage collateral fee consumed by the blockchain transaction task.

[0078] S600, the cross-layer data synchronization module 160 captures on-chain events triggered by the business smart contract 210, extracts the epoch number of the block where the on-chain event is located, and after the epoch number is confirmed after a preset number of consensus cycles, the database update is performed using the transaction hash of the on-chain event as the unique key. If a duplicate event notification with the same transaction hash is received, it is automatically ignored using the unique index, and the state is written back to ensure real-time data consistency.

[0079] To further clarify the implementation of each technical aspect of the present invention, the following will provide a detailed description of the implementation of each functional module involved above and its internal processing flow.

[0080] In this embodiment, in order to efficiently handle high-concurrency user requests while ensuring the security of underlying assets, the off-chain management layer 100 includes a unified identity authentication module 110, an object-level permission control module 120, a key escrow service module 130, a task scheduling module 140, a contract factory module 150, and a cross-layer data synchronization module 160.

[0081] The following focuses on the unified identity authentication module 110, the contract factory module 150, and the task scheduling module 140.

[0082] The unified identity authentication module 110 connects to the enterprise's existing domain account system to manage operator identities and issues temporary session identifiers and operation tokens to operators after they log in. As a specific implementation method, to achieve the aforementioned physical isolation and permission issuance, the specific operating logic of the unified identity authentication module 110 may include the following steps:

[0083] S111, the unified identity authentication module 110 receives a user login request from the front-end interface and extracts the user credential information carried in the login request. This credential information is then sent to the enterprise's existing domain account system for comparison to verify the true identity of the currently logged-in user. The identity verification and lightweight directory access protocol interaction method of the domain account system can be implemented using existing domain controller service interfaces, which are well-known technologies in the field and will not be elaborated upon here.

[0084] S112, after the domain account system returns a successful verification response, the unified identity authentication module 110 calls a secure hash algorithm (such as the SHA-256 algorithm) to generate a globally unique temporary session identifier for the currently logged-in user, and issues an operation token based on asymmetric encryption technology combined with the OAuth2 protocol standard (such as using the Spring Security OAuth2 framework). The data structure of the operation token includes the temporary session identifier, the role field of the currently logged-in user, and a valid timestamp.

[0085] S113, the unified identity authentication module 110 establishes an identity mapping table for the currently logged-in user in a relational database, records the binding relationship between the employee's employee number and the temporary session identifier, and returns the operation token to the front-end interface for subsequent requests. As a preferred isolation security mechanism, neither the unified identity authentication module 110 nor the identity mapping table stores any blockchain private key data, achieving physical isolation between the user's identity and the underlying blockchain network node assets through data structure-level isolation.

[0086] After verifying the operator's identity, the contract factory module 150 stores pre-built smart contract bytecode and application binary interface data in the database, receives front-end parameters, and assembles the contract deployment payload for the corresponding business scenario, based on specific on-chain business deployment requirements. The specific operation steps of the contract factory module 150 are as follows:

[0087] S121, System Initialization Phase: The contract factory module 150 establishes a smart contract template table in a relational database. The smart contract template table includes a template number, business type, smart contract bytecode compiled using the Solidity language, and application binary interface data fields. The compilation process of the smart contract source code and the underlying bytecode generation rules can be completed by those skilled in the art using existing compiler tools; these are well-known technologies in the field and will not be elaborated upon here.

[0088] S122, Contract Factory Module 150 receives a contract creation request initiated by the front-end interface and extracts the business type identifier and business parameter set from the contract creation request.

[0089] S123, Contract Factory Module 150 accesses the smart contract template table using the business type identifier as the query condition, and reads the corresponding smart contract bytecode and application binary interface data.

[0090] S124, In this embodiment, considering that in a virtual machine or a compatible underlying smart contract system, contract deployment requires not only core logic code but also initialization parameters encoded according to specific rules, the contract factory module 150 performs encoding conversion operations on the business parameter set according to the parameter type specifications defined in the application binary interface data, appends the encoded data to the end of the smart contract bytecode, and assembles and generates the contract deployment payload. The contract deployment payload calculation formula is as follows:

[0091] ;

[0092] In the formula, Deploy payloads for contracts in byte array format. The smart contract bytecode read from the smart contract template table. This is a specification encoding function for using binary interface data, used to convert variables of high-level language types into fixed-length hexadecimal strings. For a set of business parameters, This is a byte concatenation operator. The purpose of this concatenation step is to generate a complete transaction data stream that conforms to the standards executable by the underlying network node virtual machine of the blockchain.

[0093] During the generation of the aforementioned contract deployment payload or the processing of routine business requests, to prevent system downtime due to sudden traffic surges, the task scheduling module 140 utilizes the queue structure of an in-memory database (preferably a Redis database) to receive and cache concurrent business operation requests, and sequentially constructs the cached operation requests into asynchronous blockchain transaction tasks awaiting signature. Upon receiving the signature result returned by the key escrow service module 130, a broadcastable signed blockchain transaction task is formed. The specific operating steps of the task scheduling module 140 are as follows:

[0094] S131, the task scheduling module 140 receives concurrent operation requests from the front-end interface. The task scheduling module 140 counts the number of unprocessed requests currently in the memory database and determines whether the number of unprocessed requests has reached a preset queue length upper limit threshold. As a preferred method, to avoid decision dead zones caused by a single indicator and abnormal situations where the denominator approaches zero during processing calculations, this queue length upper limit threshold is determined based on multi-dimensional system load status. Specifically, the maximum available memory capacity allocated to the memory database is obtained as the numerator, and a division operation is performed using the pre-statistically calculated average number of bytes occupied by a single standard request object as the denominator. If the real-time statistically calculated average number of bytes occupied approaches zero or is lower than the preset minimum safe memory byte count, the preset minimum safe memory byte count is forcibly used as the divisor denominator to prevent division by zero errors. Then, the quotient is multiplied by a safety buffer coefficient ranging from 0.6 to 0.8 to obtain the queue length upper limit threshold.

[0095] S132, if the number of unprocessed requests reaches or exceeds the upper limit of the queue length, the task scheduling module 140 directly returns a system busy response message to the front-end interface. If the number of unprocessed requests does not reach the upper limit of the queue length, the task scheduling module 140 serializes the operation request into a standard request object and pushes the standard request object to the end of the buffer queue of the memory database.

[0096] S133, In this embodiment, to prevent task loss due to unexpected process termination, the task scheduling module 140 runs an independent background consumption daemon thread. The background consumption daemon thread pops standard request objects from the head of the memory database buffer queue in a loop according to the first-in-first-out extraction rule.

[0097] S134, the task scheduling module 140 parses the pop-up standard request object, extracts the target operation type and data payload, and constructs an asynchronous blockchain transaction task to be signed by combining the contract deployment payload generated by the contract factory module 150; the task scheduling module 140 assigns a transaction task serial number to the blockchain transaction task, and writes the transaction task serial number into a relational database after establishing a mapping relationship between the transaction task serial number and the blockchain transaction task to be signed; after receiving the signature result returned by the key custody service module 130, the task scheduling module 140 forms a signed asynchronous blockchain transaction task and broadcasts it to the underlying blockchain network nodes.

[0098] In this embodiment, the off-chain management layer 100 implements enterprise-level off-chain access control through the object-level permission control module 120 and the key escrow service module 130 to ensure the security and compliance of the interaction between the underlying network nodes of the blockchain.

[0099] The object-level access control module 120 intercepts operation requests initiated by the frontend at the application layer gateway using aspect-oriented programming (AOP). As a preferred approach, to reduce the coupling between business logic and security authentication logic, see [reference needed]. Figure 4 It demonstrates the object-level permission control and signature submission process. The specific operating logic of the object-level permission control module 120 may include the following steps:

[0100] S211, the object-level permission control module 120 receives the operation request transmitted from the front-end interface. In this embodiment, the object-level permission control module 120 intercepts the request by configuring an aspect-oriented mechanism. Before the operation request enters the core business logic processing unit, it parses the message and extracts the target object identifier and the target operation type. The underlying dynamic proxy mechanism and pointcut configuration method of aspect-oriented programming can be implemented using existing object-oriented programming frameworks by those skilled in the art, and are well-known technologies in the field, so they will not be described in detail here.

[0101] S212, the object-level access control module 120 queries a pre-set access control list record table (e.g., the relational database ACL_ENTRY table) in a relational database based on the extracted target object identifier. This access control list record table stores the session identifier (SID) of the authorized user associated with each target object identifier in the system, as well as the execution permission bitmask corresponding to that session identifier. As a preferred exception handling mechanism, to avoid algorithmic logic dead zones in the query matching process, if the object-level access control module 120 does not find a record matching the session identifier (SID) of the currently logged-in user in the access control list record table (e.g., the relational database ACL_ENTRY table), it forcibly assigns a default permission bitmask with a value of zero, thereby preventing security vulnerabilities caused by null pointer exceptions in subsequent calculations.

[0102] S213. Considering that in the low-level instruction operation of computers, bitmasking technology can abstract and map complex permission sets into a single integer binary bit, and use the registers of the central processing unit for bitwise calculation, thereby greatly reducing the system's memory overhead and improving the judgment speed, this embodiment uses bitmasking technology for permission comparison based on this general technical principle. The object-level permission control module 120 reads the session identifier of the currently logged-in user and looks up the user permission bitmask corresponding to the session identifier in the access control list record table (as a preferred method, its data structure is a 32-bit or 64-bit unsigned integer), and then performs a bitwise AND operation with the target permission bitmask required to execute the target operation type (e.g., bitmask 16 corresponding to the EXECUTE execution permission). The specific bitwise operation verification formula is as follows:

[0103] ;

[0104] In the formula, This is the value of the permission verification result. This is the user permission bitmask corresponding to the session identifier of the currently logged-in user in the access control list record table. The target permission bitmask required to perform the target operation type. This is the bitwise AND operator. The purpose of this bitwise AND operation is to utilize the bit processing characteristics of low-level computer instructions to achieve extremely low-latency determination of the status of permission sets.

[0105] S214, Object-level access control module 120 determines the access verification result value. Does it match the target permission bitmask? If the two are completely equal, it indicates that the currently logged-in user has the necessary permissions to perform the target operation type. The object-level permission control module 120 determines that the verification is successful and outputs a verification success instruction to the key escrow service module 130 to trigger the subsequent signature process. If the two are not equal, it indicates that the currently logged-in user lacks the corresponding operation authorization. The object-level permission control module 120 directly throws an access denial exception instruction (e.g., Access Denied Exception).

[0106] S215, after throwing an access denial exception command, the object-level permission control module 120 immediately terminates the task flow of the current operation request and returns an insufficient permission prompt message to the front-end interface. In this embodiment, this blocking mechanism can intercept all invalid or unauthorized requests at the off-chain management layer 100, preventing them from being converted into blockchain transactions and entering the underlying public blockchain network nodes. This avoids invalid requests occupying the storage and computing resources of the underlying blockchain network nodes, achieving permission interception with zero transaction fee (Gas) loss.

[0107] After the object-level access control module 120 completes the preliminary access verification, the key escrow service module 130 is responsible for subsequent secure signature authorization. As a specific implementation, the specific operating steps of the key escrow service module 130 are as follows:

[0108] S221, the key escrow service module 130 centrally stores the enterprise administrator's blockchain private key through a hardware security module or a threshold signature algorithm. In this embodiment, the hardware security module provides tamper-proof protection at the level of physical isolation, and the threshold signature algorithm divides the blockchain private key into multiple encrypted fragments through multi-party secure computation and distributes them across different nodes. For the underlying instruction set specification of the hardware security module and the key distribution algorithm of the threshold signature algorithm, those skilled in the art can use existing cryptographic standard libraries for implementation; these are well-known technologies in the field and will not be elaborated upon here.

[0109] S222, the key escrow service module 130 remains in a dormant or listening state during normal operation. As a preferred triggering mechanism, the key escrow service module 130 is conditionally triggered to enter the signature process and extract the transformed transaction payload corresponding to the operation request only when it accurately receives the verification pass instruction output by the object-level permission control module 120.

[0110] S223. Considering that in the underlying network nodes of a public blockchain, to ensure the authenticity of digital asset transfers, transaction data must undergo a specific cryptographic curve signature before it can be verified by the consensus of the underlying distributed nodes. Based on this requirement, the key escrow service module 130 calls the internally encapsulated elliptic curve digital signature algorithm (for example, using the network-compatible secp256k1 standard curve as a preferred method), uses the escrow enterprise administrator's private key to cryptographically sign the hash value of the transaction payload, and generates the signature result for the corresponding underlying network node of the blockchain. The specific digital signature calculation formula is as follows:

[0111] ;

[0112] In the formula, The generated signature result has a data structure that consists of a standard blockchain signature tuple containing a recovery identifier and two large integer components. For elliptic curve digital signature functions, The private key for the enterprise administrator, which is hosted in the key hosting service module 130, is a 256-bit hexadecimal private key scalar. For a secure hash algorithm function (as a preferred option, the Keccak-256 algorithm is used to compress variable-length data into a fixed-length digest to prevent hash collisions), This signature step represents the transaction payload corresponding to the operation request. It uses the enterprise administrator's credentials to provide a non-repudiable endorsement of the transaction payload, ensuring that the blockchain transaction containing this signature can be legally verified and accepted by the consensus network composed of the underlying blockchain nodes. It is important to emphasize that this step essentially involves the off-chain object-level permission control module 120 endorsing the operator's permissions, and using the enterprise administrator's private key for interaction on the blockchain, rather than the operator's or user's personal private key. This creates an enterprise-level permissioned interaction model on the public blockchain.

[0113] In this embodiment, in addition to the aforementioned off-chain management layer 100, the system architecture also includes an on-chain execution layer 200 running on the underlying network nodes of the public blockchain (preferably, using the Conflux blockchain underlying network nodes compatible with virtual machines). The on-chain execution layer 200, as the underlying trust anchoring environment, mainly includes business smart contracts 210 and sponsorship whitelist control contracts 220, responsible for the atomic transfer of core assets and the operation of the underlying payment mechanism.

[0114] The business smart contract 210 (e.g., a red envelope contract written in Solidity as a specific implementation) executes the corresponding digital asset cross-address transfer logic based on the input parameters. To reduce on-chain transaction fees and mitigate security risks, the business smart contract 210 adheres to the principle of logic minimization, retaining only the core fund transfer logic. As a preferred implementation, its operational logic may include the following steps:

[0115] S311, In this embodiment, the business smart contract 210 receives the set of business initialization parameters (including but not limited to total assets, number of allocations, preset upper limit of single allocation amount, preset lower limit of single allocation amount, and activity validity period threshold) passed in by the off-chain system during the deployment phase, and completes instantiation and compilation in the underlying network node of the blockchain to generate a globally unique contract address.

[0116] In step S312, business smart contract 210 receives an asset claim request (e.g., calling the `claim` method) initiated by an external account address. Before processing the core logic, business smart contract 210 extracts the current blockchain underlying network node timestamp and determines whether this timestamp is less than a preset activity validity period threshold. Simultaneously, business smart contract 210 verifies whether the external account address already exists in the claimed record mapping table of the internal state storage. As a preferred exception handling mechanism, if any verification fails, business smart contract 210 will trigger a state rollback instruction from the underlying virtual machine, forcibly terminating the current transaction.

[0117] S313, assuming successful verification, considering that the smart contract cannot directly read the actual physical random number source, this embodiment uses hash operations combined with the current block state parameters to generate pseudo-random numbers to achieve randomness in digital asset allocation. Specifically, the business smart contract 210 extracts the generation timestamp of the current block and the external account address that initiated the call, concatenates them, inputs them into a hash function, then converts the output fixed-length hash digest into an unsigned large integer, and performs a modulo operation based on a preset amount range to calculate the asset allocation amount that the external account address should receive. The specific random amount allocation calculation formula is as follows:

[0118] ;

[0119] In the formula, For the calculated asset allocation amount, the data type is preferably a 256-bit unsigned integer, and the unit is the basic unit of the underlying blockchain network node (e.g., Wei). This is a data type conversion function used to parse a byte string into a large integer; For secure hashing algorithm functions; This is the timestamp of the current block's creation, measured in seconds. The external account address that initiated the call; its structure is a 160-bit hexadecimal value. The preset maximum amount that can be allocated per transaction; This is a preset minimum allocation amount for a single transaction; The modulo operator is used. To prevent underlying virtual machine crashes caused by division by zero during the modulo operation, the business smart contract 210 forcibly verifies whether the difference between the upper and lower limits of the single allocation amount is strictly greater than zero before executing the formula. If the difference is equal to zero, the upper limit of the single allocation amount is directly used as the asset allocation amount. This calculation step utilizes the inherent state variables of the underlying blockchain network nodes to generate unpredictable allocation values ​​to meet the random distribution requirements in marketing scenarios. In addition, as an equivalent alternative implementation, the business smart contract 210 can also obtain secure off-chain random numbers and calculate asset allocation amounts by accessing a Verifiable Random Function (VRF) oracle; this invention does not limit this to a single method.

[0120] S314, In this embodiment, the business smart contract 210 will be equivalent to the asset allocation amount. The native token (such as the CFX token) or digital token is transferred from the contract address account to the external account address in an atomic operation. The atomic operation ensures that the asset transfer process is indivisible and avoids the abnormal intermediate state where funds are deducted but not received.

[0121] S315, after the transfer is completed, the business smart contract 210 triggers a claim success event (e.g., a Claim Success event) containing transaction details (e.g., external account address and asset allocation amount). This event, as a tamper-proof state locking credential, is permanently recorded in the blockchain's log tree structure for subsequent event-driven framework listening and writing back. The data structure and event publishing principle of the blockchain's underlying network node log tree can be implemented by those skilled in the art using existing blockchain underlying network node storage mechanisms, which are well-known technologies in the field and will not be elaborated upon here.

[0122] During the interaction of the aforementioned business smart contract 210, to achieve a zero-transaction-fee user experience, the platform introduces a sponsor whitelist control contract 220 (e.g., a Sponsor Whitelist Control contract in the Conflux protocol layer) for payment configuration. As a specific implementation method, the implementation steps of the sponsor whitelist control contract 220 are as follows:

[0123] S321, the sponsor whitelist control contract 220 receives the payment binding call instruction sent by the off-chain system immediately after the business smart contract 210 is deployed.

[0124] S322, the sponsor whitelist control contract 220 extracts the target contract address parameter and the payment limit parameter from the call instruction, executes the transaction fee payment binding operation (e.g., calling the set Sponsor For Gas method), forces the transaction fee payer of the specific business smart contract 210 to be set to the enterprise administrator account, and simultaneously sets the upper limit of gas resources for each transaction payment to prevent malicious calls from exhausting the payment fund pool.

[0125] S323, the sponsor whitelist control contract 220 extracts the collateral parameters from the call instruction, executes the storage collateral fee payment binding operation (e.g., calling the set Sponsor For Collateral method), and synchronously sets the underlying storage collateral fee payer of the corresponding business smart contract 210 to the enterprise administrator account.

[0126] S324, the sponsorship whitelist control contract 220 extracts the whitelist array parameter from the call instruction and adds the zero address (i.e., 0x00000000000000000000000000000000000000000) to the call whitelist of the business smart contract 210 (e.g., by calling the addPrivilege method). In this embodiment, the underlying purpose of adding the zero address to the whitelist is to enable global password-free payment authorization. Since the underlying protocol of this system (e.g., the Conflux sponsorship mechanism) determines that the zero address represents all external accounts (i.e., a global wildcard), this configuration allows the system to automatically exempt any user address from verifying and deducting its own account balance when calling the business smart contract 210. All transaction fees and storage collateral fees consumed are deducted from the payment pool of the enterprise administrator account, thereby achieving seamless interaction at the user level.

[0127] As business progresses, traditional payment mechanisms often result in a large amount of deposits being tied up in the underlying blockchain network nodes after the event ends. To improve the efficiency of corporate fund turnover, the platform has built an automated fund recovery mechanism based on the sponsor whitelist control contract 220. The specific implementation steps are as follows:

[0128] S331, the system continuously compares the current time with the activity validity period threshold set by the business smart contract 210 through off-chain timed tasks, or as an alternative, it listens for specific lifecycle termination events issued by the business smart contract 210.

[0129] S332, when it is determined that the business activity lifecycle has ended, the system automatically constructs and sends a fund withdrawal instruction to the sponsor whitelist control contract 220.

[0130] S333, the sponsorship whitelist control contract 220 verifies whether the cryptographic signature subject of the fund withdrawal instruction belongs to the authorized enterprise administrator account. Upon successful verification, the sponsorship whitelist control contract 220 executes the payment unbinding and refund operations. Because the underlying blockchain network node protocol maintains the state variables of the payment pool in real time, there is no need for computationally intensive traversal and accumulation operations within the contract. The system directly calculates and returns the remaining unspent balance based on the underlying state accounting model. The underlying formula for the remaining fund recovery state settlement is as follows:

[0131] ;

[0132] In the formula, The remaining unused deposit that should be recovered is a data type of unsigned large integer. This represents the total amount of the deposit made during the initial stage. This represents the total transaction fees incurred for this contract during the event period. This represents the total storage collateral fee accumulated for this contract during the event period. This recovery and settlement step can accurately separate the on-chain resource consumption that has occurred, and safely return the idle remaining collateral to the enterprise administrator's account, preventing the permanent locking or accumulation of digital assets due to the end of the business smart contract's 210 lifecycle, thereby achieving closed-loop management of the entire lifecycle of enterprise payment funds.

[0133] In the actual operating environment of smart contracts, due to the decentralized distributed consensus mechanism of public blockchain underlying network nodes, temporary block forks and state rollbacks may occur when there is network latency or node state asynchrony. To ensure accurate and consistent synchronization between the asset change results of the on-chain execution layer 200 and the business state of the off-chain management layer 100, the system architecture in this embodiment also includes a cross-layer data synchronization module 160. The cross-layer data synchronization module 160 is used to solve the data inconsistency problem caused by blockchain forks and realize a closed loop of business state across the entire chain. As a preferred specific implementation, the operating logic of the cross-layer data synchronization module 160 may include the following steps:

[0134] S411, in this embodiment, the blockchain listener in the cross-layer data synchronization module 160 establishes a network communication connection with the underlying blockchain network node through an application programming interface (preferably, using a WebSocket long connection or HTTP polling mechanism via a development toolkit such as the Conflux Java SDK), and sends a subscription instruction to the underlying blockchain network node to continuously listen to and subscribe to the underlying block logs / events corresponding to the address where the business smart contract 210 is located. The establishment of the communication connection with the underlying blockchain network node and the log polling mechanism can be implemented by those skilled in the art using existing software development toolkits, which are well-known technologies in the field and will not be elaborated upon here.

[0135] S412, when the business smart contract 210 triggers a specific event (such as the aforementioned successful retrieval event) and it is recorded in the block, the cross-layer data synchronization module 160 parses the parameter payload in the underlying block log and converts it into an application event (such as a Spring Application Event) that the backend service framework can recognize. During this process, the cross-layer data synchronization module 160 does not directly process the business logic, but instead publishes the application event to the system's internal event bus (Spring Event Bus) for asynchronous scheduling.

[0136] To address the aforementioned asynchronous acquisition of application events and prevent minor forks and state rollbacks caused by latency in the underlying blockchain network nodes or malicious computing power attacks, the cross-layer data synchronization module 160 in this embodiment introduces an anti-fork confirmation mechanism based on the general probabilistic final confirmation principle. Since the selection of the blockchain's main chain follows the principle of longest chain or highest weight, as the number of subsequently attached blocks increases, the probability of the original block containing the target transaction being isolated and rolled back across the entire network decreases exponentially. Based on this principle, the specific implementation steps are as follows:

[0137] S421, the transactional event listener (e.g., Transactional EventListener) in the cross-layer data synchronization module 160 receives the aforementioned application events and extracts the epoch number of the original block corresponding to the event from the metadata of the application events. The epoch number is a state parameter in the underlying blockchain network node protocol used to identify the consensus cycle progression sequence.

[0138] S422, as a specific implementation method, the cross-layer data synchronization module 160 periodically obtains the latest epoch height of the underlying blockchain network nodes through continuous interaction. Based on the epoch number of the original block and the latest epoch height, the cross-layer data synchronization module 160 calculates the number of consensus cycles that the application event has undergone and determines whether it has reached the preset anti-rollback confirmation threshold. The specific anti-fork confirmation determination formula is as follows:

[0139] ;

[0140] In the formula, The number of consensus cycles that the application event has gone through; its data type is an unsigned integer. The latest epoch height of the blockchain obtained by the cross-layer data synchronization module 160 is an unsigned integer. The epoch number of the original block in which the application event was packaged; its data type is an unsigned integer. This is a function to find the maximum value. Further explanation is provided below: [Introduction to...] The function helps prevent negative number operations when the height of the latest epoch is temporarily less than the height of the original block epoch due to deep reorganization of the underlying network nodes of the blockchain, ensuring that the consensus cycle number is always a non-negative integer.

[0141] S423, after obtaining the calculation results, the cross-layer data synchronization module 160 forcibly verifies the number of consensus cycles. Is it greater than or equal to the anti-rollback confirmation threshold? As a preferred approach, considering the consensus block generation rate and security of blockchain underlying network nodes based on a compatible virtual machine, a threshold for the number of confirmations to prevent rollback is considered. The value range is set to 20 to 50. (If the consensus cycle number...) Less than the rollback confirmation threshold The cross-layer data synchronization module 160 suspends and postpones the processing of the application event. Conversely, if the consensus cycle count... Greater than or equal to the rollback confirmation threshold The cross-layer data synchronization module 160 does not blindly allow transactions. Instead, based on multi-dimensional verification logic, it initiates a transaction receipt query request to the underlying blockchain network nodes again through the application programming interface. The cross-layer data synchronization module 160 verifies whether the transaction hash corresponding to the application event still exists on the latest main chain and whether the execution status is successful. As an exception handling mechanism, if the query finds that the transaction has been discarded by the network or has become an invalid transaction in an orphan block, the system will permanently discard the application event; only when the transaction receipt verification passes can the event status be determined to be solidified and enter the subsequent data write-back process. The purpose of this anti-fork confirmation judgment is to utilize the time accumulation effect of the consensus mechanism of the underlying blockchain network nodes, combined with the secondary verification of the actual status of the main chain, to ensure that the monitored application events have been confirmed by the vast majority of nodes in the entire network, thereby fundamentally eliminating the risk of off-chain data rollback caused by micro-chain forks.

[0142] After successfully navigating the fork danger period and confirming that the on-chain state has reached eventual consistency, the system needs to address the issue of duplicate message delivery in high-concurrency network environments. To address this, the cross-layer data synchronization module 160 in this embodiment performs an idempotent write-back operation. As a preferred implementation, the steps are as follows:

[0143] S431, the cross-layer data synchronization module 160 extracts the transaction hash carried in the application event and maps it to a unique key in the underlying database business table structure. The transaction hash is a globally unique cryptographic identifier generated by the underlying blockchain network node for each on-chain transaction, and has the physical characteristics of being immutable and non-repeatable.

[0144] In step S432, the cross-layer data synchronization module 160 constructs a state update request from application event parameters with unique keys and sends it to the database engine layer. When processing the state update request, the database engine layer determines whether the transaction hash already exists in the business table based on the unique index constraint. If it already exists, a unique index conflict is triggered, and the write request is ignored. If it does not exist, the corresponding business data's state is updated according to the application event parameters, and the total available quota is deducted synchronously. This idempotent write-back step aims to address the possibility of duplicate event pushes received by the blockchain listener in a high-concurrency network environment. It utilizes the underlying database's anti-conflict mechanism to ensure the uniqueness and accuracy of core business data, thoroughly achieving secure closed-loop synchronization of cross-layer data.

[0145] To further illustrate how the above modules work together to achieve full lifecycle management, this embodiment uses the scenario of enterprise marketing red envelope distribution as an example to explain the implementation method of hierarchical management of red envelope distribution based on the above system architecture. See also... Figure 5 It demonstrates the entire lifecycle process of tiered management of red envelope distribution. As a preferred implementation method, the system's operational logic during the front-end configuration and off-chain approval stages can be broken down into the following steps:

[0146] S511, in this embodiment, the business personnel enter the business initialization parameters for issuing red envelopes through the front-end interface. These parameters include, but are not limited to, the total amount of red envelopes and the number of envelopes issued. The unified identity authentication module 110 receives the entry request from the front-end interface, extracts and records the identity information of the current operator. Preferably, the system generates and stores the corresponding red envelope object record in the underlying database based on the aforementioned business initialization parameters, and sets the initial state of the red envelope object record to pending approval.

[0147] S512, as a specific implementation method, the object-level permission control module 120 intercepts approval operation requests initiated by managers at various levels for the red envelope object record through the aspect interception mechanism of the underlying framework. Specifically, the object-level permission control module 120 verifies the session identifier permissions of the department manager and the financial director in sequence according to the preset multi-level approval flow rules. If the verification passes, the object-level permission control module 120 updates the approval status of the red envelope object record in the underlying database. At this stage, the system only changes the data status in the off-chain management layer 100 and does not directly send instructions to the underlying blockchain network nodes, thereby avoiding the waste of on-chain network resources caused by approval failure or unilateral business cancellation.

[0148] Once the aforementioned off-chain approval process is completed and final approval is achieved, in order to securely and reliably map the business intent to the underlying blockchain network nodes, the system in this embodiment enters the automated on-chain deployment and payment setup phase. See also... Figure 2 This demonstrates the end-to-end macroscopic interaction sequence at this stage; for further details on the underlying microscopic execution logic, please refer to [link / reference]. Figure 3 This demonstrates the detailed execution timing between the core internal modules of the system. The specific implementation steps are as follows:

[0149] S521, once the CFO's final approval request is verified, the system internally triggers the contract deployment process, which includes the following sub-steps:

[0150] S521-1, the CFO sends a final approval confirmation request to the task scheduling module 140 through the front-end interface;

[0151] S521-2 After receiving the request, the task scheduling module 140 sends an instruction to the contract factory module 150 to read the corresponding underlying bytecode and business initialization parameters.

[0152] S521-3 After the contract factory module 150 completes the data splicing, it returns the integrated deployment task data to the task scheduling module 140;

[0153] S521-4, the task scheduling module 140 constructs a business smart contract internally to deploy transactions based on the returned data;

[0154] S521-5, Task scheduling module 140 calls the signature interface to request key escrow service module 130 to sign the deployment transaction using the private key of the enterprise administrator account;

[0155] S521-6, After verifying the legitimacy of the call, the key escrow service module 130 uses the escrow private key to sign the transaction and returns a deployment transaction with completed cryptographic signature to the task scheduling module 140;

[0156] S521-7, Task scheduling module 140 broadcasts the signed deployment transaction to the underlying blockchain network nodes;

[0157] S521-8 After completing consensus packaging, the underlying network node of the blockchain instantiates and deploys the business smart contract 210 on the chain, and returns the globally unique contract address to the task scheduling module 140, thus completing the contract deployment.

[0158] S522, after the business smart contract 210 is deployed and a globally unique contract address is generated, in order to avoid users incurring high underlying network costs in subsequent interactions, the task scheduling module 140 continuously initiates policy call instructions for the sponsor whitelist control contract 220, specifically including the following sub-steps:

[0159] S522-1, the task scheduling module 140 constructs a transaction fee payment binding instruction, requests the private key signature of the enterprise administrator account from the key custody service module 130, and after obtaining the signed call instruction, sends the transaction fee payment binding instruction to the underlying network node of the blockchain.

[0160] S522-2, the underlying blockchain network node routes the instruction to the sponsor whitelist control contract 220, sets the underlying transaction fee payer to the administrator account and executes the successful record status. Then the underlying blockchain network node returns a configuration success receipt to the task scheduling module 140.

[0161] S522-3, the task scheduling module 140 then constructs the storage collateral fee payment binding instruction, requests the private key signature from the key custody service module 130 again, and sends the storage collateral fee payment binding instruction to the underlying blockchain network node after obtaining the signature.

[0162] S522-4, the underlying network node of the blockchain routes the instruction to the sponsor whitelist control contract 220, sets the underlying storage collateral fee payer to the administrator account, and returns a configuration success receipt to the task scheduling module 140;

[0163] S522-5, the task scheduling module 140 continues to construct the zero-address call whitelist addition instruction, requests the private key signature from the key custody service module 130, and after obtaining the signature, sends the call whitelist addition instruction to the underlying blockchain network node;

[0164] S522-6, the underlying network node of the blockchain adds the zero address to the call whitelist array of the business smart contract 210 according to the instruction, and returns a configuration success receipt to the task scheduling module 140;

[0165] S522-7 After confirming that the above three configurations have returned successful receipts, the task scheduling module 140 establishes the underlying payment mechanism and updates the business status of the underlying database, and returns a successful deployment and payment setting response to the front-end interface, completing the entire automated configuration process.

[0166] Furthermore, to more clearly illustrate the streamlined communication links between the core scheduling unit, the cryptographic signature unit, and the external network during the aforementioned on-chain deployment and payment setup phases, please refer to [reference needed]. Figure 3 It demonstrates the same two stages from the perspective of core system interaction, and its specific interaction logic is as follows:

[0167] In the on-chain automated deployment phase of Phase One (corresponding to embodiment S521), the system communication link includes the following steps:

[0168] The front-end interface sends a final approval confirmation request to the task scheduling module 140;

[0169] The task scheduling module 140 calls the interface to request the private key signature of the enterprise administrator from the key escrow service module 130;

[0170] After completing internal signature verification, the key escrow service module 130 returns the cryptographic signature to the task scheduling module 140;

[0171] Task scheduling module 140 then broadcasts the business smart contract to deploy transactions to the public blockchain underlying network nodes;

[0172] After the underlying network node of the public blockchain has finished processing, it returns a response containing the globally unique contract address to the task scheduling module 140.

[0173] In the automated payment configuration phase of Phase Two (corresponding to embodiment S522), the system communication link includes the following steps:

[0174] The task scheduling module 140 internally constructs underlying payment binding and whitelist configuration instructions;

[0175] In response to this configuration instruction, the task scheduling module 140 requests the enterprise administrator's private key signature from the key escrow service module 130 again.

[0176] The key escrow service module 130 returns a cryptographic signature to the task scheduling module 140;

[0177] After obtaining the signature, the task scheduling module 140 continuously sends policy invocation instructions (sponsor whitelist control contract) to the underlying network nodes of the public blockchain.

[0178] After completing the node consensus, the underlying network nodes of the public blockchain return an execution success receipt to the task scheduling module 140;

[0179] Finally, the task scheduling module 140 returns the deployment and payment configuration completion status to the front-end interface.

[0180] Based on the aforementioned underlying password-free payment mechanism, the system provides end users with a seamless interactive experience. As a specific implementation method, it executes the following steps:

[0181] In S531, an end-user initiates an asset retrieval request for business smart contract 210 through an external account address under their control (e.g., a Fluent wallet or MetaMask digital wallet invoked via a front-end H5 link). Since the sponsorship whitelist control contract has included zero addresses in the call whitelist, the virtual machine of the underlying network node in the public blockchain, during authentication, determines that the end-user's call behavior conforms to the payment rules, thus automatically exempting the external account address from the underlying deduction logic for transaction fees and storage collateral fees. The external account address does not need to hold any underlying native tokens as network fees in advance throughout the entire call process.

[0182] In step S532, the business smart contract 210 receives the asset redemption request. The underlying blockchain network node virtual machine executes a verification mechanism according to the preset activity validity period threshold and redemption status. If the verification passes, the business smart contract 210 extracts the current block status parameters and generates a pseudo-random number using hash calculation, thereby calculating the specific asset allocation amount that the external account address should receive. After obtaining the calculation result, the business smart contract 210 directly transfers digital assets equivalent to the asset allocation amount to the external account address, completing the atomic transfer logic of the underlying token.

[0183] In complex distributed network environments, a single asynchronous event callback may result in partial data loss due to node failure or network interruption. To ensure the rigor and traceability of changes to core assets, the system ultimately performs data closure and dual auditing operations. The specific implementation steps are as follows:

[0184] S541, idempotent write-back is performed based on the application event to update the final status of the transaction and simultaneously deduct the amount. In this embodiment, the blockchain listener in the cross-layer data synchronization module 160 continuously captures the successful claim event triggered by the business smart contract 210. The cross-layer data synchronization module 160 parses the parameter payload carried by the successful claim event, and after determining that the number of consensus cycles that the successful claim event has gone through has reached the anti-rollback confirmation threshold, it sends a status update request to the database engine layer. The system executes idempotent write-back logic based on the status update request, changes the transaction status of the corresponding red packet object record in the underlying database to "claimed", and simultaneously deducts the remaining available amount of the red packet displayed on the front-end interface. Furthermore, after the underlying database status update is completed, the system can also asynchronously push the status change message to the enterprise's external business system through the Webhook callback mechanism to achieve asynchronous decoupling across systems.

[0185] S542 executes multi-source data alignment calculations to complete dual-logging audits and lifecycle closed-loop archiving. As a preferred anomaly prevention mechanism, the system periodically performs dual-logging audit traceability operations. In this process, simply relying on the comparison of total funds can easily mask the potential for discrepancies in underlying details. Therefore, the system first executes precise alignment logic for multi-source data based on globally unique transaction hash identifiers. Specifically, the system extracts the transaction details of all red packet objects recorded in the underlying database, using the activity lifecycle time window as a constraint, and simultaneously obtains the historical transaction hash records and actual transfer amounts of the business smart contract address 210 corresponding to execution layer 200 on the blockchain through the application programming interface. The system aligns the transaction records of the business layer with the transaction records of the underlying blockchain network nodes one by one (for example, the system can provide on-chain verification links based on transaction hashes to blockchain explorers such as ConfluxScan for manual review). After confirming that each transaction hash has a one-to-one mapping relationship, the system further calculates the consistency of the two in terms of macro total amount. The specific dual-logging consistency verification formula is as follows:

[0186] ;

[0187] In the formula, This is the ledger deviation value, which is a signed large integer and is in the basic unit of the underlying blockchain network node. This represents the total number of transaction records for red envelope objects in the underlying database. For the first in the underlying database The transaction history of each red envelope recipient records the amount; This refers to the total number of asset transfer transactions actually generated by the smart contract 210 of this business within the on-chain execution layer 200. For the 200th in the on-chain execution layer The actual amount recorded in the book for this asset transfer transaction. After calculation, the system determines the ledger deviation value. Is it strictly equal to zero? If the ledger deviation value... The number of records is equal to zero. and If the values ​​are equal and the mapping alignment rate of the underlying transaction hashes reaches 100%, then the data of the off-chain management layer 100 and the on-chain execution layer 200 are determined to be eventually consistent; if the ledger deviation value is... If any verification indicator is not equal to zero or shows an anomaly in any dimension, the system triggers an alarm work order containing abnormal characteristic data, which is then handed over to the system administrator for manual intervention and investigation. For the extraction and traversal of historical transaction hashes on the blockchain, those skilled in the art can use the conventional remote procedure call interface of the underlying blockchain network node, which is a well-known technology in the field and will not be elaborated upon here. The purpose of this dual ledger audit traceability step is to utilize the immutable ledger characteristic of the blockchain to perform objective cross-verification of the internal system's transaction data, thoroughly preventing inconsistencies in ledger amounts caused by system network failures, database rollbacks, or malicious data tampering.

[0188] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A smart contract service platform based on a two-tier architecture, characterized in that: include: The off-chain management layer includes an object-level access control module, a key escrow service module, a task scheduling module, and a cross-layer data synchronization module; The on-chain execution layer runs in the underlying network nodes of the blockchain and includes business smart contracts and sponsorship whitelist control contracts. The object-level permission control module is used to extract the target object identifier and target operation type from the operation request, and query the access control list record table based on the target object identifier to verify whether the session identifier of the currently logged-in user has execution permission; The key escrow service module is used to digitally sign the transaction payload corresponding to the operation request using the escrowed enterprise administrator's private key after the object-level permission control module has passed the verification, thereby generating a blockchain transaction task. The task scheduling module is used to send blockchain transaction tasks to the on-chain execution layer and call the business smart contract to execute business logic; the business smart contract interacts with the sponsor whitelist control contract, and the sponsor account corresponding to the enterprise administrator's private key automatically deducts transaction fees and storage collateral fees; The cross-layer data synchronization module is used to capture on-chain events triggered by business smart contracts and perform state write-back operations on the underlying database based on the epoch number and transaction hash of the block where the on-chain event is located.

2. The smart contract service platform based on a two-tier architecture according to claim 1, characterized in that, Based on the target object identifier, query the access control list record table to verify whether the currently logged-in user's session identifier has execution permissions, including: Search the access control list record table for the user permission bitmask corresponding to the session identifier; Perform a bitwise AND operation between the user permission bitmask and the target permission bitmask required to execute the target operation type to obtain the permission verification result value; If the permission verification result is exactly equal to the target permission bitmask, the verification is deemed successful. If the permission verification result is not equal to the target permission bitmask, an access denial exception is thrown and the operation request is terminated.

3. The smart contract service platform based on a two-tier architecture according to claim 1, characterized in that, The key escrow service module stores the enterprise administrator's private key through a hardware security module or a threshold signature algorithm; The process of digitally signing the transaction payload corresponding to the operation request using the private key of the managed enterprise administrator includes: The elliptic curve digital signature algorithm is invoked, and the hash digest of the transaction payload is cryptographically calculated using the private key of the enterprise administrator to generate a signature result containing a recovery identifier and an integer component. The signature result is then appended to the transaction payload to constitute the blockchain transaction task.

4. The smart contract service platform based on a two-tier architecture according to claim 1, characterized in that, The off-chain management layer also includes a contract factory module; The contract factory module is used to perform encoding operations on the business parameter set according to the preset application binary interface data specification, and append the encoded data to the end of the smart contract bytecode to assemble and generate the contract deployment payload, so as to instantiate and deploy the business smart contract at the on-chain execution layer. The sponsorship whitelist control contract is used to receive payment binding call instructions after the business smart contract is deployed, set the transaction fee payer and storage collateral fee payer of the business smart contract to the enterprise administrator account corresponding to the enterprise administrator's private key, and add the zero address to the call whitelist of the business smart contract.

5. The smart contract service platform based on a two-tier architecture according to claim 4, characterized in that, The sponsorship whitelist control contract is also used to verify whether the signatory of the fund withdrawal instruction is the enterprise administrator account corresponding to the enterprise administrator's private key when a fund withdrawal instruction is received from the off-chain system. If the verification is successful, the sponsorship whitelist control contract will execute the payment unbinding and refund operation. Based on the state accounting model of the underlying blockchain network nodes, the total amount of the initial deposited payment deposit will be deducted from the total amount of transaction fees and storage collateral fees consumed during the event period to calculate the remaining unconsumed payment deposit to be recovered, and the remaining unconsumed payment deposit will be returned to the enterprise administrator account corresponding to the enterprise administrator's private key.

6. The smart contract service platform based on a two-tier architecture according to claim 1, characterized in that, Based on the epoch number and transaction hash of the block where the on-chain event is located, perform a state write-back operation on the underlying database, including: Extract the epoch number of the original block from the metadata of the on-chain event, and obtain the latest epoch height of the underlying network node of the blockchain; Calculate the difference between the latest epoch height and the epoch number, and use it as the number of consensus cycles that the on-chain event has gone through; Verify whether the number of consensus cycles is greater than or equal to the preset anti-rollback confirmation threshold; If the consensus cycle number is greater than or equal to the anti-rollback confirmation number threshold, then query the underlying blockchain network node for the transaction receipt corresponding to the on-chain event, and enter the state write-back operation after the transaction receipt is verified.

7. The smart contract service platform based on a two-tier architecture according to claim 6, characterized in that, The state write-back operation includes: Extract the transaction hash carried in the on-chain event and map the transaction hash to a unique key in the underlying database business table structure; The on-chain event parameters with the unique key are constructed into a state update request and sent to the database engine layer; The unique indexing mechanism of the database engine layer is used to verify whether the transaction hash is duplicated in the business table structure. If no duplicates are detected, the business data status of the underlying database is updated based on the on-chain event parameters.

8. The smart contract service platform based on a two-tier architecture according to claim 1, characterized in that, The task scheduling module uses the buffer queue of the memory database to receive and cache concurrent operation requests; Before converting the operation request into a standard request object and pushing it into the buffer queue, the number of unprocessed requests is counted, and it is determined whether the number of unprocessed requests has reached the upper limit threshold of the queue length. The upper limit threshold for queue length is calculated by dividing the maximum available memory capacity allocated to the memory database by the average number of bytes occupied by a single standard request object, and multiplying by a preset safety buffer coefficient.

9. The smart contract service platform based on a two-tier architecture according to claim 7, characterized in that, The off-chain management layer also includes a dual ledger audit module, used for: Using a time window as a constraint, extract the transaction details of the red envelope objects recorded in the underlying database, and obtain the historical transaction records of the corresponding business smart contract in the on-chain execution layer; Based on the transaction hash, the red packet object transaction details in the underlying database are aligned with the historical transaction records of the on-chain execution layer; The first total amount is obtained by summing the recorded amounts of all red packet object transaction details in the underlying database, and the second total amount is obtained by summing the recorded amounts of historical transactions in the on-chain execution layer. Calculate the ledger deviation value between the first total amount and the second total amount, and trigger an alarm work order when the ledger deviation value is not equal to zero.

10. A two-tier architecture-based hierarchical management method for red envelopes, characterized in that, Applied to the smart contract service platform according to any one of claims 1-9, the method includes the following steps: The object-level permission control module of the off-chain management layer extracts the red packet object identifier and target operation type from the red packet distribution operation request. Based on the red packet object identifier, the access control list record table is queried to verify whether the session identifier of the currently logged-in user has execution permission. After the object-level permission control module passes the verification, the key escrow service module uses the escrow enterprise administrator's private key to digitally sign the transaction payload corresponding to the red packet distribution operation request, generating a blockchain transaction task. The task scheduling module sends the blockchain transaction task to the on-chain execution layer, calls the business smart contract to execute the business logic, and interacts with the sponsor whitelist control contract during the execution. The transaction fee and storage collateral fee are automatically deducted by the sponsor account corresponding to the private key of the enterprise administrator. The cross-layer data synchronization module captures on-chain events triggered by the business smart contract and performs a state write-back operation on the underlying database based on the epoch number and transaction hash of the block where the on-chain event is located.

Images