Bls precompiles

.gitignore

@@ -1,9 +1,5 @@
 .DS_Store
-dist/
 node_modules
-_site
 vendor/
-fission.yaml
-.sass-cache
 __pycache__
 .venv

FIPS/fip-0086.md

@@ -334,6 +334,18 @@ type PowerTableEntry struct {
   Power BigInt
   Key BLSPublicKey
 }
+
+// PartialGossiPBFTMessage represents a GossiPBFT message with a zeroed out vote
+// value, and a precomputed MerkelizeValue of the original vote value.
+//
+// This key allows verification of the GossiPBFTMessage signature without needing
+// the specific chain tipsets represented by its Vote.Value.
+type PartialGossiPBFTMessage struct {
+  *GossiPBFTMessage
+
+  // VoteValueKey is the precomputed MerkelizeValue of the GossiPBFTMessage Payload.Value.
+  VoteValueKey []byte
+}
 ```
 
 Values for phase numbers are:
@@ -418,7 +430,7 @@ GossiPBFT(instance, inputChain, baseChain, committee) → decision, certificate:
 // Committee is implicitly used to calculate quora.
 
 01:  round ← 0
-02:  proposal ← inputChain  // CHain that the participant locally believes should be decided.
+02:  proposal ← inputChain  // Chain that the participant locally believes should be decided.
 03:  timeout ← 2*Δ
 04:  timeout_rebroadcast ← timeout + 1 // Any value larger than timeout, at implementation discretion.
 05:  value ← proposal // Used to communicate the voted value to others (proposal or 丄)
@@ -430,10 +442,13 @@ GossiPBFT(instance, inputChain, baseChain, committee) → decision, certificate:
 10:  while (phase != DECIDE)  {
        // QUALTIY
 11:    if (round = 0)
-12:      BEBroadcast <QUALITY, value>; trigger (timeout)
+         // The timeout for QUALITY may set to be longer than the other phases using a 
+         // multiplier. This is to increase the chances of collecting a strong quorum 
+         // of QUALITY messages and reduce potential hindrance on successive phases. 
+12:      BEBroadcast <QUALITY, value>; trigger (timeout * quality_timeout_multiplier)
 13:      phase ← QUALITY
 14:      collect a clean set M of valid QUALITY messages from this instance 
-           until HasStrongQuorum(proposal, M) OR timeout expires
+           until HasStrongQuorum(proposal, M) OR timeout * quality_timeout_multiplier expires
 15:      C ← C ∪ {prefix : IsPrefix(prefix,proposal) and HasStrongQuorum(prefix,M)}
 16:      proposal ← longest prefix ∈ C  // At least baseChain, or something longer
 17:      value ← proposal
@@ -687,6 +702,7 @@ The synchronization of participants within an instance is achieved with a timeou
 
 As an optimization, participants may finish a phase once its execution is determined by the received messages, without waiting for the timeout. For example, if a participant receives QUALITY messages from all participants, it can proceed to the next phase without waiting for the timeout. More generally, if the remaining valid messages to be received cannot change the execution of the phase, regardless of the values contained in the messages, then a participant may continue to the next phase.
 
+In the `QUALITY` phase, a $\Delta$ multiplier is applied to facilitate better propagation of proposals from all honest participants at the start of a GPBFT instance. This adjustment is because inadequate or delayed proposal propagation during this phase can significantly increase the likelihood of requiring additional rounds, thereby raising the chances of defaulting to the base decision. This issue is exacerbated in large networks with intermittent connectivity or message delivery throttling, leading to longer finalization times, which are undesirable.
 
 ### Synchronization of Participants across Instances
 
@@ -803,6 +819,77 @@ A smart contract will never accept a finality certificate earlier than those it
 
 Only one such smart contract is needed on a single blockchain execution environment, which can provide the resulting final tipset information to others.
 
+### Side-channel EC Chain Propagation
+In GPBFT protocol, each message contains at least one payload, with each payload holding a value that represents the EC chain being decided. This value makes up a large portion of the total message size with a high rate of duplicities throughout a typical instance progression. To significantly reduce the size of GPBFT messages and the bandwidth required for their propagation, a side channel is introduced to separately propagate a mapping between a chain's `MerkelizeValue` and the actual Value itself. Instead of directly propagating full GPBFT messages, a partial GPBFT message is propagated. This partial message includes all components except the EC chain value being decided, along with the `MerkelizeValue` corresponding to that chain.
+
+This approach reduces the size of GPBFT messages and allows for deduplication in EC chain value propagation. The use of `MerkelizeValue` ensures that the signature of partial messages remains verifiable without needing the actual chain being decided. Most validation processes can still be performed, except for checking the base tipset relative to the head of the previously finalized chain.
+
+Implementers need to buffer partial messages with unknown `MerkelizeValue` as well as discovered `MerkelizeValue`s with their unseen corresponding partial messages. Security recommendations include adjusting the priority of buffered data based on the progress of GPBFT to ensure timely processing and validation with a bound buffer size. This adjustment helps maintain the integrity and efficiency of the protocol while managing the propagation of EC chain values effectively.
+
+#### Partial Message Signature Verification
+
+The partial message signature verification process is the same as `GossiPBFT` message verification, except that the `MerkelizeValue` is used in place of computing it from the actual chain.
+
+#### Chain Exchange Protocol
+
+The chain exchange protocol facilitates the dissemination of EC chain values that are being decided among the participants.
+The chain exchange message format is as follows:
+
+```go
+type ChainExchangeMessage struct {
+  Instance  uint64      // ID of the GPBFT instance.
+  Chain     []ECTipset  // The vote value being decided.
+  Timestamp int64       // The timestamp at which the message was created.
+}
+```
+
+The instance ID identifies the GPBFT instance to which the chain value belongs. The chain value represents the EC chain being decided in that instance. The timestamp ensures message freshness and must be within `MaxTimestampAge` to be valid.
+
+The timestamp is adjusted to the current time, rounded down to the nearest multiple of the chain exchange `RebroadcastInterval`. This adjustment helps minimize the number of messages propagated across the network.
+
+The chain exchange protocol should ensure that the chain being decided is propagated to all participants within the $\Delta$-synchrony bound. Delays in propagation can lead to decisions defaulting to the base chain, but will not disrupt GPBFT progress since the base chain is known to all participants.
+
+Within each GPBFT instance, a chain broadcast is triggered by:
+1. **Phase Transition**: Immediately triggers a broadcast.
+2. **Periodic Rebroadcast**: Occurs every `RebroadcastInterval`.
+
+The broadcasted chain is selected based on:
+* The triggering event.
+* Previous chain broadcasts in the instance.
+
+This ensures the most informative chain is shared. Participants can infer all intermediate `MerkelizeValue`s from longer chains, making shorter chains redundant if they are prefixes of longer ones.
+
+Chain selection procedure is as follows:
+* If no prior broadcast exists, use the chain from the triggering event.
+* Otherwise, switch to the new chain only if it is not a prefix of the last broadcast chain.
+
+This logic results in the QUALITY phase proposal being broadcast until the participant is swayed.
+
+#### Partial Message Validation
+
+The validation of `PartialGossiPBFTMessage`s is the same as non-partial messages except for the following:
+* An empty `MerkelizeValue` indicates a zero-valued chain, i.e., bottom.
+* The `MerkelizeValue` is used in place of the actual chain value for signature verification.
+* The `MerkelizeValue` is used in place of the actual chain value for justification phase validation relative to Vote.
+* The `MerkelizeValue` is used in place of the actual chain value for justification signature verification.
+
+The above substitutions make it possible to partially validate the messages prior to buffering. To complete the validation upon discovering the chain that corresponds to a `MerkelizeValue`, the participant must:
+* Check that the EC Chain itself is structurally valid, e.g. order of tipset epochs, etc. 
+* Check that the EC Chain indeed corresponds to the `MerkelizeValue` in the partial message.
+* Check that the base tipset of the EC Chain being decided is the head of the previously finalized chain.
+
+Once the validation is complete, the message is passed to GPBFT.
+
+#### Buffering Recommendations
+
+Participants must buffer partial messages until the corresponding `MerkelizeValue` is identified. To prevent unbounded growth, the buffer should be bounded and prioritize messages based on GPBFT progress to ensure timely processing and validation.
+
+Buffering recommendations include:
+* Resolve partial messages with known `MerkelizeValue`s first.
+* Prioritize discovering `MerkelizeValue`s for pending partial messages.
+* Limit the number of concurrent instances buffered, considering GPBFT progress and committee lookback.
+* Implement a timeout mechanism to discard unresolved buffered partial messages after a certain period.
+
 ### Merkle Tree Format
 
 This protocol uses merkle trees as vector commitments to commit to both (a) the tipsets in an instance and (b) the values committed to in each tipset. It uses a single, balanced binary merkle tree format in both cases, where:

FIPS/fip-0097.md

@@ -27,26 +27,67 @@ While the FEVM implementation utilizes permanent storage for practical reasons,
 ### Opcode Descriptions
 
 #### `TLOAD`
-- **Opcode Hex:** `0x5C`  
-- **Stack Input:**  
-  - `key`: Location of the transient storage value to load  
-- **Stack Output:**  
-  - `value`: Stored value or zero if no value exists  
-- **Description:** Retrieves the value associated with `key` in the transient storage for the current transaction.
+- **Opcode Hex:** `0x5C`
+- **Stack Input:**
+  - `key`: Location of the transient storage value to load
+- **Stack Output:**
+  - `value`: Stored value or zero if no value exists
+- **Description:**
+  - Retrieves the value associated with `key` in transient storage.
+  - If the transaction has ended, transient storage is cleared, and `TLOAD` returns zero.
 
 #### `TSTORE`
-- **Opcode Hex:** `0x5D`  
-- **Stack Input:**  
-  - `key`: Location to store the value  
-  - `value`: Value to store  
-- **Output:** None  
-- **Description:** Stores `value` at the specified `key` in the transient storage for the current transaction.
+- **Opcode Hex:** `0x5D`
+- **Stack Input:**
+  - `key`: Location to store the value
+  - `value`: Value to store
+- **Output:** None
+- **Description:**
+  - Stores `value` at the specified `key` in transient storage.
+  - Data is cleared at the end of the transaction.
+
 
 ### Lifecycle Management
-Transient storage is valid only within the context of a single transaction. A lifecycle mechanism tracks transaction metadata (`origin` and `nonce`) to enforce lifecycle validation. 
+Transient storage is valid only within a single transaction. The system enforces this behavior by:
+
+- **Tracking `origin` and `nonce`**: Each transient storage slot is associated with the transaction’s origin actor and nonce.
+- **Resetting Storage on New Transactions**: If a new transaction begins, previous transient storage data is discarded.
+- **Allowing Reentrancy**: If a contract calls itself within a transaction, it retains access to the same transient storage.
+
+At the implementation level, transient storage is managed via `StateKamt<U256, U256>`, ensuring transaction-scoped isolation.
 
 ### Implementation Details
-The FEVM implements transient storage using a lifecycle validation mechanism to ensure data remains accessible only during the originating transaction. This validation enforces the same behavior as Ethereum’s transient storage. Internally, transient storage relies on permanent storage to manage lifecycle data and state while ensuring functional adherence to Ethereum’s behavior.
+The FEVM implements transient storage (`TLOAD` and `TSTORE`) using an internal lifecycle validation mechanism. This ensures that transient storage remains scoped to the transaction and is automatically cleared once execution ends.
+
+##### Data Structures
+The implementation introduces the following Rust data structures:
+
+- **`TransientData`**: Stores the transient storage state for a contract within a transaction.
+- **`TransientDataLifespan`**: Tracks the lifespan of transient storage using the `origin` actor ID and `nonce` of the transaction.
+
+```rust
+pub struct TransientData {
+    pub transient_data_state: Cid,  // CID of the transient storage map
+    pub transient_data_lifespan: TransientDataLifespan, // Lifecycle validation
+}
+
+pub struct TransientDataLifespan {
+    pub origin: ActorID,  // Origin actor ID
+    pub nonce: u64,  // Unique transaction identifier
+}
+```
+
+##### Storage and Lifecycle Enforcement
+The FEVM utilizes **persistent storage** to back transient data but enforces strict lifecycle rules to ensure it behaves like Ethereum's transient storage. The system:
+
+1. **Checks Transaction Context**:
+   - Before every `TLOAD` or `TSTORE` operation, the contract verifies the transaction’s `origin` and `nonce` to ensure validity.
+
+2. **Clears Storage at Transaction End**:
+   - If a new transaction begins, the system resets the `TransientData` state, ensuring no data persists across transactions.
+
+3. **Handles Reentrant Calls**:
+   - If a contract invokes itself within the same transaction, transient storage remains available.
 
 ---
 
@@ -63,25 +104,43 @@ At the time of writing, support for `TLOAD` and `TSTORE` in current versions of
 
 ## Test Cases
 
-### Essential Tests
-1. **Basic Functionality:**
-   - Verify `TLOAD` retrieves the correct value.
-   - Verify `TSTORE` writes data to the transient storage correctly.
-   - Verify `TLOAD` from an unitialized location returns the zero value.
+##### **1. Basic Functionality**
+- Verify `TLOAD` retrieves the correct value.
+- Verify `TSTORE` writes data to transient storage.
+- Verify `TLOAD` from an uninitialized location returns zero.
+
+##### **2. Lifecycle Validation**
+- Verify transient storage is **cleared** at the end of a transaction.
+- Verify **reentrant calls** access the same transient storage space.
+- Verify **nested contract calls** have independent transient storage.
+
+##### **3. Cross-Contract Isolation**
+- Deploy two contracts, `A` and `B`.
+- Have contract `A` write to transient storage.
+- Have contract `B` attempt to access `A`'s transient storage.
+- Verify that `B` cannot read `A`'s transient storage.
+
+##### **4. Handling Reverted Transactions**
+- Store a value in transient storage.
+- Revert the transaction before it completes.
+- Verify that no transient storage data persists.
 
-2. **Lifecycle Validation:**
-   - Verify that transient storage is automatically cleared and becomes inaccessible after the transaction ends.
-   - Verify that transient storage is properly cleared at the end of each transaction and any out-of-lifecycle data does not interfere with subsequent transaction operations.
-   - Verify that nested contracts have independent transient storage spaces can read and write independently.
-   - Verify that memory remains accessible and stable after contract reentry.
 
 ---
 
 ## Security Considerations
-Transient storage introduces minimal additional risk compared to existing state storage. Lifecycle validation ensures storage is inaccessible outside the originating transaction. Security measures include:
-- Preventing out-of-bounds memory access.
-- Ensuring transient storage clears properly after a transaction ends.
-- Ensuring nested contracts do not have access to each other's memory spaces.
+Transient storage introduces security considerations, primarily around ensuring that data does not persist beyond the transaction. To mitigate risks:
+
+1. **Automatic Clearing at Transaction End**
+   - Transient storage is reset when a new transaction starts.
+   - Even if the contract does not explicitly clear storage, the FEVM enforces reset.
+
+2. **Preventing Cross-Contract Leakage**
+   - Contracts cannot access transient storage from other contracts.
+   - Each contract’s transient storage is isolated by its execution context.
+
+3. **Reentrancy Safety**
+   - Contracts can safely store temporary data within a transaction.
 
 ---
 

FIPS/fip-0098.md

@@ -1,9 +1,9 @@
 ---
 fip: "0098"
 title: Simplify termination fee calculation to a fixed percentage of initial pledge
-author: @Schwartz10, @anorth, @jimpick
+author: Jonathan Schwartz (@Schwartz10), Alex North (@anorth), Jim Pick (@jimpick)
 discussions-to: https://github.com/filecoin-project/FIPs/discussions/1036
-status: Last Call
+status: Accepted
 type: Technical
 category: Core
 created: 2024-09-26