4 ms·

Does anyone else feel like replacing all the legacy finance infrastructure with decentralised code is going to produce a worrying number of stories like this? M

Does anyone else feel like replacing all the legacy finance infrastructure with decentralised code is going to produce a worrying number of stories like this? Most of the examples I've seen so far it's happening to someone who works in tech, has disposable income, and is generally a proponent of cryptocurrency. I haven't written a lot of decentralised code in production, but I get the impression there is generally more to consider, and a fun new class of failure modes to worry about.

dnautics 5y ago
How would exactly the same argument not be applicable to any sort of public code repo?
- deleted 5y ago
  [deleted]
jollybean 5y ago
It's worse than that. Contracts are not code. It's a complete misunderstanding to posit them as such. Contracts depend first and foremost upon the legal regime in which they are valid. Every jurisdiction has rules, precedence, language means specific things. There is quite a bit of variability in this stuff, which is why we have lawyers. And Judges. Putting a contract into a crypto ... is basically pointless. There's possibly more transparency, akin to publishing contracts on the web or something like that. And of course, there is a 'narrow range of agreement possibilities' that could take place on crypto contracts, for example, things like stock options etc.. But generally speaking, even the contract cryptos are 'technologies looking for application'. We don't want to 'nay say' new, dreamy ideas, but these new dreamy ideas, combined with a bit of hubris, arrogance, greed, lack of self awareness can create problems.
- crooked-v 5y ago
  The most obvious example for 'contracts are not code': the most airtight contract in the world can get quickly voided in court if it turns out one of the parties was actually a minor at the time of signing, even if they hid that fact or didn't actually know it.
  - fogihujy 5y ago
    This. The foremost example being EULA's and warranties in countries where the law gives consumers far more rights than the copy/paste legalese texts that everyone accepts at installation/purchase.
- TeMPOraL 5y ago
  > Contracts depend first and foremost upon the legal regime in which they are valid. Every jurisdiction has rules, precedence, language means specific things. One could counter that no code ever stands alone, but is executed in terms of some runtime. But I think I can bolster your point with two further thoughts: 1. Contracts are not meant to be code. The process of drafting a contract helps people arrive at a common understanding - a shared consensus, a "meeting of the minds" - and once signed, it then documents that understanding along with relevant context sufficient for third parties to be able to recreate that common understanding. The contract is not executable - it, at best, is a declarative description of some of the outcomes. The actual execution is handled independently by the parties that entered the contract. The contract only exists so that common understanding can be preserved through time and shared with other people - whether it's because some party forgot the details, or it needs to be modified, or third parties (like lawyers, judges or arbitrators) need to be involved in dispute resolution. 2. To the extent a contract contains anything resembling executable code - say, the aforementioned declarative descriptions of outcomes, or imperative descriptions of specific behavior, or some attachments with deliverable specifications, etc. - these are all expressed in a very high-level programming language, i.e. natural language. This "code" is ultimately "executed" by sapient human beings. In other words, the programming language and runtime in questions are GAI-complete: that is, coding them up from scratch, e.g. to enable "smart" contracts to be comparable in utility to regular ones, would be equivalent to creating a human-level general-purpose artificial intelligence. We're not anywhere close to achieve that, thus by definition, "smart" contracts are too dumb to make sense when we can use the normal ones.
coryrc 5y ago
No, because I expect it to implode well before "all" gets replaced!
jacoblambda 5y ago
I think the big issue is using tools without verification infrastructure. Of course there are specification level bugs to deal with but hacks seem to be oh so often the simple "I forgot to initialise a variable" kind of attacks. I think we really need to be splitting up code for smart contracts into 3 classes: - Low Complexity, Automated Assurance: Non-turing complete DSLs that allow you to fully reason about their behaviour and catch bugs in a near completely automated manner. The only one of these that I know of at the moment is Marlowe however I'd love to know if more existed. This class should be easily accessible by finance people and should be near impossible to get wrong. - Medium Complexity, Semi-automated Assurance: These are tools that are expressive and more code than contract however they may or may not be turing complete. These can catch a wide number of bug classes but may need manual intervention (annotations or proofs) to cover the last mile. - High Complexity, Manual Assurance: The are tools that give you the full power of a turing complete language and all the landmines that come with them. I personally believe any smart contract written with one of these tools should not be used in production unless it is accompanied with a formal specification and an end to end set of proofs verifying correctness. At least with this model you can judge the risk factor by how complex your application is. 90% of smart contracts probably fall into the first class and another 9% probably fall into the second. There really is no reason to be using a tool without any reasonable amount of assurances provided unless your project is extraordinarily complex (and even then it'd probably cost a fortune to run on a network) and even then there's no reason for these smart contracts to exist without any proofs backing them.
- Paradigma11 5y ago
  There are some interesting projects on Tezos in this regard: https://archetype-lang.org/ https://archetype-lang.org/ is a non-turing complete dsl that you can run http://why3.lri.fr/ http://why3.lri.fr/ proofs on. Another way is to run proofs on the michelson that was generated by a higher level language (https://ligolang.org/ https://ligolang.org/, https://hackage.haskell.org/package/morley https://hackage.haskell.org/package/morley ...) with: https://gitlab.com/nomadic-labs/mi-cho-coq https://gitlab.com/nomadic-labs/mi-cho-coq The most interesting project (still alpha i think) to me is: https://juvix.org/ https://juvix.org/ a rather elegant dependently typed language.
cfcosta 5y ago
I'd say this is a problem of a really new tech, with the advanced attack vectors and methodologies we have nowadays. Thankfully, other cryptos (such as Cardano) are building their smart contract platform with correctness/security in mind (compiler checks and so on), so we might see less problems like this.
arp242 5y ago
> Does anyone else feel like replacing all the legacy finance infrastructure with decentralised code is going to produce a worrying number of stories like this? And stuff like "I lost £95,000 in a bank scam after my solicitor's email was hacked".[1] She managed to recover £57k after , but still lost £35k, not an insubstantial amount! If anything, we need more protection against stuff like this. Sending money to the wrong account because your solicitor's email account was compromised is something that can happen to anyone, especially if it's someone you've been in regular contact with. It seems the systems for dealing with fraud in the current banking system is already inadequate (although there is now a new "voluntary code" according to the article, no idea how well this works in practice), and for crypto it's woefully so. [1]: https://www.theguardian.com/money/2020/feb/29/bank-scam-solicitors-email-hacked https://www.theguardian.com/money/2020/feb/29/bank-scam-soli...
- Dayshine 5y ago
  This is before the recent change in bank transfers that requires account name to match account number right? My understanding was that change basically closes the majority of these scams (where the account details are substituted) as you would now need to create an account with a name you don't have ID for which is very very hard.
  - arp242 5y ago
    Yeah, you're correct. As for how this actually pans out in practice: I don't know. I'd guess that having people also fill in a name isn't impossible either, although it certainly makes it a lot harder.
ryanmarsh 5y ago
Even as a crypto maximalist I believe code can create tyrannies of it's own kind. Take the example a story posted on HN some time ago of code Hertz wrote reporting cars not turned in as stolen and getting people (unfairly) arrested. If I call my bank, they can fix a mistake, no matter how bad, because they own "truth". I think what will end up happing is every contract will have the ability for some authorized key to make arbitrary movements of tokens amongst custodial accounts and nobody will build contracts where anything is moved out of custodial accounts until there's been multiple authorizations. Sort of how I transfer money into Gemini, I don't just trade from my personal checking account and they won't transfer to my checking without some authorizations. Look, I know I'm not being sophisticated here, I'm just saying, you need a way of un-fucking a fuckup and if someone can abscond with tokens easily because of a small logic flaw that doesn't work writ large.
- Daishiman 5y ago
  So then why even bother with DeFi when what you're doing is just relaying trust back to a centralised human party? It's just regular finance with extra steps.
  - intotheabyss 5y ago
    Except it's not at all. You can take synthetic TSLA shares and deposit those as collateral to mint stablecoins as a loan. Where else can you do that from your web browser at 10am on a Sunday and confirmed in 30 seconds?
    - Daishiman 5y ago
      Clearly the demand for this isn't exactly as important as anyone claims given the abject failure of the microloans industry to pan out. The problem with loans generally isn't that you can have one at 10Am on a Sunday morning.
      - ryanmarsh 5y ago
        I've always thought the retail lending side of DeFi was silly. The risk is too high. Screenshot this, mortgage backed securities will be the first major success of blockchain debt based products.

dnautics 5y ago

How would exactly the same argument not be applicable to any sort of public code repo?

deleted 5y ago
[deleted]

jollybean 5y ago

It's worse than that. Contracts are not code. It's a complete misunderstanding to posit them as such. Contracts depend first and foremost upon the legal regime in which they are valid. Every jurisdiction has rules, precedence, language means specific things. There is quite a bit of variability in this stuff, which is why we have lawyers. And Judges. Putting a contract into a crypto ... is basically pointless. There's possibly more transparency, akin to publishing contracts on the web or something like that. And of course, there is a 'narrow range of agreement possibilities' that could take place on crypto contracts, for example, things like stock options etc.. But generally speaking, even the contract cryptos are 'technologies looking for application'. We don't want to 'nay say' new, dreamy ideas, but these new dreamy ideas, combined with a bit of hubris, arrogance, greed, lack of self awareness can create problems.

crooked-v 5y ago
The most obvious example for 'contracts are not code': the most airtight contract in the world can get quickly voided in court if it turns out one of the parties was actually a minor at the time of signing, even if they hid that fact or didn't actually know it.
- fogihujy 5y ago
  This. The foremost example being EULA's and warranties in countries where the law gives consumers far more rights than the copy/paste legalese texts that everyone accepts at installation/purchase.
TeMPOraL 5y ago
> Contracts depend first and foremost upon the legal regime in which they are valid. Every jurisdiction has rules, precedence, language means specific things. One could counter that no code ever stands alone, but is executed in terms of some runtime. But I think I can bolster your point with two further thoughts: 1. Contracts are not meant to be code. The process of drafting a contract helps people arrive at a common understanding - a shared consensus, a "meeting of the minds" - and once signed, it then documents that understanding along with relevant context sufficient for third parties to be able to recreate that common understanding. The contract is not executable - it, at best, is a declarative description of some of the outcomes. The actual execution is handled independently by the parties that entered the contract. The contract only exists so that common understanding can be preserved through time and shared with other people - whether it's because some party forgot the details, or it needs to be modified, or third parties (like lawyers, judges or arbitrators) need to be involved in dispute resolution. 2. To the extent a contract contains anything resembling executable code - say, the aforementioned declarative descriptions of outcomes, or imperative descriptions of specific behavior, or some attachments with deliverable specifications, etc. - these are all expressed in a very high-level programming language, i.e. natural language. This "code" is ultimately "executed" by sapient human beings. In other words, the programming language and runtime in questions are GAI-complete: that is, coding them up from scratch, e.g. to enable "smart" contracts to be comparable in utility to regular ones, would be equivalent to creating a human-level general-purpose artificial intelligence. We're not anywhere close to achieve that, thus by definition, "smart" contracts are too dumb to make sense when we can use the normal ones.

coryrc 5y ago

No, because I expect it to implode well before "all" gets replaced!

jacoblambda 5y ago

I think the big issue is using tools without verification infrastructure. Of course there are specification level bugs to deal with but hacks seem to be oh so often the simple "I forgot to initialise a variable" kind of attacks. I think we really need to be splitting up code for smart contracts into 3 classes: - Low Complexity, Automated Assurance: Non-turing complete DSLs that allow you to fully reason about their behaviour and catch bugs in a near completely automated manner. The only one of these that I know of at the moment is Marlowe however I'd love to know if more existed. This class should be easily accessible by finance people and should be near impossible to get wrong. - Medium Complexity, Semi-automated Assurance: These are tools that are expressive and more code than contract however they may or may not be turing complete. These can catch a wide number of bug classes but may need manual intervention (annotations or proofs) to cover the last mile. - High Complexity, Manual Assurance: The are tools that give you the full power of a turing complete language and all the landmines that come with them. I personally believe any smart contract written with one of these tools should not be used in production unless it is accompanied with a formal specification and an end to end set of proofs verifying correctness. At least with this model you can judge the risk factor by how complex your application is. 90% of smart contracts probably fall into the first class and another 9% probably fall into the second. There really is no reason to be using a tool without any reasonable amount of assurances provided unless your project is extraordinarily complex (and even then it'd probably cost a fortune to run on a network) and even then there's no reason for these smart contracts to exist without any proofs backing them.

Paradigma11 5y ago
There are some interesting projects on Tezos in this regard: https://archetype-lang.org/ https://archetype-lang.org/ is a non-turing complete dsl that you can run http://why3.lri.fr/ http://why3.lri.fr/ proofs on. Another way is to run proofs on the michelson that was generated by a higher level language (https://ligolang.org/ https://ligolang.org/, https://hackage.haskell.org/package/morley https://hackage.haskell.org/package/morley ...) with: https://gitlab.com/nomadic-labs/mi-cho-coq https://gitlab.com/nomadic-labs/mi-cho-coq The most interesting project (still alpha i think) to me is: https://juvix.org/ https://juvix.org/ a rather elegant dependently typed language.

cfcosta 5y ago

I'd say this is a problem of a really new tech, with the advanced attack vectors and methodologies we have nowadays. Thankfully, other cryptos (such as Cardano) are building their smart contract platform with correctness/security in mind (compiler checks and so on), so we might see less problems like this.

arp242 5y ago

> Does anyone else feel like replacing all the legacy finance infrastructure with decentralised code is going to produce a worrying number of stories like this? And stuff like "I lost £95,000 in a bank scam after my solicitor's email was hacked".[1] She managed to recover £57k after , but still lost £35k, not an insubstantial amount! If anything, we need more protection against stuff like this. Sending money to the wrong account because your solicitor's email account was compromised is something that can happen to anyone, especially if it's someone you've been in regular contact with. It seems the systems for dealing with fraud in the current banking system is already inadequate (although there is now a new "voluntary code" according to the article, no idea how well this works in practice), and for crypto it's woefully so. [1]: https://www.theguardian.com/money/2020/feb/29/bank-scam-solicitors-email-hacked https://www.theguardian.com/money/2020/feb/29/bank-scam-soli...

Dayshine 5y ago
This is before the recent change in bank transfers that requires account name to match account number right? My understanding was that change basically closes the majority of these scams (where the account details are substituted) as you would now need to create an account with a name you don't have ID for which is very very hard.
- arp242 5y ago
  Yeah, you're correct. As for how this actually pans out in practice: I don't know. I'd guess that having people also fill in a name isn't impossible either, although it certainly makes it a lot harder.

ryanmarsh 5y ago

Even as a crypto maximalist I believe code can create tyrannies of it's own kind. Take the example a story posted on HN some time ago of code Hertz wrote reporting cars not turned in as stolen and getting people (unfairly) arrested. If I call my bank, they can fix a mistake, no matter how bad, because they own "truth". I think what will end up happing is every contract will have the ability for some authorized key to make arbitrary movements of tokens amongst custodial accounts and nobody will build contracts where anything is moved out of custodial accounts until there's been multiple authorizations. Sort of how I transfer money into Gemini, I don't just trade from my personal checking account and they won't transfer to my checking without some authorizations. Look, I know I'm not being sophisticated here, I'm just saying, you need a way of un-fucking a fuckup and if someone can abscond with tokens easily because of a small logic flaw that doesn't work writ large.

Daishiman 5y ago
So then why even bother with DeFi when what you're doing is just relaying trust back to a centralised human party? It's just regular finance with extra steps.
- intotheabyss 5y ago
  Except it's not at all. You can take synthetic TSLA shares and deposit those as collateral to mint stablecoins as a loan. Where else can you do that from your web browser at 10am on a Sunday and confirmed in 30 seconds?
  - Daishiman 5y ago
    Clearly the demand for this isn't exactly as important as anyone claims given the abject failure of the microloans industry to pan out. The problem with loans generally isn't that you can have one at 10Am on a Sunday morning.
    - ryanmarsh 5y ago
      I've always thought the retail lending side of DeFi was silly. The risk is too high. Screenshot this, mortgage backed securities will be the first major success of blockchain debt based products.