Current thoughts on Decimal128 vs BigDecimal?

[gnidan]

This isn't an issue, per se, but I'm wondering the current thinking on the direction this proposal will go. Is the plan still to prototype both proposals?

For what it's worth, I'd like to advocate strongly for the need for true BigDecimal types, since the Ethereum ecosystem heavily relies on JS tooling, and the Ethereum Virtual Machine is a 256-bit architecture. For mission-critical financial applications, a built-in BigDecimal type would alleviate software supply-chain concerns, since the use of third-party dependencies for this functionality introduces risk that these dependencies are compromised by malicious actors. As someone who has been following this proposal for years, it's my belief that moving forward with Decimal128 alone would be a huge missed opportunity for the Ethereum ecosystem.

If there's anything I can do to help this effort, please let me know. I lead Truffle (https://github.com/trufflesuite/truffle), a widely used JS tool for Ethereum smart contract development, and this proposal is directly related to my professional work.

Thank you!

[ptomato]

The plan is to prototype both variations of Decimal, indeed.

Thanks for taking the time to give feedback. I'd be curious to know a bit more about your needs for precision, if you're able to share! I've heard from other people involved in financial applications that Decimal128 is more than enough precision even if they prefer BigDecimal. Is it different because Ethereum would require 256 bits of precision due to it being a 256-bit architecture? (Would it be helpful to have a call to talk about this?)

[novemberborn]

Cryptocurrency tokens on Ethereum are encoded as 256 bit integers but typically define a number of decimal places. 1 ETH has 18 decimal places, the smallest possible value that can be sent to another address being 1 Wei.

A hypothetical token could use all 256 bits for decimal places, or none. Ideally a decimal type can be used for this entire range so no userland library is required.

[munrocket]

🤔 Maybe fixed point arithmetic with BigInt will be better for Ethereum with uint256 inside. Good support in browsers and you still will not use the exponential part in BigDecimal.

[gnidan]

I'd be curious to know a bit more about your needs for precision, if you're able to share!

@ptomato speaking only for Truffle, an isolated example is our @truffle/decoder NPM package (see docs), which decodes on-chain values into JS-friendly machine-readable results. Right now, these results represent integer values (up to 256-bits) using bn.js and fixed-point values (up to 256-bits wide, up to 80 decimal places) using big.js. The underlying values generally follow the Solidity ABI specification¹ (scroll down to Types on that page); note that all major Ethereum languages make use of this ABI spec (not just Solidity).

Continuing to speak only for Truffle, we're really keen to get rid of both bn.js and big.js and just use bigint and bigdecimal values, since those two packages prevent us from distributing our decoding logic dependency-free (if you see the docs I've linked, it states how our low-level @truffle/codec package has no dependencies other than for precision number representation).

Speaking more broadly of what I know of the Ethereum ecosystem, well: every language uses Solidity's ABI; JS libraries for reading/writing ABI values must handle high-precision numbers; right now every such library uses its own choice of userland package for representing these values; this causes pain and confusion².

Is it different because Ethereum would require 256 bits of precision due to it being a 256-bit architecture?

Yep, and also because values likely take up the full word-size.

A hypothetical token could use all 256 bits for decimal places, or none.

@novemberborn note that token standards like EIP-20 still use uint256 values and expect client code to do the division, even though the ABI does define a family of fixedNxM types (which I've described above). It's a shame that there's this disconnect, but yeah you're absolutely right - it's valid for a token to define itself as having 255 decimal places, even though it's a 256 bit value!

Anyway, @ptomato thanks for your offer to get on a call with me! If my comment here doesn't make enough sense, let me know or email me [email protected] and we can schedule. Also happy to schedule here; whatever works!

Thanks all 🙇

Footnotes

1. Technically, while Solidity's ABI spec defines fixed-point types, Solidity does not actually support these. To the best of my knowledge, only Vyper (the second-most popular Ethereum language) produces fixed-point values as defined by this ABI spec. ↩

2. For example, Truffle depends on Web3.js for some of its ABI decoding, and Web3.js uses BN³. Web3.js, in turn, actually defers to ethers.js for its decoding, and ethers.js uses its own version of BigNumber (but not MikeMcl's bignumber.js). Truffle and Web3.js do support MikeMcl's bignumber.js objects as input, but those are not the same as what ethers.js allows. You can imagine, there's a lot of logic everywhere to determine what kind of precise number some object is. ↩

3. As far as I know, Web3.js doesn't support fixed-point types, hence why I only mention BN.js. A lot of Ethereum libraries don't support fixed-point types, likely because Solidity doesn't produce fixed-point values. As mentioned, Vyper does, and I'm hoping to help push the Ethereum ecosystem towards proper fixed-point support. I know Solidity is working on adding support. ↩

[munrocket]

@gnidan I made a library with fixed point arithmetic for you, please give feedback https://github.com/munrocket/fixed-point
Also sent a message on email.

[gnidan]

Thanks @munrocket; I will find time to review your library. For some reason your email didn't come through; how should I get feedback to you?

[munrocket]

In issue is enough :)