Understanding Trusted Setups: A Guide

If you are familiar with cryptography, computational protocols, and distributed systems, you must surely have encountered the phrase 'trusted setups'.

Trusted setups are integral to the optimal performance of several cryptographic protocols like zero-knowledge proof systems. Yet, some users of these systems may have trouble understanding the complexities going on behind the scenes.

In this article, we will explain the concept of trusted setups in detail along with the need for them, their inner workings, and the different alternatives to trusted setups in cryptography.

What are trusted setups?

To understand the concept of trusted setups, let us consider both words in the phrase.

Trust comes into play because a group is involved in the setup process of a proof system. In contrast, the setup phase involves performing (the setup part) some computation that generates a piece of data (parameter generation) called into use every time you run a specific cryptographic protocol. Trusted setups are exceptional cases of multi-party computation, that require randomness, multiple individuals, and at least one honest party.

A trusted setup is a procedure that involves more than one party. Its aim is to produce the standard parameters that a proof system or similar cryptographic protocols rely on. During this setup, random numbers (secrets) are generated, encrypted, used to generate the data, and then deleted to ensure the protocol remains foulproof. People refer to these random values as toxic wastes because they need to be deleted forever. As the participants need to be trusted for the setup to fulfill its purpose, this process is called a trusted setup.

After generating the initial parameters and destroying their random values, the trusted setup participants have fulfilled their obligations, and no further action is required from them. Single-participant setups are also possible, requiring one person to generate secrets, use them to produce the parameters, and destroy them. However, single-participant setups have a gaping loophole: you need to trust the sole participant to destroy the secrets after the parameter generation event. Them failing to do so exposes the whole protocol.

During its trusted setup ceremony, Zcash famously attempted to turn this issue on its head by selecting an explicit group of both anonymous and ‘trusted’ figureheads to generate a set of random numbers. These numbers were then leveraged to function as the public parameters for creating private transactions on the network.

The entire event, from generating random values to creating a structured reference string (parameters), destroying them, etc. is known as a trusted setup ceremony.

The need for trusted setup ceremonies

As of now, ZK technology has two main applications in the context of blockchains: privacy and scalability. When it comes to privacy-enhancing tools and protocols, non-interactive ZK proofs such as zkSNARKs are often leveraged to achieve on-chain privacy. Many of these protocols, especially in the areas of data availability sampling and zkSNARKs, depend on trusted setups to generate initial parameters also known as a common reference string (CRS).

A common reference string is required for non-interactive and short ZK-proofs that can be shared between the verifier and prover. Without a trusted setup ceremony that destroys the random number function used to create the commor reference string, a malicious actor can create a fake CSR and subsequently generate fake proofs, thereby breaking the proof system.

Several ZK cryptographic protocols rely on trusted setup ceremonies to collaboratively generate their cryptographic parameters. In these ceremonies, each participating party uses secret information, generated locally, to generate data that helps create these initial parameters. The finalized public parameteres determined by a group of participants during the trusted setup ceremony serve as the standard enabling users to trust the privacy assurance of the network.

In other words, trusted ceremonies generate random values and then use them to create a “source” for the system that protects users’ privacy (the common reference string). If at least one participant of this ceremony is fully honest and does not save their contribution, every future user’s privacy is safe.

A simple analogy for trusted setups

Let’s say you want to create a unique perfume that will be made only once and used by people forever.

However, you’re not supposed to share the recipe with anyone or even know it yourself. To make this perfume, you give a bunch of people the instruction to bring in a random amount of a random ingredient. Some bring in roses, other lilies, vanilla extract, etc. You also assign yourself an ingredient to bring a random amount of, and demand that no one, not even yourself, takes note of the amount of their ingredient they brought or its type. Everyone will, without meeting, or seeing the ingredients of others, enter theirs into a special blender that does not let anyone see what’s inside.

If this process is followed correctly, no one will be able to replicate your exact mix ever again with full certainty. The second-to-worst scenario in this case is that everyone but one person kept record of their values. However, even if the rest of the participants aims to replicate the perfume, no one will be completely sure about the missing ingredient (at least in a low-tech setting).

In the above analogy, the final recipe is the key and the perfume the zkSNARKs parameters. Once these initial parameters are set, the key is destroyed to ensure the parameters are never tempered by anyone.

This kind of event is quite popular in proof systems and privacy-enhancing protocols like Zcash, Loopring, etc. These protocols needed a trusted setup ceremony to remain foulproof, especially from an economic point of view.

Additional information on trusted setups

Since privacy-enhancing cryptographic protocols run on the data generated by the trusted setup ceremony, protecting these parameters remains key to keeping the network secure. After the parameter generation, the random values become toxic waste, which must be deleted forever. If these secrets –random values– fall into the hands of a malicious entity, they can create false proofs (in proof systems), threatening the network's integrity. In a network like Zcash, this equals creating fake coins at will, inflating its supply and crashing the entire protocol. To prevent these things from happening and to ensure the protocol performs as designed, generating proofs and verifying transactions, its trusted setup ceremony was necessary.

This need makes trusted setup ceremonies essential, as it ensures that secrets do not fall into the hands of untrusted parties. Furthermore, some trusted setups split up a secret between multiple parties. This makes it such that participants may not know anything besides the secret in their possession or may not even know what the secret is, only that they need to compute it, creating a kind of secure multi-party computation protocol. In some instances, the trusted setup may only require one participant to dispose of the secrets in their possession to secure the network.

Since parameter generation depends on different secret pieces, having at least one honest party is sufficient to prevent malicious activity. A shortcoming of this instance is that some multiparty computation protocols do not need all the pieces of the secret to generate proofs, but a minimum threshold amount. This challenge is easily countered when the participants are selected randomly within a large distributed set and when participants do not know one another (participation in anonymity).

Categories of trusted setups

There are several routes through which a trusted setup may run to achieve its desired result.

Trusted setups, in fact, have multiple phases. The setup phase is done only once, thereby enabling the main phase. Once the main phase is activated, this enables all participating parties to interact with a single trusted part repeatedly. Individuals send inputs to the trusted party, which’s job is to run certain functions, after which the trusted party sends the corresponding output to the respective particpating parties.

The main phase is usually repeated. This scenario assumes that all communication channels between individuals and trusted party are secure. Based on the different dynamics that can take place at this time, a typical trusted setup should fit into one of the following categories:

No setup

Ironically, the first category of trusted setups is “none at all”. A protocol without a setup phase is easier to trust than those that rely on trusted setups, although it cannot provide features such as privacy. In a protocol with no trusted setup, there are no trusted entities. Instead, we assume that there communication between the parties involved.

There are two significant varieties of 'no setup' protocols:

The first is called an anonymous channel model, which assumes that the parties communicating are unknown entities. In contrast, the second draws relevance from the knowledge of the global identities of all participants. While the first type may not be readily acceptable in real-world applications, the second is, as it helps establish some measure of trust. It is easier to know whether to trust a protocol when you know the parties responsible for keeping it running.

Although it is easier to trust protocols without trusted setups, several limitations are associated with the “no setup” category, such as likeliness of man-in-the-middle attacks due to their non-authenticated communication channels.

Pairwise setups

While the “no setup” category suffers from non-authenticated communication channels, pairwise setups assume that the communication channels between any two of the set of initial parties are secure. The members of the initial set of parties are grouped in twos, with each pair having a secure line of communication.

For example, when Member-1 sends a message on the (1,2) channel, Member-2, who is the message's recipient, knows it came from Member-1 because they are the only two parties that share the channel. Depending on some conditions, this setup may fail, while with the right conditions, it can permit the full implementation of different functionalities, such as contract signing, secret exchange, joint coin flipping, voting, and playing poker.

.

Broadcast setups

The broadcast setup category of trusted setups assumes a phase without secrets. Instead of secrets being split up and distributed across participants, the trusted entity chooses to be transparent by distributing all important components across all participants, making them public.

A typical example of a trusted setup in the broadcast category is seen in public key infrastructure (PKI) protocols. In a typical PKI scenario, a trusted entity broadcasts all the public key addresses of all parties to the public. Also, all the inputs and outputs received or sent are public knowledge, including its random common reference string. With broadcast setups, it is assumed that the protocol's security is not at risk, even if the trusted entity has to be transparent.

With public key infrastructure and broadcast setups, the chances of the protocol's ability to keep running even if some parties are compromised increase significantly. This process is relatively simple, and broadcast setups are less prone to computational attacks. However, a trusted entity distributing different keys to different parties may lead to the failure of a broadcast setup.

Partially public setups

In a partially public setup, some parts of the process are made public, like in broadcast setups, while others are withheld (deleted or kept a secret), like in a regular trusted setup. In this arrangement, the output from the trusted entity is made public, while the inputs from participants and the random values generated at the initial phase are kept secret. The partially public setup is also known as the Common Reference String model.

For example, the trusted entity may trigger a function that generates an encryption key pair and a puzzle that shields half of the key pair until a set time. Then, it sends the puzzle out to all parties with the other half of the encryption key pair. Since trusted setups are two-phase procedures, the second phase will see users encrypting their messages using the other half of the encryption key pair. Users will also subsequently broadcast the encrypted messages while trying to solve the puzzle to access all encrypted messages.

Partially public setups have been used to develop verifiable secret sharing models and zero-knowledge protocols, while a fully-private setup usually requires a trusted setup ceremony for efficiency.

Fully private setups

A fully private setup represents the ideal trusted setup structure, where even the generated output that the parties receive after computing is kept secret. Hence, either party is oblivious of what they have received. Therefore, trusted setups required for blockchain networks or protocols using zero-knowledge technology fall under fully-private setups.

Fully private setups are often known as “the offline phase”, as MPC (Multi-party computation) protocols usually have an offline and online phase.

To understand how fully private setups work, we must consider two foremost cryptographic setups that fit into this category: offline phases for MPCs and distributed key generation setups for threshold signature schemes. The offline phase of a typical secure multiparty computation protocol is usually private, as the output needs to remain secret to curtail malicious operations and maintain security.

Distributed key generation setups come in handy for threshold signature schemes, which do not require all inputs to produce the already-generated secret, but a minimum number of the involved parties. This involves random bits of the input and a key pair, where one part of the key pair is distributed to all parties, while the other part is split into shares and distributed, with each participant required to keep its part of the secret.

Alternatives to trusted setups

The emergence of Bitcoin and blockchain technology has already established a fact that we do not have to depend on an individual, institution, or third-party for a network or payment system to function. Trustless systems are the need of the hour and, as we have witnessed in the past decade, these systems are getting more robust and versatile.

It’s worth noting that ZK-technology is still in its infancy and, until now, trusted setups were the most secure way to establish initial parameters for recursive proof systems. However, the need to look beyond building systems that rely on trusted setups cannot be avoided.

Some categories of trusted setups do not support decentralization, while others are prone to computational attacks. Whatever seeks to replace trusted setups must ensure proof generation and verification without the trusted setup is possible, without sacrificing speed or performance.

Some protocols use multiple setups that generate several common reference strings (CRSs), assuming that they generate a percentage of these reference strings genuinely. With several CRSs in the mix, the protocol can eliminate the need for a single trusted setup. Also, the 'no setup' phase is an alternative, along with collision-resistant hash functions, employed by zkSTARK technology.

Notably, a trusted setup phase is only done once, and a protocol has to run on the parameters generated on its existing setup until there’s a need to revise its initial parameters. If they fail, a new ceremony is to be conducted. The idea of running a current system on dated parameters may be risky, security-wise. An alternative approach is to adopt continual setup phases that keep updating their common reference string such that the setup phase remains current with the protocol's state.

Finally, a breakthrough emerged when Sean Bowe, Jack Grigg, and Daira Hopwood published a paper called Recursive Proof Composition without a Trusted Setup. This paper obtained and implemented Halo, the first practical example of recursive proof

composition without a trusted setup.

It’s worth noting that in May of 2022, Zcash started using the Halo 2 proving system, thereby removing the need for trusted setup ceremonies. Halo 2 is a fast zero-knowledge proof-carrying data implementation which doesn’t require a trusted setup.

Besides Halo, there’s also work being done to run on-chain trusted setup ceremonies without going through all the complexities of the traditional form of trusted setup ceremonies. One of them, known as a powers-of-tau ceremony, this kind of ceremony leverages smart contracts on Ethereum to allow anyone to run such a ceremony.

Some of the protocols that used powers-of-tau setup to run their own ceremonies include ZK-rollup networks such as Hermes Network, Loopring, Aztec, and zkSync. However, power-of-tau ceremony come with their own set of limitations, such as allowing only up to 64KB of cryptographic parameter size. This limitation of size is due to on-chain data constraints, thereby, only limiting its applications to only small parameters.

Conclusion

Trusted setups are integral to the structure and operations of several cryptographic protocols and distributed technologies today. As their name suggests, they are heavily dependent on the honesty of the participants, which poses a risk to the security of the networks running on them.

With the rising pace of innovations in cryptography and most-importantly in ZK-technology, new models are being proposed to do away with the need for generating parameters with trusted setups as we used to know them. Thanks to these new methods, cryptogaphic projects can finally say goodbye to conventional trusted setup ceremonies and achieve the same results on-chain using the fully decentralized Ethereum network.

About Panther

Panther is a decentralized protocol that enables interoperable privacy in DeFi using zero-knowledge proofs.

Users can mint fully-collateralized, composable tokens called zAssets, which can be used to execute private, trusted DeFi transactions across multiple blockchains.

Panther helps investors protect their personal financial data and trading strategies, and provides financial institutions with a clear path to compliantly participate in DeFi.

Stay connected: Telegram | Twitter | LinkedIn | Website

Share this article on: