RFC30: Ensure that index is less than length in input since field using epoch.

rfcs/0030-ensure-index-less-than-length-in-since/0030-ensure-index-less-than-length-in-since.md

@@ -1 +1,61 @@
-In review, see <https://github.com/nervosnetwork/rfcs/pull/223>
+---
+Number: "0030"
+Category: Consensus (Soft Fork)
+Status: Draft
+Author: Ian Yang
+Organization: Nervos Foundation
+Created: 2021-02-04
+---
+
+# Ensure That Index Is Less Than Length In the Input Since Field Using Epoch With Fraction
+
+## Abstract
+
+This document proposes adding a new consensus rule to verify the `since` field in the transaction.
+
+As described in the RFC17, [Transaction valid since](../0017-tx-valid-since/0017-tx-valid-since.md), when a transaction input uses the epoch with fraction in the `since` field, the `value` is an encoded rational number `E + I / L`, where
+
+- `E` is the epoch number.
+- `I` is the block index in the epoch.
+- `L` is the epoch length.
+
+This RFC requires that when any transaction uses the epoch with fraction as the unit, the encoded number `E + I / L` is valid only if
+
+- `I` is less than `L`, or
+- `I` and `L` are both zero.
+
+If any `since` field is invalid, the transaction is rejected.
+
+## Motivation
+
+The `since` field prevents the transaction from being mined before an absolute or relative time.
+
+When the `since` field uses epoch with fraction number as the unit, the `value` is an encoded rational number `E + I / L`. If it is a relative time, the rational number is used as it is. But when it is the absolute time, the special rule, **Absolute Epoch With Fraction Value Normalization** as mentioned in RFC17, requires normalizing the number to `E + 1 + 0 / 1` when `I` equals to or is larger than `L`.
+This document suggests adding a new rule to verify that when `since` uses epoch as the unit, it must ensure that the index `I` is less than the length `L`.
+
+## Specification
+
+This RFC adds a new verification requirement on the transaction `since` field.
+
+When an input `since` field is present, and the `metric_flag` is epoch (01), the `value` part is the encoded number `E + I / L`. No matter whether the relative flag is `relative` or `absolute`, the number is valid if and only if
+
+- `I` is less than `L`, or
+- `I` and `L` are both zero.
+
+There are no changes to the rules in RFC17, except that **Absolute Epoch With Fraction Value Normalization** is no longer needed.
+
+## Test Vectors
+
+When `since` uses the absolute epoch `99 + 360 / 180`, and the current epoch is `100 + 0 / 180`, the transaction is mature using the old consensus rule but is invalid using the new rule.
+
+## Deployment
+
+The deployment can advance in two stages.
+
+The first stage will activate the new consensus rule, starting from a specific epoch. The mainnet and testnet will use different starting epochs and all other chains will use the new rule from epoch 0.
+
+The second stage is optional. After the new rule is active, and the blocks in the chain before activation can also pass the new consensus rule, the old rule is redundant and can be safely removed.
+
+## Backward compatibility
+
+The new rule is stricter than the old one thus it can be deployed via a soft fork. When most mining nodes have upgraded to the new version, the old version full nodes can keep up to date. Blocks generated by old version mining nodes may be rejected by new version full nodes.