-
Notifications
You must be signed in to change notification settings - Fork 145
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Michael Garber <[email protected]> Co-authored-by: Michael Garber <[email protected]>
- Loading branch information
1 parent
75c68e5
commit aa374e6
Showing
1 changed file
with
23 additions
and
25 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -2,15 +2,16 @@ | |
| hip: 756 | ||
| title: Contract Scheduled Token Create | ||
| author: Nana Essilfie-Conduah (@nana-ec), Luke Lee (@lukelee-sl) | ||
| working-group: Richard Bair (@rbair23), Jasper Potts (@jasperpotts), Atul Mahamuni (@atulmahamuni) | ||
| working-group: Richard Bair (@rbair23), Jasper Potts (@jasperpotts), Atul Mahamuni (@atulmahamuni), Stanimir Stoyanov ([email protected]) | ||
| 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/756 | ||
| updated: 2023-09-18 | ||
| updated: 2025-01-24 | ||
| --- | ||
|
|
||
| ## Abstract | ||
|
|
@@ -37,7 +38,7 @@ By providing a secure mechanism to assign accounts roles on tokens, smart contra | |
|
|
||
| 1. As a smart contract developer, I would like to initiate a smart contract transaction that creates a token and assigns other accounts to autorenew and/or treasurer operator roles. | ||
| 2. As a smart contract developer, I would like to update the accounts that are currently assigned as autoRenew and treasurer. | ||
| 3. As a smart contract developer, I would like to retrieve information such as the address and other token details for the token created via a scheduled token create transaction. | ||
| 3. As a smart contract developer, I would like to retrieve information such as the token details for the scheduled token create transaction. | ||
|
|
||
| An example of an E2E flow would see an EOA `Ama` call contract account `B` which then calls a variation of the `IHTS` `createToken()` methods to create a token `C` which assigns EOA `Dede` as a treasurer account and EOA `Eric` as the autoRenew account. | ||
| Upon execution of the transaction by the system contract logic on a consensus node will submit a synthetic `ScheduleCreate` transaction with the desired `TokenCreate` as the inner transaction. The transaction execution will return the address of the `ScheduleId` to the calling contract `B`. | ||
|
|
@@ -48,27 +49,23 @@ When the last signature is obtained by a network node the scheduled `TokenCreate | |
|
|
||
| The ledger HSCS will utilize the existing Scheduled transaction service supported on the ledger within the System contract logic. | ||
|
|
||
| To achieve this the Hedera Token Service (HTS) system contract logic must be updated to create scheduled transactions and utilize scheduled transaction features. | ||
| To achieve this the Hedera Schedule Service (HSS) system contract logic must be updated to create scheduled transactions and utilize scheduled transaction features. | ||
|
|
||
| ### Hedera Token Service (HTS) system contract | ||
| ### Hedera Schedule Service (HSS) system contract | ||
|
|
||
| The `IHederaTokenService` interface must be updated to explicitly | ||
| The `IHederaScheduleService` interface must be updated to explicitly | ||
|
|
||
| - capture scheduled token creations | ||
| - retrieve information about the scheduled transaction | ||
| - obtain the token address that will be created by the successful execution of the scheduled transaction. | ||
| - capture the details of a scheduled token creation for clarity | ||
| - capture scheduled token creations and updates | ||
| - retrieve information about the scheduled token creation | ||
|
|
||
| | Hash | Selector | | ||
| |---------------|--------------------------------------------------------------------------------------------------------------------------| | ||
| | `0xe780c5d3` | `getScheduledFungibleTokenCreateTransaction(address scheduleAddress) returns (FungibleTokenInfo memory tokenInfo)` | | ||
| | `0x14749042` | `getScheduledNonFungibleTokenCreateTransaction(address scheduleAddress) returns (NonFungibleTokenInfo memory tokenInfo)` | | ||
| | `0xf616ec93` | `getScheduledTokenAddress(address scheduleAddress) returns (int64 responseCode, address tokenAddress)` | | ||
| | `0x4742876e` | `scheduleCreateFungibleToken(…) returns (address scheduleAddress)` | | ||
| | `0xa001e7d2` | `scheduleCreateFungibleTokenWithCustomFees(…) returns (address scheduleAddress)` | | ||
| | `0xbbaa57c2` | `scheduleCreateNonFungibleToken(…) returns (address scheduleAddress)` | | ||
| | `0x228fa74a` | `scheduleCreateNonFungibleTokenWithCustomFees(…) returns (address scheduleAddress)` | | ||
| | `0xc42a9a17` | `scheduleUpdateTokenInfo(…) returns (int64 responseCode, address scheduleAddress)` | | ||
| | Hash | Selector | | ||
| |---------------|---------------------------------------------------------------------------------------------------------------------------------------------| | ||
| | `0xda2d5f8f` | `getScheduledCreateFungibleTokenInfo(address scheduleAddress) returns (int64 responseCode, FungibleTokenInfo memory tokenInfo)` | | ||
| | `0xd68c902c` | `getScheduledCreateNonFungibleTokenInfo(address scheduleAddress) returns (int64 responseCode, NonFungibleTokenInfo memory tokenInfo)` | | ||
| | `0xca829811` | `scheduleNative(address systemContractAddress, bytes callData, address payerAddress) returns (int64 responseCode, address scheduleAddress)` | | ||
|
|
||
| `scheduleNative(address,bytes,address)` will be used to schedule the token creation or update transaction. The `callData` will be the ABI encoded `TokenCreate` or `TokenUpdate` transaction. The `payerAddress` will be the account that will pay for the transaction fees. | ||
| For the purpose of the HIP the only whitelisted `systemContractAddress` will be the `HederaTokenService` system contract (`0x167`) and for the `callData` the only acceptable ABI encoded transaction will be the `TokenCreate` and `TokenUpdate` transactions - `createFungibleToken`, `createFungibleTokenWithCustomFees`, `createNonFungibleToken`, `createNonFungibleTokenWithCustomFees` and `updateTokenInfo`. | ||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
|
|
@@ -102,17 +99,18 @@ Gas collections should encompass the following aspects of the network | |
|
|
||
| A few options were considered prior to this, notable considerations were | ||
|
|
||
| 1. An update to the `TokenCreate` HAPI transaction to optionally leave out signatures for treasury and autoRenew, with the requirement that a future `TokenUpdate` transaction would be required by the treasurer and autoRenew accounts to either accept or reject their assignments. The normal functioning of a token would be halted until roles had been accepted. Additionally, the concept of a `TokenAccountOperator` enum would have been introduced in the protobuf to capture various operator roles. On the system contracts additonal functions (`defaultTokenOperators()`, `authorizeTokenOperator(address operator, uint operatorType)` and `revokeTokenOperator(address operator, uint operatorType)`) to expose query, apporval and rejection logic. These function were inspired by EIP 777. | ||
|
|
||
| 1. An update to the `TokenCreate` HAPI transaction to optionally leave out signatures for treasury and autoRenew, with the requirement that a future `TokenUpdate` transaction would be required by the treasurer and autoRenew accounts to either accept or reject their assignments. The normal functioning of a token would be halted until roles had been accepted. Additionally, the concept of a `TokenAccountOperator` enum would have been introduced in the protobuf to capture various operator roles. On the system contracts additonal functions (`defaultTokenOperators()`, `authorizeTokenOperator(address operator, uint operatorType)` and `revokeTokenOperator(address operator, uint operatorType)`) to expose query, apporval and rejection logic. These function were inspired by EIP 777. | ||
| 2. Overload the existing create and update token functions by adding a `bool` to indicate if the transaction is a scheduled transaction. This would require that the returned address be either the token address or the schedule address and thus make the api unnecessarily confusing. | ||
| 3. Create separate functions that reflect the existing `TokenCreate` and `TokenUpdate` functions but with the ability to schedule the transaction - `scheduleCreateFungibleToken(…), scheduleCreateFungibleTokenWithCustomFees(…), scheduleCreateNonFungibleToken(…), scheduleCreateNonFungibleTokenWithCustomFees(…) and scheduleUpdateTokenInfo(…)`. This would have required a new set of functions to be added to the `IHederaScheduleService` interface for every future schedulable functionality. | ||
| 4. A function to retrieve the token address given a schedule address prior to the token creation. This would have required a new function to be added to the `IHederaScheduleService` interface. | ||
|
|
||
| ## Open Issues | ||
|
|
||
| 1. How can a consensus node retrieve the valid TokenAddress given a ScheduleAddress. On the Mirror Node this will be possible by following ScheduleAddress → ScheduleId → Schedule transaction execution timestamp → Token Create child transaction → recordFile Token Id. However, this information isn’t available to the consensus node. Should a ScheduleId → TokenId map be created and persisted? | ||
| 2. It is possible to overload the existing create and update token functions by adding a `bool` to indicate if the transaction is a scheduled transaction. This would require that the returned address be either the token address or the schedule address and thus make the api unnecessarily confusing. | ||
| 1. Long term scheduled transactions via smart contract. This issue will be addressed in a future HIP. | ||
|
|
||
| ## References | ||
|
|
||
|
|
||
| - [HIP-755](https://hips.hedera.com/hip/hip-755) | ||
|
|
||
| ## Copyright/license | ||
|
|
||
|
|
||