Rolling Your Own Blockchain in Haskell

http://www.michaelburge.us/2017/08/17/rolling-your-own-blockchain.html

by nicolast • 9 years ago

234 32 9 years ago

Here is another "minimum viable" blockchain implementation in Haskell: https://github.com/adjoint-io/nanochain.

It's a bit simpler in implementation; the relevant data structures are defined a bit differently, so it could give a nice alternate perspective about what a blockchain written in Haskell may look like.

umen• 9 years ago

Great stuff , where can I learn about blackchain in begginers level with code examples ?

imdsm• 9 years ago

https://news.ycombinator.com/item?id=14659775

cyphar2• 9 years ago

It's quite a cute idea, implementing a blockchain (a fundamentally impure concept) in Haskell. If you're interested in other cool Haskell projects, check out JoeyH[1].

[1] http://joeyh.name/code/

Kinnard• 9 years ago

What do you mean by a 'fundamentally impure concept'?

quickthrower2• 9 years ago

Not the OP but maybe he means there are side effects. Of course Haskell can side effects that is one of the big misconceptions.

cyphar2• 9 years ago

Impure as in "has side-effects". An append-only state that is used for synchronisation between different machines by definition has side-effects. Of course, you can have side-effects in Haskell, I just thought it was an interesting choice.

arianvanp• 9 years ago

Seems a fundamentally pure concept to me. Writing down facts that never change in append-only fashion.

alphaalpha1013• 9 years ago

I like the idea behind this article, but this isn't the way to do it. It hides the simplicity of the blockchain concept behind arcane syntax and overly complicated higher-order typing constructs.

    newtype BlockF a = Block (V.Vector a) deriving (Eq, Show, Foldable, Traversable, Functor, Monoid)
    type Block = BlockF Transaction

    type Blockchain = Cofree MerkleF Block

Does anyone really think this is how one should write software? I think that constructions like Cofree are interesting, but I don't think they're programming.

WmyEE0UsWAwC2i2• 9 years ago

It depends on the reader's amount of "vocabulary". Why write more complicated code if it is just Cofree? DRY.

OTOH, how many elements should the reader's vocabulary have to enable him to read other's people code?

mixedCase• 9 years ago

From https://hackage.haskell.org/package/free-4.12.4/docs/Control... :

"A Comonad v is a cofree Comonad for f if every comonad homomorphism from another comonad w to v is equivalent to a natural transformation from w to f.

A cofree functor is right adjoint to a forgetful functor.

Cofree is a functor from the category of functors to the category of comonads that is right adjoint to the forgetful functor from the category of comonads to the category of functors that forgets how to extract and duplicate, leaving you with only a Functor."

So I take it you believe that a degree in category theory is the bare minimum for people to expect to be able to understand other people's code? The layman interpretation of "Avoid success at all costs" comes to mind.

MichaelBurge• 9 years ago

Cofree in general I use all the time, especially in compilers. The Generic and Binary Cofree instances were lifted straight out of a decompiler I'm supposed to be working on. The most common reason is to get Traversable and Plated instances:

https://hackage.haskell.org/package/lens-4.15.4/docs/Control...

For the blockchain stuff specifically, I suppose I didn't really use them too heavily in this article. So you could argue they aren't currently doing a whole lot of good.

I'm not actually certain if people prefer seeing the heavier types that I default to in real code(to avoid refactoring later), vs. types that are as simple as needed but might need to change as the program evolves. The first choice lets people who already know Haskell learn something from it, while the second makes beginners less confused.

pseudonom-2• 9 years ago

FWIW, I appreciated the example of Cofree in use.

pseudonom-2• 9 years ago

Actually, I realized I follow the "abstract recursion out of your structures" intuition but don't really realize why you chose Cofree instead of some of the other options:

    import Control.Monad.Free
    import Control.Comonad.Cofree
    import Data.Functor.Foldable

    data A f
      = ANil
      | ACons f
    type AList a = Cofree A a
    a :: AList Int
    a = 1 :< ACons (2 :< ACons (3 :< ANil))
    
    data B a f
      = B a f
    type BList a = Free (B a) ()
    b :: BList Int
    b = Free (B 1 (Free (B 2 (Free (B 3 (Pure ()))))))
    
    data C a f
      = CCons a f
      | CNil
    type CList a = Fix (C a)
    c :: CList Int
    c = Fix (CCons 1 (Fix (CCons 2 (Fix (CCons 3 (Fix CNil))))))

You wanted to ensure it's non-empty? Something about the actual Comonad (extend, etc) interface?

rev_null• 9 years ago

I think the opposite could be said. That the C++ implementation hides the simplicity of the blockchain in a language that lacks powerful abstractions and prevents code reuse.

If cofree seems like it isn't programming, that is only because this style of code helps avoid the need for it.

thinkpad20• 9 years ago

I agree and disagree. There is nothing about the usage of Cofree and other similar concepts which is "not programming". I think it's a completely viable way to write software within a particular scope (e.g. depending on the team that will work with the internals of the code, and whether the users of the library are to be required to understand the concept). If it provides the correct abstraction and can lead to more performant, maintainable and/or readable code (which is of course subjective), then by all means.

That said, I agree that the article doesn't spend a great deal of time explaining the concepts, whether blockchain itself or the category theory it's using, leading to a sense (for me) of being overly terse and coming across as a bit pompous. Although, I realize that for a certain audience there's nothing pompous about this at all and it might seem perfectly reasonable.

jcranberry2• 9 years ago

Coming from a math background, this actually reads as very expository and not at all pompous.

macsj200• 9 years ago

Initially read submission site as malbolge.us

ngcc_hk• 9 years ago

any other language? Python and lisp would be interesting.

Narhem• 9 years ago

Python: https://github.com/llSourcell/The_Power_of_the_blockchain/bl...

Relevant video: https://www.youtube.com/watch?v=LZEHOlZY2To

qaezel• 9 years ago

https://github.com/input-output-hk/cardano-sl

Rolling Your Own Blockchain in Haskell

Related Stories