Sulkta-OSS/agora
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

apply suggestions

Browse source
This commit is contained in:
Emily Martins 2022-04-11 19:48:12 +02:00
parent f29cfe0716
commit d30feaf198
3 changed files with 9 additions and 9 deletions
Download patch file Download diff file Expand all files Collapse all files

4
docs/tech-design/effects.md
View file

@ -32,7 +32,7 @@ We don't. Effects will be _unable_ to alter the system without burning [_governa
All 'governable' components of a system must be able to interface with effects and allow them to make necessary changes, so long as they are in possession of a GAT.
In order for effects to be identifiable through some off-chain metadata and verification of source code, it helps for effects to be reusable, their varied functionality being dependent onn their datum. This allows for effects to be given names, be audited, and to be tracked. The datums are more easily inspected because of their human-readable encoding, CBOR.
In order for effects to be identifiable through some off-chain metadata and verification of source code, it helps for effects to be reusable, their varied functionality being dependent on their datum. This allows for effects to be given names, be audited, and to be tracked. The datums are more easily inspected because of human-readable representations of their underlying encoding in [CBOR](https://en.wikipedia.org/wiki/CBOR) (See [`plutus_data` in alonzo.cddl](https://github.com/input-output-hk/cardano-ledger/blob/master/eras/alonzo/test-suite/cddl-files/alonzo.cddl#L274-L279))
## What can an effect _be_?
@ -56,6 +56,6 @@ This should not be a major limitation in the system, as community members _shoul
## Guidelines for building effects
One of the first targets for safety regarding handling of GATs in effects is that an effect ought to only allow transactions which include the burning of exactly one GAT. This essentially prevents all of the issues of authority token leaking, multi-GAT burn issues, etc.
The primary safety consideration for handling GATs with proposal effects should be that an effect's transaction should only be valid when it burns exactly one GAT. This essentially prevents all of the issues of authority token leaking, multi-GAT burn issues, etc.
Furthermore, an effect could require that no funds are sent to the effect within the spend transaction. This prevents issues with residue datums leaking into future uses of the same script (reuse of scripts is a *requirement* for correct tagging, implementation safety, etc).