feat: Add EIP-7702 authorization list support to Transaction

[Filter94]

What does this PR do?

This PR adds support for 7702 transactions returned from various ETH API methods, like eth_getBlockByX, eth_getTransactionByX

Where should the reviewer start?

ResponseTest.java‎
Or
EthBlock.java

Why is it needed?

Because otherwise it's impossible to get valid deserialized 7702 transactions from an Ethereum node with Web3j

Checklist

• I've read the contribution guidelines.
• I've added tests (if applicable).
• I've added a changelog entry if necessary.

[Copilot]

Pull request overview

This PR adds support for EIP-7702 authorization lists to the Transaction class, enabling Web3j to handle the new transaction type introduced by EIP-7702. The implementation includes a new AuthorizationTuple class to represent authorization list entries and updates to the Transaction class to include an optional authorization list field.

Key changes:

• Introduced AuthorizationTuple class with fields for chainId, address, nonce, yParity, r, and s
• Added authorizationList field to Transaction class with getter/setter methods
• Updated Transaction and EthBlock.TransactionObject constructors to support the new field while maintaining backward compatibility
• Added comprehensive test coverage for transactions with authorization lists

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
AuthorizationTuple.java	New class representing EIP-7702 authorization tuple with proper equality, hashCode, and getter/setter methods
AuthorizationListTest.java	Test coverage for AuthorizationTuple equality and getter methods
TransactionTest.java	Test coverage for Transaction equality with authorization lists
Transaction.java	Added authorizationList field, updated constructors to delegate to the main constructor, and updated equals/hashCode methods
EthBlock.java	Added new TransactionObject constructor accepting authorizationList and updated existing constructors to pass null for new fields
ResponseTest.java	Added tests for deserializing transactions with authorization lists from JSON responses
Contract.java	Minor formatting improvements (line wrapping)

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The new TransactionObject constructor that accepts authorizationList (lines 790-840) lacks test coverage. Consider adding a test similar to testEthBlockFullTransactionsWithBlob that includes transactions with authorization lists to ensure proper deserialization from JSON responses.

[gtebrean]

@Filter94 the support for this was already added with #2178, most of the transactions EIPs were created as separated objects. Could you please try to see if what we have now is working for you?

[Filter94]

@gtebrean So it means that with the current latest version of Web3j I can fetch and deserialize a complete 7702 transaction from the chain, right? And if that's the case, org.web3j.protocol.core.methods.response.Transaction should have some field for the authorization list

Can you please point me where this field is in the existing codebase? You should be able to easily check this using a 7702 transaction sample and the ResponseTest

[gtebrean]

@Filter94, now I get it, the 7702 transaction from now can be included in the reponse of those rpcs and that's why Transaction has to be update because else will just increase complexity of the code by managing the custom class there.

Please update the pr with the autorization tuple from crypto module (is already referenced in this module) and I will merge it, also update the changelog too. Will be included in the next release

[Filter94]

@gtebrean I think what you're asking implies a deeper refactoring. Right now org.web3j.protocol.core.methods.response.EthBlock, TransactionObject are just intermediate objects that contain deserialized data (plain String-s) and aren't meant to be used in any business logic. Classes in Crypto modules are more like domain objects. They contain properly typed data and more suited for sophisticated logic

If we use the existing AuthorizationTuple in TransactionObject

1. it won't be uniform, because the rest of the data stored in TransactionObject are just String-s
2. We'd have to set Jackson annotations in the domain model class, org.web3j.crypto.AuthorizationTuple. It would mix 2 different responsibilities in org.web3j.crypto.AuthorizationTuple, which violates single responsibility principle
3. Core would need to depend on Crypto module, which violates the principles of clean architecture. That's the case already, but I don't want to advance this repo further on this path. But maybe I just misunderstand the idea behind web3j architecture