An alternative Rust node client for the Cardano blockchain. Aimed as an entrypoint for client applications initially, it aspires to become a full block-producing node running side-by-side with the Haskell nodes to further increase the decentralisation of the platform while fostering its rich open source ecosystem.
One of the core objectives is to achieve a full block-producing Cardano node which can run side-by-side the existing Haskell nodes in a fully interoperable manner. The project is ambitious and spans over many areas such as networking, cryptography or language theory. It is developed from several parts each covering a different aspect of the node and its surrounding ecosystem.
Besides, Amaru is also geared towards developer experience and aims at providing easy to grasp interfaces using widely spread technologies such as gRPC while maintaining compatibility with the strong ecosystem of middlewares, such as Ogmios or Oura, that constitutes the backbone of Cardano services.
Matthias Benkort Technical Director @ Cardano Foundation 
Arnaud Bailly Technical Architect @ Cardano Foundation 
Pi Lanningham CTO @ Sundae Labs 
Damien Czapla Project Manager @ Open The Lead A node capable of synchronizing the chain from a (remote) trusted peer, and serve the data to client applications through an API query layer.
Such a node is most useful for decentralised applications building on the blockchain. It doesn't however take part in the consensus nor help to propagate blocks on the network.
A full relay node as an entrypoint to the network is still required at this point. This first phase is fully demonstrated by Dolos: a data-node written in Rust and whose core modules will be re-used for the development of Amaru.
A node capable of synchronizing the chain from a remote trusted peer while maintaining its own state and performing some ledger validations. So while it can only follow a single chain (provided by its single peer), it is fully autonomous in validating that this chain is conform to the protocol.
It can, in particular, validate a slot-leader schedule and check for consensus rewards in full autonomy. Such a node is most useful as a step towards a relay. It doesn't however take part in the consensus nor help to propagate blocks on the network yet.
A node capable of validating blocks seen on the network and propagate them by taking part in the p2p gossiping between nodes. It can also seemingly follow the chain from multiple peers by performing adequate chain selection.
Such node doesn't yet take part in the consensus and cannot produce blocks. It can however fully replace any relay. From the perspective of any external observer, it is a Cardano relay node.
A node that can produce blocks and take part to the consensus. It can monitor the leader schedule, manage a mempool, forge blocks and follow protocol updates (hard-forks).
A full node is not however capable of validating the historical chain. Instead, it always bootstrap from a snapshot constructed from an archive node.
At this point our node should be able to do everything the Haskell node does but with less resources usage and with better performance on most aspects of execution.
The recording from the demo happening live at the end of the 2nd node diversity workshop in Toulouse.
The demo showcases the latest progress with the chain synchronisation and conformance tests, as well as an update on the consensus simulation and implementation.
A demo showcasing the latest progress on the ledger rules and the Rust-agnostic testing approach used for conformance. Then, we dive into some preliminary visualisation of the simulation engine, with auto-generated sequence diagrams and a terminal user interface that allows exploring execution traces.
Finally, another look at some of the Amaru metrics, obtained from running a cluster of Amaru nodes talking to one another. This demonstrates how our observability stack is particularly well suited for aggregating distributed traces from multiple processes.
First, an overview showcasing the latest progress on deterministically simulating the consensus, using pre-generated blockchain trees.
Then, a tour of the ledger rules and the separation of concerns between block validation and state management, and how Amaru tackles this nicely.
Finally, an update on the ongoing work on the Peer-to-Peer (P2P) networking stack being designed not only for Amaru, but for the wider Rust blockchain ecosystem.
Three contributions covering:
Showcasing Amaru's on-disk ledger storage, solving a long-standing challenge of the Cardano node. The ledger state in this demo is comprised of the entire UTxO, stake pools parameters and registrations, rewards accounts and delegations. It is tracked throughout block application and persisted on-disk efficiently with regular snapshots at each epoch boundary.
While it doesn't yet calculate rewards at the epoch boundary, the on-disk state now contains all elements necessary to the calculation of rewards. It thus becomes the immediate next step.
A simple pipeline showcasing an Amaru node fetching blocks from the network, validating their header (VRF & KES) and forwarding them to an in-memory ledger performing UTxO management and phase-2 validations.