Ethereum Contracts – Understanding Execution Triggers and Miner Involvement

contract-designcontract-developmentcontract-invocation

As a newbie, I am a bit confused…

I understand that a contract is a set of conditions the certain parties agreed upon, and that some actions may/should follow as a part of an agreement.

What I do not understand is whether the miners always execute the contract when they encounter it, or whether there is some kind of a trigger that tells the miners whether to execute the contract or not?
What if contracts become outdated and obsolete, and do not apply to a real-world anymore but can be executed regardless… wouldn't that be a waste of resources, and how is this situation handled ?
What if contract executes to do something stupid such as sending the spam or access the certain website to initiate a DoS attack… It cannot be deleted, it is decentralized, miners have no clue, etc. How is this prevented ?

If there is some kind of a trigger that tells the miners whether to execute it:

Could there be a sort of a null-trigger that tells the miners to always execute the contract ?
What is the set of conditions that miners process before processing the contract, and where is this programmed (if inside of a contract, then it must be a separate section of a code that acts as an execution trigger only, otherwise a contradiction) ?
Does the trigger need to be the money/ETH or can we use something else (for example, data from a weather station instead of ETH transactions) ?

Best Answer

It looks like I thought that Ethereum was a much bigger animal, or something completely different. Some of the questions I asked do not apply to Ethereum. The answer was well-written on Quora, and below is the copy-paste.

One way to understand Ethereum is to think of it as a special kind of bank containing all the money in the world. This means that there are no transactions to and from other banks. All transactions happen within. More importantly, it has no employees and instead operates by the consensus of its customers.

Like many other banks, Ethereum maintains bank accounts for its customers, each containing some money denominated in a currency called Ether. When one customer transfers money to another customer, the bank does not withdraw physical cash from one account and deposit it in the other. Instead, it simply increments the balance of the recipient account, and decrements the balance of the originating account.

In this way, you can see that the list of account balances is the “ground truth” - it is the ultimate arbiter of who is wealthy and who isn’t. In Ethereum, this list of accounts and their balances is known as the state. Every transaction can thus been seen as a state transition.

Executing a contract could involve several transactions. In our special Ethereum bank, it is not only people that have bank accounts - contracts have bank accounts too. In fact, one helpful way to think of contracts is to imagine them as people who execute instructions just as lawyers execute wills.

Executing a contract typically starts with the recipient, sender, third-party or even another contract, triggering the contract by making a transaction to it. You would think that it would be a cashless transaction since we are only triggering the movement of money. However, as with lawyers, you have to pay them for their services and they often charge by the hour. In Ethereum, the amount of work taken to execute the contract is denoted in a quantity called Gas. Different contracts may charge you different amounts of Ether for each unit of Gas. The triggering party has to foot this bill of say X amount. The contract, whose balance already contains the money to be paid out, will then make a transaction to pay the agreed upon amount, say Y, to the receiver. This completes the execution of the contract.

We can verify that the contract has been executed correctly by ensuring that the two state transitions occurred correctly. After the first transaction, the triggering account should have decreased by X Eth, and the contract’s account should have increased by the same amount. After the second, the contract’s account should have decreased by Y Eth and the recipient’s account should have increased by the same amount.

In our special bank, if most of its customers, even those not involved in the transaction, make these computations and agree on the end state, the outcome is ratified and taken as truth. The bank then moves on to processing the next transaction.

—-

The Ethereum White paper contains more details. It is remarkably comprehensible for a technical document explaining novel concepts. White Paper · ethereum/wiki Wiki · GitHub

Related Solutions

Solidity – How to Implement Contracts Callback in Solidity

This is what I came up with by filling in the blanks and edidting your code as little as possible. The difference with using events in your case, is that for each callback, a different value for param can be provided.

I'm certainly not very fond of this architure, as I think you should use interfaces instead, but alas.

pragma solidity 0.4.24;

contract A{

    struct ToCallBackContract {
        address contractAddress;
        bytes4 contractMethodToCall;
        bytes32 theOnlyArgument;
    }

    ToCallBackContract[] public contracts;

    // This mapping is used for finding contracts by their address
    mapping(address => uint256) contractIndexes;

    function triggeredFromOutside() public returns (bool){
        // Don't use var, the compiler wil infer you use uint8, and it might overflow quickly
        for(uint256 i=0; i< contracts.length; i++){
            //2- how? call the callback function of each registered contract

            ToCallBackContract storage toCallBackContract = contracts[i];
            // THIS MIGHT BE UNSAFE, PLEASE BE CAREFUL
            address(toCallBackContract.contractAddress).call(toCallBackContract.contractMethodToCall, toCallBackContract.theOnlyArgument);
        }

    }

    function registerCallback(bytes4 _cMethod, address _cAddress) public {
        //1- how? to save contract/method, number of parameters to receive?

        // Incrementing the lenght of the array creates an empty struct.
        uint256 index = contracts.length++;

        // Fill it up
        contracts[index].contractAddress = _cAddress;
        contracts[index].contractMethodToCall = _cMethod;

        // Register it in the indexes mapping
        contractIndexes[_cAddress] = index;
    }

    // This function sets the argument
    function setTheOnlyArgument(address _contractAddress, bytes32 _value) public {
        ToCallBackContract storage toCallBackContract = contracts[contractIndexes[_contractAddress]];
        toCallBackContract.theOnlyArgument = _value;
    }
}


contract P{
    A addressOfA;
    constructor(A _addressOfA) public {
        addressOfA = _addressOfA;
    }

    function _callback(bytes32 param) public {
       //do something
       emit SomethingDone(param);
    }

    function callFromOutsideToRegisterWithA() public {
       //3- how? to register with A 

       // A function signature is calculated like so:
       bytes4 sig = bytes4(keccak256("_callback(bytes32)"));
       // Then, register it
       addressOfA.registerCallback(sig, this);
    }

    event SomethingDone(bytes32 param);
}

To use it, first deploy A. The, deploy a P using the address of the deployed A. After that, call P's callFromOutsideToRegisterWithA method. This registers P and its _callback method with A. To set the value of the argument that is going to be sent to the _callback method of P, use A's setTheOnlyArgument method providing the address of P and the value you want A to pass to it.

Then, call A's triggeredFromOutside method, which whill call each registered P's callback, passing along the given value for theOnlyArgument.

Best Answer

Related Solutions

Solidity – How to Implement Contracts Callback in Solidity

Related Topic