feat: Creates design doc for enabling access to hts token evm address

[konstantinabl]

Description:

Creates a design doc for new change to trasnaction receipt format, related to hts token address
Reference: hashgraph/hedera-smart-contracts#901

Related issue(s):

Fixes #3257

[github-actions]

Test Results

 19 files  + 18  254 suites  +247   30m 38s ⏱️ + 30m 8s
609 tests +604  604 ✅ +600  4 💤 +4  1 ❌ ±0 
699 runs  +663  692 ✅ +657  6 💤 +6  1 ❌ ±0 

For more details on these failures, see this check.

Results for commit 06ba64b. ± Comparison against base commit ce43b76.

This pull request removes 1 and adds 605 tests. Note that renamed tests count towards both.

"before all" hook in "@api-batch-2 RPC Server Acceptance Tests" ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-2 RPC Server Acceptance Tests "before all" hook in "@api-batch-2 RPC Server Acceptance Tests"

"before all" hook in "Debug API Test Suite" ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests Debug API Test Suite "before all" hook in "Debug API Test Suite"
"eth_call" for non-existing contract address returns 0x ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call "eth_call" for non-existing contract address returns 0x
001 Should call pureMultiply ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call Caller contract With evm address 001 Should call pureMultiply
001 Should call pureMultiply ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call Caller contract With long-zero address 001 Should call pureMultiply
002 Should call msgSender ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call Caller contract With evm address 002 Should call msgSender
002 Should call msgSender ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call Caller contract With long-zero address 002 Should call msgSender
003 Should call txOrigin ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call Caller contract With evm address 003 Should call txOrigin
003 Should call txOrigin ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call Caller contract With long-zero address 003 Should call txOrigin
004 Should call msgSig ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call Caller contract With evm address 004 Should call msgSig
004 Should call msgSig ‑ RPC Server Acceptance Tests Acceptance tests @api-batch-3 RPC Server Acceptance Tests eth_call Caller contract With long-zero address 004 Should call msgSig
…

♻️ This comment has been updated with latest results.

[Nana-EC]

Nice start,
More details need to be highlighted in the design doc to give a clear idea of approach.
See docs under https://github.com/hashgraph/hedera-json-rpc-relay/tree/main/docs/design for inspiration

[Nana-EC]

What approach are you intending to utilize to extract?
Is it just brute force string manipulation or are you using additional logic to parse the bytes into an expected format and pull the address from that?

[konstantinabl]

Brute force manipulation I would say, Improved the description

[Nana-EC]

Nice improvements.
Signing off so as to not block but please adopt some form of my suggestions

[sonarcloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 77.88%. Comparing base (ce43b76) to head (06ba64b).
Report is 4 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #3258      +/-   ##
==========================================
+ Coverage   77.84%   77.88%   +0.03%     
==========================================
  Files          66       66              
  Lines        4460     4468       +8     
  Branches     1000     1003       +3     
==========================================
+ Hits         3472     3480       +8     
  Misses        613      613              
  Partials      375      375              

Flag	Coverage Δ
config-service	98.14% <ø> (ø)
relay	78.63% <ø> (+0.04%)	⬆️
server	83.28% <ø> (ø)
ws-server	36.66% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

see 2 files with indirect coverage changes

[natanasow]

This design handles the direct precompile call flow well.

There might be a case where we create an HTS token within the contract's constructor. What will we return in that case? Is the newly created contract's address or the HTS token address?

In terms of the Ethereum equivalence, we always must return the contract's address. Maybe we should add a section in the readme with something like "In case of HTS token creation within the constructor, the user should manually emit an event and handle the token address exposure on the contract's side"?

@Nana-EC actually, are we thinking of handling an HTS token creation within a contract and populating the contractAddress field with the newly created token address on the top-level transaction's receipt?

[Nana-EC]

This design handles the direct precompile call flow well.

There might be a case where we create an HTS token within the contract's constructor. What will we return in that case? Is the newly created contract's address or the HTS token address?

In terms of the Ethereum equivalence, we always must return the contract's address. Maybe we should add a section in the readme with something like "In case of HTS token creation within the constructor, the user should manually emit an event and handle the token address exposure on the contract's side"?

@Nana-EC actually, are we thinking of handling an HTS token creation within a contract and populating the contractAddress field with the newly created token address on the top-level transaction's receipt?

Hmmm, I don't think we need to handle in contract calls as there it is the responsibility of the developer to handle the functions response. And yeah if they want they can emit an event to externalize the token address.