3 ms·

I think you may have inverted the responsibility. > any script kiddie can write dapps right away without even bothering to study what the risks are and what is

I think you may have inverted the responsibility. > any script kiddie can write dapps right away without even bothering to study what the risks are and what is happening under the hood It's not the contract author's responsibility to guarantee that the contract works properly -- they aren't forcing anyone to use it. Any script kiddie SHOULD be able to write a dapp. Most people don't [understand that they don't] understand the complexities our our modern financial system, but we don't require that one has a PhD in order to spend a dollar. A low barrier to entry when dealing with financial transactions is desirable. > end users aren't able to evaluate the quality of the dapps they entrust their money to This is entirely not true. Because dapps are publicly audit-able, an end user can evaluate whether or not he/she wishes to participate in a contract based on his/her understanding of the code. Granted, it might take a lot of time to properly learn the language used to build a contract, but this would be true of any language. Even so, if a user does not understand a contract, he/she can choose not to use it.

KMag 9y ago
> A low barrier to entry when dealing with financial transactions is desirable. Writing a dapp is much closer to issuing an exotic cross-asset derivative than it is to spending a dollar.
- johnhenry 9y ago
  I'd agree that the example of spending a dollar is a gross over simplification. I'd go further to say that there are good reasons to not allow just anyone to issue an exotic derivative. If you're going to draw up contracts, you should have a good understanding of how the rules of the contract work. Although using a language other than JavaScript may help prevent some errors, it does not fix the fundamental issue of responsibility. One should not enter into a complex contract, blockchain or not, without fully understanding the contract itself. If instead of understanding the contract, you are relying on the structure of the language to protect you, well, you're doing it wrong.
ghgr 9y ago
> Because dapps are publicly audit-able [...] Correct me if I'm wrong, but I believe that auditing a Dapp is far from trivial. Only the bytecode is stored in the blockchain, and even if the source code is published, it's hard to see if it corresponds to the published bytecode (and even then, FOSS still have bugs, remember OpenSSH and its latest security bugs). From [1]: > Q: How can I verify that a contract on the blockchain matches the source code? > A: AFAIK the best way to do this at the moment is to compile the source code again with the exact same compiler version the author used (so this is something that needs to be disclosed) and to compare the bytecode. (Thomas Bertani @ StackExchange) In addition, in the source code itself a contract programmer could implement "contractual" backdoors... ahem.. loopholes. And you'll have no recourse. [1] https://ethereum.stackexchange.com/questions/195/how-can-i-verify-that-a-contract-on-the-blockchain-matches-the-source-code https://ethereum.stackexchange.com/questions/195/how-can-i-v...
- johnhenry 9y ago
  > Correct me if I'm wrong [...] I agree, this is not trivial, but as you point out, since only the bytecode is stored in the blockchain, examining it must be only way to know what a contract does. > In addition, in the source code [...] Yes, the programmer could implement backdoors, no matter what the language is. As such, the end user should not rely on specific properties of a language to make guarantees as to whether or not it the contract does what they expect. It can help, but it's not foolproof. My point is that if you invest in a smart contract, it is unreasonable rely on outside entities -- either the person who created the contract or the contract language itself --- to ensure that it will work as expected. As hard as it may be to do, if you can't reasonably understand what's going to happen when you enter into a contract, you shouldn't.
danmaz74 9y ago
> Any script kiddie SHOULD be able to write a dapp. Most people don't [understand that they don't] understand the complexities our our modern financial system, but we don't require that one has a PhD in order to spend a dollar. A low barrier to entry when dealing with financial transactions is desirable. I think that simple market approach works well when customers are able to understand and compare what they are buying (or investing into), but it doesn't work when customers don't have the means to do so. That's why the financial industry is one of those that needs to be heavily regulated. So, no, IMHO having lowering the barrier to entry to write complex financial instruments that can trade hundreds of millions of dollars is a recipe for disaster, not for useful innovation. Of course I understand that, if you're a libertarian, you're not going to agree :)

KMag 9y ago

> A low barrier to entry when dealing with financial transactions is desirable. Writing a dapp is much closer to issuing an exotic cross-asset derivative than it is to spending a dollar.

johnhenry 9y ago
I'd agree that the example of spending a dollar is a gross over simplification. I'd go further to say that there are good reasons to not allow just anyone to issue an exotic derivative. If you're going to draw up contracts, you should have a good understanding of how the rules of the contract work. Although using a language other than JavaScript may help prevent some errors, it does not fix the fundamental issue of responsibility. One should not enter into a complex contract, blockchain or not, without fully understanding the contract itself. If instead of understanding the contract, you are relying on the structure of the language to protect you, well, you're doing it wrong.

ghgr 9y ago

> Because dapps are publicly audit-able [...] Correct me if I'm wrong, but I believe that auditing a Dapp is far from trivial. Only the bytecode is stored in the blockchain, and even if the source code is published, it's hard to see if it corresponds to the published bytecode (and even then, FOSS still have bugs, remember OpenSSH and its latest security bugs). From [1]: > Q: How can I verify that a contract on the blockchain matches the source code? > A: AFAIK the best way to do this at the moment is to compile the source code again with the exact same compiler version the author used (so this is something that needs to be disclosed) and to compare the bytecode. (Thomas Bertani @ StackExchange) In addition, in the source code itself a contract programmer could implement "contractual" backdoors... ahem.. loopholes. And you'll have no recourse. [1] https://ethereum.stackexchange.com/questions/195/how-can-i-verify-that-a-contract-on-the-blockchain-matches-the-source-code https://ethereum.stackexchange.com/questions/195/how-can-i-v...

johnhenry 9y ago
> Correct me if I'm wrong [...] I agree, this is not trivial, but as you point out, since only the bytecode is stored in the blockchain, examining it must be only way to know what a contract does. > In addition, in the source code [...] Yes, the programmer could implement backdoors, no matter what the language is. As such, the end user should not rely on specific properties of a language to make guarantees as to whether or not it the contract does what they expect. It can help, but it's not foolproof. My point is that if you invest in a smart contract, it is unreasonable rely on outside entities -- either the person who created the contract or the contract language itself --- to ensure that it will work as expected. As hard as it may be to do, if you can't reasonably understand what's going to happen when you enter into a contract, you shouldn't.

danmaz74 9y ago

> Any script kiddie SHOULD be able to write a dapp. Most people don't [understand that they don't] understand the complexities our our modern financial system, but we don't require that one has a PhD in order to spend a dollar. A low barrier to entry when dealing with financial transactions is desirable. I think that simple market approach works well when customers are able to understand and compare what they are buying (or investing into), but it doesn't work when customers don't have the means to do so. That's why the financial industry is one of those that needs to be heavily regulated. So, no, IMHO having lowering the barrier to entry to write complex financial instruments that can trade hundreds of millions of dollars is a recipe for disaster, not for useful innovation. Of course I understand that, if you're a libertarian, you're not going to agree :)