validation

Type Members

1. case class ChangedRule(newValue: Array[Byte]) extends RuleStatus with Product with Serializable

   

   The status of the rule whose parameters are changed via soft-fork extensions.

   The status of the rule whose parameters are changed via soft-fork extensions. The same rule can be changed many times via voting.

   newValue

   new value of block extension value with key == rule.id

2. sealed class MapSigmaValidationSettings extends SigmaValidationSettings

   

   Default representation of validation settings.

3. case class ReplacedRule(newRuleId: Short) extends RuleStatus with Product with Serializable

   

   The status of the rule which is replaced by a new rule via soft-fork extensions.

   The status of the rule which is replaced by a new rule via soft-fork extensions. This is similar to DisabledRule, but in addition require the new rule to be enabled at the same time (i.e. atomically)

   newRuleId

   id of a new rule which replaces the rule marked with this status

   See also

   ValidationSettings.isSoftFork

4. sealed trait RuleStatus extends AnyRef

   

   Base trait for rule status information.

5. abstract class SigmaValidationSettings extends Iterable[(Short, (ValidationRule, RuleStatus))]

   

   Configuration of validation.

   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.

   See also

   SoftForkWhenCodeAdded

6. trait SoftForkChecker extends AnyRef

   

   Interface implemented by objects capable of checking soft-fork conditions.

7. trait SoftForkWhenCodeAdded extends SoftForkChecker

   

   Checks that the unknown code is however present in the ChangedRule new value stored in block extensions section.

   Checks that the unknown code is however present in the ChangedRule new value stored in block extensions section. This is interpreted as soft-fork condition, i.e. the unknown code is not arbitrary, but explicitly added to the blockchain configuration and implemented in newer versions of the protocol.

8. trait SoftForkWhenReplaced extends SoftForkChecker

   

   Checks that the failed validation rule has ReplacedRule status in block extensions section.

   Checks that the failed validation rule has ReplacedRule status in block extensions section. This means the rule given by ruleId is not used in newer versions of the protocol. Instead it has been replaced by the new rule given by ReplacedRule status.

9. case class ValidationException(message: String, rule: ValidationRule, args: Seq[Any], cause: Option[Throwable] = None) extends Exception with Product with Serializable

   

   Base class for all exceptions which may be thrown by validation rules.

   Base class for all exceptions which may be thrown by validation rules. Instances of this class are used as messages to communicate soft-fork information, from the context where the soft-fork condition is detected (such as in ValidationRules), up the stack to the point where it is clear how to handle it. Some messages of this kind are not handled, in which case a new Exception is thrown and this instance should be attached as a cause parameter.

   This exception should typically always come with Some(cause). As result, stack trace is not filled in when this instance is create. The cause parameter should be examined for the source of the exception.

10. case class ValidationRule(id: Short, description: String) extends SoftForkChecker with Product with Serializable

    

    Base class for different validation rules registered in ValidationRules.currentSettings.

    Base class for different validation rules registered in ValidationRules.currentSettings. Each rule is identified by id and have a description. Validation logic is implemented by apply methods of derived classes.