Context
This proposal is about reader nodes only, not claim posting validators. So when thinking about end users or DApps, it’s useful to think of a front end website that wants to display information about one or more DApps.
Being an application-specific rollup, DApps deployed with Cartesi do not get a network of node runners ready to run and support the application out of the box. It’s up to the DApp developer to run its own node or seek the services of a professional reader node operator.
Right now, the only way to get professional operators is through a bilateral agreement, which brings some challenges:
- Where to find node operators?
- How to monitor the reliability of available operators?
- How will node runners know what DApps will generate demand?
- How to figure out what is a fair price to pay for read queries?
Proposal goals
We propose a reader node marketplace that matches reader demand (queries) to reader nodes, taking into account node capacity, reliability, and costs. This match should be accompanied by a reward system that incentivizes fair price formation and integrity of the information provided.
This proposal aims to describe the simplest components that achieves the stated goals so we can get a functional version out as soon as possible. Each component can grow in complexity and be replaced for future versions to achieve additional goals or improve the product according to community and stakeholders feedback.
Goals:
- Match nodes and applications (per demand).
- Incentivize proper reporting.
- Provide Fair price formation.
- Incentivize participants that have vested interest in the Cartesi ecosystem.
This proposal is about convenience only: Participation by application/frontend developers or node runners is not supposed to be mandatory. It will always be possible to bypass the marketplace and run a node independently or agree bilaterally with a validator.
Components
Additional read: The Graph documentation can provide more context for some concepts laid out for those components as there are a lot of similarities in what we are trying to accomplish.
Application discovery
Applications that are popular in the Cartesi ecosystem or more useful to the community should be prioritized. Also, they need to be on node runners’ radar so a lot of operators can be ready and available to run them at any time. We need to allow users to signal with their tokens what DApps should be on top of the list.
If those signalers get rewarded with part of the query fees, they are incentivized to report their true beliefs about the application’s usefulness and if we make the reward bigger for early signalers we can incentivize a network of users that scan the ecosystem for new DApps with potential and bring them notoriety.
Additionally, we can use CTSI as the currency to signal, ensuring that signalers have an incentive to choose applications that will be useful to the Cartesi ecosystem.
Reader node stake
To ensure that node runners will provide good information, they need to be liable for untruthful reporting. So there has to be a mechanism to financially punish nodes that misbehave. We propose a stake that can be slashed if needed.
The ability to fulfill queries of a node should be limited as a function of their stake, as the potential damages increased with the number of queries.
It’s also convenient to use the CTSI as the staked token, creating an additional incentive for good behavior since node runners will (literally) be stakeholders of the ecosystem.
Gateway/load balancer
The gateway redirects the queries from applications to nodes. The job of the load balancer is to receive a query, check what awaken nodes can run the necessary application, and distribute to the node according to some criteria: price, round robin, etc.
The gateway provides front end developers with a single entry point to send queries without needing to know individual validators.