A privacy-preserving scheme with multi-level regulation compliance for blockchain

With the increasing presence of blockchain-based distributed applications in various aspects of daily life, there has been a growing focus on the privacy protection of blockchain ledgers and the corresponding regulatory technologies. However, current mainstream solutions primarily concentrate on the verifiable encryption of blockchain transaction addresses and contents, neglecting the regulatory requirements for private transactions. Moreover, the few monitorable solutions suffer from issues such as excessive centralization and a single-minded approach to regulatory content. To address these deficiencies, this paper proposes a blockchain privacy-preserving scheme that supports multi-level regulation through the utilization of zero-knowledge proofs (zk-SNARKs) and attribute-based encryption (ABE). Firstly, by leveraging zk-SNARKs, this scheme achieves blockchain privacy-preserving within an account model, enabling the concealment of user transaction addresses and values. Secondly, by employing attribute-based encryption, a multi-level regulatory model is developed alongside the privacy protection measures, allowing for selective disclosure of transaction content. Finally, we analyze the security of the proposed scheme and compare it with other schemes, discussing its advantages in terms of privacy, security, and regulatory capabilities, we also provide a preliminary evaluation of the scheme's efficiency through experiments. In conclusion, the scheme demonstrates strong privacy by relying on mathematical proofs through zk-SNARKs to ensure security while comprehensively safeguarding content. It also achieves multi-level regulation on the foundation of privacy protection, with comprehensive regulatory coverage and decentralized regulatory authority.

1.The use of the zk-SNARKs algorithm enables a privacy protection scheme based on an account model.This ensures the confidentiality of both account balance and transaction value, while also severing the mapping relationship between transaction parties.As a result, anonymous transactions can be achieved.2. Building upon this privacy scheme, a multi-level regulatory structure is designed.It incorporates various roles with distinct identity attributes such as monitors, primary regulators, senior regulators, transaction parties, and miners.Each level of regulator is responsible for tracking different transaction information and has the option for real-name authentication.By distributing regulatory tasks among different entities, the harm of information leakage from a single node is mitigated, and regulatory efficiency is enhanced.3. ABE encryption is utilized to assign keys with specific attributes to each level of regulator.Users attach transaction privacy information encrypted with ABE public keys of corresponding attributes to the transaction.This approach enables selective disclosure of transaction information and reduces the centralization prevalent in current regulatory measures.
By implementing this blockchain privacy protection scheme, we can address the aforementioned challenges while striking a balance between privacy and regulatory requirements.
The rest of this paper is organized as follows.In "Related work", we present the related work.Then, preliminaries are provided in "Preliminaries", the privacy model and Multi-level Regulatory Model are formulated in "Our scheme".In "The protocol description", the detailed construction of our protocol are described.Security analysis is given in "Security analysis" and performance evaluation is presented in "Performance analysis".Finally, we conclude the paper in "Conclusions".

Related work
In recent years, numerous research findings have been published on privacy protection in blockchain.In 2014, Bonneau et al. introduced the Mixcoin protocol [ 1 ], which ensured transaction address privacy and incorporated an audit mechanism to govern third parties.Subsequently, Maxwell proposed the Coinjoin protocol 2 that achieved decentralized coin mixing without relying on trusted third parties, but it required participating users to negotiate and execute the mixing process themselves.To comprehensively safeguard transaction privacy, SASSON et al. proposed the ZeroCash scheme 3 , which employed zero-knowledge proof technology to protect the addresses and transaction values of both transaction initiators and receivers.However, this scheme relied on trusted third parties for parameter initialization and suffered from low efficiency.Monero 4 utilized ring signature technology 5 to protect data privacy and employed stealth addresses 6,7 to hide the associativity problem between input and output addresses.Nonetheless, ring signatures had security vulnerabilities and necessitated multiple off-chain interactions to complete transactions 8,9 .The MimbleWimble protocol 10 , proposed by Tom Elvis Jedusor, combined mixing, encryption commitment, range proof 11 , and Dandelion 12 technologies to ensure the privacy of blockchain transactions.However, it required multiple user interactions to complete private transactions, and its security was subject to debate.Subsequently, projects offering privacy protection for smart contracts on public chains began gaining prominence in various scenarios.The Hawk protocol 13 , proposed by Kosba et al., implemented smart contract privacy protection based on zk-SNARKs.The Ekiden protocol 14 , studied by Oasis Labs, implemented privacy computing based on TEE.The Zether protocol 15 , introduced by Bünz et al., protected the input and output values of smart contracts.The BlockMaze 16 established a blockchain privacy protection solution based on zk-SNARKs for an account-based model, which was more compatible with smart contracts than ZeroCash.However, these solutions were generally built on the Ethereum platform and functioned via smart contracts, resulting in significant gas consumption and privacy vulnerabilities.After 2020, the emergence of DeFi drew attention to privacy protection in cross-chain exchanges.Phala 17 , Raze Network 18 , and Manta Network 19 focused on privacy protection in cross-chain DeFi based on the Substrate framework.They utilized zk-SNARKs to achieve end-to-end anonymity, high interoperability between chains, and a secure and user-friendly protocol.Nonetheless, with the increase in cryptocurrency-related illegal activities, governments worldwide have intensified their concerns regarding the regulation of privacy projects.Several privacy protection projects have been compelled to make improvements, including Zerocash and Tornado.The former had to incorporate regulatory keys during the 2019 Sapling update, while the latter faced sanctions and access restrictions in 2022.Consequently, research on regulatable privacy protection schemes currently offers broad application prospects.
Currently, there are multiple schemes available that can provide a certain degree of regulation while safeguarding user privacy.El Defrawy et al. proposed a scheme based on secure multiparty computation 20 .This scheme ensures the traceability of user identity by distributed shares of the secret user identity to multiple servers.It requires reaching a threshold number of servers to recover the user identity.A scheme based on linkable group signatures provides both traceability of user identity and the auditability of transaction content 21 .The linkable property enables other users to determine whether two transactions originate from the same sender, allowing for the identification of abnormal users.This scheme separates registration, auditing, and identity tracking operations among different entities, avoiding centralization.Li et al. introduced a regulatory scheme based on the Zerocash privacy protection scheme 22 .In this scheme, regulatory authorities issue symmetric encryption keys to each regulated user.The users employ these keys to encrypt transaction-related information, while zero-knowledge proofs ensure consistency between encrypted information and transaction information.Regulatory authorities use their private keys to decrypt each ciphertext and obtain the transaction content of the regulated user.Lastly, centralized regulation often depends on third-party central nodes to conduct transaction regulation.For example, centralized mixing can be accomplished by employing mix servers as regulatory nodes.Group signatures can track the real signature user address through group administrators 23 .Alternatively, users may be required to encrypt their corresponding privacy content before submitting it to the chain for review by regulators.The two-layer identity structure 24 proposed by Hongbo Li and Tao Xie achieves decentralized e-commerce real-name supervision based on smart contracts, but does not support privacy protection for transaction information.Wang and Fu proposed RPTM 25 , which implements privacy-preserving task matching in blockchain-based crowdsourcing.RPTM can provide task matching services without compromising the privacy of task requesters and workers by utilizing a novel integer vector encryption scheme.Wang and Gao's proposal 26 employs attributebased encryption to achieve multi-level regulation on Bitcoin.However, the proposal only enables regulation of regular Bitcoin transactions and does not possess privacy protection capabilities.The multi-level regulation in this proposal allows different regulatory entities to oversee distinct user categories, with the ability to access users' true identities, the levels are not based on the content of regulation but rather on the range of user categories.Higher levels encompass a broader range of individuals, resulting in excessive concentration of power among high-level regulators and a lower degree of decentralization.The proposal 27 put forward by Tianyu et al. achieves transaction regulation under privacy protection through the linkability of ring signatures.However, the comprehensiveness of regulatory content is severely lacking as it only reveals the sender's public key.Hyperledger Fabric 28 utilizes Attribute-Based Encryption (ABE) to enforce access control rules in consortium blockchains, yet it lacks privacy protection features and only addresses user identity management in terms of regulation.
The details of comparison are shown in Table 1.
The existing schemes for privacy protection with regulatory capabilities have certain limitations, and their suitability varies depending on the specific application scenario.These schemes commonly encounter the following issues: (1) limited regulatory content: most schemes can only access transaction addresses or statistical information, which fails to meet the comprehensive regulatory needs of most scenarios.(2) Privacy concerns: many schemes rely on technologies like coin mixing or ring signatures for regulation, but these technologies do not effectively safeguard user privacy.(3) Centralization of regulatory authority: the majority of schemes rely on a single third-party node for regulatory functions, leading to concentration of all regulatory information in one place.This increases the risk of information leakage and imposes a heavy workload on the regulatory entity.

Preliminaries Notations
This paper presents a blockchain privacy protection scheme that supports multi-level regulation.It encompasses the definition and utilization of cyclic group, zero-knowledge proof, and various data structures.Some of the parameter symbols are shown in Table 2.

Zero-knowledge proof
Zero-knowledge proof is a cryptographic technique that verifies data confidentiality without disclosing specific information.It proves the truth or falsehood of a proposition while maintaining privacy.The non-interactive zero-knowledge proof technology (zk-SNARKs) 29 has three key characteristics: completeness, soundness, and zero-knowledge.Completeness: if a proposition is true, then an honest prover will with high probability be able to successfully pass the verification.Soundness: if a proposition is false, then a cheating prover with no information will only have a low probability of passing the verification.Zero-knowledge: apart from the truth or falsehood of the proposition, no other information is leaked.Zero-knowledge proof algorithms can be described as polynomial-time algorithms: Z = (Setup, KeyGen, Prove, Verify) 1. Setup 1 → pp Z .Given the security parameter λ, the algorithm performs an initialization operation to generate and output the public parameters Here, p is a prime number; e represents a bilinear map from , and G T are three cyclic groups of order p ; P 1 and P 2 are the generators of G 1 and G 2 , respectively; F p is a finite field.In zk-SNARKs, all other algorithms take pp Z as the default input for public parameters. 2. KeyGen(C) → (pk z , vk z ) .Given a circuit C , this algorithm utilizes the public parameters pp Z to generate a key pair (pk z , vk z ) , where pk z is the proving key used for generating zero-knowledge proofs, and vk z is the verification key used for verifying zero-knowledge proofs. 3. Prove pk z , − → x , − → w → π .This algorithm is used to generate a zero-knowledge proof π .In the input param- eters, − → x represents the input of circuit C , which is a publicly declared state; − → w represents the auxiliary input of circuit C , which is a private evidence; π is the zero-knowledge proof that demonstrates the correspond- ence between − → x and − → w satisfying the construction of circuit C .It should be noted that − → x and π are publicly available and visible to anyone. 4. Verify vk z , − → x , π → b .With the use of this algorithm, anyone can check and verify the validity of zero- knowledge proofs.If the zero-knowledge proof is successfully verified, the algorithm outputs b = 1 ; other- wise, it outputs b = 0 to indicate the failure of verification.
The workflow of zero knowledge proof is shown in Fig. 1.

Attribute-based encryption
Attribute-based encryption (ABE) is a one-to-many access control method for public key encryption 30 .The data owner begins by defining a security policy for their data.Subsequently, a key authority converts this policy into encryption keys.Only users who satisfy the conditions specified by the policy can decrypt the data successfully.This approach strengthens data security and privacy.The algorithmic details are as follows: 1. Setup 1 → (PK, MK) .Given the security parameter λ as input, the algorithm outputs the initial keys (PK, MK) for the system. 2. KeyGen(MK, A u i ) → SK u i .The key authority runs this algorithm to generate a private decryption key SK u i , corresponding to the attributes A u i possessed by the user.The private keys are generated by a random algorithm executed by the key authority, creating a private key for each attribute tree in the attribute domain.This algorithm takes the message m to be encrypted, the access policy T defined by a set of attributes, and the public key PK as inputs. 4. Decrypt ABE (SK u i , CT, PK) → m .A user who possesses the attributes satisfying the access policy uses this algorithm with the corresponding key SK u i to decrypt the ciphertext CT and recover the message m.

Our scheme
We will describe the principles and operational steps of this approach to achieving privacy protection and multilevel regulation in this section.Section "Data structure", provides a detailed description of the data structures involved in this approach, including their mathematical symbols and key roles.Section "Privacy model" presents the workflow of the privacy protection model, highlighting the application of zk-SNARK in the approach and explaining the functions and important parameters of the main algorithms.Lastly, in "Multi-level regulatory model", we specifically focus on how multi-level regulation operates in conjunction with the privacy protection model, examining the application of attribute-based encryption (ABE) in regulation, as well as outlining the specific responsibilities and tasks of regulators at different levels.

Data structure
The commitment of balance is defined as cmt = COMM(addr, value, sn, r) , which is stored in the account as the user's balance.After each transaction, the user updates the commitment and submits it for verification by miners.The commitment of transfer is defined as It is related to the trans- fer information in the Send transaction and its compliance is ensured through zero-knowledge proofs.
The serial number is defined as sn = CRF(sk, r) .The serial number sn accompanies each balance commitment and transfer commitment.It is generated by the random number r and the user's private key sk , ensuring that sn must be generated by the initiator of the corresponding transaction.
Zero-knowledge balance zk_balance = {cmt, addr, value, sn, r} .zk_balance is a set of parameters related to the user's account balance.
Commitment set CMTSet .It stores the set of cmt v from Send transactions within each block.
Serial number set SNSet .It is responsible for storing all transfer commitments sn A .Whenever a miner veri- fies the validity of a transaction, they need to check if sn A has appeared in SNSet .This method can help resist double-spending attacks.

Privacy model
Inspired by BlockMaze 16 , this solution utilizes zk-SNARKs to achieve unlinkability of transaction addresses and transaction content privacy in the account model.It employs commitments to protect account balances, transfer values, and the correspondence between senders and receivers.The solution incorporates a two-step transfer mechanism: senders first send funds to the blockchain, and then receivers deposit the funds from the blockchain.This mechanism safeguards the correlation between senders and receivers.To protect balance information on the public ledger, only the commitment cmt of the corresponding value is recorded through zk_balance .During transfers, the receiver's address is not included in the transaction.Instead, the receiver receives a hash value h of the transaction, concealing the sender's address.The receiver can use h to retrieve the corresponding transac- tion on the chain.When depositing funds, the receiver places the commitment cmt v of the transfer value on a leaf node of a Merkle Patricia Trie (MPT) tree.The root rt of the tree is utilized in the zero-knowledge proof to hide the commitment of the transfer value and the sender's address.Both the sending and receiving processes ensure security and privacy through zero-knowledge proofs using zk-SNARKs.Blockchain validators validate transfer operations by verifying the zero-knowledge proofs, without gaining access to the transfer value or the relationship between senders and receivers.The workflow of privacy model is shown in Fig. 2.
The algorithm descriptions involved in the entire privacy transaction are as follows: 1. Setup(1 ) → pp : Given a security parameter λ, this algorithm generates a public system parameter list pp , which is publicly accessible to anyone.It is important to note that the Setup algorithm can only be executed by a trusted third party and should be executed once. 2. CreateAccount pp, ID → {addr, (pk, sk)} : Given the public parameter list pp , this algorithm creates an account address for the user and generates a key pair (pk, sk) .The private key sk is used to access private data and decrypt ciphertext data in transactions, while the public key pk is used to encrypt shared transac- tion parameters.The account address is used for sending and receiving transfer funds.At the same time, the public key pk is generated and issued to the user by a key management organization, and it is bound to the user's real identity information ID. 3. Send zk_balance A , sk A , pk B , v → {zk_balance * A , tx S } : This algorithm allows sender A to send zero-knowl- edge value to receiver B. Given the current zero-knowledge balance zk_balance A of account A, the sender's account private key sk A , the receiver's account public key pk B , and the plaintext value v to be transferred as zero-knowledge value, account A can use this algorithm to update its zero-knowledge balance zk_balance *

Multi-level regulatory model
We propose a multi-level regulatory model based on existing privacy models.The model operates as follows: observers monitor the ledger for abnormal fluctuations in transaction frequency, allowing them to detect suspicious transactions or accounts.They report these findings to higher-level regulators.Third-level regulators are responsible for the disclosure of specific transaction information.Attribute-based encryption (ABE) and zeroknowledge Succinct Non-interactive Arguments of Knowledge (zk-SNARKs) are utilized to support the entire process.The regulatory model of this scheme possesses the following characteristics: 1. ABE is used to selectively disclose privacy information in transactions, allowing different levels of regulators to access specific information.This decentralizes regulatory work to some extent.Moreover, the one-to-many nature of ABE enables each regulator to possess a unique key, reducing the management cost of regulatory keys.2. By leveraging the features of send and receive transactions, incentive measures can be implemented to encourage active participation in basic transaction monitoring by ordinary users or miners.This reduces the workload of dedicated regulators and facilitates the detection of abnormal transaction behavior.3. Relevant government departments serve as trusted third parties, fulfilling roles such as user identity verification (Know Your Customer, KYC), attribute key management for different levels of roles, and acting as the highest authority for transaction regulation.This ensures compliance with mandatory regulatory requirements imposed by various countries on blockchain privacy projects.4. Zero-knowledge proofs are utilized throughout the process to maintain consistency between regulatory information and transaction information.This prevents the use of false information by transacting parties to evade monitoring.
The workflow of multi-level regulation is shown in Fig. 3. Roles in the regulatory scheme can be divided as follows:

User
The main role involved in privacy transactions, including the sender and receiver of the transaction.Their tasks include generating send and receive transactions, broadcasting them to the blockchain, and updating zeroknowledge balances in their accounts.Users also need to encrypt different levels of privacy information using public keys of different attributes and include them in the transaction on the blockchain.Additionally, they generate corresponding zero-knowledge proofs for miners to verify.

Miner
Miners are responsible for verifying, packaging, and broadcasting processes related to privacy transactions.They must validate the legitimacy of the transaction without knowing its value or addresses involved.The specific process is as follows: first, they verify whether cmt v and sn v exist in CMTSet and SNSet , respectively, to prevent double-spending attacks.Then they verify the correctness of the zero-knowledge proof corresponding to the transaction to ensure that the transaction value is within the correct range.Finally, they verify the correctness of

Monitor
The main role of the monitor is to observe fluctuations in user transaction frequency to identify abnormal accounts.This role can be performed by ordinary users or miners.By tracking the frequency of send and receive transactions associated with a specific address, monitors can detect suspicious behavior, such as a significant increase in transaction volume within a specific time period.Monitors should report these findings to higherlevel regulators, and valuable information reported may result in partial rewards.

Primary regulator
The primary regulator's main task is to trace the addresses of both parties involved in the transaction.Employees hired by virtual service providers usually perform this role.They use their attribute public keys to decrypt relevant fields in send transactions, obtaining the recipient's public key.Similarly, they decrypt relevant fields in receive transactions to obtain the sender's public key.This enables the establishment of a mapping relationship between the addresses of the transaction parties, completing the tracking of transaction addresses.

Intermediate regulator
The main task of the intermediate regulator is to query the specific value of privacy transactions.Administrators of virtual service providers usually perform this role.They use their attribute public keys to decrypt relevant fields in send and receive transactions, obtaining the transaction value and completing the tracking of the content of privacy transactions.

Senior regulator
The senior regulator's main tasks include user registration, distribution of regulatory keys, and providing realname regulation for illegal transactions.This role is typically undertaken by relevant administrative departments.They generate key pairs (pk, sk) associated with users' real identities as the public and private keys of the transaction account.Additionally, they issue attribute keys to regulators at all levels to enable real-name tracking of illegal users.
From the functional allocation of the regulatory model, it is evident that regulators at different levels can only access transaction-related information such as addr and value .They cannot access secret parameters like sk, sn v , or r v , which are required to generate spending proofs π s .As a result, all regulators are unable to impersonate traders and spend the balances in their accounts, ensuring the security of the transaction model.

The protocol description
Building upon BlockMaze 16 , we have amended the privacy protocol to enhance its support for multi-level regulation.Within the Setup, sections for ABE algorithm initialization and key distribution have been incorporated.In the Send and Receive algorithms, the generation of regulatory ciphertext for transaction value and address is now based on the regulation permission tree.Additionally, a circuit has been included in the zero-knowledge proof to demonstrate the consistency between the regulatory ciphertext and the transaction value.Finally, the Regulate algorithm delineates the regulatory actions initiated by regulators of different levels for private transactions, demonstrating the distinctions between regulation permissions and contents.The following provides a detailed description of each algorithm.

Setup
Setup Is an algorithm used to generate a system's public parameter list.In order to construct zero-knowledge transactions, it is necessary to design specific circuits, denoted as C , to ensure that the state of the accounts before and after executing the algorithmic operations, as well as the constructed transactions, are all valid and legal.www.nature.com/scientificreports/Key pairs are generated for both proving and verifying these circuits.It is important to note that this algorithm is executed only once by a trusted third party.The detailed is as follows: Setup Input:

ABE initial parameter
Output: , Zero-knowledge parameters Account information 1. ABE Initialization and Key Distribution:

Send
The Send transaction is used by the sender to transfer funds and generate transaction tx S .After generating the tx S transaction, account A informs account B offline of the transaction hash value h tx S = CRF(tx S ) for retrieval and parsing of tx S , enabling subsequent Receive operations to construct tx D for deposit.Once tx S is agreed upon by miners and recorded on the blockchain, the state of account A undergoes the following changes: prior to executing the Send algorithm, the state of account A is pt_balance, cmt ; after executing the Send algorithm, the state of account A is {pt_balance, cmt * } .The detail is as follows: The π s is the core content of the Send transaction, which can prove the following: 1. value A >= vThe value v in the Send transaction must be less than or equal to the balance value A of account A to prevent users from spending more than the available balance. 2. sn A = CRF(sk A , r A ), sn * A = CRF sk A , r * A , sn v = CRF(sk A , r v ) The serial numbers sn used in the Send transac- tion are correctly generated and bound to the private key sk A of account A, ensuring they cannot be forged. .The balance commitments cmt used in the Send transaction are correctly generated and bound to the account's address addr .Additionally, the binding relationship between sn A and r A ensures that they cannot be forged. 4. auth enc = CRF(sk A , h enc ) .The signature auth enc is a signature about h enc , proving that the ciphertext aux A , CT 1 , and CT 2 have not been modified.

Receive
The Receive transaction is used by the recipient to receive funds.The recipient receives the off-chain h tx = CRF(tx send ) sent by the sender and retrieves the corresponding transaction on the blockchain.During this process, there is no direct interaction between the recipient and the sender.When receiving funds, it is not advisable to directly disclose cmt v as part of the statement , as it would link back to the sending transaction tx send .Therefore, cmt v is used as a leaf node to construct a Merkle Tree, with its root rt as part of the statement .The relationship between rt and cmt v is then proved.The detail is as follows: The π r is the core content of the Receive transaction, which can prove the following: 1. sn B = CRF(sk B , r B ), sn * B = CRF sk B , r * B .The serial numbers sn involved in the Receive transaction are cor- rectly generated and bound to the private key sk B of account B, making them unable to be forged. 2. cmt B = COMM(addr B , value B , sn B , r B ), cmt * B = COMM addr B , value B + v, sn * B , r * B , cmt v = COMM(addr A , pk B , v, sn v , r v , sn A ) .The balance commitments cmt involved in the Receive transac- tion are correctly generated and bound to the account's address addr .Moreover, sn B is bound to r B , preventing them from being forged. 3. rt = path(cmt v ) .rt is the Merkle root of the Merkle tree CMTSet concerning the transfer commitment cmt v .
It can prove that cmt v has indeed appeared in CMTSet and is related to the current rt generation.

Verify
The algorithm checks and verifies all zero-knowledge transactions.Once these transactions are packaged into candidate blocks, miners will examine each transaction to confirm whether the relevant account information (e.g., serial numbers of balance commitments and fund transfer commitments) has been previously disclosed and if the Merkle roots in the transaction are valid.If all the aforementioned checks pass, miners will proceed with the following operations: (1) update the zero-knowledge balance commitments of the relevant accounts in the transaction, i.e., update cmt A to cmt * A ; (2) append the disclosed serial numbers (such as sn A , sn B , sn v ) in the transaction to SNSet to prevent double-spending attacks; (3) append the fund transfer commitment (such as cmt v ) to CMSet in the block, awaiting the recipient to make a deposit.The detailed process is as follows: Vol:.( 1234567890 The verification includes the following aspects: (1) verify if the corresponding sequence number sn is in the spent list for each transaction.(2) For receive transactions, verify if cmt v and its corresponding path can gener- ate the root rt .(3) Verify the zero-knowledge proof corresponding to each transaction.(4) Miners also need to update the zero-knowledge balance and sequence number list, and add cmt v to the block.

Regulate
The algorithm includes methods for different levels of regulators to monitor transaction information.Monitors can observe the transaction frequency of accounts from the public ledger.If an abnormal frequency is identified within a certain time period, the corresponding account address can be provided to higher-level regulators.The primary regulator can decrypt CT 1 using attribute keys to obtain the addresses of the transacting parties, while the intermediate regulator can decrypt CT 2 using attribute keys to obtain the transaction value v .Finally, after comprehensive analysis, if it is found that an account is involved in illegal transaction activities, the address can be submitted to the senior regulator to complete the real-name tracking of the account user.The detailed process is as follows:

Security analysis
According to the security model defined by ZeroCash, this scheme satisfies ledger indistinguishability, transaction unlinkability, transaction non-malleability, and balance conservation.The specific analysis is as follows: www.nature.com/scientificreports/ 2. The senior regulators hold significant power within the regulatory roles, as they have control over the generation and distribution of ABE keys.They also possess the capability to hold accountable users suspected of illegal transactions or regulators engaging in non-compliant operations.It is essential to distribute or oversee the power of these superior regulators.One potential approach could involve establishing a decentralized key distribution organization composed of multiple government agencies that distribute authority among different entities.3. The design of the multi-level regulatory structure is still relatively basic.Currently, non-compliant actions by regulators can only be addressed through real-name accountability or deducting their security deposits by service providers.There is a lack of corresponding technical means.The attribute design of regulators' ABE keys is not comprehensive enough, and it can be gradually improved in the subsequent application process.4. The efficiency of the zero-knowledge proof algorithm still requires enhancement, particularly concerning the use of the SHA-256 algorithm in commitment functions.The excessive number of multiplication gates inserted into the zero-knowledge circuit results in a high computational cost for generating Merkle Tree path proofs.To address this, future exploration can focus on optimizing the HASH algorithm and Merkle Tree to improve performance in the zero-knowledge proof algorithm.

Conclusions
In recent years, blockchain technology had experienced continuous development, leading to its practical application.However, traditional blockchains still face privacy leakage issues that need to be addressed.While previous methods had focused on enhancing user privacy, there had been limited exploration of regulatory methods for the blockchain.This paper introduces a blockchain ledger privacy protection scheme that supports multi-level regulation using zero-knowledge proofs (zk-SNARKs) and attribute-based encryption (ABE).The scheme ensures user privacy while allowing for transaction public verification.It enables various levels of regulators to trace user transaction privacy, ensuring comprehensive regulatory coverage.We also discuss practical issues such as regulatability, security, and privacy in detail.Our analysis demonstrates that our scheme provides sufficient security, stronger anonymity compared to similar schemes, and avoids concentration of regulatory power.Experimental results indicate that our scheme performs well in terms of verification efficiency, which is crucial for traceability research in blockchain.However, future research challenges involve reducing transaction length and verification time in regulated blockchain studies.

A
and generate transaction tx S .4. (4)Receive zk_balance B , pk B , sk B , h tx S → {zk_balance * B , tx D } : This algorithm allows receiver B to check and store the received value in their account.Given the current ledger, public parameters, account key pair ( pk B , sk B ), the hash value h tx S of transaction tx S , and the current zero-knowledge balance zk_balance B of account B, receiver B calls the Receive algorithm to receive and deposit the payment, obtaining a new zero- knowledge balance zk_balance * B and generating transaction tx D . 5. Verify(tx) → b : Given the current ledger and transaction tx , the miners use this algorithm to check the validity of all zero-knowledge transactions.If the tx is valid, the algorithm outputs b = 1 ; otherwise, it out- puts b = 0 .Miners (or nodes maintaining the blockchain) are responsible for verifying all transactions and updating the state of the relevant accounts.

Table 1 .
Comparison of current regulatable privacy protection schemes.

Table 5 .
Performance comparison of privacy algorithms.