sigmastate-interpreter
sigmastate-interpreter copied to clipboard
[v6.0] Accumulate ErgoTree rewriting cost when handling Deserialize operations
Current implementation
In order to execute DeserializeContext operation, the ErgoTree is traversed once. During the traverse the DeserializeContext node is replaced by the result of deserialization. It is done here
The deserializeSubstitutionCost
is calculated and accumulated to the new context1
as initCost
, however
the context1
is erroneously not used in applyDeserializeContextJITC
.
What should be done
The context1
should be used in applyDeserializeContextJITC
instead of context
.
I would like to attempt this.
Hi, some questions regarding this. I've accumulated the deserialization cost, but this presents some issues:
- Wouldn't this technically be a soft-fork? (I'm guessing this shouldn't apply to versions earlier than 6.0). What's the best way in sigmastate-interpreter to only conditionally do this? Should I add a ValidationRule for this?
- Since this is for 6.0 should I add a new ErgoTree version (version 3) in this PR as well?
@SethDusek, yes, this change can only be activated (or rather its execution should be conditional on the currently activated protocol version) Here is an example how such change has been done for v5.0 https://github.com/ScorexFoundation/sigmastate-interpreter/blob/aae4118fed18f6587413d9a6330e449b05d8d5ad/data/shared/src/main/scala/sigma/ast/trees.scala#L38 You can add a new version constant here https://github.com/ScorexFoundation/sigmastate-interpreter/blob/11c98a3382646095ee943b333a0b5bfa65fa291d/core/shared/src/main/scala/sigma/VersionContext.scala#L37-L36
Call it like this
val ScriptVersionForV6: Byte = 3
Hi, another question regarding this. Should this only apply if both v6.0 is activated and the ErgoTree version is >= 3, or should it apply to any version of ergotree including 0, 1, and 2 provided this is activated on the network? Asking because if it applies if activation then the test cases will need deserialization costs for all previous versions (Some of them have different ergotree byte lengths apparently)
Hi, @SethDusek. It shouldn't depend on the test cases, but rather on usability and backwards compatibility.
- Regardless of the activated version, dApps can create new ergo tree with v0-v2, and with v3 activated, they should continue to do so.
- Cost estimation is internal mechanism, and we better keep it simple when possible, which means we can do the same calculation of costs for all versions of ErgoTree.
So, I think we should choose "it apply to any version of ergotree including 0, 1, and 2 provided this is activated on the network".