Clients are allowed for free-trial connection from the server. Since server needs to win the reputation
before earning money from clients.
During the connection, server can always send some announcements to clients via LNR. Basically LNR
can include arbitrary information necessary, e.g. current price(wei per token), remaining free-trial time, service token contract address.
Regarding the remaining free-trial time, it doesn't mean: (1) free clients are still guarantee to keep connection at that much time. (2) free clients will be kicked out after the free-trial. It only shows that free client with very high chance to be kicked out after free-trial.
By the way, do we need to consider a minimal free-trial connection time? During this time, connection are promised.
So server can use the cheap UDP packet to broadcast the status of itself to all potentional customers.
After several minutes trial, the client thinks it's a good server for data serving, so it can choose to pay for the server the long term stabilized paid service.
Each server needs to deploy a service contract if it wants to earn money(Of course, contract based micropayment is only one approach for payment. Server can also offer some other approaches like raw ether transaction, even offchain fiat payement. It's all decided by clients ).
On-chain transactions are super expensive, so we will try to move all payment offchain.
The payment mechanism can like this:
-
Clients send a on-chain transaction to deposit a few ether into server's service contract
-
All following token purchase operations are done off-chain.
- Client sends a cheque to server, with
Cumulative issued amountinside - Server receives the cheque and ensures it's issued by the client, gives it corresponding tokens
- When the token is almost used up, server can use LNR to notify the client to renew the tokens
- Client sends a cheque to server, with
-
Server can choose to withdraw all expense of clients by submitting the signed cheque from clients
- We don't need to open a challenge window for clients. Since it's signed by it.
- It can happen that server receives the cheque but never issue tokens for the client. Or even worse the server can totally disappear with all money. So client should be responsible for itself by issuing small amount cheque(perhaps one time each hour)
-
Client can choose to withdraw it's deposit, but we need to open a time window for server to submit the latest cheque issued by client. If server is offline and miss the time window, client may withdraw all
deposit.
- But it's acceptable, server doesn't lose money, but just offer some free services.
- It will encourage the server to keep online all the time
- We don't need the monitor tower service which is necessary for lightnining network or raiden network. So thing is get simplified a lot.
-
All deposit-withdraw behaviors can be recorded in the contract.
-
Price and token
- Server can update price, but it's not allowed to update the price too frequently. For example: update every second. So it's hard for client to determine which price is the current price.
- 10 second one time is acceptable
- The amount of issued token is decided by server. It means client will only send that much money to server, and server should issue corresponding tokens
- The only way to check the token balance for client is via the LNR by server. Server can always send the token balance of client with stable frequency.
- If client feels the money is used too fast because server is cheating him, client can choose to stop renewing new tokens.
We can also use service token contract to store some historical serving data, like all deposit-withdraw behaviors, it can act as the reputation source.
Like the server already serves 100,000 clients in the past 2 years, earn 100 ether from the client and the average serving time is.
Basically the longer average serving time, the higher service quality server has. It's kind of public reputation
data.