fix: Update transaction validation logic in ethclient

[Leekyungun]

Description

This PR resolves an issue where blocks containing system transactions could not be retrieved properly using getBlock.
For such blocks, the transactionsRoot is set to EmptyTxsHash, but the Transactions list contains one transaction, which leads to a mismatch and prevents block information from being retrieved.
The validation logic has been updated to handle these cases correctly.
Example block with system transaction: https://amoy.polygonscan.com/block/16653120

Changes

• Bugfix (non-breaking change that solves an issue)
• Hotfix (change that solves an urgent issue, and requires immediate attention)
• New feature (non-breaking change that adds functionality)
• Breaking change (change that is not backwards-compatible and/or changes current functionality)
• Changes only for a subset of nodes

Breaking changes

No breaking changes have been introduced in this PR.

Nodes audience

This PR affects all nodes and does not include changes limited to a subset of nodes.

Checklist

• I have added at least 2 reviewer or the whole pos-v1 team
• I have added sufficient documentation in code
• I will be resolving comments - if any - by pushing each fix in a separate commit and linking the commit hash in the comment reply
• Created a task in Jira and informed the team for implementation in Erigon client (if applicable)
• Includes RPC methods changes, and the Notion documentation has been updated

Cross repository changes

• This PR requires changes to heimdall
  • In case link the PR here:
• This PR requires changes to matic-cli
  • In case link the PR here:

Testing

• I have added unit tests
• I have added tests to CI
• I have tested this code manually on local environment
• I have tested this code manually on remote devnet using express-cli
• I have tested this code manually on mumbai/amoy
• I have created new e2e tests into express-cli

Manual tests

1. Retrieved a block with system transactions (transactionsRoot as EmptyTxsHash but including Transactions).
2. Verified that block information is now retrieved correctly without validation errors.
3. Confirmed that other blocks without system transactions remain unaffected.

Additional comments

See the example block for context:
https://amoy.polygonscan.com/block/16653120

[manav2401]

Hi, thanks for raising this PR. The issues seems correct that it will happen when there's only 1 transaction which is a state-sync (system) transaction and nothing else.

But, IMO, we shouldn't get rid of the error. Let me see if there's some way to find out if it's a state-sync tx or not.

[manav2401]

Hi @Leekyungun, can you update the PR to handle this specific condition explicitly instead of removing this check?

Basically, system transactions are directly applied on state and hence the TxHash field in header is unaffected (EmptyTxsHash in this case). Can you add a check to match the to and from fields of the only transaction. If it's 0x00..00, then it's indeed a system transaction and we can skip this check in that case. If it's not, this check should be applied.

Also, could you raise the PR against develop branch instead? Lmk if you're upto do this. Thanks!

[Leekyungun]

Can you add a check to match the to and from fields of the only transaction. If it's 0x00..00, then it's indeed a system transaction and we can skip this check in that case.

Good idea!
I'll comment when the work is done.Thanks

[Leekyungun]

I've added exception handling and updated the target branch to develop.

Initially, I considered declaring the address "0x0000000000000000000000000000000000000000" as a constant and replacing its occurrences, but I was concerned that future updates in Ethereum might cause conflicts.
For now, I’ve made minimal modifications.

Please provide feedback.
@manav2401

[kamuikatsurgi]

Hey @Leekyungun, thanks for the PR, just small suggestions and would wait for final review from @manav2401 😄

[Leekyungun]

Thanks for the review, it seems like the code has improved because of it.
Please check it one more time.
@kamuikatsurgi

[kamuikatsurgi]

Thanks for the review, it seems like the code has improved because of it. Please check it one more time. @kamuikatsurgi

Hey, the PR looks good, wait for the final review from @manav2401 😄

[manav2401]

@Leekyungun thanks for updating the PR. I think it can be done in a simple way without introducing new functions.

if head.TxHash == types.EmptyTxsHash && len(body.Transactions) > 0 {
		tx := body.Transactions[0]
		zeroAddress := common.HexToAddress("0x0000000000000000000000000000000000000000")
		if *tx.From != zeroAddress || *tx.tx.To() != zeroAddress {
			return nil, errors.New("server returned non-empty transaction list but block header indicates no transactions")
		}
	}

Moreover, you can define zeroAddress in bor_ethclient.go as a public variable as it's bor specific.

Also, to answer your question, state sync transactions are always added at the end and there's exactly one of them. You can assume this for your implementation. Thanks.

[Leekyungun]

        if head.TxHash == types.EmptyTxsHash && len(body.Transactions) > 0 {
		tx := body.Transactions[0]
		zeroAddress := common.HexToAddress("0x0000000000000000000000000000000000000000")
                 if (tx.From != nil && *tx.From != zeroAddress) || (tx.tx.To() != nil && *tx.tx.To() != zeroAddress) {
			return nil, errors.New("server returned non-empty transaction list but block header indicates no transactions")
		}
	}

Just to be safe, if tx.From and tx.tx.To() are both nil, it would cause a panic. How about adding a nil check?
@manav2401

[manav2401]

@Leekyungun it works. thanks!

[Leekyungun]

I updated the implementation.
Finally, I defined a Sync Transaction as a case where either from or to is zeroAddress.
Can you verify if it should check for both being zeroAddress instead?

Thank you!
@manav2401

[manav2401]

@Leekyungun current logic is fine. Few minor nits and then it's good to go.

[Leekyungun]

Completed!
Please review it.
@manav2401

[manav2401]

hey @Leekyungun I messed something up locally and accidentally force pushed something to your branch. Can you create a fresh PR the changes required.

Also, while you're at it, you can do the change I did here. Apologies for this. Thanks!

[Leekyungun]

It's OK!
This is new PR: #1435
Rather, the commits are cleaner and better.

Please review it
@manav2401 @kamuikatsurgi