Configuration of validation. Each ValidationRule instance should be
implemented as an object to facilitate type-safe usage. It then should be
registered in ValidationRules.currentSettings to be used in the code to
perform validation. Added to currentSettings the rule has EnabledRule
status by default, but only in a current version of the code. Thus, the
value currentSettings represents the validation settings of the current
version of the code. The set of rules in currentSettings is fixed in the
current version of the code and thus only rule status can be changed (as
described below)
Old versions of the code don't have access to the rules added in newer
versions. The implementation of the specific rule, once released under
specific ruleId, should never be changed, hence ruleId denotes that
implementation. However, the behavior of rules (released with code) can be
altered by changing their status in block extensions section via voting.
The status changes are represented in ValidationSettings using the
RuleStatus type. Each descendant class represent a particular change in the
rule status. Rule ids are used as keys of the status values stored in the
block extension section. RuleStatus instances are deserialized from the
block extension values. Deserialized (ruleId, status) pairs are joined with
the (ruleId,status) pairs in currentSettings, and for matching ruleIds the
default statues stored in currentSettings are replaced with the new
statuses obtained from the blockchain. Deserialized (ruleId,status) pairs
which don't match with currentSettings are ignored.
Each rule has associated check of soft-fork condition by implementing
isSoftFork method. If isSoftFork returns true, then ValidationException
raised by the rule is interpreted as *soft-fork condition*. Depending on the
use case, soft-fork condition allows some operations performed by an old
code to succeed which otherwise would fail due to ValidationException raised
by the validation rule. One notable use case is Box.ergoTree validation in
which old code can skip ValidationExceptions under soft-fork condition (i.e.
when isSoftFork returns true), for example when a new opCode is added in the
newer version of the protocol, and this fact can be recognized by the old
code.
Configuration of validation. Each
ValidationRule
instance should be implemented as anobject
to facilitate type-safe usage. It then should be registered inValidationRules.currentSettings
to be used in the code to perform validation. Added tocurrentSettings
the rule has EnabledRule status by default, but only in a current version of the code. Thus, the valuecurrentSettings
represents the validation settings of the current version of the code. The set of rules incurrentSettings
is fixed in the current version of the code and thus only rule status can be changed (as described below)Old versions of the code don't have access to the rules added in newer versions. The implementation of the specific rule, once released under specific ruleId, should never be changed, hence ruleId denotes that implementation. However, the behavior of rules (released with code) can be altered by changing their status in block extensions section via voting.
The status changes are represented in ValidationSettings using the RuleStatus type. Each descendant class represent a particular change in the rule status. Rule ids are used as keys of the status values stored in the block extension section. RuleStatus instances are deserialized from the block extension values. Deserialized (ruleId, status) pairs are joined with the (ruleId,status) pairs in
currentSettings
, and for matching ruleIds the default statues stored incurrentSettings
are replaced with the new statuses obtained from the blockchain. Deserialized (ruleId,status) pairs which don't match withcurrentSettings
are ignored.Each rule has associated check of soft-fork condition by implementing
isSoftFork
method. IfisSoftFork
returns true, then ValidationException raised by the rule is interpreted as *soft-fork condition*. Depending on the use case, soft-fork condition allows some operations performed by an old code to succeed which otherwise would fail due to ValidationException raised by the validation rule. One notable use case is Box.ergoTree validation in which old code can skip ValidationExceptions under soft-fork condition (i.e. when isSoftFork returns true), for example when a new opCode is added in the newer version of the protocol, and this fact can be recognized by the old code.SoftForkWhenCodeAdded