An Access Control System Based on Blockchain with Zero-Knowledge Rollups in High-Traffic IoT Environments

The access control (AC) system in an IoT (Internet of Things) context ensures that only authorized entities have access to specific devices and that the authorization procedure is based on pre-established rules. Recently, blockchain-based AC systems have gained attention within research as a potential solution to the single point of failure issue that centralized architectures may bring. Moreover, zero-knowledge proof (ZKP) technology is included in blockchain-based AC systems to address the issue of sensitive data leaking. However, current solutions have two problems: (1) systems built by these works are not adaptive to high-traffic IoT environments because of low transactions per second (TPS) and high latency; (2) these works cannot fully guarantee that all user behaviors are honest. In this work, we propose a blockchain-based AC system with zero-knowledge rollups to address the aforementioned issues. Our proposed system implements zero-knowledge rollups (ZK-rollups) of access control, where different AC authorization requests can be grouped into the same batch to generate a uniform ZKP, which is designed specifically to guarantee that participants can be trusted. In low-traffic environments, sufficient experiments show that the proposed system has the least AC authorization time cost compared to existing works. In high-traffic environments, we further prove that based on the ZK-rollups optimization, the proposed system can reduce the authorization time overhead by 86%. Furthermore, the security analysis is presented to show the system’s ability to prevent malicious behaviors.


Introduction
The Internet of Things (IoT) connects parts of machines, devices, users, and intelligent systems on a massive scale [1,2]. It is anticipated that by 2022, there will be 50 billion connected IoT devices [3,4], and this enormous expansion demonstrates that IoT systems will be extensively used in an increasing number of fields (e.g., smart transportation, smart healthcare, smart city, smart grid, etc.) and will significantly enhance the user experience in different scenarios. Although the application of IoT systems has made our lives easier, it also results in many security and privacy issues, among which the access control (AC) [5,6] issue is particularly prominent.
The access control issue can be described as being based on a security mechanism to guarantee that only authorized entities access specific IoT devices. Common access control methods include mandatory access control (MAC) [7], role-based access control (RBAC) [8], attributed-based access control (ABAC) [9] and capability-based access control (CapBAC) [10]. AC systems include traditional centralized AC systems and distributed AC systems [11]. Traditional AC requires a central entity for decision-making, (1) We propose the ZK-rollups of the access control authorization process, where the authorization matching and access token grant processes from different access control requests can be grouped into the same batch of transactions to generate the zeroknowledge proof uniformly. (2) We propose a specialized zero-knowledge proof, to ensure that participants involved in the authorization can be honest and that the sensitive data in the authorization matching process will not be leaked. Furthermore, we develop a practical system that supports zero-knowledge access control authorization and demonstrates the complete arithmetic circuit generation algorithms and the protocol implementations. (3) We design sufficient experiments to prove that the proposed system is suitable for high-traffic IoT environments and provide security analysis to verify the system's ability to guarantee honesty.
The structure of this work is as follows: Section 2 introduces the related work, Section 3 introduces an overview of the system, Section 4 introduces generation algorithms of the arithmetic circuits required for the zero-knowledge proof and the protocol required to implement the proposed system, Section 5 introduces the implementation details of the proposed system and the experimental results, Section 6 introduces the security analysis which shows the ability of the proposed system to ensure the honesty of participants, and Section 7 concludes this paper.

Attribute-Based Access Control
The term "attribute-based access control" (ABAC) [25], also known as "policy-based access control", refers to an access control paradigm in which the decision as to whether a subject is authorized to perform some operations by evaluating a set of attributes. ABAC is a technique for enforcing access control policies that are highly adaptable and can be adjusted using a variety of attributes, making it appropriate for usage in distributed or quickly changing contexts. ABAC policy rules are generated as boolean functions of the subject's attributes, the object's attributes, and the environmental attributes. An access control authorization is performed by both PEP (Policy Enforcement Point) and PDP (Policy Decision Point) [26], PEP is where authorization is enforced, and PDP is where authorization is made. The ABAC authorization process can be described as follows: the subject submits its attributes to PEP, PEP submits the subject's attributes to PDP, PDP combines object, subject, and environmental attributes into access attributes to match with the pre-defined policy, PDP returns the matching result to PEP, and then PEP informs the subject. The matching process of access attributes and policies is called authorization matching.

Blockchain Technology
Satoshi Nakamoto initially suggested the blockchain in 2009 [27]. The first widely used peer-to-peer trustless electronic currency was called Bitcoin. Since then, a variety of new digital currencies (known as cryptocurrencies) have been developed using a similar framework. In the meanwhile, other blockchain-based apps have been created throughout the years to execute scenarios other than cryptocurrency. One of these is the IoT scenario.
Directly implemented in blockchain networks, smart contracts [28] are computer protocols that simplify, verify, or enforce contract negotiation. Without requiring human interaction, smart contracts offer the ability to directly track and enforce intricate agreements between parties.

zkSNARK and Zero-Knowledge Rollups
A method known as the zero-knowledge proof (ZKP) allows one party (the prover) to convince another party (the verifier) that a specific statement is true, while the prover refrains from revealing any information other than the fact that the statement is indeed true [29,30]. Zero-knowledge Succinct Non-interactive Argument of Knowledge, or zk-SNARK [22,23], is a popular form of non-interactive zero-knowledge proof today. Using zkSNARK, the prover and verifier do not need to directly communicate, and the generated proof is brief and simple to verify. We will follow up with an informal definition of zkSNARK, see Bitansky et al. [23] for a complete introduction. Given an arithmetic circuit C that encodes the proposition mathematically, a zkSNARK is defined as a triple of algorithms (KeyGen, Prove, Veri f y) where: (pk, vk) ← KeyGen(1 λ , C) (1) π ← Prove(pk, x, w) (2) {0, 1} ← Veri f y(vk, π, x) • KeyGen: Input a security parameter λ and an arithmetic circuit C, then use the key generator function KeyGen to probabilistically sample a proving key pk and verification key vk. Both keys can be exposed as public parameters and can be used multiple times. • Prove: Given a proof key pk, an input message x, and a witness w, Prove outputs a non-interactive proof π, which proves the correctness of the circuit C. In the zkSNARK framework, the arithmetic circuits C are first transformed into the rank 1 constraint system (R1CS) ccs, which in turn generates the x and w required by Prove. • Veri f y: Given verification key vk, the proof π, and input x, Veri f y outputs 1 if the verification is correct, otherwise 0 if it is false.
Because of its low throughput, or low TPS (transactions per second), blockchain technology has a variety of application-related issues. Layer 2 is suggested as a method to boost the TPS and enhance the scalability of the blockchain [31], and the rollup [24] is one of its implementations. At the moment, Ethereum [32] has designated the rollup as one of the major characteristics to be implemented in the upcoming phase. The rollup can be implemented by constructing a corresponding Merkle proof for a transaction to prove its correctness so that it can be correctly submitted to the blockchain and advance the state transfer of the blockchain. In this way, rollups remove the need for execution directly on the blockchain: only the on-chain verification is performed, thus the computational pressure is shifted off the chain. One of the on-chain verifiable computing implementations is the zero-knowledge rollup using the zkSNARK framework.

Blockchain-Based AC Systems with ZKP
Considering the lightweight and low-power nature of most IoT devices, processes involved in the access control process, such as policy storage, cryptographic operations, or additional network access, need to be performed by a central entity as an intermediary on behalf of the device, which introduces additional security risks, such as single point of failure or data tampering. Therefore, many scholars introduced blockchain technology as a distributed and trusted entity involved in access controls [33]. In advance, to solve the problem of exposing sensitive data in the blockchain, such that the blockchain becomes vulnerable [34][35][36], many scholars introduced zero-knowledge (ZKP) into blockchain-based AC systems.
The works that are identical to ours include Qinan Li et al. [19], Hu et al. [20] and Maesa et al. [21]. Qinan Li et al. [19] presented a ZK access control protocol, this work was among the first to apply ZKP to the field of AC, but it is limited to the request phase and does not consider the risk of replay attacks. Hu et al. [20] proposed a system to exchange tokens with ZKP of access rights to make IoT devices granted anonymously, it maintains confidentiality on the identities of users. However, this work maintains a Merkle tree with a height of 32 for all tokens, and such a high tree will result in an unacceptable Merkle proof generation time overhead and leaf node storage overhead. Maesa et al. [21] expanded the XACML standard for ABAC systems with the novel concept of private attributes, then built a system that leverages smart contracts and zero-knowledge proofs to allow for transparent policies evaluation without disclosing the value of such sensible attributes. However, this work is not suitable for high-traffic IoT environments. On the one hand, the work is performed on Ethereum to build the system, which provides low TPS and high transaction latency; on the other hand, the much higher-than-average gas consumption of authorization matching means that the system has high computational and storage costs. Moreover, this work does not guarantee the honesty of all participants, and the malicious user has the opportunity to complete the access grant without the existence of the corresponding authorization request.
In summary, identical type of work exists two kinds of problems. On the one hand, these systems suffer from low TPS and high latency, which are not suitable for hightraffic IoT environments; on the other hand, they cannot fully guarantee the honesty of participating users, and malicious users have the opportunity to bypass pre-defined rules to attack systems. Considering the above two issues, we design a special ZKP to guarantee the honesty of users and optimize the blockchain-based AC system based on the ZK-rollup concept to improve the execution efficiency of access authorization, ensuring the stable performance of the system in high-traffic IoT environments. We also design reliable comparison experiments to demonstrate that the proposed system has the best access authorization performance in low-traffic environments and further demonstrate its advantages in high-traffic environments.

System Overview
In this section, both the participant entities of the system and a sample access control process are presented.

Participant Entities
As shown in Figure 1, there are eight participant entities in this system.

• Requester
The requester as an object, who asks for access control privileges for the IoT device as a subject, is the one who starts the access control process. The requester logs into the blockchain network using their device while maintaining anonymity. Other than the cryptographic public key required to encrypt sensitive data and the signature public key used to authenticate calls to smart contracts, it does not reveal redundant information to other network users.

•
Requester Device The requester device acts as an intermediary between the requester and the blockchain network. Through its device, the requester starts the authorization process for access control to the blockchain network and carries requester attributes to facilitate further authorization. If the access control is valid, the requester device will obtain the token it needs from the blockchain network to connect to the IoT device.

• Owner
The owner is the holder of an IoT device in the system, marking that an IoT device belongs to that owner. Similar to a requester, the owner also maintains anonymity throughout the blockchain network. The owner establishes a connection with the blockchain network through its server and performs two duties: (1) the owner needs to register the IoT device with the blockchain network so that the requester can discover the IoT device and initiate access control; (2) the owner can discover from the server that the requester needs to apply for access control to a certain IoT device held by the owner, and store the policies required to authorize requester access control legitimacy in the server.

•
Owner Server The owner server, which holds the owner's specified policies, serves as a conduit for communication between the owner and the blockchain network. The owner server takes part in the network as a peer node as well. The server must ascertain whether the access attributes satisfy the previously established policies when it obtains authorization from the blockchain network, and create a zero-knowledge proof for a batch of authorization requests to indicate the authorization results (success or failure). The owner server also creates the access token needed to connect to the IoT device.

• IoT Devices
IoT devices are entities that requesters can access. The gateway acts as the intermediary between the IoT device and the blockchain network because the majority of IoT devices have constrained storage and computing capabilities. A requester uses a specific IP address to connect to an IoT device and is equipped with an access token. The IoT device then verifies the token's legitimacy with the smart contract via the gateway, and if the token is legitimate, the requester's access is verified.

• Gateway
The gateway is the agent that establishes the connection between IoT devices and the blockchain network. It is responsible for communicating with IoT devices using dedicated structured protocols (e.g., mqtt [37], modbus [38], etc.) and invoking smart contracts deployed on the blockchain to authenticate the requester's access token to reduce security issues caused by a large number of IoT devices directly accessing the blockchain network. To reduce the interaction latency with the blockchain, each gateway is deployed as a peer node that holds public data on the chain together.

• Blockchain
The blockchain has two purposes in this system. On the one hand, blockchain acts as a channel of communication between the requester and the owner. The proposed system implements asynchronous communication based on the blockchain network. The communication initiator can initiate a request through a smart contract call, and the receiver can sense the initiator's request by registering the on-chain callback function, obtaining the corresponding request message body from the chain, and reply it using the same asynchronous communication mechanism.
On the other hand, blockchain acts as a verifier in the ZKP. To confirm the validity of the proof, the owner must construct it off-chain using tamper-evident data from the chain. On-chain verification is then carried out using the pre-uploaded verification key.

• Smart Contract
Based on smart contracts deployed in the chain, we build a series of protocols for interaction between participant entities in the system, which can be divided into three phases: setup phase, access control authorization phase, and token authentication phase. During the setup phase, the smart contract is responsible for the registration of users (requester or owner) and IoT devices, as well as the uploading of verification keys required for ZKP verification. During the access control authorization phase, on the one hand, the smart contract is responsible for facilitating the requester to obtain the user attributes required for authorization matching and initiate an authorization request for access control. On the other hand, the smart contract verifies the ZKP submitted by the owner and returns the required access token to the requester. During the token authentication phase, the smart contract is responsible for providing the gateway to authenticate the legitimacy and validity of the access token.

Sample Access Control
A sample access control flow is shown in Figure 2. First of all, the requester asks the owner for the format of the required attributes. Note that the requester and the owner communicate asynchronously via the blockchain. The owner returns the encrypted format to the requester, who prepares the relevant attributes according to the format and transmits them, encrypted, to the owner. The owner matches the attributes submitted by the requester with the predefined policies. The owner creates a ZKP for a batch of authorization requests coming from various requesters. For successfully authorized requests, the owner server will generate the access token, then encrypt tokens and IP addresses of IoT devices using the requester's public key. The proof, tokens, and IP addresses will be packaged and submitted to the smart contract as the rollup, and the smart contract will verify the ZKP. If the ZKP verification is passed, the requester can obtain the IP and access token through the callback event registered on the blockchain, and apply for access control permission to the IoT device. After the IoT device receives the token from the requester, the token will be verified by the blockchain via the gateway. If the token is legal, the requester officially has access control permission for the target IoT device.

Access Control Authorization with ZK-Rollups and Protocols
In this section, we will introduce the implementation of access control authorization with ZK-rollups and protocols among participant entities in our proposed system based on the overview of Section 3. Notations that appear in this section are shown in Table 1.

Access Control Authorization with ZK-Rollups
In this subsection, we will go over the design of access control authorization which implements ZK-rollups [24] optimization and ensures the honesty of participants. The zkSNARK framework builds solid proof propositions from arithmetic circuits [22,23]. The arithmetic circuit, which outlines the proof that needs to be constructed, is actually a formal representation of the NP (Non-deterministic Polynomial) statement [34]. By combining this with Section 3, we can conclude that a valid access control authorization procedure meets the following NP statement: (1) The owner receives an access control authorization request from a specific requester, as well as the requester attributes for authorization. (2) The owner matches the access attributes with the set policy.
(3) The requester obtains the required token to access the IoT device.

Notation Description
A The access attribute set used for authorization matching α i The ith access attribute in A P The policy set used for authorization matching ρ i The ith policy in P C The arithmetic circuit Hash Hash function h The hash calculation result dev The "Device"data structure in the public ledger acc The "Access" data structure in the public ledger leaves A list of leaf nodes in the Merkle tree siblings Sibling nodes needed to generate the Merkle proof of a leaf token The token required for the requester to perform access control on a device salt Randomness used to generated token PK enc , PK sig Public key for encryption or signature generation SK enc , SK sig Private key for encryption or signature generation KeyGen enc , KeyGen sig The generation function of < PK, SK > pair ENC, DEC Encryption and decryption functions Sign The signature generation function SigVeri f y The signature verification function DS U A Data structure describing the composition form of U A pk, vk Proving key and verification key of zkSNARK x Input message of zkSNARK w Witness of zkSNARK txns The transactions of ZK-rollups π Generated non-interactive proof of zkSNARK K rd Symmetric session key for requester and IoT device To generate proof from this NP statement, we construct two basic circuits, "Authorization Matching Circuits" and "Access Token Grant Circuits".

Authorization Matching Circuits
As shown in Table 2, there are five common access control policies as follows, among which ID req , UA, and ID dev need to be generated by the requester side, which we call requester attributes (RA). RA indicates that access control authorization is initiated for the specified IoT device, while EA and AA are generated at the owner server side. Thus, a set of access control attributes can be defined as A = {RA, EA, AA} = ID req , ID dev , UA , EA, AA . Used to describe the environmental characteristics of the IoT device when access control occurs, such as time, temperature, etc.

Access Action (AA)
Used to specify the IoT device operations that the requester is permitted to perform, such as read, write, execute, etc.
The "Authorization Matching Circuits" are responsible for proving the "the owner matches the access attributes with the set policy". An authorization matching process can be described as follows: (1) Requester uses RA to initiate access control authorization, owner server generates access attributes A = {RA, EA, AA} = {α 0 , α 1 , α 2 , . . . , α n } for matching; (2) Owner uses policy P = {ρ 0 , ρ 1 , ρ 2 , . . . , ρ n } to match, if A ⊂ P, then the authorization access control is legal, otherwise it fails.
Combining the five types of policies shown in Table 2, the proposed system sets the following three attribute-matching patterns.
• Equivalence Matching. Determines that α i is exactly equal to ρ i , e.g., ID req is consistent with the policy. • Range Matching. Determine α i within the given range of ρ i , for example, the timestamp of this access control is Time, the timestamp of last access control is LastTime, and the maximum time interval allowed for consecutive access is GapTime, which needs to satisfy multi-value matching needs to judge α i = ρ i . For example, the "Access Action" determines whether a requester has read access to all files in a file list.
For "Equivalence Matching" and "Range Matching", the general zkSNARK framework comes with based arithmetic circuits to describe such processes, while for "Multivalue Matching", since α i and ρ i need to be considered as a whole, we use the arithmetic circuit of hash operations to describe the matching process, i.e., to determine To guarantee that the owner does use attributes submitted by the requester to do matching, we additionally add an arithmetic circuit of hash operations to determine Based on a hash calculation of its submitted requester attributes, the requester generates and appends h RA to the authorization request as a puzzle. The owner must reconstruct this hash value when producing proof to show that it truly makes use of the requester attributes provided by the requester to do authorization matching computation. The existence and correctness of h RA are performed based on the Merkle proof [32], which will be described in Section 4.1.2.
We first need some functions to generate the basic arithmetic circuits and combine these basic components to finally form the target arithmetic circuit, which can represent the NP statement. In combination with the above description, we defined three basic circuit generation functions corresponding to three matching patterns: • C ← CircuitEq(x, y): Construct an arithmetic circuit where x and y are equal; • C ← CircuitRangeEq(x, y): Construct an arithmetic circuit with x in the specified range of y. In practice it is a quantitative relationship determined by the matching requirements of access attributes and policies; • (C, h) ← CircuitHash(X): Construct an arithmetic circuit which reveals that Hash(X) = Hash(x 0 x 1 x 2 · · · x n ) and output the hash calculation result h.
With two additional functions: The owner uses RA.ID dev and RA.ID req to query in the owner server to obtain the EA and AA of the corresponding IoT device, and after combining them with RA, the access attribute A is generated.
With the above basic circuits and function, we can construct "Authorization Matching Circuits" via Algorithm 1.

Algorithm 1 Build Matching Circuit
In Algorithm 1, C means an arithmetic circuit, C ← C 1 ∪ C 2 represents the combination of two circuits. The time and space complexity of Algorithm 1 are related to the size of the (A, P) pair, both being O(N).

Access Token Grant Circuits
"Access Token Grant Circuits" are responsible for proving that "the owner receives an access control authorization request from a specific requester, as well as the requester attributes for authorization" and "the requester obtains the required token to access the IoT device".
To design arithmetic circuits to implement these two NP statements, we introduce the Merkle proof to confirm: (1) the existence and correctness of the access control authorization request made by the requester and (2) that the IoT device being accessed is in an idle state with no requester for access control. Therefore, we design two different Merkle trees [39], namely, "Access Merkle Tree" and "Device Merkle Tree", as shown in Figure 3. These two Merkle trees will be stored permanently in the blockchain to prevent tampering, thus guaranteeing the correctness of the Merkle proof.
Each time a requester initiates an access control authorization, a data structure called "Access" is saved in the public ledger of the blockchain, and its hash value will be added to the "Access Merkle Tree" as a leaf. ID acc identifies this access control authorization; ID dev is the ID of the corresponding IoT device; ID req identifies the initiating requester; RA enc is the encrypted form of RA using owner's public key; h RA is the result Hash(RA) in Section 4.1.1; nonce initiates as 0, which changes to 1 when the access control authorization is completed, through nonce to guarantee that owner cannot repeatedly use the same data structure to construct a proof. By saving these values in the Merkle tree, we can guarantee that (1) the access control authorization is indeed initiated by a requester, an owner cannot arbitrarily grant access control token of the IoT device; (2) h RA exists and is correct, arithmetic circuits of "Access" Merkle proof and Hash(RA) ensure that owner uses requester attributes submitted by the requester to do off-chain authorization matching. Similarly, the data structure called "Device" identifies the meta info of the IoT device and the current access control status; ID dev and ID own identify the IoT device and its owner. The default value of token and ID req is set to null, which means that no requester is authorized to access this IoT device. As a result, the process of granting an access token can be characterized as first executing a Merkle proof on the token and ID req to ensure that their values are null, after which new token and ID req are assigned, and a new Merkle root hash is calculated. token is generated at the owner server side, and the computation process is shown in Equation (4), salt is the random number generated. The owner needs to inform the requester about the salt, and the requester needs to carry access action AA and salt when initiating formal access control. The gateway repeats the same hash computation process and compares it with the public ledger to determine the correctness of token.
In combination with the above description, we have defined a basic circuit: • C ← CircuitVeri f yProo f (rt, siblings, X): Construct an arithmetic circuit to verify that With the above basic circuits, we can construct "Access Token Grant Circuits" via Algorithms 2 and 3, where dev stands for the "Device" data structure, and acc stands for the "Access" data structure. The time and space complexity analysis of Algorithms 2 and 3 is performed. Suppose the size of leaves is N. For the function Proo f SiblingGeneration, in order to obtain the sibling nodes, a Merkle tree needs to be constructed through the parameter leaves, and the time complexity required for the construction is O(N). Cal MerkleRoot and CircuitVeri f y require a sequential hash computation from the leaf nodes to the root node with a time complexity related to the tree height of O(logN). Therefore, the time complexity of the above algorithms is O(N + logN + logN) = O(N). Furthermore, the space complexity of the above two algorithms is related to the space complexity of the constructed Merkle trees, which are both O(N).
In practice, we choose to keep the height of the Merkle tree within a certain range for four reasons: • As the tree height increases, the time overhead of Algorithms 2 and 3 execution will be concentrated on Proo f SiblingGeneration, which will slow down the authorization overall, as we will show in Section 5.2 in conjunction with experimental data. • Proo f SiblingGeneration also needs to bring Merkle leaves into memory for generating proof, considering an IoT environment with a large number of devices and access authorization requests, a tree with a height of 30 can verify about 1 billion leaf nodes, and a leaf hash of 256 bits will bring a memory overhead of 2 30 × 256 bit = 32 GB. • The article [40] shows that the height of the Merkle tree only affects how many leaves can be verified with the Merkle proof, and has no effect on the security of proof, which is mainly determined by the hash function.
• The owner needs to query Merkle leaves from the public ledger; taller trees mean heavier transmission delay.
For the "Device Merkle Tree", since a single owner has limited IoT devices, for every owner, we generate a tree with its identifier. For "Access Merkle Tree", since the number of authorization requests from the requester may grow infinitely, we choose to have the smart contract reconstruct a Merkle tree and return the identifier of the tree to the users whenever M acc leaf nodes are generated. M acc is usually set to 2 10 to make authorization execute efficiently.

Zero-Knowledge Rollup Circuits
We take into account the characteristics of huge instantaneous access control requests in IoT environments while implementing zero-knowledge access control authorization, combining this with the characteristic of centralized off-chain computation at the ownerserver side in the proposed system. As a result, we use the ZK-rollup [24] concept and decide to create a ZK proof for a batch of access control authorization requests before submitting it to the smart contract for ZK proof verification. This will increase the throughput of the owner server side, decrease the time cost of authorization verification, and lower on-chain computation overhead. Figure 4 depicts the ZK-rollup procedure in its entirety. The owner server simultaneously receives authorization requests from various requesters. Following off-chain authorization matching of access attributes and policy, each authorization request is treated as a transaction. When combined with other authorization requests, these transactions form the rollup of access control authorization. Then, the ZK proof is created using the generated rollup and sent for proof verification to the blockchain smart contract. O(N leaves + N batch × (logN leaves + N match )) (5)

Algorithm 4 Build ZK-Rollup Circuit
if i > 0 then 12: C ← C ∪ CircuitEq(rt acc , rt before acc ) 13: Because Algorithm 4 needs to construct two Merkle trees and perform N batch authorization matching during its execution, the space complexity is: In Algorithm 4, List acc where RA enc is decrypted into RA and List dev is a list of data structure "Access" and "Device"; List token is a list of access tokens for requesters to access to IoT devices, which is also generated by the owner; the identifiers in List ID req identify requesters, meaning requester's access permission; List P is policies stored in a local database of owner server. The size of the lists above is batchSize, which is equal to the size of transactions. In lines 9-11, the generated circuits will verify the intermediate Merkle root hash to ensure the continuity of the token grant process of the rollup.
It is important to note that Algorithm 4 shows the authorization process for a successful authorization matching, and the generation algorithm for circuits that fail to match only removes the arithmetic logic associated with the "Device Merkle Tree". It does not need to consider the process of the token grant, the token and ID req maintain default null value, since lines 6, 9-10, 17-18, and 20 can be removed.

Protocols of System
In this subsection, we will explain the protocols of the proposed system, which are divided into three phases, the setup phase, the access control authorization phase, and the token authorization phase.
To verify the caller's identity, all protocols-aside from "Register User" and "Token Authentication"-must be verified for signatures on the smart contract. The caller (requester or owner) uses SIG = Sign(Hash(X), SK sig ) = Sign(Hash(x 0 x 1 · · · x n ), SK sig ) to generate the signature, and the smart contract uses {0, 1} ← SigVeri f y(SIG, Hash(X), PK sig ) for signature verification, where X is the list of parameters of the smart contract, and < PK sig , SK sig >, is the public-private key pair used for the signature. In the above procedure, the signature of the caller is generated based on the hash of the parameter list; in the SigVeri f y function, the smart contract first uses PK sig to obtain the plaintext of SIG and compares it with Hash(X), if they are the same, the signature verification is successful.

Protocol 1. Register User
• Goal: register users in the proposed system, which may be owners or requesters • Smart contract parameters: PK enc , PK sig , type Steps: (1) Requester U req or owner U own , generate locally the public-private key pair for encryption < PK enc , SK enc >= KeyGen enc (r) and the public-private key pair for signature < PK sig , SK sig >= KeyGen sig (r), r is the randomness. (2) Upload PK enc , PK sig , type to the smart contract, type is the user type.
(3) Generate globally unique user identifier ID user by smart contract and store user information U = ID user , PK enc , PK sig in public ledger.

Protocol 2. Register Device
• Goal: the owner registers the owned IoT device with the blockchain network • Smart contract parameters: {ID dev , ID own } Steps: (1) Owner U own generates locally the identifier ID dev of the owned device and the publicprivate key pair for encryption < PK dev enc , SK dev enc >= KeyGen enc (r). (2) Submit ID dev , ID own , PK dev enc to the smart contract. (3) The smart contract stores the information of the IoT device D = {ID dev , ID own , token null , ID null req , PK dev enc } to the public ledger, where token null and ID null req represent the default token and ID req which shows that no requesters can use a token to access to the IoT device, and adds a leaf node to the "Device Merkle Tree" marked as ID own . (4) Register a callback event with the owner server so that the owner is aware that a requester has initiated access control authorization for the IoT device.

Protocol 3. Verification Key Setup
• Goal: upload verification key of ZK proof to smart contract • Smart contract parameters: {ID own , vk} Steps: (1) Owner U own generates C with Algorithm 4, input parameters rt dev , rt acc , leaves acc , leaves dev are queried from the public ledger, the rest of the parameters can be generated through a batch of past authorization requests. (2) Use C to generate the proving key pk and verification key vk from the Equation (1), as well as the R1CS ccs required by w and x in Equation (2), store pk and ccs in the local server. (3) {ID own , vk} is uploaded to the smart contract, which generates a globally unique vk identifier ID vk and stores V = {ID vk , ID own , vk} to the public ledger.

Access Control Authorization Phase
The access control authorization phase procedure is described in Figure 5.

Protocol 4. Obtain User Attributes
• Goal: let the requester request user attributes (U A) from owner for access control authorization • Smart contract parameters: ID req , ID dev Steps: (1) Requester uploads ID req , ID dev to the smart contract to obtain the needed user attributes for a specific IoT device.
(2) The smart contract will store the requester attributes information in the public ledger RA req = ID req , ID dev . (3) Register a callback event with the requester device so that the requester detects the owner's modification of RA req , then triggers the callback event registered by the owner in Register Device. Figure 5. Procedure of the access control authorization phase.

Protocol 5. Set User Attributes
• Goal: let the owner inform the requester of the required user attributes format for authorization • Smart contract parameters: ID req , ID dev , DS enc U A Steps: (1) The owner senses the request of getting user attributes format through the callback event and stores the policy P required in the server.

Steps:
(1) Requester detects that the owner has set the user attributes format required for authorization via the callback event.
(2) Decrypt DS U A = DEC(DS enc U A , SK req enc ) using the private key, and then generate the RA required for authorization locally.
(3) Obtain the PK own enc of the corresponding owner from the public ledger, and use the encryption function to obtain RA enc = ENC(RA, PK own enc ) and compute h RA = Hash(RA). (4) Call the smart contract. (5) Smart contract generates the identifier ID acc for this access control authorization in the public ledger and stores ACC = ID acc , ID req , ID dev , RA enc , h RA , nonce = 0, ID acc Merkle to the public ledger. (6) Add a leaf node to the "Access Merkle Tree", the identifier of tree generated by smart contract is ID acc Merkle . (7) Trigger the callback event for the owner registered in "Register Device", informing the owner that a requester has initiated authorization.

Protocol 7. Access Control Verify
• Goal: owner integrates authorization requests into a batch of transactions, constructs the zero-knowledge proof, and submits them to smart contracts for verification, the authorization matching result of transactions should be all successful or failed. • Smart contract parameters: {ID vk , π, x, txns, f lag} Steps: (1) Following the receipt of a predetermined number of access control authorizations, the owner begins building the circuit C using Algorithm 4, where the public ledger is queried for the input parameters rt dev , rt acc , leaves acc , leaves dev , and the remaining parameters are built using the authorization requests received. (2) In C, all ID acc in the batch, initial rt dev and rt acc before access control authorization are set to x that can be made public, then read ccs and pk previously saved locally to construct the proof π using Equation (2); (3) Owner uploads {ID vk , π, x, txns, f lag} to the smart contract, where f lag is the authorization result type of π (success/failure), and txns = {txn 0 , txn 1 , . . . , txn n }, txn i = ID acc , token, time token , IP enc dev , salt enc , AA enc . time token represents the duration of the requester to access the device. IP, salt, and AA are encrypted using the requester's encryption public key. Furthermore, token is generated using Equation (4). (4) The smart contract verifies that all ID acc in List ID acc exist in x and obtains rt acc , rt dev from x to compare with the values in the current public ledger, if they are equal, the corresponding vk is obtained by ID vk and executes verification using Equation (3), otherwise the smart contract will return. (5) After executing verification, if the verification value is 1, the smart contract assigns a value of 1 to the nonce and records π in ACC corresponding to ID acc , then assign token and ID req to the corresponding "Device" if f lag is true. If the verification value is 0, the smart contract will reject the batch of authorization verification.

Protocol 8. Token Authentication
• Goal: requester uses the token to access the IoT device Steps: (1) Requester and IoT device establish the session key K rd based on key exchange algorithm (RSA [41]/DH [42]/ECDHE [43]) using their respective public keys. The communication process between the requester and the IoT device will then be encrypted via K rd . (2) Requester initiates a new access control command, encrypts salt and AA using K rd , which is then sent to the IoT device. (3) The IoT device decrypts to obtain salt and AA, also obtains token in the current public ledger via the gateway, and uses Equation (4) to check the correctness of token. If token is legitimate, the IoT device generates a random number N d to send to the requester.
(4) Requester encrypts N d with K rd and sends it to the IoT device. The IoT device decrypts N d and compares it with the previous value to achieve strong authentication of the requester. (5) To make sure that N d is fresh, the requester must repeat steps (2)-(4) when a new access control command is initiated.

Implementation Details
We develop a prototype of the proposed system on Hyperledger Fabric 2.2 [44], using fabric-go-sdk for blockchain smart contract calls, implemented in Golang 1.19 programming language, and the zkSNARK framework used is gnark [45]. The hash arithmetic logic of the circuit and the protocol uniformly use MIMC [46] as the hash function. The cryptographic algorithm of ecc [47] is used in the protocol to encrypt sensitive data, and EdDSA [48] is used as the signature algorithm. The key exchange algorithm uses the ECDHE [43].
The prototype is built on a server with Intel(R) Xeon(R) Platinum 8269 CY CPU @ 2.50 GHz, 16G RAM, and Ubuntu 20.04 OS. Based on the architecture shown in the system overview, we create three virtual machines (VMware Workstation 16) on the server as the owner server, requester device, and gateway, then deploy fabric peer nodes on each of them. The number of processors per virtual machine is set to 2 and the memory is set to 4 GB. A Raspberry Pi (CPU: 1.5 GHz ARM Cortex-A, Memory: 4G) is also connected to the virtual machine that acts as a gateway.

Experiment Results
In the proposed system, we implement eight kinds of protocols. The time cost of protocols 1, 2, 4, 5, 6, 8 can be steadily controlled in less than 5 s. The running time of protocols 3, 7 is related to three functions KenGen, Prove, Veri f y required to perform zeroknowledge proof [22] and Algorithm 4, BuildRollupCircuit. In practice, the time cost of ZK-related functions and Algorithm 4 may be affected by the batch size and height of Merkle trees. To find the effect of the above two factors on the time cost, in the experiment we set the height of "Access Merkle Tree" and "Device Merkle Tree" to 9, 11, 13, 16, as shown in Figures 6 and 7.
The time needed for KenGen is the longest of the three ZK-related functions, as illustrated in Figure 6a. When the batch size is 12 or smaller, the total time consumed can be managed within 100 s, but if the batch size surpasses 50, the total time consumed exceeds 200 s. In general, the time used grows linearly with the increase in batch size. Fortunately, KenGen is a preprocessing function that generates the pk and vk required for authorization, and this part is off-chain computation, which is performed in protocol "Verification Key Setup" in advance. The owner can pre-generate various arithmetic circuit types on the server and obtain the corresponding pk and vk, preventing the KeyGen function from slowing down the whole authorization procedure.
The time consumption of function Prove, which is used for access control authorization, is depicted in Figure 6b. The time overhead of Prove also increases linearly with batch size, although it is still possible to keep the total time overhead under 50 s. By choosing the right batch size, we can in fact reduce this portion of the overall time overhead. Figure 6c illustrates the amount of time required by the procedure for Veri f y, an on-chain computation carried out by the smart contract. As shown in Figure 6c, we can observe that the time spent in this portion can be consistent at the single-digit millisecond level and is less influenced by the batch size and tree height. As a consequence, the very small zero-knowledge verification time allows the proposed system's on-chain computation overhead to remain stable, and when the authorization result is published to the chain, it can be immediately accepted by all peer nodes.   Figure 7 illustrates the amount of time required by the procedure for Algorithm 7. The image demonstrates that the time overhead of this component is minimal when Height = 9, 11, 13 but drastically increases when Height = 16. This is because the proposed system only stores the leaf nodes, necessitating a recalculation of the intermediate values from the leaf nodes to the root node when the function Proo f SiblingGeneration in Section 4.1.2 is used to construct the root hash rt. This is the reason why we keep the maximum number of "Access" generated consecutively to M acc = 2 10 in Section 4.1.2.
The memory use of the produced pk and vk is displayed in Tables 3 and 4, where the input arithmetic circuit is generated by Algorithm 4. The memory footprint of pk grows from tens to hundreds of MB as the tree height and batch size rise, but the memory footprint of vk merely grows as the batch size does. pk takes up more space compared to vk, but pk is only used to generate the proof π off the chain, while vk, which needs to participate in Veri f y function calls on the chain, only takes up KB-level space in the public ledger, which does not significantly increase the storage overhead of peer nodes. The size of π generated by Prove is constant at 1024 bits, which also does not increase the storage overhead on the chain. Next, we will compare the performance of existing systems with respect to the access authorization process. Systems by Maesa et al. [21], Hu et al. [20], and ours are presented. The system by Maesa et al. only considers the authorization matching process, and the system by Hu et al. only considers the access token grant process. Our system includes both processes. Operation (modular or monolithic) of Evaluate SMART POLICY in the system by Maesa et al. generates the zero-knowledge proof of authorization matching off the chain and submits the proof to the chain for verification; tx dele in the system by Hu et al. completes the zero-knowledge token grant. We divide the entire access authorization process into two parts, the off-chain computation, and on-chain computation.
The off-chain computation mainly involves the generation of the zero-knowledge proof. We first compare the system of Maesa et al. with the proposed system. As shown in Figure 8, the time cost of generating the zero-knowledge proof for our system and the modular approach stays consistent as the number of access attributes rises, but the monolithic approach's time cost keeps rising. To ensure that the generated proofs contain the knowledge related to the accessed attributes, both systems add hash puzzles similar to Section 4.1.1 to the proofs. For the modular approach and our system, the strategy of generating an overall hash puzzle for all attributes is adopted, so the proof generation time remains stable; while for the monolithic approach, each attribute in the attribute set has to generate a specific hash puzzle, so the time overhead continues to rise.   [21] and ours.
The on-chain computation mainly includes smart contract execution, node consensus agreement, and network communication. Smart contracts contain ZKP verification and system-varied business logic, such as registered device verification, access token granting, etc. Network communication includes two different ways, between users and blockchain nodes or between nodes. Since the work of Hu et al. does not mention the relevant smart contract implementation, we mainly compare the performance of Maesa et al.'s system with ours for on-chain computation in a low-traffic environment. Maesa et al.'s system is implemented based on Ethereum, and we set the average block time of this system to 12 s, which is consistent with the practical application environment https://ycharts.com/ indicators/ethereum_average_block_time (accesed on 13 March 2023). In addition, we control the number of concurrent requests in the experimental environment at the same time to 5-50 for simulating a low-traffic environment. As shown in Figure 9, as the number of concurrent requests increases, the time for on-chain computation continues to increase in the system by Maesa et al. regardless of the modular approach or the monolithic approach. For the proposed system, we set the height of the associated Merkle tree to the common 10 or 15, and the time cost can remain stable in the low-traffic environment. Figure 9. On-chain computation time cost (s) for system of Maesa et al. [21] and ours in the lowtraffic environment.
As shown in Figure 10, we combine the on-chain and off-chain computation and compare the overall access authorization process performance for different systems. For the system by Hu et al., we still shrink the height of the Merkle tree to 20, and choose to deploy a ZKP-verified contract on the Hyperledger Fabric. We set the number of concurrent requests in the experimental environment to 50. Combining the previous discussion and experimental results of Figure 10, the proposed system has a lower time cost of the overall access authorization process in the low-traffic environment compared to the other two systems. To further demonstrate the optimization of our system for high-traffic IoT environments, we design an experimental environment with a large number of concurrent requests. Figure 11 displays the total amount of time spent by the protocol "Access Control Verify" when the "Device Merkle Tree" and "Access Merkle Tree" heights are 10 and the experimental environment simulates the situation where there are 1000, 5000, 10,000, 20,000 concurrent smart contract requests in the blockchain network, 40 total access control requests that need to be authorized, and every batch size is set to 1, 2, 5, 8, 10, 20, 40. According to Figure 11, the time required by the protocol in the same scenario decreases exponentially as the batch size increases. When comparing different scenarios of existing concurrent requests, we can see that time consumption varies significantly when the batch size is 1, even reaching 993 s when there are 20,000 concurrent requests. The difference in time consumption between various scenarios gradually lowers as the batch size grows. It can be observed that with a batch size of 40, the time cost can be reduced to 133 s, which is an 86% reduction compared to the case of a batch size of 1.
The following is an analysis of the above experimental results of Figure 11. For zero-knowledge access control authorization in "Access Control Verify", the off-chain computation needs to consider the time overhead of Algorithm 4 Build ZK-Rollup Circuit and generate a proof, and this part of the overhead can be optimized by controlling the tree height and batch size. For on-chain computation, we need to consider the transmission delay of each invocation to the smart contract and the time for each peer node to reach an agreement using the consensus algorithm. Therefore, based on the ZK-rollup method, aggregating the access control authorization in fewer batches can reduce the number of smart contract calls and reduce transmission latency in congested network environments on the one hand; on the other hand, since the Veri f y time on the chain is stable at the single-digit millisecond level as shown in Figure 6c, fewer batches mean fewer on-chain consensus algorithm calls. The experimental results demonstrate that the ZK-rollup-based optimization can significantly reduce the time consumed by access control authorization in high-traffic environments, thus making the proposed system more suitable for IoT environments with a large number of devices and instantaneous accesses. Figure 11. Time cost (s) of the protocol "Access Control Verify" in the environment with many concurrent requests.

Security Analysis
In this section, we will provide a security analysis to demonstrate the system's ability to guarantee user honesty.

Potential Attack Modes and Defenses
• Attack 1: a malicious requester wants to obtain the privileges of a device by forging the requester attributes in an existing authorization request. On the one hand, π is generated based on zkSNARK, which does not expose any information about access attributes and policies, and on the other hand, user attributes are encrypted using the requester's private key, which cannot be restored by the attacker via RA enc . Furthermore, the format DS U A of the user attribute U A is not exposed, because DS U A is also encrypted during the transmission. • Attack 2: a malicious requester initiates a replay attack, reusing ACC in the public ledger to initiate access control authorization. If the nonce is 1, the owner server will not perform authorization matching after receiving the request. If the nonce is found to be 0, although the malicious requester obtains the authorization result through Protocol 7, it cannot obtain salt, AA, and the IP of the device through decryption. The malicious requester can neither initiate access control to the IoT device nor obtain any knowledge about token. • Attack 3: a malicious owner receives an access authorization request from a requester and has the corresponding policy in its server, but the owner chooses to forge nonexistent requester attributes to perform the authorization matching. Hash(List acc [i].RA) = List acc [i].h RA in the arithmetic circuit to ensure that the owner can only use the submitted requester attributes for matching, and proof of "Access Merkle Tree" ensures that h RA exists and any forged requester attributes do not pass the Merkle proof test. • Attack 4: a malicious owner wishes to bypass the rules of authorization matching and arbitrarily grant access permission of an IoT device to a requester. This system ensures that this behavior does not occur in three ways: first, the malicious owner cannot build a non-existent proof of "Access Merkle Tree", which ensures that an owner can only grant the token through an authorization request initiated by a requester; second, nonce, if equal to 1, ensures that requests that have completed authorization matching are not reused; third, nonce if equal to 0, with line 9 of Algorithm 4 ensures the correspondence between the requester and the authorization request, the malicious owner cannot use the request initiated by a specific requester to grant token to another requester. • Attack 5: the attacker aims to take control of an IoT device by replaying previous requests during the "Token Authentication" phase. To prevent the attacker from obtaining the most recent N d , the AA and salt are encrypted using the symmetric secret key K rd . Moreover, the freshness of N d assures that an attacker cannot obtain access control by using N d 's previous value.

Formal Security Verification Using AVISPA
We test the security of our suggested protocols in Section 4.2 against an adversary using the widely used AVISPA [49], which is a formal security software verification tool. In AVISPA, a security protocol is tested to see if it is safe or unsafe using the "High-Level Protocol Specification Language (HLPSL)".
We analyze the protocols of the "Access Control Authorization" phase and "Token Authentication" phase using AVISPA. For the "Setup" phase, we consider that the information generated in this phase is publicly available in the blockchain network, so there is no relevant analysis. We use different authentication mechanisms for the two phases. For the "Access Control Authorization" phase, we want the system to complete the authorization faster with less communication in this phase, so we use a weak authentication mechanism and the wrequest function in HLPSL for authentication. In this phase, even if an attacker of the Dolev-Yao intruder model [50] hijacks the intermediate message, the attacker cannot obtain the information related to the requester attributes and token because of the asymmetric encryption algorithm of the proposed system. For protocol of the "Token Authentication" phase, we use a strong authentication mechanism, hoping that an attacker cannot masquerade as a requester and gain access control permission without knowing any information about token, so we use the request function in HLPSL for authentication. The HLPSL code is available in the URL https://github.com/SheenLin/ZKRollups-AC (accessed on 13 March 2023). In the protocol analysis, we use OFMC and CL-AtSe as backend, and the results of the protocol security analysis are shown in Figures 12 and 13.

Research Summary
The blockchain-based AC system with ZKP [22,23,29,30] is currently a popular area of study [19][20][21]. However, current solutions cannot be adaptive to high-traffic IoT environments, also cannot fully guarantee user honesty. We propose a system based on the above considerations. The proposed system is based on the ZK-rollups [24] concept, where specialized Merkle trees [39] and a hash puzzle are designed to construct the zeroknowledge proof. The authorization matching and token grant processes from different authorization requests are encoded into arithmetic circuits. The generated proofs conform to the NP statement for access control authorization and effectively prevent malicious users from initiating attacks on the system, ensuring the honesty of participants and the non-disclosure of sensitive data such as access attributes and policies. We also introduce the communication protocols among participant entities in the system, which are based on a series of arithmetic circuit generation algorithms to effectively improve performance in high-traffic environments and the security of the system. Through a solid experimental design, this work also illustrates how the proposed system can be used in an IoT scenario. A reasonable design of batch size and Merkle tree height can stabilize the time required for the protocols. The produced pk solely consumes off-chain memory, and vk does not significantly increase the on-chain memory occupation, according to experimental data. We split the entire access control authorization process into two processes: off-chain and on-chain computation, and we compare how long each process takes on existing systems and ours. We also show that the proposed system has the least access control authorization time cost in low-traffic IoT environments by integrating the two processes. Further, we demonstrate that in high-traffic environments, the proposed system can cut the authorization time overhead by 86% based on the ZK-rollups optimization. In the security analysis, we construct five different attack modes and show how our system can protect user honesty by demonstrating that it can resist these malicious behaviors. In addition, we verify the security of the system protocols through the AVISPA tool [49].

Future Work
Currently, our proposed system still has some limitations, but it is moving in the direction in which our future work will go.

1.
Each participant entity in the proposed system must maintain a public-private key pair since the conventional asymmetric encryption key management technique is used. However, in an IoT environment with high traffic and many participating entities, such a key management method is undoubtedly very complicated. To lessen the difficulties of key management on the one hand and provide fine-grained access control to encrypted data on the other, we intend to add attribute-based encryption [51] in future work.

2.
In practice, we found that using Algorithm 1 to generate authorization matching circuits is strongly related to the specific business. Despite the fact that we have established three matching patterns, users still need to construct several authorization matching circuits beforehand to meet various business needs. To maximize the effectiveness of authorization matching circuit generation, we want to further improve Algorithm 1 and provide relevant template configuration techniques in future work.

3.
Currently, the proposed system takes into account that in a high-traffic IoT environment, the owner's side may receive a large number of access authorization requests instantaneously, so it adopts the idea of ZK-rollups to design the Protocol "Access Control Verify". However, the requester also needs to send a large number of access authorization requests at the same time to obtain the privileges of an IoT device. Therefore, in future work, we plan to use similar batch optimization on the requester side to improve the performance of the related protocols.