ERC-1228 Delegated Execution

[kosecki123]

eip: TBD
title: Delegated Execution
author: Piotr Kosiński <piotr@chronologic.network>, Logan Saether <logan@chronologic.network>, Anthony Adegbemi <anthony@chronologic.network>, Josip Bagaric <joseph@chronologic.network>, Daniel Kmak <daniel@chronologic.network>
type: Standards Track
category: ERC
status: draft
created: 2018-07-18
Requires: 1197

Simple Summary

A standard interface for delegated transactions in order to execute them.

Abstract

The following standard allows for the implementation of a standard API for contracts that can be executed by any execution agents. We aim to define the type of interactions, payload storage and incentives for execution.

Motivation

A standard interface allows any smart contract to set a reward for the delegated execution. This allows developers to build general-purpose execution agent networks serving multiple protocols based on the delegated execution principal.

The idea of third party executions exists in the Ethereum Alarm Clock and Chronos protocols, as well as in standards such as EIP #1077 and EIP #948. This present EIP can in fact be viewed as a layer of abstraction over EIP #1077 as it defines the API for which third party executors can implement in order to be flexible across all of the third party execution schemes.

Ideally, the third party executor software could switch out the addresses it would execute at and be able to call these methods out of the box.

Specification

Contract

Methods

execute

Executes the _payload provides by the caller. MUST check for canExecute to return true before execution. SHOULD allow any caller to successfully execute the contract. SHOULD transfer funds set as fee to caller after successful execution.

OPTIONAL - payload equals 0x0 in case contract storing it internally.

function execute(bytes _payload) returns (bool result)

canExecute

Returns true if execution conditions are fulfilled for provided _payload.

function canExecute(bytes _payload) view returns (bool result)

payload

Returns the payload to be used for execute and canExecute functions

function payload() view returns (bytes payload)

payloadStorage

Returns the location of _payload. 0x0 in case using internal storage. Multilink in case using external storage.

function payloadStorage() view returns (bytes payloadStorage)

nonceUsed

Checks whether a specific nonce has been used for an account.

function nonceUsed(address _account, bytes32 _nonce) returns (bool used)

Will return true if the specific nonce has been used for the account and therefore the transaction is invalid to be executed. Otherwise, the nonce has not been used and the execution is valid for that nonce.

payToCode

Defines the code to be ran when an execution took place. The code will follow the EIP #1197 Meta Payments standard.

function payToCode() view returns (bytes _code)

Returns the code that will be run upon execution.

Events

Implementation

WIP https://github.com/chronologic/chronos/blob/c--/contracts/c_offchain/C.sol

History

Copyright

Copyright and related rights waived via CC0.

[PhABC]

Hey @kosecki123 ! Could you expand a bit more on how this is related to #1077 and why 1077 is not sufficient to cover the needs #1228 aims to fulfill? Some examples could be useful to better undersand!

[kosecki123]

Hey @PhABC. Both #1077 and this can fulfill the same needs. The differences I can think of now:

• ERC-1228 Delegated Execution #1228 doesn't define any scheme for payload, aims to be as flexible as possible - payload is not only the data to be sent with transaction but can also contains any other necessary fields like to, value, conditions etc - this is taken from our work at https://github.com/chronologic/chronos/blob/master/encoding.txt
• ERC-1228 Delegated Execution #1228 supports on-chain stored payloads too
• ERC-1228 Delegated Execution #1228 uses ERC-1197 Meta Payments #1197 as payments for execution

[PhABC]

Regarding payload flexibility, it seems to be like the data field in #1077 allows for arbitrary data, no? This could include conditions, values, even contract deployment data. It's just how the receiving contract interprets and handles this data that matters. Would you have a concrete example where something could not conform to #1077 when it comes to the payload definition?

I think I can see where storing on-chain the payloads could be useful for some applications, it can make things simpler.

ERC-1077 does refund the gas (in any tokens), but does not allow explicitly to pay more than the gas consumed. That's a good point

[kosecki123]

Regarding payload flexibility, it seems to be like the data field in #1077 allows for arbitrary data, no? This could include conditions, values, even contract deployment data. It's just how the receiving contract interprets and handles this data that matters. Would you have a concrete example where something could not conform to #1077 when it comes to the payload definition?

Agree, I overlooked the definition for the payload on #1077. So, yes this is the same.

ERC-1077 does refund the gas (in any tokens), but does not allow explicitly to pay more than the gas consumed. That's a good point

I think in general there are 2 different approaches and the root problems these ERCs are trying to solve.

• ERC: Executable Signed Messages refunded by the contract #1077 seems to be for UX improvements - which then probably leads to market structure where users of protocol A that uses token B will be able to interact with protocol A using only token B (not having ETH for gas). In this approach the executors will either be protocol A creators (similar to 0x relayers) or maybe other protocol A users (to improve protocol and token utility)

• ERC-1228 Delegated Execution #1228 aims to create the market structure where multiple protocols and tokens can be served. The executors in that model are random nodes that willing to execute transactions due to extra incentive defined by scheduler

@alexvandesande let me know if that's correct

[mesqueeb]

@kosecki123 What are your thoughts on #965 ?

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.