Limitations and Outlook

Applied cryptography research and development is in a stage of rapid evolution and innovation, and Web Proofs are on the cutting-edge of tooling for application developers. While the speed of iteration is producing incredible work from many teams and organizations, some foundational work underpinning Web Proofs is still not fully battle-tested or optimized for performance.

Pluto’s number one objective is to create useful infrastructure for developers. In the blockchain context specifically, we must provide a credible path towards operating the software we create in a neutral, privacy-preserving, and censorship-resistant way. For the immediate future, while we battle-test, audit, and further harden the security of our core infrastructure, the Web Proofs SDK has some safeguards and trust assumptions in place, which we detail below for sake of transparency and accountability.

Pluto believes in the ongoing reduction and removal of these safeguards and trust assumptions using the tools of applied cryptography and progressive decentralization. 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

Trust assumptions ultimately depend on the needs of each individual application developers, whose applications may require different types of trade-offs depending on the specific use case. Below, we list out the major trust assumptions that our software (and other software that we rely on) introduces in the short-term.

Note that Origo Mode, TEE Mode, and MPC Mode are tools for attesting to the data provenance of internet data. In other words, these tools are different methods for creating Web Proofs. These approaches have slightly different trust assumptions, which are mentioned below.

• Centralized notary and proxy infrastructure - The infrastructure used for Origo (proxying), MPC Mode (multi-party computation), and TEEs (attestation in a trusted execution environment) is currently centralized. Our servers must be live to act as proxy or notarize requests, which means Pluto could potentially censor client requests (either purposefully or simply because hardware has gone offline).
• 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 or could effectively censor client proof generation requests.
• False notary attestations - The attestations generated by the Origo/MPC Mode protocols can be forged by Pluto, if Pluto were to collude with the client to attest to ‘false’ data (data that was not actually provided by the server, but which Pluto attested to). As a result, there is currently no way to verify to an external party that Pluto has not colluded with a client request.
• TLS certificates - The onchain verifier for 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 - When using authenticated data proofs, our SDK collects user credentials via mobile browser. This information is never removed from the device and will never be sent to a server. 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.
• Trusted hardware in TEE Mode - TEEs are built on two critical trust assumptions. First, users must trust that hardware manufacturers have implemented the technology with integrity — in other words, users must trust that there are no hidden backdoors in the system. Second, users need to trust that the hardware’s security mechanisms can effectively resist both physical tampering and side-channel attacks. While these assumptions may be acceptable for some use cases, they might give pause to users handling particularly sensitive or high-value operations.

We will continue to research, develop, and implement further approaches for minimizing trust in our Web Proofs infrastructure.

Future outlook

We have mentioned some approaches to mitigating these trust assumptions above, and there are multiple other interesting routes to continue exploring, including:

• Further development of our client-side proving stack, 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 the Pluto notary in the MPC Mode case
• Integration of proving marketplaces to make proof generation less reliant on Pluto
• Reproducible builds and transparent verification for workloads running inside a TEE

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