dckc / awesome-ocap

Awesome Object Capabilities and Capability Security
The Unlicense
342 stars 25 forks source link

Delegatable - Solidity framework for extending smart contracts with counterfactual revocable-delegation #39

Open 0xpatrickdev opened 1 year ago

0xpatrickdev commented 1 year ago

Came across this on twitter, and think it may deserve a spot in this repo!

Counterfactual Delegations

The Delegatable Framework, architected by Dan Finlay and Rick Dudley, inspired by exisiting Object Capabilities and Capability security models, is a scalable peer-to-peer access control system for EVM compute environments.

Capability-based security is a concept in the design of secure computing systems, one of the existing security models. A capability (known in some systems as a key) is a communicable, unforgeable token of authority. It refers to a value that references an object along with an associated set of access rights. A user program on a capability-based operating system must use a capability to access an object.

Capability-based security refers to the principle of designing user programs such that they directly share capabilities with each other according to the principle of least privilege, and to the operating system infrastructure necessary to make such transactions efficient and secure. Capability-based security is to be contrasted with an approach that uses traditional UNIX permissions and Access Control Lists.

The Delegatable Framework uses counterfactual assertions to enable unforgeable and revocable on-chain delegations.

Caveat enforcers enable transaction-level limiters using on-chain information like timestamp, blockNumber and data from on-chain DataStreams and/or Oracles; features not currently available to native transactions.

Why

With the Delegatable framework, a decentralized exchange (DEX) like Uniswap, could use the BlockNumberBefore Enforcer instead of including blockNumber deadlines at the application/protocol layer. Additionally Users could set before, after and between conditionals, instead of just before, without changing the core smart contract function logic.

Why is this important, you might ask?

First, we have to ask the question "Why does Uniswap have to enforce transaction-level access controls at all?"

It's actually kind'of odd that UniswapV2 is required to include blockNumber deadlines in an AutomatedMarketMaker primitive when you really think about it. Ultimately that's a decision, which should be made independently of the protocol. A power exclusive to the Account signing and executing the transaction.