Merge branch 'main' into rep-38

RSS3-Network · Oct 24, 2024 · 2ba92ab · 2ba92ab
2 parents 411b079 + ac2e09b
commit 2ba92ab
Show file tree

Hide file tree

Showing 8 changed files with 142 additions and 37 deletions.
diff --git a/README.md b/README.md
@@ -6,15 +6,25 @@ REP stands for RSS3 Evolution Proposal, a detailed documentation proposed by the
 
 This repository tracks all REPs proposed by the RSS3 Community.
 
-| REP Number                 | Title                               | Proposer(s)                                                                                                                                                                                                                                                                                             | Type     | Status    |
-| -------------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------- |
-| [REP-1](./REPs/REP-1.md)   | Purpose and Guidelines              | <[email protected]>                                                                                                                                                                                                                                                                                         | Process  | Living    |
-| [REP-11](./REPs/REP-11.md) | Protocol Upgrade                    | [BruceXC](mailto:[email protected]), [HenryQW](mailto:[email protected]), [KallyDev](mailto:[email protected]), [Nya Candy](mailto:[email protected]), [polebug](mailto:[email protected]), [pseudoyu](mailto:[email protected]), [Thomas](mailto:[email protected]) | Protocol | Final     |
-| [REP-16](./REPs/REP-16.md) | Staking Rewards Taxation Adjustment | [Albert](mailto:[email protected]), [HenryQW](mailto:[email protected])                                                                                                                                                                                                                                        | Core     | Final     |
-| [REP-20](./REPs/REP-20.md) | Data Availability Layer Integration | [Albert](mailto:[email protected]), [HenryQW](mailto:[email protected])                                                                                                                                                                                                                                        | Core     | Final     |
-| [REP-26](./REPs/REP-26.md) | Chip Mechanism Upgrade              | [BruceXC](mailto:[email protected])                                                                                                                                                                                                                                                                 | Core     | Candidate |
-| [REP-33](./REPs/REP-33.md) | Node State Transition               | [KallyDev](mailto:[email protected])                                                                                                                                                                                                                                                                     | Core     | Draft     |
-| [REP-38](./REPs/REP-38.md) | Demotion and Slashing Mechanism     | [Polebug](mailto:[email protected])                                                                                                                                                                                                                                                                       | Core     | Review    |
+| REP Number                 | Title                                          | Proposer(s)                                                                                                                                                                                                                                                                                             | Type     | Status    |
+| -------------------------- | ---------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- | --------- |
+| [REP-1](./REPs/REP-1.md)   | Purpose and Guidelines                         | <[email protected]>                                                                                                                                                                                                                                                                                         | Process  | Living    |
+| [REP-11](./REPs/REP-11.md) | Protocol Upgrade                               | [BruceXC](mailto:[email protected]), [HenryQW](mailto:[email protected]), [KallyDev](mailto:[email protected]), [Nya Candy](mailto:[email protected]), [polebug](mailto:[email protected]), [pseudoyu](mailto:[email protected]), [Thomas](mailto:[email protected]) | Protocol | Final     |
+| [REP-16](./REPs/REP-16.md) | Staking Rewards Taxation Adjustment            | [Albert](mailto:[email protected]), [HenryQW](mailto:[email protected])                                                                                                                                                                                                                                        | Core     | Final     |
+| [REP-20](./REPs/REP-20.md) | Data Availability Layer Integration            | [Albert](mailto:[email protected]), [HenryQW](mailto:[email protected])                                                                                                                                                                                                                                        | Core     | Final     |
+| [REP-26](./REPs/REP-26.md) | Chip Mechanism Upgrade                         | [BruceXC](mailto:[email protected])                                                                                                                                                                                                                                                                 | Core     | Final     |
+| [REP-33](./REPs/REP-33.md) | Node State Transition                          | [KallyDev](mailto:[email protected]), [BruceXC](mailto:[email protected])                                                                                                                                                                                                                            | Core     | Candidate |
+| [REP-38](./REPs/REP-38.md) | Demotion and Slashing Mechanism                | [Polebug](mailto:[email protected])                                                                                                                                                                                                                                                                       | Core     | Review    |
+| [REP-40](./REPs/REP-40.md) | Whitepaper Updates                             | [pseudoyu](mailto:[email protected])                                                                                                                                                                                                                                                              | Core     | Candidate |
+| [REP-43](./REPs/REP-43.md) | Introducing Payment Processor for Request Fees | [Nya Candy](mailto:[email protected])                                                                                                                                                                                                                                                                    | Core     | Review    |
+
+## Submit an REP
+
+1. Fork the repository by clicking the "Fork" button in the top right, then clone your fork.
+2. Duplicate `REPs/REP-Template.md` and rename it to `REPs/REP-XXXX.md` (where `XXXX` is the next available Pull Request number).
+3. Fill in the REP template with your proposal, remember to add links to relevant discussions on the RSS3 Forum.
+4. Run `npm run format`.
+5. Submit a Pull Request to RSS3 Network's `main` branch.
 
 ## License
 

diff --git a/REPs/REP-33.md b/REPs/REP-33.md
@@ -1,10 +1,10 @@
 ```
 REP: REP-33
 Title: Node State Transition
-Status: Draft
+Status: Candidate
 Type: Core
 Created: 19 Jul 2024
-Author(s): KallyDev <[email protected]>
+Author(s): KallyDev <[email protected]>, BruceXC <[email protected]>
 Description: This REP outlines every potential Node state and the transitions between them.
 Discussions: https://forum.rss3.io/t/proposal-on-node-state-transition/173
 ```
@@ -17,49 +17,58 @@ Discussions: https://forum.rss3.io/t/proposal-on-node-state-transition/173
 - [Motivation](#motivation)
 - [Specification](#specification)
   - [Node State Transition Path](#node-state-transition-path)
+  - [Reward Mechanism](#reward-mechanism)
 - [Rationale](#rationale)
+- [Reference Implementations](#reference-implementations)
 
 ## Abstract
 
-This REP proposes a comprehensive set of states and their associated transitions for Node operating on the RSS3 Network.
-It establishes a structured framework for Node operations, aiming to enhance clarity, consistency, and efficiency for Node management.
+This REP proposes a comprehensive set of states and their associated transitions for Nodes operating on the RSS3 Network. It establishes a structured framework for Node operations, aiming to enhance clarity, consistency, and efficiency in Node management.
 
 ## Motivation
 
-The Node states are currently not documented, potentially compromising network stability and complicating maintenance.
-A comprehensive set of states and their associated transitions enhance clarity, consistency, and efficiency for Node management.
-Clear definitions and guidelines will support the Network's current functionality and future scalability.
+The current lack of documentation for Node states potentially compromises network stability and complicates maintenance. A comprehensive set of states and their associated transitions enhances clarity, consistency, and efficiency in Node management. Clear definitions and guidelines will support both the Network's current functionality and future scalability.
 
 ## Specification
 
-A Node can be in 1 of the following 7 states:
+A Node can exist in one of the following 10 states:
 
-1. **Registered**: The Node is registered on the VSL with a sufficient deposit.
-2. **Initializing**: The Node is operating on the DSL. Automated tasks will be executed at this stage to ensure the Node is in a healthy condition. This state applies to the initial startup or the first startup following any change in the Node’s coverage.
-3. **Online**: The Node is operational and actively participating in network activities.
-4. **Offline**: The Node is not operational and not participating in network activities.
-5. **Exiting**: The Node is in the process of exiting the Network.
-6. **Exited**: The Node has successfully exited the Network.
-7. **Slashed**: The Node has been slashed due to a violation of network rules or malicious behavior.
+1. **None**: The initial state of a Node.
+2. **Registered**: The Node has been registered on the VSL with a sufficient deposit.
+3. **Initializing**: The Node is operating on the DSL. Automated tasks are executed at this stage to ensure the Node is in a healthy condition. This state applies to the initial startup or the first startup following any change in the Node's coverage.
+4. **Outdated**: The Node's version does not meet the minimum requirement.
+5. **Online**: The Node is operational and actively participating in network activities.
+6. **Offline**: The Node is non-operational and not participating in network activities.
+7. **Exiting**: The Node is in the process of exiting the Network.
+8. **Exited**: The Node has successfully exited the Network.
+9. **Slashing**: The Node is about to be penalized for violating network rules or engaging in malicious behavior. It has a 3-epoch appeal period.
+10. **Slashed**: The Node has been penalized due to a violation of network rules or malicious behavior.
 
 ### Node State Transition Path
 
 ![Node State Transition Path](REP-33/node-state-transition-path.png)
 
-1. **Registered** → **Initializing** → **Online**: Upon registration, a Node transitions to `Registered`.  `Initializing` is the state when the Node is started. After the automatic initialization is completed, it enters `Online` state.
-2. **Registered** → (after 30 Epochs) → **Exited**: A `Registered` Node transitions to `Exited` state after 30 Epochs of inactivity.
-3. **Online** → (current Epoch) → **Exiting**: An `Online` Node transitions to `Exiting` state upon announcing its intention to exit.
-4. **Exiting** → (waiting period) → **Exited**: An `Exiting` Node transitions to `Exited` state after completing the waiting period.
-5. **Exiting** → **Slashed**: An `Exiting` Node transitions to `Slashed` state if it prematurely exits during the waiting period.
-6. **Online** → (current Epoch) → **Offline**: An `Online` Node transitions to `Offline` state immediately within the same epoch if its Operation Pool drops below the required threshold.
-7. **Online** → (current Epoch) → **Slashed**: An `Online` Node transitions to `Slashed` state immediately within the same epoch if it is slashed.
-8. **Slashed** → (next Epoch) → **Offline**: A `Slashed` Node transitions to `Offline` state in the next epoch if the Operator fails to manually re-online it by the end of the current epoch.
-9. **Slashed** → (next Epoch) → **Online**: A `Slashed` Node transitions to `Online` state in the next epoch if the Operator manually re-online it by the end of the current epoch.
-10. **Offline** → (next Epoch) → **Online**: An `Offline` Node transitions to `Online` state in the next epoch if the Operator manually re-online it by the end of the current epoch.
-11. **Offline** →(after 30 Epochs) → **Exited**: An `Offline` Node transitions to `Exited` state after 30 Epochs of inactivity.
+1. **None** → **Registered**: A `None` Node transitions to `Registered` state upon meeting the minimum deposit requirement.
+2. **Registered** → **Initializing**: A `Registered` Node transitions to the `Initializing` state when it starts and begins indexing data but has not yet completed the process.
+3. **Registered** → **Outdated**: A `Registered` Node transitions to the `Outdated` state when the Node is started and its version does not meet the minimum requirement.
+4. **Registered**, **Outdated**, **Initializing**, **Slashed** → (anytime) → **Exited**: When a Node is in any of the `Registered`, `Outdated`, `Initializing`, or `Slashed` states, if the operator chooses to exit, the Node immediately enters the `Exited` state.
+5. **Initializing** → (next Epoch) → **Online**: After the automatic initialization is completed, the Node enters the `Online` state at the next epoch.
+6. **Online** → (current Epoch) → **Exiting**: An `Online` Node transitions to `Exiting` state upon announcing its intention to exit.
+7. **Exiting** → (waiting period) → **Exited**: An `Exiting` Node transitions to `Exited` state after completing the waiting period.
+8. **Online**, **Exiting** → **Slashing**: An `Online` or `Exiting` Node transitions to `Slashing` state if its demotion count reaches the threshold. The operator can appeal within 3 epochs.
+9. **Online**, **Exiting** → (current Epoch) → **Offline**: An `Online` or `Exiting` Node transitions to `Offline` state immediately within the same epoch if the Node is detected to be unavailable.
+10. **Offline**, **Slashed** → (current Epoch) → **Initializing**: An `Offline` or `Slashed` Node transitions to `Initializing` state if the Operator manually brings it back online.
+11. **Slashing** → (after 3 epochs) → **Slashed**: A `Slashing` Node transitions to `Slashed` state after 3 epochs.
 12. **Exited** → (anytime) → **Registered**: An `Exited` Node can re-register at any time.
 
+### Reward Mechanism
+
+Nodes in `Online`, `Initializing`, `Slashing` or `Exiting` states are eligible to provide services and receive rewards. Nodes in other states are ineligible.
+
 ## Rationale
 
-The core of this proposal is aim to standardize Node states, improve clarity, and simplify maintenance.
-This proposal will ensure consistent operations across the Network, enable efficient troubleshooting, and provide a solid foundation for future enhancements.
+The core objective of this proposal is to standardize Node states, improve clarity, and simplify maintenance. This proposal will ensure consistent operations across the Network, enable efficient troubleshooting, and provide a solid foundation for future enhancements.
+
+## Reference Implementations
+
+1. Upgraded contract : <https://scan.rss3.io/address/0x1FF6c3BC97841a3DF41e51Fc19223252ba373728>
diff --git a/REPs/REP-33/node-state-transition-path.png b/REPs/REP-33/node-state-transition-path.png
diff --git a/REPs/REP-38/3 responses [r1,r2,r3].png b/REPs/REP-38/3 responses [r1,r2,r3].png
diff --git a/REPs/REP-38/RSS3 Mainnet Diagrams (1).png b/REPs/REP-38/RSS3 Mainnet Diagrams (1).png
diff --git a/REPs/REP-40.md b/REPs/REP-40.md
@@ -0,0 +1,37 @@
+```
+REP: 40
+Title: Whitepaper Updates
+Status: Candidate
+Type: Core
+Created: 30 Jul 2024
+Author(s): pseudoyu <[email protected]>
+Description: This REP describes the updates to the RSS3 Network Whitepaper.
+Discussions: https://forum.rss3.io/t/rep-draft-on-whitepaper-updates/179
+```
+
+# REP-40: Whitepapaer Updates
+
+## Abstract
+
+This REP proposes several updates to the RSS3 Network Whitepaper. These updates aim to enhance the clarity, consistency, and accuracy of the Whitepaper, reflecting the latest developments and improvements in the RSS3 Network.
+
+## Motivation
+
+The RSS3 Network Whitepaper serves as a foundational document, providing a comprehensive overview of the Network's design, architecture, and functionality. As the Network evolves, it is crucial to keep the Whitepaper aligned with the latest implementations.
+
+This update aims to enhance clarity, correct outdated information, and ensure consistency across all RSS3 documentation. By maintaining an accurate Whitepaper, we provide a reliable reference for developers, users, and potential new participants, supporting the Network's ongoing development and adoption.
+
+## Specification
+
+This REP proposes general improvements and updates throughout the Whitepaper, with particular focus on Section III and its subsections. These changes are detailed in the associated [Pull Request](https://github.com/RSS3-Network/Whitepaper/pull/10).
+
+## Rationale
+
+The core of this proposal is to update the RSS3 Network Whitepaper to accurately reflect the current state of the Network. These updates focus on refining terminology, clarifying the role of Global Indexers, and providing more precise definitions. By implementing these changes, we aim to enhance the Whitepaper's accuracy and usefulness as a key reference document for the RSS3 ecosystem, ensuring it aligns with the latest developments and improvements in the Network.
+
+And this is an informational REP which requires no code changes and has no empirical impact on anything.
+
+## Reference Implementations
+
+1. [RSS3-Network/Whitepaper#10](https://github.com/RSS3-Network/Whitepaper/pull/10)
+2. [RSS3-Network/Whitepaper#11](https://github.com/RSS3-Network/Whitepaper/pull/11)