
Rolling Your Own Blockchain in Haskell - nicolast
http://www.michaelburge.us/2017/08/17/rolling-your-own-blockchain.html
======
lambdaxdotx
Here is another "minimum viable" blockchain implementation in Haskell:
[https://github.com/adjoint-io/nanochain](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.

------
qaezel
[https://github.com/input-output-hk/cardano-sl](https://github.com/input-
output-hk/cardano-sl)

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

~~~
imdsm
[https://news.ycombinator.com/item?id=14659775](https://news.ycombinator.com/item?id=14659775)

------
ngcc_hk
any other language? Python and lisp would be interesting.

~~~
Narhem
Python:
[https://github.com/llSourcell/The_Power_of_the_blockchain/bl...](https://github.com/llSourcell/The_Power_of_the_blockchain/blob/master/blockchain.py)

Relevant video:
[https://www.youtube.com/watch?v=LZEHOlZY2To](https://www.youtube.com/watch?v=LZEHOlZY2To)

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

~~~
MichaelBurge
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...](https://hackage.haskell.org/package/lens-4.15.4/docs/Control-
Lens-Plated.html)

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

------
macsj200
Initially read submission site as malbolge.us

------
cyphar
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/](http://joeyh.name/code/)

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

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

~~~
tree_of_item
Haskell takes a stand against _implicit_ side-effects, letting you see what a
function is capable of doing in its type. It's really weird to suggest that
performing side-effects in such a language is strange or awkward or cute or
whatever. Doing those things is the whole point of writing programs.

