fastpay

2022-04-06 ยท 4 min read

  • Date: 2020-11-03

  • Paper: https://arxiv.org/pdf/2003.11506.pdf

  • Authors: Mathieu, George, and Alberto (prev. colleagues)

  • can be used standalone or as a sidechain (well, secondary system since FP is not a blockchain)

  • when used as a secondary, assume there is some nice, consistent primary system (like a blockchain, probably distributed, but maybe slow).

  • unlike standard blockchains which use BFT Consensus, FP uses BFT Consistent Broadcast which is faster and simpler to implement (but obv. doesn't provide the full range of benefits as BFT Consensus).

state #

authorities #

  • name
  • keys
  • comittee information
  • accounts information
  • last primary tx index. See: user funding FP account.
    • For tailing funding txns on the primary system FP smart contract.

accounts #

  • verification key
  • balance
  • sequence number
  • last transfer order
  • list of certificates and synchronization orders

clients #

Clients need some persistent state:

  • account address
  • secret key
  • comittee information
  • last sequence number
  • last signed transfer order

payment flow #

Three entities:

  1. Sender
  2. Receiver
  3. Comittee

Flow:

  1. Sender -> broadcast -> Committee: signed transfer order to Receiver
  2. Committee: verify statement (balance exists, sig checks, seqnum checks, etc...)
  3. Each Committee Member -> respond -> Sender: counter-signed transfer order certificate
  4. Sender: now have at least 2f+1 signed transfer order certificates.
  5. At least one of:
    1. Sender -> broadcast -> Committee: aggregate STO certificate
    2. Sender -> Receiver -> broadcast -> Committee: aggregate STO certificates
  6. Committee: observe and verify aggregate STO certificate, update account balances, increment sender seqnum, etc...

sharding #

  • The last update-account step, (6.), can be implemented in a sharded way for horizontal scalability.
  • A single FastPay committee member can shard its user accounts across multiple machines (all in the same trust boundary).
  • (1.) Sender connects to shard responsible for their account (how?)
  • (6.) When Receiver account lives on a separate shard, we need a single cross-shard txn that just says payment is finalized and Receiver needs balance increased.

interfacing with primary system #

  • When we're in the primary/secondary system model, Committee runs a smart contract on the primary system for users:
    1. to get money into/out of the FP secondary
    2. obtain recent Committee info (pubkeys, network addrs)
    3. read total funds in system
    4. read last primary tx index (?)
    5. read redeem log (?)

user funding FP account (primary -> secondary) #

  1. User sends funding txn to FP Smart Contract on primary system (totally ordered).
  2. Committee members read all funding txns made to FP Smart Contract since last_primary_txn_index (so we don't accidentally replay or forget some funding txns).
    1. For each funding txn: add money to corresponding user balance in FP system.

user redeem FP account (secondary -> primary) #

Sender user needs to execute a redeem operation in FP, which is similar to transfer op:

  1. Sender -> broadcast -> Committee: redeem balance request to address on primary system. This locks the account.
  2. Committee: verify statement (balance exists, sig checks, seqnum checks, etc...)
  3. Each Committee Member -> respond -> Sender: counter-signed transfer order certificate
  4. Sender: now have at least 2f+1 signed redeem order certificates.
  5. Sender -> broadcast -> Committee: aggregate SRO certificate
  6. Committee: observe and verify aggregate SRO certificate, update account balance, increment seqnum, etc.... Then unlock the account.
  7. Sender -> primary system -> FP Smart Contract: post aggregate SRO certificate
  8. FP Smart Contract: verify certificate and send some of FP Smart Contract balance to user address.
  • What if Sender only posts primary on-chain redeem txn w/o notifying Committee?
    • FP account is locked until they notify.
    • If they only notify subset of Committee, they still won't be able to spend in the future unless they notify Quorum majority (2f+1) members.
  • What if Sender posts primary on-chain redeem txn multiple times?
    • Redeem log tracks every FP users' last redeemed seqnum to prevent double spend.
    • Requires O(N) smart contract state where N is number of FP users : (

implementation #

Original: novifinancial/fastpay

  • Rust
  • Tokio + UDP
    • UDP for min. latency
    • All messages are idempotent so can always safely retry
    • All messages designed to fit in one UDP frame

issues / further work #

  • checkpointing?
    • not clear how to accomplish without some kind of agreement.
  • reconfiguration / changing committee?
    • not clear how to accomplish with just BFT Consistent Broadcast.
    • probably need to use FP Smart Contract.
  • privacy?
    • Is it possible to have sender/receiver privacy?
    • Is it possible to have value privacy?
    • See: zef ZK payments protocol (todo: link)