HIP-206: Hedera Token Service Precompiled Contract for Hedera Smart Contract Service

[shemnon]

Discussion for integrating the Hedera token services with the Hedera smart contract service.

[Daniel-K-Ivanov]

The gas cost of the precompile will be variable based on the specific function called, but will not be less than 1 gas per byte of data in the input data. Gas will be priced so that it will be cheaper to do calls directly to HTS rather than through HSCS where such calls are possible.

The majority of the costs when executing normal operations comes from signature verification, so if an HTS transfer is executed, 90% of the cost is for verification (90% is an example). That being said, if users are calling HSCS they will pay for the signature verification + EVM gas costs. Those EVM gas costs will include the HTS transfer and if that HTS Precompile is priced higher than normal HTS transfers, it will be really expensive compared to normal HTS transfers.

When we price in the HTS Precompile, we can compare it to the normal HTS fee excluding the sig verifications to get a better sense of the price, since the signatures for the HTS precompile will be part of the Hedera HSCS resource usage estimation by counting the signatures provided as part of the GRPC

[Daniel-K-Ivanov]

The four remaining functions tokenMint, tokenBurn, associateTokens, and dissociateTokens serve as direct mappings to their respective gRPC calls.

I think that it would be better if the naming of the operations are more consistent. F.e tokenMint and tokenBurn are consistent with each other but for associate/disassociate that is not the case. For mint and burn we are starting with the token and after that the operation but for associate/disassociate we are starting with the operation and then the tokens. I think that you've chosen this interface since for associate/disassociate we are referring to tokens (plural) and not one token. I am completely okay with your suggestion, just sharing some thoughts around the naming. Making them consistent by having:

• tokenBurn, tokenMint, tokenAssociate and tokenDisassociate but supporting multiple tokens is not a good interface
• burnToken, mintToken, assoicateTokens and disasscoiateTokens might be worth considering but then burnToken and mintToken are not used in the normal HTS operations

[shemnon]

The argument lists were taken directly from the protobuf messages. The names were taken from the transaction body names and not the TokenService rpc names. I'll update the methods to match the service names. The goal was to allow as complete a mapping as possible.

I'll add single-token versions of associate and dissociate.

[Daniel-K-Ivanov]

Support tokenGetInfo? (total supply, symbol, etc.)

I think that having support for tokenGetInfo will be quite straightforward if we have all the other operations implemented. Do you think that we can define a struct in solidity that we can parse the token info (bytes returned from the precompile) into?

p.s we can always include it in a second release and not in the first one.

[shemnon]

It's not too difficult, but not on the "big 5" list for first release, so it's not a top priorty. I think it would make sense to prioritize it at the same level as the ERC-20/721 functions.

[Daniel-K-Ivanov]

To support contracts controlling features like minting and burning the defined but up until now unused field contractID in the Key protobuf message. When a token has a contract key as the admin key or one of the admin keys then that key is considered validated if the CALLER of the relevant method is the contract identified in the call. as well as the sender of the contract itself. This is the effect of a CALL operation in the EVM.

Have we thought about what would happen if the adminKey is set to a KeyList of n contractIDs. I am not sure how we would be able to "validate" multiple ContractIDs since we have only one CALLER

[shemnon]

That would make that threshold unsatisfiable. 1 of n for multiple contracts is viable, allowing multiple contracts (possibly one that had to be deployed in parts) to admin. 2 of n where there is at least one non-contract key also works. i.e. requires an admin key to sign the tx then one of the other contracts to execute.

The question is do we prohibit that setup? I could see possibly in the future allowing contracts to "sign" scheduled transactions, so a 3 of only contracts could be made to work.

[Daniel-K-Ivanov]

Delegatable Contract Key
Some smart contracts may want to delegate control to a library contract. In order to allow this and preserve the default security of only permitting direct contract calls to the EVM a second contract key field delegatableContractKey will be added to the Key protobuf message. The requirement for authorization will be that only the CALLER of the call be the authorized contract ID. This will allow contracts to do a DELEGATECALL to the library and then the library (or any of the other sub-libraries it then DELEGATECALLs to) can CALL the precompile contract and have the authorization granted as though it was the origin of the current delegate call chain.

Good catch!

[Daniel-K-Ivanov]

ERC-20 calls directly to Token Accounts

I think that this should be a separate HIP and delivered after the first HTS precompile is delivered, same the NOTE you've added. 🙂

[shemnon]

Looking at the schedule I think it's safe to assume ERC-20 won't ship in the same release as the "big 5" operations. I'll open a new hip for ERC-20 and ERC-721, as well as getTokenInfo and getTokenNftInfo

[JaimeSilver]

Nice HIP.

1. Could we keep the composability with other Smart Contracts?
2. What about transfers of HBars to a contract, that then triggers the action to the HTS bridge? That will enable atomic swaps with extended logic.
3. Last, what about Transfers where a recipient account is a contract. Will that forward both Hbars and Tokens to be executed in HSCS?

[shemnon]

For I think HIP-218 (in draft here) may address your concerns.

For 2 and 3 I think that the ethereum analogue is ERC777TokensRecipient. tokensReceived(...)? We don't currently have a HIP covering such interfaces for triggers or callbacks. That may come in a to-be-written hip.

[H-Bart]

@shemnon does that entail that any kind of HTS token transfers to contracts will not be possible until this yet to be drafted HIP is implemented?

[H-Bart]

@shemnon on a somewhat unrelated note to my previous question what special variables currently exist in the global namespace and are planned in future? I couldn't find any details in this regard in the developer docs or HIPS but I'd imagine block would be renamed to event since that's the nomenclature used at Hedera.

In addition event.timestamp would be non-existent as an event's consensus timestamp is the median time as perceived by the supermajority of the network which is only computed after the event, however I'd imagine that the last round's events' timestamps can be used as an on-graph source of randomness unlike block.timestamp which can be easily influenced by even a single miner.

I'd also imagine that a number of block fields would also be non-existent such as chainid, coinbase, difficulty. And perhaps in the yet to be drafted HIP the special variable msg can be extended with a values field that lists all tokens(HBAR/HTS) transferred to a contract. I'd appreciate your insight in this regard.