Why not let the blockchain engage in a game of rock-paper-scissors? The rules are simple: deploy rock-paper-scissors contracts on N chains, have them interact with each other, and determine the winner at the end. Sounds easy, doesn't it?

Let's give it a shot!

The aim of this article is to offer you a glimpse into the experience of developing applications with crosschain messages, specifically through playing rock-paper-scissors between blockchains. But don't worry, we won't delve deep into programming and development as they're not the main focus of this tale!

The scenario is set as follows:

• The developer deploys the contract on N chains and specifies that the rock-paper-scissors game will start "at a certain time". Picture this peculiar scene where a developer maintains the contract solo, and then engages in a game of rock-paper-scissors with their own contract.

• For simplicity, we will not consider session IDs. Simply put, a single round of rock-paper-scissors is played, and even if players tie, there's no rematch. Once you've played rock-paper-scissors, you won't play again.

• A generic crosschain messaging protocol (CCMP) is used for communication between blockchains. LayerZero is a well-known example.

Then, the contracts operate as follows:

• When the time comes, the first step is to decide on a move. For simplicity, the contract generates a random value (note) to determine the move, and the remainder divided by 3 is used to discern the move. For instance, if the remainder is 1, it's rock; if it's 2, it's scissors; if it's divisible by 3, it's paper.

• The contract then utilizes CCMP to inform the opponent's chain of its move.

• Simultaneously, the contract receives information about the opponent's move from their chain. Given the rules of rock-paper-scissors, it's evident that the outcome is dependent on the combination of moves played. Therefore, once everyone's moves are known, the winner can be determined. Importantly, in the event of a tie, there's no rematch.

• Since a single developer deploys the contract, there's no need for secrecy about their move. In other words, we don't account for the possibility of being caught off guard.

With these conditions set, let's delve deeper into the message exchange.

Note: The blockchain fundamentally does not support random value generation. However, for the sake of simplicity, we'll assume it here…

The CCMP utilized here is presumed to possess the following features:

• It's compatible with all chain types.

• Messaging occurs between two chains. It's a one-way exchange, analogous to letter communication, not a two-way dialogue.

• If the message doesn't reach the recipient, it has the ability to notify the sender of an unreachable error.

• Each message sent incurs a gas cost.

Assume that all chains are on par with each other. We aren't considering the presence of a game master who oversees the game. Focusing on a specific chain, how often will that chain send a message?

Given that it sends a message to every chain except its own, each chain sends a message N-1 times. With a total of N such chains, the number of message transmissions in this game is N(N-1) times. With the N squared term, we can expect the gas price to surge as the number of chains increases.

The solution is to establish a game master. In other words, participants submit their moves to the game master's chain and receive the computed results from them. This reduces the number of message transmissions from N squared to a linear number.

Let's consider a scenario where a problematic chain exits mid-game during rock-paper-scissors. Specifically, the network goes down while the game is ongoing. In such a case, can rock-paper-scissors still operate?

Assume all chains are on an equal footing (Let's disregard the game master for now!).

We aim to consider the potential situation, but before we do, let's recall this statement:

• If the message doesn't reach the recipient, it has the ability to notify the sender of an unreachable error. (From the CCMP Functions section)

Therefore, if a message fails to reach the destination chain, it can be inferred that the destination chain has exited the game, and the source chain can continue without the departed chain. It would be ideal if everyone could be informed when the absence of the exited chain is recognized. (This, however, would incur additional gas costs).

But how can other chains ascertain that a chain that didn't send a message initially is in an "absent" state? To determine this, a process stating, "If a chain doesn't send a message after a certain time frame, it's considered absent," needs to be implemented. Otherwise, no decision on "absence" can be made.

At this point, some may have specific concerns, such as what happens if a player exits (fails) while transmitting their move continuously to the opponent. Let's consider the situation where Player A exits while players A to E are engaged in rock-paper-scissors. Here, the following issues may arise:

In this scenario, we're considering the case where "Chain A begins transmitting its move information after acknowledging its opponent's move." In this situation, the derived game result differs from chain to chain. It's challenging to assert that a rock-paper-scissors game has been successfully played in such a case. To avoid this, making all chains agree on the game results' consistency could be an option, but this would entail additional gas costs. If the results aren't consistent, the developer would need to decide in advance whether to invalidate the game and revert it or force a majority vote to establish the outcome.

As discussed, considering irregular conditions like failures makes it hard to encapsulate crosschain exchanges within an application with atomicity (i.e., the only two options are to complete the exchange or revert to the original state in case of a problem).

Further development could include the introduction of session IDs and a rematch feature for rock-paper-scissors. If an appealing chain emerges in the future, and you wish to include that chain in the rock-paper-scissors game, what steps would you need to undertake?

The answer is, "You'll need to modify the contracts of all pre-existing chains.” The existing contracts must incorporate the ability to interact with the newly added chains. That's substantial work.

As discussed, applications employing crosschain messaging face the drawback that the more sophisticated the functionality and the more chains supported, the more messages required exponentially. This is because the state must be synchronized across chains, and man-hours tend to balloon when considering future scalability.

For instance, how could one borrow money on chain D using tokens from chains A, B, and C as collateral? It is anticipated that creating a function that allows borrowing money, which checks the value of assets deposited as collateral on each chain based on the oracle, would be challenging. (And there are plenty of other features in a lending protocol, right?)

Therefore, current applications using crosschain messaging are limited to:

• Applications where two (or a few) chains interact (like bridges).

• Applications where one chain manages almost all states (as in a rock-paper-scissors game with a game master in this article).

Crosschain messaging is an attractive feature, but it is basically a heavy burden on the developer.

Why not let the blockchain engage in a game of rock-paper-scissors? The rules are simple: deploy rock-paper-scissors contracts on N chains, have them interact with each other, and determine the winner at the end. Sounds easy, doesn't it?

Let's give it a shot!

The aim of this article is to offer you a glimpse into the experience of developing applications with crosschain messages, specifically through playing rock-paper-scissors between blockchains. But don't worry, we won't delve deep into programming and development as they're not the main focus of this tale!

The scenario is set as follows:

• The developer deploys the contract on N chains and specifies that the rock-paper-scissors game will start "at a certain time". Picture this peculiar scene where a developer maintains the contract solo, and then engages in a game of rock-paper-scissors with their own contract.

• For simplicity, we will not consider session IDs. Simply put, a single round of rock-paper-scissors is played, and even if players tie, there's no rematch. Once you've played rock-paper-scissors, you won't play again.

• A generic crosschain messaging protocol (CCMP) is used for communication between blockchains. LayerZero is a well-known example.

Then, the contracts operate as follows:

• When the time comes, the first step is to decide on a move. For simplicity, the contract generates a random value (note) to determine the move, and the remainder divided by 3 is used to discern the move. For instance, if the remainder is 1, it's rock; if it's 2, it's scissors; if it's divisible by 3, it's paper.

• The contract then utilizes CCMP to inform the opponent's chain of its move.

• Simultaneously, the contract receives information about the opponent's move from their chain. Given the rules of rock-paper-scissors, it's evident that the outcome is dependent on the combination of moves played. Therefore, once everyone's moves are known, the winner can be determined. Importantly, in the event of a tie, there's no rematch.

• Since a single developer deploys the contract, there's no need for secrecy about their move. In other words, we don't account for the possibility of being caught off guard.

With these conditions set, let's delve deeper into the message exchange.

Note: The blockchain fundamentally does not support random value generation. However, for the sake of simplicity, we'll assume it here…

The CCMP utilized here is presumed to possess the following features:

• It's compatible with all chain types.

• Messaging occurs between two chains. It's a one-way exchange, analogous to letter communication, not a two-way dialogue.

• If the message doesn't reach the recipient, it has the ability to notify the sender of an unreachable error.

• Each message sent incurs a gas cost.

Assume that all chains are on par with each other. We aren't considering the presence of a game master who oversees the game. Focusing on a specific chain, how often will that chain send a message?

Given that it sends a message to every chain except its own, each chain sends a message N-1 times. With a total of N such chains, the number of message transmissions in this game is N(N-1) times. With the N squared term, we can expect the gas price to surge as the number of chains increases.

The solution is to establish a game master. In other words, participants submit their moves to the game master's chain and receive the computed results from them. This reduces the number of message transmissions from N squared to a linear number.

Let's consider a scenario where a problematic chain exits mid-game during rock-paper-scissors. Specifically, the network goes down while the game is ongoing. In such a case, can rock-paper-scissors still operate?

Assume all chains are on an equal footing (Let's disregard the game master for now!).

We aim to consider the potential situation, but before we do, let's recall this statement:

• If the message doesn't reach the recipient, it has the ability to notify the sender of an unreachable error. (From the CCMP Functions section)

Therefore, if a message fails to reach the destination chain, it can be inferred that the destination chain has exited the game, and the source chain can continue without the departed chain. It would be ideal if everyone could be informed when the absence of the exited chain is recognized. (This, however, would incur additional gas costs).

But how can other chains ascertain that a chain that didn't send a message initially is in an "absent" state? To determine this, a process stating, "If a chain doesn't send a message after a certain time frame, it's considered absent," needs to be implemented. Otherwise, no decision on "absence" can be made.

At this point, some may have specific concerns, such as what happens if a player exits (fails) while transmitting their move continuously to the opponent. Let's consider the situation where Player A exits while players A to E are engaged in rock-paper-scissors. Here, the following issues may arise:

In this scenario, we're considering the case where "Chain A begins transmitting its move information after acknowledging its opponent's move." In this situation, the derived game result differs from chain to chain. It's challenging to assert that a rock-paper-scissors game has been successfully played in such a case. To avoid this, making all chains agree on the game results' consistency could be an option, but this would entail additional gas costs. If the results aren't consistent, the developer would need to decide in advance whether to invalidate the game and revert it or force a majority vote to establish the outcome.

As discussed, considering irregular conditions like failures makes it hard to encapsulate crosschain exchanges within an application with atomicity (i.e., the only two options are to complete the exchange or revert to the original state in case of a problem).

Further development could include the introduction of session IDs and a rematch feature for rock-paper-scissors. If an appealing chain emerges in the future, and you wish to include that chain in the rock-paper-scissors game, what steps would you need to undertake?

The answer is, "You'll need to modify the contracts of all pre-existing chains.” The existing contracts must incorporate the ability to interact with the newly added chains. That's substantial work.

As discussed, applications employing crosschain messaging face the drawback that the more sophisticated the functionality and the more chains supported, the more messages required exponentially. This is because the state must be synchronized across chains, and man-hours tend to balloon when considering future scalability.

For instance, how could one borrow money on chain D using tokens from chains A, B, and C as collateral? It is anticipated that creating a function that allows borrowing money, which checks the value of assets deposited as collateral on each chain based on the oracle, would be challenging. (And there are plenty of other features in a lending protocol, right?)

Therefore, current applications using crosschain messaging are limited to:

• Applications where two (or a few) chains interact (like bridges).

• Applications where one chain manages almost all states (as in a rock-paper-scissors game with a game master in this article).

Crosschain messaging is an attractive feature, but it is basically a heavy burden on the developer.