Skip to content

feat: update and fixes to rfcs part 1 #162

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
SWvheerden merged 4 commits into from
Jun 10, 2026
Merged

feat: update and fixes to rfcs part 1 #162

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
36d67a6
wip
SWvheerden Apr 9, 2026
d831504
fix dan -> ootle
SWvheerden May 29, 2026
619ddb3
review
SWvheerden Jun 8, 2026
8681728
update wording
SWvheerden Jun 9, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 12 additions & 13 deletions src/RFC-0001_overview.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,6 @@

![status: stable](theme/images/status-stable.svg)

**Maintainer(s)**: [Cayle Sharrock](https://github.com/CjS77)

# Licence

[ The 3-Clause BSD Licence](https://opensource.org/licenses/BSD-3-Clause).
Expand Down Expand Up @@ -101,9 +99,9 @@ We can't have fast, cheap digital assets and also highly secure and decentralize
Tari overcomes this constraint by building two layers:

1. A base layer that provides a public ledger of Tari coin transactions, secured by PoW to maximize security.
2. A DAN consisting of a highly scalable, efficient side-chain that each manages the state of all digital asset.
2. A DAN consisting of a highly scalable, efficient side-chain that each manages the state of all digital asset, called the Ootle.

The DAN layer gives up some security guarantees in exchange for performance. However, in the case of a liveness
The Ootle layer gives up some security guarantees in exchange for performance. However, in the case of a liveness
failure (wherein parts of the DAN cannot make progress), the base layer intervenes to break the deadlock and allow
the DAN to continue.

Expand All @@ -127,7 +125,7 @@ cryptocurrencies such as Bitcoin:
> "Mimblewimble is the most sound, scalable 'base layer' protocol we know" -- @fluffypony

In addition to this, Tari has made some novel additions to the basic Mimblewimble protocol. Primarily, these were
invented to allow the DAN to be built on top of Tari, but have found some great applications generally:
invented to allow the Ootle to be built on top of Tari, but have found some great applications generally:

* TariScript. Similar to Bitcoin script, TariScript ([RFC-201], [RFC-202]) provides limited "smart contract"
functionality on the base layer protocol.
Expand All @@ -142,8 +140,9 @@ invented to allow the DAN to be built on top of Tari, but have found some great

#### Proof of Work

Tari is mined using a hybrid approach. On average, 50% of block rewards come from [Monero merge-mining],
while 50% come from the [Sha3x][RFC-131] algorithm. Blocks are produced every 2 minutes, on average.
Tari is mined using a hybrid approach. On average, 25% of block rewards come from [Monero merge-mining],
25& solo mined using RandomX, 25% mined using Cuckaroo 29 and 25% come from the [Sha3x][RFC-131] algorithm.
Comment thread
SWvheerden marked this conversation as resolved.
Blocks are produced every 2 minutes, on average.

### The role of the base layer

Expand All @@ -156,20 +155,20 @@ The Base Layer fulfils these, and only these, major roles:
code that they expect and includes functionality like version tracking.
4. Provides a global reference clock for the digital assets layer to help it resolve certain operational failure modes.

### Digital Assets Network
### Digital Assets Network, Ootle

The DAN is focused on achieving high speed and scalability while maintaining a high degree of decentralisation.
The Ootle is focused on achieving high speed and scalability while maintaining a high degree of decentralisation.

The DAN itself is made up of two conceptual levels. On the more fundamental level, the consensus layer uses
Cerberus and emergent HotStuff to reach consensus on state changes in the DAN in a highly scalable, decentralised way.
The Ootle itself is made up of two conceptual levels. On the more fundamental level, the consensus layer uses
Cerberus and emergent HotStuff to reach consensus on state changes in the Ootle in a highly scalable, decentralised way.

@Kelketek Kelketek May 31, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps we could link to RFC-0330?


A big, and probably the biggest, advantage of this approach is that assets in disparate smart contracts can easily
interact, without the need for slow, honey pot-shaped bridges.

Then there is the semantic layer, which is where the Tari contracts are compiled, run and verified inside sandboxed
Tari virtual machines.

Together, these levels provide that smart contract enabled digital assets layer, that we've simply been calling the DAN.
Together, these levels provide that smart contract enabled digital assets layer, that we've simply been calling the Ootle.

### Interplay of the layers

Expand All @@ -183,7 +182,7 @@ enormous;
imagine controlling every piece of inventory and their live statistics for a massively multiplayer online role-playing
game (MMORPG). The base layer is also too slow. If _any_ state relies on base layer transactions being confirmed, there
is an immediate lag before that state change can be considered final, which kills the latency properties we seek for
the DAN.
the Ootle.

It is better to keep the two networks almost totally decoupled from the outset, and allow each network to play to its
strength.
Expand Down
17 changes: 5 additions & 12 deletions src/RFC-0110_BaseNodes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,6 @@

![status: stable](theme/images/status-stable.svg)

**Maintainer(s)**: [Cayle Sharrock](https://github.com/CjS77), [S W van heerden](https://github.com/SWvheerden) and [Stanley Bondi](https://github.com/sdbondi)

# Licence

[The 3-Clause BSD Licence](https://opensource.org/licenses/BSD-3-Clause).
Expand Down Expand Up @@ -55,17 +53,12 @@ their general approach for doing so.

* [RFC-0140: SyncAndSeeding](RFC-0140_Syncing_and_seeding.md)

$$
\newcommand{\so}{\gamma} % script offset
$$

## Description

### Broad Requirements

Tari Base Nodes form a peer-to-peer network for a proof-of-work based blockchain running the [Mimblewimble]
protocol. The proof-of-work is performed via hybrid mining, that is merge mining with Monero and stand-alone SHA 3.
Arguments for this design are presented [in the overview](RFC-0001_overview.md#proof-of-work).
protocol. The proof-of-work is performed via hybrid mining, Arguments for this design are presented [in the overview](RFC-0001_overview.md#proof-of-work).

Tari Base Nodes MUST carry out the following tasks:

Expand All @@ -76,7 +69,7 @@ Tari Base Nodes MUST carry out the following tasks:
* connect to peer nodes to catch up (sync) with their blockchain state;
* provide historical block information to peers that are syncing.

Once the Digital Assets Network (DAN) goes live, Base Nodes will also need to support the tasks described in
Once the Ootle goes live, Base Nodes will also need to support the tasks described in
[RFC-0303_DAN](RFC-0303_DanOverview.md). These requirements may involve but are not limited to:
* maintain an index of validator node registrations;

Expand Down Expand Up @@ -123,7 +116,7 @@ The transaction is validated as follows:
* The transaction excess is a valid public key. This proves that:
$$ \Sigma \left( \mathrm{inputs} - \mathrm{outputs} - \mathrm{fees} \right) = 0 $$.
* The transaction excess has a unique value across the whole chain.
* The [Tari script] of each input must execute successfully and return the public key that signs the script signature.
* The [Tari script] of each input must execute successfully and return the public key that signs a valid script signature.
* The script offset \\( \so\\) is calculated and verified as per [RFC-0201_TariScript].

Rejected transactions are dropped without service interruption and noted in log files.
Expand Down Expand Up @@ -154,10 +147,10 @@ With an `S` of 1MiB and `N` of 16, the block and transaction body weights are as
| | Byte size | Natural Weight | Adjust | Final |
|-------------------|-----------|------------------------|--------|------------------------|
| Output | | | | |
| - Per output | 832 | 52 | 0 | 52 |
| - Per output | 832 | 52 | +1 | 53 |
| - Tari Script | variable | size_of(script) / 16 | 0 | size_of(script) / 16 |
| - Output Features | variable | size_of(features) / 16 | 0 | size_of(features) / 16 |
| Input | 169 | 11 | -2 | 9 |
| Input | 169 | 11 | -3 | 8 |
| Kernel size | 113 | 8 | 2 | 10 |

Pseudocode:
Expand Down
58 changes: 43 additions & 15 deletions src/RFC-0111_BaseNodeArchitecture.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,8 +4,6 @@

![status: stable](theme/images/status-stable.svg)

**Maintainer(s)**: [Cayle Sharrock](https://github.com/CjS77)

# Licence

[ The 3-Clause BSD Licence](https://opensource.org/licenses/BSD-3-Clause).
Expand Down Expand Up @@ -61,7 +59,7 @@ The major components are separated into separate modules. Each module exposes a

### Base Node Service

The Base Node Service fields requests for the local nodes chain state and also accepts newly mined blocks that are
The Base Node Service fields requests for the local node's chain state and also accepts newly mined blocks that are
propagating across the network. The service subscribes to NewBlock and BaseNodeRequest messages via the P2P comms
interface. These messages are propagated across the P2P network and can also be received directly from other nodes. The
service also provides a local interface to its functionality via an asynchronous Request-Response API.
Expand All @@ -72,8 +70,8 @@ The P2P message types this service subscribes to are:
node will validate it. Its action depends on the validation outcome:
* _Invalid block_ - drop the block.
* _Valid block appending to the longest chain_ - add the block to the local state and propagate the block to peers.
* _Valid block forking off main chain_ - add the block to the local state and propagate the block to peers.
* _Valid block building off unknown block_ - add the orphan block to the local state.
* _Valid block forking off main chain_ - add the orphan block to the local state.
* _Valid* block building off unknown block_ - add the orphan block to the local state. These blocks are only checked for PoW and other stateless checks.

* **BaseNodeServiceRequest:** A collection of requests for chain data from the node.

Expand All @@ -93,8 +91,8 @@ block. The mempool is ephemeral and non-consensus critical, and as such may be a
a large mempool is far more important for Base Nodes serving miners than those serving wallets. The mempool structure
itself is a set of hash maps as described in [RFC-0190]

When either the node reboots, or it synchronises a default number of 5 blocks, the Mempool sync service will contact peers and sync valid mempool transactions from them. After
it has synced this service runs to field such requests from other peers.
When either the node reboots or it synchronises a default number of 5 blocks, the Mempool Sync Service will contact peers and sync valid mempool transactions from them. After
it has synced, this service runs to field such requests from other peers.

The Mempool service handles Mempool Service Requests which it can receive from the P2P comms stack via its
subscriptions, via the Mempool RPC service and via an internal Request-Response API. All these interfaces provide the
Expand All @@ -108,13 +106,13 @@ following calls:

The Liveness service can be used by other modules to test the liveness of a specific peer and also periodically tests a
set of its connected peers for liveness. This service subscribes to `Ping` P2P messages and responds with `Pong`s. The
service gathers data about the monitored peer's liveness such as its latency. The `Ping` and Pong` messages also contain
a copy of this nodes current Chain Metadata for use by the receiving nodes Chain Metadata Service.
service gathers data about the monitored peer's liveness such as its latency. The `Ping` and `Pong` messages also contain
a copy of this node's current Chain Metadata for use by the receiving node's Chain Metadata Service.

### Chain Metadata Service

The Chain Metadata Service maintains this nodes current Chain Metadata state to be sent out via `Ping` and `Pong`
messages by the Liveness service. This node also monitors the Chain Metadata received from other peers in the `Ping` and
The Chain Metadata Service maintains this node's current Chain Metadata state to be sent out via `Ping` and `Pong`
messages by the Liveness Service. This service also monitors the Chain Metadata received from other peers in the `Ping` and
`Pong` messages received by the Liveness service. Once a full round of `Pong` messages are received this service will
emit this data as an event which the Base Node State Machine monitors.

Expand Down Expand Up @@ -147,18 +145,17 @@ be thread-safe.
### P2P communications
The Tari Peer to Peer messaging protocol is defined in [RFC-0172]. It is a fire-and-forget style protocol. Messages can
be sent directly to a known peer, sent indirectly to an offline or unknown peer and broadcast to a set of peers. When
a message is sent to specific peer it is propagated to the peers local neighbourhood and stored by those peers until it
a message is sent to a specific peer it is propagated to the peer's local neighbourhood and stored by those peers until it
comes online to receive the message. Messages that are broadcast will be propagated around the network until the whole
network has received them, they are not stored.

### RPC Services
Fire-and-forget messaging is not efficient for point to point communications between online peers. For these applications
the Base Node provides RPC services that present an API for clients to interact with. These RPC services provide a
Request-Response interface defined by Profobuf for clients to use. RPC also allows for streaming of data which is much
Request-Response interface defined by Protobuf for clients to use. RPC also allows for streaming of data which is much
more efficient when transferring large amounts of data.

Examples of RPC services running in
Base Node are:
Examples of RPC services running in the Base Node are:
- **Wallet RPC service**: An RPC interface containing methods used by wallets to submit and query transactions on a
Base Node
- **Base Node Sync RPC Service**: Used by the Base Node State Machine Service to synchronise blocks
Expand Down Expand Up @@ -194,6 +191,37 @@ A non-exhaustive list of methods the base node module API will expose includes:
* Block and transaction validation calls
* Block synchronisation calls

### HTTP Interface

The base node exposes an HTTP API built with [Axum](https://github.com/tokio-rs/axum). Interactive API documentation is
available via Swagger UI at `/swagger-ui`, with the OpenAPI specification served at `/openapi.json`.

The following endpoints are available:

| Method | Path | Description |
|:-------|:-----------------------------------|:-----------------------------------------------------|
| GET | `/get_tip_info` | Returns chain tip metadata and sync status |
| GET | `/get_header_by_height` | Retrieves a block header at a given height |
| GET | `/get_height_at_time` | Returns the block height for a given Unix timestamp |
| GET | `/get_utxos_mined_info` | Returns mining info for UTXOs identified by hash |
| GET | `/fetch_utxo` | Fetches a single UTXO by output hash |
| GET | `/get_utxos_deleted_info` | Returns deletion/spend info for a set of UTXOs |
| GET | `/transactions` | Queries a transaction by its excess signature |
| GET | `/sync_utxos_by_block` | Paginated UTXO sync starting from a header hash |
| GET | `/get_utxos_by_block` | Returns all UTXOs for a block by header hash |
| POST | `/json_rpc` | JSON-RPC 2.0 endpoint (e.g. `submit_transaction`) |
| GET | `/generate_kernel_merkle_proof` | Generates a Merkle proof for a kernel signature |
| GET | `/get_mempool_fee_per_gram_stats` | Returns fee-per-gram statistics from the mempool |

All endpoints use JSON request and response bodies. A global request body size limit of approximately 10 MB is applied,
though several endpoints disable this limit to support larger payloads. Caching behaviour is configurable per route.

The `/json_rpc` endpoint follows the [JSON-RPC 2.0](https://www.jsonrpc.org/specification) specification. Currently
supported methods:

* `submit_transaction` — Submits a transaction to the mempool. The response includes whether the transaction was
accepted, any rejection reason, and whether the node is synced.

# Change Log

| Date | Change | Author |
Expand Down
Loading
Loading