2018年7月6日BCOM技术定期更新

We write the rules of the game into code on the blockchain, but we really don't want to trade on the chain at every step of the predictive quiz game. However, there is no reason not to let the blockchain itself manage the rules of the game - and more importantly, manage the code that executes the game rules. If we create a state machine function on the game and publish it on the chain, it can be pre-verified to be correct and can be referenced by anyone.

More importantly, however, the function can be executed under the chain, which is faster and cheaper than dozens of times on the chain. (Note: The form of the state machine itself does not introduce side effects, so it is actually a commonly used function.)

Therefore, if we replace the local client state machine execution in our example above with the chain code execution, both parties will have more confidence in the accuracy of the running code and the information they sign.

But the biggest advantage is that we now have a way to deal with cheating. If the signature message sent by the cheater contains an invalid state transition - just like not following the code rules on the chain - we can take arbitration! The receiver can call the chain dispute resolution function to pass the signed invalid state transition. This function can call the same chain state machine code and show that it is invalid, and the cheater dispute will be invalid.

Therefore, in this way, we can construct a variety of state machines for various purposes, and can insist on using chain logic to advance under the chain in a verifiable way, and can perform verification and arbitration on the chain in the event of a dispute.

This approach does not limit the complexity of the state machine, state, or transition state of the action, except for the portion that can be executed on the chain - so the state machine is as Turing-complete as the blockchain that executes the state machine.

In the second part, I intend to discuss:

· On the Gaming platform, how do we implement practical solutions based on this concept, and some of the challenges we face

· How do we inject randomness into this process?

· How to deal with some disputes about the results

· Discuss gambling games that set fixed odds for different rules for each participant, and the differences between states in a series of games played in the same state channel

· How to extend this method to hundreds of games that implement different rules

Carlos Callejo, CTO of BetComm –6July 2018

我们在区块链上将游戏的规则编写成代码，不过我们真的不想要在预测竞猜游戏的每一步骤都用链上交易。然而，没有理由不让区块链自身管理游戏规则——更重要的是，管理执行游戏规则的代码。如果我们在游戏上创建了状态机函数，并将它发布在链上，它可以预先自主验证为正确的，而且任何人都可以参照。

然而，更重要的是，该函数可以在链下执行，比在链上执行更快、也更便宜数十倍。（注：状态机这个形式本身不会带来副作用，因此它实际上是常用函数。）

因此，如果把我们上述例子中的本地客户端状态机执行替换为链上代码的链下执行，参赛双方都会对运行的代码和他们签署的信息的准确性更有信心。

不过最大的优点是，我们现在有方法应对作弊行为了。如果作弊方发送的签名信息中包含无效的状态转换——就如同不遵守链上代码规则——我们可以采取仲裁！接收方可以调用链上争端解决函数，将已签名的无效状态转换传递进去。该函数可以调用相同的链上状态机代码并显示它是无效的，作弊方争端将会无效。

因此，通过这种方法，我们可以出于各种目的构建各种各样的状态机，可以坚持使用链上逻辑通过可验证的方式在链下推进，出现争端时可以在链上进行验证仲裁。

这种方法没有限制状态机、状态或转换状态的行动的复杂性，除了能够在链上执行的部分——因此状态机和执行状态机的区块链一样图灵完备。

在第二部分，我打算讨论：

在博彩平台，我们是如何基于这个概念执行实际解决方案的，以及我们面对的一些挑战

我们是如何在这一过程中注入随机性的

如何处理一些对结果又争议的情况

讨论对每个参与者设定不同规则的固定赔率的赌博游戏，以及在相同的状态通道中进行的一系列游戏在状态之间的差异

如何将这种方法扩展应用至上百种实行不同规则的各类游戏中

Callejo，BetComm首席技术官- 2018年7月6日

---------------END--------------