Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: HIP-755 - add post implementation updates for accuracy #1098

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+17 −12
Open

chore: HIP-755 - add post implementation updates for accuracy #1098

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
93f43cc
chore: add post implementation updates for accuracy
lukelee-sl Jan 14, 2025
7fb3f99
change updated date
lukelee-sl Jan 14, 2025
51906a5
add requested-by header
lukelee-sl Jan 14, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
29 changes: 17 additions & 12 deletions HIP/hip-755.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,14 +3,15 @@ hip: 755
title: Schedule Service System Contract
author: Nana Essilfie-Conduah (@nana-ec)
working-group: Richard Bair (@rbair23), Jasper Potts (@jasperpotts), Atul Mahamuni <@atul-hedera>
requested-by: Hashgraph
type: Standards Track
category: Service
needs-council-approval: Yes
status: Accepted
last-call-date-time: 2023-07-28T07:00:00Z
created: 2023-06-14
discussions-to: https://github.com/hashgraph/hedera-improvement-proposal/pull/755
updated: 2023-09-18
updated: 2025-01-14
---

## Abstract
Expand All @@ -20,7 +21,7 @@ This proposal addresses the feature gap of a smart contracts ability to interact
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 implimentations.
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

Expand All @@ -37,9 +38,8 @@ By providing a secure mechanism to acquire asynchronous authorization from multi
## 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 tranaction without having to deploy an additional smart contract.
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.
4. As an EOA I would like to initiate a smart contract execution or query that allows me to extract information about a scheduled transaction.

## Specification

Expand All @@ -50,32 +50,31 @@ To achieve this a new Hedera Schedule Service (HSS) system contract will need to
### 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 `0x16a` address and will expose the following methods callable within 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)` |
| `0x5e147101` | `getScheduledTransactionInfo(address) external returns (int64 responseCode, ScheduleInfo memory scheduleInfo)` |
| `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 sigatures and their future submission, as often utilized in direct HAPI transaction submissions.

The `ScheduleInfo` object will be a struct that matches the details of the [ScheduleInfo protobuf message](https://github.com/hashgraph/hedera-protobufs/blob/main/services/schedule_get_info.proto)
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.
Comment on lines +62 to +64
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These last two sentences are less "specification" (the section name) and more "suggestion to developers". Especially the last sentence. I don't suggest moving them elsewhere, but maybe they should be subordinate in some way, e.g., a bullet point?

(This is me ratholing on style again, sorry.)


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.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the only use of "HRC" in this file. Is it supposed to be "HIP"? Or if "HRC" then also spell out the acronym somewhere (footnote)?


| Hash | Selector |
|---------------|-----------------------------------------------------------------------------------------------------------|
| `0x06d15889` | `signSchedule() external returns (int64 responseCode)` |
| `0x88af14e6` | `getScheduledTransactionInfo() external returns (int64 responseCode, ScheduleInfo memory scheduleInfo)` |

`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](https://github.com/hashgraph/hedera-protobufs/blob/main/services/schedule_sign.proto#L50).

The execution of `authorizeSchedule(address)` or `signSchedule(...)` will execute a synthetic [ScheduleSign](https://github.com/hashgraph/hedera-protobufs/blob/main/services/schedule_sign.proto) 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 inned schedule transaction will be executed by the network.
The execution of `authorizeSchedule(address)` or `signSchedule(address, bytes)` will execute a synthetic [ScheduleSign](https://github.com/hashgraph/hedera-protobufs/blob/main/services/schedule_sign.proto) 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.
Expand Down Expand Up @@ -128,7 +127,13 @@ Gas collections should encompass the following aspects of the network


## 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

Expand Down
Loading