Twitter | Pretraživanje | |
\u221e
Excited to share this blog post about some of the work and I have been doing at the , designing a new network stack for Zcash:
We give a deep dive into the network architecture of Zebra, the Foundation's Zcash node implementation
Zcash Foundation Zcash Foundation @ZcashFoundation
Reply Retweet Označi sa "sviđa mi se" More
\u221e 28. sij
Odgovor korisniku/ci @durumcrustulum @ZcashFoundation
as mentioned in the post, our goal for Zebra is to support the core strength of Zcash – its best-in-class cryptography – by placing it on a solid foundation, providing a modern, modular implementation that can be broken into components and used in many different contexts.
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @hdevalence
for instance, we'd like the networking layer to be useful not just for running a node but also for running a network crawler / monitoring infrastructure, for the chain data structures to be useful for our pegzone project, etc.
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @hdevalence
but because the existing Zcash tooling is built on top of legacy Bitcoin code, this is extremely difficult and cumbersome, so a key part of this project is re-grounding the Zcash cryptography on a modern foundation.
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @hdevalence
as a Bitcoin fork, Zcash inherited Bitcoin's networking stack, and both the protocol and its implementation leave a lot to be desired.
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @hdevalence
so instead, we define our own internal request/response protocol, and then perform per-peer translation between our protocol and the legacy Bitcoin protocol.
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @hdevalence
unlike zcashd or bitcoind, which maintain one state machine for all connections, this means that we can isolate the connection state for each peer, and the state space is much smaller and easier to reason about.
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @hdevalence
as a nice side effect, because connection state is isolated and each connection is an independent async task, we're automatically immune to the `ping` attack on Zcash, even though we chose this design before that attack was published :)
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @hdevalence
then, we provide a connection pool that load-balances outbound requests over all available peers, so that the rest of our code doesn't need to know about individual peer connections.
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @hdevalence
the size of the connection pool is dynamically determined by backpressure, growing when outbound request demand is high and shrinking to shed inbound request load.
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @marius
this is all made possible by Tower (), which provides a vocabulary for writing generic service-handling code, based on the ideas from 's _Your Server As A Function_:
Reply Retweet Označi sa "sviđa mi se"
\u221e 28. sij
Odgovor korisniku/ci @marius
and thanks to Monodraw there's even a nice diagram:
Reply Retweet Označi sa "sviđa mi se"