KIP-0027: Make User Guards SysOnly to ReadOnly

[CryptoPascal31]

Following my discussion with @jmcardon,

The proposal is to change the execution environment of User guards from SysOnly to ReadOnly.

This would be an amazing feature, that would definitively "unleash the power of Kadena"

Would like to have the feeling of the team about this. Maybe there are some pitfalls I didn't catch ?

https://github.com/kadena-io/KIPs/blob/06223ea13461aac38702abeefb1e872b2be9cc68/kip-0027.md

---

• To see the specific tasks where the Asana app for GitHub is being used, see below:
  • https://app.asana.com/0/0/1208668844268890

[jmcardon]

So in looking @ this KIP, the only thing I wonder about is: Aren't all of these cases doable via a capability guard that enforces these invariants? That is, take this example:

(module balance-checker GOV
  (defcap GOV ()
    (enforce fail "No-Upgrade"))
    
  (defcap HAS_MINIMUM_BALANCE (target-account:string min-balance:decimal) 
      (let ((bal (coin.get-balance target-account)))
      (enforce (>= bal min-balance) "No"))
  ) 

  (defun has-minimum-balance:bool (target-account:string min-balance:decimal)
    (let ((bal (coin.get-balance target-account)))
      (enforce (>= bal min-balance) "No"))
  )

  (defun get-guard:guard (target-account:string min-balance:decimal)
    (create-capability-guard (HAS_MINIMUM_BALANCE target-account min-balance))
  )
  
  (defun my-create-account (target-account:string min-balance:decimal)
    (with-capability (HAS_MINIMUM_BALANCE target-account min-balance)
        (coin.create-account "alice" (balance-checker.get-guard "alice-savings" 1000.0))
  )
)

(coin.create-account "alice" (balance-checker.get-guard "alice-savings" 1000.0))

[CryptoPascal31]

So in looking @ this KIP, the only thing I wonder about is: Aren't all of these cases doable via a capability guard that enforces these invariants? That is, take this example:

@jmcardon Your example doesn't work. Or at least is incomplete ... Where do you acquire the cap ? to unlock the guard. :wink:

More generally, using a cap guard, you always REQUIRE to have a caller module to acquire the cap...

Sometimes, it's not very convenient: eg: Alice want's to access her funds by doing a simple (coin.transfer ) at the top level.

But often having a caller module is not possible: eg

• namespace rotation
• module deployment
• pact continuation

The firsts two are necessary to implement namespaces / modules managed by DAO or stuffs like evolved mutli-sigs. The third is a typical case for a Marmalade buyer.