Trust assumptions

Trust assumptions ultimately depend on the needs of application developers building useful applications using the Pluto SDK. However, we want to be clear that we believe in progressive decentralization. Our number one objective is to create useful infrastructure for developers, but we cannot do that without a credible path towards operating the technology we create in a neutral, privacy-preserving, and censorship-resistant way.

As a result, we may start with infrastructure that has a central dependency, but only when we see clear paths towards achieving credible-neutrality in the future.

Trust assumptions for Pluto’s testnet SDKs

• Notary prevention of disclosure - We use a technology called TLS Notary to notarize the data retrieved from an internet server. This process uses multi-party computation (‘MPC’) to maintain privacy of the encryption and decryption between the server, and as a result, the notary is capable of preventing disclosure of the private communication with the server. However, for our testnet version, we have removed the selective disclosure process for performance and testing reasons. We are in the process of constructing an improved selective disclosure process, which will be incorporated by mainnet.
• False notary attestations - The TLS Notary infrastructure we rely upon uses MPC between a notary and the client retrieving the data from the web server. This process can produce incorrect data in the event that the notary and the client collude to provide incorrect data. Today, Pluto operates the notary centrally. As a result, there is no way to verify by an external party that we have not colluded with a client request. At mainnet, we will produce attestations that we’ve correctly operated the notary.
• TLS certificates - The verifier for our Web Proofs currently depends upon a published hash of the TLS Certificate for a given domain. We maintain a public list of these certificates uploaded by a central server. These are verifiable, but currently depend on us as operators to update and modify the certificates.
• Linking our open-source code to verifiable builds - We maintain a mobile SDK (and demo app) that collects user credentials via the browser for authenticated web proofs. This information is never removed from the device, will never be sent to a server, and our SDK will be open-source at launch. However, at this moment, we are not aware of a way to link the open-source software to a verifiable build on the App Store. We are investigating methods to reduce this trust assumption.
• Verification keys - The verifier for our Web Proofs currently depends upon a verification key for the ZKPs we generate. This key is verifiable using our SRS and publicly available proof generation logic, but currently depend on us as operators for placement onchain.
• Perpetual Powers of Tau - The proof generation for Web Proofs depends upon an SRS which contains trusted data. We currently use the SRS from the Perpetual Powers of Tau; this generation process was run by a neutral third party and is relied upon by key infrastructure. In the extremely rare event that every participant of the ceremony was dishonest, our proofs would be jeopardized.
• Centralized notary infrastructure - The notary infrastructure is currently centralized and notarization happens on a server operated by Pluto. This means our servers must be live to notarize requests, which means Pluto could potentially censor notarization requests. In time, we will produce attestations to the correctness of this procedure and we have ongoing workstreams to decentralize the cosigning.
• Centralized proof generation infrastructure - The proof generation infrastructure is currently centralized and generated on a server operated by Pluto. This means our servers must be live to produce proofs. Furthermore, it means Pluto could censor user proof generation. In time, this process can be decentralized.
• Ongoing development of blockchain infrastructure - We depend on blockchain infrastructure that is still developing towards credible-neutrality and censorship-resistance. Specifically, we deploy our verifier to various execution environments, like Ethereum and potentially Ethereum L2s. Ethereum is by far the most robust and censorship-resistant smart contract platform.

We will continue to research, develop, and implement further approaches for minimizing trust, decreasing attack surfaces (as it relates to privacy, trust, and censorship-resistance)

Potential future approaches and mitigations

We have mentioned many of these approaches above, and there are multiple other interesting routes to continue exploring, including:

• Client-side proving, which will continue to improve and to which we hope to contribute our own research and development
• A ‘free market’ of notaries, potentially with subsidized business models in the short-term to make them viable, to limit reliance on Pluto notary
• Integration of proving marketplaces to make proof generation less reliant on Pluto

If you’d like to work on solving these problems with us, please reach out.