State Channels

[kwannoel]

In GitLab by @fahree on Feb 10, 2021, 14:08

See previous prototype.

General principle

• [ ] In the compiler and runtime, replace the sending and receiving of messages from a simple mechanism that sends bytes irrespective of state, by a protocol that knows how to speculate between several committed or uncommitted on-chain and off-chain states.
• [ ] Most compiler passes remain the same

Contract behavior

• [ ] Compared to direct-style, the contract isn't designed to play every message, but to restore any fast-forward consensual state and verify any message.
• [ ] Given a state consensually signed by all parties with a message count great than that of the last consensually signed message accepted by the contract, it will reset its state to the new state.
• [ ] Given a message from a single party valid from the current state, it will accept the message and update the state, very much like in direct style (modulo some extra wrapping) — this is necessary to add or remove resources or participants to/form the contract, as well as to further the interaction when one party is unresponsive (typically invoking a timeout after a few messages). [Note that these direct messages do NOT increase the signed message count.]
• [ ] Given a settlement signed by all parties and according input assets, it will distribute resources according to that settlement, close the contract, and if applicable roll the remaining assets over to a new contract with a new nonce and possibly a new set of participants.

Client behavior

• [ ] Optimistically, send and receive messages to gather signatures from all active participants.
• [ ] Fall back to using the blockchain if some person stops cooperating
• [ ] Constantly watch the blockchain for challenges in case some other participant invokes this fallback mechanism.
• [ ] All of the above is abstracted as communication in a process execution, but execution actually involves non-local effects in the runtime.
• [ ] Each unconfirmed state leads to speculative execution, forking the state of the DApp so it can still work from any of the previous confirmed states.
• [ ] If some interaction requires adding or removing resources or participants to/from the interaction, invoke the contract from the latest state for that.
• [ ] If some other participant posts a new message from the latest signed state, accept it.
• [ ] If the end of the interaction is reached, sign a settlement.
• [ ] If some other participant posts an old state on the chain, use the latest state to reset the contract.
• [ ] When a settlement is signed, it does not need to be posted, unless one of the participants actually wants to get some assets in or out of the contract. But until it is posted, new participants should not trust the contract to have accepted their role, and should consider participation as speculative, whereas old participants who are leaving the contract must still cooperate for the computation to make progress.

Clocks:

• [ ] Maybe Lamport clocks are necessary for the "timestamp" to avoid attacks whereby a state is replaced by another state with conflicting history.

e.g. Alice and Bob have agree on a state S with timestamp T. Alice sends Bob a message with state S plus a message, but Bob keeps it and dishonestly claims he didn't receive anything, so posts a message on the consensus with S plus a message. If messages on the consensus do not increase the timestamp, then Bob can later use the message to cancel all that happened on the consensus, the information in which he might be able to use to win starting from the message posted afterwards.

If on the other hand, messages on the consensus do always increase a linear counter, then, Bob might sometimes be able to do the opposite trick: interact with Alice, extract information, then post and old state followed by many enough messages to pass past the counter and cancel that history.

Thus, a linear clock can only be used for state channel timestamp in a context with strict alternation between participants with no choice as to who is next and to how many messages they may send — like rps. It looks like pure payment channels like the Lightning Network are also safe with a linear clock, because there is no message that can be sent on the consensus to modify an accepted state, except a request to close the channel (which is safe, as long as the only other participant may post a new state update before actual close).

In a more general setting, Lamport clocks and more generally CRDTs could solve the issue, wherein message history is a DAG rather than a sequence. Then, a participant may always add but not remove messages.

• [ ] Actually, a linear clock might be enough if honest participants are always careful to: for each clock number, have a clear leader only diverge by at most one from a previous consensual state wait for soft consensus before to sign any new state. if timeout happens, or cheating is detected (e.g. two conflicting messages from the leader), go back to the hard consensus, and figure out which is the next step. Punish the leader if there was double signatures from him.

[kwannoel]

In GitLab by @fahree on Feb 10, 2021, 22:52

changed the description