2 ms·

10 seconds is still an two orders of magnitude too slow given many use cases and the technology which is currently available. I should be able to tap my card on

10 seconds is still an two orders of magnitude too slow given many use cases and the technology which is currently available. I should be able to tap my card on a subway turnstile and have it open immediately such that the subway faces zero fraud risk. A centralized system should be limited only by RTT and there are ways to overcome even that via caching layers or cryptographic techniques. You want something sub 250ms.

desc 7y ago
It doesn't need to be centralised, and it doesn't even need to be limited by RTT. 'Zero fraud risk': you cannot prevent people from finding loopholes. Every system breaks. Instead, you use the same techniques that have been used for centuries in finance: keep audit logs, make it possible to fix things later, and maybe try to catch the majority of possible attacks by adding more rules. If you're processing tens of millions of transactions a second, you do not have a single point of truth. You have at least a cluster, ie. a distributed system. Fortunately finance grew up before automatic computing and telecoms even existed, so its algorithms and systems run just fine (FSpecificVO) at less than 1 FLOP/S with communication latencies measured in weeks. So you might as well just collect transactions locally, then sort them out as a batch job in the evening, with a percent or two price hike to cover liabilities due to fraud. Last time I went anywhere near London, they had the instant payment system working down there in the Tube. It's not centralised and none of the important stuff is necessarily low-latency, but it seems to work fine anyway.
TazeTSchnitzel 7y ago
It's usually much faster, but it depends on the particular banks. With my particular pair of banks, I get the notification from the destination bank before I see the confirmation from the origin bank!

desc 7y ago

It doesn't need to be centralised, and it doesn't even need to be limited by RTT. 'Zero fraud risk': you cannot prevent people from finding loopholes. Every system breaks. Instead, you use the same techniques that have been used for centuries in finance: keep audit logs, make it possible to fix things later, and maybe try to catch the majority of possible attacks by adding more rules. If you're processing tens of millions of transactions a second, you do not have a single point of truth. You have at least a cluster, ie. a distributed system. Fortunately finance grew up before automatic computing and telecoms even existed, so its algorithms and systems run just fine (FSpecificVO) at less than 1 FLOP/S with communication latencies measured in weeks. So you might as well just collect transactions locally, then sort them out as a batch job in the evening, with a percent or two price hike to cover liabilities due to fraud. Last time I went anywhere near London, they had the instant payment system working down there in the Tube. It's not centralised and none of the important stuff is necessarily low-latency, but it seems to work fine anyway.

TazeTSchnitzel 7y ago

It's usually much faster, but it depends on the particular banks. With my particular pair of banks, I get the notification from the destination bank before I see the confirmation from the origin bank!