Deployment patterns

[leighmcculloch]

@nikhilsaraf posed the question to me recently about how payment channels might be deployed, and if we would have some sort of service that a user could deploy and use to watch the network for bad actors closing channels in old states.

I think this also raises the question of what components will a user of a payment channel likely have, or how might they want to organize monitoring, etc. Regardless of whether we build these components, or only build the building blocks for them, I think it is worthwhile we hash this out a little in parallel with the work we're doing.

There could probably be many types of deployments, so the goal of this discussion should be to capture different possible deployments so we can develop and understanding of how the SDK might be used.

cc @nikhilsaraf @acharb @accordeiro

[leighmcculloch]

I think there could be a deployment that separates the responsibilities of proposing payments, agreeing to proposals, and monitoring for safety, into three components:

1. A watcher that monitors the state of the escrow accounts on the network, has a copy of the latest agreement, and in the event an older agreement is published to the network, it submits the latest declaration transaction to ensure the latest agreement is preserved. This would be a long running service.

2. A server that receives new agreements from the other participant and signs them if the new agreements result in the participant gaining funds, and the new agreement is valid and won't break the channel. The server also shares the latest agreement with the watcher so it knows about that new state. This would be a long runner service.

3. A client that connects to the other participant's server to make payments. The client also shares the latest agreement with the watcher so it knows about the new state. This could be short-lived logic embedded in an application.

In diagram form:

Diagram source

[leighmcculloch]

I think something that becomes challenging in this model is synchronized access to the data store that the client and server use. A server and client must never sign different transactions for the same iteration. A high-throughput application could have significant contention on database locks.

[leighmcculloch]

I think there could be a deploy that embeds most responsibility into a client or daemon, although where something external can monitor for bad behavior as well. I think this is more similar to what @nikhilsaraf found elsewhere in research.

1. A watcher that monitors the state of the escrow accounts on the network, has a copy of the latest agreement, and in the event an older agreement is published to the network, it submits the latest declaration transaction to ensure the latest agreement is preserved. This would be a long running service.

2. A client that opens channels, proposes new states for the channel, and agrees to new states proposed by the other participant. This would be a long running service, always-on and persistently connected to the other participant.

In diagram form:

Diagram source

[nikhilsaraf]

I think having the watcher node/service is definitely going to play a key part. I can also see the community building this into a SaaS for anyone to sign up to be their watcher node for redundant protection.

[nikhilsaraf]

As a third option, also want to include the "mailbox" component in our list that we had discussed, which is slightly different from the watcher/client/server model. This watcher/client/mailbox pattern isn't fully applicable today with our high-throughput use-case but an important component to list since we're listing components here.

Both server and mailbox are long running services that can serve to operate as proxies for the client when client is offline, but the key difference between the server and mailbox is that the client always has to go through the mailbox to receive messages (which also gets around the synchronization in the client/server model) and the mailbox will never auto-approve payments even if the client will gain funds.

I'd like to analogize the mailbox approach to email, whereas our fast throughput approach is like IM. We are focusing on the IM case for now and when we get to the email case (low throughput) we can consider the mailbox component.

[leighmcculloch]

I like the mailbox approach as well, but CAP-21 requires a multi-step signing process on each agreement which makes mailbox problematic. For example, I can send you a payment, and you can accept it, but it isn't authorized until I send you a second follow up message finalizing it. To do a single message in either direction, like email, we'd need another change to the Stellar protocol in addition or instead of CAP-21. I've been discussing this specific limitation with @stanford-scs in Slack. I don't have a good idea yet for how we could change the protocol to make this work better like email.

[leighmcculloch]

I think we can make this deployment pattern possible if we implement this proposal: #165.

[shanzzam]

@leighmcculloch and @nikhilsaraf: now that CAP-40 is published does this mean you want to move forward designing the "mailbox" as part of the model as outlined above?

@nikhilsaraf

"This watcher/client/mailbox pattern isn't fully applicable today with our high-throughput use-case"
Can you clarify this? Do you mean this is a component we need for future use-cases but we should probably build now?

@leighmcculloch the diagram is very useful, thank you for taking the time to create that.