Felföldi Zsolt zsfelfoldi

A quick explanation of the `expiredValue` structure

Goal

The lesPay token sale model uses service tokens that continuously "expire" under certain conditions, meaning their value is reduced exponentially over time. Expiration happens when some amount of free connection is possible and therefore all existing tokens are spendable. Expiration can be interpreted as a kind of "spendability" fee that incentivizes clients to indeed spend their tokens in a limited time frame. This can be realized in two ways:

with "inflationary" units; if all prices rise exponentially then value of existing tokens is reduced inversely
with "stable tokens"; if the nominal value of each token is stable then the token balances should be reduced continuously

The second interpretation fits with the model better because service tokens (which are basically a promise from the server) are meant to have a more or less predictable purchasing power. With stable token nominations the client can expect the prices to not change qui

createDeposit(amount map[common.Address]uint64) depositID
- sends a transaction to create a new deposit with the given target allowances
subscribeDepositEvents(ch chan struct {id depositID, state int})
- sends an event to the given channel every time a deposit goes into pending, active or expired state
estimatedExpiry(id depositID) time.Duration
- returns the estimated remaining time while cheques can still be written using this deposit
allowancesLeft(id depositID) map[common.Address]uint64
lastCheque(id depositID, to common.Address) (totalSpent, allowanceLeft uint64)
writeCheque(id depositID, to common.Address, amount uint64) (totalSpent, allowanceLeft uint64, proofOfPayment []byte)
- creates a cheque if the deposit is in active state and there is enough allowance left (otherwise proofOfPayment should be nil)

Simple probabilistic payment channel for LES payments

It is possible to do simple probabilistic one-to-many payments with one condition: the set of potential recipients and their assigned probabilities should be decided when creating the payment contract. This is actually a very good fit for light client incentivization. A client can collect many potential recipients (anyone who provided free service) but cannot really know how a particular server will actually react to receiving payments and whether it is worth paying for over the long term. Starting with very small payments is preferable. A one-to-one channel can limit the amount redeemable at the receiver side but the sender still has to pay transaction costs to build a payment route to every new potential receiver. Therefore it has to expect a high amount of free service from every server before risking the first payment. This could make the bootstrapping process for clients slow and/or expensive. One the other hand the proposed method could build a p

Payment module

LES in-protocol payments can be sent using multiple payment technologies or even multiple currencies. These are realized as plug-in modules. The payment sender module generates a "proof of payment" that the receiver module can interpret and verify. These proofs can be transmitted through an LES connection or LESTALK UDP messages.

Note: the design allows using multiple currencies on both the client and server side. Each payment module uses one specific currency but it can handle value conversions on both ends. In the first implementation we won't allow this though, the first payment module should only handle ETH. This makes value calculations a lot easier for requestPayment and paymentCost. Expected transaction costs have to be considered but that can be very simple too (hardcoded gas cost, user specified gas price).

Payment receiver module

func receivePayment(from enode.ID, proofOfPayment, oldMeta []byte) (value uint64, newMeta []byte, err error)

title	sort_key
les Namespace	C

The les API allows you to manage LES server settings, including client parameters and payment settings for prioritized clients. It also provides functions to query checkpoint information in both server and client mode.

TOC {:toc}

ServerInfo() map[string]interface{}: query server info

minimumCapacity: minimum allowed capacity for any client
freeClientCapacity: capacity assigned to free (unknown, non-priority) clients
totalCapacity: total allowed capacity of simultaneously connected clients (may change dynamically during operation)
totalConnectedCapacity: total capacity of currently connected clients
priorityConnectedCapacity: total capacity of currently connected priority clients
totalPriorityCapacity: total capacity of all priority clients (may exceed totalCapacity in which case priority clients might be rejected too)

SetClientParams(ids []string, tags []string, params map[string]interface{}) error: set certain parameter fields for each client whose id is in the ids list or has all tags in the tags list

userTags: user tags assigned to the client

Modular Protocol Framework proposal

Author: Zsolt Felfoldi [email protected]

Abstract

This document proposes a standardized handshake and message/metadata format for peer-to-peer protocols. Implementing this standard in Ethereum-related protocols would make it easy to share mechanisms like flow control or micropayment incentivization. It could also replace devp2p protocol multiplexing which separates protocols completely and instead handle different protocols as not necessarily disjoint sets of supported messages or message/metadata combinations.

Server capacity

In the LES service model capacity is defined as a scalar value which is assigned to each client while the total capacity of simultaneously connected clients is limited (totalConnCap <= totalCapacity). The exact meaning of capacity values may depend on the server implementation and may change in subsequent versions. The behavior expected from the server is that in any situation the served amount of similar types of requests should be proportional to the capacity value. (Note: this behavior is also tested by https://github.com/ethereum/go-ethereum/blob/master/les/api_test.go). The server also specifies specifies a minimum useful value for client capacity minCapacity which in practice means a large enough flow control buffer that allows the client to send all types of requests.

The total capacity of the server can change dynamically for various reasons. The actual request serving capacity can change due to external circumstances and it can only be properly measured while actually serv

	package main

	import (
	"fmt"
	"math"
	"sort"
	)

	const (
	maxLevel = 10

	### New LES server API calls implemented in https://github.com/ethereum/go-ethereum/pull/18230

	// TotalCapacity queries total available capacity for all clients
	func (api *PrivateLightServerAPI) TotalCapacity() hexutil.Uint64

	// SubscribeTotalCapacity subscribes to changed total capacity events.
	// If onlyUnderrun is true thenhttps://github.com/ethereum/go-ethereum/pull/18230 notification is sent only if the total capacity
	// drops under the total capacity of connected priority clients.
	//
	// Note: actually applying decreasing total capacity values is delayed while the