As research has been made on gas abstraction and gas sponsorship, such as @bajpai244’s gas paymaster demo, there’s been discussion around the limitations of Sway’s msg_sender() implementation. Specifically, smart contracts that depend on msg_sender() will fail if a paymaster includes a separate ETH coin to cover gas fees.
Proposals have been made for how to “fix” the msg_sender function, such as my proposal to add “Note” inputs. However, some contributors have raised the point that the entire concept of a universal “sender” should probably be moved away from when building Fuel applications.
I’ve put together a demo of an application that features a basic “vault” application, where the owner of each vault is represented by an NFT. Users can manage their vault (depositing or withdrawing) by including the NFT in their transaction and referencing the input or output coins in their function call.
I believe this architecture is a more “Fuel-native” approach to permissioning access in smart contracts, and would love to hear the community’s feedback on this approach.
When the user wants to deposit funds, they’ll call the deposit_assets method with the assets to deposit. They must also include the NFT in the transaction, by “transferring” the NFT to the same address. The vault_token parameter of the function call will “point” to the input, using the Input option of the TokenIdentifier, which will indicate the input index of the NFT.
Nit: you often don’t need to constraint the “deposit” endpoint because there isn’t a reason to stop someone from giving money voluntarily, especially when it will cost extra gas. You should only check in the case that people might be taking from others.
True, although the purpose of the demo isn’t really to build a vault, it’s to demonstrate this constraint/permissioning. Demoing it for deposit is useful to demo the “create-and-deposit” flow.
Hey @david !
This idea of access control in sway via tokens is something I put a fair bit of thought into a couple years ago.
I was prototyping a generalized access control system inspired by the idea of “Object Capabilities”. Habitat Chronicles: What Are Capabilities?
TLDR; A capability is a token that both designates a resource and authorizes some kind of access to it.
The general idea was that a sway contract could mint access control tokens(fungible) and these tokens could be given to other contracts to allow them to access the minting contract. They also (used to have?) the nice property that for a given token id, there was only one contract that could have minted it, so the token itself identifies the resource to which it grants access. I’m not certain, but I think we’ve lost this propertie with changes to support native NFT’s.
FWIW, I talked with someone who implemented something similar on Ethereum as well.
Overall, I think NFT’s + access control is a fantastic match.
Great demo and approach! I really like how you’re leveraging NFTs for access control, and it’s interesting to see the comparison with the ‘Object Capabilities’ concept. NFTs seem like a great fit for permissioning in Fuel applications, and it’s exciting to see how this can evolve with future improvements!
