logos-messaging/specs
1
0
Fork 0
mirror of https://github.com/logos-messaging/specs.git synced 2026-01-02 14:13:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

Change first incentivized light protocol from Store to Lightpush (#45)

Browse Source 
* change first incentivized light protocol from Store to Lightpush

* Update standards/core/incentivization.md

Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>

* chore: clarify incentivization PoC architecture for RLNaaS in Lightpush

---------

Co-authored-by: Hanno Cornelius <68783915+jm-clius@users.noreply.github.com>
This commit is contained in:
Sergei Tikhomirov 2024-10-30 14:37:48 +01:00 committed by GitHub
parent 315264c202
commit b38f248b4f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 48 additions and 63 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

111
standards/core/incentivization.md
View File

@ -15,8 +15,10 @@ In an incentivized request-response protocol, only eligible (e.g., paying) clien
Clients include eligibility proofs in their requests. Clients include eligibility proofs in their requests.
Eligibility proofs are designed to be used in multiple Waku protocols, such as Store, Lightpush, and Filter. Eligibility proofs are designed to be used in multiple Waku protocols, such as Store, Lightpush, and Filter.
Store is planned to become the first Waku protocol to support incentivization. Lightpush is planned to become the first Waku protocol with an incentivization component.
We discuss the proof-of-concept implementation of incentivization for Store in a later section. In particular, a Lightpush client will be able to publish messages without their own RLN membership.
Instead, the client would pay the server for publishing the client's message using the server's RLN proof.
We will discuss a proof-of-concept implementation of this incentivization component in a later section.
## Background / Rationale / Motivation ## Background / Rationale / Motivation
@ -41,13 +43,13 @@ In that case, a client MUST provide a valid eligibility proof as part of its req
Forms of eligibility proofs include: Forms of eligibility proofs include:
- Proof of payment: for paid non-authenticated requests. A proof of payment, in turn, may also take different forms, such as a transaction hash or a ZK-proof. In order to interpret a proof of payment, the server needs information about its type. - Proof of payment: for paid non-authenticated requests. A proof of payment, in turn, may also take different forms, such as a transaction hash or a ZK-proof. In order to interpret a proof of payment, the server needs information about its type.
- Proof of membership: for services for a predefined group of users. An example use case: an application developer pays in bulk for their users' requests. A client then prove that they belong to the user set of that application. A similar concept (RLN) is used in Waku Relay for spam prevention. - Proof of membership: for services for a predefined group of users. An example use case: an application developer pays in bulk for their users' requests. A client then prove that they belong to the user set of that application. Rate limiting in Waku RLN Relay is based on a similar concept.
- Service credential: a proof of membership in a set of clients who have prepaid for the service (which may be considered a special case of proof of membership). - Service credential: a proof of membership in a set of clients who have prepaid for the service (which may be considered a special case of proof of membership).
Upon a receiving a request: Upon a receiving a request:
- the server SHOULD check if the eligibility proof is included and valid; - the server SHOULD check if the eligibility proof is included and valid;
- if that proof is absent or invalid, the server SHOULD send back response with a corresponding error code and error description; - if that proof is absent or invalid, the server SHOULD send back a response with a corresponding error code and an error description;
- if the proof is valid, the server SHOULD send back the response that the client has requested. - if the proof is valid, the server SHOULD send back the response that the client has requested.
Note that the protocol does not ensure atomicity. Note that the protocol does not ensure atomicity.
@ -76,48 +78,43 @@ message EligibilityStatus {
We include the `other_eligibility_proof` field in `EligibilityProof` to reflect other types of eligibility proofs that could be added to the protocol later. We include the `other_eligibility_proof` field in `EligibilityProof` to reflect other types of eligibility proofs that could be added to the protocol later.
## Implementation in Store (PoC version) ## Implementation in Lightpush (PoC version)
This Section describes a proof-of-concept (PoC) implementation of incentivization in the Store protocol. This Section describes a proof-of-concept (PoC) implementation of incentivization in the Lightpush protocol.
Note: this section may later be moved to Store RFC. Note: this section may later be moved to Lightpush RFC.
Store is one of Waku's request-response protocols. Lightpush is one of Waku's request-response protocols.
A Store client queries the server for historic messages. A Lightpush client sends a request to the server containing the message to be published to the Waku network on the client's behalf.
A Store server responds with a list of messages that pass the user's filter. A Lightpush server responds to indicate whether the client's message was successfully published.
See [13/WAKU2-STORE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/13/store.md) for the definitions of `HistoryQuery` and `HistoryResponse`. See [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) for the definitions of `PushRequest` and `PushResponse`.
The PoC Store incentivization makes the following simplifying assumptions: The PoC Lightpush incentivization makes the following simplifying assumptions:
- the client knows the server's on-chain address `A`; - the client knows the server's on-chain address `A` (likely on an L2 network);
- the client and the server have agreed on a constant price `r` per hour of message history. - the client and the server have agreed on a constant price `p` per published message.
To query messages from a period of length `t`, the client: To publish a message, the client:
1. calculates the total price `p` as `p = r * t`; 1. pays `p` to the server's address `A` with an on-chain transaction;
2. pays `p` to the server's address `A` with an on-chain transaction; 2. waits until the transaction is confirmed with identifier `txid`;
3. waits until the transaction is confirmed with identifier `txid`; 3. includes `txid` in the request as a proof of payment.
4. includes `txid` in the request as a proof of payment.
It is the server's responsibility to keep track of the `txid`s from prior requests and to make sure they are not reused. It is the server's responsibility to keep track of the `txid`s from prior requests and to make sure they are not reused.
Note that `txid` may not always be practical as proof of payment due to on-chain confirmation latency. Note that `txid` may not always be practical as proof of payment due to on-chain confirmation latency.
To address this issue, future versions of the protocol may involve: To address this issue, future versions of the protocol may involve bulk payments, that is, paying for multiple requests in one transaction.
In that scheme, after a bulk payment is made, the client will not have to face on-chain latency for each new prepaid request.
- paying for multiple requests in one transaction; ### Wire Format Specifications for Lightpush PoC incentivization
- using faster (likely L2-based) payment mechanisms.
### Wire Format Specifications for Store PoC incentivization
#### Request #### Request
We extend `HistoryQuery` to include an eligibility proof: We extend `PushRequest` to include an eligibility proof:
```protobuf ```protobuf
message HistoryQuery { message PushRequest {
// the first field is reserved for future use string pubsub_topic = 1;
string pubsubtopic = 2; WakuMessage message = 2;
repeated ContentFilter contentFilters = 3;
PagingInfo pagingInfo = 4;
// numbering gap left for non-eligibility-related protocol extensions // numbering gap left for non-eligibility-related protocol extensions
+ optional bytes eligibility_proof = 10; + optional bytes eligibility_proof = 10;
} }
@ -126,60 +123,48 @@ message HistoryQuery {
An example of usage with `txid` as a proof of payment: An example of usage with `txid` as a proof of payment:
```protobuf ```protobuf
HistoryQuery history_query { PushRequest push_request {
// the first field is reserved for future use pubsub_topic: "example_pubsub_topic"
pubsubtopic: "example_pubsub_topic" message: "example_message"
contentFilters: []
pagingInfo: {
// provide values for PagingInfo fields
}
eligibility_proof: { eligibility_proof: {
proof_of_payment: 0xabc123 // txid for the client's payment proof_of_payment: 0xabc123 // txid for the client's payment
// eligibility proofs of other types are not included // eligibility proofs of other types are not included
}; };
} }
``` ```
#### Response #### Response
We extend the `HistoryResponse` to indicate the eligibility status: We extend the `PushResponse` to indicate the eligibility status:
```protobuf ```protobuf
message HistoryResponse { message PushResponse {
// the first field is reserved for future use bool is_success = 1;
repeated WakuMessage messages = 2; // Error messages, etc
PagingInfo pagingInfo = 3; string info = 2;
enum Error { + EligibilityStatus eligibility_status = 3;
NONE = 0;
INVALID_CURSOR = 1;
+ NON_ELIGIBLE = 2;
}
Error error = 4;
+ EligibilityStatus eligibility_status = 5;
} }
``` ```
Example of a response if the client is eligible: Example of a response if the client is eligible:
```protobuf ```protobuf
HistoryResponse response_example { PushResponse response_example {
messages: [message_1, message_2] is_success: true
pagingInfo: paging_info info: "Request successful"
error: NONE
eligibility_status: { eligibility_status: {
status_code: 200 status_code: 200
status_desc: "OK" status_desc: "OK"
}
} }
}
``` ```
Example of a response if the client is not eligible: Example of a response if the client is not eligible:
```protobuf ```protobuf
HistoryResponse response_example { PushResponse response_example {
messages: [] // no messages sent to non-eligible clients is_success: false
pagingInfo: paging_info info: "Request failed"
error: NON_ELIGIBLE
eligibility_status: { eligibility_status: {
status_code: 402 status_code: 402
status_desc: "PAYMENT_REQUIRED" status_desc: "PAYMENT_REQUIRED"
@ -216,7 +201,7 @@ Copyright and related rights waived via [CC0](https://creativecommons.org/public
### normative ### normative
- A high-level [incentivization outline](https://github.com/waku-org/research/blob/master/incentivization.md) - A high-level [incentivization outline](https://github.com/waku-org/research/blob/master/incentivization.md)
- [13/WAKU2-STORE](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/13/store.md) (for Store-specific sections) - [19/WAKU2-LIGHTPUSH](https://github.com/vacp2p/rfc-index/blob/main/waku/standards/core/19/lightpush.md) (for Lightpush-specific sections)
### informative ### informative