I was inspecting the Gomuku application sample where channel operations are shown in a web app. From what I saw, seems there is no state channel + Smart contract interaction in this sample; I mean using SC functionality in a state channel message exchange, for example as a transaction verifier ( your move is invalid, your move does not comply with a,b,c, and so on).
The example does effectively open/close channels, trigger updates, and message exchanges - which is undoubtedly useful- , but may be there’s a more complex example including SC for validating state ?
When gomoku game was first written there wasn’t support for contracts in state channels in javascript sdk. That’s why generic messages were used instead. So only the result of the game is secured (after it’s signed by both participants).
Now smart contracts are implemented in state channels in javascript sdk and gomoku contract is being written (should be released soon). I’ll write in this thread when this is done.
You are correct. The benefit of using smart contract instead of generic messages in case of gomoku game is that with smart contract each move is signed by both players and can be executed on chain in case of dispute. So it’s not possible to cheat that you didn’t make a move or you made a different move.
Thanks for your answer, so in the context of two player games I assume that the following “full offchain” model is possible:
players agree to start a new game thru a new channel
they create an instance of a smart contract in the channel. The state of this smart contract is part of the state tree in the channel.
they both play and the Smart contract verifies e.g valid moves, if the game is finished, etc. The smart contract modifies the internal state of the channel , so the players actually exchange Smart Contract state updates.
they finish and the last valid state is enforced in the mainnet.
Now, this is a case where a SmartContract works as bussiness logic for State channel peers, like some kind of "State Channels on steroids "; I mean instead of exchanging simple M messages, we can exchange e.g M' = f(M) messages, transformed through Smart contract logic.
This is correct?
An alternative scenario (this is probably a bad example) could be that a game requires getting global state from the blockchain at start, for example, difficulty handicap to say something, or retrieve player past plays, recorded statistics, and so on.
This should be done from each client -e.g: retrieve state from the blockchain through deployed SC and pass it to the Smart-contract residing in the channel- or it-s possible for a Smart contract in a channel to get data from the blockchain while that channel is open ?
If I may add something: In more complex applications, it may be quite useful to employ both contract calls and generic messages. Apart from the differences in validation power, there is also a significant difference in cost.
While smart contract calls are very powerful (or rather, because they are), they are fairly costly to execute: Simple contract calls could be executed at a rate of roughly 20-30 calls/sec on one channel. Generic messages, OTOH, approach 1000 msgs/sec per channel.
So if one can combine the speed of generic messages with the safety of contract calls, it should be possible to achieve both great speed and robustness.
So in case of gomoku we could use generic messages to record a state of the game which consists of:
state of the board (for example a 225 (15*15) characters long string where "0" is empty, "x" is player a and "y" is player b)
signatures of two players
nonce (perhaps not necessary)
And use smart contract only to validate that the state is correct and distribute tokens to the winner of the game (probably it also needs force progress capability).
Assuming we need two messages to record one move we are looking at 16x speed improvement ((1000 [msgs per sec] / 2) / 30 [calls per sec] = 16.66).
Would that be a good use of combination of generic messages and contracts?
Yes, something like that (though I didn’t scrutinize the details).
Back when I was part of building telecoms systems at Ericsson, we used to try to separate data into different layers of persistence and redundancy semantics:
data that must survive a restart
data that must not survive a restart
data that must be available if we failed over to a standby (thus must be replicated)
data that could be reproduced from redundant info, and thus shouldn’t be replicated.
This was not just useful for speed; in some cases, e.g. persisting Event & Alarm data would cause confusion, as all events and alarms were supposed to be cleared and re-generated (if still valid) after a restart.
So in a game, the actual move could be validated in a contract, and messages to redraw the board or animating state transitions etc could use generic messages. Control questions to ask in order to guide the decision might be: “Does this message require a reply?”, “Is approval necessary?”, “Is there a dispute potential?”