Why State Channel won’t fit SlotNSlot
State Channel’s Fxxking Good
State channel have so much potentials for utility in real-time DApps with frequent micro transactions: such as Gambling services just like SlotNSlot! State channel is basically an off-chain p2p solution where only the initial and final states are processed on the blockchain, and the intermediate states are processed between participants of the channel, off-chain. This has much advantages for DApps in that it relieves from the blocktime dependency and huge gas costs for frequent transactions.
One frequently presented scenario of malicious action is where either participant tries to submit an intermediate state instead of the final state. This requires the constructor to wait for a specified time after it receives a final state, so that the other party can claim what is truly the final state. By a game theoretic way, both parties are forced to submit the actual final state, because since the smart contract would accept the submitted state with the greatest sequence number, either party would submit a state that maximizes its profit with a sequence number greater than the opponent’s.
An example of state channel
Alice submits the state with most benefits to her balance, which is sequence #3. Then Bob would submit the state most benefits him after #3, which is #6. Knowing this, Alice would choose another sub-optimal after #6, which is #8. So would Bob with #10. This iterates throughout the whole states, thus both choosing the true final state.
But State Channel is Doomed
NO. NOT for SlotNSlot. Yes, it’s an amazing scalability solution for so many DApps. But it’s not eligible considering our core value proposition: a Mobile compatible, fast and easy access to fun and cool experience on slot games. Due to limitations in exception handling, SlotNSlot considers implementing the state channel as putting a burden on users. Imagine a exceptional, but likely-to-occur scenario, on Alice and Bob.
Alice created a slot machine on SlotNSlot, which runs the games off-chain with state channel solution. Bob, on his way to work in the subway, puts out his smartphone and turns on SlotNSlot mobile application. He visits Alice's slot, and starts playing. After losing some bets, he wins a huge prize, Jackpot, of a x2000 multiplier. Feeling so lucky, he continues to play another tens of bets in Alice's slot. All of a sudden, his phone is disconnected from SlotNSlot contracts due to...1)battery discharge
2)wireless network disconnection, or
3)his phone broke as he dropped it on the ground.Bob rushes to reconnect to network. As state channel passes its expiry time, Alice is now able to submit her "final state" claim to the constructing smart contract. Since Bob's client stopped interacting with Alice's, she finds out Bob is disconnected, and submits the state before Bob won the Jackpot. To claim a later state, Bob struggles to deal with his problem,a)trying to find a power source in the subway
b)reaching his hands upright to reconnect to wireless network
c)praying to god that his phone revivesBob was so happy that he'd win 200000% profit from Alice's slot, but he was suddenly in despair. Very highly unlikely, but anyway he finally reconnected to the game, and claimed the final state to the constructor. Unfortunately and tragically, the constructor has already expired and finalized the channel with the state submitted by Alice. Instead of earning x2000 the bet, Bob rather lost some tens of bets to Alice.
This is really something we don’t want users on SlotNSlot experience. On SlotNSlot where games are played in atomic unit on-chain, Bob would have been cool with the disconnection and just forget about it. Then he would try reconnecting later to retrieve what he’d been playing before the disconnection(More likely, it would already have been transferred to his wallet because Alice have to trigger the cash-out to accept another player on her slot).
What’s done & What should be done
As mentioned, using an on-chain alternative to progress the game, exceptional disconnections are easier to deal with, and the blocktime dependency is bypassed as described in our prior post, with a proactive verification on pending transactions.
On top of that, games on SlotNSlot always ensure 100% transparency since all of them are processed in atomic unit on the blockchain, whereas off-chain solutions can’t assure what happened between participants.
We’re still left with reducing the gas cost. The development team is putting all the resources to optimize the codes, computations, algorithms, and data structures to save as much gas as possible. Furthermore, as the on-chain way strictly relates to the current state of Ethereum network, we will have to keep eyes on the modifications(i.e. EIPs) to Ethereum.
We’re keeping researches on creative solutions to overcome barriers on Ethereum, and are already prepared to implement state channel solution on our codes, which we will be using only if we ultimately find it useless to use alternatives. Don’t forget to try our beta release on this weekend.
Check out our
WebPage // Whitepaper // Github // Reddit // Youtube
Facebook // Twitter // Discord // Telegram
*Join our fresh new Telegram channel to discuss on the project
*we’ve moved from Hipchat to Discord
*SLOT Crowdsale starts on August 20th, 2017.
