Update bsip-0040.md

This commit is contained in:
Stefan Schießl 2018-07-28 23:53:05 +02:00 committed by GitHub
parent 5da66a4c34
commit 6c64b50d23
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23

View file

@ -39,7 +39,7 @@ The above list of named keys is nothing that is known to the backend as the back
# Rational # Rational
Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `asserts` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks for each operation if there is a `custom active authority` for any of the required accounts. If all operations within the transaction have a matching `custom active authority` (match means same `operationid`, now is within `valid_to` and `valid_from` and all `asserts` pass), then active authority of the corresponding account is granted. Custom active permission is a list of `custom active authorities`. A `custom active authority` contains an `operation_id`, an `authority` (just like with active permission) and `asserts` than can be used to restrict arguments and is only valid a certain time period (`valid_from` and `valid_to`). When handling incoming signed transactions, the backend checks for each operation if there is a `custom active authority` for any of its required accounts. Check for every required account of the transaction if all its belonging operations have at least one positively matched `custom active authority` (match means same `operationid`, now is within `valid_to` and `valid_from` and all `asserts` pass), and if so grant the active authority of the corresponding account.
# Specification # Specification
@ -145,7 +145,7 @@ Note: This is just an illustration of a possible serialization, not a specificat
When a signed transaction arrives and before the backend evaluates if all necessary authorities are present through the signatures, do the following: When a signed transaction arrives and before the backend evaluates if all necessary authorities are present through the signatures, do the following:
- iterate over required accounts and for each account, iterate over all operations within the transactions that require the active authority of this account - iterate over required accounts and for each account, iterate over all operations within the transactions that require the active authority of this account
- iterate the `custom_active_authorities` of said account - iterate the `custom_active_authorities` of said account
- if a `custom_active_authority` is found that matches (same `operationid` and passes all `asserts`), remember that and stop iterating the authorities and continue until all operations are checked - if a `custom_active_authority` is found that matches (same `operationid`, now is within `valid_to` and `valid_from` and passes all `asserts`), remember that and stop iterating the authorities and continue until all operations are checked
- if the account has a `custom active authority` match for every operation in the transaction that requires it, then grant the `active authority` of said account. If no match is found, treat as if no authority was given - if the account has a `custom active authority` match for every operation in the transaction that requires it, then grant the `active authority` of said account. If no match is found, treat as if no authority was given
Note: Note: