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
This data type has custom instances of ToData and FromData that ensure its constructors are represented as integers, which is crucial for on-chain extensibility.
The problem is that the semantic meaning of ScriptId has become unclear. It was originally created to avoid using integers when retrieving scripts from the versioning system. However, we also use ScriptId when deserializing the scripts. Not all scripts are versioned, but all scripts are (de)serialized, which means there exist constructors for scripts that are not versioned.
More interestingly, there also exist abstract script identifiers. This leads to bizarre situations. Consider these two constructors:
| GovernancePolicy
| MultiSigPolicy
GovernancePolicy represents the currently active modular governance (cf. #48), so whenever we want to recover an active version of governance we will refer to it using the GovernancePolicy constructor. MultiSigPolicy on the other hand refers to a concrete implementation of a governance policy (possibly one of many implementations). And so when the MultiSigPolicy script gets inserted into the versioning system it will be stored under the GovernancePolicy ID, serving as an implementation of modular governance. Thus, GovernancePolicy is just an abstract identifier. The fact that we store script with one ID under a different ID in the versioning system is confusing and we should rethink how to approach this.
In the off-chain code we have a
SciptId
data type (in theTrustlessSidechain.Versioning.ScriptId
module):This data type has custom instances of
ToData
andFromData
that ensure its constructors are represented as integers, which is crucial for on-chain extensibility.The problem is that the semantic meaning of
ScriptId
has become unclear. It was originally created to avoid using integers when retrieving scripts from the versioning system. However, we also useScriptId
when deserializing the scripts. Not all scripts are versioned, but all scripts are (de)serialized, which means there exist constructors for scripts that are not versioned.More interestingly, there also exist abstract script identifiers. This leads to bizarre situations. Consider these two constructors:
GovernancePolicy
represents the currently active modular governance (cf. #48), so whenever we want to recover an active version of governance we will refer to it using theGovernancePolicy
constructor.MultiSigPolicy
on the other hand refers to a concrete implementation of a governance policy (possibly one of many implementations). And so when theMultiSigPolicy
script gets inserted into the versioning system it will be stored under theGovernancePolicy
ID, serving as an implementation of modular governance. Thus,GovernancePolicy
is just an abstract identifier. The fact that we store script with one ID under a different ID in the versioning system is confusing and we should rethink how to approach this.IOG Jira: https://input-output.atlassian.net/browse/ETCM-8062
The text was updated successfully, but these errors were encountered: