Replies: 5 comments 6 replies
-
|
We'd like to open this discussion up to the community, to seek a range of views, and give people a chance to raise points we haven't considered. Is it too risky to shift the ceremony to a community-run project? Or is it a no-brainer? We'd also welcome comments on how the ceremony should continue: Should we consider expanding it to other curves? |
Beta Was this translation helpful? Give feedback.
-
|
An interesting idea. I love what you're doing with the operation. It's great to have a centralized place where to get decent trusted setups done. Doing them properly is a major hassle for any smaller project. Thanks for this! Would it be possible to decentralize the operation somewhat? Add another entity (and later more) that holds (part of?) the required data and helps share the load. In the best case, one entity dropping off wouldn't matter much. This probably requires a lot more work, and I understand this may not be feasible at this point. Or maybe a round-robin of sorts - the entity running the operation is chosen half-randomly from a pool of operators. As you mentioned, accepting invalid contributions is the biggest risk in a trusted setup. Is it possible for a random operator to allow invalid contributions, without anyone noticing? Is it possible to build the system so that this kind of contributions aren't possible? Excluding collusion of all participants with their toxic waste. |
Beta Was this translation helpful? Give feedback.
-
|
See notes on verification below. t;dr - it's easy. Thanks for your suggestions. |
Beta Was this translation helpful? Give feedback.
-
Is it easy to back it up to IPFS as well? It should just be one API call and I'm sure folks in the community would step up to help pin.
Overall, in the current state, it seems hard to even verify that an invalid transition of the ceremony has occurred. One way to ensure decentralization proceeds smoothly is to require proofs of valid transitions, i.e. updates should include i.e. a zk proof that the user knows a valid discrete log (i.e. the toxic waste) that corresponds to the right updates. There's one example here. You can use a transparent, trusted setup-free snark like zkboo to prove this update. I don't really see how you can decentralize without this step, or else it seems we put massive trust in each new coordinator (I guess we already put trust in current coordinators and even contributors). |
Beta Was this translation helpful? Give feedback.
-
|
IPFS is easy enough, but torrent sharing seemed to have some advantages. It works even with partial files, and there are plenty of clients to choose from. We'd welcome more seeders, especially for the most critical files. The ceremony does have a public key submitted with each contribution. It can be verified using pairing checks, so it's easy and strong. The implementation in snarkjs is here. So, the coordinator doesn't need too much trust. Tampering is easily detected. Censorship is not so easy, but could be called out using social media. |
Beta Was this translation helpful? Give feedback.
-
|
@glamperd Do you consider the history files to be the most critical? Maybe history and the last contribution? |
Beta Was this translation helpful? Give feedback.
-
|
The critical ones are the last contribution and the history of private keys (i.e. the |
Beta Was this translation helpful? Give feedback.
-
|
How many people are seeding? |
Beta Was this translation helpful? Give feedback.
-
|
2 or 3 :( |
Beta Was this translation helpful? Give feedback.
-
|
If I understand right, it's now decided that PSE will not manage this repo/resource anymore? After the sunset announcement: https://pse-team.notion.site/A-new-era-for-PSE-f4cde2e1a20d49ed92071a93ad8ba7df Where/how will it be communicated how this project can be continued by some other entity? Can any entity just come forward and suggest continuing this by themselves? |
Beta Was this translation helpful? Give feedback.
-
|
There has been no decision that the repo & ceremony won't be managed by PSE any more. The organisational changes in PSE mean that the Trusted Setup team will no longer continue, and that has been the group that has run the ceremony in recent times. The repo & data will continue to be maintained as PSE resources for the time being. |
Beta Was this translation helpful? Give feedback.
-
Perpetual Powers of Tau - Exit to Community
This document discusses a possible path to an “Exit to Community” for the Perpetual Powers of Tau. No decision has been made to date that such an action is planned. This discussion should be considered an exploration of how such a move ought to be structured, along with its risks and opportunities.
Ceremony Operations
PSE’s Role
PSE is expected to provide competent oversight of the archive, to vet new contributions, and to avoid censorship.
Risks
Let’s consider some of the worst possibilities. These outcomes, regardless of the organisational structure of the ceremony, would be considered a failure.
Allowing Invalid Contribution
A serious breach of the ceremony’s security would result if an invalid contribution were accepted and presented as if it were valid. A variation on this would include tampering with the historical records.
The records presented by the Github repo are trusted by the community of users. In particular, the data files shown to be the latest is expected to have the most entropy, and to be the tip of a chain of verifiably valid contributions.
A mitigation is that any project using the data, and with significant value at stake, should perform their own verification, including confirming that the chain is valid and the data file they retrieve is self-consistent.
Loss of Data
Some of the data files we maintain are reproducible from other data, only at the cost of time and computing resources. There is redundancy between compressed (response) files and uncompressed (challenge) files. Prepared phase 2 files can always be regenerated from contribution files. Contribution files cannot be reproduced, even if the public keys are known. We expect contributors to destroy their secret (toxic waste) once their contribution is complete. That secret is required to reproduce a contribution, so this avenue is not available.
The latest contribution file is required to build a new contribution. Should that data be lost, we would restart the chain from a prior state for which we have data. The loss of entropy would be unfortunate, but not catastrophic.
The history of public keys for all contribution is also necessary, as this provides proof against interference with the chain of contributions.
We therefore focus our priorities on retaining the latest data file, the public key history, and a selection of past data files that could serve as recovery points.
The AWS S3 storage bucket provided and administered by PSE serves as the primary storage location. It is also a single point of failure. A previous data loss incident happened due to changes in personal and in devops practise. Whilst there is more awareness of the issue now, it is vulnerable to such changes.
As a backup we have a torrent sharing network. Currently, this is effectively a PSE-only operation, although other parties have taken an interest.
Exit to Community
The ceremony requires a structure that will replace all functions currently being provided by PSE with members drawn from the wider community. Funding of the resources used by the ceremony would need to be replaced from other sources.
DAO
Administration of the PPoT ceremony needs a high level of transparency and integrity. A DAO provides the organisational structure to best achieve this goal.
The DAO will need a legal counterpart, an incorporated entity operating as a non-profit organisation, in order to register for an AWS account, etc. The DAO will also need to control a fiat bank account, and accounts for GitHub, and social media (e.g. Twitter, Farcaster) for communication of updates.
The DAO would operate by authorising individuals to operate the accounts, pay routine small bills. Verification of contributions could be done by anyone (or multiple individuals), and proposed as a PR in the repo, whereupon others vet the results and approve.
DAO proposals would cover:
Membership admission criteria should be tailored to discourage appearances of partiality. I’d suggest that past contributors be invited to join and form the governance group.
Costs
Routine costs for the PPoT ceremony:
These cost amount to around US$200 per month.
The “Prepare Phase 2 files” task is estimated to cost around $2000 in EC2 costs. This could be done once or twice per year if funds allow.
Funding
We could expect the DAO to receive funds from such sources as:
This assumes that individuals performing coordination tasks give their time voluntarily, or with the approval of their employer.
Some situations need special attention:
The initial transfer of data from PSE servers to the DAO’s account will entail data access costs for the entire archive.
This could cost up to $500 for 5Tb of data we currently hold. We can avoid this if it’s transferred to another S3 bucket in the same zone.
Should the DAO fail to pay its AWS bills, either through lack of funds or administrative failure, the data might be lost from its primary storage site. This should be avoided at all costs. We possibly need a ‘funder of last resort’ agreement in place with the EF.
WIll this succeed?
We have some tangible evidence of continued community interest in the ceremony, including:
Success of the above proposal would depend on converting this interest into a willingness to participate in and fund the ceremony. Requests for contribution often come from projects that are about to run a ceremony for their circuits. There is no better defence against collusion than providing your own entropy in your own environment. Such projects are willing to put the time into making a contribution, so we can reasonably hope for contributions from them. It's not a trivial task, but much easier than setting up a ceremony of their own. I expect that the web3 community has sufficient awareness of the PPoT project and the importance of the security it provides to muster the modest funds required.
A counterbalancing factor is that trusted setups are becoming less prominent as proof systems that don’t require them are developed. However, the ceremony still provides a basis for universal trusted setups, a requirement for some current proof systems and for KZG-commitments, which seem to be retaining prominence. Groth-16 remains the most cost-efficient way to submit a proof on-chain. In any case, as long as projects based on the PPoT data continue to run, the data should be maintained in order to support verification.
Beta Was this translation helpful? Give feedback.
All reactions