Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lisk: Blockchain development in JavaScript

blog.lisk.io

Post reply on HN
Print view View original

81–90 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#81

Post by danek »

13years wrote: post #80
seanwilson wrote: post #67

Earlier quoted context omitted.

I didn't find that convincing at all and most studies like this are full of issues because coder productivity is notoriously hard to measure. The graph of bugs per language is just a simple count of how many GitHub issues were labelled "bug" which isn't meaningful. I don't even know why you need a study for this anyway. Working in a language where it's impossible to mix up strings and numbers, impossible to call a fu…

Studies are important simply because reality is often counter intuitive to theory.

This is true but a study is useless if it can't measure the thing you want. Things in programming are notoriously difficult to quantify, compared to say, stuff in physics. Perhaps it's why there are so many holy wars.

Re: Lisk: Blockchain development in JavaScript

#82

Post by ghgr »

johnhenry wrote: post #69
danmaz74 wrote: post #47

Earlier quoted context omitted.

* 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] under…

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

Re: Lisk: Blockchain development in JavaScript

#83

Post by jsnathan »

yorwba wrote: post #66
jsnathan wrote: post #53

Earlier quoted context omitted.

> Short-answer is yes, and there's been lots of work done to go even further than having static typing and have formal verification for smart-contracts. Yes, I've looked at some of these projects before. And I certainly think it's a good idea to use automated tools to try to prove properties about programs. But I'm more excited about things like property testing than I am about things like strong type systems. And I'…

> I don't doubt that strong type systems can catch bugs, I am wondering how their capabilities in catching bugs differ from test suites. Type systems and test suites are complementary. When a test suite finds a bug, that proves that the program is incorrect for some inputs. When a type system doesn't reject a program, that proves that the program is correct for all inputs. Which one to use depends on the impact of an…

> When a test suite finds a bug, that proves that the program is incorrect for some inputs. When a type system doesn't reject a program, that proves that the program is correct for all inputs.

> Which one to use depends on the impact of an error. In the case of a system that controls lots of money, you'll want a guarantee that all inputs lead to a correct balance. That suggests to use a type system.

When a test suite passes that proves that the program is correct for a subset of all inputs. But I do not see how the same can be said about a type system.

Types do not usually capture semantics - unless we are talking about something a lot more powerful than what I'm used to seeing in real programming languages.

> I think a good compromise would be a language that allows you to annotate your types with arbitrary properties, but doesn't complain if it can't type-check them, so long as you write a test.

But why do I need types for this? Why can't I just assert the properties outright, writing assertions only in terms of the code interface? It's not the types that tell me what arbitrary properties my code should have!

Re: Lisk: Blockchain development in JavaScript

#84

Post by sealthedeal »

azag0 wrote: post #68
qaq wrote: post #40

Earlier quoted context omitted.

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.

Why does "irreversible transaction" or "custom transactions" matter at all when talking about writing something in javascript?

Re: Lisk: Blockchain development in JavaScript

#86

Post by purerandomness »

qaq wrote: post #40
flunhat wrote: post #36

Earlier quoted context omitted.

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

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.

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

Re: Lisk: Blockchain development in JavaScript

#87

Post by yorwba »

jsnathan wrote: post #83
yorwba wrote: post #66

Earlier quoted context omitted.

> I don't doubt that strong type systems can catch bugs, I am wondering how their capabilities in catching bugs differ from test suites. Type systems and test suites are complementary. When a test suite finds a bug, that proves that the program is incorrect for some inputs. When a type system doesn't reject a program, that proves that the program is correct for all inputs. Which one to use depends on the impact of an…

> When a test suite finds a bug, that proves that the program is incorrect for some inputs. When a type system doesn't reject a program, that proves that the program is correct for all inputs. > Which one to use depends on the impact of an error. In the case of a system that controls lots of money, you'll want a guarantee that all inputs lead to a correct balance. That suggests to use a type system. When a test suite…

> Types do not usually capture semantics - unless we are talking about something a lot more powerful than what I'm used to seeing in real programming languages.

You are right, I should have specified that the correctness proof only applies to properties actually given in the type system. So for a high-stakes financial application, your types should be strong enough to capture at least elementary arithmetic. This is definitely not something you'd see in a mainstream programming language.

> It's not the types that tell me what arbitrary properties my code should have!

When you give a variable in a program a type, you assert a property for all values that variable will ever take. The converse is also true: for any property you want to express, there is a type system that can encode it. This is called the Curry-Howard correspondence.

Unfortunately, most interesting properties one might want to formalize require either an undecidable type system, or you have to write a bunch of proof code just to convince the type checker that the rest of the code conserves the properties it should. That isn't too different if you'd be doing formal verification for all your code anyway, but it gets annoying when it is enforced everywhere, even when you'd deem it unnecessary otherwise. In that, it is similar to a policy of "unit tests everywhere", which probably catches some bugs, but also leads to lots of boilerplate stating the obvious.

Re: Lisk: Blockchain development in JavaScript

#88

Post by kin »

flunhat wrote: post #13

> ...Even though JavaScript is a weakly typed language it doesn’t mean that it is inherently insecure. Yes, the programming language used plays an important role, but at the end of the day it is the developers obligation to write secure code in the first place...We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its s…

Would you prefer a different language or just a better answer? From my perspective, I don't see how the language makes a difference. In security, you have way more to worry about before even considering an application's underlying implementation language.

Re: Lisk: Blockchain development in JavaScript

#89

Post by johnhenry »

ghgr wrote: post #82
johnhenry wrote: post #69

Earlier quoted context omitted.

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] under…

> 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 bl…

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

Re: Lisk: Blockchain development in JavaScript

#90

Post by chrisco255 »

danek wrote: post #64
chrisco255 wrote: post #48

Earlier quoted context omitted.

Please read "The Shocking Truth about static Types" by Eric Elliott, which includes links to studies on bug density by programming language. JavaScript is in the middle of the pack, and programs built on JS are on average less buggy than C++ and Java. https://medium.com/javascript-scene/the-shocking-secret-abou...

I read the studies he cited and I'm not sure we can conclude anything from them. As far as I can tell, "bug density by language" is not a thing you can measure in a meaningful way. It depends on the specific programmers at a specific point in their career, their skill level, domain knowledge for the project, scope of project, who the project manager is, their culture of testing, etc. For example a great JavaScript pr…

I agree with all your points. I think, if anything, the study should show that JS is not inherently worse than any other language. It's got a bad rap, that mostly has to do with weird quirks in the language (i.e. == vs ===), but those quirks are easy to avoid. I do think testing in general is a good way to build more reliable programs.
Post reply on HN