Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HIP-1056 Account BlockItem to RecordItem transformers #10249

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

HarshSawarkar
Copy link
Contributor

@HarshSawarkar HarshSawarkar commented Jan 27, 2025

Description:

Added tranformers for CryptoAddLiveHash, CryptoDeleteAllowance, CryptoDeleteLiveHash

Related issue(s):

Fixes #10164

Notes for reviewer:

Checklist

  • Documented (Code comments, README, etc.)
  • Tested (unit, integration, etc.)

@steven-sheehy steven-sheehy changed the title Chore:Account BlockItem to RecordItem transformers HIP-1056 Account BlockItem to RecordItem transformers Jan 27, 2025
@steven-sheehy steven-sheehy added the enhancement Type: New feature label Jan 27, 2025
@steven-sheehy steven-sheehy added this to the 0.123.0 milestone Jan 27, 2025
@edwin-greene
Copy link
Contributor

Thanks for contributing. There are tests that need to be added, you can find example test cases in BlockFileTransformerTest

@HarshSawarkar
Copy link
Contributor Author

HarshSawarkar commented Jan 29, 2025

Thanks for contributing. There are tests that need to be added, you can find example test cases in BlockFileTransformerTest

@edwin-greene Sure! I will update the tests for all the account transformers. In the meantime, could you please review the transformer classes and suggest any necessary changes?

…into chore-HIP-1056-Account-BlockItem-to-RecordItem-transformers
…into chore-HIP-1056-Account-BlockItem-to-RecordItem-transformers
Signed-off-by: Harsh Sawarkar <[email protected]>
for (var stateChange : stateChanges.getStateChangesList()) {
if (stateChange.getStateId() == STATE_ID_ACCOUNTS.getNumber() && stateChange.hasMapUpdate()) {
var value = stateChange.getMapUpdate().getValue();
if (value.hasAccountIdValue()) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The key issue here is any account with state changes will be here, with exact same state id, change case, key case, and value case.

It's very common for any transaction having at least the following account map update in state changes

  • node account id
  • fee collector account id, 0.0.98
  • staking reward account 0.0.800
  • node reward account 0.0.801

There isn't a way for us to confidently identify the new account. Using the key in the transaction body can work in most cases however the network allows many accounts to use the same key so it's not a 100% reliable method.

We may have to ask for a change to add the new account id to CreateAccountOutput

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@edwin-greene Please chase this down with the relevant teams

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that this is a miss in the protobuf definitions.
Suggested resolution:

  1. CreateAccountOutput should be added to TransactionOutput
  2. The created AccountID should be added to CreateAccountOutput
  3. The Account ID newly assigned for any account that is created (via CryptoCreate, EVM CREATE2, or similar) should be recorded in the CreateAccountOutput.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be complete.
This is, I believe, specific to account. In most cases the state changes (which immediately follow the triggering transaction) are more than sufficient to identify the created entity.

Unfortunately, as noted above, Account state changes follow every transaction, and it is unusually difficult to separate the create from other account updates; particularly if an account is created as a result of an EVM transaction.

Comment on lines 29 to 49
@Override
protected void updateTransactionRecord(BlockItem blockItem, TransactionRecord.Builder transactionRecordBuilder) {
if (blockItem.transactionResult().getStatus() != SUCCESS) {
return;
}

for (var stateChanges : blockItem.stateChanges()) {
for (var stateChange : stateChanges.getStateChangesList()) {
if (stateChange.getStateId() == STATE_ID_ACCOUNTS.getNumber() && stateChange.hasMapUpdate()) {
var value = stateChange.getMapUpdate().getValue();
if (value.hasAccountValue()) {
var accountDelete = value.getAccountValue();
if (accountDelete.getDeleted()) {
transactionRecordBuilder.getReceiptBuilder().setAccountID(accountDelete.getAccountId());
return;
}
}
}
}
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

receipt.account_id shouldn't be set for crypto delete transaction

Suggested change
@Override
protected void updateTransactionRecord(BlockItem blockItem, TransactionRecord.Builder transactionRecordBuilder) {
if (blockItem.transactionResult().getStatus() != SUCCESS) {
return;
}
for (var stateChanges : blockItem.stateChanges()) {
for (var stateChange : stateChanges.getStateChangesList()) {
if (stateChange.getStateId() == STATE_ID_ACCOUNTS.getNumber() && stateChange.hasMapUpdate()) {
var value = stateChange.getMapUpdate().getValue();
if (value.hasAccountValue()) {
var accountDelete = value.getAccountValue();
if (accountDelete.getDeleted()) {
transactionRecordBuilder.getReceiptBuilder().setAccountID(accountDelete.getAccountId());
return;
}
}
}
}
}
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated

Comment on lines 33 to 38
if (stateChange.getStateId() == STATE_ID_ACCOUNTS.getNumber() && stateChange.hasMapUpdate()) {
var value = stateChange.getMapUpdate().getValue();
if (value.hasAccountIdValue()) {
transactionRecordBuilder.getReceiptBuilder().setAccountID(value.getAccountIdValue());
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

weird enough, receipt.account_id for crypto update transaction is set in record stream files.

again, the logic shares the same problem in the comment for crypto create transaction.

Think we can choose not to set it at all, or set it to the value from crypto update transaction body

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Temporarily removing the updateTransactionRecord method until we identify a better solution.

Signed-off-by: Harsh Sawarkar <[email protected]>
Copy link

codecov bot commented Jan 31, 2025

Codecov Report

Attention: Patch coverage is 46.66667% with 16 lines in your changes missing coverage. Please review.

Project coverage is 92.28%. Comparing base (d61c0e4) to head (2df4bfe).
Report is 4 commits behind head on main.

Files with missing lines Patch % Lines
...der/block/transformer/CryptoCreateTransformer.java 11.11% 16 Missing ⚠️
Additional details and impacted files
@@             Coverage Diff              @@
##               main   #10249      +/-   ##
============================================
- Coverage     92.33%   92.28%   -0.06%     
- Complexity     7841     7855      +14     
============================================
  Files           954      961       +7     
  Lines         32952    32984      +32     
  Branches       4158     4163       +5     
============================================
+ Hits          30425    30438      +13     
- Misses         1548     1565      +17     
- Partials        979      981       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

…into chore-HIP-1056-Account-BlockItem-to-RecordItem-transformers
@HarshSawarkar HarshSawarkar marked this pull request as ready for review January 31, 2025 15:18
@HarshSawarkar HarshSawarkar requested a review from a team as a code owner January 31, 2025 15:18

@Override
protected void updateTransactionRecord(BlockItem blockItem, TransactionRecord.Builder transactionRecordBuilder) {
if (blockItem.transactionResult().getStatus() != SUCCESS) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We'll want to update this with the new blockItem.successful() method from #10248 once it's merged.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will update it once the PR is merged.

for (var stateChange : stateChanges.getStateChangesList()) {
if (stateChange.getStateId() == STATE_ID_ACCOUNTS.getNumber() && stateChange.hasMapUpdate()) {
var value = stateChange.getMapUpdate().getValue();
if (value.hasAccountIdValue()) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@edwin-greene Please chase this down with the relevant teams

…into chore-HIP-1056-Account-BlockItem-to-RecordItem-transformers
Signed-off-by: Harsh Sawarkar <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Type: New feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

HIP-1056 Account BlockItem to RecordItem transformers
5 participants