Hacker News Reader

Comment by flunhat | Hacker News Reader

The problem isn't that they wrote the blockchain in JavaScript, it's that the language they chose for user-written contracts and dapps (out of all the languages in the world, mind you) was JavaScript. Meaning that in the future, if this project really takes off (suspend disbelief here), an entire generation of blockchain apps that transfer money back and forth will be built on JavaScript when they didn't have to be. If they chose C as the language for smart contracts/dapps/whatever I would be ragging on them just the same. They had options, and choose the one of the worst ones.

View on HN

Paypal, Walmart are doing just fine handling huge amounts of transactions in JS. Majority of security breaches are via targeted emails with attachments and have very little to do with language services are written in.

Yes, but Paypal nor Walmart don’t handle irreversible transactions. Nor are they platforms on which apps and custom transactions can be implemented. So I don’t think this is a good analogy.

Not sure what is making everyone upset Paypal is doing 1.7 billion transaction per quarter (100 billion + in volume). 80%+ of breaches at companies are via email as a vector.

Are Paypal and Walmart actually handling their transactions in JS or is that just the front end? In either case, when they transfer money, they hopefully use a sane database transaction mechanism. AFAIK, that would have prevented the DAO hack.

web layer is Node so yes they are actually handling transactions in JS up to a point.

None of those companies handles actual monetary transactions in JavaScript. That would be insane.

Define handling transactions, they have Node services which are touching cardholder data and are subject to PCI DSS compliance. The web layer is Node.

So you prefer the state of affairs with a language with arguably less safety than C _and_ many more amateurish implementation errors?

I wish Etherium had chosen Javascript. It'd have started from a better place.

I totally agree with you about Solidity.

If you're interested in developing a better language for smart contracts, check out Viper (https://github.com/ethereum/viper). Although development is kind of slow right now because Vitalik is the only one who merges pull requests.

I'm not sure I trust that team at all.

Quite frankly, I think Etherium is a shameless powergrab by a bunch of folks who's sole positive contribution to the medium is growing it.

It's a tribute to the essentially unskilled & uninformed investors and inventors in many parts of the blockchain ecosystem that Eth has been allowed to grow at all. It's a great idea for the owners of Eth and a terrible idea for everyone, everyone, EVERYONE else (except maybe certain classes of miners).

I've got 0 interest in contributing my time to a system that will only be used to extract wealth from other people's good ideas while simultaneously welding them to a release calendar that keeps them at the back of the pack of blockchain software. If I wanted to pitch in with that, zcash is way more competent anyways.

You don't standardize to a platform at the beginning of a boom. You standardize to protocols. And that is, by the way, exactly what every competent programmer is doing; standardizing on the protocols laid out by bitcoin as they develop their own chains and experiment with new, cheaper ways to sustain a digital currency.

Maybe it's one of the best ones because it is one of the most accessible programming languages on the planet.

* Most accessible language in the planet -> any script kiddie can write dapps right away without even bothering to study what the risks are and what is happening under the hood

* dapps manage real money in real time

* end users aren't able to evaluate the quality of the dapps they entrust their money to

* what could possibly go wrong?

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.

> 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.

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.

> 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-v...

> 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.

> 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 :)

Are we going round in circles? Yes that's why they chose it. Posters here disgaree that popularity should be the major decision factor.

Reply on news.ycombinator.com