DApps Not Need to Wait for Blocktime

Blockchains are slow. So slow that almost any application that requires real time response merely cannot be implemented on-chain. Ethereum Foundation has estimated the blocktime to consistently increase throughout the rest of the year, from 20 seconds at the time of writing to 45 seconds on November. This surely will lay serious difficulties on real time DApps.

There comes the question, do we really need to wait for the whole blocktime for every transactions in DApps? As Betteridge’s law says, we DON’T. Though the actual modification of status on the smart contracts surely needs block confirmations including ETH balances, the results of the transactions and the modified status can be computed in advance to block confirmation if given the original source codes of the contract and the legitimate inputs to it. Any application which doesn’t hesitate to reveal the non-compiled solidity codes of the contracts open in the public, enables its terminal clients to infer the results of the on-chain interactions, thus NOT having to wait for the on-chain confirmation.

SlotNSlot project very well fits the condition. The smart contract codes will all be open public in Github repositories, and the same logics will be implemented in the client sides. Players on slot machines, or the bankers watching them play, need not to wait for the blockchain to give back the result of every round to proceed the games, as long as they’re confident that the transactions they see in the pending list will definitely be mined into the chain.

Prior Designs

In designing a two-party commit&reveal random number generation(RNG) for our service, our initial idea was to utilize Whisper, the p2p messaging protocol on Ethereum, to reduce the number of transactions required for every round of the slot games, thus save the cost and time. Just right after posting the idea we found that there were serious fallacies in the model that could suffer modifications and/or discarding of the RNG seeds on each round.

Using a serial hash chain, i.e. consecutive hashed values of a seed, solved the possibility of modification of the result since a specific original seed makes all the hashes of the chain deterministic(i.e. attempt to change the hashed seed in any point of the chain fails the hash verification), while reducing the required number of transactions to half because every reveal of a round is commit for next round at the same time. We still believed using the whisper between clients would make it faster to proceed the game by giving what the seed is for this round, before it is known by the mined block. But this still had a vulnerable point: they can still send a different information in the whisper message.

Proactive TX Verification

As described above, games could be proceeded by computing the results from the pending transactions. It was confirmed that waiting for a whisper message isn’t much faster than waiting for pending transactions. Unlike whisper message where clients can “lie” about how they broadcasted their transactions, watching the pending transactions ensures having the “actual” transaction broadcasted.

Running a geth client with fast node sync enables a terminal to receive propagated transactions from peers of the network. Among those transactions received, the client will filter them with the recipient of the transaction so that they’re only watching those sent to the game contract of interest. In this way, the client can find out the transactions which are sent from the opponent to the game contract. These transactions of the opponent user will then be verified on the txData with predetermined logics. A successful verification on a transaction would “proactively” predict the result and/or the event after the transaction is mined on-chain, thus proceeding the regular process of the game apart from the blockchain interactions.

Clients can store the most recent histories of both their and their opponent’s transactions in the local storage, to cope with fallback management in case of failure. (exceptional disconnections, page refreshing on Web, application killed in Mobile, etc.)

Further Considerations

The logic to verify the transactions must be structured such that a successfully verified transaction is guaranteed to be mined in the blockchain to modify the status on the game contract, and the predicted result/event is exactly what the on-chain confirmation would give out.

There’s an alternative way to get the result and event of the pending transactions by asking the mining nodes in the peer. In this way, the peers wouldn’t give a valid result/event if the transaction isn’t guaranteed to be mined successfully. Then there’s no need to have a verifying logic. The choice between verifying with preset logic and asking to peer full nodes would depend on the status of the network. But in general it’d be better to have the logic for unexpected situations.

There’s a chance of Finney attacks, overriding of already broadcasted transactions by another transaction with a same nonce. This is especially available when the network is at abnormal state, like the Status ICO event. Another possible scenario of Finney attack is to give different gasPrices on two transactions so that miners including transactions over certain gasPrice would only include the one with higher gasPrice.

Utilizing the proactive tx verification scheme would proceed the game much faster than it is actually processed on-chain. This might lead to occasions where transactions in later rounds are mined earlier. This would fail the hash chain verification because the prior hash values are absent on the contract. To avoid this, we’ve implemented a multiple hash chain scheme. A detailed explanation of this multiple hash chain scheme will be posted.

Actual time spent to play slot games from our initial design was around 90 seconds on Rinkeby, whereas the proactive method reduced it to roughly 5 seconds.

We hope this proactive mechanism would provide breakthroughs to many DApps with real time interactions. Any suggestions, feedbacks, references of relevant information, and discussions on fallacies of the idea would be greatly appreciated.

Check out our
WebPage // Whitepaper // Github // Reddit
Facebook // Twitter // HipChat
*you can join our hipchat without sign up