> 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
Lisk: Blockchain development in JavaScript
21–30 of 110 posts
Re: Lisk: Blockchain development in JavaScript
#22> ...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.
Re: Lisk: Blockchain development in JavaScript
#23People who think compiling a language offers security know very little about it.
It's similar to those who think "encrypting" something in Base64 makes it secure.
Re: Lisk: Blockchain development in JavaScript
#24Earlier quoted context omitted.
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.
I'm not calling blockchains a buzzword as a derogatory term towards blockchains. I'm more using the term to point out the way blockchains are being used right now (e.g. marketing bad ideas and non-ideas as groundbreaking tech). That's not to say there aren't plenty of promising projects out there. There absolutely are.
[deleted]
Re: Lisk: Blockchain development in JavaScript
#25With 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.
Re: Lisk: Blockchain development in JavaScript
#26> ...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'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system?
I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway?
I'm genuinely curious: what types of bugs does a stricter type system catch that a reasonable test suite probably would not?
Note I'm not saying that tests guarantee bug-free code, or that you can't do both. I'm just wondering about which different kinds of bugs you might catch.
Re: Lisk: Blockchain development in JavaScript
#27> 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?
Verifiable audit trails.
Re: Lisk: Blockchain development in JavaScript
#28Re: Lisk: Blockchain development in JavaScript
#29So 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?
Re: Lisk: Blockchain development in JavaScript
#30> ...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'm curious: could any of the recently known smart contract bugs have been prevented through the use of a stricter type system? I tend to think of type systems more as a hindrance myself. I mean, they can certainly help you catch bugs before the code even runs - but which of those bugs would you not catch during the testing phase anyway? I'm genuinely curious: what types of bugs does a stricter type system catch that…
>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 you mean by "reasonable" (is it extensive? testing pathological cases? where do you draw the line?). But type checking at compile time makes your code less inclined to showcase a certain class of bugs that are the byproduct of ambiguity in the language semantics and logical mistake in the programmer writing the code.
And with formal verification you can actually make sure that your logic meets the specs. You can hardly extract stronger correctness guarantees than that!
If that interests you, check out Tezos (https://tezos.com/) and github.com/tezos/tezos. The entire codebase is in OCaml.
It was on the frontpage a while back: https://news.ycombinator.com/item?id=15061029