5 ms·

Do you have plans to have policies on accounts? I.e. you don’t know your Customer yet fully but allow some small transactions as long as your customer’s account

• jorangreef 5y ago
  Yes, we've reserved space in our Account data type for future accounting policy: https://github.com/coilhq/tigerbeetle/blob/main/src/tigerbeetle.zig#L6-L20 https://github.com/coilhq/tigerbeetle/blob/main/src/tigerbee... At present, TigerBeetle can already be used to limit debits/credits against an account to not exceed the credits/debits of the account by setting account.debits_must_not_exceed_credits = true when creating the account. This will then become an immutable policy on the account and TigerBeetle will then cap transactions to never exceed the liquidity available. If you wanted to rate limit transactions, you could create something like a "prepaid" account where you periodically top up the account, and then let transfers drain it out. Would these address something like what you were thinking? TigerBeetle also has support for something called Linked Events where you can submit a batch of either accounts, transfers or commits and where you can then chain a subset of events within this batch together by toggling a "linked" flag on each, so that these subset chains succeed or fail atomically together, much like what you can do when submitting IO through io_uring: https://github.com/coilhq/tigerbeetle/blob/main/src/tigerbeetle.zig#L56-L66 https://github.com/coilhq/tigerbeetle/blob/main/src/tigerbee... We didn't go into our accounting features too much beyond the big idea because we wanted to focus more on the technical aspects for this talk.
  • weitzj 5y ago
    I was thinking about KYC and my idea was something like: You want to promote your micropayments and therefore give your customers for example $1 as a gift and they just need an email address to sign up on your platform. Once they have $10 in their account they have to at least give you their phone number/address before they can trade more money. Now you have 12 customers sending money to customer A who has now $12 in their account. In the meantime customer A sent out $1 to somebody else. Depending on who sent, got the money first you have breached the $10 limit. And I don’t grasp how this use case can be met with double bookkeeping besides using a single synchronous ledger (or maybe virtual accounts to do reconciliation). If you now have customer A maybe in USA and customer B on another continent I am even more clueless about latency. :)
    • jorangreef 5y ago
      Thanks for the interesting example. If the goal of the policy was to prevent customer A from staying under the KYC threshold by constantly shifting received gifts elsewhere, then I think it should be possible to account for this by giving customer A two accounts, one that they receive gifts into (capped to be no more than incoming 10 credits), and one that they send from (capped to be no more than 1 outgoing debit). KYC would then be required before customer A can receive any more gifts or be transferred into a full-duplex account. Can you spot any bugs in this approach? There might also be better ways to model a chart of accounts for this scenario. And if you have any more scenarios you can imagine and send through, I would also really like to work through them to see what we can learn. Regarding latency: If payments are global, then I believe that any system would need to incur latency at some point when updating both accounts if they are homed in different jurisdictions. At this point, is your question about global cross-continent latency differences between active Paxos replication vs passive Multi-Paxos replication? Or are you more comparing the latency of a strict serializability RSM like TigerBeetle vs the latency of something like a byzantine fault tolerant payment system that uses cryptographic signing and sharding but which cannot do things like payment-versus-payment?
      • weitzj 5y ago
        I was more interested in latency of a strict serializability RSM like TigerBeetle. I was thinking that maybe my use case is maybe something which should not be solved in the ledger directly, but merely the ledger should offer an API to fulfill transactions in the ledger. And the Api consumer has to provide an idempotency key to perform the transaction . But then again I would assume that the ledger would have to provide an endpoint what the current balance is (the sum over all transactions). And when the api consumer makes a decision depending on KYC and current balance, whether to try to record a transaction on the ledger, in the meantime the balance could have changed. So maybe one could send an idempotency key and the balance which was used to decide whether to fulfil the transaction. Or a more generic version: an api consumer could send an idempotency key and a smart contract compute kernel on a transaction request. And the smart contract gets evaluated on the fly with the live data inside the ledger. I smell like I am inventing a database and SQL here. ;) Regarding: “ KYC would then be required before customer A can receive any more gifts ” Where would the validation live? Inside the ledger as a contract per customer across their accounts? When customer B tries to send money to customer A and A fails: what will customer B see? An immediate error or an asynchronous message