Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make this into a library #9

Open
dmdque opened this issue Mar 24, 2018 · 7 comments
Open

Make this into a library #9

dmdque opened this issue Mar 24, 2018 · 7 comments

Comments

@dmdque
Copy link

dmdque commented Mar 24, 2018

It would be helpful if this were made into a library using Solidity's library.

@JohannesMayerConda
Copy link

I need this also and as far as I know it's also not in openzeppelin (just SafeMath which is less than this) so I want to contribute this (see Pullrequest linked above). Please admin like @rainbreak review and approve (personal mention because in this repo seems to be little activity...)

@rainbreak
Copy link
Member

rainbreak commented Nov 30, 2018

Using this as a library would mean having the cost of DELEGATECALL (700 gas) on every arithmetic operation. Have you considered this?

[not necessarily true, see below]

@JohannesMayerConda
Copy link

JohannesMayerConda commented Nov 30, 2018

That's right (a test showed me gasUsed can be in practice even higher).
Out of my experience the gas cost factor is less critical than getting all the code you need into a contract without running into a block gas limit reached error (at least upon a certain point of complexity). That's where a library can help. It's not uncommon to put math stuff into a library e.g. openzeppelin math libraries.
I guess everyone who want's to optimize after completing development could still copy the functions he needs from the library.

But I can see your point. Should I copy&paste the library code into a DSMathC.sol (C for contract L for library)? Then everyone can decide. Downside is that two files have to be maintained

I especially neeeded the wmul() func and for me the best thing would be to have it in openzeppelin. I hope this can be a next step...

@dmdque
Copy link
Author

dmdque commented Dec 1, 2018

You have a good point about the cost of DELEGATECALL. As @JohannesMayerConda alluded to, more complex projects can't fit all functionality into a single contract due to the block gas limit, and have to be split up into multiple contracts. Having each one inherit ds-math is cumbersome.

Having the option for both seems like a no-brainer.

@JohannesMayerConda
Copy link

I didn't realize that ds-math is part of DappHub and tests can be executed via https://dapp.tools/ (see PullRequest discussion). My PullRequest would change this library into a truffle project which doesn't fit into the system and was therefore rejected (which I totally understand). I don't know if this would be an easy change to fit into the system but as @rainbreak said gas would also increase and isn't desired.

I feel like adapting my Pullrequest to adding a library containing duplicate code that is not even being used (because of higher gas) feels wrong so I suggest we close this issue (by an admin) and everyone interested in using ds-math as library approach can checkout my forked implementation via https://github.com/JohannesMayerConda/ds-math. I've adapted the readme to reflect this. I think a separate repository using truffle makes sense anyway for being closer to openzeppelin SafeMath Library

@dmdque
Copy link
Author

dmdque commented Dec 3, 2018

FYI most reputable tokens and protocols use OpenZeppelin's SafeMath, which is a library. The cost of gas is deemed acceptable for most projects out there.

@rainbreak
Copy link
Member

I was incorrect in the above comment about delegatecall being used everywhere. This is only true for public functions. However the functions in ds-math are all internal, so a user of a ds-math library would just be inlining them and accessing them with jump.

This removes the concern about excess runtime gas costs, but also the concern about deploytime gas costs.

https://solidity.readthedocs.io/en/v0.5.1/contracts.html#libraries

Libraries can be seen as implicit base contracts of the contracts that use them. They will not be explicitly visible in the inheritance hierarchy, but calls to library functions look just like calls to functions of explicit base contracts (L.f() if L is the name of the library). Furthermore, internal functions of libraries are visible in all contracts, just as if the library were a base contract. Of course, calls to internal functions use the internal calling convention, which means that all internal types can be passed and types stored in memory will be passed by reference and not copied. To realize this in the EVM, code of internal library functions and all functions called from therein will at compile time be pulled into the calling contract, and a regular JUMP call will be used instead of a DELEGATECALL.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants