hs-libp2p: A Haskell Implementation of the libp2p Stack

Devcon 8 · 4 Nov 2026 · 6:18

Shouki Tsuda, a protocol researcher at Nyx Foundation, presents hs-libp2p, a Haskell implementation of the libp2p networking stack, as a way to add client diversity to Ethereum consensus clients. The talk argues that Haskell's pure functions, strong static types and immutable data, plus software transactional memory for shared state such as Yamux stream state, make networking code more robust. The implementation partially supports QUIC, is not yet in production, and the work extends to post-quantum signatures and key exchange, with a workshop on Friday.

Speakers

Topics

From Devcon 8, hosted by Ethereum Foundation.

Transcript

[music] [music] Hey guys, how everyone? Uh, here is Shi from Nyx Foundation. So today I'm talking about my current work HSL repeat. So does anyone know about the Huskell? No. Nice, nice, nice. And okay, let's move on to my topic. So in terms of the resion we using the lipid zippy on the consensus client and the lipid is a protocol stack for pipes and a bunch of network protocol supports and uh in the consensus client each client implement different languages like a

prism using the go and lighthouse and garden implemented in last also they choose the lipid in go or last uh once for example uh prism has a bugs in go repeat it's collapsed prism networks but uh if you uh if the any other language is also implemented in each client the bug would be not effect for entire network this is a client diversity however as you can see there is no functional programmings so I introduce and uh introduce a new paradigm for uh with the program uh uh functional

programming. So Haskell is a good fit for robust uh system like a blockchain or uh financial system. Uh for example, you can find a cardon blockchain uh which main client is implemented in Huskll. So I think it's good work for blockchain as well and ethereum. uh they have a big property like pure functions and strong static types and main important so usually it's uh output uh same output and also they have a strong static types so uh the compiler rejects the do not uh undefined behavior like uh for example r using the

undefined but huskell do not have such kind of things so it's more robust for the by default and each data is immutable. So once you your value is implemented in the huskell each data is uh easy to flop and there are mistakes but it's easy to understand for AI because compiler reject such kind of undefined behavior and the compilers uh protect that kind of slope. So here's a example of the uh stream state which is defined in Yamox which is a max preexource and uh you can see kind of stream or kind of

the scene and local crosser which is a life cycle of a stream state and each stage is defined by static datas and you can see the transaction value which is bottom top bottom size and which is a shared variable that only state SDM transaction can change. What is STM is a software transaction memory. So if you protect self concurrency uh SDM is useful in HCO that is that protect the thread up shared state or or nothing. So we do not need a logs locks or something like that to make concurrencies.

So currently our implementation support the calia dtory build hash table implementation and which is pass the or test with python repeat or neo or something like that. So uh also we support a quick protocol which is a main use uh main option on consensus client. However it's partially pass the functions. So we need to implement the B transfer and it's just only interact with gorp.

So yeah our our lip is not in production. So we need to make more implementations and uh involve any other P2P guys. Also we try to migrate a post quantum signature or key exchanges. This part is not uh not specified at now. Uh yeah. Oh and uh we have a workshop tomorrow and you uh sorry on Friday. So if you want to understand what happened in postquantum signature or postquantum key exchange in P2P layer, please feel free to join us.

Uh yep, that's it for me. Thank you so much. >> Beautiful. Thank you very much, Yuki. Now, we're going to have time for about one question here if anyone wants me to throw the box. [laughter] >> Nice catch. >> Uh do you have or plan to have uh interrupt testing with uh other implementations of flip? >> Uh you mean the I have uh interact with any other clients implement?

>> Yeah. Yeah. Yeah. Yeah. Exactly. >> Uh yeah, for now we don't have any specific plan but uh we try to unify test with go or just not only for but also last or something like that in client things we do not integrate with any other clients for now. >> Mhm. >> Just only for P2P networks. Yeah. >> Right. Okay. Yeah. Uh we'll try I'll try to cut you to chat later. >> Thanks so much. >> Beautiful. Thanks Jiannis. Uh time for one last question. It looks like you're free. You >> Thank you.

>> Thank you very much for the talk, Suki. And you're welcome. [music]