feat: update and fixes to rfcs part 1

src/RFC-0001_overview.md

@@ -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).
@@ -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.
 
@@ -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.
@@ -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. 
+Blocks are produced every 2 minutes, on average.  
 
 ### The role of the base layer
 
@@ -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.
 
 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
 
@@ -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.

src/RFC-0110_BaseNodes.md

@@ -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).
@@ -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:
 
@@ -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;
 
@@ -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.
@@ -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: 

src/RFC-0111_BaseNodeArchitecture.md

@@ -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).
@@ -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. 
@@ -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.
 
@@ -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 
@@ -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.
 
@@ -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
@@ -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    |