HIP-993: Improve record stream legibility and extensibility

[tinker-michaelj]

This idea aggregates several small changes that each improve the legibility of the record stream, or make it more extensible in preparation for future versions of the node software.

1. Itemize auto-creation fees in the preceding CryptoCreate stream item.
2. Hide synthetic consensus times from child transaction handlers.
3. Set a CONSENSUS_GAS_EXHAUSTED status in the first child transaction that is throttled inside a contract operation.
4. Omit unused fields from the synthetic ContractUpdate finalizing a hollow account as a contract.
5. At genesis in pre-prod environments, externalize the contents of the initial system files in synthetic FileCreate operations.

1️⃣ At present, when the network automatically creates an account as a side effect of a CryptoTransfer sending assets to an unused account alias, it "squashes" the fees for the implicit CryptoCreate into the record of the CryptoTransfer instead of being itemized in the preceding auto-creation record.

For example, take this CryptoTransfer from HashScan. Its transactionFee is given as $0.0474, even though $0.0473 of that amount was actually charged for the work done in the preceding child here.

We propose the network instead itemize the auto-creation fees in the preceding child record. That is, instead of externalizing the two record excerpts below,

*** <<<Current preceding child>>> ***
receipt {
  status: SUCCESS
  accountID {
    accountNum: 6134246
  }
}
...
transactionID {
...
  nonce: 1
}
memo: "auto-created account"
transactionFee: 54047391
transferList {
}

*** <<<Current following parent>>> ***
receipt {
  status: SUCCESS
...
}
...
transactionFee: 54162549
transferList {
  accountAmounts {
    accountID {
      accountNum: 8
    }
    amount: 4664
  }
  accountAmounts {
    accountID {
      accountNum: 98
    }
    amount: 48742097
  }
  accountAmounts {
    accountID {
      accountNum: 800
    }
    amount: 5415788
  }
  accountAmounts {
    accountID {
      accountNum: 3929606
    }
    amount: -55162549
  }
  accountAmounts {
    accountID {
      accountNum: 6134246
    }
    amount: 1000000
  }
}

The network should externalize,

*** <<<Proposed preceding child>>> ***
receipt {
  status: SUCCESS
  accountID {
    accountNum: 6134246
  }
}
...
transactionID {
...
  nonce: 1
}
memo: "auto-created account"
transactionFee: 54047391
transferList {
  accountAmounts {
    accountID {
      accountNum: 98
    }
    amount: 48642652
  }
  accountAmounts {
    accountID {
      accountNum: 800
    }
    amount: 5404739
  }
  accountAmounts {
    accountID {
      accountNum: 3929606
    }
    amount: -54047391
  }
}

*** <<<Proposed following parent>>> ***
receipt {
  status: SUCCESS
...
}
...
transactionFee: 115158
transferList {
  accountAmounts {
    accountID {
      accountNum: 8
    }
    amount: 4664
  }
  accountAmounts {
    accountID {
      accountNum: 98
    }
    amount: 99445
  }
  accountAmounts {
    accountID {
      accountNum: 800
    }
    amount: 11049
  }
  accountAmounts {
    accountID {
      accountNum: 3929606
    }
    amount: -1115158
  }
  accountAmounts {
    accountID {
      accountNum: 6134246
    }
    amount: 1000000
  }
}

2️⃣ At present, when a child transaction is dispatched inside a contract operation, a synthetic consensus time "planned" for the child transaction is exposed to the logic handling the dispatch. This has no visible effect for any type of child transaction except a non-fungible TokenMint. In this case, an NFT minted by the child transaction will have its creation_time set to the synthetic time of the child dispatch instead of the consensus time of its parent contract operation.

There is no value or significance in using a consensus time different from the parent operation, and leaking a "planned" synthetic consensus time makes it much more complicated to defer the final choice until the end of the transaction (which is a much more flexible approach that would remove artificial limits on the number of child transactions).

We propose that NFTs minted by child TokenMint transactions now have as creation_time the consensus time of their parent contract operation.

3️⃣ At present, if a contract operation dispatches more child transactions than are allowed by the network throttles, it will run to completion before being rolled back with a CONSENUS_GAS_EXHAUSTED failure code. There is no benefit to this approach, as it does work that will not be committed to state; and can make the reason for the failure less obvious.

We propose that child transactions are throttled at the point of dispatch, and the first throttled transaction fail with a CONSENSUS_GAS_EXHAUSTED status.

4️⃣ At present, the synthetic ContractUpdate externalized when a hollow account is finalized as a contract via collision with a CREATE1 or CREATE2 address has fields set that imply it inherits properties such as auto-renew account from the sender address. This does not actually happen, so the synthetic transaction is misleading.

We propose removing these unused fields.

5️⃣ At present, when a pre-prod environment starts a network from genesis, any mirror node in that environment will not automatically get the contents of the initial system files (0.0.101, 0.0.102, 0.0.111, 0.0.112, 0.0.121, 0.0.122, 0.0.123). This is in contrast to the initial system accounts, which are externalized via synthetic CryptoCreate transactions added as preceding children of the first handled user transaction.

We propose to externalize the initial system files as additional preceding children with synthetic FileCreate transactions.

[Neurone]

Hi @tinker-michaelj , overall the HIP-993 looks good to me.

I have some of doubts about features #2 (Unified child consensus times) and # 6 (Use natural order for preceding dispatch records).

In general, do those updates change the values on the record files?

In particular, does #2 imply changes in the consensusTimestamp or parentConsensusTimestamp fields and their values I can read in the record file? I don't see any creation_time at that level, so I'm unsure if #2 is a service or mirror node feature.

Also, does # 6 imply changes in field values (the nonce), or is it just a reordering in how we write information in record files without real impact on fields and values?

Can you clarify in the HIP the systems/components (consensus nodes, mirror nodes, explorers, etc.) impacted by each of the six proposed changes?

[Neurone]

@mgarbs asked to continue the conversation in the first PR for the HIP, so copied questions there: #993 (comment)