8 ms·

The answer to the question implied in the article -- why does Libra make such unjustified design decisions -- is simple. Some people have become enamored with b

by pron 7y ago

The answer to the question implied in the article -- why does Libra make such unjustified design decisions -- is simple. Some people have become enamored with blockchain despite it having almost no good use cases, and this certainly isn't one. It seems like a classic example of focusing on the technology rather than on the problem. -- Regardless of the other, far more important sections of this article, I find the section about the programming language misleading. Programming language theory does not study the quality of programming languages or their suitability to certain tasks. It is simply outside the purview of the discipline. PLT does not have any tools whatsoever to determine which language is more or less suitable and it is not interested in that question. The theory studies the properties of formal systems and the internal implications of their design. Much like mathematics can deduce from the Peano axioms that 10 > 5, but it says absolutely nothing about whether 10 is "better" than 5 because the answer to that depends on context (are we talking cookies or tumors?) that is simply outside the purview of mathematics. Similarly, PLT can say whether a certain formal system is sound or not, but it says nothing whatsoever about whether soundness is "good", "bad" or neutral, and certainly not how good or bad it is. Of course, programming language theorists have opinions on the matter, but those opinions are not supported by the theory. Also, given the other glaring flaws, there is nothing to suggest that a formal definition of the programming language would improve matters in any perceptible way. After all, we do entrust the world's monetary system, and sometimes even our lives, to software written in programming languages that don't have a formal definition. As someone who studies the issue of software correctness, a formal definition of a programming language is certainly of interest to theorists, but it has not been shown to be a particularly worthwhile means of increasing correctness.

nradov 7y ago
The NIST has a helpful decision tree to determine whether a blockchain architecture is appropriate for your use case. https://www.nist.gov/publications/blockchain-technology-overview https://www.nist.gov/publications/blockchain-technology-over... (page 42)
- brokensegue 7y ago
  and someone turned it into a website http://doyouneedablockchain.com/#/1/0 http://doyouneedablockchain.com/#/1/0
K0SM0S 7y ago
If you may spare a minute, I'd like to know your opinion on mission-critical software in dangerous-prone contexts (such as avionics, life support, even just economically for permanently-written "ROM" software, etc). Formal methods seem required in such projects, but your final paragraph seems to imply the formalism isn't key to end quality? (my agenda, for transparency: I want to send SOC's in space on tiny RISC-V satellites, and the lowest layers of those should be 100% error-free because there's no going physically there to reboot a working shell, remote is all we have.) Regarding 'love' for blockchain, I think it's the basic proposition of "100% accurate data that cannot be controlled by anyone" that seduces. The 'cost' of that in performance becomes a nagging second concern. It gives people a feeling of safety if no other party, not their bank nor family nor employer nor anyone can alter their data, their transactions (whatever the kind, financial is but one use). Whether blockchain is the only way to achieve that is another matter, but (afaik?) so far it's the only working implementation of the concept of perfectly secured data. I think that's what drove people nuts. I also think Bitcoin or currency in general is but one use case and a very impractical one in the current financial environment, i.e. Earth circa 2019. I'd wager there are much better avenues to explore, eminently non-financial in nature, such as peer-to-peer 'free' communication, or formal (law, contracts) codification (anything official and 'forever' until 'revoked'). No coin, no market, no whatever but the benefits of a slow but 100% truthful database, for small data (text fits quite well).
- kragen 7y ago
  > (my agenda, for transparency: I want to send SOC's in space on tiny RISC-V satellites, and the lowest layers of those should be 100% error-free because there's no going physically there to reboot a working shell, remote is all we have.) Speaking from a bit of experience at Satellogic as well as folklore, trying to make the lowest levels 100% error-free isn't a good strategy. A better strategy is to make the lowest levels capable of recovering from the errors that will occur most frequently. Radiation is going to flip bits; processors are going to fail and sometimes hang; batteries are going to go low; temperatures are going to exceed specifications. If your system is built on the assumption that the lowest layers are going to be 100% error-free, you won't give sufficient attention to handling those errors when your assumption inevitably turns out to be wrong. One suggestion: include a remotely-triggerable reset sequence in a hardware state machine. A 4-bit state machine driven by 4-bit symbols will work reliably if your channel error rate is small compared to one error per 16 symbols, and it has a false positive trigger rate of 5.4 × 10⁻²⁰. (This is of course vulnerable to malicious DoS attacks if a malicious party learns the 64-bit reset code, but in practice those have historically been an enormously smaller concern than satellites failing randomly in ways that a reset switch can correct.) It's worth thinking through the fault tree of that reset mechanism. It needs to use omnidirectional antennas, for example, because otherwise it's dependent on attitude control. It needs to be on all the time, not just when you're passing over ground stations, because otherwise it depends on the clock and whatever kind of navigational system you have. It needs to be unencrypted, because otherwise it depends on your encryption protocol, which typically also involves clocks. It unavoidably depends on some kind of power source, but you can connect it directly to the solar panels and/or batteries, rather than through a switch. You probably want to use logic that can tolerate a fair bit of uncontrolled variation of the power supply voltage, not, say, TTL. But then you need like 4 flip-flops and a couple dozen gates. It can fail, but it's simple enough that you can make it highly reliable, unlike a RISC-V. So, don't think in terms of making the bottom level 100% reliable. You won't get there. Think in terms of how to prevent inevitable unreliability from snowballing, how to make the satellite resilient against inevitable damage and malfunctions, as well as reducing that bottom-level unreliability to an absolute minimum. As for blockchains, I think they're a very pragmatic solution to serious problems that are otherwise unsolvable: how can I send money to a friend in Venezuela? How can refugees carry their money safely without it being confiscated by pirates, corrupt police, or immigration authorities? How can people pay for illegal drugs without meeting in person with the vendors? How can we fund Wikileaks so they have the resources to transport Ed Snowden to safety? How can we fund Sci-Hub so that knowledge is available to everyone and not lost? Even international remittances to family members work enormously better with Bitcoin than with Western Union or SWIFT, particularly between countries with some degree of unfriendly relations. It's a similar approach to that with satellites: we know there are bad actors in the financial system, and we want to engage in transactions with them, without giving them the opportunity to sell our credit card numbers to the Russian Mafia or take all our money. We want to prevent the small amounts of inevitable unreliability from snowballing and destroying the entire civilization. Also, we want to minimize the number of attempted ripoffs, so that our defenses against them can be less costly. It turns out that thieves, unlike cosmic rays, respond to incentives, so by making thefts more difficult to pull off, we can also decrease the number of attempted thefts. Obviously I don't trust Facebook to design the world financial system, though. They elected Trump.
EGreg 7y ago
I disagree that blockchain has almost no good use cases. All a blockchain is, is a Merkle tree with a third party that ensures there is only one “main line”. That’s the use case. All the other stuff — such as having all computers in the network watch every transaction — that’s the wasteful part. There are other ways to have a set of third party validators, that is a subset of the network watching a given merkle tree, simply says which branch is correct. SAFE network uses a Kademlia DHT with various mechanisms to ensure the validators have no say in what they watch and they need to “earn” their way into having any say about anything over time. There are tons of useful properties, some of which are used in Merkle trees like git: Immutability Quick verification of tree membership using Merkle branch Ability to download different parts from different actors (Bittorent) Consensus and rule enforcement (eg chess game or any other evolving document) Smart contracts and autonomous code execution And much much more. The main problem is when people think of blockchain they think of a giant monolithic chain of blocks each of which contains ALL TRANSACTIONS IN THE NETWORK. This is wasteful. What’s even more wasteful is when you have divisibility of the tokens, leading to an exponential growth of UTXOs and unlimited storage requirements. And each full node needs to verify the entire history of every transaction because then they get intertwined. That’s the ridiculous part. And proof of work is the most wasteful thing of all. People need to get off of that!
- Tomte 7y ago
  > All a blockchain is, is a Merkle tree with a third party that ensures there is only one “main line”. No. The "wasteful part" is also part of the definition of the blockchain. Just because the word "blockchain" seems to describe only the data structure, doesn't mean that's the case. The innovation was to couple a Merkle tree with a proof-of-work system. Both existed before in standalone forms. The Merkle tree in many, many applications, the proof-of-work for example in Hashcash to combat email spam. Only the combination of both reached a level of novelty that deserved a new name. (That we still haven't found a single compelling use case is another matter.) What you mean is indeed succinctly and correctly named "Merkle tree" or "hash tree". It would have been wasteful to coin another word for it.
  - tuesdayrain 7y ago
syllable_studio 7y ago
Regarding your claim that blockchain has almost no good use cases, I see news every week which disagrees. Here is the first article I could find from just today which shows a great use case. Coca Cola is expanding their blockchain trial project to a $21 billion-a-year supply chain because they found very significant savings. https://www.coindesk.com/coca-cola-supply-chain-firm-to-expand-blockchain-effort-to-70-partners https://www.coindesk.com/coca-cola-supply-chain-firm-to-expa...
- whatshisface 7y ago
  Why would Coca-Cola need to use a block chain? They can run their own code on their own servers.
  - spir 7y ago
    Because while the core innovation of blockchain is a trusted database a context without trust, the core benefit of blockchain is reduced transaction costs. A blockchain is a singleton global computer of program code and data. It turns out this is sufficient to represent capital (money) on that computer. In practice this results in dramatically reduced transaction costs. For example you can transfer money with an API call. Another example is that an API can be "implemented with money". The https://uniswap.io/ https://uniswap.io/ API allows you to exchange currencies without any API keys or middlemen. But, the Uniswap API only works because there's a large amount of liquidity deposited by 3rd parties into its system, much like an inventory of food in a grocery store that shoppers can then access. "What's the big deal?", you might say. "Uniswap sounds just like a bank. Who cares?". Well as I understand it Uniswap was built by a dude in a basement over a few months, not a multi-million dollar bank project. And you can integrate your app with Uniswap in an afternoon. If you don't think that's going to change the world then you might consider spending a few dozen hours reading https://weekinethereumnews.com/ https://weekinethereumnews.com/ and see if your opinion is stable :)
    - pron 7y ago
      > the core benefit of blockchain is reduced transaction costs. No, this is not true. It might incidentally currently be the case with, say, Bitcoin vs. $US, but there's nothing technical that inherently makes it so. In fact, as this article and countless others reiterate, from a technical perspective blockchain is almost always more costly.
ouid 7y ago
I disagree. You're making two different arguments. The first is that PLT does not study suitability, but then you switch course and say that math analagously can define suitability for specific tasks but suitability is not (and this is my own words) a normed space. Programming language theory does not, in fact, make value judgments, but it does make statements upon which value judgments can be built given context, which contradicts your first statement.
- pron 7y ago
  I think you've misread my comment. Also, of course theory could be used to make judgment given all the necessary context, but the context, in this case, is much harder to obtain than the theory. If we knew whether a language's type system being sound is greatly positive (for some metric), slightly positive, neutral, slightly negative or greatly negative, then the knowledge that a certain language is sound or not could be valuable in making certain judgments. But PLT does not even attempt to ask that question, and it seems to be a much harder question than the ones PLT does ask. Don't get me wrong -- I think that PLT is a valuable theory, but people are often confused about what it actually studies. PLT most certainly cannot tell us whether certain language designs are desirable or not as that is not what the theory studies. It can't even tell us if certain language designs lead to more correct programs or programs that are easier to read. It does tell us that if certain typing rules are used, then, say, all types in the language can be inferred, or that a system with certain typing rules is sound.
  - ragona 7y ago
    I’m new to this space so I’m not sure how PLT is distinct from formal verification, but my view of it is that formal methods are another form of testing. Unit testing also does not guarantee that you’re testing the right things, but it’s a good way to catch issues post-compile but pre-release. Formal verification moves that so that you catch issues as part of the compilation step, which is just another tool in the general toolbox of finding errors before you ship them to your users. It’s not about proving that your spec is good, it’s about automatically generating tests that find certain types of bugs.
thesz 7y ago
>PLT does not have any tools whatsoever to determine which language is more or less suitable and it is not interested in that question. You are slightly off here. Look at [1], it views over a metric which correlates with language utility and provides 1) result of the metric applied to various languages and 2) reason why some languages can be more of utility (less errors, for example). [1] http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf

by pron 7y ago

nradov 7y ago

The NIST has a helpful decision tree to determine whether a blockchain architecture is appropriate for your use case. https://www.nist.gov/publications/blockchain-technology-overview https://www.nist.gov/publications/blockchain-technology-over... (page 42)

brokensegue 7y ago
and someone turned it into a website http://doyouneedablockchain.com/#/1/0 http://doyouneedablockchain.com/#/1/0

K0SM0S 7y ago

If you may spare a minute, I'd like to know your opinion on mission-critical software in dangerous-prone contexts (such as avionics, life support, even just economically for permanently-written "ROM" software, etc). Formal methods seem required in such projects, but your final paragraph seems to imply the formalism isn't key to end quality? (my agenda, for transparency: I want to send SOC's in space on tiny RISC-V satellites, and the lowest layers of those should be 100% error-free because there's no going physically there to reboot a working shell, remote is all we have.) Regarding 'love' for blockchain, I think it's the basic proposition of "100% accurate data that cannot be controlled by anyone" that seduces. The 'cost' of that in performance becomes a nagging second concern. It gives people a feeling of safety if no other party, not their bank nor family nor employer nor anyone can alter their data, their transactions (whatever the kind, financial is but one use). Whether blockchain is the only way to achieve that is another matter, but (afaik?) so far it's the only working implementation of the concept of perfectly secured data. I think that's what drove people nuts. I also think Bitcoin or currency in general is but one use case and a very impractical one in the current financial environment, i.e. Earth circa 2019. I'd wager there are much better avenues to explore, eminently non-financial in nature, such as peer-to-peer 'free' communication, or formal (law, contracts) codification (anything official and 'forever' until 'revoked'). No coin, no market, no whatever but the benefits of a slow but 100% truthful database, for small data (text fits quite well).

kragen 7y ago
> (my agenda, for transparency: I want to send SOC's in space on tiny RISC-V satellites, and the lowest layers of those should be 100% error-free because there's no going physically there to reboot a working shell, remote is all we have.) Speaking from a bit of experience at Satellogic as well as folklore, trying to make the lowest levels 100% error-free isn't a good strategy. A better strategy is to make the lowest levels capable of recovering from the errors that will occur most frequently. Radiation is going to flip bits; processors are going to fail and sometimes hang; batteries are going to go low; temperatures are going to exceed specifications. If your system is built on the assumption that the lowest layers are going to be 100% error-free, you won't give sufficient attention to handling those errors when your assumption inevitably turns out to be wrong. One suggestion: include a remotely-triggerable reset sequence in a hardware state machine. A 4-bit state machine driven by 4-bit symbols will work reliably if your channel error rate is small compared to one error per 16 symbols, and it has a false positive trigger rate of 5.4 × 10⁻²⁰. (This is of course vulnerable to malicious DoS attacks if a malicious party learns the 64-bit reset code, but in practice those have historically been an enormously smaller concern than satellites failing randomly in ways that a reset switch can correct.) It's worth thinking through the fault tree of that reset mechanism. It needs to use omnidirectional antennas, for example, because otherwise it's dependent on attitude control. It needs to be on all the time, not just when you're passing over ground stations, because otherwise it depends on the clock and whatever kind of navigational system you have. It needs to be unencrypted, because otherwise it depends on your encryption protocol, which typically also involves clocks. It unavoidably depends on some kind of power source, but you can connect it directly to the solar panels and/or batteries, rather than through a switch. You probably want to use logic that can tolerate a fair bit of uncontrolled variation of the power supply voltage, not, say, TTL. But then you need like 4 flip-flops and a couple dozen gates. It can fail, but it's simple enough that you can make it highly reliable, unlike a RISC-V. So, don't think in terms of making the bottom level 100% reliable. You won't get there. Think in terms of how to prevent inevitable unreliability from snowballing, how to make the satellite resilient against inevitable damage and malfunctions, as well as reducing that bottom-level unreliability to an absolute minimum. As for blockchains, I think they're a very pragmatic solution to serious problems that are otherwise unsolvable: how can I send money to a friend in Venezuela? How can refugees carry their money safely without it being confiscated by pirates, corrupt police, or immigration authorities? How can people pay for illegal drugs without meeting in person with the vendors? How can we fund Wikileaks so they have the resources to transport Ed Snowden to safety? How can we fund Sci-Hub so that knowledge is available to everyone and not lost? Even international remittances to family members work enormously better with Bitcoin than with Western Union or SWIFT, particularly between countries with some degree of unfriendly relations. It's a similar approach to that with satellites: we know there are bad actors in the financial system, and we want to engage in transactions with them, without giving them the opportunity to sell our credit card numbers to the Russian Mafia or take all our money. We want to prevent the small amounts of inevitable unreliability from snowballing and destroying the entire civilization. Also, we want to minimize the number of attempted ripoffs, so that our defenses against them can be less costly. It turns out that thieves, unlike cosmic rays, respond to incentives, so by making thefts more difficult to pull off, we can also decrease the number of attempted thefts. Obviously I don't trust Facebook to design the world financial system, though. They elected Trump.

EGreg 7y ago

I disagree that blockchain has almost no good use cases. All a blockchain is, is a Merkle tree with a third party that ensures there is only one “main line”. That’s the use case. All the other stuff — such as having all computers in the network watch every transaction — that’s the wasteful part. There are other ways to have a set of third party validators, that is a subset of the network watching a given merkle tree, simply says which branch is correct. SAFE network uses a Kademlia DHT with various mechanisms to ensure the validators have no say in what they watch and they need to “earn” their way into having any say about anything over time. There are tons of useful properties, some of which are used in Merkle trees like git: Immutability Quick verification of tree membership using Merkle branch Ability to download different parts from different actors (Bittorent) Consensus and rule enforcement (eg chess game or any other evolving document) Smart contracts and autonomous code execution And much much more. The main problem is when people think of blockchain they think of a giant monolithic chain of blocks each of which contains ALL TRANSACTIONS IN THE NETWORK. This is wasteful. What’s even more wasteful is when you have divisibility of the tokens, leading to an exponential growth of UTXOs and unlimited storage requirements. And each full node needs to verify the entire history of every transaction because then they get intertwined. That’s the ridiculous part. And proof of work is the most wasteful thing of all. People need to get off of that!

Tomte 7y ago
> All a blockchain is, is a Merkle tree with a third party that ensures there is only one “main line”. No. The "wasteful part" is also part of the definition of the blockchain. Just because the word "blockchain" seems to describe only the data structure, doesn't mean that's the case. The innovation was to couple a Merkle tree with a proof-of-work system. Both existed before in standalone forms. The Merkle tree in many, many applications, the proof-of-work for example in Hashcash to combat email spam. Only the combination of both reached a level of novelty that deserved a new name. (That we still haven't found a single compelling use case is another matter.) What you mean is indeed succinctly and correctly named "Merkle tree" or "hash tree". It would have been wasteful to coin another word for it.
- tuesdayrain 7y ago

syllable_studio 7y ago

Regarding your claim that blockchain has almost no good use cases, I see news every week which disagrees. Here is the first article I could find from just today which shows a great use case. Coca Cola is expanding their blockchain trial project to a $21 billion-a-year supply chain because they found very significant savings. https://www.coindesk.com/coca-cola-supply-chain-firm-to-expand-blockchain-effort-to-70-partners https://www.coindesk.com/coca-cola-supply-chain-firm-to-expa...

whatshisface 7y ago
Why would Coca-Cola need to use a block chain? They can run their own code on their own servers.
- spir 7y ago
  Because while the core innovation of blockchain is a trusted database a context without trust, the core benefit of blockchain is reduced transaction costs. A blockchain is a singleton global computer of program code and data. It turns out this is sufficient to represent capital (money) on that computer. In practice this results in dramatically reduced transaction costs. For example you can transfer money with an API call. Another example is that an API can be "implemented with money". The https://uniswap.io/ https://uniswap.io/ API allows you to exchange currencies without any API keys or middlemen. But, the Uniswap API only works because there's a large amount of liquidity deposited by 3rd parties into its system, much like an inventory of food in a grocery store that shoppers can then access. "What's the big deal?", you might say. "Uniswap sounds just like a bank. Who cares?". Well as I understand it Uniswap was built by a dude in a basement over a few months, not a multi-million dollar bank project. And you can integrate your app with Uniswap in an afternoon. If you don't think that's going to change the world then you might consider spending a few dozen hours reading https://weekinethereumnews.com/ https://weekinethereumnews.com/ and see if your opinion is stable :)
  - pron 7y ago
    > the core benefit of blockchain is reduced transaction costs. No, this is not true. It might incidentally currently be the case with, say, Bitcoin vs. $US, but there's nothing technical that inherently makes it so. In fact, as this article and countless others reiterate, from a technical perspective blockchain is almost always more costly.

ouid 7y ago

I disagree. You're making two different arguments. The first is that PLT does not study suitability, but then you switch course and say that math analagously can define suitability for specific tasks but suitability is not (and this is my own words) a normed space. Programming language theory does not, in fact, make value judgments, but it does make statements upon which value judgments can be built given context, which contradicts your first statement.

pron 7y ago
I think you've misread my comment. Also, of course theory could be used to make judgment given all the necessary context, but the context, in this case, is much harder to obtain than the theory. If we knew whether a language's type system being sound is greatly positive (for some metric), slightly positive, neutral, slightly negative or greatly negative, then the knowledge that a certain language is sound or not could be valuable in making certain judgments. But PLT does not even attempt to ask that question, and it seems to be a much harder question than the ones PLT does ask. Don't get me wrong -- I think that PLT is a valuable theory, but people are often confused about what it actually studies. PLT most certainly cannot tell us whether certain language designs are desirable or not as that is not what the theory studies. It can't even tell us if certain language designs lead to more correct programs or programs that are easier to read. It does tell us that if certain typing rules are used, then, say, all types in the language can be inferred, or that a system with certain typing rules is sound.
- ragona 7y ago
  I’m new to this space so I’m not sure how PLT is distinct from formal verification, but my view of it is that formal methods are another form of testing. Unit testing also does not guarantee that you’re testing the right things, but it’s a good way to catch issues post-compile but pre-release. Formal verification moves that so that you catch issues as part of the compilation step, which is just another tool in the general toolbox of finding errors before you ship them to your users. It’s not about proving that your spec is good, it’s about automatically generating tests that find certain types of bugs.

thesz 7y ago

>PLT does not have any tools whatsoever to determine which language is more or less suitable and it is not interested in that question. You are slightly off here. Look at [1], it views over a metric which correlates with language utility and provides 1) result of the metric applied to various languages and 2) reason why some languages can be more of utility (less errors, for example). [1] http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf http://www.cs.stir.ac.uk/~kjt/techreps/pdf/TR141.pdf