You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the artifact contains "bytecode", which has ASM-formatted bytecode. Because there are multiple ways to represent bytecode as ASM (multiple ASM representations), it is probably better to have "bytecode" be hex-formatted. Then we can add an "asm" field for users to read it easily.
We could add a few lines of code to the CashScript SDK / utils library to be backwards compatible with the old format.
If we wanted to be completely backwards compatible, we could also leave the old "bytecode" field as-is and add a new "bytecodeHex" field (to be used by libraries).
I personally think it is kind of OK to do some backwards incompatible stuff with the artifact format in v1.0 if it means the format is "cleaner" going forward.
Would love to hear more opinions on this.
The text was updated successfully, but these errors were encountered:
Right now the artifact contains
"bytecode"
, which has ASM-formatted bytecode. Because there are multiple ways to represent bytecode as ASM (multiple ASM representations), it is probably better to have"bytecode"
be hex-formatted. Then we can add an"asm"
field for users to read it easily.We could add a few lines of code to the CashScript SDK / utils library to be backwards compatible with the old format.
If we wanted to be completely backwards compatible, we could also leave the old
"bytecode"
field as-is and add a new"bytecodeHex"
field (to be used by libraries).I personally think it is kind of OK to do some backwards incompatible stuff with the artifact format in v1.0 if it means the format is "cleaner" going forward.
Would love to hear more opinions on this.
The text was updated successfully, but these errors were encountered: