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:
this idea of having bytecodeHex in the Artifact goes against the idea of #214 to enable template variables in the contract asm
I don't think having the hex there adds much value, instead it makes more sense to me to not have duplicate info in the artifact and make the asm include templated variables
what could be interesting to add to the Artifact is a contract's fingerprint, this is a hash of the contract logic (minus the data pushes).
Here's a longer explanation:
By transforming sequences of data push operations into normalized count indicators, and applying a hash function to the resulting pattern, we create unique fingerprints that identify contract types regardless of their specific parameter values.
This method facilitates efficient contract classification, analysis, and discovery, while maintaining the ability to reconstruct and filter individual contract instances based on their parameters.
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: