
Lisk: Blockchain development in JavaScript - omarchowdhury
https://blog.lisk.io/what-is-lisk-and-what-it-isnt-e7b6b6188211
======
flunhat
> ...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.

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

~~~
relyio
>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/](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](https://news.ycombinator.com/item?id=15061029)

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

No offense, but all of the answers I've gotten so far are very vague, and
don't really address my question. I don't doubt that strong type systems can
catch bugs, I am wondering how their capabilities in catching bugs differ from
test suites.

Let me give you an example, say we have a hypothetical language with a strict
type system, and we declare a variable to be of type List[Foo]. Then later we
use that variable as if it was really of type Foo. That's not gonna work, and
a type-checker would catch that at compile-time. But a test suite (that covers
the variable access) is going to catch that as well, because the code won't
behave as it should.

At which point is a strong type system going to surface a bug that a good test
suite would not have? Like, can you give an example?

> Not sure what you mean by "reasonable" (is it extensive? testing
> pathological cases? where do you draw the line?).

The line is as variable as the strictness of the type system we would compare
it to.

I guess one could argue that a type system will force the programmer to
satisfy it, while a test suite can be written very sloppily. So maybe there is
some kind of signalling value in using these types of languages.

~~~
yorwba
> 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](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.)

~~~
jsnathan
> 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!

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

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

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

------
Adamantcheese
> 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?

~~~
zeroxfe
Verifiable audit trails.

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

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

~~~
stephengillie
It's similar to those who think "encrypting" something in Base64 makes it
secure.

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

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

------
EGreg
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?

------
stcredzero
If you added:

[https://facebook.github.io/immutable-
js/](https://facebook.github.io/immutable-js/)

Would you wind up with an Immutalisk?

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

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

~~~
TheAceOfHearts
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
Let's just hope it doesn't die on the floor like SIMD did.

------
dfischer
This is actually pretty cool.

------
659087
File under: terrible ideas made possible by buzzwords.

~~~
dang
Would you please stop posting unsubstantive comments to HN?

~~~
659087
I see what I'd consider "unsubstantive" comments left alone on HN in pretty
much every thread, so if you could, please define "unsubstantive".

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

