Mixing
Ethereum Smart Contract execution principle
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
I have a question that might sound really dumb, but its understanding is crucial for me.
Say, I have a Smart Contract, which has a public variable, and a setter to change that variable. If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves? Will it execute the first contract for the first address, and then execute it for the second one, or will it make a "copy" of the contract, to execute it for the second address? Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
contract-invocation
asked 1 hour ago
Ruham
14112
add a comment |Â
up vote
1
down vote
favorite
I have a question that might sound really dumb, but its understanding is crucial for me.
Say, I have a Smart Contract, which has a public variable, and a setter to change that variable. If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves? Will it execute the first contract for the first address, and then execute it for the second one, or will it make a "copy" of the contract, to execute it for the second address? Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
contract-invocation
asked 1 hour ago
Ruham
14112
add a comment |Â
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I have a question that might sound really dumb, but its understanding is crucial for me.
Say, I have a Smart Contract, which has a public variable, and a setter to change that variable. If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves? Will it execute the first contract for the first address, and then execute it for the second one, or will it make a "copy" of the contract, to execute it for the second address? Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
contract-invocation
asked 1 hour ago
Ruham
14112
I have a question that might sound really dumb, but its understanding is crucial for me.
Say, I have a Smart Contract, which has a public variable, and a setter to change that variable. If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves? Will it execute the first contract for the first address, and then execute it for the second one, or will it make a "copy" of the contract, to execute it for the second address? Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
contract-invocation
contract-invocation
asked 1 hour ago
Ruham
14112
asked 1 hour ago
Ruham
14112
asked 1 hour ago
Ruham
14112
asked 1 hour ago
Ruham
14112
asked 1 hour ago
Ruham
14112
14112
add a comment |Â
add a comment |Â
2 Answers
2
active
oldest
votes
up vote
2
down vote
accepted
It's not a dumb question.
It will never make sense while thinking about the contracts as separate instances running on different nodes. The EVM is modeled as a distributed state machine. There is an EVM state that is logical, and separate and apart from the nodes. The protocol ensures (nearly) that the nodes will eventually agree on the canonical state at a given point.
A crucial concern to sort out is the order of transactions. All nodes must agree on this as a prerequisite for agreement about the effect of those transactions. There is ambiguity about transaction order due to network latency. This is resolved by the mining process. Mining produces blocks of transactions in a specific order. When nodes hear about a block, they process the contained transactions and then will reach agreement with other nodes at that block number, also known as block height.
If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves?
This is not possible. Everything is kicked off by an externally owned account (a wallet) signing a transaction and addressing it to a smart contract, normally to a specific function. The contract isn't "running", but the transaction is proposed.
The transaction will be mined. There is no assurance about the mined order of two transactions signed by two different accounts that are broadcast more or less simultaneously. What we can be sure of is the mining process will ensure that one or the other proceeds first. It will be evaluated entirely before work on the next transaction starts.
Will it execute the first contract for the first address, and then execute it for the second one
It will execute the one that got mined first, and then the one that got mined second.
or will it make a "copy" of the contract, to execute it for the second address
a "copy of the contract" exists on every full node. Contracts are part of the state and are used to process the transactions in the blocks (how can a node process the transaction against a contract if they don't have a copy of the contract?). Every full node runs every transaction. The "state" of the virtual machine is known to all full nodes. The state is the only logical conclusion given well-ordered transactions described in the blockchain about which they all agree.
Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
No. However, the state of the contract at the beginning of the second transaction will be the result of the first transaction. It will execute in the context the first transaction left behind when it was done.
Here's a simple example I cobbled together. Imagine a coordinated burst from multiple senders all trying to be first. It will only work for the first transaction mined, which is not the same as first sent. Indeed, the contestants can compete with each other by bidding for priority using the gasPrice.
pragma solidity 0.4.25;
contract WorksOnce
bool isUsed;
event LogLuckyWinner(address sender);
function pickMe() public
require(!isUsed);
isUsed = true;
emit LogLuckyWinner(msg.sender);
Hope it helps.
answered 30 mins ago
Rob Hitchens
22.8k43571
2
Just looking at the discussion. It may help to think of it as a strictly sequential single-threaded process with no parallelism. This process is reinforced by impressive redundancy so we can be confident that the process will continue in adversity up to known failure points.
– Rob Hitchens
26 mins ago
This is a great explanation, thank you!
– Ruham
21 mins ago
add a comment |Â
up vote
1
down vote
Logically, there is no parallel execution of transactions. All transactions are executed sequentially. However, to a large degree, it depends on the miner, which sequence is finally included in the block. There is only one exception: transaction from the same sender address have to strictly follow the nonce of that address.
answered 42 mins ago
ivicaa
3,652835
If in my case the sequence of transactions is not important, does that mean that Ethereum's architecture covers the point that I mentioned, that there will be no case when a variable will be "unavailable" to set, since it's already "busy" in another transaction?
– Ruham
31 mins ago
During the execution of a transaction, there is no concurrency at all. Rob just provided a more detailed answer.
– ivicaa
29 mins ago
add a comment |Â
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
2
down vote
accepted
It's not a dumb question.
It will never make sense while thinking about the contracts as separate instances running on different nodes. The EVM is modeled as a distributed state machine. There is an EVM state that is logical, and separate and apart from the nodes. The protocol ensures (nearly) that the nodes will eventually agree on the canonical state at a given point.
A crucial concern to sort out is the order of transactions. All nodes must agree on this as a prerequisite for agreement about the effect of those transactions. There is ambiguity about transaction order due to network latency. This is resolved by the mining process. Mining produces blocks of transactions in a specific order. When nodes hear about a block, they process the contained transactions and then will reach agreement with other nodes at that block number, also known as block height.
If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves?
This is not possible. Everything is kicked off by an externally owned account (a wallet) signing a transaction and addressing it to a smart contract, normally to a specific function. The contract isn't "running", but the transaction is proposed.
The transaction will be mined. There is no assurance about the mined order of two transactions signed by two different accounts that are broadcast more or less simultaneously. What we can be sure of is the mining process will ensure that one or the other proceeds first. It will be evaluated entirely before work on the next transaction starts.
Will it execute the first contract for the first address, and then execute it for the second one
It will execute the one that got mined first, and then the one that got mined second.
or will it make a "copy" of the contract, to execute it for the second address
a "copy of the contract" exists on every full node. Contracts are part of the state and are used to process the transactions in the blocks (how can a node process the transaction against a contract if they don't have a copy of the contract?). Every full node runs every transaction. The "state" of the virtual machine is known to all full nodes. The state is the only logical conclusion given well-ordered transactions described in the blockchain about which they all agree.
Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
No. However, the state of the contract at the beginning of the second transaction will be the result of the first transaction. It will execute in the context the first transaction left behind when it was done.
Here's a simple example I cobbled together. Imagine a coordinated burst from multiple senders all trying to be first. It will only work for the first transaction mined, which is not the same as first sent. Indeed, the contestants can compete with each other by bidding for priority using the gasPrice.
pragma solidity 0.4.25;
contract WorksOnce
bool isUsed;
event LogLuckyWinner(address sender);
function pickMe() public
require(!isUsed);
isUsed = true;
emit LogLuckyWinner(msg.sender);
Hope it helps.
answered 30 mins ago
Rob Hitchens
22.8k43571
2
Just looking at the discussion. It may help to think of it as a strictly sequential single-threaded process with no parallelism. This process is reinforced by impressive redundancy so we can be confident that the process will continue in adversity up to known failure points.
– Rob Hitchens
26 mins ago
This is a great explanation, thank you!
– Ruham
21 mins ago
add a comment |Â
up vote
2
down vote
accepted
It's not a dumb question.
It will never make sense while thinking about the contracts as separate instances running on different nodes. The EVM is modeled as a distributed state machine. There is an EVM state that is logical, and separate and apart from the nodes. The protocol ensures (nearly) that the nodes will eventually agree on the canonical state at a given point.
A crucial concern to sort out is the order of transactions. All nodes must agree on this as a prerequisite for agreement about the effect of those transactions. There is ambiguity about transaction order due to network latency. This is resolved by the mining process. Mining produces blocks of transactions in a specific order. When nodes hear about a block, they process the contained transactions and then will reach agreement with other nodes at that block number, also known as block height.
If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves?
This is not possible. Everything is kicked off by an externally owned account (a wallet) signing a transaction and addressing it to a smart contract, normally to a specific function. The contract isn't "running", but the transaction is proposed.
The transaction will be mined. There is no assurance about the mined order of two transactions signed by two different accounts that are broadcast more or less simultaneously. What we can be sure of is the mining process will ensure that one or the other proceeds first. It will be evaluated entirely before work on the next transaction starts.
Will it execute the first contract for the first address, and then execute it for the second one
It will execute the one that got mined first, and then the one that got mined second.
or will it make a "copy" of the contract, to execute it for the second address
a "copy of the contract" exists on every full node. Contracts are part of the state and are used to process the transactions in the blocks (how can a node process the transaction against a contract if they don't have a copy of the contract?). Every full node runs every transaction. The "state" of the virtual machine is known to all full nodes. The state is the only logical conclusion given well-ordered transactions described in the blockchain about which they all agree.
Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
No. However, the state of the contract at the beginning of the second transaction will be the result of the first transaction. It will execute in the context the first transaction left behind when it was done.
Here's a simple example I cobbled together. Imagine a coordinated burst from multiple senders all trying to be first. It will only work for the first transaction mined, which is not the same as first sent. Indeed, the contestants can compete with each other by bidding for priority using the gasPrice.
pragma solidity 0.4.25;
contract WorksOnce
bool isUsed;
event LogLuckyWinner(address sender);
function pickMe() public
require(!isUsed);
isUsed = true;
emit LogLuckyWinner(msg.sender);
Hope it helps.
answered 30 mins ago
Rob Hitchens
22.8k43571
2
Just looking at the discussion. It may help to think of it as a strictly sequential single-threaded process with no parallelism. This process is reinforced by impressive redundancy so we can be confident that the process will continue in adversity up to known failure points.
– Rob Hitchens
26 mins ago
This is a great explanation, thank you!
– Ruham
21 mins ago
add a comment |Â
up vote
2
down vote
accepted
up vote
2
down vote
accepted
It's not a dumb question.
It will never make sense while thinking about the contracts as separate instances running on different nodes. The EVM is modeled as a distributed state machine. There is an EVM state that is logical, and separate and apart from the nodes. The protocol ensures (nearly) that the nodes will eventually agree on the canonical state at a given point.
A crucial concern to sort out is the order of transactions. All nodes must agree on this as a prerequisite for agreement about the effect of those transactions. There is ambiguity about transaction order due to network latency. This is resolved by the mining process. Mining produces blocks of transactions in a specific order. When nodes hear about a block, they process the contained transactions and then will reach agreement with other nodes at that block number, also known as block height.
If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves?
This is not possible. Everything is kicked off by an externally owned account (a wallet) signing a transaction and addressing it to a smart contract, normally to a specific function. The contract isn't "running", but the transaction is proposed.
The transaction will be mined. There is no assurance about the mined order of two transactions signed by two different accounts that are broadcast more or less simultaneously. What we can be sure of is the mining process will ensure that one or the other proceeds first. It will be evaluated entirely before work on the next transaction starts.
Will it execute the first contract for the first address, and then execute it for the second one
It will execute the one that got mined first, and then the one that got mined second.
or will it make a "copy" of the contract, to execute it for the second address
a "copy of the contract" exists on every full node. Contracts are part of the state and are used to process the transactions in the blocks (how can a node process the transaction against a contract if they don't have a copy of the contract?). Every full node runs every transaction. The "state" of the virtual machine is known to all full nodes. The state is the only logical conclusion given well-ordered transactions described in the blockchain about which they all agree.
Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
No. However, the state of the contract at the beginning of the second transaction will be the result of the first transaction. It will execute in the context the first transaction left behind when it was done.
Here's a simple example I cobbled together. Imagine a coordinated burst from multiple senders all trying to be first. It will only work for the first transaction mined, which is not the same as first sent. Indeed, the contestants can compete with each other by bidding for priority using the gasPrice.
pragma solidity 0.4.25;
contract WorksOnce
bool isUsed;
event LogLuckyWinner(address sender);
function pickMe() public
require(!isUsed);
isUsed = true;
emit LogLuckyWinner(msg.sender);
Hope it helps.
answered 30 mins ago
Rob Hitchens
22.8k43571
It's not a dumb question.
It will never make sense while thinking about the contracts as separate instances running on different nodes. The EVM is modeled as a distributed state machine. There is an EVM state that is logical, and separate and apart from the nodes. The protocol ensures (nearly) that the nodes will eventually agree on the canonical state at a given point.
A crucial concern to sort out is the order of transactions. All nodes must agree on this as a prerequisite for agreement about the effect of those transactions. There is ambiguity about transaction order due to network latency. This is resolved by the mining process. Mining produces blocks of transactions in a specific order. When nodes hear about a block, they process the contained transactions and then will reach agreement with other nodes at that block number, also known as block height.
If a Smart Contract is executed by 2 addresses simultaneously, how the Ethereum Blockchain behaves?
This is not possible. Everything is kicked off by an externally owned account (a wallet) signing a transaction and addressing it to a smart contract, normally to a specific function. The contract isn't "running", but the transaction is proposed.
The transaction will be mined. There is no assurance about the mined order of two transactions signed by two different accounts that are broadcast more or less simultaneously. What we can be sure of is the mining process will ensure that one or the other proceeds first. It will be evaluated entirely before work on the next transaction starts.
Will it execute the first contract for the first address, and then execute it for the second one
It will execute the one that got mined first, and then the one that got mined second.
or will it make a "copy" of the contract, to execute it for the second address
a "copy of the contract" exists on every full node. Contracts are part of the state and are used to process the transactions in the blocks (how can a node process the transaction against a contract if they don't have a copy of the contract?). Every full node runs every transaction. The "state" of the virtual machine is known to all full nodes. The state is the only logical conclusion given well-ordered transactions described in the blockchain about which they all agree.
Can there be a case, when the setter function for the second address will fail to change the variable, since the variable will be already "in use" by the first address?
No. However, the state of the contract at the beginning of the second transaction will be the result of the first transaction. It will execute in the context the first transaction left behind when it was done.
Here's a simple example I cobbled together. Imagine a coordinated burst from multiple senders all trying to be first. It will only work for the first transaction mined, which is not the same as first sent. Indeed, the contestants can compete with each other by bidding for priority using the gasPrice.
pragma solidity 0.4.25;
contract WorksOnce
bool isUsed;
event LogLuckyWinner(address sender);
function pickMe() public
require(!isUsed);
isUsed = true;
emit LogLuckyWinner(msg.sender);
Hope it helps.
answered 30 mins ago
Rob Hitchens
22.8k43571
answered 30 mins ago
Rob Hitchens
22.8k43571
answered 30 mins ago
Rob Hitchens
22.8k43571
answered 30 mins ago
Rob Hitchens
22.8k43571
22.8k43571
2
Just looking at the discussion. It may help to think of it as a strictly sequential single-threaded process with no parallelism. This process is reinforced by impressive redundancy so we can be confident that the process will continue in adversity up to known failure points.
– Rob Hitchens
26 mins ago
This is a great explanation, thank you!
– Ruham
21 mins ago
add a comment |Â
2
Just looking at the discussion. It may help to think of it as a strictly sequential single-threaded process with no parallelism. This process is reinforced by impressive redundancy so we can be confident that the process will continue in adversity up to known failure points.
– Rob Hitchens
26 mins ago
This is a great explanation, thank you!
– Ruham
21 mins ago
2
2
Just looking at the discussion. It may help to think of it as a strictly sequential single-threaded process with no parallelism. This process is reinforced by impressive redundancy so we can be confident that the process will continue in adversity up to known failure points.
– Rob Hitchens
26 mins ago
Just looking at the discussion. It may help to think of it as a strictly sequential single-threaded process with no parallelism. This process is reinforced by impressive redundancy so we can be confident that the process will continue in adversity up to known failure points.
– Rob Hitchens
26 mins ago
This is a great explanation, thank you!
– Ruham
21 mins ago
This is a great explanation, thank you!
– Ruham
21 mins ago
add a comment |Â
up vote
1
down vote
Logically, there is no parallel execution of transactions. All transactions are executed sequentially. However, to a large degree, it depends on the miner, which sequence is finally included in the block. There is only one exception: transaction from the same sender address have to strictly follow the nonce of that address.
answered 42 mins ago
ivicaa
3,652835
If in my case the sequence of transactions is not important, does that mean that Ethereum's architecture covers the point that I mentioned, that there will be no case when a variable will be "unavailable" to set, since it's already "busy" in another transaction?
– Ruham
31 mins ago
During the execution of a transaction, there is no concurrency at all. Rob just provided a more detailed answer.
– ivicaa
29 mins ago
add a comment |Â
up vote
1
down vote
Logically, there is no parallel execution of transactions. All transactions are executed sequentially. However, to a large degree, it depends on the miner, which sequence is finally included in the block. There is only one exception: transaction from the same sender address have to strictly follow the nonce of that address.
answered 42 mins ago
ivicaa
3,652835
If in my case the sequence of transactions is not important, does that mean that Ethereum's architecture covers the point that I mentioned, that there will be no case when a variable will be "unavailable" to set, since it's already "busy" in another transaction?
– Ruham
31 mins ago
During the execution of a transaction, there is no concurrency at all. Rob just provided a more detailed answer.
– ivicaa
29 mins ago
add a comment |Â
up vote
1
down vote
up vote
1
down vote
Logically, there is no parallel execution of transactions. All transactions are executed sequentially. However, to a large degree, it depends on the miner, which sequence is finally included in the block. There is only one exception: transaction from the same sender address have to strictly follow the nonce of that address.
answered 42 mins ago
ivicaa
3,652835
Logically, there is no parallel execution of transactions. All transactions are executed sequentially. However, to a large degree, it depends on the miner, which sequence is finally included in the block. There is only one exception: transaction from the same sender address have to strictly follow the nonce of that address.
answered 42 mins ago
ivicaa
3,652835
edited 28 mins ago
answered 42 mins ago
ivicaa
3,652835
answered 42 mins ago
ivicaa
3,652835
answered 42 mins ago
ivicaa
3,652835
3,652835
If in my case the sequence of transactions is not important, does that mean that Ethereum's architecture covers the point that I mentioned, that there will be no case when a variable will be "unavailable" to set, since it's already "busy" in another transaction?
– Ruham
31 mins ago
During the execution of a transaction, there is no concurrency at all. Rob just provided a more detailed answer.
– ivicaa
29 mins ago
add a comment |Â
If in my case the sequence of transactions is not important, does that mean that Ethereum's architecture covers the point that I mentioned, that there will be no case when a variable will be "unavailable" to set, since it's already "busy" in another transaction?
– Ruham
31 mins ago
During the execution of a transaction, there is no concurrency at all. Rob just provided a more detailed answer.
– ivicaa
29 mins ago
If in my case the sequence of transactions is not important, does that mean that Ethereum's architecture covers the point that I mentioned, that there will be no case when a variable will be "unavailable" to set, since it's already "busy" in another transaction?
– Ruham
31 mins ago
If in my case the sequence of transactions is not important, does that mean that Ethereum's architecture covers the point that I mentioned, that there will be no case when a variable will be "unavailable" to set, since it's already "busy" in another transaction?
– Ruham
31 mins ago
During the execution of a transaction, there is no concurrency at all. Rob just provided a more detailed answer.
– ivicaa
29 mins ago
During the execution of a transaction, there is no concurrency at all. Rob just provided a more detailed answer.
– ivicaa
29 mins ago
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fethereum.stackexchange.com%2fquestions%2f60130%2fethereum-smart-contract-execution-principle%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password