Optimize address parsing of stake-related interfaces

[CarlChaoCarl]

Rationale

TransactionLog combined with EventPlugin mechanism is an important way to analyze transaction data.

At present, it is found that when calling the query transaction interface of the tron-eventquery service,
one of the transaction's fields returned is as follows:

{"contractType": "UnDelegateResourceContract","fromAddress": null,"toAddress": null}

To the transaction type: UnDelegateResourceContract, the returned fields: fromAddress, toAddress are not correctly assigned.

Below are the stake-related transactions include:

• UnfreezeBalanceContract
• FreezeBalanceV2Contract
• UnfreezeBalanceV2Contract
• WithdrawExpireUnfreezeContract
• DelegateResourceContract
• UnDelegateResourceContract
• CancelAllUnfreezeV2Contract

The fromAddress and toAddress should be correctly parsed into the TransactionLog, and then the fields will be correct when the query transaction of the tron-eventquery service is called.

Why should this feature exist?

Before writing the new transaction into the transactionLog, the address needs to be parsed correctly

Implementation

For the new transactions, to correctly parse fromAddress and toAddress to TransactionLog, the following code must be modified: class TransactionLogTriggerCapsule, method TransactionLogTriggerCapsule

public TransactionLogTriggerCapsule(TransactionCapsule trxCapsule, BlockCapsule blockCapsule,
       int txIndex, long preCumulativeEnergyUsed, long preCumulativeLogCount,
       TransactionInfo transactionInfo, long energyUnitPrice) {
           case UnfreezeBalanceContract:
               ...
           break;
           case FreezeBalanceV2Contract:
                …
           break;
           case UnfreezeBalanceV2Contract:
                …
           break;
           case WithdrawExpireUnfreezeContract:
                …
           break;
           case DelegateResourceContract:
                …
           break;
           case UnDelegateResourceContract:
                …
           break;
           case CancelAllUnfreezeV2Contract:
                …
           break;
}

In this way, for the newly added transactions, fromAddress and toAddress are able to be correctly parsed and then assigned to TransactionLogTrigger.

Furthermore, for the TransactionLog's message event, an "extMap" field has been added, originally designed as a general extension field.Currently, this field is only assigned a value for transaction logs of the "CancelAllUnfreezeV2Contract" type; other transactions do not receive a value.For "CancelAllUnfreezeV2Contract" type transactions, it represents the amount of resources (bandwidth energy) canceled by the operation of canceling "UnfreezeV2" type transactions.

[lxcmyf]

I understand that UnfreezeBalanceContract is still open to the public, and perhaps this transaction type needs to be added to the TransactionLogTrigger as well.

[CarlChaoCarl]

I understand that UnfreezeBalanceContract is still open to the public, and perhaps this transaction type needs to be added to the TransactionLogTrigger as well.

@lxcmyf
OK, good addition, I will add this transaction type

[endiaoekoe]

does the signature of the function TransactionLogTriggerCapsule will change after introducing new Stake APIs？ if so,how to corp with this situation？

[CarlChaoCarl]

does the signature of the function TransactionLogTriggerCapsule will change after introducing new Stake APIs？ if so,how to corp with this situation？

I understand that the signature will not change, because the parameter return value of the constructor has not changed, but the support logic for the new transaction type has been added. If you have any questions, please add

@mikeluxue

[tomatoishealthy]

You can associate this issue with your PR if there is one.

[CarlChaoCarl]

You can associate this issue with your PR if there is one.

The link of PR is as follows: #5419

@tomatoishealthy

[lxcmyf]

I understand that UnfreezeBalanceContract is still open to the public, and perhaps this transaction type needs to be added to the TransactionLogTrigger as well.

@CarlChaoCarl I found out that this is still missing.

[CarlChaoCarl]

I understand that UnfreezeBalanceContract is still open to the public, and perhaps this transaction type needs to be added to the TransactionLogTrigger as well.

@CarlChaoCarl I found out that this is still missing.

OK, just updated. @lxcmyf

[ferdinand026]

How about vote and withdraw reward types of transaction? Does the same issue exist?

[CarlChaoCarl]

How about vote and withdraw reward types of transaction? Does the same issue exist?

@ferdinand026
According to our discussion, transaction data for voting and reward extraction types, we currently do not need to analyze or subscribe to. If you have specific requirements, you can request them separately.