About HIPs

    GitHub Logo HIP-755: Schedule Service System Contract

    Author Nana Essilfie-Conduah
    Working Group Richard Bair, Jasper Potts, Atul Mahamuni
    Requested By Hashgraph
    Discussions-To https://github.com/hashgraph/hedera-improvement-proposal/pull/755
    Status Accepted ⓘ
    Needs Council Approval Yes ⓘ
    Review period ends ⓘ Fri, 28 Jul 2023 07:00:00 +0000
    Type Standards Track ⓘ
    Category Service ⓘ
    Created 2023-06-14
    Updated 2025-01-14

    Table of Contents

    Abstract

    This proposal addresses the feature gap of a smart contracts ability to interact with and support scheduled transactions via the HAPI scheduled transactions.

    Since smart contracts executions do not utilize the Hedera signature map they are unable to carry along the authorizations that the Hedera ledger uses to confirm an accounts participation and acknowledgment in a transaction.

    To address this, Smart Contracts could utilize the Hedera Schedule Service (HSS) by submitting authorizing transactions to indicate acceptance of the previously created scheduled transaction. This flow provides an easy route for asynchronous coordination of transaction approval. This HIP gives a framework through the Hedera Smart Contract Service (HSCS) to manage scheduled interactions created via HAPI or other future HIP implementations.

    Motivation

    In many decentralized scenarios a contract may issue a transaction that would require approval or authorization by multiple entities.

    This essentially means multi party operations are made challenging if not infeasible when using smart contracts.

    This is a step back in the Hedera UX that was made easier by the use of in transaction signatures.

    Rationale

    By providing a secure mechanism to acquire asynchronous authorization from multiple accounts, smart contracts can continue to be used for more decentralized operations while still maintaining the integrity of account sovereignty by allowing accounts to approve and confirm their participation in a transaction.

    User stories

    1. As an EOA I would like to initiate a smart contract execution that allows me to sign a scheduled transaction.
    2. As an EOA I would like to execute a smart contract transaction that signs a scheduled transaction without having to deploy an additional smart contract.
    3. As an EOA I would like to initiate a smart contract execution that prompts a contract to authorize a scheduled transaction.

    Specification

    HSCS will utilize the existing scheduled transaction service supported on the ledger within the system contract logic.

    To achieve this a new Hedera Schedule Service (HSS) system contract will need to be created to encompass and expose the necessary scheduled transaction features.

    Hedera Schedule Service (HSS) system contract

    A new IHederaScheduleService interface will be implemented to allow accounts to interact with the scheduled transaction service via smart contracts. Following system contract convention, HSS will be callable at the 0x16b address and will expose the following methods callable within smart contracts.

    Hash Selector
    0xf0637961 authorizeSchedule(address) external returns (int64 responseCode)
    0x358eeb03 signSchedule(address, bytes) external returns (int64 responseCode)

    signSchedule(address, bytes) allows a contract to pass along the protobuf serialized signature from an EOA needed for a future schedule transaction. This supports the prior acquisition of signatures and their future submission, as often utilized in direct HAPI transaction submissions. In order to validate the signatures in the signature map for the signSchedule(address, bytes) function call, a message has to be agreed upon. The most logical message would be the concatenated values of the shard, realm and number of the schedule transaction ID and this value will be used by convention.

    To support safe and easy direct calls by an EOA in accordance with the security model, new facade methods will be added as part of this HRC 755.

    Hash Selector
    0x06d15889 signSchedule() external returns (int64 responseCode)

    signSchedule() will not be callable from within a smart contract. For EthereumTransaction transactions, signSchedule() will reply on the inner ECDSA signature found in the RLP encoded transaction. For ContractCall and ContractCreate transactions, any applicable signature found in the signature map will be utilized just as with ScheduleSign.

    The execution of authorizeSchedule(address) or signSchedule(address, bytes) will execute a synthetic ScheduleSign child transaction on the network. In this case the submitted EthereumTransaction or ContractCall will be the parent transaction of the child ScheduleSign transaction. Should the ScheduleSign transaction provide the final key authorization of a schedule then in accordance with the HSS logic the inner schedule transaction will be executed by the network.

    Note, this HIP does not provide an API to create a scheduled transaction. This is left to future HIPs to present the appropriate transactions that may be scheduled. No further protobuf or application level changes are needed as HSS is already implemented and functional.

    Complex multisig scenarios involving both EOAs and contracts can be enabled using these features. Take a scenario where Ama schedules a transaction which requires the authorization keys of Bob (ECDSA), Carol (Complex), David (ED25519) and Contract E (ContractKey) in addition to her ED25519 key. The following sequence diagram shows how each of the parties interact with the network to ensure the execution of the scheduled transaction.

    HSCS multiSig schedule transaction

    Each entity in the flow may may take a notably different approach

    1. Ama provides her ED25519 authorization key as part of the ScheduleCreate transaction she submitted using the Hedera SDK.
    2. Bob issues calls to HSCS facade methods only to provide his ECDSA key`. In this flow Bob does not require the deployment of a wrapper contract to call the system contract functions. This flow shows how DApps may enable EOA’s to transaction with multi sig scheduled transactions. This flow suits EVM native wallets like Metamask where it’s not possible to expose HAPI details.
    3. Carol follows a flow in which she utilizes a wrapper contract of her own that makes the explicit system contract calls. She creates her complex signature (which may require other signers) out of band and submits it as a contract function parameter. This flow suits complex DApps and tooling as both ContraclCall and EtheremTransaction typs can be used.
    4. Dave utilizes Hedera native tools such as HashPack/Blade or direct SDK to submit a ContractCall since he must provide an ED25519 authorizing key.
    5. Contract E submits its ContractKey authorization after prompt from its owner. In this flow the owner may not be known but highlights decentralized flows such as DAOs where an administrative contract must carry out an action. This flow is applicable to all Hedera and EVM native tools as the key is a ContractKey type.

    Notably, all EOA’s could decide to follow the standard process and submit a HAPI ScheduleSign transaction outside of HSCS flows. This HIP simply exposes appropriate APIs to interface with HSS.

    Backwards Compatibility

    Backwards compatibility is ensured as no existing features are modified. Similar to the HTS system contract, this HIP simply exposes HAPI transaction functionality and the system contract will utilize the same HAPI services on the node.

    Security Implications

    Existing security consideration such as throttles for the HSS and HSCS will remain applicable. Additional considerations may include storage and fees.

    Notably, smart contract execution transactions may not be scheduled. That is, the scheduling of a ContractCreate, ContractCall or EthereumTransaction transactions will not by supported by HSS system contracts and nodes will explicitly reject such transactions.

    Storage considerations

    Schedule transaction timespan will continue to be honored and scheduled transactions will be removed from memory upon execution or expiration.

    Fee considerations

    Gas collections should encompass the following aspects of the network

    • Storage cost via fees
    • EVM execution work via gas
    • Consensus Node execution work via fees

    How to Teach This

    • Additional documentation
    • Smart Contract library repo examples
    • Doc site tutorials

    Reference Implementation

    Rejected Ideas

    The following functions were initially considered for implementation but were rejected after the determination that the only necessary information needed for the flows described above is the scheduleId.

    In the IHederaScheduleService interface:

    • getScheduledTransactionInfo(address) In the facade proxy contract
    • getScheduledTransactionInfo()

    Open Issues

    References

    • https://github.com/hashgraph/hedera-services/blob/develop/hedera-node/docs/scheduled-transactions/revised-spec.md
    • https://docs.hedera.com/guides/docs/hedera-api/schedule-service
    • https://docs.hedera.com/guides/docs/sdks/schedule-transaction
    • https://docs.hedera.com/guides/docs/mirror-node-api/rest-api#schedule-transactions
    • https://github.com/hashgraph/hedera-protobufs/blob/main/services/schedule_sign.proto

    Copyright/license

    This document is licensed under the Apache License, Version 2.0 – see LICENSE or (https://www.apache.org/licenses/LICENSE-2.0)

    Citation

    Please cite this document as: