HIP-1313: Enable a new high volume entity creation option

[jsync-swirlds]

This new option allows a system submitting a transaction that creates a new entity to use a high volume throttle at a potentially increased cost, based on the overall entity creation rate for the network.

• Added new hip document with HIP number 1313.

[kpachhai]

Under the section "How to Teach This", I see we are showing how someone would opt in to the "priority lane" using the SDK but how would one opt in from the EVM side using smart contracts? The HIP mentions the following 3 transactions would also be eligible to take this "priority lane":

1. EthereumTransaction
2. ContractCreate
3. ContractCall

However, how would someone explicitly be able to use the priority lane from the smart contract side? or is that only possible by the JSON RPC Relay itself?

[EMerchant90]

Good to see that this keeps fairness with ordering remaining FIFO and paying more only grants access to additional capacity and not priority within the lane.

Noticed that this was updated to address HAPI transactions and I think this was a solid pivot.

LGTM!

[ty-swirldslabs]

Under the section "How to Teach This", I see we are showing how someone would opt in to the "priority lane" using the SDK but how would one opt in from the EVM side using smart contracts? The HIP mentions the following 3 transactions would also be eligible to take this "priority lane":

1. EthereumTransaction
2. ContractCreate
3. ContractCall

However, how would someone explicitly be able to use the priority lane from the smart contract side? or is that only possible by the JSON RPC Relay itself?

We reduced scope to only HAPI transactions, so this is a good question but will be addressed in a future HIP

[akdev]

One question, which may be outside the scope of this HIP, is whether the fee multiplier will be included as part of the transaction fee data in the block stream.

[jsync-swirlds]

One question, which may be outside the scope of this HIP, is whether the fee multiplier will be included as part of the transaction fee data in the block stream.

I believe whether to include the multiplier in the record stream can be determined during implementation (I would recommend including it, if not too difficult).
The effective multiplier can, or should, be calculable from data already in the block stream; but it might be appropriate to add the multiplier directly to the block stream transaction result entry as well.