>For a system that is designed to be run in a consortia of highly regulated multinational corporates, all running Facebook signed code and access controlled by Facebook it simply makes no sense to deal with malicious actors at the consensus level. Why is this system designed to be byzantine tolerant at all rather than just maintaining a consistent audit log for compliance checks. The possibility that a Libra node run by Mastercard or Andressen Horrowitz would suddenly start running malicious code is such a bizarre scenario to plan for and is better solved by simply enforcing protocol integrity and through non-technical (i.e. legal) means.
Eh, I'm not so sure about that. It seems like a good feature that hackers successfully targeting a single node don't take down the whole system.
>In congressional testimony the product was stated as a challenger to emerging international payment protocols such as WeChat, Alipay and M-Pesa. Yet none of these systems are designed to run on byzantine tolerant pools of validators. They are simply designed in the traditional high-throughput bus that orders ledger transactions according to a fixed set of rules. This is the natural approach to designing a payment system. Preventing double-spends and forks is simply not an issue that a properly designed payment rails should ever have to deal with by design.
I would assume these systems are each run by a single company though, no? Which makes them fundamentally different from what Libra seems to be aiming at.
>The overhead from the consensus algorithm serves no purpose and will only limit throughput of the whole system, and appears to be there here no reason other than apparently cargo culting public blockchain technology which is not designed for this use case.
On the contrary, running byzantine fault tolerant consensus on a small number of node partners (which each submit aggregations of transactions from their clients) seems like exactly the kind of system that blockchain technology is best suited for. Not the kind of highly distributed consensus we see in e.g. bitcoin.
>A defining feature of a payment rail is the ability to reverse transaction in case payments need to be undone by legal action or if they result in accidental or system malfunction. The Libra system is designed to have “total finality” and does not include a transaction type to reverse a payment.
I don't know that this is necessary? A transaction can of course be reversed simply by making the inverse transfer. I don't know what kinds of annotations / metadata they would be storing in the ledger for audit trails, but it doesn't seem to me like a reverse transaction should be treated extra special.
Disclosure: I work for Facebook in a totally unrelated initiative (Facebook Connectivity) but have only cursorily followed Libra news in news media. I'm generally highly skeptical of cryptocurrencies, but less skeptical of distributed byzantine fault tolerant ledgers as a general technology for some niches. My comments are completely my own personal views.