Cannot deploy the new OpenZeppelin account contract

[xJonathanLEI]

Tried using starknet-rs to deploy the latest account contract from OpenZeppelin.

The transaction is not working:

{
  "status": "REJECTED",
  "transaction_failure_reason": {
    "tx_id": 1256114,
    "code": "TRANSACTION_FAILED",
    "error_message": "Error at pc=0:45:\nGot an exception while executing a hint.\nCairo traceback (most recent call last):\nUnknown location (pc=0:509)\nUnknown location (pc=0:499)\nUnknown location (pc=0:280)\nUnknown location (pc=0:242)\nUnknown location (pc=0:219)\n\nTraceback (most recent call last):\n  File \"<hint6>\", line 5, in <module>\nAssertionError: normalize_address() cannot be used with the current constants."
  },
  "transaction": {
    "contract_address": "0x615161661cdbea1c112383ce703d33299bef0e796903b88ec5601010ee22091",
    "contract_address_salt": "0x6c8035ea0cc6d4b0d933969db1367d7380adcaa462184b814f2def2bd9adf5",
    "constructor_calldata": [
      "1"
    ],
    "transaction_hash": "0x232db7959b3ccc22b6e1321fc412025a7d9733b90db809c29e47601b5ef5e3f",
    "type": "DEPLOY"
  }
}

[xJonathanLEI]

Did some testing. I started out trying to deploy the artifact generated by the generate_artifacts.sh script with the official StarkNet CLI. It fails with the same error.

Then I tried directly compiling the account contract with starknet-compile and deploying with the official CLI. Much to my surprise, it works.

After some more testing, it turns out piping the artifact through jq is what causes the issue... The generate_artifacts.sh script uses jq to turn each artifact into a single line (so that Git diffs for example aren't a complete mess).

I tried using prettier to format the artifact instead, and it can still be successfully deployed with the official CLI.

I'm still in the process of trying to figure out what exactly has jq broken.

[xJonathanLEI]

OK it looks like the issue is jq reformatting decimal values into scientific notation. There seems to be no way to tell jq to not do this in the latest release of jq (1.6).

[xJonathanLEI]

Note that even after removing the use of jq, starknet-rs still cannot deploy the contract properly. It looks like serde_json has trouble handling very long decimal numbers as well.

So this issue is really caused by two things:

• jq turning long decimal numbers into scientific notation; and
• serde_json not properly handling long decimal numbers.

[milancermak]

[xJonathanLEI]

Turns out serde_json has this arbitrary_precision feature that adds support for long decimal numbers. Nice.

[xJonathanLEI]

OK a whole new set of issues after enabling arbitrary_precision:

• Arbitrary precision numbers don't work with serde(tag = ..) and serde(flatten) serde-rs/json#505
• Internal buffering disrupts format-specific deserialization features serde-rs/serde#1183

[xJonathanLEI]

Hmmm I skimmed through the code of serde_json, and it seems that the only way to serialize a string without quotation marks would be to use the Number type when arbitrary_precision is enabled. In that case, it uses an internal marker $serde_json::private::Number which in turns uses NumberStrEmitter to do the trick. What NumberStrEmitter uses for serialization is not exposed through the serde API, so we can't just make use of it by implementing serde::Serialize. (raw_value seems to also enable this, but it's subject the the exact same clash issue)

Basically I'm trying to make sure we're outputting the exact same string as the one we read from the artifact file, and the original file presents the number as a decimal representation without quotes.

Since we can't use arbitrary_precision due to the clash with tag and untagged, and that it's not possible to implement something like NumberStrEmitter outside of serde_json, it looks like we're stuck.

[xJonathanLEI]

I guess the best we can do here is to enable arbitrary_precision and manually implement tag and untagged without the serde buffering. This issue has turned into a much larger undertaking than what I expected, thanks to the serde bug.

IMO it's almost always a bad idea to use very large numbers in JSON without turning them into strings... Lots of bad things can happen...

[xJonathanLEI]

Created a PR for using arbitrary_precision. I tested and I can now deploy the new account contract successfully.

That said, we're still not outputting the exact same JSON representation as the input artifact due to some other reasons. We should probably track this with a follow-up issue.

[xJonathanLEI]

Just did a quick test. With the fix in place we're outputting the exact same JSON string as the input file up to:

• whitespaces, of course; and
• the missing attributes and debug_info fields; and
• ordering of fields; and
• zero hex prefixes.

The last item can be fixed by changing UfeHex from {:#064x} to {:#x}.

I think we should be good. Contract deployment should work perfectly after the fix.

[milancermak]

Well, this turned out to be an unfortunate situation. Great job on sorting it out.