Hey hey @TheGreatAxios, it is an awesome proposal !
After long-weeks discussion with Core team and SKALE Dev Community, we come up to the detailed plan about technical implementations.
This proposal details a phased approach to rolling out SKALE Chain pricing. The goal will be to start in the fastest and most simple way possible that moves chain payments to an onchain environment. This first phase is titled Minimum Viable Onchain Payments for that reason. Phase 2 will be focused on Automation and additional features. Phase 3 will be focused on advanced features.
The first implementation is proposed to launch on 1 Jan 2024 after a successful vote
This release would contain:
- Onchain payment functionality for each SKALE chain
- Claiming of rewards mechanism for each validator
- Blacklist functionality with enforcement from a decentralized security committee
- The decentralized security committee will be composed of 3 core developers, 3 validators, and 3 dApp/ecosystem builders. This is subject to change based on additional community input.
- Their primary role will be to make judgements on network security and operations decisions as they relate to workflows that require a manual input in phase 1 in lieu of having a fully automated system. These decisions will primarily be related to making judgements about validators or chains that are not meeting requirements or payments.
- Further details to be provided on how the individuals are selected and what specific authority their collective role will play.
- Following the network changes on Ethereum functionality
- Deployment of the set of smart contracts to Europa Hub
The second implementation is proposed to launch on 1 Jul 2024
- Automatically update contracts on Europa with changes from SKALE Manager on Ethereum via IMA
- Nodes addition/removal
- Schains addition/removal
- Validators addition/removal
- Automatically update SKALE Manager contracts on Ethereum with chain payment information via IMA
- Automatically update SKALE Chain ownership if payment is delayed for more than 3 months
- Automatically fetch $SKL price via SKALE Connect
- Add dynamic SKALE Chain pricing that matches the network utilization curve found in the primary proposal
- Enable anyone to create a new SKALE Chain
- Blacklist enforcement will continue to be a manual decentralized process involving a decentralized security committee.
The third stage is proposed to launch on on 1 Jul 2025
- This phase will include advanced features that automatically manage chain removal from the system while simultaneously protecting the users, assets, and data in chains.
- Automated SKALE chain deletion flow of tokens releasing via IMA to holders
- Decentralized SLA to follow the blacklist requirements
- More features to be added
- Due dates for all SKALE Chain payments will be the 1st of each month so as to match the other components of the network which are also linked to the first day. These include delegation, node creation (in terms of bounty distribution and delegation), node removal (in terms of bounty distribution and delegation)
- SKALE Chain payments will occur in $SKL on the SKALE Europa Hub.
- SKALE Chain payments are at a minimum for the next month.
- SKALE Chains may be pre-paid in $SKL tokens for up to 12 months. This is a configurable number that may be changed through a separate governance proposal and passing vote according to the network governance specifications.
- If a SKALE chain owner misses a payment, SKALE chain owner needs to pay for all months not paid in addition to the next month’s regular payment.
- For the first implementation, $SKL token price can be set by a specific role or the SKALE Multisig.
- Validators can claim payments after the 1st of each month, once a whole month has been completed. This means first validator payments cannot be claimed until month two (2) of the first implementation going live.
- Validator payments can be claimed by validator wallets
- Nodes can be blacklisted in the current month and the reward would be reduced proportionally to the percentage of time node was blacklisted during this month. The remaining tokens will be distributed to whitelisted nodes equally.
- Blacklist and whitelist can be called by BLACKLIST_ROLE WHITELIST_ROLE, or SKALE Multisig.
- Data should be initialized once by the SKALE Multisig. This initialization would include validators wallet, SKALE Chain names and amount of nodes.
- All the changes in the network (node creation/removal, SKALE Chain creation/deletion) can be sent from SKALE Multisig and taking place at the 1 day of next month
- Contract will be upgradeable by SKALE Multisig.
- All the management transactions (by SKALE Multisig) will go through IMA.
- SKALE Chains can be created by the Foundation at any time during the month
- SKALE Chains should be paid for the next month before the 1st day of next month.
Validators are required to operate at an extremely high level of performance. The following is a list of validator compliance requirements which each validator must follow.
If a validator is not fully compliant according to the list below, the following actions will be taken:
- The validator will be notified directly and asked to resolve the issue.
- If the validator does not resolve an issue during the next 3 days, nodes which contain the issue would be marked as blacklisted until the issue is resolved.
To run the node three separate services are required:
- SKALE Node running independently from other services
- SGX wallet
- Reliable ETH mainnet node connection
Node machine specification:
- 8 physical CPU cores.
- 32GB RAM.
- 16GB swap.
- Disk mounted as / - 100GB.
- Separate disk - 2Tb.
It’s possible to check whether the machine meets the requirements by running
skale node checks.
SGX machine specification:
- 4 physical CPU cores.
- 16GB RAM.
- 8GB swap.
- Disk mounted as / - 100GB.
The only supported operating system is Ubuntu 20.04 (Focal Fossa).
- 1.5 ETH for each node wallet - defined and managed by SRW (Self Recharging Wallet - part of skale-manager).
- Keep SRW balance of validator at minimum as 0.1 ETH
It’s possible to check node wallet balance by running
skale wallet info.
- Each node should have a static IPv4 address. It’s possible to migrate to the new one, but as for now the procedure may require up to a month to complete.
- SKALE node software handles configuration of the firewall. In case some external network configuration is applied, ports 80, 443, 3009, 311, and 10000–18192, and ICMP IPv4 should be left open.
- SGX wallet server should be connected to no more than five nodes.
- SGX wallet server ports (1026-1031) should be only accessible from SKALE node machines. Leaving them publicly open may have huge security related implications.
- Ethereum mainnet node should be able to operate 1M requests per day at a peak load.
- Each node should have public domain available for which there should be SSL certificates issued.
Each SKALE node can be configured to use issued certificates by running
skale ssl upload.
The validity of the newly generated certificates can be verified by running
skale ssl check.
- The backup procedure should be performed every day for both SGX wallet and SKALE node.
For the node copying tarball created by
skale node backup is enough.
For SGX wallet you can use this guide
Each node operator will consider the following security measures:
- Node, SGX and ETH client machines cannot be accessed by any third party.
- SSH keys are stored securely.
- SGX wallet backup key is stored securely.
- SGX wallet API can only be accessed from the node machines.
- Validator key is stored securely. Preferably using ledger or SGX wallet
Each validator should have at least 99% availability on each of the points below:
- Services on the nodes(docker containers are running properly).
- SGX wallet connection to each node.
- Ethereum mainnet node connection to each node.
- SKALE chains connection on the node(http/https/ws/wss).
SKALE’s Decentralized Security Committee expects from each validator organization:
- Follow the upgrade rules specified for each validator.