From 0f67df4ed484d7e384be60fb401c47a4916460a3 Mon Sep 17 00:00:00 2001 From: Konstantina Blazhukova Date: Wed, 13 Nov 2024 20:12:37 +0200 Subject: [PATCH 1/8] Creates design doc for enabling access to newly created hts token address Signed-off-by: Konstantina Blazhukova --- docs/design/hts_address_tx_receipt.md | 36 +++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) create mode 100644 docs/design/hts_address_tx_receipt.md diff --git a/docs/design/hts_address_tx_receipt.md b/docs/design/hts_address_tx_receipt.md new file mode 100644 index 000000000..22cf1f9d2 --- /dev/null +++ b/docs/design/hts_address_tx_receipt.md @@ -0,0 +1,36 @@ +# HTS Token Creation via SystemContract Receipt Enhancement + +## Purpose +The purpose of this enhancement is to improve the interoperability between Hedera Token Service (HTS) and Ethereum-compatible tools, like ethers, by ensuring access to the necessary information about newly created tokens, in this case token address. This change specifically addresses the gap in Web3 tooling support when creating tokens through HTS precompile contracts, making user experience more smooth. + + +## Problem Statement +When users create tokens (fungible and non-fungible) by directly calling the 0x167 contract there is no way for to get the contract address of the newly created token via ethers. This is because the transaction receipt's contractAddress field is not being populated correctly for HTS token creation operations, since essentially they are just a contract call, but not a contract create (deploy). + +## Current Behaviour + +Currently, when creating a token via HTS the address of the system contract ic returned as a contractAddress in the transaction receipt. + +## Proposed Solution + +### Technical Details + +1. Function Signature Detection + +Detect in the transactionResponse from the mirror node, if the transaction was calling any of the HTS method e.g createFungibleToken/createNonFungibleToken etc. + +N.B Currently, HTS supports both v1 and v2 security model function selectors + +1. Extract the token address from the call_result field in the transaction response. + +2. Add the token address to the receipt + + +## Testing Requirements + +1. Unit tests + 1. Test token creation function signature detection + +2. Acceptance tests + 1. Test fungible token creation flow via ethers and correct receipt response + 2. Test non fungible token creation flow via ethers and correct receipt response From 91a33f86405b26d8ba181200fe9b5090c1b61bfc Mon Sep 17 00:00:00 2001 From: Konstantina Blazhukova Date: Wed, 13 Nov 2024 21:29:57 +0200 Subject: [PATCH 2/8] Makes small wording changes Signed-off-by: Konstantina Blazhukova --- docs/design/hts_address_tx_receipt.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/design/hts_address_tx_receipt.md b/docs/design/hts_address_tx_receipt.md index 22cf1f9d2..163083e95 100644 --- a/docs/design/hts_address_tx_receipt.md +++ b/docs/design/hts_address_tx_receipt.md @@ -1,15 +1,15 @@ # HTS Token Creation via SystemContract Receipt Enhancement ## Purpose -The purpose of this enhancement is to improve the interoperability between Hedera Token Service (HTS) and Ethereum-compatible tools, like ethers, by ensuring access to the necessary information about newly created tokens, in this case token address. This change specifically addresses the gap in Web3 tooling support when creating tokens through HTS precompile contracts, making user experience more smooth. +The purpose of this enhancement is to improve the interoperability between Hedera Token Service (HTS) and Ethereum-compatible tools, like ethers, by ensuring access to the necessary information about newly created tokens, in this case token address. This change specifically addresses the gap in Web3 tooling support when creating tokens through HTS precompile contracts, making user experience smoother. ## Problem Statement -When users create tokens (fungible and non-fungible) by directly calling the 0x167 contract there is no way for to get the contract address of the newly created token via ethers. This is because the transaction receipt's contractAddress field is not being populated correctly for HTS token creation operations, since essentially they are just a contract call, but not a contract create (deploy). +When users create tokens (fungible and non-fungible) by directly calling the 0x167 contract there is no way for to get the contract address of the newly created token via ethers. This is because the transaction receipt's contractAddress field is not being populated with the HTS token address, since essentially the operations is just a contract call, but not a contract create (deploy). ## Current Behaviour -Currently, when creating a token via HTS the address of the system contract ic returned as a contractAddress in the transaction receipt. +Currently, when creating a token via HTS the address of the system contract is returned as a contractAddress in the transaction receipt. ## Proposed Solution From 3a07dff2cea900bba11cfc7023556c37fad02aa3 Mon Sep 17 00:00:00 2001 From: Konstantina Blazhukova Date: Thu, 14 Nov 2024 14:17:07 +0200 Subject: [PATCH 3/8] Improves design doc Signed-off-by: Konstantina Blazhukova --- docs/design/hts_address_tx_receipt.md | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/docs/design/hts_address_tx_receipt.md b/docs/design/hts_address_tx_receipt.md index 163083e95..f7007f086 100644 --- a/docs/design/hts_address_tx_receipt.md +++ b/docs/design/hts_address_tx_receipt.md @@ -5,7 +5,7 @@ The purpose of this enhancement is to improve the interoperability between Heder ## Problem Statement -When users create tokens (fungible and non-fungible) by directly calling the 0x167 contract there is no way for to get the contract address of the newly created token via ethers. This is because the transaction receipt's contractAddress field is not being populated with the HTS token address, since essentially the operations is just a contract call, but not a contract create (deploy). +When users create tokens (fungible and non-fungible) by directly calling the 0x167 contract there is no way for them to get the evm address of the newly created token via standard EVM tooling e.g ethers. This is because the transaction receipt's contractAddress field is not being populated with the HTS token address, since essentially the operations is just a contract call, but not a contract create (deploy). ## Current Behaviour @@ -17,13 +17,30 @@ Currently, when creating a token via HTS the address of the system contract is r 1. Function Signature Detection -Detect in the transactionResponse from the mirror node, if the transaction was calling any of the HTS method e.g createFungibleToken/createNonFungibleToken etc. +Detect in the transactionResponse from the mirror node, if the transaction was calling any of the HTS methods - createFungibleToken/createNonFungibleToken/createFungibleTokenWithCustomFees/createNonFungibleTokenWithCustomFees N.B Currently, HTS supports both v1 and v2 security model function selectors -1. Extract the token address from the call_result field in the transaction response. - -2. Add the token address to the receipt +```javascript +const HTS_CREATE_FUNCTIONS_SIGNATURE = [ + "createFungibleToken(...)", + "createNonFungibleToken(...)", + "createFungibleTokenWithCustomFees(...)", + "createNonFungibleTokenWithCustomFees(...)" +]; +const functionSelector = receiptResponse.function_parameters.substring(0, FUNCTION_SELECTOR_CHAR_LENGTH); +const isTokenCreation = HTS_CREATE_FUNCTIONS_SIGNATURE.some(signature => + Utils.calculateFunctionSelector(signature) === functionSelector +); +``` + +2. Extract the token address from the call_result field in the transaction response. The extractions can happen with brute force since we know what the function response is beforehand and we know the last 40 characters of the response are the token address. + +```javascript +const tokenAddress = receiptResponse.call_result.substring(receiptResponse.call_result.length - 40); +``` + +3. Add the token address to the receipt ## Testing Requirements From 92a3d619cb8981b2454965bf77fb7a918fc10e75 Mon Sep 17 00:00:00 2001 From: Konstantina Blazhukova Date: Thu, 14 Nov 2024 14:22:28 +0200 Subject: [PATCH 4/8] Makes testing plan more detailed Signed-off-by: Konstantina Blazhukova --- docs/design/hts_address_tx_receipt.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/docs/design/hts_address_tx_receipt.md b/docs/design/hts_address_tx_receipt.md index f7007f086..c8f7b739e 100644 --- a/docs/design/hts_address_tx_receipt.md +++ b/docs/design/hts_address_tx_receipt.md @@ -45,9 +45,8 @@ const tokenAddress = receiptResponse.call_result.substring(receiptResponse.call_ ## Testing Requirements -1. Unit tests - 1. Test token creation function signature detection - -2. Acceptance tests - 1. Test fungible token creation flow via ethers and correct receipt response - 2. Test non fungible token creation flow via ethers and correct receipt response +1. Acceptance tests + 1. Test creation of fungible token via ethers and correct receipt response + 2. Test creation of non fungible token via ethers and correct receipt response + 3. Test creation of fungible token with custom fees via ethers and correct receipt response + 4. Test creation of non fungible token with custom fees via ethers and correct receipt response From 49f3591f9c1983ad2a45281dc7d809de87e5cbf7 Mon Sep 17 00:00:00 2001 From: Konstantina Blazhukova Date: Thu, 14 Nov 2024 18:01:41 +0200 Subject: [PATCH 5/8] Adds example call result Signed-off-by: Konstantina Blazhukova --- docs/design/hts_address_tx_receipt.md | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/docs/design/hts_address_tx_receipt.md b/docs/design/hts_address_tx_receipt.md index c8f7b739e..648904328 100644 --- a/docs/design/hts_address_tx_receipt.md +++ b/docs/design/hts_address_tx_receipt.md @@ -15,7 +15,7 @@ Currently, when creating a token via HTS the address of the system contract is r ### Technical Details -1. Function Signature Detection +### 1. Function Signature Detection Detect in the transactionResponse from the mirror node, if the transaction was calling any of the HTS methods - createFungibleToken/createNonFungibleToken/createFungibleTokenWithCustomFees/createNonFungibleTokenWithCustomFees @@ -34,13 +34,22 @@ const isTokenCreation = HTS_CREATE_FUNCTIONS_SIGNATURE.some(signature => ); ``` -2. Extract the token address from the call_result field in the transaction response. The extractions can happen with brute force since we know what the function response is beforehand and we know the last 40 characters of the response are the token address. +### 2. Extract the token address from the call_result field in the transaction response. The extractions can happen with brute force since we know what the function response is beforehand and we know the last 40 characters of the response are the token address. + +Example call_result. First 64 characters excluding 0x prefix are the response code, second 64 characters are the token address: +```json +"call_result": "0x0000000000000000000000000000000000000000000000000000000000000016000000000000000000000000000000000000000000000000000000000000040a" +``` ```javascript const tokenAddress = receiptResponse.call_result.substring(receiptResponse.call_result.length - 40); ``` +After extraction, the expected output is: +``` +"0x000000000000000000000000000000000000000000000000000000000000040a" +``` -3. Add the token address to the receipt +### 3. Add the token address to the receipt ## Testing Requirements From 95efc286f5b2df73d2ddf359c8e58bb709dfa96d Mon Sep 17 00:00:00 2001 From: Konstantina Blazhukova Date: Thu, 14 Nov 2024 18:02:54 +0200 Subject: [PATCH 6/8] Makes small improvement to fromatting Signed-off-by: Konstantina Blazhukova --- docs/design/hts_address_tx_receipt.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design/hts_address_tx_receipt.md b/docs/design/hts_address_tx_receipt.md index 648904328..fcaeba5d6 100644 --- a/docs/design/hts_address_tx_receipt.md +++ b/docs/design/hts_address_tx_receipt.md @@ -54,7 +54,7 @@ After extraction, the expected output is: ## Testing Requirements -1. Acceptance tests +### Acceptance tests 1. Test creation of fungible token via ethers and correct receipt response 2. Test creation of non fungible token via ethers and correct receipt response 3. Test creation of fungible token with custom fees via ethers and correct receipt response From 40f8f16672bdde756092756c46c1b71a30f4e7bc Mon Sep 17 00:00:00 2001 From: konstantinabl Date: Fri, 15 Nov 2024 15:57:46 +0200 Subject: [PATCH 7/8] Update docs/design/hts_address_tx_receipt.md Co-authored-by: Nana Essilfie-Conduah <56320167+Nana-EC@users.noreply.github.com> Signed-off-by: konstantinabl --- docs/design/hts_address_tx_receipt.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/design/hts_address_tx_receipt.md b/docs/design/hts_address_tx_receipt.md index fcaeba5d6..37b621242 100644 --- a/docs/design/hts_address_tx_receipt.md +++ b/docs/design/hts_address_tx_receipt.md @@ -19,7 +19,7 @@ Currently, when creating a token via HTS the address of the system contract is r Detect in the transactionResponse from the mirror node, if the transaction was calling any of the HTS methods - createFungibleToken/createNonFungibleToken/createFungibleTokenWithCustomFees/createNonFungibleTokenWithCustomFees -N.B Currently, HTS supports both v1 and v2 security model function selectors +N.B The following forms of the [HTS system contract](https://github.com/hashgraph/hedera-smart-contracts/tree/v0.10.1/contracts/system-contracts/hedera-token-service) create token function selectors will be supported. This is as of the 0.56 version of the services. ```javascript const HTS_CREATE_FUNCTIONS_SIGNATURE = [ From 06ba64b531177d543d9e87c849f7086361d884fb Mon Sep 17 00:00:00 2001 From: konstantinabl Date: Fri, 15 Nov 2024 15:58:12 +0200 Subject: [PATCH 8/8] Update docs/design/hts_address_tx_receipt.md Co-authored-by: Nana Essilfie-Conduah <56320167+Nana-EC@users.noreply.github.com> Signed-off-by: konstantinabl --- docs/design/hts_address_tx_receipt.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/design/hts_address_tx_receipt.md b/docs/design/hts_address_tx_receipt.md index 37b621242..58a721bf9 100644 --- a/docs/design/hts_address_tx_receipt.md +++ b/docs/design/hts_address_tx_receipt.md @@ -34,7 +34,8 @@ const isTokenCreation = HTS_CREATE_FUNCTIONS_SIGNATURE.some(signature => ); ``` -### 2. Extract the token address from the call_result field in the transaction response. The extractions can happen with brute force since we know what the function response is beforehand and we know the last 40 characters of the response are the token address. +### 2. Extract the token address from the `call_result` field in the transaction response. +The extractions can performed with string matching logic since we know what the function response is beforehand and we know the last 40 characters of the response are the token address. Example call_result. First 64 characters excluding 0x prefix are the response code, second 64 characters are the token address: ```json