refactor: replace builders with evm

[alfonsobries]

Summary

https://app.clickup.com/t/86duz94j3

Tester script https://github.com/ArdentHQ/sdk-tester-scripts/pull/4

Things to keep in mind when reviewing this PR:

1. Removed all transaction builders, keeping only the EVM builder. This builder contains all necessary methods, so the abstract builder is no longer needed.
2. The same applies to transaction types. Now, there is only one class called Transaction (formerly EVMcall), which no longer extends other contracts.
3. Removed tests that are no longer applicable, along with their fixtures.
4. Similarly, the serializer and deserializer are no longer "dynamic" in the sense of instantiating different transaction types.
5. For compatibility with the JavaScript version, the serialization still includes the vendor field length (which is currently ignored). If this is removed in the future, this package will need an update.
6. For now, I am also keeping the enums for type, typeGroup, and fees. However, I understand that type and typeGroup will be removed, and this can be updated accordingly.
7. Regarding fees, I am not sure if it will still be necessary to have a default fee for each transaction type. It might be better as a separate helper, like Fee::forTransfer(), or it could be documented that only the enum should be used.

Checklist

• Documentation (if necessary)
• Tests (if necessary)
• Ready to be merged

[alfonsobries]

@ItsANameToo for now updated the docs consider the changes of this PR https://github.com/ArdentHQ/docs-poc-protocol/pull/72

[ItsANameToo]

EVM fees will be based on network usage, similar to ethereum. In that case we will need a method to define a given fee, and the client (most likely) should get a method to retrieve network based fees (slow/avg/fast) that can then be passed to the crypto library after the user selects one of them

[ItsANameToo]

let's discuss this part, as the payload is what decides the underlying logic that the transaction will apply.

The way this currently works is that the user has to create the payload, then pass the payload to the builder to get it executed on chain. Although that works, it means that the user first has to figure out the required payload and construct it manually, while that should be the job of the SDK (to make it easier for the user to work with the network).

Therefore I'd suggest that we still add transaction builders, but underneath they all make use of the EVM call transaction type. The builders will however make it easier to pass the usual parameters for each of the supported transaction "types". For example:

• transfer: here you'd call ->amount() and ->recipient() on to set these in addition to the payload (which is empty for a transfer)
• vote: this would have a parameter to define the vote/unvote/swap vote. All the payload logic would be handled internally as those things are known to use (recipient contract, abi, function name, args)
• other types (later, but similar idea)

The builders would also keep their usual methods ( ->nonce(), etc) but having these abstractions will make it easier for the user to work with the evm calls without having to construct raw payloads. Of course they can still provide raw payloads by using the EVM Call builder directly and passing it through the ->payload() method whenever they need to make a call to a contract that's not one of ours.

I think this will make the SDK easier to work with as all the contracts that we deploy and know about can be included without putting the burden on the user to figure out the right method and contract address to use.

[alfonsobries]

@ItsANameToo updated