I plan to run multiple Contract Nodes with the same Lightweight Contracts and the same config.json for Contract Backup reasons. That is working fine.
But what if:
One Node is running an older Lightweigt Contract Version (same name)? Is this even possible since the Contract is uploaded to the Blockchain, it should always use the newest version right?
But what happens, if this node also runs an older config.json that references to the older Contract? (which is technically not possible because the names are the same right?)
But which contract is going to be triggered?
And may this also be exploited somehow by "third parties"?
Your instinct is correct. The actual code for the contract is stored on the blockchain. Uploading a new version means to upload the new code and send a contract reference transaction linking that code with the same name.
All nodes running the contract runner for that account will switch to the new version at the same time: the block at which the contract reference transaction is included.
Of course that doesn't include specific configuration that you might have on each contract runner (the contract runner parameters). You should try to use contract setup parameters as much as possible, only reverting to contract runner parameters for secrets or for big parameters.
Thanks for answering. I guess I can manage to prevent different contract runner parameters.
But lets think one step further. Just purely hypothetical: my contract code would be on Github, public. Also the config.json (but without sensitive data like passphrases etc.). So anyone has access to it and could heavily modify it and upload it to the blockchain with the same reference name.
I would not even be aware of that but suddenly my Lightweight Contracts are behaving differently and even my node is executing the new version but has different parameters loaded.
For my understanding, is that not a security issue? Or am I missing something here? Anyone could break my contracts without me knowing?
The contract reference is the link between the contract runner account and the specific contract version. Multiple versions of the same contract can co-exist on the blockchain. For example contract runner account A using contract reference R1 can point to trading bot contract v4, while contract runner account B using contract reference R2 can point to the same contract v5.
There are two transactions involved on the deployment of a contract into the blockchain.
The code itself, the class or jar file, is a data cloud transaction. Nothing special about it.
The second one is a "contract reference" transaction. This links the account, the name and the setup parameters for the contract to the contract code itself. The account is just the sender of the transaction. The "contract reference" transaction includes the name given to the contract (note that this is independent from the code itself), where to find the code (the full hash of the data cloud transaction) and the setup parameters if any.
Back to your example:
R1 was upload by some account (let's say A), so it cannot be used by any other account. v4 and v5 of the contract would be different data cloud transactions. They could be from any account.
Then account A can set a contract reference pointing to v4 code. And account B can set one pointing to v5 code. They can use any name they want, that's inside the contract reference transaction. Note that names only matter for contract references in the same account.
When there are multiple contract reference on the same account with the same contract name the most recent is used. That's how you deploy a new contract version on the same account.
To wrap up, this is what a contract reference transaction contains:
Here you can see the name, the parameters and the full hash (what's referred as contract) of the contract code. The account that sent this contract reference transactions is the one that will be running this contract.
