Blockchain-Based Access and Timeliness Control for Administrative Punishment Market Supervision

Administrative punishment is one of the most important ways of enforcing administrative law in the field of market supervision in China. However, at the current stage, the abuse of data access permission and the difficulty in managing timeliness in administrative punishment still remain unresolved, which hinders the legalization and standardization of the administrative punishment system. Inspired by blockchain, which is inherently traceable, tamper-proof, and transparent, we design a system, punishment supervisor (PEATS), which is suitable for administrative punishment and technically overcomes the defects of the traditional administrative punishment procedure. To prevent the abuse of data access permission, we innovatively introduce the authorization control gateway (ACG) to verify the access permission of users based on the records in the market supervision department (MSD) contract. To ensure the timeliness of the administrative punishment procedure, we design a special case contract that has the same status as the general case processing state of administrative punishment to track case progress on the blockchain. We experiment and evaluate PEATS in terms of functionality and performance and find that PEATS provides traceability, transparency, and timeliness assurance. In addition, PEATS has 80.9% of the throughput of a traditional server with no more than an additional 3% latency and at most 60 kB additional storage space per case.


I. INTRODUCTION
I N CHINA, administrative punishment is one of the most important ways of enforcing administrative law in the field of market supervision [1], [2], [3]. To protect the legitimate rights and interests of citizens and improve the standardization of administrative punishment procedures, the State Administration of Market Supervision and Administration amended "The Provisions on the Administrative Punishment Procedures of Market Supervision and Administration." In the administrative punishment procedure, we propose two core challenges. The first is how to manage the data Manuscript  access permission of different functional personnel. In the current actual process, the obligation of confidentiality in the handling of administrative punishment cases depends solely on the self-discipline of administrative staff. The staff handling administrative punishment cases do not have differentiated data access. This situation expands the knowledge of state secrets, business secrets, and personal secrets involving staff, causing leakage that is intentional or the result of negligence. In the context of administrative punishment, data access permission control is required to be controllable, immutable, and timely. The second challenge is how to ensure the timeliness of administrative punishment, that is, how to ensure that market supervision departments (MSDs) carry out their corresponding legal responsibilities within the statutory time limit. Although the provisions set a time limit for each link of administrative punishment, time limit management still depends on the self-discipline of administrative staff. Thus, cases are often judged to be "illegal" or are "revoked" by the court due to procedural violations [4]. Existing administrative units have also taken some steps to address this phenomenon. For example, staff members are forced to perform their duties within the statutory time limit through accountability and punishment afterward. However, the effect is not significant because under the existing conditions, these behaviors do not easily leave traces, and accountability and punishment usually lack a factual basis. Procedures are not strictly followed in practice due to the inherent concept of "emphasizing the entity over the procedure" [5], [6]. Therefore, it is necessary to put an end to the manual tampering of time-out records in the administrative punishment procedure so that every link has laws that it follows and evidence for checking.
Emerging technologies have been widely studied because of their unique characteristics. The blockchain technique was proposed by Nakamoto [7]. Bitcoin is the first-generation application of the blockchain technique, which can be regarded as a cryptographically distributed ledger with unforgeable and tamper-proof properties [7]. Ethereum expands the functionality of the Bitcoin blockchain by introducing smart contracts, enabling a more complex application logic and providing programmability [8]. Blockchain has shown great promise in several fields, such as the Internet of Things (IoT) [9], [10], [11], [12], [13], finance, and government [14].
"Blockchain + Rule of law" has value for social governance in three ways: 1) information transparency and symmetry; 2) uncertainty and predictability; and 3) safety and efficiency [15]. It  intelligence, rule of law, and standardization of national governance [16]. For example, Shandong Province has applied the blockchain technique to the notarization field; linked the whole process of intellectual property generation, use and circulation, and right relief; guaranteed the authenticity of data; and achieved data information sharing with public security, courts, and other departments. In addition, the blockchain technique broadens the connotation of "self-discipline" and realizes the integration of "human self-discipline" and "code self-discipline." Inspired by blockchain, which is traceable, tamper-proof, and transparent [17], [18], [19], [20], [21], we introduce the blockchain technique into the administrative punishment process under market supervision and design a system to address the above challenges.
In response to the first challenge, we innovatively design a kind of data access permission control procedure that relies on blockchain-based authorization control gateway (ACG). Compared with general blockchain access control methods [22], [23], [24], [25], the ACG of the punishment supervisor (PEATS) that we propose is designed to be more lightweight and more suitable for access scenarios in administrative punishment procedures. The ACG is responsible for three functions. The first is to verify the access permission of users on the chain. Then, it needs to receive data access requests off the chain. Finally, it controls the actual access process based on the verification. The application of data access is authorized on the blockchain, which ensures that there is a corresponding record for each application and authorization, providing a basis for handling disputes.
In response to the second challenge, we design a complete, smart contract-based time-limiting guarantee system for administrative punishment in the field of market supervision. We deeply integrate the smart contract design into each stage of the administrative penalty procedure and deploy an MSD contract on the blockchain to receive market supervision cases. Cases are sent to the MSD contract to generate a separate case contract. case contract is manipulated by staff of the market supervision department at different levels to promote the case process. In the relevant legal provisions on administrative punishment, it is stipulated that the staff of the market supervision bureau is obliged to advance the process of the case within the statutory time limit.
Based on the general case processing state of administrative punishment, we simulate a case contract to follow the real case state. Sequentially, the basic case status goes through the status INITED (the case is ready to be handled), OPENING (the case is being handled), and CLOSED (the processing of the case has been completed in a normal manner). Only if the operation of each link is within the statutory time limit will the state of the case contract be pushed forward normally and ultimately reach the CLOSED state. If the processing time limit of the relevant link has expired, any subsequent operation will mark the case state EXPIRED, which means that the corresponding staff of the case processing state has violated the law. If the case is terminated for other reasons, the person who terminates the case has the right to mark the case state as ABORTED, which indicates that the case has no required subsequent work.
We conduct functional evaluations and performance experiments on the system through software-based simulation. In terms of functionality, PEATS provides data access permission control and administrative punishment timeliness assurance with traceability, transparency, and timeliness through blockchain. PEATS also defends against unauthorized access to the database by malicious users, whether through identity deception or permission forgery. In terms of performance, the system provides better security by introducing only at most 2.5% additional latency (which is almost negligible) in a wide area network (WAN) environment. In addition, the ACG server has 80.9% of the throughput of a traditional server, which is acceptable considering that it provides better security. Moreover, the timeliness assurance of administrative punishment via blockchain requires additional storage (at most 60 kB per case), which is not a concern since at present storage is relatively cheap.
To the best of our knowledge, our work is the first to use reliable technical means to solve the two major problems of data management and timeliness protection in administrative punishment for China's market regulation from the perspective of safeguarding the contractability of market regulation. The main contributions of this article are as follows.
1) We propose a blockchain-based data access control and administrative punishment timeliness guarantee system. It solves the problems of data abuse and timeliness assurance in the process of traditional market supervision and administrative punishment. 2) We design a system that traces the entire process of administrative law enforcement and deeply integrates the blockchain technique with the administrative punishment management process under traditional market supervision. The blockchain-based ACG is proposed to provide access control and the state of the case is specified and the timeliness of the case is ensured by the state transition graph in the system. 3) We implement our system in a private network, and it performs well in terms of both functionality and performance. Furthermore, the additional overhead introduced for the system to ensure security is within an acceptable range. The remainder of this article is organized as follows. Some background knowledge of administrative punishment for market supervision and blockchain technique is introduced in Section II. The system architecture and specific design are shown in Section III. Then, experiments are conducted in Section IV to evaluate the functionality and performance of the system. Some related work is listed in Section V and finally the conclusion is drawn in Section VI.

A. Administrative Punishment in China for Market Regulation
The administrative punishment procedures for market supervision include "filing review-investigation and evidence collection-legal review-administrative punishment making-administrative punishment performance (enforcement)-case closing and filing" [26].
1) Filing Review: The accepting institution must check the case within 15 working days, and the person in charge (PIC) of the MSD must decide whether to file the case. Under special circumstances, 15 working days can be extended upon approval. The market supervision and administration department with handling authority must inform the realnamed informer of the company's situation within five working days. At this stage, staff members are called case verification personnel (CVP) [26].
2) Investigation and Evidence Collection: If the case has passed the filing review, it will enter the investigation and evidence collection stage. The case handling agency needs to write a case investigation conclusion report and submit it to the legal review agency for review together with the case materials. At this stage, staff members are called investigation and evidence collection personnel (ICVP) [26].
3) Legal Review: After receiving the case materials, the legal review institution must complete the review of the case within ten working days and then provide written comments and suggestions. In this process, if the concerned party requests hearing, the legal review institution must organize a hearing. At this stage, staff members are called legal audit personnel (LAP) [26].

4) Administrative Punishment Making:
In market supervision, administrative punishment must be decided within 90 days from the date of filing. Due to the complexity of the case or other reasons, some decision cannot be made within the prescribed time limit. The time for making the decision may be extended for 30 days with the approval of the PIC of the market supervision and administration department. If the case is particularly complicated or there are other special circumstances that cause the decision to not be made after the extension, the PIC of the market supervision and administration department must collectively discuss and decide whether to prolong the extension. If a decision is made to prolong the extension, a reasonable time limit for the extension must be determined at the same time. At this stage, staff members are called administrative punishment decision maker (APDM) [26].

5) Administrative Punishment Performance (Enforcement):
After the decision on administrative punishment is made, if the concerned party fails to implement the decision on administrative punishment within the statutory time limit, the administrative organ must issue a letter of reminder to the concerned party. If the party still fails to perform within ten days of receiving the reminder, the party must apply to the court for enforcement. At this stage, staff members are called executive personnel (EP) [26].
6) Case Closing and Filing: After completion, it is necessary to go through the formalities of closing and filing. The PIC is responsible for this stage [26]. 7) Person in Charge of Administrative Organs: These personnel are the principal and deputy responsible persons of the administrative organ. They are responsible for participating in the implementation of the legal administrative act [26].
B. Blockchain Technique 1) Blockchain: A blockchain is a chained data structure consisting of a series of cryptographically connected blocks. Each block contains the hash value of the previous block, the corresponding timestamp, transaction information, etc. Such a design makes the content recorded in the block immutable. Typically, blockchain serves as a distributed ledger [27].
2) Ethereum: Ethereum is known as the second-generation blockchain platform; it expands the functionality of the Bitcoin blockchain by introducing smart contracts, enabling a more complex application logic, and providing programmability [28].
3) Smart Contract: Smart contracts are best practiced in Ethereum. A smart contract is a program stored on the blockchain that runs automatically when predetermined conditions are met. Since a smart contract is a program located on the blockchain platform, the execution of the smart contract is transparent and immutable, and it can be executed based on a predefined logic without modifying the execution process. The system design in this article is based on this feature of smart contracts and is implemented in combination with many other cryptographic technologies [29].

4) Consensus Protocol:
The blockchain is maintained by multiple parties. Thus, a consensus protocol is required to ensure that all parties agree on each intermediate and historical state [30].

5) Gateway:
The gateway interconnects networks (different devices) above the network layer and filters the traffic passing through the gateway based on the given rules.

III. SYSTEM ARCHITECTURE
Existing laws and regulations formulate the data access permission limit of staff at all levels and the time limit of each link of the market supervision administrative punishment. However, in the actual implementation of a case, it is impossible to ensure that these provisions are truly met.
Personnel with different functions have seriously abused their access to case information in the process of traditional market supervision. Currently, the prevention of law enforcement data leakage mainly depends on the self-discipline of staff and accountability punishment after discovery. Therefore, relying on the self-discipline of personnel involves great loopholes in legal procedures, and data leakage is difficult to detect. At the same time, because of the cohesiveness of data, the control of access granularity also has corresponding problems. For example, in complaint and whistleblower cases, the personal information of whistleblowers requires fine-grained access. To overcome this challenge, we innovatively propose a data access permission control process that relies on the blockchain ACG. Details on the solution are provided below in Section III-B.
Another major challenge in the process of traditional market supervision is that it is difficult to guarantee timeliness in the process of administrative punishment. Each link of administrative punishment is relatively independent. Before the work of the previous stage is completed, the relevant information is generally not known by the personnel responsible for the subsequent work. The phenomenon of compensating for the lack of legitimacy of the overdue period by employing antisigning still exists. Therefore, it is difficult to ensure that staff members can perform their duties according to the law within the statutory time limit by relying solely on selfdiscipline. Thus, we design a complete, smart contract-based time-limiting guarantee system for market supervision and administrative punishment, and the system is explained in detail below in Section III-C.
To conclude, we provide a system design based on the blockchain technique that effectively overcomes the above drawbacks of administrative punishment under existing market supervision. The whole system is built based on data access control, and data access control is the underlying protocol for administrative punishment timeliness assurance.

A. Overview
We divide our system into four modules ( Fig. 1): 1) a blockchain module; 2) an authentication control module; 3) an off-chain data; and 4) a personnel module. In general, off-chain personnel interact with the blockchain module, complete legal duties in the blockchain module, and leave immutable traces of law enforcement. The ACG links access permissions on the chain with actual data off the chain.
1) Blockchain Module: Contains one MSD contract, a large number of case contracts related to specific case instances, and interactive transactions. Initially, there is only one MSD contract in the system, and the case contracts will be created one by one as the system processes case instances.
The MSD contract is responsible for accepting all requests outside law enforcement, including authorizing data access requests from various types of personnel, creating the case contract corresponding to the case instance, and handling case exceptions.
Case contracts handle the corresponding case instances. They are responsible for saving the corresponding case information summary and supervising the enforcement process. Relevant legal personnel need to carry out the responsibilities stipulated in the case contract within the legal time limit and call the corresponding interface. Doing so enables the case to proceed in accordance with the status of the corresponding legal procedures within the statutory time limit; otherwise, the case contract will truthfully record the violation records.
Interactive transactions result from requests in the blockchain module, generating a transaction hash (named the TXID, which is the unique identifier of the transaction) that can uniquely identify the interaction. It contains the source of the request, where it went, and some requested data fields. The blockchain spontaneously records interactive transactions. These interactive transaction records will be stored on the blockchain as identity verification credentials, which are used in the identity verification module and as evidence of administrative punishment timeliness assurance.
2) Authentication Control Module: Contains an ACG, which is the core of this module. The ACG links the blockchain module with the off-chain data and personnel module. It is deployed in front of the local database. It receives all off-chain requests to access the local database and interacts with the blockchain module to authenticate off-chain requests in the blockchain.
3) Off-Chain Data and Personnel Module: Contain databases and staff at all levels. The database stores the case details and corresponding data access rights.

B. Data Access Permission Control
In data access permission control, PEATS marks access permission to the raw data, and only users who have obtained the corresponding authorization can access these data. Users apply for permission on the blockchain, which leaves immutable traces of data application. Next, the PIC authenticates the identity authority using the ACG. Finally, the data access control is completed 1) Demand Analysis: PEATS uses the blockchain as the basis, making it possible to achieve the immutability of data access. However, we cannot completely rely on the access control characteristics of the blockchain itself to achieve overall access control of market supervision. Due to blockchain transparency and storage capacity limitations, a large number of case details cannot be directly stored on the blockchain and can be stored only in the local database. Based on the flaws in traditional administrative punishment procedures and blockchain technique, our data access control must meet the following requirements.
Demand I: Considering that the blockchain cannot store a large amount of data, and we need to ensure that the data cannot be tampered with, the system needs to combine the blockchain with the off-chain database.
Demand II: Considering the requirement of data access control, the system needs to implement the functions of on-chain application and authorization and off-chain verification.
Demand III: Considering the requirement of access control granularity under the market supervision scenario, the system is demanded to achieve two access control modes: 1) coarse-grained access control and 2) finegrained access control. 2) Demand I: Data materials will be generated during the filing review, investigation and evidence collection, and legal review processes of administrative punishment. The method of storing data materials in the traditional process lacks standardization. Such materials are generally stored in the form of paper or on a U disk, which is easy to lose or easily causes data abuse. In this case, we store the data material itself generated during the administrative punishment process in the off-chain database and store the hash of the data material in the blockchain module. Therefore, we design to store the on-chain data hash in the case contract and design the corresponding structured data storage method off the chain.
As shown in Fig. 2, legal materials in the process of administrative punishment include documents, pictures, and videos. The original files of these materials are stored in the local database. To achieve data access control and control over corresponding items on the chain, these materials are marked with the corresponding case contract address, material name, and upload date.
3) Demand II: We design to complete data access authorization on the chain and to access data off-chain based on authorization on the chain.
On-Chain Application: The MSD contract opens a public interface called to apply for receiving data access applications. The applicant can call this interface, submit the specified parameters to the MSD contract, and generate data access application interactions. These requests will be added to the access request queue in the contract. The access request queue contains all data access applications currently waiting for authorization. MSD has a limit on the number of applications issued by the same applicant, which is to prevent malicious or accidental operations from clogging the blockchain network. We call the transaction ID generated by calling the access request interface the APPLY TXID. The transaction corresponding to the APPLY TXID includes the applicant (blockchain address), access granularity (coarse or fine granularity), access date (start timestamp to end timestamp), access mode (read-only or read-write), and signature (sign the above fields) as shown in Fig. 3.
Additionally, as illustrated in Fig. 3, the PIC judges whether the data access application is reasonable based on the actual needs of the case. The address of the PIC recorded in the MSD contract can call the authorization interface and retrieve the access request queue, allowing the application to make reasonable access requests. The parameters of the  authorization interface include the APPLY TXID and whether to agree. Calling the authorization interface will also generate a TXID (referred to as the Authorize TXID) which will be used in subsequent permission checks.
Off-Chain Data Access: As Fig. 4 shows, off-chain data access is the process by which users actually access data from the local database. The user sends an access application to the ACG through the off-chain network. The fields in the access application include the Authorize TXID, requested data content, timestamp, and digital signature. The content signed by the digital signature includes other fields in the access application. Its function is to ensure that the sender of the off-chain access application is the same as the sender of the on-chain data access application.
The ACG checks the receiving access requests in the following order.
1) The ACG verifies the access request contains a valid signature. 2) Then, the ACG verifies whether application and authorization records on the blockchain are consistent. 3) Finally, the ACG verifies whether the accessed data is outside the given range. 4) Demand III: Coarse-grained access and fine-grained access are controlled by access granularity in Apply transactions sent by applicants. In the process of administrative law enforcement, different data access granularity has different application scenarios.
For example, in cases where illegal clues come from complaints, law enforcement personnel have the obligation to keep the information of the complainants confidential. After the completion of the filing, verification procedures, the beginning of the investigation, and evidence collection procedures, ICVP needs to confirm whether the relevant complaints and reports are true. However, ICVP are not required to master the personal information of the complainants. Therefore, they need fine-grained access at this time.
From the database perspective, a coarse-grained access application in the access granularity field of an application transaction can call a wider range of data. An example of coarse-grained access is shown as "DB.T" or "DB." It specifies that the user can access table T in database DB or the whole database DB.
The fine-grained access application in the access granularity field of an application transaction can call a narrow range of data. An example of coarse-grained access is shown as "SELECT * FROM DB.T" or "SELECT NAME FROM DB.T." It specifies only the SQL queries that the user can execute. The user cannot perform any operations other than those specified in the application. In addition, fine-grained access permissions applications can refer to the design in the existing database, such as authorizing a user to CREATE and DROP permissions, enabling users to create or delete tables, only authorizing a user to SELECT permissions, enabling users to view tables only. These corresponding fine-grained access permissions can be recorded in the Apply transaction, so that users cannot access unauthorized data without permission.

5) Process Design:
We make a complete set of designs for the whole process of the data access application. Specific execution is demonstrated in Fig. 6. Data access permission control will go through the "initiate-apply-authorize -check permission-retrieve data-reply data" stages.
For a detailed description (Fig. 5), we illustrate how it works when filing review staff access complaint reporting data, as shown in Fig. 6.
For example, the filing review staff member needs to learn the case data from today to tomorrow, and due to legal regulations, he or she needs to have fine-grained access control to the database. The staff member sends an application transaction to the MSD contract with the message data as follows: address of the filing review staff member, fine-grained access mode, the period between today to tomorrow, read-only, and his or her signature for the above message. Then, the PIC checks the validation of the application and sends an authorization transaction to the MSD contract. The authorization transaction includes the following: the address of the PIC, the Apply TXID, and "yes." The filing review staff member takes the Authorize TXID, the data scope that he or she needs, today's timestamp, and the signature for the above message to the ACG. The ACG verifies the staff member's true identity and access rights based on established procedures. Then, the ACG obtains the demanded data in the local database and replies to the filing review staff member.

C. Administrative Punishment Timeliness Assurance
PEATS creates a case contract for each case instance, which simulates each status of the administrative punishment process. The status can be advanced only by the corresponding staff by handling cases. The blockchain faithfully records the case handling operations and time of the staff on the case contract to achieve full transparency in the process and to prevent reverse signatures.
1) Demand Analysis: Combined with the blockchain technique, the system designs a set of state transfer process management mechanisms based on smart contracts to ensure the openness and transparency of all aspects of the administrative punishment process. Our design meets the following requirements.
Demand I: Considering that the timeliness guarantee needs to ensure the openness and transparency of the process, the system is demanded to carry out the whole process of case handling on the chain.
Demand II: Considering the need to ensure the timeliness of the entire process of administrative punishment, the system needs to ensure the timeliness of each link and hold it accountable for going overtime.
Demand III: Considering that case handling and case data are separated inside and outside the blockchain, the system needs to ensure the synchronization of the two during the process of the case. 2) Demand I: The legally defined statute of limitations cannot be effectively enforced and there cannot be any accountability due to the opaqueness of the countersignature and process. We put all the process and staff information from the submission of the case to the end of the review on the blockchain for execution.
Link Transparency: From the time the litigator submits the case, all subsequent operations will leave an immutable record on the blockchain. Doing so ensures the openness and transparency of the session.
As shown in Table I, the MSD contract provides litigants with a Submit() interface. A litigant can call this interface to create a new uninitialized case contract. After the litigator submits the relevant information of the case to the local database, the ACG will automatically invoke the initiate interface of the MSD contract to initialize the case contract, and the case can be officially filed. At this point, the PIC needs to call the Assign() interface within the legal time to assign the initialized case contract as a task to staff at all levels. At the same time, the PIC can call other interfaces of the MSD contract to handle exceptions of the case contract, such as Abort() (called when the case is actively abandoned), monitor (the PIC calls this interface to handle timeout behavior), and End() (called when the case ends normally). The case contract provides all the interfaces of the corresponding links of the case. Law enforcement personnel need to legally operate the interface required by their legal duties within the legal time; otherwise, the blockchain will truthfully record the time-out or illegal operation of law enforcement personnel. The operation information of the case contract, including the caller, the interface called, the data sent, and the call date, will be recorded by the blockchain, which leads to link transparency.
Staff Transparency: At the same time, the list of law enforcement officers in the corresponding link will also be saved on the blockchain. As shown in Table II, each case contract maintains its corresponding addresses of law enforcement personnel, which addresses the difficult issue of accountability.
The main function of the case contract is to provide case advancement interfaces to staff at all levels and to store caserelated information. Case-related information includes the hash value of the detailed information of the case, the addresses of staff at all levels handling the case, the case status, and the status modification timestamp. The hash value of the case details is passed in with the parameters of the Submit() function of the MSD contract. The addresses of the staff at all  (Table III). The case status and status modification timestamp are the key data for the statute of limitations for administrative punishment. We will describe in detail in Demand II how the case contract relies on the status of the case to guarantee the statute of limitations.
3) Demand II: PEATS constructs a set of statuses (which will transit in sequence) for the case contract that is compatible with the administrative punishment procedure. Based on Section II, administrative punishment is mainly divided into six states: 1) OPENING; 2) VERIFYING; 3) PROCESSING; 4) EXECUTING; 5) FINISHED; and 6) CLOSED. During the program process, the normal case state transition can be implemented only by the assigned worker calling the interface of the corresponding case contract.
In addition to the normal six states, we define two abnormal states to handle other conditions: 1) EXPIRED and 2) DISCARDED. If a worker at a certain level does not call the corresponding interface within the legal deadline, that is, the latest timestamp minus the state modification timestamp is greater than the legal deadline, then the worker at this stage is identified as having not fulfilled the statutory obligations. The case status is abnormally set to EXPIRED. The purpose of setting the EXPIRED status is to prevent the case contract from stagnating due to the dereliction of duty of a certain level of personnel. If the status of the case contract is set to EXPIRED, the corresponding PIC will be held accountable. In addition, if a case contract has expired, any subsequent call to the contract will cause the case status to be set to EXPIRED. The PIC can call the monitor interface of the MSD contract to obtain the timeout information of the specified case contract.  If the legal deadline needs to be extended under special circumstances, the PIC can call the extended interface of the MSD contract to modify the legal deadline of the case contract. For other special cases that need to cancel the handling of the case, the PIC can call the Abort() interface of the MSD contract and set the case status to DISCARDED. Then, the handling of the case is terminated, and no staff member needs to continue to perform statutory responsibilities. We use Fig. 7 to show the state transition of our design.
All operations will be recorded by the blockchain and stored permanently. Time-out operations cannot be tampered with, and relevant personnel can be held accountable and cannot be denied.

4) Demand III:
When the current link requires the staff to submit relevant data materials, the staff must first submit the hash of the data materials to the case contract on the chain. Then, staff visits the ACG and provides relevant data materials. The ACG compares the hash of the relevant data material with the hash value of the case contract, and if the two are the same, the process is completed successfully. Notably, in addition to the normal administrative punishment procedure, this requirement applies when the litigant submits a case instance for the first time, as shown in Fig. 8. The litigator needs to synchronously submit the litigation materials to the local database (step 1), and the ACG performs a hash operation on the litigation materials (step 2). Then, the ACG calls the MSD contract to initialize the case contract (steps 3 and 4) so that the case can be handled. Finally, the litigation materials are loaded into the local database. 5) Process Design: Next, we demonstrate the process by which the system guarantees the timeliness of the procedure in the general administrative punishment procedure. Before the administrative punishment process begins, the litigator calls the Submit() interface of the MSD contract listed in Table I to create a new case contract, and stores the hash of the case information in the case contract. The litigant then uploads the case details to a local database via the ACG. After the ACG completes the hash check, the MSD contract is called to set the case status of the case contract to INITED, indicating that the case can start the administrative punishment procedure. The PIC calls the Assign() interface of MSD contract and specifies the addresses of staff at all levels who handle the case contract, and the case status of the case contract is set to ASSIGNED. Subsequently, the administrative punishment process officially begins.
The administrative punishment procedures for market supervision include "Filing review-Investigation and evidence collection-Legal review-Administrative punishment making-Administrative punishment performance (enforcement)-Case closing and filing" as shown in Fig. 9. Case contract presets the corresponding interface for each stage. Corresponding staffs at all levels call the interface of the corresponding administrative punishment procedure of the case contract in turn.
CVP has the obligation of filing a review. Within fifteen days from when its status was set to ASSIGNED, the CVP should invoke interface Approve() to fulfill their duty and change the status to OPENING. Then, ICVP should complete the legal investigation and evidence collection, upload evidence raw data to the local database and invoke interface Investigate() to change the status to VERIFYING. Then, LAP has the responsibility to complete the legal review in ten days. Similarly, APDMs, EP, and the PIC execute the corresponding interface of the case contract to fulfill their obligations. If any link in Fig. 9 times out, for example, APDMs invoke interface Punishment() more than ninety days after the status of the case contract changes to OPENING, any operation involving the case contract will change the status to EXPIRED. The workflow of the whole process is shown in Fig. 10.

A. Setup
We implement PEATS on Ethereum. Then, we build a private chain through geth [31], an Ethereum client developed based on the Go language. In addition, we choose proof of authority (POA) [32], which is an algorithm with blockchains  that deliver comparatively fast transactions through a consensus mechanism based on identity as a stake, as the consensus protocol. Subsequently, we create one node as miners to participate in the consensus process, and these three nodes run on three different hosts on the LAN. In addition, there is a host running the database and the ACG simulated by software. The details are shown in Table IV.
Nodejs [33] is used to emulate the ACG and the client that sends requests to the ACG, gRPC is used as the framework of the ACG server, and MySQL is used as the backend database. The specific role and version information of each component used in the experiments are shown in Table V.
Finally, we also need to create four Ethereum accounts. The first three of these accounts serve as the coinbases of miners participating in the POA consensus. A coinbase [34] is the delivery address of the consensus reward. The fourth account simulates a user who will apply for data usage. The first account will also act as the PIC in the MSD contract to authorize applications. The details are listed in Table VI.

B. System Functional Experiment
We evaluate the functionality of the system (Fig. 11), and the results show that the system can provide traceability, transparency, and timeliness. In addition, the system can resist both identity deception and permission forgery attacks. 1) Traceability: When a user denies that he or she requested access to a piece of data or an auditor denies that he or she granted access to a piece of data, the dispute can be resolved based on the records on the blockchain. When a user disputes the administrative punishment process of a case, the dispute can be resolved based on the records on the blockchain.
2) Transparency: All processes of administrative punishment are publicly visible on the blockchain.
3) Timeliness: The timeliness for cases is automatically managed by smart contracts on the blockchain, and if a case is not processed on time, then the corresponding PIC will be held accountable.

4) Tamper Resistance:
No application and authorization records can be tampered with unless the attacker is able to tamper with the blockchain. 5) Identity Deception: An attacker cannot forge an identity as someone else or use someone else's access permission to convince the ACG so that he or she can access the database. 6) Permission Forgery: An attacker cannot forge application and authorization records on the blockchain to spoof the ACG.

C. System Performance Experiment
In Sections IV-C1 and IV-C2, we use the data in the Employees Sample Database [35] as the backend database for the experiment.
1) Latency: We enable differentiated access to data through the innovative introduction of the ACG, as well as blockchainbased access request authorization. The traditional database access mode generally consists of the following steps: 1) a user sends a data request to the server; 2) the server fetches data from the database; and 3) the server sends a data reply to the user. In general, users do not interact directly with the database. The ACG can be considered the server mentioned above, except that it enables blockchain-based access control. Therefore, it needs to spend extra time on identity authentication as well as access permission checking, which will certainly increase the latency of requests. We would like to measure the request latency of the ACG server here to determine whether this latency is within acceptable levels. Alternatively, we would like to measure if it is worth sacrificing response speed to implement blockchain-based access control in exchange for better security.
We define latency T from the moment a user submits a data access application on the blockchain to the moment the user finally obtains the data as follows: where T Apply is the time consumed by the user to send an application transaction and ultimately have it recorded on the blockchain, which is determined by the specific blockchain implementation and consensus protocol; T Approve is the time taken for the PIC to learn and review the data access application, send the authorization transaction and finally record it on the blockchain, which is mainly determined by external factors such as administrative efficiency, it is not a metric of system performance; T Access is the time between when the user sends the data request and when he or she receives the corresponding data reply (assuming the user will access the database immediately after the application is granted), and this time is the part of latency that we care about. Since the user can access the database multiple times with the same token after a single application is authorized, the first two parts of latency have little impact on latency in practice and are not included in our measurements.
T Access can be further divided as follows: where T Request is the time taken for the user request to reach the ACG; T Validation is the time taken by the ACG to verify the identity and access permission; T Fetch is the time taken by the ACG to fetch the data from the database; and T Reply is the time taken for the response of the ACG to reach the user. Compared with the traditional database access mode, blockchain-based access control via the ACG has an additional time consumption on T Validation , which is exactly the difference between these two access modes. According to the measurement result, T Validation is approximately 12 ms and this value is even smaller for the hardware-specific ACG implementation. We measure the percentage of time spent on this part of the total access time T Access on the LAN and WAN. For this purpose, we will generate different requests with different data access volumes to the ACG as follows.
1) SELECT * FROM employees LIMIT 1.  The ACG executing these statements will fetch 1, 10, 100, 1000, 10 000, and 100 000 records from the employees table of the database and return them to the client.
LAN: In this case, the user client and the ACG server are on the same LAN, thus the latency caused by the transmission bandwidth bottleneck between the user and the ACG is relatively small. The measurement results are shown in Table VII. According to the results, when selecting 1, 10, and 100 records from the table, the additional latency ratio of the total latency due to the identity authentication and access permission checking in the ACG is more than 20%. However, with the increase in the data access volume, this part of the increased latency gradually becomes negligible. In particular, when selecting 100 000 records, the proportion of this part of the total latency is only 0.9%.
WAN: It is rare for the user client and ACG server to be on the same LAN. Thus, it is more informative to measure the latency on a WAN. The measurement results on a WAN are shown in Table VIII. In a WAN environment, when bandwidth becomes the bottleneck, the percentage of latency due to identity authentication and access permission checking in the ACG is negligible. The highest percentage is no more than 3%.
Insight1: Under a WAN, the additional latency caused by the ACG is actually a quite small part of the total latency due to the network bandwidth bottleneck, and it is basically negligible. Therefore, the ACG basically does not bring additional latency.
2) Throughput: Throughput is a very important indicator of server performance, reflecting the number of requests it can handle per unit of time. The introduction of the ACG brings additional identity authentication and access permission checking overhead, which inevitably has a negative impact on the server throughput. However, we still want to measure the magnitude of this impact.
We do so by generating 10 000 requests concurrently and sending them to the ACG. To measure the throughput of the  IX  THROUGHPUT OF THE ACG   TABLE X  ADDITIONAL SPACE FOR AN ADMINISTRATIVE PUNISHMENT CASE ACG server, we will record the time between the first request being sent and the last request being responded to.
The results are shown in Table IX. The Type column indicates the type of server, Processing Time indicates the whole time taken to process 10 000 requests, Throughput is the corresponding throughput, and finally, percentage indicates the ratio of ACG server throughput compared to the traditional server. The results show that ACG servers degrade throughput compared to traditional servers. The main reason is that the ACG needs to track events on the blockchain through web3.js and has to verify the application and authorization records. Overall, this part of the degradation is not very significant and is within the acceptable range.

Insight2:
The ACG server has 80.9% of the throughput of the traditional server, which is acceptable considering it provides better security.

3) Storage Space:
The timeliness assurance of administrative punishment via blockchain requires that we create a case contract on the blockchain and drive the contract state transition through transactions, which will create a series of blocks on the blockchain. These records (blocks) generated on the blockchain will occupy additional space compared to traditional administrative punishment for which the process is recorded only locally.
We want to measure the extra storage space required for an administrative punishment case with the assistance of blockchain. To do so, we create a case contract to simulate an administrative punishment case from initialization to termination and record the size of the blocks generated during this process.
The results are shown in Table X. After creating a case contract, 52 kB of storage space will be occupied, and then, 80 kB of storage will be used to drive the state of the case contract from none to closed. Note that in our experiments, the creation of the case contract and each subsequent push for its state transition will create a new block. However, none of these newly created blocks are filled, meaning that they could actually hold more transactions. However, each block holds just one transaction and consumes only 10% of the total gas limitation of the block. The storage space consumed in the subsequent process of driving the block state transition is mainly accounted for by the data structure of the block rather than the transactions that push the state transition. Therefore, if every block is filled with transactions, then an average of 8 kB of storage will be used to drive the state transition of the case contract. Therefore, a case contract will consume at most 60 kB of on-chain data from deployment to completion. Later, other nodes will also consume no more than 60 kB of storage space when synchronizing this case contract. In general, federated chains are maintained by dozens of nodes (usually no more than 100). Thus, the sum of storage space consumed by this case contract on all nodes is typically no more than 5 MB. While the file generated by the administrative punishment procedure in reality can be more than 10 MB, this additional overhead (at most 5 MB of on-chain data) is currently acceptable when storage space is relatively cheap.
Insight3: The additional storage space for the on-chain case data is acceptable.

V. RELATED WORK
Some studies focus on analyzing the defects of the administrative punishment system. Xiaojun and Chenyu [36] pointed out the legitimacy risk of the fast handling procedure of administrative punishment and proposed that improvements in six aspects should be made, including the scope of application, administrative methods, standards of proof, procedural motions, notification of rights and obligations, and sampling supervision. Buhong [37] elaborated on the difficulties brought by the substantive treatment of procedural violations and discussed the possibility of implementing the concurrent evaluation of the effectiveness of administrative acts and administrative responsibilities. Mao described the lack of legal procedures for off-site law enforcement and proposed a theoretical plan from "self-determined procedure" to "legal procedure" [38]. Although the above problems focus on the theoretical problems of administrative punishment, some problems can be solved by technical means.
A few studies have focused on combining blockchain and the rule of law, but they mainly reside at the conceptual level and discuss the possibility of combining blockchain without providing concrete and feasible solutions. Hou [39] explored the application of the blockchain technique in egovernance and analyzed the framework, difficulties, and challenges of applying blockchain to e-government at present by taking Chancheng's project as an example. In their paper, Antipova [40] tried to bring the blockchain technique to government auditing and provided a high-level framework. Kassen [41] aimed to define and classify e-government processes that can be automated using blockchain. Jun [42] introduced the significance of blockchain application in government affairs and the possible benefits of introducing the blockchain technique. Ølnes and Jansen [43] examined the potential uses of the blockchain technique in government, such as digital identity management and secure document processing. Shan et al. provided deep insight into the potential of blockchain in optimizing government management, improving government decision-making capacity, and promoting public services. They concluded that the collaborative governance model of smart government based on the blockchain technique has far-reaching significance for promoting the modernization of China's governance capacity and governance system. However, their research method was mainly based on an evolutionary game model rather than the blockchain technique [44]. Liping and Zhaoying [45] studied technique related to a cloud-based law enforcement platform from the intelligent end by integrating artificial intelligence (AI) and blockchain technique.
There are also some studies on the application of blockchain to market supervision [46], [47], [48], [49], but few provide deep insights or a systematic design.

VI. CONCLUSION
This article applies the blockchain technique to the field of administrative punishment in China's market supervision and effectively addresses the two challenges mentioned above. We implement a data access permission control protocol to ensure differentiated access to data for different functional staff. Then, based on this design, we propose a method to provide administrative punishment timeliness assurance and urge the MSD to carry out its corresponding legal responsibilities within the statutory time limit. In addition, we simulate the system using software and provide an evaluation in terms of both functionality and performance. The results show that the system provides security while ensuring availability.
The integration of law and technique is not a simple process but an intricate process of continuously exploring and experimenting based on the actual situation. Administrative punishment in the field of market supervision in China still needs technical assistance, and some questions, such as how to further improve the performance of the current system, how to realize the sharing of law enforcement data across regions and departments, and how to realize the "availability but invisibility" of private data, need to be explored further. These questions are all worthy of further research.