0

I read some pages here about concurrency but I didn't give my answer, actually I am new to Bchain, consider this scenario:

There is a game contract on the blockchain for 4 Players, so far three players are registered to the game and there is only one remaining! for example two different people from two different regions want to Enter to the game. And both of them connect to two different nodes(miner). So in every single node the contract can compare the remaining players and let the guy be in. But at the end there are two players are registered while there were only one position remained.

1- are these type of scenarios possible in blockchain??

2- what is the solution?

if it was a centralized system I could block the code by lock, semaphore, etc but here the code are distributed on every single miner, I mean each request for transaction is sent to different miner. Thanks

EDITED if both of them enter to this code in two different miners and both miner just see that the count is less than 4 so they add the sender to the list and return "ok"..!!!!

function AddPlayer(string name) public returns(string)
{
if (PlayersCount < 4)
{
PlayersCount ++;
// add he address of player to a list and …..  
return "ok";
}

EDITED 2

1- On how many nodes should this code be runned? I mean after sending the request from frontend application to this function it just return to me a true or false, right or wrong? So if it returns a true/false What is the broadcating? it is something like simple RPC. a function is called and the result is returned!!

2- what do you mean exactly by broadcasting transaction, does this "addPlayer" function call another "addPlayer" on the other node?? there isnt anything like this in the code,

3- I read something about validate the transaction, can you tell me how this function be validated after execution? does it need another function to validate it

Sorry for long questions , I really need the answers.

marked as duplicate by Ismael, shane, Richard Horrocks, Achala Dissanayake, eth Apr 12 at 0:45

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • Eventually, one of two remaining transactions will pass, and the other will fail. No need to use synchronization objects here. – goodvibration Nov 12 '18 at 6:07
  • Thanks, I want to know how?? how one of them will be passed and the other not! See my EDITED please. is it a good approach to send back something by a transaction,? – user9197034 Nov 12 '18 at 6:15
2

Your conception of what is happening isn't quite right.

None of the players are in the game until the transactions are mined. Mining creates an unambiguous order of the transactions. This unambiguous transaction order is indifferent to the nodes used to broadcast the transactions. Usually, transactions will be mined by a node somewhere and included in a block. It would usually the transactions with the highest gasPrice bid, so it's not FIFO.

Concurrent execution is not possible. Each mined transaction runs in the context of states created by mined transactions that came earlier. You write the contract to accept 4 and reject any others that follow.

For example,

pragma solidity 0.4.25;

contract FourPlayers {

    uint public maxPlayers = 4;  
    address[] public players;
    mapping(address => bool) public isPlayer;

    event LogPlayerAdded(address player);

    function addMe() public returns(bool success) {
        require(!isPlayer[msg.sender]);
        require(players.length < maxPlayers);
        emit LogPlayerAdded(msg.sender);
        players.push(msg.sender);
        isPlayer[msg.sender] = true;
        return true;
    }
}

You should be able to bang on that with simultaneous signed transactions in large numbers. It's basically a race. Enrollments won't arrive in the order sent, but rather in the order mined. This creates a financial incentive to bid for priority with a high gasPrice, perchance to be one of the lucky 4.

Hope it helps.

  • 1
    You might want to change Current execution to Concurrent execution. – goodvibration Nov 12 '18 at 6:41
  • Thank you very much, I got something about NOT being saved by FIFO. but Would you clear it more: See the Edited 2 please – user9197034 Nov 13 '18 at 5:07
  • 1
    There IS a precise order, but it's not first sent or first heard => first out. It's first mined, first out. Mining resolves uncertainty about nearly simultaneous inputs. – Rob Hitchens - B9lab Nov 13 '18 at 5:10
  • yes as I said I understood that it is not FIFO, but please look at edited 2 thanks – user9197034 Nov 13 '18 at 5:20

Not the answer you're looking for? Browse other questions tagged or ask your own question.