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

71–80 of 110 posts

Re: Lisk: Blockchain development in JavaScript

#71

Post by KMag »

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

> > 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'm wondering specifically what is the value they bring.

By "property checking" you mean theorem proving.

Static type checkers are theorem provers. More powerful type systems allow more interesting and less intuitive proofs to be written. Sometimes, the type checker is integral to the compiler and is required to run on every build, and sometimes it's an external tool.

In any case, if you're adding annotations to your source code in order for a theorem prover to statically prove certain runtime properties, those annotations constitute a static type system which is type-checked by your theorem prover.

Maybe you don't like even a subset of your theorem prover to run on every build, but if you're in favor of machine-checked proofs of program behavior, you're in favor of static typing.

Re: Lisk: Blockchain development in JavaScript

#72

Post by kaoD »

tmp12456 wrote: post #55
KirinDave wrote: post #35

Earlier quoted context omitted.

> Security should be your first priority, Do you bother folks writing blockchain implementations in C, which is at least as hard to deliver secure code in? Just curious if you're consistent in your unfair standard or if this is an even more unfair standard than a literal reading of the text.

Maybe the people saying that js is insecure were refering to the state of crypto on js. Like random number generation etc.

Probably not https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_...

JS unsafety comes from its loose rules regarding coercion, bugs that only pop up when they're actually executed (sometimes under very specific conditions), etc.

Re: Lisk: Blockchain development in JavaScript

#73

Post by quickthrower2 »

chrisco255 wrote: post #46
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 .…

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

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

Re: Lisk: Blockchain development in JavaScript

#74

Post by KMag »

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…

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

Re: Lisk: Blockchain development in JavaScript

#75

Post by johnhenry »

jorblumesea wrote: post #38

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

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.

Re: Lisk: Blockchain development in JavaScript

#76

Post by johnhenry »

KMag wrote: post #74
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…

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

Re: Lisk: Blockchain development in JavaScript

#77

Post by jsnathan »

KMag wrote: post #71
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'…

> > 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'm wondering specifically what is the value they bring. By "property checking" you mean theorem proving. Static type checkers are theorem provers. M…

Property testing [1] is about semantics, the same as regular testing, and it does not require code annotations. [Edit: It's more like "fuzzing" than "model checking".] Type systems on the other hand aren't usually powerful enough to capture semantics.

They allow you to say things like, this function takes in a list of Foo objects, and returns one Foo object. But they don't really let you express whether the object returned is or is not part of the original list, and if it is, that it was chosen according to the right mechanism. That's what tests are for.

Without being able to express the semantics of code, I don't see how you can trust it. There may not be any type mismatches, but there sure can be lots of bad logic in there.

[1]: http://hypothesis.works/articles/what-is-property-based-test...

Re: Lisk: Blockchain development in JavaScript

#78

Post by hajile »

TheAceOfHearts wrote: post #58
danmaz74 wrote: post #9

Earlier quoted context omitted.

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.

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

Let's just hope it doesn't die on the floor like SIMD did.

Re: Lisk: Blockchain development in JavaScript

#79

Post by dangerface »

cgmg wrote: post #22
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…

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.

Fair point but I have tried more programming languages than I can list "the way the language is designed makes it easier to shoot yourself in the foot" is a fairly accurate description for all of them.

Re: Lisk: Blockchain development in JavaScript

#80

Post by 13years »

seanwilson wrote: post #67
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 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.
Post reply on HN