Generalized hip-756 with scheduleContractCall

[littletarzan]

HIP-756 introduced the idea of scheduling a contract call using Hedera Schedule Service for the purpose of modifying token entities. However, it's possible to do much more than this by allowing generalized contract calls to be scheduled by HSS. Fundamentally, contract calls consist of a 4 byte function selector and a series of encoded bytes that can be passed to a smart contract using HSS.

HIP-756 can be generalized in the form of a scheduleContractCall(bytes calldata data) HTS precompile. This would minimize the size of IHederaTokenService.sol and allow smart contract developers maximum freedom for contract calls they can schedule.

[Neurone]

Hi @littletarzan , HIP-755 extended the ability to schedule transactions to the EVM service, so all types of Ethereum transactions.

You can already test this feature on the testnet, here a useful tutorial: On-Chain Smart Contract Cron Jobs with Hedera Schedule Service

I think this poses the basis for what you are asking.

The only missing part would be now making the creation of the scheduled transaction available via the HSS precompile (in addition to authorizeSchedule and signSchedule included in HIP-755) something like createSchedule(bytes) external returns (int64 responseCode, address scheduleAddress).

What do you think?

[littletarzan]

@Neurone This is a very cool and useful upgrade for scheduled transactions that has many uses for one time transactions to execute. My reasoning for allowing a smart contract to schedule ContractExecuteTransactions is to recursively schedule and execute contract calls perpetually. For example, in the smart contract below:

// Do not use this for anything, this is only an example
contract IncrementDaily is IHederaScheduleService {

    uint256 num = 0;
    
    function incrementNumberDaily() external {
          num++;
          IHederaScheduleService.scheduleContractCall(
             bytes4(keccak256("incrementNumberDaily()")),
             24*3600
          ); // schedule the next call in 1 day
    }
}

This would call itself daily as long as the contract had enough hbar to pay schedule fees and gas, making it a regularly occurring cron job. Simple use cases are to release funds from a vesting contract as they vest, harvest farming rewards or swap fees in DeFi, etc. If a contract can schedule these on its own then no external input is needed after the first contract call.

[subfallen]

Indeed...@Neurone, note that the current IHederaScheduleService.scheduleNative() method is very locked down---it supports scheduling exclusively calls to createToken() and updateToken() variants of IHederaTokenService.

The idea here is simply to allow scheduling a ContractCall to any address.

[Neurone]

Yeah, I agree and I love the idea of a smart contract being able to init a scheduled transaction via the HSS, but I see here it's probably good enough for the smart contract to be able to schedule a contract call in the future (so not all native schedule transaction types).

@littletarzan I see in your example the contract can only call itself, while @subfallen and I suggest it should be able to call any address. Is there a specific reason for this? Do you see potential problems with scheduling calls to another address, or is it good for you if we introduce a broader approach?

In parallel, I think we can definitely start moving this forward with a dedicated HIP. Would you mind creating a draft according to this guideline?

[littletarzan]

@Neurone That's right, in my simple example the contract calls itself, but there should be a target contract address whose function is being called to make it more general. Perhaps something like below:

interface IHederaScheduleService {
    ...
    function scheduleContractCall(address targetContract, uint256 epochTimeToCall, bytes memory args) external payable returns (int32 responseCode);
}