io-sim
-IOSim
simulator monad which supports asynchronous exceptions,STM
transactions andasync
interface, timers.io-classes
- type classes, all of them have instance for bothIOSim
andIO
.typed-protocols
- session type framework with support of protocol pipeliningshardagnostic-network
- shardagnostic network package which implements protocols which to run shardagnostic family of protocols, multiplexing layer.- The
cole-proxy
is a network protocol proxy between Cole and Sophie. It now lives in a separate repository.
We have two documents which describe various levels of the networking layer of the Bcc Sophie implementation:
-
Introduction to the design of Data Diffusion and Networking of Bcc Sophie
This document explains the technical requirements and key constraints for the networking layer of the Bcc Sophie implementation of Shardagnostic Optimum. This is a design document.
-
The Sophie Networking Protocol
This document is a technical specification of the networking protocol. It includes serialisation formats, necessary details of multiplexer and technical specifications of mini-protocols used by either node-to-node and node-to-client flavours of the protocol.
-
Specifically the section "Explore Bcc" is helpful, since it talks about the Bcc Architecture, Bcc Design Rationale, the Bcc Network, etc. Although the Bcc documentation is less detailed, it is a good place to start and refresh some more basic concepts about Bcc.
The API consists of three layers:
• mini-protocol api's, which are GADTs for each mini-protocol under Shardagnostic.Network.Protocol
; this hides heavy type machinery of session types. One only needs the typed Peer
type when one is using runPeer
or runPeerPipelined
function and each protocol exposes a function to create it (e.g. Shardagnostic.Network.Protocol.ChainSync.Client.chainSyncClientPeer
)
• callback ptcl -> channel -> m ()
where ptcl
is enumeration for each mini-protocol, this is either NodeToNodeProtocols
or NodeToClientProtocols
. The callback is wrapped in ShardagnosticApplication
GADT which allows to differentiate the initiator / responder (or client / server) callbacks.
• versioning which is a map from version numbers to the above callbacks and version data (the tricky part here is that version data type can be different between different versions; there is a simple way of building this map using a semigroup). You can use simpleSingletonVersion
if your application does not depend on negotiated version data. However, Shardagnostic.Network.NodeToNode
and Shardagnostic.Network.NodeToClient
expose V1
api which hides versioning from the caller.
- demo-chain-sync
- bcc-ping
- mux-demo
- demo-ping-pong
- named-pipe-demo (Windows only)
- demo-ntp-client
Instructions
To run a demo type:cabal run <DEMO_NAME> --
After --
you will need to pass arguments, when a demo is run without
arguments it will specify what arguments it needs.
Consensus layer of the family Shardagnostic blockchain protocols.
The shardagnostic-consensus/docs
folder contains documentation about the
consensus layer. Start with the
README.md.
-
The Bcc Consensus and Storage Layer
This technical report explains the design of the consensus and storage layer.
The consensus team uses stylish-haskell
>= 0.11.0.0 to format its code. This
is enforced by CI.
Either enable editor integration or run the following command to manually format all of the consensus code (but not the network code):
stylish-haskell -i `git ls-files -- 'shardagnostic-consensus*/*.hs' | grep -v Setup.hs`
Alternatively, call the script used by CI itself: https://github.com/The-Blockchain-Company/shardagnostic-network/blob/master/scripts/buildkite/check-stylish.sh
./scripts/buildkite/check-stylish.sh
When using Nix, you can use the following command, which will build and use
the right version of stylish-haskell
.
nix-shell --run ./scripts/buildkite/check-stylish.sh