hdevalence
commented
2 years ago Having both the view service and the custody service in the same browser extension could let us build a Penumbra-specific version of the "connect wallet" flow users in other ecosystems are accustomed to:
- access to the view service could be granted by the user with a "Connect Wallet (Read-Only)" prompt;
- access to the custody service would go through the extension's authorization UI, as normal.
Then, for instance, a DEX dashboard or a block explorer could request access to the user's view service, allowing it to query their private state.
In the future, we might also want to explore how invasive of a change it would be to build the wallet logic without access to any of the viewing keys (FVK/IVK/OVK), so that we could not even give viewing keys to the web content, and allow users to more meaningfully "revoke" access (whereas in the current threat model, the web content has access to viewing keys, so if it were malicious, it could compromise privacy).
mikedotexe
This issue is about designing the software architecture that will enable web-based wallets or other applications that interact with Penumbra.
Goals
We want to be able to support a wide variety of interfaces to Penumbra.
While it's important that there be at least one first-class wallet experience at launch, Penumbra's capabilities are multifaceted, and users will probably be best served by specialized interfaces: e.g., one for basic transfers or swaps, one for governance, one for power users to manage liquidity or examine the liquidity graph, etc.
Supporting a wide variety of interfaces is also important for decentralization: no one entity should "own" the Penumbra userbase via control of a single frontend, or be at risk of becoming a chokepoint for control of those users. This also means that it should be possible to build frontend interfaces to Penumbra that do not require custom backend infrastructure beyond an ordinary
pdfull node.We want those interfaces to be as easy to build as interfaces to transparent chains.
Historically, interfaces to shielded chains have been more difficult to build than interfaces to transparent chains, because they require the application developer to manage synchronization of users' private state, unlike a transparent chain, where user state is accessible via RPC. Penumbra is about privacy without compromise, so we want to make it as easy to build those interfaces for Penumbra as it is for a shielded chain.
We want our users to have security when interacting with those interfaces.
In order for users to benefit from the availability of a wide variety of third-party interfaces, users need to be confident they can use them without risk of losing funds or being hacked. We need to ensure that only the user can authorize a transaction, and be able to understand exactly what actions they're authorizing when they do so.
Structure
We've already been prototyping a modular client architecture in
pclisince April, so we have a good idea of how a Penumbra client decomposes into components with different levels of capability, and how those components interact with each other and with the network:The client decomposes into three components: the custody service, which holds spending keys and is responsible for transaction authorization, the view service, which holds viewing keys and is responsible for syncing the private chain state, and the wallet logic itself, which queries:
pdfull node (using the oblivious or specific gRPC protocols) for public chain state, or a grpc proxy to Tendermint for transaction submission;atendermintinstance (using Tendermint's JSON-RPC endpoint) to broadcast transactions.(Later, we plan to simplify this in #1232, allowing clients to use gRPC to submit transactions, so they only have to communicate with a singlepdendpoint).How do these components fit into a web interface, given the goals above?
We need to isolate the spending keys, and thus the custody service, from any web content. This is important for two reasons: first, compromised or malicious web content should not be able to access spending keys, and second, the signing interface needs to display details on a secure path, so that compromised or malicious web content cannot phish users by pretending to sign one transaction while actually signing a different one.
The scanning and synchronization performed by the view service should ideally be done once per device, rather than being duplicated across every interface.
The first point requires that the custody service be implemented in a browser extension. Then spending keys would stay inside the extension, and the extension could display its own UI to the user to authorize signing, showing the details of the
TransactionPlan. The second point suggests that it would be better if that extension also provided the view service. Then the extension could do scanning and synchronization once, save the resulting data, and allow web content to query it.The resulting architecture looks like this:
Design Questions
pdfull node? What is required to use gRPC from inside of a browser, and what changes do we need to make on thepdside to enable web pages to make gRPC queries?grpc-webis a workaround that uses a special proxy.tonic-webis the Tonic library for grpc-web support. Can we make thepdgRPC endpoints speak both normal gRPC as well as grpc-web simultaneously?grpc-webtopd.