3

I am aware that in solidity there are two types of libraries.

  1. Embedded Library: If a smart contract is consuming a library which have only internal functions than EVM simply embeds library into the contract. Instead of using delegate call to call a function, it simply uses JUMP statement(normal method call). There is no need to separately deploy library in this scenario.

  2. Linked Library : On the flip side, if a library contain public or external functions then library needs to be deployed. Deployment of library will generate unique address in blockchain. This address needs to be linked with calling contract.

From what I can see, if there is a functionality/code that will be identical over many SmartContracts, we should write Linked Library to avoid code duplication and thus save gas. We deploy such a library and link it to all the contracts that need to use its logic.

So what is then the point of Embedded Library??

Because, from what I can see, we don't deploy Embedded Library because the compiler will basically copy-paste its code into all the smart-contracts using it. So why just not write the code in SC and save yourself the trouble? (I guess it could make your code look cleaner, but that is about it)

Or am I missing something here? At the moment, Linked Library seems to have an obvious use case, while I can't find any situation where I would use Embedded Library instead. So I hope someone with more experience can explain this to me.

Link to relevant article -> All you should know about libraries in solidity

Another good article on how to downsize your SmartContracts by using Library

2 Answers 2

2

The answer isn't straightforward, one is not necessarily better than the other

Embedded libraries will be more expensive to deploy, since the code is being included with every contract deployment, but it will be cheaper to actually execute the code. Linked libraries will be the opposite, they'll make your contract deployments cheaper since you aren't redeploying that bytecode, but using them also increases execution costs due to the extra delegatecalls into the Linked library

It's a tradeoff between execution costs and deployment costs. If you are planning on deploying a set of contracts that are executed only a few times each, then you should used Linked libraries. If you are deploying a set of contracts that will be executed a lot of times, you should use Embedded libraries.

3
  • Interesting. I have another question then. Do Embedded libraries increase the size of my contracts (because the library code is included in the contract) VS Linked libraries where the code is deployed at different address ?
    – Sky
    Sep 16 at 13:51
  • That's correct, that's what I mean when I say deployment costs will be higher if you use embedded, because of the extra bytecode. but again, it will also have lower execution costs
    – natewelch_
    Sep 16 at 14:01
  • 1
    Thanks, that makes sense. If I happen to have an issue with contract size, I will use Linked Library; if not Embedded it is (because I am deploying on private network, so I don't have deployment cost issues)
    – Sky
    Sep 16 at 14:06
1

One more point is that embedded libraries increase the size of the deployed contract. As the size of a smart contract is limited, size forces us sometimes to un-embed and link the library.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.