Compliance with privacy regulations, like the European GDPR, poses a big pressure toward the adoption of private blockchain with respect to solutions based on public blockchains. However, there are cases in which adopting a private blockchain is hardly viable for other reasons, leading to situations that might result in a big obstacle for blockchain adoption of whatever kind. In this paper, we describe an approach to make a virtual private blockchain on top of a regular public blockchain, obtaining the security of the consensus algorithm of the latter while keeping the privacy features of a private blockchain. Our approach leverages cryptographic zero-knowledge proofs and authenticated data structures to allow the underlying public blockchain to verify that transactions of the VPBC conform to its specific consensus rules, without decrypting the transaction itself.
Blockchains are usually classified either as public or private. While public blockchains are famous for supporting the cryptocurrency ecosystems and to be a fundamental ingredient of the web3, private blockchains mostly find their applicative niche in restricted consortia or as the basis for integrity-critical application for company internal use.
There are advantages that are specific to private blockchains, like confidentiality, flexibility,
eficiency, and easier control of costs. Maybe the most interesting one is the possibility to keep
transactions confidential so that only the participants that contribute to the infrastructure of
the private blockchain can see them. In fact, while many proposals are aimed to improve public
blockchain with respect to eficiency, cost and developer friendliness, this is much harder for
the confidentiality aspect. Confidentiality is required for compliance with privacy regulations
(like the European GDPR [
Consider a situation in which the subjects that are supposed to participate in a private blockchain are just in small numbers, e.g., three. The security of the whole blockchain is very poor, especially if two of them may have interest to collude. This is just a simplified model of many other possible situations in which • nodes are hosted by a handful of big subjects (the only ones that can aford to do it), and that may have interest in controlling the blockchain system, and • a large number of “small” subjects just participate as clients not being involved in consensus.
A notable case of this model is the one in which there is only one big player that can aford to host a node and a multitude of small players that may have interest to participate but cannot aford to be first class citizens hosting a node. In these situations, the adoption of a private blockchain is possible only if the trust relationships among subjects make the attack unlikely, and hence the main purpose for adopting a blockchain is to improve reliability.
Developing the above considerations, we can easily identify applicative contexts in which the adoption of blockchain, although desirable, is impossible. For example, it is nearly impossible to adopt a private blockchain to support cooperation among small and local companies, cooperation among private (non-company) subjects (e.g., for local self-organized committees), cooperation with short lifespan even among companies, tracking cooperation between one big subject and a multitude of small ones, e.g., companies managing delivery riders, like deliveroo [2], or companies providing visibility, tracking and other value added services to craft sectors, like Yhop [3].
The objective of this paper is to provide an architecture in which public blockchain can be used to realize a virtual private blockchain (VPBC) in which the security of the system is provided by the underlying public blockchain, and in particular the high number of subjects involved in consensus, while confidentiality is obtained by the adoption of suitable cryptographic primitives and zero-knowledge proofs. The final goal is to enable the use of public blockchain to support applications that have to be compliant with privacy regulations and have to be very cheap for all participants (or at least for the large majority of them but one).
The name VPBC is clearly inspired by the Virtual Private Network technology in which a private point-to-point connection is obtained by a clever use of cryptographic primitives on top of plain internet. This connection is cheap since involved parties do not have to install any infrastructure. In a similar way, we propose to create a private blockchain among a number of subjects from a public one without asking the subjects to keep costly nodes.
We provide an architecture that achieves most of the desired goals. We discuss how this can realized with currently available technology and cryptographic primitives. In particular, the main idea is inspired by the work in [4], and consists in moving all the checks and computations that are usually performed by the blockchain, on the client that is creating the transaction. The transaction of a VPBC is encrypted to keep confidentiality and equipped with a zeroknowledge succinct non-interactive proof that the encrypted content satisfies certain applicationspecific consensus rules. Clearly, the public blockchain has to check the correctness of the zero-knowledge proof to accept the transaction, which can be done by a smart contract. Note that this can be done without decrypting the content. In this way, transactions are kept private to the participants in the VPBC.
Other details are discussed in the paper, in particular regarding the synchronization of the shared state and the throughput and latency of this kind of approach.
The rest of the paper is organized as follows. In Section 2, we describe the background and the related works of our approach. In Section 3, we formalize the problem. In Section 4, we describe our architecture. In Section 5, we briefly discuss some properties of our architecture. In Section 6, we present our conclusions and possible future research directions.
As stated in the Introduction, although there is a clear division between public and private blockchains, not all use cases fit neatly into this division. Before examining works similar to our proposal, we describe what other techniques are close to our goal explaining why they are not suitable for it.
Without involving the scenario of blockchains, in literature, every time we need privacy and data integrity, we use Authenticated Data Structures (ADS) [5, 6]. However, a solution based exclusively on ADS demands that the application model be client-server, with an untrusted server. This type of solution can be challenging when structure updates need to be performed. Any new root hash must be securely broadcasted to all participants. The protocols for ensuring data propagation and integrity become too complex in an adversarial environment.
Moving away from the pure use of authenticated data structures leads us to choose among solutions that involve the use of a blockchain, to increase the security of the system without overcomplicating the protocols. In the blockchain, one of the most well-known techniques for performing interactions between parties, without all participants in the chain knowing all the details, is the state channel [7, 8], or its generalized version called Multi-Party Virtual State Channels [9, 10]. The main idea behind state channels is to achieve the same security guarantees as the blockchain, but at the same time minimize the number of required on-chain transactions. They present several challenges, but the main disadvantage is the need for all participants to be online and actively involved in the operation of the channel.
To overcome the issues concerning channel confidentiality, authenticity, finalization, and dispute resolution it was proposed Speedster [11]. The main idea of Speedster is that every user creates an of-chain account protected by the hardware-based enclave, an instance of a Trusted Execution Environment (TEE). The main drawback is that these types of solutions are targeted at transaction speed, not simplicity, and cost reduction.
Another approach that is natural to think about is the creation of a private blockchain over a VPN network. This approach however is not viable when the number of participants that can aford to host a node is very small.
Contributions with a similar purpose but diferent techniques are described in [ 12, 13]. In both works, the main disadvantage of the VPBC architecture is the additional overhead required for sending and validating VPBC transactions. The first work introduces the overhead by adding a consensus algorithm among all VPBC peers. The second work introduces the overhead by using the secret sharing technique, in which each transaction must be split into n diferent parts.
As mentioned in the Introduction, our proposed solution involves encrypting transactions to maintain confidentiality and utilizing a zero-knowledge succinct non-interactive proof. In recent years, there has been an increasing demand for data privacy, leading to the use of zeroknowledge proofs in the blockchain scenario. See [14, 15] for a survey. A zero-knowledge proof is a cryptographic protocol that allows the prover to prove the truth of a statement to the verifier without providing any additional information. Non-interactive zero-knowledge proofs are particularly useful when it is not possible for the two parties to interact. There are various types of non-interactive proof, with diferent eficiency tradeofs. Among the currently best-known and most widely used approaches are: zk-SNARK [16, 17], zk-STARK [18], zk-SNORK [19, 20, 21], Bulletproofs [22].
Notably, zero-knowledge proofs are used in blockchain to implement ZK-rollup. A rollup [23] is a scaling solution that aggregates many transaction executions outside the main chain and sends the data back to the main network as a single transaction. By combining zero-knowledge with rollup protocols, we obtain so-called ZK-rollups, which allow us to publish a validity proof of the aggregate in the main chain without having to publish other information about individual transactions, thus reducing operation costs. A follow-up to the zk-rollup thread is the Zero-Knowledge Virtual Machine (ZKVM). Due to its high adoption, the Ethereum Virtual Machine is the one most studied for an evolution to a ZKEVM(zk-EVM) [24]. Since the classic Ethereum Virtual Machine does not support ZK proofs by default, zk-EVM aims to make it possible to create EVM-compatible zk-rollups.
A number of works adopt the above mentioned cryptographic primitives to achieve results that are somewhat akin to a VPBC and may be in principle used as a building block to build a VPBC. In [25], a privacy enabled cryptocurrency compatible with Ethereum is presented. The work in [26] proposes a primitive for decentralized private computations. The work in [27] proposes a privacy-preserving auditable blockchain for financial applications. The Aleo blockchain [28], is a blockchain specifically designed for privacy based on the zkVM approach. In addition, some similarities to a VPBC can be found in other work related to non-blockchain scenarios that use zero knowledge to ensure that some sort of policy is being followed correctly. In [4, 29], a Zero-knowledge Middleboxes network is presented that enforces network usage policies on encrypted trafic. Clients send the middlebox zero-knowledge proofs that their trafic is policy-compliant.
A set of subjects = {1, . . . , } need to share privately a data structure to support a certain application. The data structure evolves over time when subjects emit transactions. We denote the -th transaction as . The state of after is denoted . The application is defined by the application rules that state which transactions can be accepted. We do not go into the details of the application rules, but we suppose that, given certain application rules, there is an algorithm that given − 1 and the candidate says if can be accepted, and, in such case, which is . Subjects in do not trust each other in the sense that each of them can have interest in subverting the application rules and/or tampering with for its advantage. We also admit any collusion, even among − 1 subjects against the remaining one.
Transactions and the data structure have to be kept confidential.
For the sake of simplicity, we assume to have at disposal an ideal public blockchain which is secure, free, and can execute Turing complete smart contracts. Gas-like limitations are likely to hold in practice, however, this is not very relevant in this paper, hence we do not consider it in our model.
We look for a solution that leverages the public blockchain to realize a service that resembles a private blockchain among subjects of preserving confidentiality.
In this section, we show an architecture that solves the problem described in Section 3. Table 1 summarizes the symbols used in this section.
We represent the data structure with an Authenticated Data Structure (ADS) in the sense intended in [5, 6]. For simplicity, we denote the ADS associated with with the same symbol . We briefly recall the properties of an ADS. The content of is uniquely associated with a cryptographic hash, called root hash. We denote a version of with root hash by . It is possible to query , whose root hash is , and obtain the result data with a proof that is in . The proof can be eficiently checked against without knowing . Suppose to update applying some changes to so that a new version ′ is obtained. Given , , and the changes to be applied to , it is possible to calculate the root hash ′ of ′ without knowing . For simplicity we assume is just a key-value mapping, hence data is identified by just one or more keys.
Our architecture is shown in Figure 1. It is made of an underlying public blockchain that we intend to exploit to support a VPBC . The VPBC is formed by a set of participants, which are untrusted to each other. For simplicity, we assume that they are all equivalent and that each of them stores locally. Transactions in are called virtual transactions or vtx’s and express changes to . A vtx is encrypted so that it can be read only by participants of and when it is accepted it is recorded encrypted in blocks of . Participants of update their local copy of when a vtx is accepted by . In the following, we explain the details of how it is possible for to accept (or not) an encrypted vtx.
From the point of view of , a vtx is a pair = ⟨, ⟩, where is the set of the keys of involved in and of the value they have when is supposed to be executed and states the efect of the execution of on a subset of , that is the keys in that are changed by the execution of and the new value they assume. Not all vtx’s can be accepted. Which ones can be accepted depends on the application. We suppose there is an algorithm (, ), associated with the application, that given a vtx to be executed on the state , first checks that conforms to (and fails otherwise) and then, looking solely to , decides to accept or to fail by performing all checks that depends on the application.
Adopting the above notation, the VPBC problems can be stated as follows: realize on exploiting the consensus of so that only vtx’s that conforms to are accepted by and making vtx’s confidential by some form encryption.
To exploit the consensus mechanism of while keeping vtx’s confidential, we make use of zero-knowledge proofs [14]. In some sense, this approach is akin to the one described in [4] in which a device needs to take a decision on the content of an encrypted packet without knowing its content. There are many schemes of zero-knowledge proofs known in literature that are suitable for application in a blockchain context. In our description, we do not make any assumption besides the non-interactivity of a chosen scheme. A brief discussion on eficiency and applicability is given in Section 5.
We denote by {} the encrypted version of by a symmetric key shared among all participants of and not published to anyone else. We assume each participant of has associated a private key , which can be used to sign a transaction or part of it, and a corresponding public key . A certification authority is entitled to decide who are the participants of and expresses this decision by signing the public key of each participant with its secret key . The signed version is denoted [] and can be checked with the public key of the certification authority .
Given a vtx = ⟨, ⟩, we define the augmented form of , denoted ¯, to be the 5-tuple ⟨, , (), ′, ⟩ where • is the root hash of on which is supposed to act, • () is a set of ADS proofs, one for each element of , with respect to , • ′ is the root hash of ′ resulting from the application of the efects of on , • is the signature of by one of the participants of .
Note that, it is easy to derive from (, ) an equivalent ¯(¯) that does not need to know , by exploiting the proofs in () instead of accessing .
We assume that the chosen zk scheme can be used to provide a prover function zkp¯({¯}, ¯, , [], ), where ¯ = ⟨, , (), ′, ⟩, returning a non-interactive zero knowledge proof that • {¯} is the correct encryption of ¯ with key , • is accepted by ¯ (and hence by ), • its execution transforms into ′ , • is a correct signature of , verified by public key and [] is correctly verified by .
We also assume the chosen scheme provides a verifier function verify(, {¯}, , ′, ) to check the soundness of , its coherency with the root-hash , and with the public key of the certification authority.
Note that, to accept in , we need to be sure that can be accepted according to the application rules, signature is sound and that the state-related root hash and ′ are sound. Hence, can be accepted if verify(, {¯}, , ′, ) accepts .
We are now ready to describe the functioning of the VPBC over the underlying BC . We assume that a smart contract is available in that has only one callable operation execute, whose signature is execute(, {¯}, ′), it keeps in its state ¯ which is the current root-hash of , and knows . The execute operation performs verification using the above defined verification function called as follows: verify(, {¯}, ¯, ′, ). If verification is successful, the operation call, comprising the {¯} argument is recorded in a block of and ¯ is updated to match ′. If verification fails, no state change is performed and (possibly) nothing is recorded.
The algorithm , and its corresponding ¯, that express the application of is unique and ifxed for . Also, the prover function zkp¯(· · · ) and the corresponding verify(· · · ) are fixed for .
A participant to , with private and public keys and , submits a vtx adopting the following procedure, which assumes that the root-hash of the local copy of corresponds to the root-hash ¯ kept by .
1. Prepare = ⟨, ⟩, where is prepared on the basis of the local copy of = and records the changes to to be applied by the vtx. Clearly, the changes have to be computed respecting the application rules, so that can accept it. 2. Prepare ¯ = ⟨, , (), ′, ⟩, where ADS proofs in () are extracted from , ′ is computed by applying to (or to proofs in ()), and is the signature of with the public key of the participant. 3. Encrypt ¯ by the symmetric key obtaining {¯}. 4. Compute the zk proof = zkp¯({¯}, ¯, , [], ). 5. Submit the vtx by calling execute(, {¯}, ′) on smart contract .
If accepts the vtx, all participants of will get a block recording the call to execute(· · · ) on smart contract containing {¯}. We suppose that each participant to has an instance of with root-hash that is the one stored by before accepting the vtx. The participant can decrypt {¯} by and obtain , which can be used to obtain the new version of that has root hash matching the one stored by .
Partecipant Ar v v¯ {v¯}r′ z
A
Update the state v v¯ subm1it vtx
A
Update the state v v¯
{v¯} Smart Contract C realizing VPBC V execute(z, {v¯}, r′) 2 check vtx Verify rp¯kc r¯ = r′ {v¯}
False
True
There are a number of aspects that can be improved, and/or studied, with respect to the very brief description provided in Section 4.
Cost. We assumed that all participants keep and are always on-line to receive all accepted vtx’s. However, for many of the scenarios described in the introduction, this is not convenient or too costly. Ideally, we would like the participants to be able to stay of-line and sync when on-line again. This is possible by (1) either gathering all missed vtx’s or (2) asking to another participant to help to sync to the last version. Both solutions have pros and cons. The first requires being able to identify the vtx’s among all the transactions of the underlying blockchain. Ideally, this might be supported by the underlying blockchain or the smart contract may keep track of them at least up to a certain extent. The second requires having at least one participant that is always on-line. This is compatible with scenarios in which there is at least one big player that has enough technical capability to do so.
Thruoghput. Currently, in our proposal, it is possible to perform only one vtx per block accepted in the underlying blockchain. While this might be acceptable in the scenarios mentioned in the introduction, it is clearly suboptimal. To improve throughput, a possible direction of study is to aggregate transactions with techniques that aggregate changes to an authenticated data structure, possibly referred to diferent, but recent, root-hashes. A similar approach was proposed in [30] in a diferent context. This might require to include the proofs () of a vtx unencrypted. Hence, an analysis of the possible confidentiality threats has to be performed. Privacy Regulation Compliance. Our approach provides relevant steps toward a full compliance of private blockchain-based applications that takes advantage of premissionless infrastructures. First of all, the identification of controller and processor are streamlined as a VPBC greatly resembles a regular private/private blockchain. The only diference is that the infrastructure is provided by an external entity (the public blockchain) that while it does not guarantee confidentiality, it performs provably correct execution by design. The confidentiality aspect is compensated by the adoption of a proper form of encryption. Ensuring the principle of the right to be forgotten is slightly more complex. Suppose the controller is identified by the whole set of participants to the VPBC and suppose that a data subject has expressed its will for his/her personal data to be removed. The data can be easily removed by a proper vtx1 A bit more complex to address is the fact that vtx’s containing personal data are permanently stored in the underlying blockchain, even though encrypted. To address this problem all participants have to forget the shared key and agree on a new shared key ′ to be used for the subsequent vtx’s.
A possible Zero-Knowledge Protocol choice. Among the many ZK protocols described in literature, we think that it is worth considering the Groth16 [16] approach as a basis for a first prototype of our VPBC. Further, the availability of a framework like Circom [31] may greatly facilitate the creation of simple provers for the first experiments.
We described an architecture to realize a virtual private blockchain, that is a blockchain in which transactions and state are confidential to a limited set of participants while the infrastructure is an underlying public blockchain. In particular, in our proposal, the security of the consensus is bound to the security of the consensus of the underlying blockchain. We identified a number of scenarios in which this would be desirable, i.e., when privacy regulation compliance is needed and the number of participants that can aford to set up a node is limited. Our architecture is based on encrypted (virtual) transactions and zero-knowledge proofs. We also discussed a number of aspects that our brief description does not handle which will be the subject of future research work. 1Any copy that a participant keeps outside any blockchain-related system is clearly outside the scope of this paper and the participant is legally responsible for it. augmented form of , the 5-tuple ⟨, , (), ′, ⟩ signed version of , signed with the encrypted version of by the signature of by one of the participants of . set of keys of involved in and of the value they have when is supposed to be executed. Cardinality of public key of a subject or ADS proof depending on the context
discussions.
We are grateful to Pierpaolo Della Monica and Marco Zecchini for their valuable comments and This work was partially supported by the project “Advanced and Quantum-safe Solutions for Digital Identity and Digital Tracing” (AQuSDIT), funded by the European National Recovery and Resilience Plan (NRRP) under the Extended Partnership initiative, SERICS (PE00000014) Spoke 5 - Cryptography and Distributed Systems Security (Università della Calabria). [2] Wikipedia, Deliveroo ltd., https://en.wikipedia.org/wiki/Deliveroo, 2024. (Accessed on 11/03/2024). [3] T. srl, Yhop, https://app.yhop.beer/, 2024. (Accessed on 11/03/2024). [4] P. Grubbs, A. Arun, Y. Zhang, J. Bonneau, M. Walfish, {Zero-Knowledge} middleboxes, in: 31st USENIX Security Symposium (USENIX Security 22), 2022, pp. 4255–4272. [5] R. Tamassia, Authenticated data structures, in: Algorithms-ESA 2003: 11th Annual European Symposium, Budapest, Hungary, September 16-19, 2003. Proceedings 11, Springer, 2003, pp. 2–5. [6] A. Miller, M. Hicks, J. Katz, E. Shi, Authenticated data structures, generically, ACM
SIGPLAN Notices 49 (2014) 411–423. [7] J. Coleman, State channels - an explanation, https://www.jefcoleman.ca/state-channels/, 2015. (Accessed on 05/03/2024). [8] L. D. Negka, G. P. Spathoulas, Blockchain state channels: A state of the art, IEEE Access 9 (2021) 160277–160298. doi:10.1109/ACCESS.2021.3131419. [9] S. Dziembowski, L. Eckey, S. Faust, J. Hesse, K. Hostáková, Multi-party virtual state channels, in: Advances in Cryptology–EUROCRYPT 2019: 38th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Darmstadt, Germany, May 19–23, 2019, Proceedings, Part I 38, Springer, 2019, pp. 625–656. [10] S. Dziembowski, S. Faust, K. Hostáková, General state channel networks, in: Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security, 2018, pp. 949–966. [11] J. Liao, F. Zhang, W. Sun, W. Shi, Speedster: An eficient multi-party state channel via enclaves, in: Proceedings of the 2022 ACM on Asia Conference on Computer and Communications Security, 2022, pp. 637–651. [12] A. Arena, P. Perazzo, G. Dini, Virtual private ledgers: Embedding private distributed ledgers over a public blockchain by cryptography, in: Proceedings of the 23rd International Database Applications & Engineering Symposium, 2019, pp. 1–9. [13] S. Onalo, D. Gc, E. Pfluegel, Virtual private blockchains: security overlays for permissioned blockchains, Fifth International Conference on Cyber-Technologies and Cyber-Systems: CYBER 2020 (2020). [14] X. Sun, F. R. Yu, P. Zhang, Z. Sun, W. Xie, X. Peng, A survey on zero-knowledge proof in blockchain, IEEE network 35 (2021) 198–205. [15] J. Partala, T. H. Nguyen, S. Pirttikangas, Non-interactive zero-knowledge for blockchain:
A survey, IEEE Access 8 (2020) 227945–227961. [16] J. Groth, On the size of pairing-based non-interactive arguments, in: Advances in Cryptology–EUROCRYPT 2016: 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, May 8-12, 2016, Proceedings, Part II 35, Springer, 2016, pp. 305–326. [17] M. Petkus, Why and how zk-snark works, arXiv preprint arXiv:1906.07221 (2019). [18] E. Ben-Sasson, I. Bentov, Y. Horesh, M. Riabzev, Scalable, transparent, and post-quantum secure computational integrity, Cryptology ePrint Archive (2018). [19] M. Maller, S. Bowe, M. Kohlweiss, S. Meiklejohn, Sonic: Zero-knowledge snarks from linear-size universal and updatable structured reference strings, in: Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security, 2019, pp. 2111–2128. [20] A. Gabizon, Z. J. Williamson, O. Ciobotaru, Plonk: Permutations over lagrange-bases for oecumenical noninteractive arguments of knowledge, Cryptology ePrint Archive (2019). [21] T. Xie, J. Zhang, Y. Zhang, C. Papamanthou, D. Song, Libra: Succinct zero-knowledge proofs with optimal prover computation, in: Advances in Cryptology–CRYPTO 2019: 39th Annual International Cryptology Conference, Santa Barbara, CA, USA, August 18–22, 2019, Proceedings, Part III 39, Springer, 2019, pp. 733–764. [22] B. Bünz, J. Bootle, D. Boneh, A. Poelstra, P. Wuille, G. Maxwell, Bulletproofs: Short proofs for confidential transactions and more, in: 2018 IEEE symposium on security and privacy (SP), IEEE, 2018, pp. 315–334. [23] L. T. Thibault, T. Sarry, A. S. Hafid, Blockchain scaling using rollups: A comprehensive survey, IEEE Access 10 (2022) 93039–93054. doi:10.1109/ACCESS.2022.3200051. [24] Alchemy, What is a zkevm?, https://www.alchemy.com/overviews/zkevm, 2022. (Accessed on 07/03/2024). [25] B. Bünz, S. Agrawal, M. Zamani, D. Boneh, Zether: Towards privacy in a smart contract world, in: International Conference on Financial Cryptography and Data Security, Springer, 2020, pp. 423–443. [26] S. Bowe, A. Chiesa, M. Green, I. Miers, P. Mishra, H. Wu, Zexe: Enabling decentralized private computation, in: 2020 IEEE Symposium on Security and Privacy (SP), IEEE, 2020, pp. 947–964. [27] N. Narula, W. Vasquez, M. Virza, {zkLedger}:{Privacy-Preserving} auditing for distributed ledgers, in: 15th USENIX Symposium on Networked Systems Design and Implementation (NSDI 18), 2018, pp. 65–80. [28] A. N. FOUNDATION, Aleo | fully private applications, https://aleo.org/, 2024. (Accessed on 27/02/2024). [29] C. Zhang, Z. DeStefano, A. Arun, J. Bonneau, P. Grubbs, M. Walfish, Zombie: Middleboxes that don’t snoop, Cryptology ePrint Archive (2023). [30] M. Bernardini, D. Pennino, M. Pizzonia, Blockchains meet distributed hash tables: Decoupling validation from state storage, CEUR Workshop Proceedings 2334 (2019) 43 – 55. URL: https://www.scopus.com/inward/record.uri?eid=2-s2.0-85063259759&partnerID= 40&md5=484bac13f164c622fe00c8541b0ec436. [31] iden3, Circom, https://iden3.io/circom, 2024. (Accessed on 12/03/2024).