Yes you can automate this. There are many different approaches. I'm going to assume you need to issue transactions that interact with your contract for the purposes of the example.
There are several key parts to the system you're trying to build. Each part has plenty of choices, which means a combinatorial explosion of build options. It would help if you specified a bit more about the:
- Node: are you running an Ethereum node already, like geth or parity?
- Web3 Connector: choose from javascript, java, C#, ruby, python, etc...
- Core Logic: which connector language do you prefer?
- Scheduler: you already chose cron, great
Until we get those answers, I'll give an example with my preferred options:
- Node:
geth
with a funded, unlocked account.*
- Web3 Connector: web3.py, over an IPC connection (the default).
- Core Logic: a python script that loads the data and issues a transaction
- Scheduler: cron
*A funded, unlocked account means that any process running on your computer has the ability to drain your account. You can minimize risk by keeping the balance low enough that you wouldn't miss it if it were stolen. You only need enough to pay for gas.
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.
Best Answer
One transaction is always one call from an EOA (Externally Owned Account) to either another EOA (Ether transfer) or to one single smart contract.
So what you can do is create your own contract which does what you need. So your contract creates a reference to other contracts and calls them in specific order. Here are some references on how to do that: https://medium.com/@blockchain101/calling-the-function-of-another-contract-in-solidity-f9edfa921f4c and https://www.reddit.com/r/ethereum/comments/58x16k/how_do_i_call_a_deployed_contracts_method_in/ (note that the syntax of the code changes quite fast so the syntax is the examples might not be fully correct anymore)
The order of execution is strictly defined in a single transaction - there is no parallelism. So first the first line of code is executed, then the second and so on. If the first line fails the second line (mostly) doesn't even get executed.