Avoid global settlement of state channels

[Zerim]

Background

The hybrid network specification adopts a state channels construction for achieving scalable off-chain micropayments.

Using state channels, once an Indexing Node or an end-user has established a state channel with a hub on-chain, they may exchange an unlimited amount of state update messages off-chain between participants in a "virtual" state channel, without submitting any transactions on-chain, until one of the participants wishes to settle their state channel with the hub.

While this theoretically allows for unlimited micropayments to be made without settling on-chain, the protocol currently specifies that channels must be settled one per "round." This has the following benefits:

• Creates market visibility
• Enables inflation rewards calculations

Market Visibility

In order to have a dynamic marketplace, with efficient price discovery, it is important that Indexing Nodes are able to adjust the datasets that they choose to index in response to market demand. This requires visibility into the volume and price of requests to read data from a particular dataset. Otherwise, an Indexing Node may command a monopoly on serving requests for a particular dataset indefinitely, by never settling their micropayments on-chain, and thus never alerting potential competitors to the high demand for said dataset.

Inflation rewards calculations

There are currently two rewards in the protocol, participation rewards and curator rewards, which are calculated as a function of global transaction activity on the network.

Curation rewards are tied to how valuable a dataset is to the rest of the network, measured as a percent of global transaction value.

Participation rewards are similarly measured based on how valuable the participation is to the rest of the network, measured in terms of their aggregate transaction value relative to the global transaction value in the network. We do not want to reward participation which does not contribute to the rest of the network.

Problems

The above construction has the following drawbacks:

Global settlement is inefficient. Depending on how we design the state channels, this would create a constant overhead on the Ethereum mainnet, requiring us to settle N state channels for every round duration R, measured as a number of blocks, where N is the amount of Indexing Nodes actively staking on the network.

Global calculations are expensive. Any calculation that involves aggregating all the transaction activity in the network is likely to be expensive. This also raises the question: Who will pay the gas fees for this calculation? (This is currently not specified).

Incentivizes ballot stuffing. Depending on how expensive the fees charged by the hub for micropayments are, and what the participation reward rate is, there is a strong incentive for "stuffing the ballot" (i.e. an Indexing Node making dummy transactions in order to make their share of the participation reward go up).

Solution (WIP)

Any proposed alternate design should mitigate the above drawbacks while keeping as many of the benefits, which the current mechanisms are designed to provide, as possible.

If we assume a hard requirement that we should avoid global settlement of state channels, then we may explore two separate, but loosely related, sets of solutions: those that address the market visibility requirement, and those that propose an alternate inflation rewards calculations.

Market visibility alternative solutions

1. Centralized logging service (extra-protocol). The service would be very similar to the centralized fisherman service currently mentioned in the hybrid network spec. It would be responsible for collecting logs of queries from users, and making aggregated stats available to Indexing Nodes as well as users of the network.
2. Organic state channel settlement. Rely on unforced state channel settlements for market-visibility, as users and indexing nodes close channels on-chain, through the natural course of using the protocol.
3. Log chain. A proof-of-authority (PoA) or delegated proof-of-stake (DPoS) side-chain, which is used exclusively for logging query attestations and aggregated summaries of those attestations. A rough outline of how this might work:
   1. User submits read operation and locked micropayment to Indexing Node
      • References latest block on the log chain.
   2. Index Node responds with response and attestation.
   3. Index Node MUST submit a merkle root to log chain within E blocks on the log chain, otherwise the attestation is considered invalid.
      • Merkle root could be a sparse merkle tree or merklix tree to allow for inclusion and exclusion proofs.
        4. User has three choices:
        5. Payment
        6. Non-Payment
        7. Challenge for an inclusion proof, increasing the locked micropayment by a nominal amount.
        8. Which invites the following corresponding actions by the Indexing Node:
        9. Accept payment, no further action required.
        10. Settle the state channel settlement, this will require supplying a valid attestation as well as merkle proof that proves the attestation was posted to the logchain within E blocks.
        11. Provide a merkle proof that the attestation in order to unlock the micropayment.
            • Failure to do so, could lead to slashing, either of some amount in the state channel, or out-of-band in a separate dispute process.
        12. Some time later The Indexing Node submits a summary of their activity since coming online, or since posting their last summary. It is accompanied by a SNARKs or STARKs proof, which has the previously submitted merkle roots as inputs, and outputs a data structure which includes:
            • Total gas consumed
            • Total bandwidth consumed
            • Total value transacted for gas
            • Total value transacted for bandwidth

Credit goes to @tomclose for providing the spark for the log chain idea. A relevant example of using SMTs for efficient proofs of inclusion/non-inclusion on a high throughput side-chain is Plasma Cash (they use Bloom filters as an additional optimization).

Inflation rewards calculations alternative solutions (TBD)

[leoyvens]

On ballot stuffing:

In a network like Ethereum any work can be readily assigned to any stake holder. So work, and therefore inflation rewards, can always be split in proportion to the stake held.

However in our network the query work can only reasonably be assigned to stake holders that are already indexing that subgraph, so you can direct the work, and therefore inflation rewards, towards specific stake holders.

Seems difficult to square this with participation rewards.

[jtremback]

Random idea, and I haven't really thought it through much- Have clients occasionally call a contract which fires events containing their usage reports. Interested parties can monitor these. Another approach would be to have the clients put the usage report in storage and then delete it after a block, getting the gas refund. I'm not sure which of these is cheaper.