An e-commerce transaction system and method based on multi-person cooperation

Abstract

The application provides an e-commerce transaction system and method based on multi-person cooperation, determines the transaction credibility of each user in the cooperative transaction according to the user behavior data set, determines the quota strategy of each user based on all transaction credibilities and the inventory of the target commodity, constructs a hybrid block chain network for cooperative e-commerce transaction according to the identity of each user, the category attribute of the target commodity and the quota strategy, determines the global time lock of the main chain and the local time lock of the sub-chain, performs cross-chain state binding on the payment lock state during the cooperative transaction, and obtains the execution condition during the multi-user cross-chain cooperative transaction, triggers the transaction execution according to the execution condition, and if the number of users completing the confirmation payment reaches the lower limit of the group within the preset total time, the global time lock contract executes the fund splitting and transfers the property right certificate to the commodity provider. The scheme of the application can dynamically negotiate in the multi-person cooperative e-commerce transaction and guarantee the atomicity of multi-user cross-chain payment.

Description

Technical Field

[0001] This application relates to the field of e-commerce transaction technology, and more specifically, to an e-commerce transaction system and method based on multi-person collaboration. Background Technology

[0002] With the maturity of virtual reality technology and the popularization of e-commerce, multi-person collaborative shopping scenarios are gradually becoming a new direction for e-commerce development; multiple users can enter the same virtual store at the same time, view product information together, discuss purchase intentions, and may participate in collaborative transaction activities such as group buying and joint purchases.

[0003] Existing e-commerce transaction systems are primarily designed for single-user, independent purchase scenarios, failing to effectively support the complex needs of multi-user collaborative transactions. Some blockchain solutions attempt to achieve multi-party transactions through smart contracts, but these typically only support simple two-party transactions, struggling to handle complex scenarios where multiple users collaborate based on interactive behavior in a virtual reality environment. When multiple users are making payments across different sub-chains, it's impossible to uniformly monitor the payment status of all users, leading to transaction disputes and a degraded user experience. Furthermore, existing solutions lack quantitative evaluation mechanisms for user interactions in virtual scenarios, making it impossible to dynamically adjust quota allocations based on users' actual collaborative intentions, and also making it difficult to effectively trace malicious behavior while protecting user privacy. Therefore, how to dynamically negotiate and ensure the atomicity of cross-chain payments among multiple users in collaborative e-commerce transactions has become a major challenge for the industry. Summary of the Invention

[0004] This application provides an e-commerce transaction system and method based on multi-user collaboration, which can dynamically negotiate in multi-user collaborative e-commerce transactions and ensure the atomicity of cross-chain payments by multiple users.

[0005] Firstly, this application provides a multi-person collaborative e-commerce transaction method, including the following steps: Collect user behavior datasets by collecting interactive operations of multiple users on the same target product during e-commerce transactions and the corresponding users' historical transaction fulfillment data; The transaction credibility of each user in collaborative transactions is determined based on the user behavior dataset. Based on all transaction credibility, each user's purchase demand and the inventory of the target product, the quota strategy for each user in collaborative transactions is determined. Then, a hybrid blockchain network for collaborative e-commerce transactions is constructed based on the identity of each user, the category attributes of the target product and the quota strategy. The global time lock for the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock for the individual user payment time limit on the sub-chain are determined. Then, the payment lock state during collaborative transactions is bound across chains to obtain the atomic execution conditions for multi-user cross-chain collaborative transactions. When a user confirms a transaction according to the quota strategy, the transaction is executed according to the execution conditions. If the number of users who complete the payment confirmation within the preset total time reaches the minimum group size limit, the global time lock contract will split the funds and transfer the ownership certificate to the product provider. Otherwise, all payment locks will be released and the transaction will be rolled back.

[0006] In some embodiments, collecting the interaction operations of multiple users on the same target product during e-commerce transactions and the corresponding users' historical transaction fulfillment data to obtain a user behavior dataset specifically includes: The eye-tracking unit collects the gaze point coordinate sequence of each user when they gaze at the target product. The gesture recognition unit collects the gesture trajectory data of each user when interacting with the target product; Record the response timestamps for each user from the moment the target product is displayed until the user issues an interaction command; Collect historical transaction fulfillment data from each user; All gaze coordinate sequences, gesture trajectory data, and response timestamps are aligned and noise is filtered out to obtain the user behavior dataset.

[0007] In some embodiments, determining the transaction credibility of each user in collaborative transactions based on the user behavior dataset specifically includes: The spatial coordination factor between any two users in the virtual scene is determined based on the gaze point coordinate sequence in the user behavior dataset. The time decision factors for each user's target product are determined based on the response timestamps in the user behavior dataset. Determine the historical performance credit score for each user; By weighting and integrating all spatial collaboration factors, time decision factors, and performance credit scores, the transaction credibility of each user in collaborative transactions is obtained.

[0008] In some embodiments, determining the quota strategy for collaborative transactions among users based on the credibility of all transactions, the purchasing needs of each user, and the inventory of the target product specifically includes: Obtain the total inventory of the target product and the purchasing demand of each user; The initial quota ratio for each user is calculated by combining all purchase demands and the total inventory. The acquisition priority of corresponding users is determined based on all initial quota ratios and all transaction credibility. Collect acceptance data from each user under their respective acquisition priority. By iteratively recursively applying the acceptance data, the quota strategy for collaborative transactions among various users can be obtained.

[0009] In some embodiments, constructing a hybrid blockchain network for collaborative e-commerce transactions based on the identity identifiers of each user, the category attributes of the target product, and the quota strategy specifically includes: The number of nodes is determined based on the transaction concurrency requirements of the quota strategy, and a main chain is constructed to record the global transaction status. Based on the category attributes of the target product, create corresponding sub-chains under the main chain, and configure independent transaction ledgers for each sub-chain; Construct a certificate chain that stores the certificate status and validity of users, and then obtain the access credentials for each user to access the main chain based on the identity of each user; The quota policy is compiled into smart contract code and deployed to the transaction ledger of the corresponding subchain; The main chain, the certificate chain, and all sub-chains are combined into a hybrid blockchain network for collaborative e-commerce transactions.

[0010] In some embodiments, determining the global time lock for the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock for the individual user payment time limit on the sub-chain specifically includes: The hash time lock contract of the main chain of the hybrid blockchain network generates a random preimage and calculates the unlocking certificate for the global time lock; A total time limit is set in the main chain, and the unlocking certificate is bound to the total time limit to obtain a global time lock for the overall user payment time limit; The unlocking credentials are synchronized to the hash time lock contracts of each subchain, and an individual time limit for each user to complete the payment is set in each subchain. The unlocking credential is bound to the individual time limit of each user to obtain a local time lock for the corresponding user's payment.

[0011] In some embodiments, binding the payment lock state during collaborative transactions to the cross-chain state to obtain the atomic execution conditions for multi-user cross-chain collaborative transactions specifically includes: Determine the payment confirmation status of the local time lock of each user on each sub-chain and the global payment status of the main chain during collaborative transactions; By cross-chain binding of all payment confirmation statuses with the global payment status, the status binding conditions are obtained. The triggering rules for the global time lock are set based on the state binding conditions; The state binding condition and the triggering rule are jointly determined as the atomic execution condition for multi-user cross-chain collaborative transactions.

[0012] Secondly, this application provides an e-commerce transaction system based on multi-user collaboration, comprising: The data collection module is used to collect the interaction operations of multiple users on the same target product during e-commerce transactions and the corresponding users' historical transaction fulfillment data to obtain a user behavior dataset. The processing module is used to determine the transaction credibility of each user in collaborative transactions based on the user behavior dataset, determine the quota strategy for each user in collaborative transactions based on all transaction credibility, each user's purchase demand and the inventory of the target product, and then construct a hybrid blockchain network for collaborative e-commerce transactions based on the identity of each user, the category attribute of the target product and the quota strategy. The processing module is also used to determine the global time lock of the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock of the individual user payment time limit on the sub-chain, and then bind the payment lock state during collaborative transactions across chains to obtain the atomic execution conditions for multi-user cross-chain collaborative transactions. The execution module is used to trigger transaction execution according to the execution conditions when a user confirms a transaction in accordance with the quota strategy. If the number of users who complete the confirmation payment within the preset total time reaches the minimum group size limit, the global time lock contract will split the funds and transfer the ownership certificate to the goods provider. Otherwise, all payment locks will be released and the transaction will be rolled back.

[0013] Thirdly, this application provides a computer device, the computer device including a memory and a processor, the memory storing code, and the processor being configured to acquire the code and execute the above-described e-commerce transaction method based on multi-person collaboration.

[0014] Fourthly, this application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned e-commerce transaction method based on multi-user collaboration.

[0015] The technical solutions provided by the embodiments disclosed in this application have the following beneficial effects: The e-commerce transaction system and method based on multi-user collaboration provided in this application first collects the interaction operations of multiple users on the same target product and the historical transaction fulfillment data of the corresponding users during e-commerce transactions to obtain a user behavior dataset. Based on the user behavior dataset, the transaction credibility of each user in collaborative transactions is determined. Based on all transaction credibility, each user's purchase demand, and the inventory of the target product, a quota strategy for each user's collaborative transactions is determined. Then, based on the identity of each user, the category attributes of the target product, and the quota strategy, a hybrid blockchain network for collaborative e-commerce transactions is constructed. A global time lock for the overall user payment time limit on the main chain of the hybrid blockchain network and a local time lock for the individual user payment time limit on the sub-chain are determined. The payment lock state during collaborative transactions is then cross-chain bound to obtain atomic execution conditions for multi-user cross-chain collaborative transactions. When a user confirms a transaction according to the quota strategy, transaction execution is triggered according to the execution conditions. If the number of users who complete the confirmation payment within the preset total time reaches the minimum group size, the global time lock contract executes fund splitting and transfers the ownership certificate to the product provider; otherwise, all payment locks are released, causing the transaction to roll back.

[0016] Therefore, in the multi-user collaborative e-commerce transaction method of this application, firstly, the transaction credibility of each user in collaborative transactions is determined based on the user behavior dataset. Then, based on all transaction credibility, each user's purchase demand, and the inventory of the target goods, a quota strategy for each user's collaborative transactions is determined. Finally, a hybrid blockchain network for collaborative e-commerce transactions is constructed based on each user's identity, the category attributes of the target goods, and the quota strategy. The quota strategy represents the allocation scheme for the final quantity of target goods that each user can obtain after multiple rounds of negotiation. The hybrid blockchain network is a blockchain system composed of a main chain, a certificate chain, and multiple business sub-chains supporting multi-user collaborative transactions, used to uniformly manage global transactions on the main chain. The system employs state and cross-chain coordination to achieve anonymous authentication and traceable management of user identities on the certificate chain. It also distributes and records transaction details for collaborative transactions of different product categories across various business sub-chains. Secondly, it determines a global time lock for the overall user payment time limit on the main chain of the hybrid blockchain network and a local time lock for the individual user payment time limit on the sub-chains. This allows for cross-chain state binding of the payment lock state during collaborative transactions, resulting in atomic execution conditions for multi-user cross-chain collaborative transactions. The triggering rule defines the criteria for determining what operation the global time lock should perform when the global payment state meets specific conditions. The atomic execution condition is a complete set of rules ensuring that multi-user cross-chain collaborative transactions either all execute successfully or all automatically roll back. This solution enables dynamic negotiation and guarantees the atomicity of multi-user cross-chain payments in collaborative e-commerce transactions. Attached Figure Description

[0017] Figure 1 This is an exemplary flowchart of a multi-person collaborative e-commerce transaction method according to some embodiments of this application; Figure 2 This is an exemplary flowchart illustrating the determination of transaction credibility according to some embodiments of this application; Figure 3 These are interactive scene diagrams illustrating the transfer of property rights certificates according to some embodiments of this application; Figure 4 This is a schematic diagram of the structure of a multi-user collaborative e-commerce transaction system according to some embodiments of this application; Figure 5 This is a schematic diagram of the structure of a computer device for implementing a multi-user collaborative e-commerce transaction method, according to some embodiments of this application. Detailed Implementation

[0018] To better understand the above technical solutions, the following will provide a detailed explanation of the technical solutions in conjunction with the accompanying drawings and specific implementation methods.

[0019] refer to Figure 1 The figure is an exemplary flowchart of a multi-user collaborative e-commerce transaction method according to some embodiments of this application. The multi-user collaborative e-commerce transaction method mainly includes the following steps: In step 101, the interaction operations of multiple users on the same target product during e-commerce transactions and the corresponding users' historical transaction fulfillment data are collected to obtain a user behavior dataset.

[0020] In some embodiments, collecting user behavior datasets by collecting interaction data of multiple users on the same target product during e-commerce transactions and the corresponding users' historical transaction fulfillment data can be achieved through the following steps: The eye-tracking unit collects the gaze point coordinate sequence of each user when they gaze at the target product. The gesture recognition unit collects the gesture trajectory data of each user when interacting with the target product; Record the response timestamps for each user from the moment the target product is displayed until the user issues an interaction command; Collect historical transaction fulfillment data from each user; All gaze coordinate sequences, gesture trajectory data, and response timestamps are aligned and noise is filtered out to obtain the user behavior dataset.

[0021] In specific implementation, collecting the gaze point coordinate sequence of each user when looking at the target product through the eye-tracking unit can be achieved in the following way: An eye-tracking unit is deployed in the virtual reality device. When multiple users look at the same target product in the same virtual scene, the eye-tracking unit collects the gaze point position of each user's eyes at a fixed frequency, recording the x-axis, y-axis, and z-axis coordinates of each gaze point in the three-dimensional coordinate system of the virtual scene. These coordinates are then arranged in chronological order to obtain the gaze point coordinate sequence of each user. The fixed frequency can be 100Hz, which can be set according to actual conditions. Collecting the gesture trajectory data of each user when interacting with the target product through the gesture recognition unit can be achieved in the following way: A gesture recognition unit is deployed in the virtual reality device. When users perform interactive operations such as clicking, dragging, rotating, and scaling on the target product, the gesture recognition unit collects the movement trajectory of the user's hand in real time, recording the position coordinates of the hand in three-dimensional space and the palm orientation angle at each sampling moment. All position coordinates and angle data are organized in chronological order to obtain the gaze point coordinate sequence of each user. The gesture trajectory data; recording the response timestamps of each user from the start of the target product display to the issuance of the interaction command can be implemented in the following way: record the behavior time information of each user through the system clock, record a start time point when the target product is first displayed in the virtual scene, and record an end time point when the user makes the first interaction command, such as clicking the product or issuing a voice command. The time difference between these two time points is used as the user's response timestamp; aligning and filtering all gaze point coordinate sequences, gesture trajectory data and response timestamps can be implemented in the following way: first, align the data according to the identity of each user and the sampling time to ensure that the gaze point, gesture and response time at the same moment can correspond, then use a filtering algorithm to remove abnormal noise data caused by device jitter or environmental interference, and then integrate the historical transaction performance data of each user to finally obtain the user behavior dataset. The historical transaction performance data includes at least the payment performance rate, return rate, transaction dispute initiation rate and number of malicious defaults; other embodiments may also use other methods, which are not limited here.

[0022] It should be noted that the gaze point coordinate sequence is a data sequence that records the coordinates of the gaze focus position of each user when looking at the target product in the virtual scene; the gesture trajectory data is data that records the hand movement trajectory of each user when performing interactive operations such as clicking, swiping, and rotating on the target product; the response timestamp is data that records the time point elapsed from the time the target product is first displayed to the time when each user issues the first interactive command; and the user behavior dataset is a standardized data set that represents all interactive behaviors of multiple users on the same target product during collaborative transactions.

[0023] In step 102, the transaction credibility of each user in collaborative transactions is determined based on the user behavior dataset. Based on all transaction credibility, each user's purchase needs and the inventory of the target product, the quota strategy for each user in collaborative transactions is determined. Then, a hybrid blockchain network for collaborative e-commerce transactions is constructed based on the identity of each user, the category attributes of the target product and the quota strategy.

[0024] In some embodiments, reference Figure 2 As shown, this diagram is an exemplary flowchart for determining transaction credibility in some embodiments of this application. In this embodiment, determining the transaction credibility of each user in collaborative transactions based on the user behavior dataset can be achieved through the following steps: In 1021, the spatial coordination factor between any two users in the virtual scene is determined based on the gaze point coordinate sequence in the user behavior dataset; In 1022, the time decision factor for each user on the target product is determined based on the response timestamps in the user behavior dataset. In 1023, the historical performance credit score of each user is determined; In 1024, all spatial collaboration factors, time decision factors, and performance credit scores are weighted and integrated to obtain the transaction credibility of each user in collaborative transactions.

[0025] In specific implementation, determining the spatial co-location factor of any two users in the virtual scene based on the gaze point coordinate sequence in the user behavior dataset can be achieved in the following way: Extract the gaze point coordinate sequence of each user from the user behavior dataset; for any two users, calculate the three-dimensional spatial distance between the gaze points of the two users at each same moment; take the average of the spatial distances at all moments; and then normalize the distance values ​​to map them to the range of zero to one to obtain the spatial co-location factor of the two users in the virtual scene. Continue to determine the spatial co-location factor of any remaining two users; based on the response in the user behavior dataset... Determining the time decision factor for each user regarding the target product based on timestamps can be achieved as follows: Extract the response timestamps of each user from the user behavior dataset. For each user, map their response timestamp to a range of zero to one using a decreasing function, where shorter response timestamps result in larger mapped values. The mapped values ​​are then used as the user's time decision factor for the target product, and this process is repeated to determine the time decision factors for the remaining users. Determining each user's historical performance credit score can be achieved as follows: Standardize each user's payment fulfillment rate, return rate, and dispute rate, and then use a pre-set credit scoring model... The system calculates the credit score for each user within the 0-1 range, with higher payment fulfillment rates and fewer default records resulting in higher scores. The system then weights and integrates all spatial collaboration factors, time decision factors, and credit scores to determine each user's transaction credibility in collaborative transactions. This can be achieved by combining each user's spatial collaboration factors, time decision factors, and credit scores. First, the importance weights of spatial and time factors are determined based on the product type. For example, location-sensitive products can be assigned a higher weight to spatial collaboration factors, while time-sensitive products can be assigned a lower weight to time decision factors. A higher weight is applied, then the spatial collaboration factor is multiplied by the spatial weight, and the time decision factor is multiplied by the time weight. The two products are then added together and multiplied by the performance credit score. The final value is used as the transaction credibility of the user in the collaborative transaction. This is used to determine the transaction credibility of the remaining users in the collaborative transaction. The weight coefficient of virtual furniture products can be set to the range of 0.7 to 0.9. The weight of the time decision factor is positively correlated with the sensitivity of the product to timeliness. For example, the weight coefficient of limited-time flash sale products is set to the range of 0.7 to 0.9. The sum of the two weight coefficients is 1. Other embodiments can also be implemented in other ways, which are not limited here.

[0026] It should be noted that the spatial collaboration factor in this application is a quantitative value that characterizes the degree of spatial proximity between any two users when they observe the same target product in a virtual scene; the time decision factor is a quantitative value that characterizes the speed of each user's reaction when making interactive decisions about the target product; and the transaction credibility is a comprehensive quantitative indicator that characterizes the trustworthiness of each user's participation in decision-making and the strength of their willingness to collaborate in this collaborative transaction.

[0027] In some embodiments, determining the quota strategy for collaborative transactions among users based on the credibility of all transactions, the purchasing needs of each user, and the inventory of the target product can be achieved through the following steps: Obtain the total inventory of the target product and the purchasing demand of each user; The initial quota ratio for each user is calculated by combining all purchase demands and the total inventory. The acquisition priority of corresponding users is determined based on all initial quota ratios and all transaction credibility. Collect acceptance data from each user under their respective acquisition priority. By iteratively recursively applying the acceptance data, the quota strategy for collaborative transactions among various users can be obtained.

[0028] In specific implementation, obtaining the total inventory of the target product and the purchase demand of each user can be achieved as follows: Read the current inventory record of the target product from the product management system to obtain the total quantity of the product available for collaborative transactions among multiple users. Obtain the purchase demand of each user through the collaborative transaction interface. If the product is a physical product, obtain the actual inventory quantity; if the product is a digital product, obtain the number of units available for sale. Finally, use the total quantity read as the total inventory. The initial quota ratio for each user can be calculated by integrating all purchase demands and the total inventory. This can be achieved as follows: Add all purchase demands to obtain the total intended demand of all users. When the total intended demand is less than or equal to the total inventory, the initial quota ratio is determined according to each user's purchase demand. When the total intended demand exceeds the total inventory, adjust the oversold portion proportionally according to transaction credibility to ensure that the initial quota does not exceed the total inventory. Finally, obtain the initial quota ratio for each user. The determination of user acquisition priority based on transaction credibility can be achieved as follows: The initial quota ratio of each user is combined with the corresponding transaction credibility. For each user, their initial quota ratio is multiplied by the transaction credibility to obtain a product value. All user product values ​​are then sorted, with users having higher say or priority in subsequent negotiations. This sorted order is used as the acquisition priority for each user. The collection of user acceptance data under their respective acquisition priorities can be achieved as follows: The initial quota ratio is displayed to each user through a virtual reality interface. Users can express their acceptance level through gestures or voice, such as indicating acceptance, a desire to increase the quota, or a willingness to decrease it. The system records this feedback information, including user identifier, initial quota ratio, and user's adjustment intention. This feedback information is then used as acceptance data. Other implementation methods can also be used in other embodiments, which are not limited here.

[0029] In specific implementation, the quota strategy for collaborative transactions among users can be obtained by iteratively recursively processing the acceptance data. This can be achieved as follows: Using the acceptance data of each user as input, a multi-round quota negotiation is conducted using a reverse recursive iterative method. First, the initial quota ratio of each user is multiplied by the total inventory to obtain the initial quota quantity. Users are sorted from highest to lowest priority, and processing begins with the user with the highest priority. For the currently processed user, the adjustment willingness and adjustment range contained in their acceptance data are analyzed. If the user indicates acceptance, their current quota quantity remains unchanged. If the user requests an increase in quota, it is determined whether the remaining inventory meets the increase requirement. If it does, the user's quota quantity is increased by the corresponding value, and the remaining inventory is used to increase the quota. The quota is deducted from the remaining inventory. If the quota is not met, it is increased according to the upper limit of the remaining inventory. If a user requests a reduction in quota, the user's quota is reduced by the corresponding value and the corresponding inventory is released to the remaining inventory pool. After the adjustment of one user is completed, the remaining inventory is updated and the process moves on to the next priority user. After all users have completed one round, the ratio of the current quota quantity of each user to the total inventory is recalculated. The new ratio is used as the initial quota ratio for the next round, and user acceptance data is collected again. The above process is repeated until all users indicate that they accept the current quota allocation or the preset maximum number of iterations is reached. Finally, the final quantity of goods for each user obtained after the iteration converges is used as the quota strategy. Other embodiments may also use other methods to implement this, which are not limited here.

[0030] It should be noted that transforming the multi-user quota allocation problem into a multi-round negotiation and decision-making process, by adjusting the quota layer by layer from the highest priority user, simulates the behavior of rational users making the current optimal decision when they know how subsequent users will react. This is beneficial in ensuring the reasonable demands of high-priority users while taking into account the basic rights of low-priority users. Through iterative convergence, the quota allocation result that maximizes the overall satisfaction of all participants is achieved, avoiding transaction failures caused by unilateral forced allocation or disorderly competition.

[0031] It should be noted that the initial quota ratio in this application represents the proportion of goods initially allocated to each user based on user credibility and total inventory; the acquisition priority represents the weight value of each user's order of obtaining goods quotas relative to other users in collaborative transactions; the acceptance data represents the feedback information of each user's acceptance of the initial quota ratio allocated to them or their willingness to adjust it; and the quota strategy represents the allocation scheme of the final target quantity of goods that each user can obtain after multiple rounds of negotiation.

[0032] In some embodiments, the construction of a hybrid blockchain network for collaborative e-commerce transactions based on the identity of each user, the category attributes of the target product, and the quota policy can be achieved through the following steps: The number of nodes is determined based on the transaction concurrency requirements of the quota strategy, and a main chain is constructed to record the global transaction status. Based on the category attributes of the target product, create corresponding sub-chains under the main chain, and configure independent transaction ledgers for each sub-chain; Construct a certificate chain that stores the certificate status and validity of users, and then obtain the access credentials for each user to access the main chain based on the identity of each user; The quota policy is compiled into smart contract code and deployed to the transaction ledger of the corresponding subchain; The main chain, the certificate chain, and all sub-chains are combined into a hybrid blockchain network for collaborative e-commerce transactions.

[0033] In specific implementation, the number of nodes is determined based on the transaction concurrency requirements of the quota strategy. The main chain for recording the global transaction status can be constructed in the following way: The total number of users participating in this collaborative transaction is extracted from the quota strategy and used as the basis for calculating transaction concurrency. Simultaneously, the peak transaction coefficient corresponding to the category attributes of the target product is analyzed. For example, the peak coefficient for limited-time sale products is set to 3 to 5, and the peak coefficient for regular products is set to 1 to 2. The total number of users is multiplied by the peak coefficient to obtain the estimated peak concurrent transaction count. Then, based on the transaction confirmation time window preset by the blockchain network, the peak concurrent transaction count is calculated. Divide the number of transactions by the number of seconds in the time window to obtain the transaction concurrency required per second. Determine the required number of consensus nodes based on a preset node processing capacity lookup table. For example, if a single node can process 1,000 transactions per second, divide the concurrency per second by 1,000 and round up to obtain the number of nodes. Then, deploy the corresponding number of physical servers or cloud servers as consensus nodes. Install the underlying blockchain platform software on these nodes, configure the parameters of consensus algorithms such as proof-of-stake and the network connection parameters between nodes, and obtain the main chain that records the global transaction status. Other embodiments may also use other methods to achieve this, which are not limited here.

[0034] In specific implementation, creating corresponding sub-chains under the main chain based on the category attributes of the target product and configuring independent transaction ledgers for each sub-chain can be achieved in the following way: Analyze the category attributes of the target product, create a corresponding sub-chain for each category under the already constructed main chain, configure independent storage space for the sub-chain to store transaction data, use independent consensus nodes to process transactions on the sub-chain, and use independent ledger files to record all transaction records on the sub-chain. The created blockchain with independent ledgers serves as the sub-chain for the corresponding category. Category attributes can be classified according to natural attributes, transaction patterns, value attributes, etc. Constructing a certificate chain to store user certificate status and validity, and then obtaining access credentials for each user to access the main chain based on each user's identity, can be achieved in the following way: Deploy an independent blockchain specifically for certificate management, design a data structure for certificate storage on this certificate chain, including... The certificate chain includes fields such as user identity identifier, certificate serial number, public key information, certificate validity period, and certificate status. When a user registers, a record is generated on the certificate chain, binding the user's identity identifier to a randomly generated certificate and setting the initial status of the certificate to valid. This blockchain used for certificate management serves as the certificate chain, and all generated certificates serve as access credentials for the corresponding user to access the main chain. Storing certificate information avoids the degradation of transaction processing performance caused by a large amount of certificate data mixed in with the main chain or sub-chains. At the same time, the independent certificate chain provides an immutable distributed ledger for the entire lifecycle management of certificates. The data structure of fields such as identity identifier, certificate serial number, public key information, validity period, and status ensures the integrity and verifiability of certificate information, providing a reliable basis for identity authentication when users access the main chain, and supporting management operations such as periodic certificate updates and abnormal revocation. Other embodiments may also use other methods, which are not limited here.

[0035] In specific implementation, the quota strategy can be compiled into smart contract code and deployed to the transaction ledger of the corresponding sub-chain in the following way: the final number of goods that each user can obtain as determined in the quota strategy is written into smart contract code. The smart contract includes data fields such as user address, product identifier, and quota quantity, as well as function methods such as allocating quota, querying quota, and transferring quota. The written smart contract code is compiled into blockchain executable bytecode, and then the bytecode is deployed to the sub-chain of the corresponding product category. During deployment, the owner and management permissions of the contract need to be specified. Finally, the executable program deployed on the sub-chain is used as the smart contract code of the quota strategy. Other embodiments may also use other methods to implement this, which are not limited here.

[0036] It should be noted that the independent transaction ledger is a distributed ledger that records all transaction data on the corresponding sub-chain; the certificate chain is a dedicated blockchain used to store and manage the status and validity of each user's digital certificate; the access credential is a digital certificate used to prove the legitimacy of a user's identity and allow them to access the main chain to participate in transactions; smart contract code is a computer program that transforms quota policies into computer programs that can be automatically executed on the blockchain; the hybrid blockchain network for collaborative e-commerce transactions is a blockchain system composed of a main chain, a certificate chain, and multiple business sub-chains that support multi-person collaborative transactions. It is used to uniformly manage the global transaction status and cross-chain coordination on the main chain, to achieve anonymous authentication and traceability management of user identities on the certificate chain, and to distribute and process the collaborative transaction process of different categories of goods on each business sub-chain and record transaction details. This facilitates load balancing through a layered architecture to avoid single-chain overload, and while protecting user privacy, it also takes into account regulatory traceability requirements and ensures cross-chain data consistency and transaction atomicity.

[0037] In step 103, the global time lock of the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock of the individual user payment time limit on the sub-chain are determined. Then, the payment lock state during collaborative transactions is bound across chains to obtain the atomic execution conditions for multi-user cross-chain collaborative transactions.

[0038] In some embodiments, determining the global time lock for the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock for the individual user payment time limit on the sub-chain can be achieved through the following steps: The hash time lock contract of the main chain of the hybrid blockchain network generates a random preimage and calculates the unlocking certificate for the global time lock; A total time limit is set in the main chain, and the unlocking certificate is bound to the total time limit to obtain a global time lock for the overall user payment time limit; The unlocking credentials are synchronized to the hash time lock contracts of each subchain, and an individual time limit for each user to complete the payment is set in each subchain. The unlocking credential is bound to the individual time limit of each user to obtain a local time lock for the corresponding user's payment.

[0039] In specific implementation, the generation of a random preimage and calculation of the unlocking credential for the global time lock by the hash time lock contract of the main chain of the hybrid blockchain network can be achieved in the following way: A random number generation function is called in the hash time lock contract of the main chain to generate a sufficiently long random string as the preimage. Then, a hash function such as SHA-256 is used to calculate this random preimage to obtain a hash value of fixed length. Finally, the calculated hash value is used as the unlocking credential for the global time lock. The characteristic of the hash value is that the hash value can be calculated knowing the preimage, but the preimage cannot be deduced from the hash value. Therefore, in collaborative transactions, only when the user discloses the correct random preimage upon completion of payment confirmation can the corresponding time lock be unlocked, thus ensuring the reliable implementation of the atomic execution condition and preventing any party from prematurely unlocking the preimage by deducing the hash value, leading to transaction chaos. Other embodiments may also use other methods, which are not limited here.

[0040] In specific implementation, a total time limit is set in the main chain, and the unlocking credential is bound to the total time limit. The global time lock for the overall user payment time limit can be implemented as follows: A time parameter is set in the hash time lock contract of the main chain. This time parameter represents the latest time when all users must complete payment confirmation, typically represented by the blockchain block height or an absolute timestamp. The unlocking credential is then bound to the total time limit parameter and stored to form a lock record. This lock record can only be released if both conditions are met simultaneously: a correct unlocking credential is provided and the current time has not exceeded the total time limit. Ultimately, the locking mechanism binding the unlocking credential and the total time limit serves as the global time lock. The unlocking credential is synchronized to the hash time lock contracts of each sub-chain, and an individual time limit for completing payment is set for each user in each sub-chain. This can be implemented as follows: The unlocking credential generated on the main chain is sent to all relevant sub-chains via a cross-chain communication protocol. Each sub-chain, upon receiving the unlocking credential, sets its own hash time lock contract. The unlocking credential is stored in the time-lock contract. Then, an individual time limit is set for each user participating in the transaction on each subchain. This individual time limit can be slightly shorter than the total time limit of the main chain, allowing time margin for cross-chain communication. Finally, the unlocking credential is synchronized to each subchain, and the individual time limit is set. Binding the unlocking credential to each user's individual time limit to obtain the corresponding user's local time lock for payment can be implemented as follows: On each subchain, the stored unlocking credential is bound to each user's individual time limit, generating an independent lock record for each user. Each user's lock record contains the same unlocking credential but a different individual time limit. When a user completes payment confirmation within the individual time limit, they need to provide a random preimage corresponding to the unlocking credential to unlock their local lock. Finally, the locking mechanism that binds the unlocking credential and individual time limit for each user serves as the local time lock for that user. Other embodiments can also be implemented in other ways, which are not limited here.

[0041] It should be noted that a global time lock is generated through the main chain, and the same credential is synchronized to each sub-chain and bound to each user's individual time limit to form a local time lock. This creates a hierarchical dependency between the global and individual time locks. All users share the same unlocking credential but each has an independent time window. The global time lock can only be released when each user provides the correct random preimage within their individual time limit. This ensures the atomicity of multi-user collaborative transactions, that is, either all payments are successful or automatic rollback occurs. This effectively solves the problem of transaction inconsistency caused by some users paying and some users regretting their payments.

[0042] It should be noted that the unlocking credential in this application is a hash value used to unlock the global time lock and the local time lock, which is calculated by a hash function from a random preimage. The global time lock is a locking mechanism that controls the total time limit for all users to complete the payment. The local time lock is a locking mechanism that controls the individual time limit for a single user to complete the payment. The unlocking credential, the global time lock, and the local time lock together form a hash time lock protocol in a multi-user collaborative scenario. This facilitates the atomicity guarantee of multi-user payments through a mechanism of cross-chain sharing of the same credential and two-layer time limit hierarchical management. It effectively solves the transaction inconsistency problem caused by some users' successful payments and some users' failed payments under the traditional single-chain architecture, and provides a safe and reliable technical foundation for users to participate in collaborative transactions in virtual reality scenarios.

[0043] In some embodiments, binding the payment lock state during collaborative transactions to the cross-chain state to obtain the atomic execution conditions for multi-user cross-chain collaborative transactions can be achieved through the following steps: Determine the payment confirmation status of the local time lock of each user on each sub-chain and the global payment status of the main chain during collaborative transactions; By cross-chain binding of all payment confirmation statuses with the global payment status, the status binding conditions are obtained. The triggering rules for the global time lock are set based on the state binding conditions; The state binding condition and the triggering rule are jointly determined as the atomic execution condition for multi-user cross-chain collaborative transactions.

[0044] In specific implementation, determining the payment confirmation status of each user's local time lock on each sub-chain and the global payment status of the main chain during collaborative transactions can be achieved in the following way: The hash time lock contract of the main chain generates a random string as a preimage when generating the global time lock. This preimage is a sufficiently long random number and is only stored by the main chain contract. The hash value obtained after calculating it using the SHA-256 hash function is used as the unlocking credential and synchronized to each sub-chain. Local time lock contracts deployed on each sub-chain monitor the payment status of each user in real time. When a user initiates a payment confirmation transaction within their individual time limit, in addition to completing the fund transfer, they must also provide the original random string corresponding to the unlocking credential. The inter-chain lock contract performs a hash calculation on the string provided by the user. If the calculation result matches the stored unlocking credential, it determines that the user has completed payment confirmation, and marks the user's payment confirmation status from incomplete to complete. At the same time, it records the specific block height and timestamp of the user's payment completion. If the user fails to provide the correct random preimage by the time limit, the user's payment confirmation status is marked as timed out. Meanwhile, a global payment status variable is maintained on the main chain. The initial value of this variable is incomplete. Ultimately, the payment confirmation status of each user on each sub-chain and the global payment status variable on the main chain are used together as the status information that needs to be bound across chains. Other implementation methods can also be used in other embodiments, which are not limited here.

[0045] In specific implementation, all payment confirmation states are cross-chain bound to the global payment state. The state binding conditions can be achieved as follows: For each user's local timelock payment confirmation state on each sub-chain, a corresponding cross-chain state mapping is registered on the main chain. A global payment state variable is maintained on the main chain, defined as a logical AND function of the payment confirmation states of all users on all sub-chains. When a sub-chain node detects a change in the payment confirmation state of a user on its chain, it generates a cross-chain state update proof containing information such as the user's identifier, the new payment confirmation state value, the sub-chain identifier, and the block height. This proof is then verified through a pre-defined cross-chain state mapping in the hash timelock contract. The chain communication protocol sends the proof to the main chain. After receiving the proof, the main chain node first verifies its authenticity and validity. If it confirms that there are no errors, it updates the payment confirmation status cache of the corresponding sub-chain user according to the information in the proof. Then, it recalculates the value of the global payment status variable, that is, it performs a logical AND operation on all cached states. If all user states are completed, the global payment status is updated to completed; otherwise, it remains incomplete. Finally, this functional dependency relationship between the sub-chain payment confirmation status and the main chain global payment status, established through cross-chain state mapping and real-time synchronization mechanism, is used as the state binding condition. Other embodiments may also use other methods to implement this, which are not limited here.

[0046] In specific implementation, the triggering rule for the global time lock based on the state binding conditions can be implemented in the following way: based on the established state binding conditions, the behavior rules for the global time lock are set. The rules are that when the global payment status changes from incomplete to completed, the global time lock is automatically unlocked and subsequent fund splitting and property transfer operations are triggered. When the global payment status remains incomplete after the total time limit has expired, the global time lock automatically triggers a transaction rollback operation, returning all locked funds to the corresponding users. Finally, the above judgment rule is used as the triggering rule for the global time lock. Other embodiments may also use other methods to implement this, which are not limited here.

[0047] In specific implementation, the state binding condition and the triggering rule can be used to determine the atomic execution condition for multi-user cross-chain collaborative transactions in the following way: the state binding condition and the set triggering rule are combined to form a complete set of judgment logic. This logic ensures that in multi-user collaborative transactions, the transaction will only continue to execute when all users have completed payment confirmation within the specified time. If even one user fails to complete payment confirmation on time, the entire transaction will automatically roll back, preventing an inconsistent state where some users successfully pay while others fail. This complete set of judgment logic is ultimately used as the atomic execution condition for multi-user cross-chain collaborative transactions. Other embodiments may also use other methods, which are not limited here.

[0048] It's important to note that establishing a cross-chain state binding mechanism from subchains to the main chain maps the local timelock payment confirmation status of each user on each subchain to the global payment status of the main chain in real time, forming a dependency relationship where local states determine global states. Triggering rules for the global timelock are then set based on this binding relationship. This extends the atomicity protocol of hash timelocks in cross-chain asset exchange to multi-user collaborative transaction scenarios. Cross-chain state binding solves the problem of inconsistent monitoring of payment status when multiple users are scattered across different subchains, ensuring that users on different subchains can achieve state collaboration. Specifically, payment confirmation status is a marker indicating whether each user has completed payment confirmation within their respective local timelock; global payment status is a comprehensive status information representing the payment progress of all users recorded on the main chain; state binding conditions are rules describing the linkage between the payment confirmation status of each user on the subchain and the global payment status on the main chain; triggering rules are criteria defining what operation the global timelock should perform when the global payment status meets specific conditions; and atomic execution conditions are a complete set of rules ensuring that multi-user cross-chain collaborative transactions either all execute successfully or all automatically roll back.

[0049] In step 104, when a user confirms a transaction according to the quota strategy, the transaction is executed according to the execution conditions. If the number of users who complete the payment confirmation within the preset total time reaches the minimum group size, the global time lock contract will split the funds and transfer the ownership certificate to the goods provider. Otherwise, all payment locks will be released and the transaction will be rolled back.

[0050] In some embodiments, the global time lock contract in this embodiment can perform fund splitting and transfer of ownership certificates to the goods provider by the following steps: The main chain monitors the payment confirmation status of each sub-chain in real time. When the number of users who have completed payment confirmations in the collaborative transaction reaches the minimum threshold for group formation within the preset total time, the conditions for transaction execution are deemed met. Calculate the share of funds that each user should pay based on the optimal acquisition quantity determined in each user's quota strategy; After aggregating the payment shares of each user, the amount is transferred to the goods provider, and a digital property rights certificate corresponding to the quantity obtained is created for each user, and the certificate is transferred to each user.

[0051] In practice, the calculation of each user's share of funds, based on the optimal acquisition quantity determined in each user's quota strategy, can be achieved as follows: multiply each user's optimal acquisition quantity by the unit price of the target product to obtain the user's basic payment amount; then, after adding a deposit, handling fee, or discount according to the transaction rules, obtain the final share of funds each user should pay; where the minimum group size is the minimum number of users who have completed confirmed payment, which is pre-set by the product provider based on total inventory and expected revenue when publishing the collaborative transaction; the preset total time is the total time limit of the global time lock, dynamically configured according to transaction complexity, network latency, and the average time taken for user payment operations, typically set between 60 and 300 seconds; (Reference) Figure 3 As shown, this diagram illustrates the scenario interaction of transferring property rights certificates in some embodiments of this application. During fund transfer and certificate transfer, after determining that the group formation conditions are met, the global time lock contract automatically aggregates the fund shares of all users who have completed payment and transfers them to the product provider's account in one go through a smart contract. At the same time, it generates a digital property rights certificate containing user identifier, product identifier, and acquisition quantity based on the optimal acquisition quantity of each user. After being digitally signed by the product provider, the certificate is transferred to the corresponding user's blockchain account. Other embodiments may also employ other methods, which are not limited here.

[0052] Furthermore, in another aspect of this application, in some embodiments, this application provides an e-commerce transaction system based on multi-user collaboration, see reference. Figure 4The figure is a schematic diagram of the structure of a multi-user collaborative e-commerce transaction system according to some embodiments of this application. The multi-user collaborative e-commerce transaction system includes: a data acquisition module 401, a processing module 402, and an execution module 403, which are described below: The data collection module 401 in this application is mainly used to collect the interactive operations of multiple users on the same target product during e-commerce transactions and the historical transaction performance data of the corresponding users to obtain a user behavior dataset. Processing module 402, in this application, is used to determine the transaction credibility of each user in collaborative transactions based on the user behavior dataset, determine the quota strategy of each user in collaborative transactions based on all transaction credibility, each user's purchase demand and the inventory of the target product, and then construct a hybrid blockchain network for collaborative e-commerce transactions based on the identity of each user, the category attribute of the target product and the quota strategy. It should be noted that the processing module 402 in this application is also used to determine the global time lock of the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock of the individual user payment time limit on the sub-chain, and then bind the payment lock state during collaborative transactions across chains to obtain the atomic execution conditions for multi-user cross-chain collaborative transactions. The execution module 403 in this application is mainly used to trigger transaction execution according to the execution conditions when the user confirms the transaction according to the quota strategy. If the number of users who complete the confirmation payment within the preset total time reaches the group formation minimum, the global time lock contract will split the funds and transfer the property rights certificate to the product provider. Otherwise, all payment locks will be released and the transaction will be rolled back.

[0053] In addition, this application also provides a computer device, which includes a memory and a processor. The memory stores code, and the processor is configured to acquire the code and execute the above-described e-commerce transaction method based on multi-person collaboration.

[0054] In some embodiments, reference Figure 5 The figure is a schematic diagram of the structure of a computer device implementing a multi-user collaborative e-commerce transaction method according to some embodiments of this application. The multi-user collaborative e-commerce transaction method in the above embodiments can be implemented through... Figure 5 The computer device shown is used to implement this, and the computer device includes at least one processor 501, a communication bus 502, a memory 503, and at least one communication interface 504.

[0055] Processor 501 can be a general-purpose central processing unit (CPU) or an application-specific integrated circuit (ASIC).

[0056] The communication bus 502 can be used to transmit information between the aforementioned components.

[0057] Memory 503 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CDROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile optical discs, Blu-ray discs, etc.), magnetic disks or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. Memory 503 may exist independently and be connected to processor 501 via communication bus 502. Memory 503 may also be integrated with processor 501.

[0058] The memory 503 stores program code for executing the scheme of this application, and its execution is controlled by the processor 501. The processor 501 executes the program code stored in the memory 503. The program code may include one or more software modules. The method used in the above embodiments can be implemented by the processor 501 and one or more software modules in the program code in the memory 503.

[0059] Communication interface 504 uses any transceiver-like device to communicate with other devices or communication networks, such as Ethernet, radio access network (RAN), wireless local area networks (WLAN), etc.

[0060] In a specific implementation, as one example, a computer device may include multiple processors, each of which may be a single-core (single CPU) processor or a multi-core (multi CPU) processor. Here, a processor may refer to one or more devices, circuits, and / or processing cores used to process data (e.g., computer program instructions).

[0061] The aforementioned computer device can be a general-purpose computer device or a special-purpose computer device. In specific implementations, the computer device can be a desktop computer, a portable computer, a network server, a handheld digital assistant (PDA), a mobile phone, a tablet computer, a wireless terminal device, a communication device, or an embedded device. This application does not limit the type of computer device.

[0062] In addition, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described e-commerce transaction method based on multi-person collaboration.

[0063] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0064] Obviously, those skilled in the art can make various modifications and variations to this application without departing from the spirit and scope of this application. Therefore, if such modifications and variations fall within the scope of the claims of this application and their equivalents, this application also intends to include such modifications and variations.

Claims

1. A multi-person collaborative e-commerce transaction method, characterized in that, Includes the following steps: Collect user behavior datasets by collecting interactive operations of multiple users on the same target product during e-commerce transactions and the corresponding users' historical transaction fulfillment data; The transaction credibility of each user in collaborative transactions is determined based on the user behavior dataset. Based on all transaction credibility, each user's purchase demand and the inventory of the target product, the quota strategy for each user in collaborative transactions is determined. Then, a hybrid blockchain network for collaborative e-commerce transactions is constructed based on the identity of each user, the category attributes of the target product and the quota strategy. The global time lock for the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock for the individual user payment time limit on the sub-chain are determined. Then, the payment lock state during collaborative transactions is bound across chains to obtain the atomic execution conditions for multi-user cross-chain collaborative transactions. When a user confirms a transaction according to the quota strategy, the transaction is executed according to the execution conditions. If the number of users who complete the payment confirmation within the preset total time reaches the minimum group size limit, the global time lock contract will split the funds and transfer the ownership certificate to the product provider. Otherwise, all payment locks will be released and the transaction will be rolled back.

2. The method as described in claim 1, characterized in that, The user behavior dataset is obtained by collecting interaction data from multiple users on the same target product during e-commerce transactions, as well as the corresponding users' historical transaction fulfillment data. Specifically, it includes: The eye-tracking unit collects the gaze point coordinate sequence of each user when they gaze at the target product. The gesture recognition unit collects the gesture trajectory data of each user when interacting with the target product; Record the response timestamps for each user from the moment the target product is displayed until the user issues an interaction command; Collect historical transaction fulfillment data from each user; All gaze coordinate sequences, gesture trajectory data, and response timestamps are aligned and noise is filtered out to obtain the user behavior dataset.

3. The method as described in claim 1, characterized in that, Determining the transaction credibility of each user in collaborative transactions based on the aforementioned user behavior dataset specifically includes: The spatial coordination factor between any two users in the virtual scene is determined based on the gaze point coordinate sequence in the user behavior dataset. The time decision factors for each user's target product are determined based on the response timestamps in the user behavior dataset. Determine the historical performance credit score for each user; By weighting and integrating all spatial collaboration factors, time decision factors, and performance credit scores, the transaction credibility of each user in collaborative transactions is obtained.

4. The method as described in claim 1, characterized in that, The quota strategy for collaborative transactions among users is determined based on the credibility of all transactions, the purchasing needs of each user, and the inventory of the target product. Specifically, this includes: Obtain the total inventory of the target product and the purchasing demand of each user; The initial quota ratio for each user is calculated by combining all purchase demands and the total inventory. The acquisition priority of corresponding users is determined based on all initial quota ratios and all transaction credibility. Collect acceptance data from each user under their respective acquisition priority. By iteratively recursively applying the acceptance data, the quota strategy for collaborative transactions among various users can be obtained.

5. The method as described in claim 1, characterized in that, The construction of a hybrid blockchain network for collaborative e-commerce transactions based on user identities, target product category attributes, and the quota strategy specifically includes: The number of nodes is determined based on the transaction concurrency requirements of the quota strategy, and a main chain is constructed to record the global transaction status. Based on the category attributes of the target product, create corresponding sub-chains under the main chain, and configure independent transaction ledgers for each sub-chain; Construct a certificate chain that stores the certificate status and validity of users, and then obtain the access credentials for each user to access the main chain based on the identity of each user; The quota policy is compiled into smart contract code and deployed to the transaction ledger of the corresponding subchain; The main chain, the certificate chain, and all sub-chains are combined into a hybrid blockchain network for collaborative e-commerce transactions.

6. The method as described in claim 1, characterized in that, The determination of the global time lock for the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock for the individual user payment time limit on the sub-chain specifically includes: The hash time lock contract of the main chain of the hybrid blockchain network generates a random preimage and calculates the unlocking certificate for the global time lock; A total time limit is set in the main chain, and the unlocking certificate is bound to the total time limit to obtain a global time lock for the overall user payment time limit; The unlocking credentials are synchronized to the hash time lock contracts of each subchain, and an individual time limit for each user to complete the payment is set in each subchain. The unlocking credential is bound to the individual time limit of each user to obtain a local time lock for the corresponding user's payment.

7. The method as described in claim 1, characterized in that, The cross-chain state binding of the payment lock state during collaborative transactions, resulting in atomic execution conditions for multi-user cross-chain collaborative transactions, specifically includes: Determine the payment confirmation status of the local time lock of each user on each sub-chain and the global payment status of the main chain during collaborative transactions; By cross-chain binding of all payment confirmation statuses with the global payment status, the status binding conditions are obtained. The triggering rules for the global time lock are set based on the state binding conditions; The state binding condition and the triggering rule are jointly determined as the atomic execution condition for multi-user cross-chain collaborative transactions.

8. A multi-user collaborative e-commerce transaction system, characterized in that, include: The data collection module is used to collect the interaction operations of multiple users on the same target product during e-commerce transactions and the corresponding users' historical transaction fulfillment data to obtain a user behavior dataset. The processing module is used to determine the transaction credibility of each user in collaborative transactions based on the user behavior dataset, determine the quota strategy for each user in collaborative transactions based on all transaction credibility, each user's purchase demand and the inventory of the target product, and then construct a hybrid blockchain network for collaborative e-commerce transactions based on the identity of each user, the category attribute of the target product and the quota strategy. The processing module is also used to determine the global time lock of the overall user payment time limit on the main chain of the hybrid blockchain network and the local time lock of the individual user payment time limit on the sub-chain, and then bind the payment lock state during collaborative transactions across chains to obtain the atomic execution conditions for multi-user cross-chain collaborative transactions. The execution module is used to trigger transaction execution according to the execution conditions when a user confirms a transaction in accordance with the quota strategy. If the number of users who complete the confirmation payment within the preset total time reaches the minimum group size limit, the global time lock contract will split the funds and transfer the ownership certificate to the goods provider. Otherwise, all payment locks will be released and the transaction will be rolled back.

9. A computer device, characterized in that, The computer device includes a memory and a processor, the memory storing code, and the processor being configured to retrieve the code and execute the multi-user collaborative e-commerce transaction method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the e-commerce transaction method based on multi-person collaboration as described in any one of claims 1 to 7.

Images