Yes Even though this is not part of the protocol, this could easily be done with the current implementation. The most important thing is that contracts are really cheap, fast and easy to create inside a state channel.
This would take advantange on various different mechanincs mostly contracts calling other contracts. Probably the most trivial implementation would be a contract that keeps the balances of Alice and Bob for various tokens that had been invented inside the channel (closely resembling ERC-20 contract). So in order for Alice to use
gameContract1 - she makes a call to
balanceHolderContract (the contract that has some
myGameTokens that she can use). While calling
balanceHolderContract, she provides the address of
gameContract1, its function to be called, params and etc.
balanceHolderContract moves some
myGameTokens in its state from Alice’s balance to
gameContract1 or whatever address that make sense in this case.
Probably the most important thing would be to build contracts keeping in mind that at any time both Alice and Bob can resolve all contracts via the solo closing sequence. Or not, actually. Some contracts might be unilaterally unresolvable by purpose (and potentially burn the tokens they hold in a solo close). This really depends on the use case.
Let’s have Alice and Bob. They have a state channel. Alice wants to play tic-tac-toe with Bob. Alice proposes Bob that they both add a certain contract inside the state channel off-chain state.
In our current implementation Alice provides the contract’s code. There is no check if this contract is present on-chain or not. It is up to Alice and Bob what contract they want to use. We will make it possible to drag contracts that are present on-chain to the channel’s off-chain state but this will be post main net. This will be just a shorthand for getting the contract’s code and will not impact the protocol. On-chain contracts have a mechanic for reference counting the on-chain contracts that refer to them but there is no way of doing this for off-chain contracts. It would be nasty if the contract you’re refering on-chain disappears . Since having contracts off-chain is so cheap - off-chain state will copy those in the channel’s state, so participants are safe if the on-chain contract is closed.
On-chain and off-chain contracts solve different use cases. While on-chain ones are public, it is much more cheaper to use the off-chain ones and you can take advantage of a soft-real time interaction. I’d imagine on-chain and off-chain contracts being radically different.
Both of them execute the contract call locally. This must be deterministic. Then they compare output and results - they must match. This is how we keep state channels trustless.
If there is any dispute, anyone of the participants can bring the contract and its call on-chain. This is the forcing of progress. Then it is the miners who execute the contract.
State channels updates are 2 phased ones: Alice proposes and update, Bob agrees to it. Agreement is achieved by the update being co-signed.
Each update consists of some change being applied to the channel’s state and the root hash of the new state hash (with the change being applied). If the other party is happy - co-signs the message and returns it back. Then the proposed state is the currently latest one.
It is worth mentioning that at no point the full state is being sent between them - each party persists its own version of the state locally and applies upcoming changes to it. The proof that they both share the same state is the root hash of the MPT produced by all MPTs in the channel off-chain state (we call this
You can read the full state channels description here. The various on-chain transactions that are part of the protocol are in ON-CHAIN.md. We provide FSM that connects to other channels clients via a noise protocol. Its messages are described in the OFF-CHAIN.md. It would be really helpful if you want to build a noise protocol client of your own. We also provide a WebSocket client (that uses the FSM and noise) which would probably be the easiest way to use channels. You can read about it here.