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

Floats/Doubles could lead to non-deterministic results via different platforms for SC's #2

Open
JayArrowz opened this issue Sep 1, 2019 · 0 comments

Comments

@JayArrowz
Copy link

JayArrowz commented Sep 1, 2019

See Ref:
https://randomascii.wordpress.com/2013/07/16/floating-point-determinism/

"What is not guaranteed
Unfortunately there are a significant number of things that are not guaranteed. Many of these things can be controlled so they should not be problems, but others can be tricky or impossible. Which is why the answer is both “yes” and “no”.

Floating-point settings (runtime)
There are a number of settings that control how floating-point math will be done. The IEEE standard mandates several different rounding modes and these are usually expressed as per-thread settings. If you’re not writing an interval arithmetic library then you’ll probably keep the rounding mode set to round-to-nearest-even. But if you – or some rogue code in your process – changes the rounding mode then all of your results will be subtly wrong. It rarely happens but because the rounding mode is typically a per-thread setting it can be amusing to change it and see what breaks. Troll your coworkers! Amuse your friends!

If you are using the x87 floating-point unit (and on 32-bit x86 code you can’t completely avoid it because the calling conventions specify that an x87 register is used to return floating-point results) then if somebody changes the per-thread precision settings your results may be rounded to a different precision than expected."

Possible Issues from this:
Could lead to a variety of issues and exploits with account states. If 2 different group of nodes 2 different floating point settings then the 2 groups of nodes will both have a different possible return values and logic executions for the same smart contract.

Solution:
When floats/Doubles are used in Java Smart contracts make sure the nodes check for the keyword 'strictfp' to ensure the same result on all machine/hardware types.
"Programmers can use the modifier strictfp to ensure that calculations are performed as in the earlier versions; that is, only with IEEE single and double precision types used. Using strictfp guarantees that results of floating-point calculations are identical on all platforms. "
https://en.wikipedia.org/wiki/Strictfp
https://www.codejava.net/java-core/the-java-language/java-keyword-strictfp

This only applies to older machines with different floating points.

Yes strictfp is useless on modern CPUs, but if we do not plan to support older CPU's then they shouldn't be allowed to be a node.

@JayArrowz JayArrowz changed the title Floats could lead to non-deterministic results via different machines for SC's Floats could lead to non-deterministic results via different platforms for SC's Sep 1, 2019
@JayArrowz JayArrowz changed the title Floats could lead to non-deterministic results via different platforms for SC's Floats/Doubles could lead to non-deterministic results via different platforms for SC's Sep 1, 2019
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

1 participant