Stellar Multisig Coordination Service Architecture Draft

multisig-service-arch.md

Service federation

• Each node has a key pair to authenticate itself to its peers
  • Key pair might or might not relate to a Stellar account
• Each node provides a SSE co-signature request streaming endpoint other peers or wallets may subscribe to
• When connecting to another peer
  • Subscribe to that peer's stream
  • Post a message to invite the peer to subscribe to the node's stream
• Each node exposes a list of the peers that it is connected to
• Each node has a configurable set of trusted peers, will always connect to them and accept them subscribing
• Maximum number of connections by/to untrusted peers
• Maximum number of connections by wallets (they authenticate using an account's key)
• Blacklist peers/wallets for a short time (a few minutes maybe) if they spam
  • Considered spam: submits duplicate requests, submits invalid requests

Networking within the federation

• Goal: Don't broadcast every request, but keep it simple
• When a node accepts a co-signature request, it doesn't propagate it immediately, but:
  • Collects requests over a debouncing period (100ms or so)
  • Bundles them in a bulk message
  • Signs this message
  • Propagates it via its SSE stream
• When a node receives a bulk message from a peer:
  • Check that message hasn't been processed yet
  • Check that message hasn't been signed by the receiving node yet
  • Add the receiving node's own signature to the message
  • Propagate it to subscribers

Spam Protection

• Service: Check if accounts to send request to are actually co-signers of source account before accepting a request
• Rate limit per account (max. 10 per minute per account or so)
• Reject requests that have been submitted already

See Also

• Gist: Stellar Multisig Coordination Service

Service: Check if source account has destination accounts as co-signers before accepting a request

What about transactions that are not payments? I think this service makes a lot of sense if it'd support any kind of transaction (as outlined in SEP-0007).

@andrenarchy Ahh, bad phrasing. It's not about a potential payment's destination(s), it's about the destination(s) of the co-signature request (the co-signers of the source account). Edited the gist to make that clear.