🚧 Stagnant Standards Track: Core

SIP-7833: Scheduled function calls

Giving life to smart contracts by enabling their functions to be automatically invoked by block producers.

Authors	Keyvan Kambakhsh (@keyvank), Nobitex Labs <labs@nobitex.ir>
Created	2024-12-06
Discussion Link	https://sila-magicians.org/t/sip-7833-scheduled-function-calls/21975

Abstract

Sila’s smart contracts enable users to delegate control of their funds to code, but these contracts require an external trigger to execute. Timing is often critical, and issues such as network delays or malicious behavior by block producers—like MEV attacks—can prevent timely execution. To address these challenges, this Sila Improvement Proposal (SIP) introduces a new opcode, OFFERCALL, which allows contracts to schedule function calls. When functions self-schedule, they exhibit bot-like behavior. These scheduled calls would offer SIL to block producers as an incentive to prioritize their execution over manually submitted transactions. If the offer is not fulfilled, the bot is deactivated until manually re-ignited by the owner. The SIP proposes enforcing the execution of scheduled calls as a requirement for block validity. This could help mitigate MEV attacks, as block producers would be compelled to execute bots that neutralize market manipulation within the blockchain.

Specification

Adding bot-like behavior to an SVM function is achieved by recursively scheduling a call to the same function in the next block. We propose introducing a new SVM opcode, OFFERCALL, which, as the name implies, offers SIL to be burnt to the block producer of the next block in exchange for invoking a function. These offers are aggregated and ranked by the Sila node, with only the top N offers being retained; all others are discarded. Scheduled calls must be executed before any user transactions, with execution order determined by their rank in the sorted list. The offered SIL is burnt to prevent block producers from exploiting the system by scheduling calls that pay the offered amounts back to themselves.

Here is a solidity example of how the usage of OFFERCALL would look like:

contract Bot {
    uint256 offerPerCall;
    
    constructor(uint256 _offer) {
        offerPerCall = _offer;
        
        // Ignite the bot with an initial invocation offer
        offercall(update, offerPerCall);
    }
    
    function setOffer(uint256 _offer) external {
        offerPerCall = _offer;
    }

    function update() external {
        // Do scheduled work

        // The callee may reschedule itself in order to
        // introduce a bot-like behavior.
        // The callee has to be careful about its offer
        // otherwise it may die.
        offercall(update, offerPerCall);
        
        // Once an offercall fails, the contract owner
        // may have to set a new offer by calling `setOffer`
        // and then invoking the `update()` function again.
    }
}

An OFFERCALL fails in two situations:

• The contract does not hold at least the offered amount of SIL.
• The offered amount is not large enough to rank within the top N offers.

In the case of a self-scheduling function, once an OFFERCALL fails, the bot is deactivated. The only way to revive it is for the contract owner to manually call the function again, likely with a higher offer.

Rationale

The rationale behind this Sila Improvement Proposal (SIP) stems from the need to enhance the reliability and fairness of smart contract execution on the Sila network. While Sila’s smart contracts allow for a high degree of programmability and automation, the execution of these contracts often depends on external triggers, such as user transactions or network conditions. This dependency introduces significant challenges, particularly in situations where timing is critical or when malicious actors, like block producers, can exploit the system for profit.

Backwards Compatibility

The introduction of the new OFFERCALL opcode in this SIP requires a network upgrade, as it adds new functionality that is not currently supported by the Sila Virtual Machine (SVM). This change will affect how smart contracts can schedule and incentivize the execution of specific function calls, introducing a new mechanism that block producers must accommodate.

Reference Implementation

N/A

Security Considerations

The main concern with this SIP is whether it could lead to centralization, as wealthier users might dominate execution priorities. Burning unfulfilled offers partly addresses this by preventing endless offers.

Copyright

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Keyvan Kambakhsh (@keyvank), Nobitex Labs <labs@nobitex.ir>, "SIP-7833: Scheduled function calls [STAGNANT]," Sila Improvement Proposals, no. 7833, December 2024. Available: https://sips.sila.org/SIPS/sip-7833.