WDYT: Service providers

Massa Improvement Proposals
1

Service providers

Currently, Massa node runners provide services like maintaining and feed the blockchain consensus and state, provide API and bootstrap access and so on…

The idea of this proposal is to create a new type of actors (that can be the node runners themselves but not necessarily!) that provide multiple kinds of off-chain services with on-chain management. Those services can be - but are not limited to:

  • data storage (Dropbox-style)
  • internet connection (eg. VPN / proxy)
  • compute (eg. ZKSNARK/ZKSTARK prover-as-a-service, LLM inference as a service, cloud services…)

On the difficulty of proving off-chain service quality

Misbehavior by providers can in a few specific cases be proven on-chain to generate a penalty.
This is for example the case of cryptographically provable computation, storage proofs through Merkle paths and so on…

However, in most cases, there are no good solutions to prove an off-chain service was badly provided. Examples:

  • a data storage provider stores the data you pay them for but refuses to serve it in order to limit their bandwidth costs and legal exposure. This means they can prove they host the data if you challenge them on-chain but they won’t serve it off-chain.
  • a VPN provider throttles the proxy connection they provide to you when you visit some websites they don’t like
  • a computation provider is slow to respond to your requests

A bad solution: redundancy & majority voting

Instead of asking 1 provider to do something, the client asks 3 of them for the same thing, and to sign the hash of the request and their responses (with timestamp + unique counter to avoid replay).
If one provider responded differently than the 2 others, the client publishes the proof that they gave a “minority” response, and the provider gets slashed of some stake locked in a smart contract.

Why this is bad:

  • it does not measure quality of service, and only allows detecting “wrong” answers
  • it does not account for lack of response by the provider
  • providers could be targeted, for example by crafting a website that serves a specific page to all IPs except the one of the targeted provider. That way, when you use proxy providers to visit your website, you can prove that only that target provider responded differently and get them slashed

A better but imperfect solution

In the real world, the actual quality of most services can only be known by clients through:

  • reputation (eg. online ratings of a service provider) but those are notoriously easy to manipulate and safe decentralized permission-less and pseudonymous reputation solutions are an unsolved problem
  • trial periods (but the service could degrade once the trial period is over)
  • previous experience of the client (eg. the client tried the service before and it was good/bad) but then the client bears the risk of their first encounter with a new provider
  • third party random blind audits

In this proposal, we will aim for a self-organized, social response to provider behavior.
The idea is the following:

  • providers need to lock a MAS stake and wait some time before being enabled
  • the MAS stake of a provider defines the level of trust in it, as well as the probability of being randomly selected by clients
  • providers advertise a service and pricing
  • clients choose the service provider they will use through a recommendation algorithm based on:
    • their previous experience with that provider
    • how competitive the offer is
    • the stake of the provider (also provides Sybil resistance)
    • randomness
  • clients can cancel their subscriptions anytime

Proposed structure

Service management smart contract

If someone wants to register as a service provider, they need to call a smart contract with the following data:

  • a stake in MAS that will be locked in the smart contract
  • a service that they are ready to provide (eg. data storage) with SLAs
  • capacity (the max number clients at a given time)
  • a pricing scheme (eg. MAS per month)
  • arbitrary metadata (eg. provider name & description, some signing or encryption public keys, IP address…)

For each service they want to offer, providers need a separate registration.

If a client does not pay, the provider cancels their subscription.

TODO: how does a provider stop being a provider cleanly?

TODO: clients voting with stake to slash a provider ?

4 Likes
2

I agree with the reputation system. We could make it harder to manipulate by using an Elo rating system for the providers combined with a reputation system for the clients (similar to the Waze user rating for their report system, based on their previous report, history, longevity, frequent activity,…).
The issue is that the rating would be off at the beginning.

For the VPN part, could a routing system be used between the available VPN providers? It could prevent any connection issues or access denial.
It might be interesting to see how NYM did it Nym | The Next Generation of Privacy Infrastructure

I think a multistep mechanism is needed:

  • First, the provider stops taking new clients & notifies (On-chain?) its active clients to let them time to change providers
  • After a predetermined period, it can end its services and unstack. All clients that have not migrated will have their subscriptions canceled.

The predetermined period can depend on the type of services, short for internet connection or computation which can easily be routed through another provider, a bit longer for data storage.

I would say so too. This would help prevent spamming to the reputation system and help build a reputation system for the clients.

How to determine if a client’s vote is wrong/not related to its experience with the provider?

1 Like
3

On-chain reputation and reputation of clients, voting

I think that would be an interesting followup but quite complicated to start with. Maybe a first version with just subjective reputation (eg. clients and servers basing their decisions on personal past experience) would be enough for a start. Then independent reviewers can intervene and try the different providers, create rankings, recommendations… like in real life. People can talk about their experience on chats and such. That way, no need for client-side reputation nor any kind of voting, because the clients are the ones paying in practice and taking the risk. Let’s allow reputation to happen socially.

Burns

Burning a small part of the payments would be interesting because:

  • it would cause deflationary pressure
  • it would reduce the incentive for providers to create many fake clients that are actually themselves to boost ratings

But the burn rate should not be to high either to avoid major price hikes.

VPN: inter-provider interaction

The idea of the VPN is to offer a VPN-like decentralized service by allowing providers to lend their internet connection.

For the VPN part, could a routing system be used between the available VPN providers? It could prevent any connection issues or access denial.

Good question. Interconnect between providers opens the way to:

  • more robustness (at least until MultiPath TCP becomes available)
  • possibility of Onion Routing or mix-net flavors for stronger anonymity preservation
  • bridging with other private networks (eg. I2P)
  • possibility of a global Massa private network with its own version of the internet, and various services

But that stuff can come as a V2.

Provider graceful shutdown

Agree, also agree for the on-chain notification since the provider must atomically stop receiving requests.

An application of storage providers: decentralize the Massa indexer

Massa nodes do not keep all history because Massa is high-throughput which would require them to have much stronger hardware to store everything, which would in turn harm decentralization as less people would have the means to be node runners.

That’s why currently https://explorer.massa.net/ is powered by a centralized indexer that stores all (almost a billion !) transactions and blocks since genesis to make them searchable.
This costs us about €3000/month in AWS fees.

What if we did the following:

  • step 1: we move all the past and new data to Massa Storage Providers. Data would be both replicated and split over many providers. Massa Labs would continue paying for it but less in total, like the MAS equivalent of half the current AWS costs. That way, Massa Labs spares some funds for other activities, pays people from the Massa community instead of Bezos, and improves the decentralization of the indexer. The payment could be in MAS, which we would buy on Dusa and give to the providers. That way, coin price would not be impacted but it would stimulate the whole ecosystem and generate volume and arbitrage activity. Less value would be lost to paying for services outside of the community, and Massa Labs would be the first client of the service.
  • step 2: once Massa is heavily used, think of an independent subscription service from clients that does not depend on Massa Labs and ends the centralization of the indexer.

LLM inference as a service

As for the gamers in the community that have strong GPUs, they can provide the unused time of their GPUs for AI language model inference (eg. https://llama.meta.com/) as a service. It would be cheaper than a ChatGPT subscription and could generate a lot of hype because AI is a thing these days.

Prover as a service

I don’t want to spoil too much here, but we are working closely with Starknet and Polygon on ZK-STARK prover systems. Creating proof-as-a-service service providers could be of interest as well.

A note on storage providers

They would essentially allow for DeWeb-like decentralized services but not limited to small html/text websites. Basically stuff like a decentralized Dropbox, or Youtube become possible.

A decentralized cloud

Combining everything there, we could end up with a full 360° decentralized cloud provider competing with AWS and the like.

5 Likes
4

Hey Damir, you brought up a lot of interesting ideas, it would be awesome if it’s implemented!

I agree on the points you made but there are a few areas where I think we could face challenges or would be interesting to deep dive for a v2:

Reputation System:

I have some concerns about relying too heavily on social trust without any formal mechanisms in place, more importantly in the early stages.

A socially-driven reputation system could still be manipulated. Without some form of objective verification (or at least a minimal formal rating system), we could end up with unreliable ratings. I think implementing a lightweight reputation system (cryptographic proofs if possible, randomized client audits, oracle,…) could offer a good balance between flexibility and security.

Reputation will take time to develop, which means early users will still be exposed to the risks of poor service. In the short term, even a simple escrow mechanism, where payments are released only after certain satisfaction criteria are met could help.

A decentralized oracle system could help bridge the gap between off-chain performance and on-chain verification.
Oracle providers would be independent nodes that measure various aspects of service quality, such as uptime, response speed, or data integrity. These nodes could submit their findings on-chain as verifiable proofs.
Clients could submit challenges or requests for oracle verification. For example, a client could request an oracle check to verify connection quality. If the provider is found in violation, penalties could be enforced.
Oracles could also facilitate trust between providers. For instance, if a storage provider is shutting down, an oracle could independently verify the transfer of data to a new provider, ensuring service continuity.
But this would also raise a lot of problems and create more complexity.

Provider Shutdown Mechanism:

The idea of a multi-step shutdown process is logical, but a few practical details need refinement:

  • What happens if a provider goes offline without warning? Relying on them to follow the shutdown process might not be reliable. There should be a failsafe or backup mechanism that automatically migrates clients or alerts them when a provider fails to comply with the shutdown steps.
  • For storage providers, simply notifying users to switch providers may not be enough, especially if the service involves critical data. There should be an automated data migration process in place.

Storage and Decentralizing the Massa Indexer:

To manage the scale of data and keep it searchable we would need a decentralized query mechanism. Search requests would get distributed, minimizing the load on any single provider while maintaining speed and reliability for users accessing the indexer. However, this would be difficult to implement efficiently in a high-throughput blockchain.

Also, distributing large-scale data across multiple providers could increase costs in the long term due to redundancy and replication overhead. There’s also a question of scalability, how do we ensure that as the network grows, the storage system can handle the increasing volume without a corresponding spike in costs?
We could have a redundancy pricing model where clients could choose different levels of redundancy, from minimal redundancy (cheap but riskier) to full replication (more expensive but highly reliable).

Dynamic Pricing & Tokenized Service Vouchers → DeFi Integration:

Dynamic pricing could allow providers to adjust their rates based on various factors like performance metrics, demand & feedback.

We could then introduce tokenized service vouchers that represent access to specific services. These vouchers could be bought, sold, or even staked within DeFi protocols. This will create a secondary market for the service price and boost activity:

  • Users could buy service tokens in advance and trade them on a secondary market. For example, if a user bought storage provider tokens at a low price during a promotion but later doesn’t need them, they could sell these tokens at market value, effectively creating a decentralized service marketplace.
  • Users could stake tokens to lock in service access at discounted rates. This creates liquidity for providers and rewards long-term users while also allowing stakers to earn rewards, a sort of subscription staking.
  • These vouchers could integrate into broader DeFi ecosystems, providing liquidity pools, yield farming opportunities, or more.

Built-in Dispute Resolution via Escrow and Arbitration:

Disputes between clients and providers are inevitable.
Payments could be held in escrow by a smart contract until both parties confirm that the service has been delivered as agreed. If a dispute arises, the funds could be frozen until arbitration resolves the issue.

Third-party arbitrators or an automated dispute resolution protocol could be implemented to handle disagreements. These arbitrators could be selected randomly from a pool of trusted community members or experts in the field, and their decisions could be enforced on-chain.

Arbitrators could be incentivized to remain fair and accurate by receiving rewards for resolving disputes. They could also be penalized for bias or collusion, ensuring a balanced system.