docs: add authority claimer documentation to node

README.md

@@ -79,16 +79,16 @@ cargo test
 
 ## Architecture Overview
 
-The Cartesi Node is an event-based solution that may be depicted as follows:
-
-![Node architecture diagram](./docs/node-architecture.drawio.svg)
+The Cartesi Node is an event-based solution that runs the following microservices:
 
 The **Broker** is a Redis-based message broker that mediates the transferring of *Inputs*, *Outputs* and *Claims* between the Cartesi Node components.
 For details specific to the Broker and the available event streams, refer to the [Rollups Events project](./offchain/rollups-events/README.md).
 
 The [**State-fold Server**](./offchain/state-server/README.md) is the component responsible for tracking blockchain state changes and deriving *Inputs* from them to be processed.
 
-The [**Dispatcher**](./offchain/dispatcher/README.md) is the component that messages *Inputs* via the **Broker** to be processed elsewhere and submits *Claims* to the blockchain.
+The [**Dispatcher**](./offchain/dispatcher/README.md) is the component that messages *Inputs* via the **Broker** to be processed later on.
+
+The [**Authority Claimer**](./offchain/authority-claimer/README.md) is the component that submits *Claims* to the blockchain at the end of each epoch that contains at least one *Input*.
 
 The [**Advance Runner**](./offchain/advance-runner/README.md) is the one responsible for relaying *Inputs* to the **Server Manager** to be processed by the underlying DApp running in the embedded **Cartesi Machine**.
 The **Advance Runner** obtains the resulting **Outputs** and **Claims** from the **Server Manager** and adds them to the **Broker**.
@@ -97,40 +97,66 @@ The [**Indexer**](./offchain/indexer/README.md) consumes all *Inputs* and *Outpu
 
 The [**Inspect Server**](./offchain/inspect-server/README.md) is responsible for the processing of *Inspect* requests via HTTP.
 
-## Workflows
+## Rollups Node Features
 
-The Cartesi Node may act as a *User* (aka *Reader*) or *Validator* Node, hence performing different roles, which may be represented by different workflows.
+The Cartesi Node contains 3 main features, the combination of which defines the node capabilities.
 
-### Reader Flow
+### Input Processing
 
-In the Reader Flow, any *Input* read from the blockchain by the **State-fold Server** is received by the **Dispatcher** and relayed to the **Broker** through an input-specific stream.
+The Node is capable of processing rollup inputs stored in the blockchain.
+To do that, the node gets the inputs from the blockchain, sends them to the Cartesi machine, and stores the result in the node database.
+Once the input result is in the database, the node client can query the outputs in the GraphQL API.
+
+The *Input* is read from the blockchain by the **State-fold Server**, is then received by the **Dispatcher** and relayed to the **Broker** through an input-specific stream.
 The *Input* is eventually consumed by the **Advance Runner** and used to advance the state of the **Server Manager**, thus generating an *Advance* request to be processed by the underlying DApp.
 
 After finishing the processing, the DApp may generate a number of *Outputs*, which are eventually retrieved by the **Advance Runner** and fed back into the **Broker** through an output-specific stream.
 
 *Inputs* and *Outputs* are consumed from their respective streams by the **Indexer** and stored in a **PostgreSQL** database and may be queried by the DApp **Frontend** via a **GraphQL Server** instance.
 
-### Validator Flow
+### Claiming
 
-The Validator Flow may only be performed by *Validator* nodes.
-It complements the Reader Flow by generating *Claims* at the end of *Epochs*, which are generated by the **Server Manager**, and sent to the **Broker** by the **Advance Runner** through a claims-specific stream to be eventually consumed by the **Dispatcher** for being submitted to the blockchain.
+Claiming allows a node to be run as a *Validator* node.
+It complements the input processing by generating *Claims* at the end of *Epochs* that have *Inputs*, which are generated by the **Server Manager**.
+They are then sent to the **Broker** by the **Advance Runner** through a claims-specific stream to be eventually consumed by the **Authority Claimer** for being submitted to the blockchain.
 
-### Inspect Data Flow
+### Inspecting Data
 
 Every *Inspect* request sent by the **Frontend** via the Rollups HTTP API is captured by the **Inspect Server** and forwarded to the **Server Manager**, which queries the state of the underlying DApp via *Inspect* requests.
 
 Every request results in an *Inspect Response* that is returned to the **Inspect Server**, which sends it back to the **Frontend**.
 
-## Host mode
+## Execution modes
+
+The Cartesi Node may act as a *Reader*, a *Validator* or run locally as a *Host*, performing different roles, presented next.
+
+### Reader Mode
+
+The *Reader Mode* connects the node, however it doesn't submit claims to the blockchain, instead only reads and updates the state.
+It processes the input and provides the inspect API for queries.
+
+![Reader mode architecture diagram](./docs/reader-architecture.drawio.svg)
+
+To run the node in *Reader Mode*, one must have a Redis instance to act as the *Broker*, a PostgreSQL database instance and a GraphQL instance, and run the *State-fold Server*, *Dispatcher*, *Advance Runner*, *Indexer* and *Inspect Server*.
+
+### Validator Mode
+
+The *Validator Mode* has all the features of the *Reader Mode*, but can also submit claims through the [*Claiming Feature*](#claiming).
+
+![Validator mode architecture diagram](./docs/node-architecture.drawio.svg)
+
+To run the node in *Validator Mode*, one must start the services as described in the *Reader Mode* above, but also initiate the *Authority Claimer* service.
+
+### Host Mode
 
 The Cartesi Node may operate in a so-called *Host mode* when deployed locally for development purposes.
 
-In this case, the overall topology is very similar to the one presented in the [Architecture Overview](#architecture-overview) as depicted below.
+In this case, the overall topology is very similar to the one presented in the [Validator Mode](#validator-mode) as depicted below.
 
 ![Host mode architecture diagram](./docs/host-architecture.drawio.svg)
 
 The main difference is that the **Server Manager** is not present and, there's no **Cartesi Machine** available as a result.
-Their features are emulated by the **Host Runner**, which interacts with the **DApp Backend** being executed locally in the *host* to perform the Cartesi Node [workflows](#workflows).
+Their features are emulated by the **Host Runner**, which interacts with the **DApp Backend** being executed locally in the *host* to perform the Cartesi Node.
 
 ## Contributing
 

offchain/authority-claimer/README.md

@@ -0,0 +1,4 @@
+# Authority Claimer
+
+This service submits rollups claims consumed from the broker to the blockchain using the [tx-manager crate](https://github.com/cartesi/tx-manager).
+It runs at the end of every epoch, when new claims are inserted on the broker.

offchain/dispatcher/README.md

@@ -2,5 +2,3 @@
 
 This service generates rollups inputs from state changes in the blockchain detected by the state-server.
 These inputs are sent to the broker to be eventually used by the advance-runner.
-
-The dispatcher also submits rollups claims consumed from the broker to the blockchain using the [tx-manager crate](https://github.com/cartesi/tx-manager).