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

Add new fields for externalizing account alias #242

Merged
merged 10 commits into from
Nov 23, 2022

Conversation

MiroslavGatsanoga
Copy link
Contributor

@MiroslavGatsanoga MiroslavGatsanoga commented Nov 10, 2022

Signed-off-by: Miroslav Gatsanoga [email protected]

Description:
Creating accounts with EC keys can result in an EVM public address alias being tracked by the consensus nodes. This account identifier should be externalized so that mirror nodes have that information.

  • Add AccountID.evm_address
  • Add VirtualAddress message object to capture an evm_address and its default status
  • Add CryptoCreateTransactionBody.evm_address
  • Add CryptoGetInfoResponse.virtual_addresses list
  • Add CryptoUpdateTransactionBody.virtual_address_update
  • Add TransactionRecord.evm_address

Related issue(s):

Signed-off-by: Miroslav Gatsanoga <[email protected]>
Copy link
Contributor

@Nana-EC Nana-EC left a comment

Choose a reason for hiding this comment

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

Initial thoughts reflecting so recent updates

services/crypto_get_info.proto Outdated Show resolved Hide resolved
services/crypto_get_info.proto Outdated Show resolved Hide resolved
services/transaction_record.proto Outdated Show resolved Hide resolved
services/transaction_record.proto Outdated Show resolved Hide resolved
Co-authored-by: Nana Essilfie-Conduah <[email protected]>
Signed-off-by: Miroslav Gatsanoga <[email protected]>
MiroslavGatsanoga and others added 2 commits November 15, 2022 13:26
Signed-off-by: Miroslav Gatsanoga <[email protected]>

Co-authored-by: Nana Essilfie-Conduah <[email protected]>
@@ -110,6 +110,7 @@ message AccountID {
*/
bytes alias = 4;

bytes evmAddress = 5;
Copy link
Contributor

Choose a reason for hiding this comment

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

We've been using "snake-case" now---so evm_address, is_default_address, etc.

Copy link
Contributor

Choose a reason for hiding this comment

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

Renamed

@@ -31,6 +31,7 @@ import "custom_fees.proto";
import "transaction_receipt.proto";
import "crypto_transfer.proto";
import "contract_call_local.proto";
import "crypto_get_info.proto";
Copy link
Contributor

Choose a reason for hiding this comment

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

Unneeded import.

Copy link
Contributor

Choose a reason for hiding this comment

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

Removed

@@ -29,6 +29,7 @@ import "basic_types.proto";
import "duration.proto";
import "timestamp.proto";
import "google/protobuf/wrappers.proto";
import "transaction_record.proto";
Copy link
Contributor

@tinker-michaelj tinker-michaelj Nov 16, 2022

Choose a reason for hiding this comment

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

⚠️ Unneeded, and causes circular import:

[ERROR] /Users/michaeltinker/Dev/hedera-protobufs-java/src/main/proto/freeze_service.proto [0:0]: query_header.proto:28:1: File recursively imports itself: query_header.proto -> transaction.proto -> transaction_body.proto -> crypto_update.proto -> transaction_record.proto -> contract_call_local.proto -> query_header.proto

Copy link
Contributor

Choose a reason for hiding this comment

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

Removed

Copy link
Contributor

@tinker-michaelj tinker-michaelj left a comment

Choose a reason for hiding this comment

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

Just realized there are some unneeded imports causing circular imports.

Signed-off-by: Dimitar Dinev <[email protected]>
Comment on lines 148 to 152

/**
* Virtual address update info, if virtual address is specified in the CryptoUpdate transaction. At most one update can be performed at a time.
*/
VirtualAddressUpdate virtual_address_update = 21;
Copy link
Contributor

Choose a reason for hiding this comment

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

Won't VirtualAddress be sufficient here?'

Оnly CryptoUpdate can remove virtual addresses, and it has the intended VirtualAddressUpdate in the transaction body. Therefore, if the CryptoUpdate is successful, mirror node can get the needed virtual address update info from the transaction body, and we won't have to duplicate it in the record, correct?

And in all other transactions with virtual address info in the record, we won't be removing the address, but adding it/updating nonce, so the remove field of VirtualAddressUpdate won't be needed -> we can directly use VirtualAddress here.

Copy link
Contributor

Choose a reason for hiding this comment

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

Good point.
I like the simplification

Copy link
Contributor

Choose a reason for hiding this comment

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

The VirtualAddressUpdate field can be used in a couple of situations:

  1. When we're initially creating an account. In a couple of use cases, we need to externalize the evmAddress that is calculated on the consensus node side, but a simple bytes calculated_evm_address field will be sufficient. The nonce value is always 0.
  2. When we're updating an account and adding/removing virtual addresses from this account. In this case, the mirror nodes can extract this information from the transaction body and we don't need to write it in the records.

Conclusion: it looks like we can remove the VirtualAddressUpdate field and add bytes calculated_evm_address instead. @steven-sheehy @Nana-EC wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

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

If we maintain the nonce exposure for the account then simplifying to VirtualAddress would be right.
If we say we don't care and aren't concerned with capturing nonce for ContractCall/ContractCreate cases then sure just capturing the evmAddress is fine as calculated_evm_address.

Btw, why calculated_evm_address vs just evm_address or account_evm_address

Copy link
Contributor

Choose a reason for hiding this comment

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

Just evm_address is fine

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.

/**
* Flag if this address is being removed. If false, the virtual address is being added.
*/
google.protobuf.BoolValue removed = 2;
Copy link
Contributor

Choose a reason for hiding this comment

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

what if removed is not set?

Copy link
Contributor

Choose a reason for hiding this comment

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

Currently this is for the case where the accounts nonce was incremented and is being exposed in the record stream for mirror node consumption

services/basic_types.proto Show resolved Hide resolved
services/basic_types.proto Outdated Show resolved Hide resolved
services/basic_types.proto Outdated Show resolved Hide resolved
services/basic_types.proto Outdated Show resolved Hide resolved
Copy link
Contributor

@shemnon shemnon left a comment

Choose a reason for hiding this comment

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

Outside of the comments other reviewers have requested LGTM, so I'll defer my approvals to them.

Signed-off-by: Miroslav Gatsanoga <[email protected]>
Signed-off-by: Miroslav Gatsanoga <[email protected]>
@MiroslavGatsanoga MiroslavGatsanoga removed the request for review from kimbor November 22, 2022 15:38
Nana-EC
Nana-EC previously approved these changes Nov 22, 2022
Copy link
Contributor

@Nana-EC Nana-EC left a comment

Choose a reason for hiding this comment

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

Looks good. Just had some comment suggestions to make it explicit where the evm address had to be the keccak-256 hash of a ECDSA_SECP256K1 primitive key

services/basic_types.proto Outdated Show resolved Hide resolved
services/basic_types.proto Outdated Show resolved Hide resolved
services/crypto_create.proto Outdated Show resolved Hide resolved
steven-sheehy
steven-sheehy previously approved these changes Nov 22, 2022
Copy link
Contributor

@tinker-michaelj tinker-michaelj left a comment

Choose a reason for hiding this comment

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

Makes sense to me! 👍

Signed-off-by: Miroslav Gatsanoga <[email protected]>
Copy link
Contributor

@Nana-EC Nana-EC left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@tinker-michaelj tinker-michaelj left a comment

Choose a reason for hiding this comment

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

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

Add new fields for externalizing account alias
8 participants