Closed jeff-aion closed 5 years ago
This problem was noticed when we updated tooling to JDK11 (input bytecode version still 54 - Java10) and a small change made to the Manifest
class caused slight changes in deployed jar sizes, which led to difficult to interpret inconsistencies, where the billing rules were sensitive to this sizing.
To explain the change to Manifest
, it seems as though they changed the hard-wrap line length from 70 to 72, causing a slightly different character ordering, rarely causing a measurable difference in the compression ratio. This change appears to either be an accident or a change of opinion regarding whether the injected \r\n
is part of the line, or is part of the following line.
Additionally, in the DAppCreator
, it appears as though we are billing for code storage incorrectly: billing for the entire transaction data (which also includes initialization arguments), instead of just the jar. I suspect that this is a hold-over from the earlier point where we weren't yet including initialization arguments.
The rules which define how our billing mechanism works are spread throughout the codebase, and many are undocumented attempts to mirror Ethereum rules. Beyond this, our tests which rely on these rules are often hard-coding expected values as constants, making them brittle to subtle changes which could be managed as higher-level idioms.
We should begin moving these rules into a single location, where they can be documented, scrutinized, and be consistently referenced in tests.