Introduction
Each account keeps track of a nonce in a transaction. A nonce is a counter that can only be used once and increases with each confirmed transaction. Every transaction contains the sender’s current nonce. The protocol requires that each account use each nonce value at most once.
It is used to construct and develop blockchain technology. In general, blockchain platforms use one type of transaction that is known as sending an order using a nonce to recognize that the transaction is being verified and that a block is confirmed. The nonce 0-based increases incrementally for each transaction.
Mathematical Proof of Nonce Ordering
Let’s prove that nonces have to be processed in order using mathematical induction. Let P(k) be a propositional function which may or may not be true for every natural number integer k. It is based on the rule of deduction that P(k) is true for all natural numbers k (denoted as ℕ), if P(0) and for all k, P(k) implies P(k + 1) are true, then for all k, P(k) is true {0,1,2,…}.
The induction has two parts or cases:
- Base (Initial) Step: this step as a previous step, so the previous step is to verify that P(k) is true,
P(0)is true, and - Inductive Step: This is to prove the following assertion, which is to verify the conditional statement P(k) implies P(k + 1) is true for all k ∈ N. If P(k) is true, then P(k + 1) is true.
then P(k) is true for all 𝑘 ∈ 𝑁
The Proof Theorem
- First, Base case k = 0, P(0) is true.
From a valid account no nonces have been used, and the stored account nonce is 0. The first valid transaction from this account has to use nonce 0. Once it is confirmed, the stored nonce becomes 1.
-
Then, the miner or validator knows that P(2) is true for the next transaction because P(1) enforces P(2).
-
Inductive step, Assume P(k) holds for some k ≥ 0. That is it, all transactions with nonces 0,1,…,k have been processed exactly once and in sequence, and
-
Thus, the account’s stored nonce P(k + 1), which cannot be false.
Thus, when the first transaction holds nonce 1, the second transaction has to hold the next larger integer. A transaction from an account is valid only if its nonce equals the stored account nonce.
Transaction Processing
From sender to miner/validator, each transaction is stored in a queue known as a memory pool. If the transaction has enough fee and is error-free, and if the nonce is the next in sequence, this transaction gets verified. Then the sender can send the next transaction with a new nonce. An account-based platform such as Ethereum allows the sender to submit multiple transactions, but they can only be confirmed in nonce order.
There is no overwritten nonce once a transaction is confirmed on-chain that nonce can never be reused. An overwrite can happen in the mempool when two pending transactions from the same account use the same nonce. If one transaction offers a higher fee, miners prefer it to be in a block, but the other transaction with the same nonce gets dropped. Thus, the nonce is a unique identifier for each confirmed transaction and has to be processed in order to avoid double-spending and replay.
Errors with Nonces
Errors occur with nonces in three cases:
- Reusing nonce: The same nonce is used on the next transaction. The next transaction trys to submit a nonce that was already confirmed. This is always invalid.
- Duplicating nonce: Two pending transactions share the same nonce and when they are used with the same nonce from the same account, only one will be confirmed.
- Non-sequential nonce: Leaving a gap between nonces will not be processed until the gap is closed; however, if a missing transaction occurs in a gap due to a lower fee on a transaction or if a miner/validator drops it after a timeout, this will cause a non-sequential nonce.
The verification rule does not allow skipping the sequence order of nonces. Additionally, the blockchain platform always tracks accounts’ nonces. Afterwards, all transactions with a lower nonce can never be used again. This prevents sending a transaction that was previously sent and, therefore, is one way of reducing and stopping the opportunity for replay attacks.
Protocol Idea
The idea of the protocol is to ensure that the transaction has been verified and received currently before initiating a new nonce for the next transaction. The protocol obliges strict nonce ordering.
For example, node A sends transactions with nonces from 0 to n - 1 in the first N transactions. The nonce is satisfied with equal opportunity on:
N = N_min(t1) + n - 1
where the transaction has N = n - 1 and N_min at the time t1 is 0; where n is the number of transactions that have been verified. If node A sent t1 and if N_min is 0, then the next transaction will be at t2, where:
t2 = N_min(t1) + n
A miner/validator cannot accept or verify a transaction (i + n) until transaction (i) is verified. A new account starts with N = 0 as an initial value. If the sender (from the same account) continues to send more than one transaction at one moment, all transactions can get verified in the order as numbered sequentially, no matter what gas fee the next transaction has.
Analysis of Using This Algorithm in the Inductive Proof
If the protocol only allows one transaction per account at a time, the account has to wait for each transaction to be confirmed before sending the next transaction. Also, if one account transmits a lot of transactions, those transactions will wait to be confirmed, which evolves over time. This strategy is not very useful for modern transactions because this protocol only uses nonces to provide basic reliability, and the performance is completely slow and has limited possibility.
Suggestions for Improvement
The suggestion is aabout correctness of nonce transactions to bring questions to the table to work towards a solution such as a contract memory pool. Validating multiple transactions from one account can be specified and verified by using an axiom system of temporal logic for safety and liveness to be satisfied.
Liveness: the live algorithm always continues to verify a nonce in the correct order and that means the protocol keeps making progress and is accepting a new transaction and verifying this transaction in the correct order.
Safety: In the current transaction, a safe algorithm never verifies an incorrect nonce and that means the protocol never allows to confirm a transaction out of the correct order.
Slide contain nonces of line slide s₁, s₂, …, sₙ. This slide is called slide size in geometric theory, as window (slide) size, thanks to a Go-Back-N and Selective Repeat protocols. The previous protocol allows only one transaction to be verified at a time in an account. To allow more than one transaction at a time from the same account, a protocol uses a range of transactions, and each range has a nonce that is known by the miners and the sender as a parameter that determines how many transactions can be sent.
Smart Memory Pool Mechanism
The user can send a slide that contains transactions, and each transaction has its own nonce. It has to ensure that the transferring amount is less than or equal to the account balance, and each transaction has a different nonce in an account. Thus, there are two nonces:
- Slide Transaction Nonce
- Transaction Nonce
Slide Transaction Nonce manages the logic and allows to process in parallel (within the window). Both count for an account. When a slide is filled with three transactions and each transaction contains a nonce, a miner will not accept or verify slide (i + N) from an account until the slide has been verified.
The slide of N contains t transactions, from t to t + n - 1, that the transmitter has sent. This protocol uses a mechanism where a range of transactions can be sent within a slide protocol, which keeps track of two integer variables:
- N_min represents the lower bound
base. - N_max represents the upper bound
base + WINDOW_SIZE.
The smallest transaction nonce is N_min that has not been verified. The next transaction nonce is N_max to be verified and accepted. This is similar to the previous protocol, but the goal is to allow N_min to N_max - 1. The nonce, N, is sent in the header of the slide in each transaction. An account or a smart contract sets the integer variables N_min and N_max to 0. This requires additional functions for rearrangement. The verified transactions must also be able to identify the block with which they are associated. Every address account uses two integer variables, N_min and N_max, to keep track of its operations. The smallest transaction nonce is N_min that has been verified. The next transaction nonce is N_max, which is varied. This is similar to the previous protocol, but the goal is to transmit N_min to N_max - 1.
Conclusion
This article fully explores transaction nonces and their key role in blockchain ordering. Delving into the mathematical proof underscores the need to maintain sequential nonce order to ensure transaction reliability and prevent double-spending and replay attacks. The discussion extends to transaction processing within blockchain systems, highlighting common nonce-related errors and their implications on network integrity.
The proposed protocol demonstrates an innovative approach to improving transaction processing by enabling multiple transactions to be processed concurrently. Through detailed protocol implementation logic validation, the article shows a deep understanding of blockchain technology’s theoretical and practical aspects.