The existence of both validator-side controller and registry-side controller are confusing #229
Replies: 2 comments
-
I like this idea. Today, the complete ACL information isn't in a single place (i.e. on-chain (SC/controller) + off-chain (GRANT/REVOKE in validators)). This is related to another tension that @awmuncy touched on: knowing in a write-query will succeed or fail. |
Beta Was this translation helpful? Give feedback.
-
Yeh big fan here too, if for no reason other than it simplifies things while also leading to more powerful access control semantics! Having a single source of truth for ACL is a big win IMO. The increased price overall might be warranted, because GRANT and REVOKE statements already incur a cost anyway, and the extra state management on top is likely pretty nominal. Worth a quick test to see if this changes the game cost-wise significantly? |
Beta Was this translation helpful? Give feedback.
-
This is a tough one. I love the simplicity of
GRANT
andREVOKE
which leverage the validator's notion of "controller", and the power of the smart contract based "controller". But it would be great to unify these concepts somehow.I know at one time we considered enabling
GRANT
andREVOKE
in the registry. We could leverage the WASM SQL parser in clients and simply map those statements to contract methods, eg,GRANT
->TablelandTables.grant(...)
. However, this approach on its own doesn't allow for granular control over the type of writes, ie,GRANT INSERT|UPDATE|DELETE
, since there is no way to enforce that in the contract w/o a solidity SQL parser.We could extend the registry with
tableId
-> role mappings forinsert
,update
,delete
. This state would alter thePolicy
s that are emitted. For example, imagine a table has a controller contract that returns aPolicy
. If an address is granted theinsert
role, the registry would alter it withallowInsert
->true
. The rest of the policy could be driven by dynamic logic as usual. This becomes pretty flexible, e.g., you could have a policy that only let's holders of some token to write, but dynamically add / remove other valid addresses, etc. ("all meebit holders can write... plus bob", where adding bob doesn't require updating the contract.With this approach, roles would also be unified with the concept of locking a controller.
On the other hand, managing roles means adding state, which means more expensive
GRANT
s.Beta Was this translation helpful? Give feedback.
All reactions