PBTMS: A Blockchain-Based Privacy-Preserving System for Reliable and Efficient E-Commerce

Abstract

With the development of communication infrastructure and the popularity of smart devices, e-commerce is presenting in more diverse forms and attracting the attention of more and more users. Since e-commerce transactions usually involve sensitive information of a large number of users, privacy and security have become increasingly important issues. Despite certain advantages (e.g., trading security), the privacy protection capability and efficiency of blockchain is still limited by some key factors, especially of its architecture. In this paper, we propose a blockchain-based privacy protection system named PBTMS that integrates zero-knowledge proofs, hybrid encryption, and Pedersen commitments as foundational mechanisms to ensure robust privacy protection for transaction data and user information. To achieve secure, reliable, and efficient e-commerce transactions, the PBTMS employs blockchain technology and consensus mechanisms to enable distributed storage, thereby mitigating single points of failure and addressing the risks posed by malicious nodes. Moreover, by integrating on-chain storage with off-chain computation, the system substantially reduces blockchain-related overheads, including processing time, gas consumption, and storage costs. This design establishes the PBTMS as a highly adaptable and efficient system for the evolving requirements of secure and privacy-preserving e-commerce platforms. Theoretical analysis and experimental validation demonstrate that PBTMS reduces decryption and authentication times by 79.2% and 52.6%, respectively, while cutting encrypted data size by 52.5% and overall gas consumption by 55.4%, outperforming state-of-the-art solutions. These results indicate that PBTMS is a reliable and efficient system for secure e-commerce transaction platforms and provides a novel approach to enhancing privacy protection in e-commerce.

1. Introduction

With the development of communication infrastructure and the popularity of smart devices, e-commerce is presenting in more diverse forms, such as live streaming [1,2] and cross-border transactions [3,4]. These e-commerce activities have some specific characteristics, such as real-time interaction and personal recommendation, and thus greatly change people’s shopping habits. Correspondingly, e-commerce is attracting the attention of more and more users, so the scale of transactions and the number of users have significantly expanded. The frequency of users’ online transactions and the use of personal information have increased substantially [5].

Since e-commerce transactions usually involve sensitive information of a large number of users, privacy and security have become increasingly important issues in today’s rapidly evolving e-commerce landscape [6,7,8,9]. The information provided by users in online trading is at risk of being maliciously accessed by unauthorized third parties, which may lead to serious privacy leaks [10,11,12]. Notably, Albshaier et al. [13] noted that due to the lack of transparency and adequate security measures for e-commerce platforms, trading data and user information stored on remote servers are highly vulnerable to cyber-attacks and unauthorized access, thereby increasing the risk of data theft or leakage. Kim et al. [14] pointed out that fraudulent trading by malicious users, such as fake purchases or refund scams, further exacerbates the security concerns of online trading. In particular, numerous data breach incidents have occurred in recent years, which have aroused great concern among people. For example, Equifax experienced a major data breach during which hackers managed to pilfer sensitive information belonging to more than 146.6 million consumers in 2017 [15]. Another latest example is that Change Healthcare, a data processing firm owned by the UnitedHealth Group, was the target of a ransomware cyberattack in 2024 and thus suffered losses of more than USD 78 million [16].

These security issues indicate the need for more comprehensive security measures to protect users’ personal information and trading data in e-commerce. Fortunately, blockchain has been demonstrated by prior studies as an effective security technique to improve the security of users’ information and trading data in e-commerce [12,17]. Compared to traditional privacy protection mechanisms that offer anonymity by scrambling the direct connection between the sender and receiver, the blockchain can not only reduce the dependence on single points of failure through distributed nodes but also protect user identity information by allowing authorized accounts to access the data [13,18]. Because of these advantages, blockchain has been successfully applied to multiple scenes in e-commerce, such as trusted trading platforms [19,20], reputation systems [21,22,23,24], secure search [25], identity authentication [26], price auditing [27], and sales mode selection [28]. Particularly, Dahal [29] pointed out that since trading data in e-commerce are special due to immutable and time-stamped characteristics, a blockchain-based guarantee of integrity, anti-tampering, and traceability is necessary and challenging.

Therefore, this paper integrates blockchain technology for data storage and proof records to enhance system security. Blockchain’s decentralization, immutability, and smart contracts reduce the risk of data tampering, ensure integrity, and provide transparent transaction tracking, which complements traditional security strategies for e-commerce systems.

Despite certain advantages, the privacy protection capability of blockchain is still limited by some key factors, especially its architecture. For example, Taherdoost and Madanchian [30] emphasized that the distributed ledger and decentralized nature of blockchain can threaten user anonymity, which becomes a major limiting factor for blockchain in e-commerce applications. Ghesmati et al. [31] argued that blockchain may be cracked by on-chain analysis and thus increases the computation costs and compliance risks. To this end, research has gradually shifted to more advanced privacy-preserving technologies like ring signatures, stealth addresses, confidential trading, and zero-knowledge proofs. These technologies protect the privacy of identities and trading amounts while guaranteeing the verifiability of trading. For example, Zerocash is the first blockchain-based security trading platform that enables completely anonymous trading through the zk-SNARKs protocol [32]. Monero [33] implements anonymous cryptocurrency with enhanced accountability for a high level of privacy protection based on the CryptoNote protocol and M-LSAG. Zether [34] combines smart contracts and non-interactive zero-knowledge proofs to provide anonymous trading support for Ethereum users. Furthermore, BlockMaze [35] protects user privacy through a dual balance model based on zk-SNARKs.

In this paper, our main objective is to design a reliable and efficient blockchain-based e-commerce trading system that ensures privacy protection for transactions and provides data security for users’ information. However, the practical implementation of such a system faces several significant challenges that must be addressed to fully realize the potential of blockchain technology in e-commerce. Specifically, the system is confronted with the following three key challenges:

• Ensuring node credibility: Blockchain’s reliance on multiple nodes for transaction validation adds complexity, with reward-and-punishment mechanisms and limited interoperability between platforms, which can undermine node reliability and system credibility.
• Node abuse in data access: Blockchain’s transparency can lead to vulnerabilities, where nodes with access to sensitive data may exploit this privilege, potentially altering transaction history, breaching data integrity, and threatening user privacy.
• Balancing privacy and performance: Privacy-preserving techniques like zero-knowledge proofs protect sensitive data but add performance overhead, challenging the balance between privacy and system efficiency without sacrificing scalability or user experience.

To this end, we propose a comprehensive solution to address these challenges. By enhancing privacy protection and data security, mitigating the risks posed by malicious nodes, and achieving an optimal balance between performance and privacy, we aim to establish a reliable and efficient blockchain ecosystem tailored for e-commerce transactions.

We propose a blockchain-based e-commerce transaction system, PBTMS, to address challenges such as node credibility, privilege abuse, and the balance between privacy protection and performance. The system prevents third-party access to user and transaction information while ensuring the validity and privacy of transactions. It achieves this through privacy protection mechanisms, access control, and tolerance to malicious nodes. By leveraging blockchain technology, PBTMS ensures secure data transmission and reliable transaction storage. It integrates hybrid encryption, zero-knowledge proofs, digital signatures, and Pedersen commitments to provide high privacy protection and data security for online physical goods transactions. The main reasons why we use these security techniques include the following:

• Pedersen commitment: Due to its strong tamper-resistance and content-hiding properties, Pedersen’s commitment ensures transaction data privacy and consistency verification in blockchain-based e-commerce. It prevents information leakage while maintaining data integrity and transparency, meeting the system’s privacy protection requirements.
• Schnorr signatures: Schnorr signatures provide high security while reducing computational overhead. They enable efficient signature generation and verification in blockchain environments, improving transaction verification efficiency and supporting high performance for large-scale transactions, ensuring the e-commerce platform maintains privacy protection without compromising system efficiency.
• Bulletproofs: As a non-interactive zero-knowledge proof technology, Bulletproofs verify data validity without revealing specific data. They are ideal for verifying users’ purchasing power in e-commerce systems. Compared to other zero-knowledge proofs, Bulletproofs offer smaller proof sizes and higher computational efficiency, reducing storage needs and enhancing performance while maintaining strong security.
• ECC and AES shared key technology: ECC is widely used for its shorter key lengths and efficient computation. Combined with AES, it provides robust encryption to ensure data security during transactions. In blockchain-based e-commerce systems, the combination of ECC and AES offers an optimal balance of security and performance, making it an ideal choice for privacy protection in high-frequency trading and large-scale data processing.

The system adopts an on-chain/off-chain architecture to simplify data storage and distribution processes, improving efficiency. PBTMS uses a decentralized design, including an off-chain committee composed of blockchain miners, integrating consensus mechanisms and reputation systems to reduce the impact of malicious nodes. It strengthens node behavior constraints while addressing the trade-off between privacy and performance, establishing a reliable trust mechanism for e-commerce transactions.

In summary, our main contributions in this paper are listed as follows:

• We propose a blockchain-based trading system with on-chain storage and off-chain computation, which effectively protects private information and balances performance. Smart contracts store trading data identifiers and access authorizations, while complex operations such as encryption, verification, and computation are executed off-chain. Fine-grained data access control is achieved through shared keys.
• The concrete implementation of hybrid encryption and multi-level cryptography is proposed. For data privacy, hybrid chunked data encryption combining ECC and AES ensures the security of trading information and transaction amounts. To enhance proof mechanisms, Schnorr digital signatures, bulletproof range proofs, and Pedersen’s commitment are employed, thereby offering both efficiency and robust protection against information leakage. Meanwhile, in terms of storage, the integration of distributed storage mechanisms through smart contracts and IPFS ensures data tamper resistance while mitigating the challenges of large-scale on-chain storage. This multi-faceted approach effectively balances security, efficiency, and scalability.
• We conducted extensive experiments to evaluate the proposed system in complex e-commerce scenarios. The results show significant efficiency improvements, with decryption and authentication times reduced by 79.2% and 52.6%, respectively, and overall gas consumption decreased by 55.4%, lowering operational costs. Our findings highlight the PBTMS’s effectiveness in ensuring privacy and security while demonstrating excellent scalability, practicality, and stability for secure and efficient e-commerce systems.

The remainder of this paper is structured as follows. Section 2 reviews the related work on privacy protection in e-commerce based on blockchain. Section 3 introduces the leading technologies used in this paper. Section 4 introduces the system overview, workflow, and enemy model. Section 5 presents the algorithm flow of the system in detail. In Section 6, we describe the safety and performance analyses. In Section 7, we experimentally evaluate the performance of the system and analyze the results. In Section 8, we summarize our main work and discuss future research.

2. Related Work

In this section, we introduce the related work on privacy protection under blockchain and e-commerce, mainly including blockchain for e-commerce and privacy enhancement in blockchain-based e-commerce.

2.1. Blockchain for Privacy Protection of E-Commerce

In recent years, blockchain technology’s continuous development and expansion have demonstrated significant potential in privacy protection for e-commerce. The typical application scenes of blockchain in e-commerce include trusted trading platforms [19,20,36], reputation systems [21,22,23,24], secure search [25], identity authentication [26], price auditing [27], and sales mode selection [28]. For example, Li et al. [24] proposed a privacy-preserving reputation system based on blockchain for e-commerce, which supports all e-commerce platforms to collaboratively share users’ reputations and protect users’ identities by resisting multiple rating attacks. Takakubo et al. [27] utilized smart contract technologies to propose a price auditing system, which solves a price discrimination problem and thus offers the secure storage of product data and high-quality e-commerce services. Li et al. [28] analyzed the impact of blockchain on strategic and member operational decisions of e-commerce supply chains and derived the conditions of production and blockchain operating cost to determine a win–win outcome among supply chain members.

In particular, blockchain offers trusted e-commerce physical commodity trading systems by solving two core issues for the feasibility and widespread adoption of blockchain applications, such as trading validity and fairness [19,20,37,38,39]. Xie et al. [19] designed a trusted blockchain-based framework for higher credible trading, which utilizes a peer blockchain architecture to implement transaction storage and a strong consensus algorithm to ensure secure transactions. Liu et al. [20] designed a blockchain-based normalized autonomous transaction settlement system for IoT-related e-commerce, which contains a three-layer sharding blockchain network for improving transaction efficiency and system scalability and a searchable decentralized public key encryption protocol for uncovering illegal and criminal transactions. In addition, there are other security protocols for transaction protection and data security in e-commerce, such as ZKCP verifying payment accuracy and legitimacy without transaction details [37], RZKPB [38] enhancing trading fairness and privacy without sensitive financial information storage, and FairSwap offering digital commodity trading under secure information exchange of digital assets and services [39]. However, the above protocols still rely on sensitive data in e-commerce transactions. That is, zero-knowledge proof in ZKCP is only applied to trading data, while payment verification requires disclosing actual data. In RZKPB, commitment values and related verification information must be recorded on-chain, requiring extra storage.

2.2. Privacy Protection Enhancement in Blockchain-Based E-Commerce

Blockchain-based privacy-preserving algorithms can be enhanced by integrating advanced security techniques such as perturbation, encryption (e.g., differential privacy and homomorphic encryption), Tor networks, onion routing, zero-knowledge proofs (ZKPs), and trusted hardware. These techniques aim to ensure data security, communication privacy, and smart contract confidentiality [40]. However, they face significant challenges, including high computational overhead, reliance on trusted third parties, and performance limitations. For instance, AIDTHS [41] employs identity threshold signatures to conceal the signer’s identity but relies on trusted third parties. LedgerMaze [42] uses efficient zero-knowledge proofs to hide trading information, but its performance is affected by the amount of information it contains. MedShield et al. [43] proposed a blockchain and zero-knowledge proof-based medical data trading scheme, which depends on fully trusted regulators and assumes cloud servers to be semi-trusted, thereby introducing trust risks.

Compared to traditional privacy-preserving methods, zero-knowledge proofs (ZKPs) offer distinct advantages in ensuring data privacy while enabling efficient verification and reducing computational overhead. In blockchain and decentralized applications (DApps), ZKPs, particularly zk-SNARKs (succinct non-interactive zero-knowledge proofs), demonstrate immense potential. They provide clear advantages in proof generation and verification times, with zk-SNARKs exhibiting linear time complexity for proof generation. This means that as data volume increases, the proof generation time remains manageable, avoiding computational bottlenecks. Additionally, zk-SNARKs offer small proof sizes and low space complexity, making them ideal for efficient storage and rapid verification.

As shown in

Table 1. Comparison of computational overhead for privacy-preserving techniques (homomorphic encryption (HE), ring signatures (RS), and coin join protocol (CJP)).

Technique	Proof Generation Time	Verification Time	Proof Size
Zk-SNARK	$O\left(n\right)$	$O\left(1\right)$	Small
Zk-STARK	$O(nlogn)$	$O\left(1\right)$	Larger
HE	$O\left(n^2\right)$	$O\left(n^2\right)$	Larger
RS	$O\left(n\right)$	$O\left(1\right)$	Small
CJP	$O\left(n\right)$	$O\left(1\right)$	Medium

, compared to other privacy-preserving technologies, zk-SNARKs excel in computational efficiency, with proof generation time of O(n), verification time of O(1), and small proof sizes, making them highly suitable for efficient storage and fast verification.

Table 2. Comparison of resilience level of privacy-preserving techniques to various attacks (homomorphic encryption (HE), ring signatures (RS), and coin join protocol (CJP)).

Technique	Replay Attacks	Man-in-the-Middle Attacks	Modification Attacks	Selective Disclosure Attacks	Side-Channel Attacks
Zk-SNARK	Strong	Strong	Strong	Strong	Strong
Zk-STARK	Strong	Strong	Strong	Strong	Strong
HE	Strong	Moderate	Strong	Moderate	Moderate
RS	Moderate	Moderate	Moderate	Moderate	Moderate
CJP	Moderate	Moderate	Moderate	Moderate	Moderate

demonstrates the security advantages of zk-SNARKs, which exhibit strong resistance to replay attacks, tampering, and man-in-the-middle attacks, effectively safeguarding data integrity and privacy. Considering computational efficiency, security, and storage requirements, zk-SNARKs emerge as the preferred solution in privacy-preserving technologies, particularly for applications that require efficient verification and robust privacy protection.

In addition to privacy protection in blockchain-based e-commerce, access control and malicious node tolerance mechanisms have also become significant areas of focus. Blockchain-based permission control provides an overview of defining access rules through smart contracts by role-, attribute-, or policy-based control mechanisms [44]. BlockAuth offers storing access policies in smart contracts and decentralized authentication and pseudo-anonymous identity protection to achieve high security and privacy [45]. LockChain implements fine-grained permission management by using smart contracts, zero-knowledge proofs, and distributed collaboration, optimizing dynamic policy updates and multi-node verification [46]. However, these solutions store access policies on the blockchain and thus consume significant storage space. Malicious node tolerance mechanisms in distributed systems are commonly implemented through consensus, signature verification, sharding hierarchical networks, and incentives. However, high computational overhead remains a challenge. For instance, the Galaxy framework adopts shard-based BFT consensus with improved leader rotation but relies on the reputation of computing nodes to prevent malicious nodes from becoming leaders [47]. If multiple malicious nodes act simultaneously, system performance may still be affected. Additionally, pre-adapter signatures combined with P2SH scripts can provide offline fault tolerance without relying on smart contracts [48]. However, they involve multiple participants and dynamically generate adapter signatures, complicating key management and storage.

As shown in

Table 3. Comparison of blockchain-based privacy protection for e-commerce transactions.

Research	Method	Reference	Advantage	Disadvantage
Blockchain for E-Commerce	Fair Exchange	[37]	no middleman, secure payments, enforce conditions, data safeguard	publicly verified payment amounts
		[38]	sensitive data off-chain, no trust dependencies, identity systems	on-chain storage overhead of commitment values and verification data
		[39]	automated execution, no middleman, flexible economic incentives	limited privacy protection
Privacy Enhancement in Blockchain- based Commerce	Privacy- preserving	[41]	balance between privacy and traceability for compliant blockchain	reliance on specific roles, decentralization reduction
		[42]	strong privacy and flexible auditing	performance closely related to data amount, privacy leaks of auditing risks
		[43]	efficiency and scalability of data trading	fully trusted regulators
	Access Control	[45]	dynamic policies, traceable permissions, complex scenarios	policies stored on-chain consume storage
		[46]	private policies and attributes, fine-grained and dynamic management	policies broadcast across the network
	Malicious Node Tolerance	[47]	sharding-based random allocation for scalability	reliance on node reputation, high computational cost
		[48]	offline tolerance without smart contracts	complex key management with multiple participant signatures

, we explore blockchain-based protection approaches for e-commerce, integrating blockchain with IPFS to reduce computational complexity. We leverage stable proof sizes, permission management, and consensus mechanisms to enhance privacy and reliability and minimize single-point dependencies. Smart contracts handle permissions, with off-chain management of access policies for better system performance. Additionally, a decentralized off-chain committee and reputation system ensure node credibility and accountability and reduce the impact of malicious actors.

3. Preliminaries

In this section, we introduce the preliminaries of security techniques used in our designed private e-commerce system, mainly including Bulletproof, Schnorr digital signature, and Pedersen’s commitment.

3.1. Bulletproof

Bulletproof is a non-interactive zero-knowledge proof protocol designed for efficient range proofs without the need for a trusted setup [49]. The function of the protocol is to verify whether a committed value v lies within a specified range without revealing v. Bulletproof satisfies the properties of zero-knowledge proofs, including completeness, soundness, and zero-knowledge. Formally, given public parameters $G, H, l$, the commitment is defined as follows:

$$\mathrm{Com}\left(v\right)=vG+rH,v\in [0,2^l-1],$$

(1)

where $v, r$ are private values, $\mathrm{Com}\left(v\right)$ is the public value, and l denotes the length of the range. In general, the Bulletproof protocol consists of three main phases:

• Setup: $\mathrm{Setup}\left(1^{\lambda }\right)\to {\mathrm{pp}}_R$. This phase generates public parameters ${\mathrm{pp}}_R$ based on security parameter $\lambda$.
• Generate range proof: $\mathrm{GenRangeProof}({\mathrm{pp}}_R,\mathrm{Com}\left(v\right),w)\to \mathrm{RangeProof}$. This phase generates a range proof RangeProof using public parameter ${\mathrm{pp}}_R$ and private parameter w.
• Verify range proof: $\mathrm{VerRangeProof}({\mathrm{pp}}_R,\mathrm{Com}\left(v\right),\mathrm{RangeProof})\to b$. This phase verifies whether the range proof is valid. If successful, output $b=1$; otherwise, $b=0$.

3.2. Schnorr Digital Signature

The Schnorr digital signature scheme is a signature generation and verification process based on the discrete logarithm problem that utilizes elliptic curve cryptography to minimize computation costs [50]. In general, the main steps of the Schnorr scheme are listed as follows:

• Key generation: $\mathrm{KeyGen}(p,g,x)\to y$. The step first sets a large prime p and a generator g and then selects a private key $x<p$ to calculate the public key $y=g^{x}modp$.
• Signing: $\mathrm{Sign}(m,x)\to (e,s)$. For any message m, the step chooses a random $k<p$ and computes $r=g^{k}modp$ and hash $e=H(m\Vert r)$. Finally, the signature is derived as $s=(k-xe)mod(p-1)$.
• Verification: $\mathrm{Verify}(m,(e,s),y)\to \{\mathrm{True},\mathrm{False}\}$. This step computes $v=g^s{y}^{e}modp$ and then recalculates the hash $e^{\prime }=H(m\Vert r)$. The signature is derived as True if $e^{\prime }=e$; otherwise, $s=\mathrm{False}$.

3.3. Pedersen Commitment

The Pedersen commitment is a cryptographic protocol providing a binding and hiding commitment scheme that ensures both the privacy of the committed value and the inability of the committer to change the value once committed. Formally, the Pedersen commitment scheme is defined over a group of prime order q with a generator g and an additional independent generator h. Given a value $v\in {\mathbb{Z}}_q$ and a random value $r\in {\mathbb{Z}}_q$, the commitment C is computed as follows:

$$C=g^v{h}^{r}modp,$$

(2)

where v is the value to be committed, r is a random blinding factor, g and h are generators of a cyclic group of order q. The commitment ensures that C does not reveal v.

4. Overview of the System

In order to address security risks in physical e-commerce, we design a blockchain-based privacy-preserving system named PBTMS that ensures data integrity and privacy and reduces reliance on middlemen. The system prevents unauthorized access, tampering, and data loss so as to ensure traceability of e-commerce trading and protect stakeholders’ rights. Figure 1 shows the overview of PBTMS, including several core functions such as encryption, privacy preservation, distributed access control, verification, data traceability, and fair trading. These features collaboratively establish a secure, privacy-preserving system for online physical commodity trading that ensures the reliability and trustworthiness of e-commerce platforms.

4.1. Entities and Responsibilities

As shown in Figure 1, the entities of the system and their responsibilities are listed as follows:

• Buyer: The entity first initiates a trading request and submits its order to a seller. During these operations, the buyer should complete the identity authentication and balance proof to ensure the legitimacy and validity of the trading. After the amount of the trading is paid, the harvest proof should be submitted.
• Seller: Once receiving the trading request from the buyer, the entity should confirm the trading order, complete the authentication, and submit the proof of delivery.
• Trust authority: As a trusted institution, the entity is responsible for generating and publishing the key and authorizing the corresponding trading.
• Off-chain committee: The entity is responsible for two important functions, including (i) verifying identities, transaction validity, and completion status and (ii) authorizing access via smart contracts. It maintains member credibility with a reputation system, using multi-signature authorization and batch processing to improve throughput and ensure decentralized, secure, and efficient operation.
• Blockchain and IPFS: Blockchain stores trading metadata and permission management, while IPFS stores trading details and proofs and guarantees data integrity and privacy.

The five entities in the PBTMS collaborate to manage the entire lifecycle of e-commerce trading, including direct interactions between the buyers and sellers, verification services provided by the miner, coordination and oversight by the trusted authority, and distributed storage by the IPFS and blockchain. As a result, the system ensures trading privacy, security, and traceability and offers reliable technical support for e-commerce.

4.2. Off-Chain Committee Structure

In this paper, the off-chain committee in the PBTMS is primarily responsible for proof verification and authorization execution. To put it simply, the committee can be divided into two layers, i.e., verifying proofs and initiating multi-signature proposals in the first layer and reviewing the results in the second layer.

4.2.1. Operations of the Off-Chain Committee

In order to further ensure the security of the PBTMS, the off-chain committee adopts multiple key measures on the buyer and seller side, which are shown in Figure 2. At first, the buyer pre-pays the amount and uploads the order information without requiring review. After multi-signature approval by the first-layer committee, these operations take effect immediately, ensuring efficient transaction processing. Then, the seller downloads order information without any need for review after approval by the first-layer committee. After the first-layer committee initiates the proposal, it enters a time lock and requires review by the second-layer committee. This ensures that the seller’s identity is legitimate. If the seller’s identity is in doubt, the system will block the redemption of funds and close the transaction. Finally, if the seller’s identity is in question, the incorrect seller, who does not possess the corresponding private key, cannot access the true transaction information. The system will automatically close the transaction and return the buyer’s prepayment, avoiding malicious actions and ensuring fairness in the transaction.

4.2.2. Reputation System in the Off-Chain Committee

To ensure the fairness of the results, this paper implements a reputation system that manages the credibility of off-chain committee nodes. The specific responsibilities and rules of the reputation system are listed as follows:

• Responsibilities: The reputation system prevents malicious nodes from tampering with transactions, submitting invalid signatures, or being inactive for extended periods, which could affect the system’s stability. The behavior of each node is measured based on a reputation score (RS), thereby ensuring the security and long-term sustainable operation of the committee.
• Calculation rules: As shown in

  Table 4. Credit calculation rules.

  Behavior	Credit Change	Description
  Successful Participation	+5	Ensure long-term participation Enhance awareness efficiency
  Correct Signature Generation	+5	Ensure security of limited signatures
  Long-Term Inactivity	Removed	Penalize unparticipated points Prevent user hijacking
  Non-Participation	−20	Ensure participation in key points of the system
  Incorrect Judgment on Submission	−10	Prevent mistakes or invalid operations
  Incorrect Signature Submission	−30	Prevent invalid operations and identity fraud
  Credit Below 50	Removed	Prohibit participation in the system

  , each committee member’s initial reputation score is set to 50 in the rules. The reputation score is dynamically adjusted based on the behavior of the member.
• Credit score calculation: Formally, the credit score is defined as

  $$R{S}_{t+1}=R{S}_t+G·{\displaystyle \frac{1}{1+e^{-k(N-N_0)}}},$$

  (3)

  in which $R{S}_t$ is the reputation score at time t, G is the maximum reputation gain, N is the number of successful participations, $N_0$ is the threshold for reputation increase, and k is the growth rate constant.
• Impact of credit score: The credit score is defined as

  $$W\left(RS\right)={\left({\displaystyle \frac{RS}{100}}\right)}^2,$$

  (4)

  where $W\left(RS\right)$ is the weight of the node, and $RS$ is the reputation score of the node. This formula prevents the system from being significantly affected by nodes with low reputation.

4.3. Workflow of the System

The PBTMS ensures trading privacy, integrity, and security through encryption technologies, distributed verification, and decentralized management mechanisms. Figure 3 shows the workflow of how the buyer and seller complete the physical commodity trading in our designed privacy-preserving e-commerce. To put it simply, the workflow contains six parts, including trading initiation and key generation, identity verification and balance proof, authorization and data storage, data encryption and trading information retrieval, commodity delivery and status update, and dispute resolution. In the following section, we will introduce every part in detail.

4.3.1. Trading Initiation and Key Generation

The first key part of e-commerce trading is to initialize trading and generate the corresponding key. The detailed operations are listed as follows:

• ECC key generation: When a user creates an account, the trusted authority generates an ECC key based on the user’s information and timestamp. The key is sent to the user on the e-commerce platform via a TLS secure channel, and the user’s ECC key is periodically updated.
• Shared key generation: During the initiation of the transaction, the trusted authority encrypts predefined information (transaction ID, transaction start timestamp, and both parties’ public keys) and sends it to both parties via the TLS secure channel. The recipient decrypts the data to generate a shared key, ensuring confidentiality, security, and integrity.
• Order creation and fragment encryption: The buyer creates the order, ECC encrypts the prepayment amount and uploads it to the smart contract. The amount address, obfuscated (i.e., encrypted using AES), is placed into the transaction message. The transaction information is then fragmented, and the shared key is used to encrypt the order.

4.3.2. Identity Verification and Balance Proof

Both identity verification and balance proof are very important in the PBTMS and ensure trading security. The corresponding operations include the following:

• Schnorr signature generation: Both the buyer and seller generate a Schnorr signature using their public keys, the timestamp when requesting identity verification, and the transaction ID for authentication.
• Balance proof: The buyers generate Bulletproof for balance verification.
• Proof information contract: Balance proofs and signatures are uploaded to the blockchain.
• Proof information upload: The balance proof and signature are uploaded to the blockchain.
• Off-chain committee validation: The agent notifies the off-chain committee, where miners verify the buyer’s Schnorr signature and balance proof. The result is determined via a consensus algorithm and the result is notified to a trust authority.

4.3.3. Authorization and Data Storage

This part contains authorizing the trading and storage of the encrypted data by trusted entities in the PBTMS. They are as follows:

• Authorization proposal: After validating the legitimacy of the buyer’s and seller’s proofs, the off-chain committee batch initiates proposals. Multiple users can be processed in one transaction.
• Authorization execution: Once the proposal is approved and execution conditions are met, the off-chain committee grant the buyer permission to upload data to the contract.
• Encrypted data upload: The buyer uploads the encrypted data fragments to IPFS and stores the corresponding hash data (ICD) in the transaction information contract on the blockchain.

4.3.4. Data Decryption and Trading Information Retrieval

During trading between the buyer and the seller, sensitive information should be encrypted. Correspondingly, data decryption and trading information retrieval include the following:

• AES key decryption: The seller uses the private key to decrypt the AES key.
• Data fragment retrieval and reconstruction:

  –

  Upon successful verification, the seller retrieves the encrypted data fragments corresponding to the ICD from the IPFS network.

  –

  The retrieved encrypted fragments are reassembled, and decryption is performed using the AES key to reconstruct the complete trading dataset, including transaction details and exchanged assets.

4.3.5. Commodity Delivery and Status Update

After the commodity delivery is finished, the system should update the status of all the participants. They are as follows:

• Seller shipment: The seller ships the commodity according to the trading details and updates the status to “success”.
• Buyer confirmation of receipt: The buyer receives the commodity and updates the status to “success”.
• Commitment generation and upload: The buyer and seller use the trading details, trading creation time, and AES key to generate their respective Pedersen commitments and upload them to the contract.

4.3.6. Dispute Resolution

In the event of a dispute between the buyer and the seller, the third party involved in the dispute (e.g., bank, logistics company, etc.) and the parties to the trade are asked to provide the Pedersen commitment for verification purposes. The outcome of the dispute is decided based on the three commitments.

4.3.7. User Balance Update

Once the transaction status is marked as successful, both the buyer and the seller need to update their user balances. The balance is protected using ECC homomorphic encryption, and the update operation is performed within the encrypted domain without the need for decryption. The buyer’s balance decreases while the seller’s balance increases. The updated encrypted balance is stored in the blockchain ledger, thereby ensuring transaction security and user privacy.

4.4. Security Risk from Internal and External Adversaries

In PBTMS, there are several common types of privacy and security risks from the user’s perspective, mainly including the following:

• Data leakage: The data may be personal or transaction information. That is, personal information leakage refers to attackers stealing the user’s registration information (e.g., name, address, and contact details) or transaction records (e.g., buyer and seller identities, amounts, goods, etc.). Once the user’s information is leaked, they may face risks such as identity theft or fraud. Transaction information leakage means that the user’s transaction credentials (e.g., transaction password and payment information) may be stolen. Attackers can use this to access the user’s trading account, potentially stealing funds or accessing personal transaction data.
• Service interruption: There are two possible cases that cause service interruption. On the one hand, attackers may consume system resources or block communication channels so as to affect platform operation and cause transaction delays or failures, which disrupt the user’s normal trading experience. On the other hand, attackers targeting critical system components may cause some transactions or validation processes to fail, affecting transaction integrity and preventing the user’s transactions from being processed or validated in a timely manner.
• Loss of trust: Improper actions by the user (e.g., fraudulent transactions or data manipulation) may raise doubts about their credibility among other users, significantly decreasing the user’s reputation and affecting their future transaction opportunities.
• Payment and delivery risks: One possible risk is a mismatch between payment and delivery. After payment, the user may not receive the expected goods or services, resulting in financial loss. This may be caused by altered transaction data, forged transaction records, or similar reasons. Another risk may be unmet expected returns. The user may not receive the expected reward for goods or services as agreed, leading to a mismatch between actual returns and expected returns, causing financial losses.

In the PBTMS, we consider two classes of potential adversaries, i.e., internal and external adversaries. As shown in

Table 5. Potential adversaries in PBTMS.

Category	Adversary	Threats	Users Affected
Internal	Malicious Buyer	Forge receipt proofs Leak seller’s sensitive information Impersonate other buyers	Decrease user credibility Leak data Payment and delivery risks
	Malicious Seller	Provide false shipping proofs Leak buyer’s sensitive information	User credibility decreases, Data leakage Payment and delivery risks
	Malicious Miner	Block permission allocations Forge validation results Disrupt consensus protocols Manipulate verifications	Decreases user credibility Payment and delivery risks
External	Passive Attacks	Analyze data to infer details Conduct traffic analysis	Leak data Payment and delivery risks
	Active Attacks	Intercept and tamper with communication Corrupt proofs or manipulate trade data Impersonate users Launch DoS attacks on critical components	Service interruption Payment and delivery risks

, these adversaries pose various levels and threats to the system’s security.

4.4.1. Internal Adversaries

Internal adversaries are legitimate participants in the PBTMS, but they may maliciously exploit their access and permissions. The possible internal adversaries include the following:

• Malicious buyer: A buyer may forge receipt proofs that cause inconsistencies between delivery and receipt proofs or leak the seller’s sensitive information that results in losses for the seller. A buyer may also impersonate other buyers to gain unauthorized benefits.
• Malicious seller: A seller may provide false shipping proofs that enable fake deliveries or leak the buyer’s sensitive information that causes harm to the buyer.
• Malicious miners: Miners may block permission allocations, forge validation results, or deliberately disrupt the execution of consensus protocols. They may also provide false delivery or receipt verification results so as to manipulate the determination of an e-commerce trade’s success or failure.

4.4.2. External Adversaries

External adversaries are attackers outside the system whose aim is to compromise its confidentiality, integrity, and availability through passive observation or active intervention. The typical attack modes include the following:

• Passive attacks:
  • Accessing public data: Attackers analyze public blockchain data to infer sensitive transaction information (e.g., identities and amounts), compromising user privacy.
  • Traffic analysis and data correlation: Attackers analyze network traffic to infer transaction patterns, which can lead to more precise attacks by identifying transaction times and volumes.
• Active attacks:
  • Data tampering: Attackers intercept and alter transaction data, potentially compromising correctness and causing financial loss.
  • Impersonating legitimate users: Attackers forge identities to participate in transactions, leading to loss of funds or goods and damaging the system’s credibility.
  • DoS attacks: Attackers target critical system components (e.g., off-chain committees and IPFS storage) to disrupt service, leading to downtime or delayed transactions.

Faced with the threat of internal and external adversaries, the PBTMS should take advantage of various robust security mechanisms to defend them well and guarantee the security of trading and the participants’ sensitive information.

5. Implementation of Privacy Preservation in PBTMS

In order to protect the e-commerce platforms, the PBTMS must achieve trading data privacy, security, and integrity through encryption algorithms, distributed verification, consensus mechanisms, and permission control. Below is the detailed algorithm design with corresponding expressions.

5.1. Hybrid ECC and AES-Based Chunked Data Encryption for Data Security

For trading data, we propose a hybrid ECC and AES-based chunked data encryption approach to ensure its security, which is shown in Algorithm 1. The idea of the algorithm is to divide a large amount of trading data into multiple chunks and then encrypt them in parallel. The objective of Algorithm 1 is to ensure efficient and secure encryption and derive a symmetric AES encryption key. Formally, the encryption of each chunk is computed as

$${\mathrm{EncryptedChunk}}_i={\mathrm{AES}}_{\mathrm{Encrypt}}({\mathrm{Chunk}}_i,\mathrm{DerivedKey},\mathbf{H}),$$

(5)

in which ${\mathrm{Chunk}}_i$ is the i-th chunk of the input data, ${\mathrm{AES}}_{\mathrm{Encrypt}}$ is the AES encryption function with the derived symmetric key, DerivedKey is the symmetric encryption key derived from the shared ECC key using HKDF, and $\mathbf{H}$ is a hash function calculated from the timestamp and the transaction ID. Then, all the encrypted chunks are aggregated as

$$\mathrm{EncryptedData}=\bigcup _{i=0}^N{\mathrm{EncryptedChunk}}_i,$$

(6)

where N is the total number of chunks. It should be noted that the aggregation process is parallelized using a thread pool.

Algorithm 1: ECC-based AES encryption and decryption.

In addition, the ECC key exchange between any pair of participants in the PBTMS is performed as

$$\mathrm{SharedKey}=\mathrm{PrivateKey}.\mathrm{exchange}(\mathrm{ECDH},\mathrm{PeerPublicKey}),$$

(7)

in which PrivateKey represents the ECC private key, and PeerPublicKey is the public key of the peer. Finally, the symmetric key can be derived as

$$\mathrm{DerivedKey}=\mathrm{HKDF}(\mathrm{SHA}256,\mathrm{SharedKey},\mathrm{info},\mathrm{length}=32),$$

(8)

where HKDF ensures that the derived key is cryptographically secure for use in AES encryption, and info consists of the transaction ID and timestamp to ensure the uniqueness of the key.

For the proposed AES-GCM and key management, we have demonstrated that it has some key characteristics for data security based on the following theorems.

Theorem 1 (Confidentiality).

Under the computational Diffie–Hellman (CDH) assumption and the AES-GCM confidentiality assumption, an attacker cannot recover the plaintext data.

Proof. 

The CDH assumption holds that solving the discrete logarithm problem (DLP) in the group is computationally hard, so an attacker cannot recover the shared key. HMAC-based key derivation function (HKDF) is secure and satisfies indistinguishability, meaning the attacker cannot gain any information about the shared key from the derived key. Since AES-GCM mode is IND-CPA secure in the random oracle model, even if an attacker obtains multiple ciphertext blocks, they cannot recover the plaintext data.    □

Theorem 2 (Replay Attack Resistance).

If the data block includes a timestamp, the attacker cannot replay the same encrypted data.

Proof. 

In the AES-GCM encryption process, the nonce must be unique. Otherwise, it breaks the encryption’s security. Since the nonce is derived from the hash of the timestamp and sequence number, it will always be unique, preventing an attacker from replaying old valid transactions within the system.    □

Theorem 3 (CCA Resistance).

Assuming AES-GCM is IND-CCA2-secure, the attacker cannot forge a valid ciphertext.

Proof. 

In AES-GCM mode, each ciphertext includes an integrity check value (authentication tag). If the ciphertext is modified, the decryption will fail the verification, and the receiving party will reject the message. Therefore, an attacker cannot forge a ciphertext that passes verification.    □

Theorem 4 (Key Leak Prevention).

Under the key management mechanism combining ECDH, HKDF, and AES-GCM, even if some information is leaked, the attacker cannot recover the complete key.

Proof. 

Each ECDH exchange generates a new session key, and ECDH only exposes the public key. The CDH assumption ensures that an attacker cannot derive the shared secret from the public keys. HKDF provides irreversibility, ensuring that the shared key and the final symmetric key are not directly recoverable from each other. The keys generated by ECDH are uniformly distributed, and HKDF further obscures the key, so even partial leakage does not allow the attacker to recover the full key.    □

5.2. ECC-Based Signature for Data Integrity Verification

Data integrity verification consists of two operations: signature computation and integrity verification. At first, the signature with respect to some data is computed as

$$\mathrm{Signature}={\mathrm{ECC}}_{\mathrm{Private}}\left(\mathrm{Hash}\left(D\right)\right),$$

(9)

where Signature is the ECC signature for data D, $\mathrm{Hash}\left(D\right)$ is the hash value of the data D, and ${\mathrm{ECC}}_{\mathrm{Private}}$ is the ECC private key used for signing. After receiving the signature, the receiver can verify the integrity of data by the following equation:

$$\mathrm{Hash}\left(D\right)\stackrel{?}{=}{\mathrm{ECC}}_{\mathrm{Public}}\left(\mathrm{Signature}\right),$$

(10)

in which ${\mathrm{ECC}}_{\mathrm{Public}}$ is the ECC public key used for verification.

5.3. Trading Verification and Consensus

Trading verification and consensus in PBTMS include three important components: identity authentication, balance proof verification for funds guarantee, and delivery and receipt proof. Algorithm 2 shows the complete process of proof generation and verification for trading verification and consensus. In the following, we will introduce every component in detail.    

Algorithm 2: Proof generation and verification using Schnorr and Bulletproof.

5.3.1. Schnorr Signature Verification

The transaction summary is generated using the transaction ID and the sender’s public key along with the following timestamp:

$$m=H(\mathrm{Transaction}\mathrm{ID}\Vert \mathrm{Timestamp}\Vert \mathrm{Sender}’\mathrm{s}\mathrm{public}\mathrm{key}).$$

(11)

Using the Schnorr signature scheme to verify the identity of the buyer and the seller, the expressions are as follows:

$$R=g^{k}modp,$$

(12)

$$s=k+x·H(m,R,y)modq,$$

(13)

$$\sigma =(R,s),$$

(14)

where p and q are parameters for the signature, R is the random value, k is the random number generated by the secure random number generator (CSPRNG) to prevent leakage, x is the private key, m is the transaction summary, and H is the hash function.

The corresponding signature verification method is as follows:

$$g^s=R·y^{H(m,R)}modp,$$

(15)

where y is the public key.

For the Schnorr signature, we have demonstrated that it has several key security characteristics based on the following theorems.

Theorem 5 (Replay Attack Prevention).

Suppose the hash function H is modeled as a random oracle (ROM). If the attacker tries to replay an old transaction, it will be rejected by the system.

Proof. 

Assume the attacker intercepts a valid transaction $(m,R,s)$ and attempts to replay it. Since the transaction’s m is unique for every transaction, under the ROM assumption, the output $H(m,R,y)$ is unpredictable, and thus the attacker cannot replay and perform a new transaction. If the attacker tries to reuse m, it becomes invalid. Hence, the attacker cannot replay an old transaction, which prevents a valid proof.    □

Theorem 6 (Collision Resistance).

If the attacker can observe two signatures using the same random number k, the attacker can compute the secret x.

Proof. 

Suppose there are two different messages $m_1$, $m_2$ but the random number k is the same.

$$s_1=k+c_1·xmodq,$$

(16)

$$s_2=k+c_2·xmodq,$$

(17)

$$s_1-s_2=(c_1-c_2)·xmodq.$$

(18)

Since the random number k is chosen correctly, the attacker cannot deduce x.    □

Theorem 7 (Anti-CCA).

In the case of the discrete logarithm assumption (DLP) and ROM model, the attacker cannot forge a valid Schnorr signature.

Proof. 

Assume the attacker can select a ciphertext and obtain its signature. Since the signature is dependent on $H(m,R,y)$, the attacker cannot generate a valid signature through a forged ciphertext.    □

Theorem 8 (Public Key Substitution Attack Prevention).

If the attacker substitutes a public key y with a different one, the attacker cannot forge a valid signature.

Proof. 

Since H is collision-resistant, $H(m,R,y)\ne H(m,R,y^{\prime })$. Therefore, the attacker cannot forge a valid signature using a different public key.    □

5.3.2. Balance Proof Verification

The transaction has a unique identifier computed as follows:

$${\mathrm{ID}}_{\mathrm{tx}}=H(\mathrm{Transaction}\mathrm{ID}\Vert \mathrm{Timestamp}),$$

(19)

where the Transaction ID is the unique identifier of the transaction, such as the order number or a hash value from a blockchain transaction, and the Timestamp is the time of the transaction, which helps prevent replay attacks.

The objective of balance proof verification is to check whether or not the buyer’s balance is sufficient for trading. It consists of two operations, i.e., balance proof computation and verification. At first, the balance proof is derived by

$${\mathrm{Proof}}_{\mathrm{Balance}}=\mathrm{Bulletproof}(\mathrm{Amount},\mathrm{Balance}),$$

(20)

where ${\mathrm{Proof}}_{\mathrm{Balance}}$ is the zero-knowledge proof generated by Bulletproof, Amount is the trading amount, and Balance is the buyer’s current balance. Then, it verifies the balance proof by the following equation:

$$\mathrm{Verify}\left({\mathrm{Proof}}_{\mathrm{Balance}}\right)\stackrel{?}{=}\mathrm{True},$$

(21)

where Verify is the verification algorithm of Bulletproof.

For the balance proof, we have demonstrated that it satisfies some unique security characteristics based on the following theorems.

Theorem 9 (Replay Attack Prevention).

The attacker intercepts the transaction and attempts to replay it but fails.

Proof. 

Each transaction proof includes a unique identifier formed by the transaction ID and the timestamp, ensuring that the proof for any transaction is unique.    □

Theorem 10 (Forgery Prevention).

Under the random oracle model (ROM) and the discrete logarithm assumption (DLP), the attacker cannot forge a valid proof.

Proof. 

The core idea of Bulletproofs is based on the Pedersen commitment, and since Pedersen commitments are homomorphic, the attacker cannot choose a valid message to forge a valid commitment to either the balance or the amount in the transaction.    □

Theorem 11 (Information Leakage Attack).

Under the random oracle model (ROM) and the Pedersen commitment’s hiding property, the attacker cannot infer any sensitive information from multiple proofs in the same transaction.

Proof. 

The Bulletproof proof either returns True/False, and does not reveal any values inside the commitment or the commitment’s randomness. Pedersen commitments maintain non-interactivity, meaning that the same proof value can be reused without leakage.    □

Theorem 12 (Prevention of Proof Modification).

Under the constraints of the Pedersen commitment’s binding property and the Bulletproof proof system’s integrity, the attacker cannot modify the proof.

Proof. 

The Bulletproof system uses a hash value $H(m,R,y)$ to bind the commitment to the transaction’s amount. The commitment is binding and cannot be modified without invalidating the proof. Once the commitment is generated, it cannot be changed without causing the proof to fail.    □

5.3.3. Delivery and Receipt Proof

The objective of delivery and receipt proof is to verify consistency between delivery and receipt proofs. In particular, it uses the Pedersen commitment to implement the above objective, which can be divided into three operations. The first operation is that the buyer generates a random number r by encrypting the order timestamp with the AES key:

$$r={\mathrm{AES}}_K\left(\mathrm{Timestamp}\right).$$

(22)

The second operation is that both the buyer and seller generate Pedersen commitments based on the following equation:

$$C=g^{x_{\mathrm{Order}}}·h^r,$$

(23)

where $x_{\mathrm{Order}}$ is the order information, r is the random number, and $g,h$ are public parameters. The last operation is to verify the commitment, which is expressed as

$$C_{\mathrm{Delivery}}\stackrel{?}{=}{C}_{\mathrm{Receipt}}.$$

(24)

For delivery and receipt proof, we have demonstrated that it satisfies the following security characteristics.

Theorem 13 (Replay Attack Prevention).

The attacker cannot replay an old transaction to create a fraud.

Proof. 

Due to the randomness of the time-stamp value r generated by AES, which ensures that each instance is different, the attacker fails if they try to replay an old transaction with the same timestamp.    □

Theorem 14 (Forgery Prevention).

Under the assumption of the binding property of the Pedersen commitment, the attacker cannot modify the transaction information.

Proof. 

Due to the difficulty of the discrete logarithm problem (DLP), the attacker cannot determine a new $x_{\mathrm{order}}^{\prime }$ that satisfies $C^{\prime }=C$.    □

Theorem 15 (Information Leakage Attack Prevention).

Under the hiding property of the Pedersen commitment, the attacker cannot infer the transaction information.

Proof. 

$$log\left(C\right)=x_{\mathrm{order}}+log{h}^r,$$

(25)

which ensures that if r is chosen randomly, the $x_{\mathrm{order}}$ is non-trivial and cannot be deduced. If the two different transactions have distinct commitments, under the DLP assumption, the attacker cannot decide if the two transactions are the same.    □

5.4. Permission Management

Permission management is composed of two important tasks, i.e., permission allocation and authorization. For permission allocation, the main objective is to control access to sensitive data, which is expressed as

$$\mathrm{Permission}(U,A)=\left\{\begin{array}{cc}1\hfill & \mathrm{if}\mathrm{Verified}\left(U\right)\hfill \\ 0\hfill & \mathrm{otherwise}\hfill \end{array}\right.,$$

(26)

where U is some user, and A is the user’s action (e.g., upload and download).

In addition, the objective of permission authorization is to achieve consensus among distributed miners for authorization and verification tasks. The final result is determined based on the agreement of more than two-thirds of the participating miners. To this end, we propose a consensus mechanism for distributed authorization and verification, which is composed of four key steps. The first step is for the miner to compute its local verification result for individual miner verification. The result is derived as

$$V_i=\left\{\begin{array}{cc}1\hfill & \mathrm{if}\mathrm{verification}\mathrm{is}\mathrm{successful}\hfill \\ 0\hfill & \mathrm{if}\mathrm{verification}\mathrm{fails}\hfill \end{array}\right.,$$

(27)

where $V_i$ is the result of miner i. The second step is that the miners broadcast the result. Correspondingly, the set of received results is represented as follows:

$$\mathcal{V}=\{V_1,V_2,\dots ,V_n\},$$

(28)

where n is the total number of miners participating in the consensus. The third step is majority voting that determines the final consensus result. The voting result is expressed as

$${\mathrm{Result}}_{\mathrm{final}}=\left\{\begin{array}{cc}1\hfill & \mathrm{if}\sum _{i=1}^n{V}_i\ast W_i>2n/3\hfill \\ 0\hfill & \mathrm{otherwise}\hfill \end{array}\right.,$$

(29)

where $2n/3$ is the threshold for consensus. Finally, the final decision is made. That is, if ${\mathrm{Result}}_{\mathrm{final}}$ is 1, the authorization or verification task is considered successful, and the trust authority proceeds with the next step (e.g., granting permissions or updating the blockchain). Otherwise, the task fails, and corrective actions are triggered. The above process of permission management is shown in Algorithm 3.

5.5. Dispute Resolution

Dispute resolution between trading parties by verifying Pedersen commitments is provided by the buyer, seller, and relevant third parties (e.g., bank and logistics) for dispute-related data, such as tracking numbers or trading IDs. The concrete process is divided into two parts. The first part is a cross-party data comparison that compares the verified data from all parties by the following equation:

$$C_{\mathrm{Buyer}}\stackrel{?}{=}{C}_{\mathrm{Seller}}\stackrel{?}{=}{C}_{\mathrm{ThirdParty}}.$$

(30)

If the data values match, the dispute is resolved in favor of consistency. Otherwise, further investigation is required. The second part is the final judgment based on the results of commitment verification and data comparison. If inconsistencies are found, the PBTMS should identify the responsible party. For example, if $C_{\mathrm{Buyer}}$ matches $C_{\mathrm{ThirdParty}}$ but differs from $C_{\mathrm{Seller}}$, the seller may be at fault. More importantly, the PBTMS should resolve the dispute by either rejecting or validating the trading and recording the decision on the blockchain.    

Algorithm 3: Proof generation and verification for shipping and trading.

5.6. Smart Contract for Access Control and Data Storage

In the PBTMS, we use smart contracts to implement two contracts, i.e., an access control contract for permission management and a data storage contract for storage management. As shown in Figure 4 and Figure 5, the smart contract is mainly used to manage the upload and download permissions and to perform data upload and download.

5.6.1. Access Control Contract

The objective of an access control contract is for the access control component to dynamically manage permissions for different users during the trading process. The contract includes two main operations, i.e., grant and revocation. The grant permission refers to when a user U is granted permission R, i.e., $P_R\leftarrow P_R\cup \left\{U\right\}$, and any pending requests from U for permission R are re-evaluated. On the other hand, the revocation permission means that when a user U has their permission R revoked, i.e., $P_R\leftarrow P_R\setminus \left\{U\right\}$, any ongoing tradings requiring permission R for U are immediately terminated. Based on the contract, access control uses dynamic permission sets to manage access, which are defined as

$$\begin{array}{cc}\hfill P_{\mathrm{upload}}& =\{U_i\mid U_i\mathrm{is}\mathrm{authorized}\mathrm{to}\mathrm{upload}\mathrm{data}\};\hfill \end{array}$$

(31)

$$\begin{array}{cc}\hfill P_{\mathrm{download}}& =\{U_j\mid U_j\mathrm{is}\mathrm{authorized}\mathrm{to}\mathrm{download}\mathrm{data}\}.\hfill \end{array}$$

(32)

As a result, the corresponding access decisions are based on the following rule:

$$\mathrm{Access}(U,R)=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}U\in P_R\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right..$$

(33)

5.6.2. Data Storage Contract

The data storage contract is composed of two core functions: upload and download, which manage the storage and retrieval of trading data. Both functions ensure that only authorized users can perform the respective operations. The upload function allows authorized users (e.g., buyers) to store trading-related data references on the blockchain. It first checks whether the user is authorized to upload data based on the following rule:

$$\mathrm{Access}(UserID,P_{\mathrm{upload}})=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}UserID\in P_{\mathrm{upload}}\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right..$$

(34)

If a user is authorized, data are stored on the blockchain. The upload operation is performed by

$$\mathrm{Upload}(UserID,Data)\to \mathrm{Status},$$

(35)

where UserID is an identifier of the requesting user, Data is the trading-related data reference (e.g., ICD), $P_{\mathrm{upload}}$ is a set of users authorized to upload data, and Status is confirmation of the data storage and updated trading state.

On the other hand, the download function allows authorized users (e.g., sellers) to retrieve stored data references from the blockchain. It first checks whether the user is authorized to download data based on the following equation:

$$\mathrm{Access}(UserID,P_{\mathrm{download}})=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}UserID\in P_{\mathrm{download}}\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right..$$

(36)

If a user is authorized, he/she retrieves the data reference from the blockchain based on the following rule:

$$\mathrm{Download}(UserID,OrderID)\to \mathrm{Data},$$

(37)

where $P_{\mathrm{download}}$ is a set of users authorized to download data, and Data is the requested data reference (e.g., ICD).

5.6.3. Security Theorems for Smart Contracts

Theorem 16 (Re-entrancy Attack Prevention).

The attacker cannot gain unauthorized funds or permissions through a re-entrancy attack.

Proof. 

The contract uses the ReentrancyGuard library and nonReentrant modifier to prevent re-entrancy attacks. Through these mechanisms, the contract ensures that each operation involving fund transfers or permission modifications can only be executed once. Even if an external call is initiated during the contract’s execution, the contract’s state cannot be maliciously modified by reentry, thereby avoiding the loss of funds or abuse of permissions due to re-entrancy attacks.    □

Theorem 17 (Front-running Attack Prevention).

The attacker cannot interfere with or tamper with a proposal before the transaction is executed by using a front-running strategy.

Proof. 

To prevent front-running attacks, the contract implements a time-lock mechanism and a review process. The time-lock ensures that all approved proposals cannot be executed immediately, preventing malicious nodes from observing the proposal and submitting competing transactions. Additionally, the review mechanism provides a second-layer confirmation for all proposals. Even if a malicious node attempts to interfere, the second-layer committee’s review can effectively block the occurrence of front-running.    □

Theorem 18 (Integer Overflow and Underflow Prevention).

Mathematical operations within the contract do not cause integer overflow or underflow.

Proof. 

All mathematical calculations in the contract use the SafeMath library, which prevents integer overflow or underflow issues. Even when handling large amounts of funds or transactions, SafeMath automatically checks for overflow or underflow, as well as subtraction, multiplication, and division operations. If any issues are detected, an exception (revert) is triggered, ensuring that the contract’s execution will not result in the loss of funds due to overflow errors.    □

5.6.4. Smart Contract Auditing and Verification

The auditing and verification process of the smart contract includes the following key steps:

• Static code auditing: The contract’s source code is analyzed by using tools like Slither and MythX to automatically scan the code for potential vulnerabilities.
• Functional verification: Testing frameworks (such as Truffle) are used for unit testing and integration testing, thereby ensuring that the contract’s functionality meets the expected behavior.
• Security testing: Common attacks, such as re-entrancy attacks, front-running attacks, integer overflow, etc., are simulated to check the security of the contract and ensure that it can withstand these types of attacks.
• Monitoring and updates: After the contract is deployed, continuous monitoring is performed to check for any new security vulnerabilities or abnormal behavior. An automatic alert system will notify developers or administrators of any issues. If potential vulnerabilities or issues are discovered, the system will propose fixes or prompt for an urgent update to the contract.

In particular, we use OpenZeppelin Defender for real-time monitoring. That is, OpenZeppelin Defender provides real-time monitoring of contract operations, detecting potential malicious activities, reentrancy attacks, or other misuse of the contract. Through real-time transaction monitoring, contract event listening, and automatic alerts, issues can be detected and addressed promptly. Defender’s automation features also ensure that critical operations in the contract are executed as scheduled and can automatically update the contract or pause operations with security risks.

5.7. PBTMS: Put Them in Together

Based on the above operations (e.g., data encryption and signature, trading verification and consensus, permission management, and dispute resolution), the flow chart of PBTMS is shown in Figure 6. It should be noted that the yellow section is for encrypted trading information and amounts, the pink section is for proof of identity and balance, the blue is for proof of receipt and upload, and the purple is for dispute view and amount redemption. The PBTMS achieves robust data privacy, distributed verification, and permission control, ensuring secure, reliable, and private trading.

6. Security and Performance Analysis of PBTMS

In this section, we analyze the security and performance of PBTMS in terms of multiple metrics, such as security and privacy, authentication and accountability, fairness, availability, throughput, response time, gas consumption, proof size, and scalability.

6.1. Security Analysis of PBTMS

The PBTMS addresses security issues in e-commerce trading, as shown in

Table 6. Potential attack on the PBTMS and the corresponding defense.

Metric	Potential Attack	Defense Mechanism
Security and Privacy	Passive/Active Attacks, Data Leakage, Forgery	AES Key Encryption, Obfuscated Addresses, ECC Signature, Blockchain Storage
Authentication	Identity Forgery, MITM Attacks	Schnorr Signatures, Distributed Validation
Fairness	False Delivery/Receipt, Miner Bias	Commitment Verification, Consensus Mechanisms
System Availability	DoS Attacks, Miner Disruption	IPFS Storage, Robust Consensus, Collaborative Management

, including security and privacy, authentication and accountability, fairness, and reliability. The focus of these security issues is listed as follows:

• Security and privacy: It refers to protecting sensitive trading data from unauthorized access and ensuring it cannot be tampered with during transmission or storage.
• Authentication and accountability: It refers to verifying the legitimacy of trading participants to prevent them from denying their actions in the trading process.
• Fairness: It refers to ensuring that all participants are treated equally to avoid losses due to fraud or unfairness.
• Reliability: It refers to maintaining system functionality even under adversarial conditions.

This section analyzes potential attack scenarios based on the defined internal and external adversary models and discusses the system’s defense mechanisms and security guarantees.

6.1.1. Security and Privacy

The potential security and privacy attacks on the PBTMS are listed as follows:

• External passive attack: Adversaries monitor blockchain or network traffic to extract sensitive trading information, such as trading amounts, order details, or user identities.
• Internal data leakage: Malicious miners exploit privileges to access fragmented data, leaking sensitive trading details.
• External active attack: Adversaries intercept and alter trading data or results during transmission.
• Internal forgery: Malicious participants or miners forge delivery or receipt proofs, disrupting the trading process.

Faced with these attacks, the PBTMS can adopt the following security measures:

• Shared AES key, slice, and encryption of data: Data are fragmented and encrypted using a shared AES key, preventing reconstruction from intercepted fragments.
• Obfuscated address: The system obfuscates addresses of contract to protect amount. As a result, it ensures that any tampering with data invalidates the signature.
• On-chain storage: Blockchain’s distributed consensus and tamper-proof structure prevent unauthorized modifications and ensure data consistency.

6.1.2. Authentication and Accountability

The potential authentication and accountability attacks on the PBTMS are listed as follows:

• Identity forgery: Adversaries impersonate legitimate users to gain unauthorized benefits.
• Man-in-the-middle (MITM) attacks: Adversaries intercept and modify identity verification data.

Correspondingly, the defense mechanisms of the PBTMS include the following:

• Schnorr signature: The system authenticates trading participants so that only legitimate users can sign and engage in trading.
• Distributed validation by miners: Independent miners validate signatures to reduce the risks of tampering or forgery.

6.1.3. Fairness

The potential fairness attacks on the PBTMS include the following:

• False delivery: Malicious sellers forge delivery proofs to claim payments without delivering commodity.
• False receipt: Malicious buyers forge receipt proofs to avoid payment or request refunds.
• Miner bias: Malicious miner nodes manipulate validation results, causing unfair trading outcomes.

In order to ensure the fairness of the PBTMS, the proper defense mechanisms are listed as follows:

• Commitment-based proof verification: Buyers and sellers generate Pedersen commitments for order data. Miners verify these commitments for authenticity.
• Distributed consensus: Miners use consensus mechanisms to prevent manipulation and ensure fairness.

6.1.4. System Availability

The potential attacks on the PBTMS’s availability may be as follows:

• Denial-of-service (DoS) attacks: External adversaries launch DoS attacks on validation miners or IPFS, attempting to disrupt trading verification or data storage services.
• Malicious miner disruption: Malicious miners refuse to allocate permissions or participate in consensus, attempting to interrupt the trading process.

In order to guarantee the availability of the PBTMS, the corresponding protection mechanisms include the following:

• Distributed storage in IPFS: Data and proofs are fragmented and stored, with the result of avoiding single points of failure.
• Robust consensus mechanism: The system can ensure the functionality even if up to $1/3$ of miners are malicious or fail.
• Collaborative node management: Miners work together to manage permissions and validations, avoiding interruptions.

As shown in

Table 7. Comparison of safety properties.

References	Security & Privacy	Fairness	Authentication & Accountability	Availability
[51]	✗	✓	✓	✓
[52]	✗	✓	✓	✓
[53]	✓	✓	✗	✓
[54]	✓	✗	✓	✓
PBTMS	✓	✓	✓	✓

Note: ✓ indicates that the property is satisfied, while ✗ means it is not satisfied. The references correspond to the following works: ref. [51]—Escrow Protocols for Cryptocurrencies: How to Buy Physical Goods Using Bitcoin, ref. [52]—A survey on privacy protection of blockchain: The technology and application, ref. [53]—SPENDER: A platform for secure and privacy-preserving decentralized P2P e-commerce, ref. [54]—Design and implementation of Web3-Based e-commerce cryptocurrency payment system.

, some studies [51,52] employed an escrow protocol based on a Bitcoin script that uses threshold signatures combined with zero-knowledge proofs, as well as multi-signatures and verifiable cryptographic signatures, to ensure that tradings are fair. However, none address measures to protect the anonymity of the identities of the parties to the trading and the confidentiality of the trading amount. In contrast, Zheng et al. [53] implemented a trustless trading process using smart contracts, encrypted addresses, and a bidding mechanism. However, verifying the user’s balance needs to be recognized, and it is impossible to determine whether the user has enough balance to purchase the commodity. Lee et al. [54] paid attention to verifying identity and balance based on privacy protection but did not consider the consistency of receiving and shipping information, which cannot guarantee the trading’s fairness. Our design is more comprehensive in security, enhancing trading safety, privacy, and fairness while addressing the shortcomings of existing schemes.

6.1.5. Defense Analysis of Sybil Attacks

A Sybil attack refers to an attack where the attacker creates a large number of fake nodes to influence the consensus results, thus manipulating transaction validation or permission management [55,56]. For off-chain committees, a Sybil attack may result in vote manipulation, threshold signature manipulation, and even the breakdown of the permission management system [57].

Here, we consider four common Sybil attack approaches and present the corresponding defense measures. At first, Sybil nodes manipulate voting, which means that the attacker creates a large number of new nodes (initial reputation 100) and uses their voting power to influence the consensus, forcing the system to accept invalid transactions or incorrect identity verification. Faced with the attack, there are three proper measures, including that (i) newly joined nodes have an initial reputation of 50 (instead of 100) to prevent sudden influence on consensus, (ii) reputation must be improved through long-term correct behavior, and (iii) voting rights based on the reputation score adopt exponential decay, with low-reputation nodes having a lower voting weight.

Then, the attacker temporarily boosts reputation to manipulate consensus. The attacker controls a batch of Sybil accounts, performs legitimate consensus tasks in the short term to boost their reputation, and then forges transactions or submits incorrect signatures to influence consensus decisions. The corresponding defense measures can be severe penalties for incorrect behavior and Removal of inactive nodes in the long term to prevent attackers from temporarily boosting their reputation and then stagnating to await the opportunity for attack.

Next, the attacker attempts to manipulate multi-party proposals. The attacker uses Sybil accounts to gain proposal rights, forge signatures, or block legitimate transactions. There are two possible defense measures. The first one is that high-reputation nodes are prioritized to enter the proposal group. Only nodes with a reputation score (RS) $\ge 80$ are allowed to join the proposal group. Nodes with RS $<50$ are immediately removed from the proposal group. Another one is that the proposal weight is related to the reputation score.

Lastly, the attacker creates fake identities at a low cost. In the off-chain committee, attackers may try to create fake identities to increase their influence by maliciously controlling multiple committee nodes, tampering with the reputation system to gain higher voting rights, or colluding to manipulate consensus. Faced with the attack, each committee node must be bound to a Web3 DID (decentralized identity) or pass a KYC (know your customer) certification to ensure the uniqueness of each identity. The DID is linked to the reputation score. New nodes must undergo sufficient consensus cycles to accumulate a high reputation, preventing attackers from gaining control over the committee in a short period. Reputation scores are public and automatically adjusted based on historical behavior, preventing artificial manipulation that could lead to reputation abuse.

6.2. Performance Analysis of PBTMS

As shown in

Table 8. Performance metrics with custom star ratings.

Metric	Effect	Methods
High Throughput (TPS)	★★★✩✩	off-chain permission verification, off-chain storage
Low Response Time	★★★★★	Schnorr and Pedersen, ECC-AES slice encryption and storage, parallel task
Optimized Gas Consumption	★★★★★	off-chain calculations, IPFS index storage
Lightweight Proof Size	★★★★★	Bulletproofs, Pedersen commitments
High Scalability	★★★★✩	task separation, distributed storage, multi-node collaboration

* Note: The star ratings indicate the effectiveness of each metric. More black stars represent a higher rating and better performance.

, the performance of the PBTMS has the advantages of high throughput, low response time, optimized gas consumption, lightweight proof size, and high scalability. It provides an efficient and cost-effective solution for e-commerce trading scenarios through technologies such as distributed storage and authentication, low-complexity consensus mechanisms, and zero-knowledge proofs. It should be noted that the number of black stars indicates the performance score in Table 8. TPS and scalability, though representing the best achievable performance under the current experimental setup, score lower due to consensus mechanism limitations and performance declines with increasing nodes. The other three indicators perform well and receive high scores.

In order to ensure the high throughput of the PBTMS, it adopts two measures, including that (i) PBTMS reduces the complexity of contract authorization by verifying permissions off-chain, and (ii) storing non-critical data to IPFS reduces stress on on-chain data storage. The response time of e-commerce trading in the PBTMS is rather low for three reasons. They are that (i) the system uses ECC to generate AES-shared keys for encryption and slices storage to speed up data encryption and upload, (ii) the efficient Schnorr signature and Pedersen commitment generation algorithms significantly reduce computation time, and (iii) authentication and authorization miners perform tasks in parallel to reduce latency. The PBTMS has optimized gas consumption since it uses the specific smart contract. Particularly, smart contract operations are streamlined by moving complex calculations (e.g., commitment validation) off-chain, reducing redundant on-chain calculation steps. Furthermore, smart contracts store only IPFS indexes to reduce uploaded data size. PBTMS uses bulletproofs and Pedersen commitment as proof mechanisms so that the proof size is significantly smaller than that of traditional schemes. The PBTMS also has high scalability because of two operations. The first one is that separating on-chain and off-chain tasks allows the system to maintain low latency even after node expansion. The second one is that distributed storage and multi-node collaboration ensure high availability of data access and avoid a single point of failure.

7. Performance Evaluation

In this section, we perform extensive experiments to evaluate our designed system in terms of multiple evaluation metrics.

7.1. Experimental Setup

7.1.1. Experimental Environment

The performance testing of the PBTMS was conducted on an Intel Xeon 16-core CPU, 32 GB RAM, 1 TB SSD, running Ubuntu 20.04 LTS, using Ganache (7.9.2) and Truffle (5.11.5) as the blockchain platform, which is shown in

Table 9. Experimental environment configuration.

Category	Configuration Details
Hardware
CPU	Intel Xeon 16-core
RAM	32 GB
Storage	1 TB SSD
Software
Operating System (OS)	Ubuntu 20.04 LTS
Ganache	version 7.9.2
Truffle	version 5.11.5
web3	version 1.10.0
IPFS	version 0.6.0
Programming language
Python	version 3.10
Rust	version 1.83.0
Solidity	version 0.4.26

.

7.1.2. Parameter Setup

The experiments were conducted under well-defined parameters and categorized into blockchain settings and cryptographic components. Blockchain parameters included PoW consensus, a 10-node network, and a gas limit of 20,000,000, while cryptographic techniques utilized included Schnorr signatures, ECC-AES encryption, Bulletproof range proofs, and Pedersen commitments for privacy and efficiency. The detail is shown in

Table 10. Blockchain parameters.

Parameter	Details
Blockchain Parameters
Consensus Mechanism	PoW (Proof of Work)
Network Scale	Initial nodes: 10
Gas Limit	30,000,000
Cryptographic Components
Schnorr Digital Signature	Signature size: 64 bytes
ECC-AES Encryption	ECC curve: secp256k1;
AES key length: 128 bits
Bulletproof Range Proof	Input range: 0–100,000
Pedersen Commitment	Commitment size: 32 bytes

.

7.1.3. Comparison with Existing Schemes

We selected [42,58] as a comparison scheme. Ref. [58] targets similar e-commerce scenarios but uses a less efficient authentication method. Our system adopts a concise proof mechanism and streamlines delivery and receipt verification, significantly improving performance (see Section 7.2.3). Similarly, while [42] employs comparable encryption and proof processes, our use of an efficient signature mechanism and an on-chain/off-chain model reduces response time, as detailed in Section 7.2.1. These enhancements demonstrate the advantages of our framework in terms of performance and efficiency.

7.1.4. Evaluation Metrics

Performance testing focuses on the following key metrics:

• Response time: This refers to the time from trading initiation to completion, including the delay of each phase.
• Throughput (TPS): This refers to the number of tradings processed by the system per second.
• Proof size: This refers to the size of proofs such as Bulletproofs and the Pedersen commitment, which affects storage and transmission efficiency.
• Gas consumption: This represents the amount of gas consumed during smart contract execution, which is used to evaluate trading costs.

7.1.5. Scenarios

The following test scenarios were designed to fully evaluate the performance of the PBTMS:

• Encryption and proof efficiency: This simulates the generation of transaction information, the transaction amount, encryption of transactions, and proof generation process. It also evaluates the impact of message size and proof size on the complexity of transaction time. The expected results include the following:

  –

  As the data size increases, the encryption time grows linearly, with a relatively slow growth rate.

  –

  As the number of parallel transactions increases, the change in encryption time becomes smoother, indicating that the system has good scalability for parallel processing.

  –

  In each transaction processing stage, compared to existing solutions, the PBTMS system demonstrates significant optimization in time consumption, especially in encryption and proof generation efficiency.

• Throughput: This simulates the processing capability of concurrent uploads, downloads, and authorized transactions under different node quantities. The expected results include the following:

  –

  As the number of nodes increases, the system’s throughput (TPS) is expected to show a gradual upward trend and will peak when a certain number of nodes is reached. At the same time, the download TPS will significantly exceed upload TPS and authorization TPS, indicating significant optimization in data processing efficiency, especially in data transmission and processing.

• Gas consumption: This measures the gas consumption of each entity at different transaction stages. The expected results include the following;

  –

  During the transaction, the gas consumption of each entity, compared to existing solutions, shows significant optimization in the PBTMS system. This optimization indicates effective improvements in resource utilization efficiency, reducing transaction costs and enhancing overall system performance.

• Proof size: This evaluates the impact of different proof sizes on the range proof. The expected results include the following:

  –

  In range proofs, as the proof range expands, the growth rate of proof size exhibits a slow linear increase, indicating that the proof scheme can effectively support large-scale transactions while maintaining high efficiency in scalability and performance.

  –

  The data size generated during the transaction, especially encrypted data and proof data, shows a significant reduction compared to existing solutions. This optimization demonstrates that the system has higher efficiency in data processing and storage, effectively reducing resource consumption and improving overall performance.

• Stress test: This simulates the system’s capacity to handle high loads and evaluate its performance under high-concurrency transactions, increased data volumes, and changes in the number of nodes. The evaluation primarily focuses on simulating high-concurrency transactions, increasing data volumes, and adding nodes to assess the system’s big data processing ability and scalability. The expected results include the following:

  –

  As concurrent transactions increase, the system throughput (TPS) is expected to rise gradually and eventually level off at a peak value after reaching a certain number of transactions.

  –

  As the system load increases, the response time for transactions may experience some delay, but the overall trend should remain within a reasonable range, indicating that the system can handle high loads.

  –

  Gas consumption is expected to increase as the load rises, but it should remain within a controllable range to avoid resource bottlenecks.

7.2. Experimental Results and Analysis

7.2.1. Encryption and Proof Efficiency

Our hybrid encryption scheme uses ECC to generate a shared key and AES to encrypt data, combining ECC’s security with AES’s efficiency. As shown in Figure 7, it performs similarly to AES for small data but is significantly faster for large data due to ECC’s one-time key generation amortizing overheads. In contrast, AES’s complex logic increases overhead in multi-threaded environments. This approach ensures high security and better performance for large data volumes.

In integrity verification, we use ECC cryptographic hashes for signature verification, and as can be seen from Figure 8, it shows a significant time advantage compared to the RSA scheme. Due to its lightweight characteristics, ECC cryptography has lower computational complexity in signing and verifying. It especially scales better in highly parallel scenarios, with a much lower time increase than RSA. Therefore, the ECC scheme is more suitable for multipoint consensus and high-concurrency scenarios, such as blockchain transaction verification or IoT authentication.

The scheme proposed by [59] spends 593.84ms in the trading processing part, compared to the total trading processing time of 506.9ms for our proposed scheme, significantly improving time performance. Moreover, according to Figure 9, compared with [42], the scheme proposed by PBTMS shows higher efficiency in all phases, especially in the decryption and signature phases, where the optimization is most significant. Overall, PBTMS is more suitable for application scenarios with high-performance requirements.

7.2.2. Throughput (TPS)

The test is conducted for three task scenarios: download, upload, and authorization, with the number of nodes set to 10, 20, 40, 60, 80, and 100, respectively.

As shown in Figure 10, TPS peaks at around 20 nodes, with download TPS reaching 750 and upload and authorization TPS at 50% and 45% of that, respectively. This efficiency stems from effective multithreading (eight cores per node), controlled consensus overhead, and balanced computational loads. However, as nodes increase, quadratic growth in consensus time and rising network latency reduce TPS, exposing limitations in the consensus mechanism. While performance is strong with a medium number of nodes, optimizing the consensus algorithm and network efficiency remains a key area for future research.

7.2.3. Gas Consumption

Table 11. The execution costs and duration for all entities in the on-chain phase.

Entities	Transactions	GasUsed	Costs
Miners	8	211,640	Certificate Upload Authorization * 2 + Trading Information Upload Authorization + Trading Information Download Authorization + Proof of Receipt and Delivery Authorization * 2 + Trading Amount Upload Authorization + Trading Amount Download Authorization
Seller	2	160,940	Upload proof of identity + Upload proof of delivery
Buyer	4	321,880	Upload proof of identity and balance + Upload Trading Information + Upload Trading amount + Upload Proof of Receipt
Total 14 694,460

shows the test results of PBTMS’s gas consumption. Combined with the data in Figure 11, it can be seen that compared with [58], PBTMS shows higher efficiency in all entity operations, and total resource consumption, especially the Gas consumption of miners, is significantly reduced, which fully reflects its optimization capability. The aggregate data further illustrates the superior overall resource utilization of PBTMS.

7.2.4. File Size Impact on Performance

In our design, most cryptographic operations produce fixed-size outputs for efficiency and predictability due to having stable sizes derived from hashes and private keys. The only variable-sized proof is the Bulletproof balance proof, which grows logarithmically with range size, as shown in Figure 12. Unlike Sigma and CT proofs, which grow linearly and result in significantly larger sizes, Bulletproof maintains compactness, ensuring low resource consumption and minimal overhead. This makes it ideal for scenarios with large ranges or extensive participant data, where scalability and efficiency are critical.

As shown in Figure 13, the results highlight that PBTMS significantly reduces data sizes compared to [42]’s approach, demonstrating its efficiency in blockchain transactions. PBTMS reduces encrypted data size by 52.5% (6336 to 3008 bytes) and proof data size by 70% (4672 to 1403 bytes), showcasing the effectiveness of its ECC-AES encryption and compact proof mechanisms. While the data size slightly increases (16 to 18 bytes), this minor trade-off ensures enhanced functionality.

7.2.5. Stress Test

The stress test results show that the system exhibits strong high-load capability and scalability. As the number of concurrent transactions increases, response time gradually rises but stays within a reasonable range. As shown in the Figure 14, when reaching 1000 concurrent transactions, the response time is 977.3 ms, indicating the system can handle high-concurrency transactions with stable performance. The increase in response time is mainly due to resource contention and consensus delays, but the system mitigates this through multi-node parallel processing, optimized consensus mechanisms, and efficient resource allocation.

Similarly, as shown in Figure 15, gas consumption increases from 694,460 to nearly 833,352 with higher concurrency. This rise reflects the added demand for CPU and bandwidth, particularly during storage and consensus processes. However, the system effectively controls gas growth through multi-container deployment and resource optimization, keeping it within a reasonable range and confirming good scalability. Figure 16 demonstrates that TPS increases as concurrency rises, peaking and stabilizing around 300 concurrent transactions. Even near the system’s load limits, TPS remains high, thanks to optimized parallel processing, resource distribution, and consensus mechanisms, ensuring the system maintains stable performance under high load.

8. Conclusions

In this paper, we proposed the PBTMS system, a blockchain-based e-commerce transaction platform designed to address key challenges such as node trustworthiness, privilege abuse, and the balance between privacy protection and performance. By leveraging decentralized data storage and management, PBTMS effectively prevents third-party access to sensitive user and transaction information, ensuring both transaction validity and privacy. Through its innovative integration of multiple cryptographic techniques and decentralized architectures, the system achieves a robust solution for secure, privacy-preserving transactions.

The major highlight of PBTMS lies in its multi-agent collaborative framework, which incorporates a range of key participants, including buyers, sellers, trusted authorities, miners, blockchain, and IPFS. This framework enables efficient integration of decentralized storage, permission management, and transaction validation, reducing security risks and enhancing the overall system efficiency. In contrast to existing solutions, PBTMS minimizes the reliance on centralized authorities, offering a more secure and transparent model for e-commerce transactions.

However, despite the notable improvements in privacy protection and transaction validation, PBTMS still faces certain limitations. Specifically, the consensus mechanism can face throughput bottlenecks in high-concurrency scenarios, particularly as the number of nodes increases. Furthermore, while the system performs well in simulated environments, further real-world validation and optimization are necessary, particularly for large-scale e-commerce platforms.

The PBTMS system holds significant potential for application across various sectors. It can be effectively deployed in cross-border payment systems to ensure secure, decentralized, and privacy-preserving transactions. Additionally, it offers a strong privacy protection mechanism for decentralized finance (DeFi) applications, enhancing security and preventing sensitive data leaks. In e-commerce platforms, PBTMS can provide robust privacy protections while ensuring transaction authenticity and compliance, thereby fostering greater user trust. Moreover, the system’s features are highly applicable to supply chain management, where it can maintain privacy while ensuring data integrity and transparency throughout the supply chain.

Overall, PBTMS represents a significant advancement in addressing the challenges of privacy, security, and performance in e-commerce transactions, with considerable potential for future improvements and broader applications in various domains.