Parano1d v2. Capacity and consensus

A proof-native block has to fit two budgets. Its transactions must fit the transition relation, and the proof of that relation must be practical for the machines producing and verifying the network. Increasing the number printed beside “transactions per block” solves only the first half of that problem.

Parano1d v2 makes the relationship explicit: a default Small class, an optional Large class, the same contract core in both, and a 30-second block target. Capacity, proof construction and consensus timing form one design.

Start with the page

The physical unit is a Tx8x2 page: up to eight inputs and two outputs, encoded in 323 bytes. An ordinary payment with one input and two outputs fits one page. A larger logical payment can join pages through PagedSpend, retaining one transaction identifier, authorization capsule, fee and receipt.

Page count therefore measures physical capacity. Logical transaction count depends on the workload. A consolidation can use several pages; a contract call uses one page and consumes one exact contract output. The active input limit applies across the entire block, including both kinds of work.

The three limits apply together. Small can hold 63 ordinary one-page payments, 63 calls, or a mixture totalling 63 pages. Large can hold 206 one-page payments, or 63 calls plus 143 one-page payments, provided the combined inputs fit 504. Large provides more payment room around the same contract workload.

The primary coinbase is separate. An additional mandatory system page, when required, uses one of those positions, leaving 62 or 205 user pages. An ordinary logical transaction can span at most 128 pages, further restricted by its block class and the shared input budget.

One contract core, two production choices

The parameter m identifies the padded binary proof domain: m23 has $2^{23}$ positions, m24 has $2^{24}$. Those positions pay for the whole recursive relation: authorization, exact State updates, contract execution, prior-proof verification and the other consensus checks. They are not transaction slots.

Both classes implement the same 16-instruction contract core with two persistent counters. A program accepted under Small has the same meaning under Large. Application developers do not select a weaker execution environment to reach ordinary nodes.

A producing server enables Large with --v2-large-blocks. The flag permits fee-based class selection; it does not force every candidate into Large. The GUI has no corresponding switch. Every validating node accepts and verifies either class under the same consensus rules.

This matters economically. Larger proving work must be worthwhile for the producer. An almost empty block does not become cheap in direct proportion to its transaction count: the selected class still proves its fixed relation. A default that depends on every miner choosing the largest possible workload would be a poor fit for that cost structure.

What thirty seconds means

Block production still follows the atomic path: construct the exact candidate, prove its transition, freeze the template, then search proof-of-work nonces. An accepted block contains both the block and its matching HistoryStep terminal. There is no second chain tip waiting for proofs to catch up.

The 30-second target describes the network's mean block interval. It includes the full production path. It is neither a fixed allowance for proving followed by another 30 seconds of mining, nor a promise that any particular machine will produce a block every half minute.

At that target, 63 one-page payments per Small block correspond to 2.1 payments per second; 206 per Large block correspond to about 6.87. Both classes allow at most 2.1 contract calls per second at the target. These are workload-specific capacity ceilings. Actual throughput also depends on class selection, multi-page transactions, available inputs, proving time and block arrival times.

The clocks around the block

Changing the interval affects every rule whose duration is expressed in blocks. V2 keeps those quantities explicit and adjusts the difficulty schedule across the activation boundary.

ASERT counts the old and new target intervals on their respective sides of the fork. Candidate-height rule selection is repeated after a reorganization. A deadline in a contract uses its inclusion height, so “one day” means a nominal 2,880 blocks and still needs confirmation headroom.

A bounded network object

The terminal transport cap remains 1,100,000 bytes. The v2 bounds are 1,014,132 bytes for Small and 1,081,396 for Large. Increasing execution capacity does not silently enlarge the terminal a peer must accept.

The first v2 proof binds to the authenticated last pre-v2 block. The transition release carries both matrix generations. The retirement mechanism supports later builds that omit the old matrices while preserving the authenticated connection to the earlier chain. Removing old files cannot mean replacing that connection with an assumed snapshot.

Likewise, a Large block's proof obligations remain represented in subsequent history. The verifier can cache exact carried claims it has already authenticated, avoiding repeated work while continuing to verify new claims and transitions. Class switching preserves the proof chain.

Capacity with a defined cost

V2 gives the network a larger default payment budget and a real contract budget, while making the more expensive production choice explicit. The same limits govern admission, block construction, verification and the application's view of available capacity.

The resulting profile is concrete enough to build against: 30-second blocks, one contract core, two production classes, bounded terminals and a height-authenticated transition. The performance record provides measurements with their exact workloads and hardware; the parameter reference gives the complete limits.

Continue with Parano1d v2. Tokenomics, then From live value to live rights.