How do I check msg.sender in Cadence? Capabilities!
EDIT Oct 2024: The Cadence code in the article uses Cadence 0.42 which is incompatible with the current version of Cadence on all Flow networks. The themes and advice are all mostly still the same though but the code examples will need to be updated to the latest Cadence version.
Hello! My name is Josh Hannan and I am a smart contract engineer on the Flow Team at Dapper Labs. It has a been a while since I posted last. It has been a busy time for the Flow team. Things have been going fast here on the Flow team and we have a lot of awesome stuff in the works! Here is what I’ve been working on.
Epoch Smart Contracts
Have you gotten a chance to take a look at the Flow Staking Smart Contract yet? If you haven’t I would recommend checking out the documentation first, and then learning about how the staking contract works. It isn’t your typical NFT contract, so there might be some interesting design patterns and tools in there that you find useful!
The Flow Staking contract is just one part of a set of Cadence contracts that Flow will use to manage Epochs, the week-long periods where the node identity table is set and nodes prepare for the next epoch while running the network. The core logic of this part of the protocol is handled via smart contracts and we’re getting closer to bringing it to mainnet!
We’re going to put more extensive documentation ready soon, but I’ve created some Flow Improvement Proposals (FLIPs) for the smart contracts if you are curious about what they do!
- Epoch Cluster Quorum Certificate smart contract
- Epoch Distributed Key Generation (DKG) smart contract
- Epoch Lifecycle smart contract
We also have an open feature branch with all of the code and tests if you want to dive in, learn more, and potentially leave feedback!
Central Place to access my blog posts!
The team at Dapper Labs was kind enough to make an official blog post that lists all of my blog posts in this series!
They will update this post every time I post a new blog, so it’ll always be a single place you can use to access all of my blogs. Feel free to bookmark it to reference in the future!
If you don’t have any experience with Flow or Cadence, I would highly recommend going there and getting started with my first blog! 😃
Access Control
One question that every Solidity user asks when they start programming in Cadence is “how do I check msg.sender?". On Ethereum, checking msg.sender is used to identify the account that is calling a function and to modify that function's behavior appropriately. Doing so is key to identity, permissions, ownership and security on Ethereum. An ERC-20 contract lets users send tokens by checking msg.sender to see which tokens to move. A governance contract checks msg.sender to register the vote of the caller so they cannot vote again. There are many more examples.
Cadence does not have msg.sender and there is no transaction-level way for Cadence code to uniquely identify its caller. This isn’t only because it hasn’t been added. In Cadence, transactions can be signed by more than one account, so getting the msg.sender from that wouldn’t even make sense.
All of this means that a task that would be implemented by a single central contract checking msg.sender in Solidity will require a different approach in Cadence. The design of Cadence is intentionally different, it follows a Capability-based security model instead of an Access-Control List-based model. We believe that this design offers distinct advantages for code robustness and security.
One of the smart contract engineers on the Flow team, Rhea Myers, has created a document that describes why we cannot use msg.sender in Cadence, what we use instead, and examples for various different use cases where this feature is important. Capability Security is one of the most important aspects of Cadence’s design, and it is vitally important that you understand it if you ever want to build your own smart contracts.
Check out Rhea’s document here:
For my next few blog posts, I’m going to take some of the examples from Rhea’s document and expand on them, providing step-by-step tutorials for how to use capabilities for various types of smart contracts.
Conclusion
I hope this information is useful to you! As usual, please reach out to me via one of our channels if you have any questions or suggestions!
Flow Discord: https://discord.gg/flow
Flow Forum: https://forum.onflow.org
Flow Github: https://github.com/onflow/flow
See you next time! 👋
HUGE Thank you to Rhea Myers who provided the inspiration, intro, and much of the content that I speak about in regards to the main subject of the article!
