Client-Side Validation

Build Research
1

Background:

The heavy technical burden of the original Pocket Network session design has led the implementation team to try to find another more feasible solution to validation (consensus). In addition, a conversation with the B2B team has introduced two possible product problems:

  1. The current model doesn’t validate the data until after the client receives it
  2. Clients don’t want to trust a system to validate their data. They want to validate their own data.

Hypothesis:

Creating and maintaining a stateful, distributed shard for each individual Pocket Network Session is inefficient, complicated, and only provides ‘after-the-fact’ validation to the response data the client receives. Client-Side validation allows a stateless, communicationless, shard which executes in parallel and allows real-time validation for the clients.

Design

  1. The client sends X requests to X nodes
  2. The client receives X independent responses from X nodes
    a. Each nodes response is weighted by their karma score
  3. The client chooses the majority answer
  4. The client sends X requests + validation grade to X nodes
    a. The validation grade and request is signed by the client
  5. The nodes submit their batch transaction after the session is concluded.
    a. The nodes are paid based on their karma score (meaning little mint goes to low karma score etc.)

Client%20Side%20Validation%20Proposal
Client%20Side%20Validation%20Proposal761×911 91.4 KB

Tradeoffs

  1. Client-side validation is more client signature data on the blockchain (signature < 75 bytes)
  2. Burden on the client: more signatures are required for each request / response
  3. Clients will have to wait for a certain timeout before making the next request
2

Sounds like in a general a more efficient design.

In tradeoff 3. wait for a certain timeout.

How does this effect the end user experience?

Is it significant enough to make the end-user lag?

3

Good question. It will add lag to the end user. We will do our best to make it negligible lag. However, interestingly enough this may allow customization schemes on the client side.

4

Ok that’s my one worry, any DApp that has mainstream aspirations will need to have as little lag as possible.

Customization schemes client side? Can you give me an example or two?

5

Tracie just brought this to my attention, and correct me if I’m wrong @Andrew

Clients could choose how strong they want their security guarantees to be. By default we can recommend 5 nodes to respond, which would increase difficulty in having dishonest nodes returning bad data.

A client can choose to have 1 node respond for less security, but quicker response.

Interestingly enough this can act as a filter mechanism for Karma, meaning to earn Karma for relays, you must be in a larger set than (n), because if you’re responding as an individual node in a Session, the protocol can’t be sure you had checks on that response.

2 Likes
6

You’re correct. In addition, you could do parallel processing by sending different requests to each node. That’s what I meant by client-side customization @Patrick727

2 Likes