agorise/bsips
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

add logical assert

Browse source
This commit is contained in:
Stefan Schießl 2018-07-30 14:39:45 +02:00 committed by GitHub
parent 41a2403875
commit cf72eaa2d7
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 15 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

24
bsip-0040.md
View file

@ -73,17 +73,16 @@ A `custom active permission` contains a list of `custom active authority`. `Cust
### Asserts
The `asserts` field is a list of restrictions consisting of argument to assert mappings.
An tuple of `(argument_identifier, assert_object[, logical_link])` is called a restriction on an argument.
All asserts within one restriction are evaluated per default with `and` logic, `or` logic can be put by specifying the `logical_link`. The `asserts` field is specified as follows:
A dictionary-type object like
```
asserts = list of (argument_identifier, list of assert_object, logical_link) tuples
argument_identifier = // target variable, can be argument of operation, or attribute in case of nesting
assert_object = {
function, // functionid to do the assert
data, // stores data specific to the chosen function
state // if this assert is statefull
function, // argument_identifier
argument, // constant value, or pointer to a dynamic value (argument of the operation, or attribute when nested)
data, // data specific to the function
}
```
is called a restriction. All asserts within one restriction are evaluated per default with `AND` logic.
List of possible asserts are:
| function | data | state |
@ -94,6 +93,7 @@ List of possible asserts are:
| `limit` | [`max_cumsum`, `interval_in_sec`] | [`current_cumsum`, `interval_began`] |
| `limit_monthly` | [`max_cumsum`, `interval_in_months`] | [`current_cumsum`, `interval_began`] |
| `attribute_assert` | list of restrictions | stateless |
| `logical` | list of restrictions | stateless |
Following cases must hold for a restriction:
- if there is no value given (e.g. an optional argument, or nested value not given), the assert passes (no change, no violation)
@ -134,6 +134,11 @@ Statefull assert, only `int` type arguments. Analogue to `limit`, but `interval_
#### `attribute_assert`
Stateless assert, only for dictionary type objects. The `attribute_to_assert` list contains restrictions that all must assert positively. Allows nesting of `attribute_assert`.
#### `logical`
Stateless assert, only for dictionary type objects. The data is a list of restrictions, `argument` defines the logical link
- `OR`: If one of the restrictions in data asserts positively
- `AND`: If ALL restrictions in data assert positively
#### Example: Nested arguments like `options`
Assume `asset_update_operation`. All attributes of its `options` must be filled on update call. This assert can not be used to realize a "may only change attribute xzy of `options`". This would require that the logic knows which of the arguments are reflected on-chain and it knows how to query it for every operation that contains `options`. If `options` are to be restricted with this assert, all values that should not change would need be fixated by defining an `any` assert for those attributes, while having e.g. a `lt` assert for the one attribute that is allowed to change.
@ -150,10 +155,11 @@ custom active authority = {
account_auth: []
},
asserts: [
(to, {
{
function: any,
argument: to,
data: [B]
}) // this restricts the argument identified with "to"
} // this restricts the argument identified with "to"
]
}
```