Hacker News new | ask | show | jobs
by mbrock 3109 days ago
Suboptimal smart contracts directly incur unnecessary transaction costs for users, and it's hard to imagine that Haskell as a source language would translate to efficient EVM bytecode.

For one, do you really want to have a lazy evaluation runtime compiled into your multisig? Now do you want to prove the correctness of that runtime? ...

I don't think Haskell is anywhere near a good source language for Ethereum smart contracts, if you think of it as "compiling Haskell".

There was a master's thesis about compiling Idris to EVM, and it also shows that the performance problems are difficult indeed even without laziness.

https://publications.lib.chalmers.se/records/fulltext/234939...

But I do think it's very interesting to think of Haskell as a powerful metalanguage for defining smart contracts that then get compiled to EVM.

Other examples of Haskell as a DSL environment for generating more restricted programs:

https://hackage.haskell.org/package/accelerate

http://ku-fpg.github.io/software/kansas-lava/

http://www.clash-lang.org/

Quote from the Kansas Lava site:

Kansas Lava is a Domain Specific Language (DSL) for expressing hardware-oriented descriptions of computations, and is hosted inside the language Haskell. Kansas Lava programs are descriptions of specific hardware entities, the connections between them, and other computational abstractions that can compile down to these entities. Large circuits have be successfully expressed using Kansas Lava, and Haskell’s powerful abstraction mechanisms, as well as generic generative techniques, can be applied to good effect to provide descriptions of highly efficient circuits.

That's an approach I think is much more appropriate for the strengths and weaknesses of Haskell!

As it happens, we've started very modestly at using Haskell like this. At the moment we only have a simple monadic assembler that lets you write EVM code. See this example:

https://github.com/dapphub/ds-weth/blob/master/src/weth4.hs

Of course we want to take this further and find some more abstractions for cleanly expressing actual smart contract patterns...