12 ms·

Lisk: Blockchain development in JavaScript

186 points by omarchowdhury 9y ago

keypusher 9y ago
> 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 critical contract code, the lack of safety almost guarantees catastrophic bugs and vulnerabilities will be made in production code. Maybe this is fine for hobby projects, but if you are talking about moving billions of dollars around in the real global economy, I don't see it being done safely in Javascript. I like that projects such as Tezos are integrating formal verification of smart contract code, that seems like the right way forward.
- danmaz74 9y ago
  Not just that. One thing that worries me a lot about JS in this context is numbers: JS was designed to make it easy to use numbers and convert to/from strings without caring about the precision and exact internal representation. Which is perfectly fine for UI code and the like, but a terrible idea when you're transacting money.
  - kaoD 9y ago
    Well, there are plenty of number libraries like BN.js that univocally convert from/to buffers and have unlimited precision. Numbers are the least of my worries with JS security code.
    - danmaz74 9y ago
      The point is that you have to know you need to use those libraries to have exact computations. Lisk chose javascript to make dapps available to the masses. How many javascript programmers do you think even know what a number on a computer really is? The risks of summing floats? Etc. etc.
  - TheAceOfHearts 9y ago
    I have good news for you! There's a BigInt proposal [0], and it's already in stage 3 of the process. Now they're asking for feedback and waiting for implementations. [0] https://github.com/tc39/proposal-bigint https://github.com/tc39/proposal-bigint
    - hajile 9y ago
      Let's just hope it doesn't die on the floor like SIMD did.
- 52-6F-62 9y ago
  I'm one of probably the larger JS fans, and even love working with NodeJS (don't shoot me please) -- but I totally agree with you. I would certainly not trust myself, I really wouldn't trust somebody else trying the same. I don't see a huge problem using some JS blockchain library for some non-critical application if it somehow added to the end product, but something so highly critical... no thanks. Except for the part about Tezos. I haven't looked into it.
  - kevinmannix 9y ago
    I really don't think liking Node is a cross to bear
    - spraak 9y ago
      Many other people seem to think so... So I assume the poster above (like myself) have encountered that sentiment before
- hasenj 9y ago
  The whole "Misunderstandings" section reads like a flat-earther denying that they're anti-science.
- progx 9y ago
  You are right, but who uses Cobol today?
- seanwilson 9y ago
  I wouldn't use JavaScript directly but why not one of the many languages that compiles into JavaScript?
Adamantcheese 9y ago
> You can now build a decentralized Internet of Things application which allows you to securely (with authorisation!) turn on gadgets with a simple transaction, which can be just a push on a button. Why would it be necessary to use a transaction to turn something on/off securely?
- deleted 9y ago
  [deleted]
- ArchReaper 9y ago
  Ya, I fail to see the benefit of this (for IoT) over using any other widely-available technology for secure communication (SSH, etc)
- zeroxfe 9y ago
  Verifiable audit trails.
659087 9y ago
File under: terrible ideas made possible by buzzwords.
- dang 9y ago
  Would you please stop posting unsubstantive comments to HN?
  - 659087 9y ago
    I see what I'd consider "unsubstantive" comments left alone on HN in pretty much every thread, so if you could, please define "unsubstantive".
    - omarchowdhury 9y ago
      In this specific case you call Lisk a terrible idea without substantiating why, other than the fact that's its related to a nascent technology (buzzword as you say).
    - dang 9y ago
      Moderation works by random sample so it obviously isn't going to be consistent. But if you post like that repeatedly, you're eventually going to get asked not to. Whatever the definition of unsubstantive is, snarky generic dismissals are certainly included.
  - retox 9y ago
    Is there an option to disable this auto-collapsing?
- omarchowdhury 9y ago
  There was a time when common internet protocols we take for granted today were a buzzword, too. Buzzwords are buzzwords until implementation is (or isn't) proven useful. Lisk is making an attempt. Let's judge the attempt and the fruits or lack thereof. Disclaimer: I am not an investor, stakeholder, or employee in Lisk.
dfischer 9y ago
This is actually pretty cool.
flunhat 9y ago
> ...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 speed and security across a wide range of devices. I don't mean to be rude, but that's the worst possible answer you could have given. Security should be your first priority, not an afterthought to popularity. That it isn't tells me everything I need to know about the seriousness of your project.
- AgentME 9y ago
  The main problem with Javascript cryptography called out in https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ 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 keys to the server. The server operator could even serve that malicious change to a subset of users so that it's even less likely to be noticed. In systems where the Javascript isn't loaded on demand from a server on every use (like a server written in node.js, or an application built with electron), then that issue doesn't apply.
  - protomikron 9y ago
    I guess your parent meant security problems due to bugs that could have been prevented using a language that has a stricter type system. This does not mean you don't have to deal with security (your case still applies), but at least you get rid of some known bugs in advance.
    - AgentME 9y ago
      If it was just about type systems, then you'd expect similar outrage over web apps written in PHP, Python, and Ruby. Personally I'm a huge fan of how Flow or Typescript add a type system on top of Javascript and think anyone writing a >500 line web app would hugely benefit from using one of them.
tiagobertolo 9y ago
People who think compiling a language offers security know very little about it.
- stephengillie 9y ago
  It's similar to those who think "encrypting" something in Base64 makes it secure.
  - sealthedeal 9y ago
    HAHAHAHAHAHA!
saghm 9y ago
> We are also contemplating pushing back certain critical core features to C++ for maximum speed and security. C++ for security? I'm not sure that would make me feel any better
girvo 9y ago
With all of the pain I've had with Hyperledger Composer, I'm not sure JavaScript is a good idea for smart contracts. Even on private blockchains its still painful.
EGreg 9y ago
So basically LISK has a bunch of computers the others vote for to secure transactions. That's it? So that's consensus? That's easy! What's the downside of this?
jorblumesea 9y ago
> We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its speed and security across a wide range of devices. What about WASM? Seems like if we're future thinking "things that can run everywhere" just about any language can be compiled into a web assembly target and used. WASM is supported in most major browsers except IE.
- johnhenry 9y ago
  The difference here is that JavaScript is a human-readable format and, although, it can be translated into a readable format, WASM is byte-code. It is more practical to write contracts in a high-level language and translate them into byte-code than writing the byte-code itself. Ethereum uses this concept by translating solidity code into ethereum byte-code, whereas Lisk appears to interpret the JavaScript directly without translation. WASM would be a candidate to replace the byte-code in ethereum, but in order to avoid the impracticality of writing contracts directly in WASM, we'd also need a high-level language from which to compile. This reason this is a good idea is because one could write contracts in any language for which a WASM compiler exists, but I imagine that could also be done with ethereum byte-code. WASM currently has the '"runs literally everywhere" advantage' here, but it should be simple to create a compiler that translates from solidity to WASM, or even directly from ethereum byte-code itself. Further, I don't buy in to the '"runs literally everywhere" advantage' for JavaScript because it loses this advantage to any language that can compile to it and this is becoming increasingly true for WASM as well.
latchkey 9y ago
> 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/accounts.js#L17 https://github.com/LiskHQ/lisk/blob/development/test/api/acc...
- chauey 9y ago
  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.
thinbeige 9y ago
Fyi, Poloniex shows from time to time (but often enough) that Lisk has some issues, is slow in processing and can't be traded.
stcredzero 9y ago
If you added: https://facebook.github.io/immutable-js/ https://facebook.github.io/immutable-js/ Would you wind up with an Immutalisk?

186 points by omarchowdhury 9y ago

> 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 critical contract code, the lack of safety almost guarantees catastrophic bugs and vulnerabilities will be made in production code. Maybe this is fine for hobby projects, but if you are talking about moving billions of dollars around in the real global economy, I don't see it being done safely in Javascript. I like that projects such as Tezos are integrating formal verification of smart contract code, that seems like the right way forward.

danmaz74 9y ago
Not just that. One thing that worries me a lot about JS in this context is numbers: JS was designed to make it easy to use numbers and convert to/from strings without caring about the precision and exact internal representation. Which is perfectly fine for UI code and the like, but a terrible idea when you're transacting money.
- kaoD 9y ago
  Well, there are plenty of number libraries like BN.js that univocally convert from/to buffers and have unlimited precision. Numbers are the least of my worries with JS security code.
  - danmaz74 9y ago
    The point is that you have to know you need to use those libraries to have exact computations. Lisk chose javascript to make dapps available to the masses. How many javascript programmers do you think even know what a number on a computer really is? The risks of summing floats? Etc. etc.
- TheAceOfHearts 9y ago
  I have good news for you! There's a BigInt proposal [0], and it's already in stage 3 of the process. Now they're asking for feedback and waiting for implementations. [0] https://github.com/tc39/proposal-bigint https://github.com/tc39/proposal-bigint
  - hajile 9y ago
    Let's just hope it doesn't die on the floor like SIMD did.
52-6F-62 9y ago
I'm one of probably the larger JS fans, and even love working with NodeJS (don't shoot me please) -- but I totally agree with you. I would certainly not trust myself, I really wouldn't trust somebody else trying the same. I don't see a huge problem using some JS blockchain library for some non-critical application if it somehow added to the end product, but something so highly critical... no thanks. Except for the part about Tezos. I haven't looked into it.
- kevinmannix 9y ago
  I really don't think liking Node is a cross to bear
  - spraak 9y ago
    Many other people seem to think so... So I assume the poster above (like myself) have encountered that sentiment before
hasenj 9y ago
The whole "Misunderstandings" section reads like a flat-earther denying that they're anti-science.
progx 9y ago
You are right, but who uses Cobol today?
seanwilson 9y ago
I wouldn't use JavaScript directly but why not one of the many languages that compiles into JavaScript?

Adamantcheese 9y ago

> You can now build a decentralized Internet of Things application which allows you to securely (with authorisation!) turn on gadgets with a simple transaction, which can be just a push on a button. Why would it be necessary to use a transaction to turn something on/off securely?

deleted 9y ago
[deleted]
ArchReaper 9y ago
Ya, I fail to see the benefit of this (for IoT) over using any other widely-available technology for secure communication (SSH, etc)
zeroxfe 9y ago
Verifiable audit trails.

659087 9y ago

File under: terrible ideas made possible by buzzwords.

dang 9y ago
Would you please stop posting unsubstantive comments to HN?
- 659087 9y ago
  I see what I'd consider "unsubstantive" comments left alone on HN in pretty much every thread, so if you could, please define "unsubstantive".
  - omarchowdhury 9y ago
    In this specific case you call Lisk a terrible idea without substantiating why, other than the fact that's its related to a nascent technology (buzzword as you say).
  - dang 9y ago
    Moderation works by random sample so it obviously isn't going to be consistent. But if you post like that repeatedly, you're eventually going to get asked not to. Whatever the definition of unsubstantive is, snarky generic dismissals are certainly included.
- retox 9y ago
  Is there an option to disable this auto-collapsing?
omarchowdhury 9y ago
There was a time when common internet protocols we take for granted today were a buzzword, too. Buzzwords are buzzwords until implementation is (or isn't) proven useful. Lisk is making an attempt. Let's judge the attempt and the fruits or lack thereof. Disclaimer: I am not an investor, stakeholder, or employee in Lisk.

dfischer 9y ago

This is actually pretty cool.

flunhat 9y ago

> ...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 speed and security across a wide range of devices. I don't mean to be rude, but that's the worst possible answer you could have given. Security should be your first priority, not an afterthought to popularity. That it isn't tells me everything I need to know about the seriousness of your project.

AgentME 9y ago
The main problem with Javascript cryptography called out in https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/ 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 keys to the server. The server operator could even serve that malicious change to a subset of users so that it's even less likely to be noticed. In systems where the Javascript isn't loaded on demand from a server on every use (like a server written in node.js, or an application built with electron), then that issue doesn't apply.
- protomikron 9y ago
  I guess your parent meant security problems due to bugs that could have been prevented using a language that has a stricter type system. This does not mean you don't have to deal with security (your case still applies), but at least you get rid of some known bugs in advance.
  - AgentME 9y ago
    If it was just about type systems, then you'd expect similar outrage over web apps written in PHP, Python, and Ruby. Personally I'm a huge fan of how Flow or Typescript add a type system on top of Javascript and think anyone writing a >500 line web app would hugely benefit from using one of them.

tiagobertolo 9y ago

People who think compiling a language offers security know very little about it.

stephengillie 9y ago
It's similar to those who think "encrypting" something in Base64 makes it secure.
- sealthedeal 9y ago
  HAHAHAHAHAHA!

saghm 9y ago

> We are also contemplating pushing back certain critical core features to C++ for maximum speed and security. C++ for security? I'm not sure that would make me feel any better

girvo 9y ago

With all of the pain I've had with Hyperledger Composer, I'm not sure JavaScript is a good idea for smart contracts. Even on private blockchains its still painful.

EGreg 9y ago

So basically LISK has a bunch of computers the others vote for to secure transactions. That's it? So that's consensus? That's easy! What's the downside of this?

jorblumesea 9y ago

> We chose JavaScript because it runs literally everywhere, is extremely popular & widespread, and has huge companies like Google or Microsoft working on its speed and security across a wide range of devices. What about WASM? Seems like if we're future thinking "things that can run everywhere" just about any language can be compiled into a web assembly target and used. WASM is supported in most major browsers except IE.

johnhenry 9y ago
The difference here is that JavaScript is a human-readable format and, although, it can be translated into a readable format, WASM is byte-code. It is more practical to write contracts in a high-level language and translate them into byte-code than writing the byte-code itself. Ethereum uses this concept by translating solidity code into ethereum byte-code, whereas Lisk appears to interpret the JavaScript directly without translation. WASM would be a candidate to replace the byte-code in ethereum, but in order to avoid the impracticality of writing contracts directly in WASM, we'd also need a high-level language from which to compile. This reason this is a good idea is because one could write contracts in any language for which a WASM compiler exists, but I imagine that could also be done with ethereum byte-code. WASM currently has the '"runs literally everywhere" advantage' here, but it should be simple to create a compiler that translates from solidity to WASM, or even directly from ethereum byte-code itself. Further, I don't buy in to the '"runs literally everywhere" advantage' for JavaScript because it loses this advantage to any language that can compile to it and this is becoming increasingly true for WASM as well.

latchkey 9y ago

> 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/accounts.js#L17 https://github.com/LiskHQ/lisk/blob/development/test/api/acc...

chauey 9y ago
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.

thinbeige 9y ago

Fyi, Poloniex shows from time to time (but often enough) that Lisk has some issues, is slow in processing and can't be traded.

stcredzero 9y ago

If you added: https://facebook.github.io/immutable-js/ https://facebook.github.io/immutable-js/ Would you wind up with an Immutalisk?