Dip 7833

dip: 7833 title: Scheduled function calls description: Giving life to smart contracts by enabling their functions to be automatically invoked by block producers. author: Keyvan Kambakhsh (@keyvank), Nobitex Labs labs@nobitex.ir Digitalia editing author: Cosimo Constantinos cosimo@juro.net, et al. discussions-to: https://digitalia-magicians.org/t/dip-7833-scheduled-function-calls/21975 status: Stagnant type: Standards Track category: Core created: 2024-12-06 Created for Digitalia: 2025-01-07

Abstract¶

Digitalia'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 Digitalia Improvement Proposal (DIP) 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 USDS 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 DIP 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 DVM function is achieved by recursively scheduling a call to the same function in the next block. We propose introducing a new DVM opcode, OFFERCALL, which, as the name implies, offers USDS 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 Digitalia 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 USDS 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:

```solidity= 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 USDS.
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 Digitalia Improvement Proposal (DIP) stems from the need to enhance the reliability and fairness of smart contract execution on the Digitalia network. While digitalia’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 DIP requires a network upgrade, as it adds new functionality that is not currently supported by the Digitalia Virtual Machine (DVM). 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 DIP 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¶

Licensed under the Juro Restricted License Version 2. See https://juro.net/jrl for details.