Enhancing the Evolution of SKALE Chain Pricing and Moving into Network Growth Phase 2

[payvint]

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.

Timeline

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.

Stage 1 - “Minimum Viable On-Chain Payments”

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

Stage 2 - “Automation”

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.

Stage 3 - “Advanced Features”

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

Specification

Payment

• 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.

Distribution

• 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.

Operations

• 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.

Validator Compliance Requirements

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:

1. The validator will be notified directly and asked to resolve the issue.
2. 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.

Services

To run the node three separate services are required:

1. SKALE Node running independently from other services
2. SGX wallet
3. Reliable ETH mainnet node connection

Hardware Requirements

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.

Operating System (OS)

The only supported operating system is Ubuntu 20.04 (Focal Fossa).

Node Wallet ETH Amount

• 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.

Static IP Address

• 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.

Node Machine Firewall

• 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 Allocation

SGX wallet should not be hosted on SKALE node machines due to potential performance degradation.

• SGX wallet server should be connected to no more than five nodes.

SGX Wallet Machine Network Isolation

• SGX wallet server ports (1026-1031) should be only accessible from SKALE node machines. Leaving them publicly open may have huge security related implications.

Reliable Ethereum Mainnet Node Connection

The only supported execution client is go-ethereum. For the consensus client, Prysm is recommended. Using external providers like Infura are not recommended at this time.

• Ethereum mainnet node should be able to operate 1M requests per day at a peak load.

TLS certificates

• 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.

Backup

• 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

General security

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

Availability

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).

Operations

SKALE’s Decentralized Security Committee expects from each validator organization:

• Follow the upgrade rules specified for each validator.

[TheGreatAxios]

Hey @payvint

Thanks for putting this together!
I think it fits the initial proposal quite nicely. I don’t have any comments or concerns on the validator requirements. My only request is for clarification on SKALE Chain Deletion timing.

I see in the Operations section, that there is a note that SKALE Chains can be deleted taking place on the first day of the next month. Confirming this means that there is actually an N + 1 runway for the chain.

Meaning if the first chain payment is due on Dec 1 and max # of months you can go without paying (N) is set to 2 (for example), then if the chain runs through January and gets to Feb 1 with no payment it can be scheduled for deletion? Or does it then need to wait until March 1?

[olehnikolaiev]

hey @payvint ! glad to see SKALE Chain Pricing discussion going! is it planned to add automated checks or SLA at stage 3 to check validators compliance? if so does it mean that in after the stage 3 there will be no need in decentralized security committee?

[payvint]

Hey @TheGreatAxios

Good question!

So if SKALE chain “A” was paid for one months starting 1 Dec(Owner of this chain paid in November)

It is necessary to pay for January months in Dec(for example in 29 Dec)
If the payment is missing and 1 January already come - this month would be considered as a missing month and would collect debt.

After the 1 January Owner of SKALE chain “A” need to pay debt first and after that pay the next month/months

Debt can be collected for up to 3 months - after that ownership of SKALE chain would be passed to SKALE Multisig, it is not correct for users to delete a SKALE chain if it was not payed by the owner.

So in this case if the debt for the chain was not payed until the 1 April - SKALE chain ownership would be transferred to the SKALE Multisig.

If the Owner of SKALE chain “A” decided to cover the debt on 31 March - Owner need to pay debt first (January, February, March) and then owner can pay for April and etc

Thanks!

[payvint]

Hey @olehnikolaiev

You are right!

In first implementation of SKALE Manager(Set of smart contract on Ethereum which controlling the whole SKALE Network) there was a first implementation of SLA to check node characteristics/stats/requirements and etc
But it was a proposal to remove it because of amount of computation which is needed on Ethereum and costs.

So Decentralized SLA would be a Decentralized security committee by itself:)

There are plans to run it on SKALE chain and roll it up to Ethereum via Levitation protocol.

So each validator node would checks other validator nodes and send verdicts regarding the operational health to the smart contract, which would analyze all the verdicts and slash or benefit depends on results.

Also thanks to SKALE Connect(Built in Oracle into the skale-node) - it would be possible to verify different off-chain requests(like time to response, skale chain docker containers health and etc).

Decentralized SLA on SKALE chain would be much more powerful than it was in a first implementation thanks to SKALE ecosystem features development and improvements.

[Edouard_Stakin]

Hi everybody,

As a validator operator at Stakin and a long-term supporter of the Skale ecosystem, it’s exciting to see this plan about Skale Chain Pricing going live and the transition into Phase 2 of Skale’s development, as well as the upcoming Phase 3.

Skale has achieved significant traction in the number of active Skale chains, and transactions, and contributed to saving billions of dollars of gas fees for the end users. Now that Skale has achieved a certain level of traction, it seems like a natural evolution to open up the discussion of Chain Pricing and progressively move away from a free model.

I believe that Skale Chain Pricing going live represents a big opportunity to further strengthen the ecosystem, giving additional value to the SKL token (more demand, less need for inflation), and further incentivizing stakers and validator node operators.

It’s important to strike the right balance in terms of pricing to ensure Skale remains attractive for builders. I would love to see an iterative approach in the future with regular reviews of the Chain Pricing model and open discussions like this one, to ensure we all benefit from ecosystem builders to stakers to validators.

I don’t have many questions at this stage. The plan is well-structured and makes sense. All in all, my opinion is that this proposal should benefit the ecosystem in the long term and will happily support this plan. Would love to read some thoughts from delegators and other ecosystem participants too.

[delightlabs_io]

Hi SKALE community,

As DELIGHT LABS has been validating since its genesis, we’re very glad to hear about this and more upcoming proposals. The community would be excited that SKL becomes no longer an inflationary currency but will activate its own function. I’m glad to see that the roadmap on the whitepaper turns into the real.

There’s no objection in the overview but some questions about the network utilization - pricing graph.

1. How much is the utilization now?
2. Is there any reason why the pricing hugely increases between 45% and 50%, about 10x? If it is around 50%, I wonder which dApp company could pay tens of thousand USD monthly.

• Could the multiplier be lower?
• Could the increase point be started from more earlier utilization?

The graph below does not mean any exact, derived point but just shows my brief opinion.

[ethalita]

Hi @payvint
Thanks, I’m thrilled about this. Agree with @delightlabs_io on his question, appreciate if you can share a bit about the choice of parameter values.

We at Chorus One believe in Skale’s potential and appreciate this proposal addressing any concerns regarding profitability and sustainability of the Network. We’re happy to continue supporting the Network and ecosystem in this new phase.

[delightlabs_io]

@payvint Plus, the chart would be more reasonable if you could show the data below, if possible (I remember there’s any survey related on this.):

• expected gas consumption if the dApps are shipped on ETH network
• any attraction factor from no gas consumption by users
• the expecting critical point between staying on SKALE and leaving to another EVM network

[TheGreatAxios]

Hey @Edouard_Stakin

I fully agree that the right balance does need to be found here. As this is pretty new territory for everyone, I think iterating on this on a consistent basis to start and checking in with all parties who are involved makes complete sense. I will think deeper about the items that we should be checking on. At a minimum, the numbers and processes can always have changes proposed that can be finalized with a vote (same as this will be).

[TheGreatAxios]

Hey @delightlabs_io @ethalita

Thanks to both of you for questions and thoughts as well.
The questions in this comment here: Enhancing the Evolution of SKALE Chain Pricing and Moving into Network Growth Phase 2 - #10 by delightlabs_io are:

Q: How much is the utilization now?
A: The current utilization is going to be the totalNumberOfNodesInTheNetwork / 2. The reason for it being divided by two is because a SKALE Chain 1 subnode from 16 individual nodes. With each individual node supporting up to 8 subnodes, then we can just do 16/8 = 2. This means if we aggregate the number of subnodes together it takes 2 nodes worth of subnodes to run a SKALE Chain today.

According to the SKALE Network Dune dashboard, the current number of Active nodes in the network is 115 (https://dune.com/queries/2771528/4619198). I am not sure how many nodes are available in a different state (will let @payvint hop back in and confirm that), but if we use the 115 the current number. We can then take that and divide it by 2 as we did above. That gives us 57.5 or 57 SKALE Chains available if every node were to host the maximum number of SKALE Chains.

From there, we can see that the network has 20 chains running today so 20/57.5 ~= 34.78% utilization as of today with these numbers.

**Q: Is there any reason why the pricing hugely increases between 45% and 50%, about 10x?

A: With each SKALE Chain having an average throughput capacity of ~400 tps. It means a SKALE Chain can do over 10 billion transactions per year. That’s in addition to the on-chain file storage of ~60gb, built in random-number generation in Solidity, and native Oracle solution. This makes each and every SKALE Chain highly valuable from a pure compute perspective. However, something that should not be discounted is the security and setup of the network. SKALE Network operates using a pooled-security model which means the SKALE Chains share the nodes. This means instead of having to create a means of incentivizing validators that is going to be sustainable and secure in the short and long term, recruiting validators, and managing everything that comes along with bootstrapping a network; with SKALE you can have a new chain spun up in I believe just a few minutes (fact check on how long to spin up a new chain please @payvint ) that is integrated with all the other chains in the network via IMA, takes advantage of this pooled security model, etc etc.

With the ultimate goal being profitability for validator hardware; the jump in price should ensure this as chains become more and more in-demand. It’s also important to note that the goal of chain pricing is to be used in the short-term for validator operators only, but in the long-term used to create even greater sustainability for the delegators as well. The price increase will make sure that even as portions of chain payments are diverted to other areas of the network; validators are always being properly supported to ensure the successful operation of the network.

Q: Could the multiplier be lower?

Yes! It certainly is possible and these numbers are all flexible and could be changed either before a vote is made for this first proposal, or in the future through another vote. One thing I would like to clarify is that all the numbers used in this proposal took months of research, discussion, and collaboration to get to where it is today with the goal of not only working – upon a passing vote – but also with the goal of being sustainable in the long-term.

Anybody is welcome to propose alternative numbers, time-frames, etc to help aid in the community effort to bring this to fruition!

Q: Could the increase point be started from more earlier utilization?

Once again here, I believe yes it certainly could. However, the outcome of lowering the utilization % increase point to some other number that is lower than the proposed could have a negative result on the network as a whole. For example, 50% of 57 chains is ~23 chains. This means that if the 50% target was lowered to for example 30%, then upon go-live all chains in the network would be required to pay the ~$46,000 a month which could result in many chains choosing to leave. As more chains leave, the validators would actually lose out on payments for each and every chain that chooses to leave with a possible result being enough chains leave that the utilization goes below 30% and the validator operators are being paid the same starting number, but for far fewer chains meaning less for everyone.

Hope the above answers some of your questions! Please feel free to tag me with any other questions.

Thanks!

[delightlabs_io]

@TheGreatAxios @payvint
Fully agree with your opinion, and it would be good to proceed to vote for this time and calibrate the number later. I believe that the number is derived from your research but some questions above came in my brain because there was no number written in this post.

Waiting that some critical numbers would be shown in the SKALE analytics or any official dashboard

[Ruby_Pyrite]

Hi @TheGreatAxios and team,

It’s really encouraging to see this work being done and progress being made towards long-term network sustainability. Also, great work on the detailed technical implementation, @payvint.

We’ve spent some time discussing this internally and are in agreement that this balances the needs of different stakeholders in the SKALE network. The non-inflationary aspect and maintaining the SaaS model are both good to see. We’re excited about the additional functionality and flexibility for chain owners and the overall ecosystem in these updates, and of course the role that Europa will play.

As dantereminick notes, it would be good to see some mitigation for the possibility of a sudden price jump, like a transition period, or locked-in price for a time. (Pre-payment partially covers this, but an issue might arise if prices rose significantly towards the end of the payment period.)

Also, like delightlabs_io, we’re curious whether there’s a case for a smoother price curve, and what effect this might have on the rate that new nodes are added to the network.

One thing that might help is a series of Alice/Bob-style worked examples, for different circumstances, network load, and so on, just to help ground some of the figures in the “real world”.

Overall, the Ruby team likes this proposal and it looks like the best way forwards. 2024 should be an exciting year for SKALE!

[TheGreatAxios]

Hey @delightlabs_io

Which numbers do you not see in this post/thread?

Thanks!

[TheGreatAxios]

Hey @Ruby_Pyrite

Thanks to you and your team for the time reviewing and leaving some feedback.

Will continue the discussion with @payvint and other parties involved in the technical portion on a possible transitional period and what that could look like from a technical perspective and come back with any updates.

As for the smoother price curve, the impact on nodes coming to the network I don’t think would change. The number of nodes in the network and the desire to create and run more nodes from a validator ideally would be dependent on utilization increase (i.e if utilization approaches 50% and climbs it makes sense for validators to run more nodes to keep the price point in the middle). As for the smoother price curve, that is a goal as part of Phase 3:

Dynamic pricing in Phase 3 represents a significant evolution in SKALE’s economic model. This mechanism leverages advanced smart contracts and market dynamics to dynamically adjust chain prices based on supply and demand of SKALE chain rentals .

However, doing so at an earlier stage could actually have a negative impact as chain owners today would start paying more sooner as the network is still growing while it works toward achieving sustainability. As for the examples, will try and create some that may help illustrate this proposal better.

If no specific alternatives are proposed then it probably makes the most sense to proceed as is with the current proposed values knowing that if things are not working then parameters can be changed through a future proposal and successful vote.

[delightlabs_io]

I mean the live dashboard like SKALE Mainnet Stats

[payvint]

Hi @delightlabs_io

The live dashboard is moving to Dune here: https://dune.com/skale/analytics
Good suggestion!
We would update the dashboard with all of the parameters and numbers!

[TheGreatAxios]

Hey everyone!

Thanks to all for participating here on the forum, those who helped with research, those who helped with design, and in general just those who have supported with their feedback throughout the process.

At this point in time, as there have been no directly proposed changes and we have agreed to come back and continue to iterate on this on a consistent basis as a community to find the; the vote has been opened on Snapshot for delegators and validators of the SKALE Network to vote on.

This officially comes in as the first SKALE Improvement Proposal (e.g. SIP 1) and is available to vote on here: Snapshot

Thank you!

[Anonstake]

Hey SKALE team,

Kudos to @TheGreatAxios, @payvint and the whole team for detailed steps and plan laid for SKALE Chain pricing. We like the presented proposal and think it is well thought out. Phase 1 is ending with success, we are noticing increased activity, with more teams working on SKALE and ecosystem gaining traction. Therefore we encourage the idea of the dynamic pricing model introduced and hope it will work as planned in order to incentivise shareholders of chain for long-term growth.

We are looking forward to see utilization curve versus growth of dapps on network as we proceed to Phase 3. We like the idea of a sliding scale based on network utilization as it adds flexibility and responsiveness to the network. We see that a lot of effort and technical details were considered in the proposal and we appreciate the focus and consideration given to compensating validators for their cost.

We commend SKALE team commitment to decentralized governance, preparing timeline and specifications for each stage and trusting the community with the decision. We hope the team will be open to reconsiderations based on the responses of the community and network evolution once chain pricing goes live. As a validator, we look forward to seing the plan above be put in action, marking the next stage in SKALE’s evolution. Exciting times ahead for SKALE!

[MathiasExorde]

Hey everyone,

Glad to see this important side of SKL token utility moving again. At Exorde we are lucky to have seen the evolution of the SKALE project over the last few years. @TheGreatAxios @payvint

We have been attracted to SKALE due to the chain model, flexibility and control, and gas-less ness, and we continue to do so.

We do now around 350-400k transactions a day, on a very stable basis. We now proudly represent 60%-70% of the transactional load on SKALE right now. We have been collaborating at a very fundamental & technical level with SKALE for a long time and we are pleased with the service.

We’d love to give our feedback on the proposal, and the general question of the SKL/Skale Chain pricing model:

1. The model is great. The $3600/month price per month is reasonable and expected. In our experience, it is in the same order of magnitude as what would be the gas cost of our operations on another L1/L2 platform.

2. Being able to prepay long-term is crucial. Meanwhile being able to accumulate SKL to pay in the future is nice, certainty is a must for a business dealing with lots of uncertainty already. Good that it will be possible as soon as possible.

3. The payments going directly 100% to the validators make complete sense, the infrastructure is key, and I believe this should remain the case forever (for at least 90%).

4. Keep in mind that SKALE chain “users” (like us at Exorde Labs) usually reason in terms of competitiveness and gas cost (w.r.t the competition in the L1/L2 space).

• It makes sense that if networks approach saturation, the incentivization to boot new SKALE chain nodes should increase to bring more “node supply” to the network requiring new chains.
• It makes sense to have an increase of SKALE chain price, but the exponential growth rate of the price could not be the best idea. Maybe imagine an auction system when the network reaches saturation? It would probably capture demand more accurately.
• A temporary sudden $40,000 USD+/months price acts, for us, more like a deterrent. If the monthly cost, during a high utilization period (>60% for example), is high, a new SKALE network client is more incentivized to wait for the price to come down, than pay 10x+ the price of his transactions/protocol on another network, before migrating back. This is a question of balance, and maybe a smoother price curve is to be explored at least initially?

Overall we believe the pricing model to be very good and intuitive, with a note of exception on the pricing model during network saturation: we would expect the network to incentivize new nodes, without deterring new clients that much. Stability is one of the key differentiators of using SKALE and we are glad it’s being considered.

Thanks