meta(library linking): tracking issue for library linking improvements

[mds1]

Component

Forge

Describe the feature you would like

WIP

Additional context

No response

[sakulstra]

Hey adding #4339 here as it seems related.

Upon a bit investigation what seems to be happening here is that FlashLoanLogic relying on BorrowLogic will currently result in BorrowLogic being deployed twice.

In latest.json you will have only one BorrowLogic which will then break verification for some contracts (as they were apparently deployed with the other BorrowLogic).

"libraries": [
    "lib/aave-v3-core/contracts/protocol/libraries/logic/BorrowLogic.sol:BorrowLogic:0x15196D30Bc37d2fc5C718ffCd9d7687D76f3Ad1f",
    "lib/aave-v3-core/contracts/protocol/libraries/logic/BridgeLogic.sol:BridgeLogic:0x235d5ed464b3d0a7a616305ff6e71a2a06f82283",
    "lib/aave-v3-core/contracts/protocol/libraries/logic/ConfiguratorLogic.sol:ConfiguratorLogic:0x3e05eb6e12a3c9ed5e46a710bcf052efd6d73fbd",
    "lib/aave-v3-core/contracts/protocol/libraries/logic/EModeLogic.sol:EModeLogic:0x89654c66a6abd7174b525d05c2f4c442a615cee8",
    "lib/aave-v3-core/contracts/protocol/libraries/logic/FlashLoanLogic.sol:FlashLoanLogic:0xe88fb4eaf67ea87bb458e24c94bef0eb02b5f449",
    "lib/aave-v3-core/contracts/protocol/libraries/logic/LiquidationLogic.sol:LiquidationLogic:0x31a239f3e39c5d8ba6b201ba81ed584492ae960f",
    "lib/aave-v3-core/contracts/protocol/libraries/logic/PoolLogic.sol:PoolLogic:0xe427fcbd54169136391cfedf68e96abb13da87a0",
    "lib/aave-v3-core/contracts/protocol/libraries/logic/SupplyLogic.sol:SupplyLogic:0xe63eaf6dab1045689bd3a332bc596ffcf54a5c88"
  ],

In this case the appropriate fix would be to only have one library deployed.

[mattsse]

thanks, this could also be a script issue.

will debug this shortly.

lib-linking will also get a makeover

[sakulstra]

@mattsse not sure if relevant, but after some digging seems like this was not actually the first issue reporting this.
Seems like it's a duplicate of #3664 and #2607

[sakulstra]

@mattsse I created a minimal reproduction here: sakulstra/forge-bug-repro@main...bug/library-deploy

As you can see the library is included twice in the dry run:

• https://github.com/sakulstra/forge-bug-repro/blob/81880b0ec3d2ae0e9599c4725829e212b656e6f7/broadcast/Ghost.s.sol/1/dry-run/run-latest.json#L6
• https://github.com/sakulstra/forge-bug-repro/blob/81880b0ec3d2ae0e9599c4725829e212b656e6f7/broadcast/Ghost.s.sol/1/dry-run/run-latest.json#L63

[mattsse]

thanks for this!
I'll have a look asap since this seems to be a very annoying bug

[sakulstra]

Tried to have a look at an actual fix myself but i don't really understand where to fix this due to lacking rust fu. I guess one could filter duplicates here: https://github.com/foundry-rs/foundry/blob/master/cli/src/cmd/forge/script/cmd.rs#L127 , but seems wrong as probably should not land here in first place.

I tried manually deploying the external libraries and using compiler linking, but seems manually deploying libraries doesn't work either as i'm getting TypeError: Invalid use of a library name.
Do you have an idea on how one could work around this in the meantime?

[hexonaut]

Has there been any progress on this? It's a pretty big blocker for us. I get there is a rewrite happening, but in the mean time we really need a work around or a fix on this specifically. Anything we can do to help here?

[gakonst]

Here's a possible resolution:

1. We finish our prios this week
2. We allocate next week into fixing this, either by fixing the bug, or by rewriting linking altogether
3. We release Foundry 1.0 in 2 weeks
4. We TURBO prio this for the 2 weeks after it and release Foundry 1.0.1 with the proper fix.

@Evalir will drive here, we've just been less close to this code and hadn't fully appreciated how much of a blocker this would be for people.

[hexonaut]

That sounds great. Really appreciate this.

[Evalir]

I think we can close this! Fix was made in #5164

[Evalir]

Reopening as we've had to revert the fix on #5164 due to strange behavior observed by some users. We're working on a new fix

[kartojal]

While there is a final fix for this issue, I found out a workaround to handle Library deployments with Foundry Solidity scripts and ffi, which consists in multiple steps:

1. With a Solidity script, perform the deployment of Libraries using CREATE2 and type(LibraryName).creationCode and fill the FOUNDRY_LIBRARIES environment variable to .env programmatically, with the deployed libraries and their correct path. The script detects if the library is already deployed on-chain in the desired network or if the code changed and updates the FOUNDRY_LIBRARIES env.
2. Repeat step 1 if you have libraries which depends of other libraries, adding the new libraries to FOUNDRY_LIBRARIES programmatically with Solidity script.
3. Perform contracts deployments that depends of those libraries, now Foundry will use the libraries provided by FOUNDRY_LIBRARIES and will not deploy the already deployed libraries or deploy twice the libraries.

In this way, the process is automated, there is no library duplication and the developer have full control of the libraries deployment step, allowing the developer to perform the deployment of libraries in one transaction instead of multiple transactions or tweak the order of deployment.

The downside is that this requires multiple compilation steps, is tedious to setup and could produce side-effects if the procedure is not correctly verified.

Would love to share a snippet to show this pattern to others once I find some time, but hope it could help others in the meantime.

[Evalir]

Hey all! Posting back after a week.

We took some days debugging and #5194 was recently merged with an additional fix that should hopefully alleviate these. Could you try the latest nightly and report back if it works for y'all? @kartojal @hexonaut @sakulstra

[hexonaut]

It appears to be working. I just did a deploy /w verification of Aave V3 Pool: https://goerli.etherscan.io/address/0x4662c88c542f0954f8ccccde4542eec32d7e7e9a#code

[Evalir]

Closing again, as #5194 has fixed this (again)

[0xTimepunk]

While there is a final fix for this issue, I found out a workaround to handle Library deployments with Foundry Solidity scripts and ffi, which consists in multiple steps:

1. With a Solidity script, perform the deployment of Libraries using CREATE2 and type(LibraryName).creationCode and fill the FOUNDRY_LIBRARIES environment variable to .env programmatically, with the deployed libraries and their correct path. The script detects if the library is already deployed on-chain in the desired network or if the code changed and updates the FOUNDRY_LIBRARIES env.
2. Repeat step 1 if you have libraries which depends of other libraries, adding the new libraries to FOUNDRY_LIBRARIES programmatically with Solidity script.
3. Perform contracts deployments that depends of those libraries, now Foundry will use the libraries provided by FOUNDRY_LIBRARIES and will not deploy the already deployed libraries or deploy twice the libraries.

In this way, the process is automated, there is no library duplication and the developer have full control of the libraries deployment step, allowing the developer to perform the deployment of libraries in one transaction instead of multiple transactions or tweak the order of deployment.

The downside is that this requires multiple compilation steps, is tedious to setup and could produce side-effects if the procedure is not correctly verified.

Would love to share a snippet to show this pattern to others once I find some time, but hope it could help others in the meantime.

Could you share the snippet that allowed you to achieve this? I am having trouble in obtaining a create2 address for a contract dependent on linked libraries
@kartojal