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

61–70 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#61

Post by bandang »

AgentME wrote: post #15
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…

The main problem with Javascript cryptography called out in https://www.nccgroup.trust/us/about-us/newsroom-and-events/b... is that the Javascript is delivered to the user's browser from the server on every view. If someone makes a web app for doing end-to-end encrypted messages between users, it can't be secure from the web server operator: the server operator can update the javascript one day to leak users' private…

Don't see how that differs from any other language. Any program, no matter what the language its written in can send you bad code from the server you have to download it from.

You also have the javascript engine/c compiler to worry about, which can of course also be malicious.

Then you have the OS to worry about.

Then, given all that, you have people pretending to know what they are talking about and stating they take security seriously to worry about. When clearly, all your base are belong to us.

Re: Lisk: Blockchain development in JavaScript

#62

Post by chauey »

latchkey wrote: post #39

> we are planning an eventual transition to TypeScript Just switch today. That's kind of silly to write a whole bunch of untyped code and then move to types. Especially since you can do it over time with TS. All these tests that something is a string... why not let a compiler do that for you? https://github.com/LiskHQ/lisk/blob/development/test/api/acc...

yep i love Typescript! Been using it with Angular 2 and Angular 4. I come from a C#/.NET background and don't want to go back. I even co-founded a .NET user group and the name of my company has ".NET" in it! No reason to not use TypeScript.. Can use what you want or continue writing javascript in the .ts files. Might need to change some default settings, don't know, i've had NO reason to NOT get all these autocomplete/intellisense/advice/errors/warnings/best-practices.

Re: Lisk: Blockchain development in JavaScript

#63

Post by qaq »

yorwba wrote: post #59
qaq wrote: post #45

Earlier quoted context omitted.

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.

Re: Lisk: Blockchain development in JavaScript

#64

Post by danek »

chrisco255 wrote: post #48
cgmg wrote: post #22

Earlier quoted context omitted.

I agree. I don't understand why people say things like "You can create bugs and make mistakes in any language." That's not the issue. The issue is how likely someone is to make mistakes in that language, and whether the way the language is designed makes it easier to shoot yourself in the foot.

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 programmer will make a less buggy program than a mediocre c++ programmer.

There is no silver bullet, though the article tries to pass off TDD as one. Also he does concede that static types can power tooling that might "feel like they make us more productive".

Disclaimer: I prefer having types but I also think JavaScript is great and don't shy away from using it.

Re: Lisk: Blockchain development in JavaScript

#66

Post by yorwba »

jsnathan wrote: post #53
relyio wrote: post #30

Earlier quoted context omitted.

>I'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? 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. >I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not? Not sure what…

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

On the other hand, if you're just writing an app to get data from a website and display it, you can probably afford it if the program doesn't work in some cases. If you can write a generator for realistic input, and check the output, that will give you a probabilistic estimate of correctness.

The main advantage that test suites have over type systems is the kind of properties they can easily check. If you have a test suite that only checks that the output values have the right structure (EDIT: https://news.ycombinator.com/item?id=15137691 points out that part of the Lisk test suite does exactly that), you'd probably benefit even from the C type system. But to formalize the correctness of values, for many programs you'd need a much more powerful type system e.g. using dependent types, that isn't quite so simple to use as writing the equivalent test.

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 it should complain when it can prove that the properties never hold, e.g. using success types, so that you don't waste time writing a test for that.)

Re: Lisk: Blockchain development in JavaScript

#67

Post by seanwilson »

chrisco255 wrote: post #48
cgmg wrote: post #22

Earlier quoted context omitted.

I agree. I don't understand why people say things like "You can create bugs and make mistakes in any language." That's not the issue. The issue is how likely someone is to make mistakes in that language, and whether the way the language is designed makes it easier to shoot yourself in the foot.

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 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 function with the wrong number of arguments etc. leads to less bugs by definition. Do you really need a study to prove you're more productive and your code is more secure in a language where mixing up types is impossible compared to using a language that lets you make that mistake? You can write secure code in assembly if you want but you're just making life hard for yourself.

Re: Lisk: Blockchain development in JavaScript

#68

Post by azag0 »

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.

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.

Re: Lisk: Blockchain development in JavaScript

#69

Post by johnhenry »

danmaz74 wrote: post #47
chrisco255 wrote: post #46

Earlier quoted context omitted.

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.

Re: Lisk: Blockchain development in JavaScript

#70

Post by seanwilson »

keypusher wrote: post #2

> 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. Sorry, but I just don't agree. Javascript is a popular language, and has an important role to play in frontend development, but for financial transactions and cr…

I wouldn't use JavaScript directly but why not one of the many languages that compiles into JavaScript?
Post reply on HN