This is achieved by using ExpanderEntryPoint which uses fallback() in order to accept calldata bytes directly. This is superior to a function that takes a bytes argument, because the solidity ABI adds a surprising amount of stuff to encode that:
4 bytes for a method ID
32 bytes for the calldata offset location of the bytes argument
32 bytes for the length of the bytes argument
0-31 bytes padding at the end to ensure the calldata length is a multiple of 32
By using fallback(), we just accept the raw calldata directly. No method ID necessary. There is no calldata offset because we just get the full calldata unmodified. The length doesn't need to be encoded because there's an EVM instruction to get the calldata length. And the padding simply isn't needed.
How can these changes be manually tested?
(Replicating this test isn't required.)
Register the source BLS key and address and destination address, and do an ETH transfer. View the calldata in the block explorer (or otherwise) and confirm it's under 100 bytes.
Does this PR resolve or contribute to any issues?
Resolves #589.
Checklist
[x] I have manually tested these changes
[x] Post a link to the PR in the group chat
Guidelines
If your PR is not ready, mark it as a draft
The resolve conversation button is for reviewers, not authors
Dependent PR
This PR depends on https://github.com/web3well/bls-wallet/pull/584.
After that's merged, toggle the target branch back and forth or push an empty commit to fix the diff. (Preview of this PR's changes.)
What is this PR doing?
Before:
Explorer link
After:
Explorer link
This is achieved by using
ExpanderEntryPoint
which usesfallback()
in order to accept calldata bytes directly. This is superior to a function that takes abytes
argument, because the solidity ABI adds a surprising amount of stuff to encode that:bytes
argumentbytes
argumentBy using
fallback()
, we just accept the raw calldata directly. No method ID necessary. There is no calldata offset because we just get the full calldata unmodified. The length doesn't need to be encoded because there's an EVM instruction to get the calldata length. And the padding simply isn't needed.How can these changes be manually tested?
(Replicating this test isn't required.)
Register the source BLS key and address and destination address, and do an ETH transfer. View the calldata in the block explorer (or otherwise) and confirm it's under 100 bytes.
Does this PR resolve or contribute to any issues?
Resolves #589.
Checklist
Guidelines
resolve conversation
button is for reviewers, not authors