Secure chain-to-solo communication verification with a Tendermint light client

michaelfig commented 3 years ago

What is the Problem Being Solved?

Ag-solos currently trust their RPC node to report on chain communication.

We would like to verify the communication by having a light client within our solo, but that necessitates making chain round trip time two blocks instead of one. It also means a client can become out-of-sync if it wasn't used recently (i.e. past the unbonding period), which requires trusting a particular block served by an RPC server to establish a trusted voting set.

Description of the Design

Consensus events

Chain-to-solo communication events need to be included in consensus, so that they can be proven by the light client.

Light client emulation

Even before we have light client, we should adjust expectations that chain-to-solo communication needs an extra block to ensure it's in the apphash:

after initial mailbox query, ask what block height it was, then stick it in the pendingVerification list for that height
for every new block, scan for mailbox events, stick them in the pendingVerification list for that height
deliver mailbox contents to the solo only after another block has passed

Light client timeout

There needs to be a way to reinitialise the solo's light client if it is unused for some time. This may be reflected in the wallet UI, say indicating a "approve RPC server" vs. "establishing trust" and "trust established" status. Deciding what the user needs to do is a hard problem for this.

Security Considerations

This won't be bulletproof security, but will at least be a "trusted on first use"-like system, where reconnecting (or first connecting) to the chain needs some kind of approval, but after that, the light client will keep up-to-date.

Test Plan

dckc commented 3 years ago

@rowgraus note in the description:

Deciding what the user needs to do is a hard problem for this.

p.s. Inspired by today's discussion of crankHash, I labelled this Risk: High as an experimental process for surfacing issues that merit product management attention. When there's consensus on what the user needs to do, the label should be removed.

rowgraus commented 3 years ago

Based on my understanding of this feature after a conversation with @dckc - the wallet warning a user after a long period of inactivity could possibly be useful in the future but isn't urgent. Suggest moving to Icebox.

dckc commented 3 years ago

We had an earlier discussion of how the market for RPC node service works. I think the closest issue is #2756.

My vague impression is that a wallet product includes RPC service for that wallet to connect to. It's not ideally decentralized, but I gather it's the state-of-the-art.

Agoric / agoric-sdk