Youngjoon Lee
8449c81d0f
Mixnet PoC base branch (#316)
* Add `mixnode` and `mixnet-client` crate (#302) * Add `mixnode` binary (#317) * Integrate mixnet with libp2p network backend (#318) * Fix #312: proper delays (#321) * proper delays * add missing duration param * tiny fix: compilation error caused by `rand` 0.8 -> 0.7 * use `get_available_port()` for mixnet integration tests (#333) * add missing comments * Overwatch mixnet node (#339) * Add mixnet service and overwatch app * remove #[tokio::main] --------- Co-authored-by: Youngjoon Lee <taxihighway@gmail.com> * fix tests for the overwatch mixnode (#342) * fix panic when corner case happen in RandomDelayIter (#335) * Use `log` service for `mixnode` bin (#341) * Use `wire` for MixnetMessage in libp2p (#347) * Prevent tmixnet tests from running forever (#363) * Use random delay when sending msgs to mixnet (#362) * fix a minor compilation error caused by the latest master * Fix run output fd (#343) * add a connection pool * Exp backoff (#332) * move mixnet listening into separate task * add exponential retry for insufficient peers in libp2p * fix logging * Fix MutexGuard across await (#373) * Fix MutexGuard across await Holding a MutexGuard across an await point is not a good idea. Removing that solves the issues we had with the mixnet test * Make mixnode handle bodies coming from the same source concurrently (#372) --------- Co-authored-by: Youngjoon Lee <taxihighway@gmail.com> * Move wait at network startup (#338) We now wait after the call to 'subscribe' to give the network the time to register peers in the mesh before starting to publish messages * Remove unused functions from mixnet connpool (#374) * Mixnet benchmark (#375) * merge fixes * add `connection_pool_size` field to `config.yaml` * Simplify mixnet topology (#393) * Simplify bytes and duration range ser/de (#394) * optimize bytes serde and duration serde --------- Co-authored-by: Al Liu <scygliu1@gmail.com> Co-authored-by: Daniel Sanchez <sanchez.quiros.daniel@gmail.com> Co-authored-by: Giacomo Pasini <Zeegomo@users.noreply.github.com>
nomos-node
Nomos blockchain node mvp
Project structure
nomos-core
: Nomos core is the collection of essential structures for the Nomos mvp and experimental nodes.nomos-services
: Nomos services is the collection of components that are used as building blocks of the Nomos node prototype and the experimental nodes.- consensus
- log
- http
- mempool
- network
- metrics
nodes
: Nomos nodes is the collection of nodes that are used to run the Nomos mvp and experimental nodes.nomos-node
: main implementation of the Nomos mvp node.mockpool-node
: node with single mempool service, used to measure transaction dissemination.
Services
The Nomos node uses Overwatch
as its main internal framework. This means that services request communication channels
to other services to interchange information through a specified messaging API.
Service architecture
Most of the services are implemented with the same idea behind. There is a front layer responsible for handling the Overwatch
service
and a back layer that implement the actual service logic.
This allows us to easily replace components as needed in a type level system. In any case, a node can be setup in a declarative way composing the types. For example:
...
#[derive(Services)]
struct MockPoolNode {
logging: ServiceHandle<Logger>,
network: ServiceHandle<NetworkService<Waku>>,
mockpool: ServiceHandle<MempoolService<WakuAdapter<Tx>, MockPool<TxId, Tx>>>,
http: ServiceHandle<HttpService<AxumBackend>>,
bridges: ServiceHandle<HttpBridgeService>,
}
Docker
To build and run a docker container with Nomos node run:
docker build -t nomos .
docker run nomos /etc/nomos/config.yml
To run a node with a different configuration run:
docker run -v /path/to/config.yml:/etc/nomos/config.yml nomos /etc/nomos/config.yml
Description
Languages
Rust
99.3%
Groovy
0.3%
Dockerfile
0.3%