Transfer-and-Call, Transfer-Multi-and-Call, Get-Call-Data and other enhancements

[IaroslavMazur]

feat: implement contract to test transfer-and-call functionality
feat: infra for testing transfer-multi-and-call
feat: Get Call Data functionality

fix: send MNTs to a single address, instead of many
fix: make the MNTs sender implicit (i.e. the msg.sender)
fix: transfer and call
fix: make NativeTokens::balanceOf() callable by both EOAs and Smart Contracts

test: NaiveTokenTransferrerMock

refactor: make the token transfer sender (i.e. address(this)) implicit
refactor: restrict the burning ability to just the token holders
refactor: change the signature of INativeTokens::burn()
refactor: change the type of sub id and token id to uint256
refactor: remove the unused code

chore: format the code in the repo
chore: work around the forge fmt <-> bun solhint max-line conflict

[IaroslavMazur]

@PaulRBerg, curiously enough, there seems to be an issue with the "max line length" parameter of forge's formatter, in which the maximum acceptable length for a code line is considered to be N+1, instead of the N you've submitted as line_length in the [fmt] section of foundry.toml 🤔

Because of the above, the "same" max line limit for forge's and solhint's formatter was, actually, off by one - and was generating an error during the execution of the lint job in CI.

I've worked around this by configuring the forge fmt's line_length to 119.

[PaulRBerg]

@IaroslavMazur that's a known issue with the Forge formatter:

foundry-rs/foundry#4450

Rather than lowering the formatter's line length to 119, we should instead increase Solhint's max-line-length, just like we did in the Lockup repo:

https://github.com/sablier-labs/v2-core/blob/8a3121013e2b199dcbac0a83db1c079843f012c3/.solhint.json#L12

[IaroslavMazur]

@IaroslavMazur that's a known issue with the Forge formatter:
foundry-rs/foundry#4450

Oh, wow... I did try looking for this issue reported in their repo, and did notice the issue above, but haven't looked deeper into it, because thought that it refers to smth else. 😅

Well done reporting the problem!

---

Rather than lowering the formatter's line length to 119, we should instead increase Solhint's max-line-length, just like we did in the Lockup repo:

Thanks for the idea! Just pushed the new changes.

Given how in Solhint, the max line length is a hard requirement, it does make sense to configure it there (i.e. configuring it in Foundry's formatter would only give us unpredictable results).

[IaroslavMazur]

TIL: it is perfectly fine for Solidity libraries to have internal functions.

To generate the "callable" bytecode for the NativeTokens lib in our SabVM tests, instead of making the lib functions external and deploying the lib "independently" (i.e. to a separate address), we should, rather, use the bytecode associated with the contract(-s) (i.e. SRF20Mock, in our case) that end up using those internal lib functions (and, therefore, contain the definitions of those functions inline).

Pushed the updates to this PR.

cc @PaulRBerg

[IaroslavMazur]

I've realized that given

• the current architecture of the NativeTokens library (that delegateCalls into our Rust Precompile),
• as well as the way its functionality is being accessed by the contracts implementing the SRF20 standard (via the use NativeTokens for address instruction),

the NativeTokens library is not the right place for checking whether the Native Tokens are, indeed, being minted/burned by a contract (and not an EOA).

This is because in the current design, the EOA calling the SRF20 contract remains the msg.sender (and so, we can't base our verification on it).

The right place for the verification is, therefore, our Rust Precompile. Its ContextPrecompile type hasn't natively supported accessing the "msg sender", but I've brought this info into its context.

Pushed the updates to this PR.

cc @PaulRBerg

[IaroslavMazur]

Ready to be reviewed by you, @PaulRBerg & @smol-ninja 🙌

[PaulRBerg]

Great work @IaroslavMazur. I am glad that we have been able to pull this off.

Given that we've decided to turn this work into an EIP, I will trust that your work is good enough as a PoC, and skip the review.

Freel tree to merge this.

[IaroslavMazur]

I am glad that we have been able to pull this off.

Oh, you're not alone in this feeling! 😃😌🥳

@smol-ninja, would you like to take a look - or do I have the green light to merge the PR? 👀

[smol-ninja]

I will have a look at it soon.

[IaroslavMazur]

I will have a look at it soon.

Awesome, thank you!

[smol-ninja]