Node Marketplace

[pedro.argento]

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.

[milton-cartesi]

This is a great proposal! I believe that a robust marketplace framework for node runners is fundamental for Cartesi and app-chains in general.
Eager to hear more details about possible incentive mechanisms, and how you imagine payments being done.

[felipeargento]

There are a few things I really like about this proposal:

• The ability to have a sort of prediction market for the popularity of a dapp, which can help a lot to navigate a scenario with lots and lots of appchains.
• The match between demand and node supply, which will help deal with ghost chains - which, I guess, tend to be even more prevalent in the web3 space.
• The existence of a mechanism to slash misbehaving readers, which is a real problem in the web3 reader space (infura, alchemy etc) afaik.

This will add quite a cool convenience layer for deployment of dapps and node running.

[tuler]

@pedro.argento

get a functional version out as soon as possible

In the spirit of “getting a functional version out as soon as possible” what is the relation of such proposal with the definition of the authority validator of an application. Is the validator also under the gateway? Or is the validator outside of this proposal completely?

The cartesi rollups node 1.4 has capabilities to disable validation. So it’s possible to run a node without the validator “role”. But it does not have the capabilities of running a node only for validation. The reader role is always there.

[erick.demoura]

It would be great if the marketplace is also used for validation.

I have been envisioning the introduction of Dave (unpermissioned validation) as an extension of a permissioned setup since Dave’s specification doesn’t cover the need for at least one node in charge of placing claims.

Even with a quorum implementation, as we enter the Dave era, an (unbounded set of unpermissioned) node runners could seamlessly expand the previous set of permissioned validators.

[erick.demoura]

As we discuss the validator marketplace while keeping an eye on simplicity, we need to consider staking and slashing as means to disincentivize node misconduct. Here is a proposal that counts on Cartesi’s current staking system (Noether) as the basis for this requirement.

Premises:

1. Noether can be replaced by an equivalent L2 implementation on Cartesi Rollups
2. Besides being more cost-effective, Noether’s new version can include slashing as a feature, which is triggered upon evidence of incorrect rollup node behavior. The slashing mechanism can be used for both reader and validator nodes
3. Stakers can be incentivized to migrate their CTSI to the new system in a timely yet comfortable way

The plan can be rolled out in two consecutive phases:

Phase 1 - Staking on Noether without slashing mechanism

Noether has passed the test of time and remained a reliable staking mechanism throughout the years. In this phase, Noether is used as a simple gate into the marketplace.

Any node runner entity willing to participate in Cartesi Rollups’ node marketplace is required to prove a minimum staking on Noether. The minimum staking amount can be decided in Cartesi’s public forum and may be put under snapshot voting from CTSI holders.

Since Noether doesn’t implement slashing, staking is only used as a pre-selection process and not as a way of discouraging node misconduct.

Therefore, during Phase 1, validator nodes must be permissioned. Permissioning may also be imposed on reading services for better security.

Phase 2 - L2 Noether equivalent with slashing mechanism

Once the new staking system implemented on Cartesi Rollups is in production, it’s possible to conceive the following migration plan.

First, an allocation snapshot is taken for every Noether staker and considered in the new system. While Noether immediately stops receiving and distributing funds from the reserve mine, the new system takes over and starts to fulfill this role, based on the snapshot.

During a “transition period” to be defined (e.g. 1-3 months), stakers would be rewarded according to a function that takes as parameters the snapshot and new staking brought into the system, with an extra incentive to move funds as soon as possible.

For example, during the transition time, the system can disburse mine rewards at a faster rate, such that it:

• Keeps rewarding users at the same rate as before, based on their staking snapshot
• Provides extra reward to newly added tokens, where tokens added to snapshot accounts have more weight compared to new tokens not associated with snapshot accounts

Regardless of the specific incentive in place, the idea is to ensure that Noether stakers are incentivized to bring most or all of their tokens into the new system before the end of the transition period.

Assuming the new staking system implements slashing, we have the pre-conditions in place to render the marketplace unpermissioned so that reader nodes and validators can place slashable stakes as a guarantee of correct node behavior.