Flow

Flow is a permissionless layer-1 blockchain built to support the high-scale use cases of games, virtual worlds, and the digital assets that power them. The blockchain was created by the team behind Cryptokitties, Dapper Labs, and NBA Top Shot. One core attribute that differentiates flow from the other blockchains is its usage of capability-based access control. At its core, capability-based access control creates tokens of authority to give stakeholders selective access to certain resources without sharing everything. But why is this important for you as a Flow developer? With capabilities, you can define a user’s granular-level access privileges. So, if you’re building a music app and want to give the capability to access top playlists to only premium users, you can control that very easily with the built-in capabilities functionality of Flow. ( ) Source What is Blockchain authorization? Blockchain authorization is the methodology by which access to information and execution permissions are granted on a blockchain system. Several operations that a user may need to perform within a blockchain may include the following: Creating new smart contracts Updating smart contract code Executing smart contract functions Being a validator node Updating smart contract data If the methodology used to manage the execute permissions of the above operations is not fault-tolerant, then it could be a huge security risk for the application. There are several major types of authorization that have the same objectives but slightly different implementations. Access Control Lists (ACLs) Access Control Lists (ACLs) refer to the authentication mechanism that works on maintaining individual lists for managing access to different objects. ACLs are like guest lists for a resource. Those participants that are on the guest list of a certain object are allowed to access, and others are not. Role-based access control (RBAC) Role-based access control refers to the idea of assigning permissions to network participants on the basis of their role within an organization. The access rules are mapped to the roles rather than the individual identities. This is the most common form of authorization used in popular products like AWS. Capability-based authorization A capability is an unforgeable token of authority. In Capability-based authorization, your identity does not matter. If you receive an access token from the owner/admin that grants you the capability to access a resource, and you are able to execute that capability, then you will have access. At runtime, the application does not check what your identity is but only that you have the capability to access the requested resource. ACLs versus Capability-based authorization There are certain drawbacks to implementing ACLs, especially in the context of decentralization, which we’ll discuss below. Ambient Authority problem Let’s say that, as a user, you have received several different types of access and privileges to an app on your operating system. At some point, you request the app to fetch certain data for you. You would want to make sure that the app fetches only the data that’s absolutely necessary and doesn’t access anything else. However, in the case of ACL systems, there is no way to make sure this happens since the app has “ambient” authority. This can only be solved by using capability-based security systems. Watch to learn more. this video Confused Deputy problem Let’s say there’s a program A requesting a program B to perform certain actions. There might be instances where only program B has access to perform some of those actions, but program A does not. Program B still performs them because it didn’t double-check. In this case, program B was tricked into misusing its privileges by program A. This can be solved by using capabilities. Watch to learn more. Here’s how the company 25 years ago. this video Tymshare faced this problem ACL attack vector Because ACL lists are usually maintained with a centralized owner, it is prone to malicious updates at any time. Using capabilities takes away the power of performing malicious updates from a centralized owner and hence makes the system secure from the large ACL attack vector. ( ) Source About Capabilities A capability (also known as the ‘key’) is a hash that designates both the resource and access to it. This is also the model implemented in Bitcoin, where “your key is your money,” and in Ethereum, where “your key is gas for EVM computations.” In the Flow blockchain, “your keys are your data,” and hence, data access is controlled directly by keys instead of identities. By tying access to the key, capability-based models push security to the edge, decentralizing large attack vectors. Capabilities also make it very easy to write code that defines security privileges in a granular fashion. There are two major types of capabilities in Flow blockchain: Public capabilities Public capabilities are created using public paths and hence have the domain “public”. After creation, users can access them with authorized accounts (“AuthAccount”) and public accounts (“PublicAccount”). Private capabilities Private capabilities are created using private paths and hence have the domain “private”. After creation, they can only be accessed by authorized accounts (“AuthAccount”) and not by public accounts (“PublicAccount”). 3 Tenets of Capability-based Security — Capability-based security always has an unforgeable key to go with a particular access. This means that just the identity of a participant is not enough to get access. Encryption-based — Capability-based security is totally decentralized. This means that the success of the security system is not dependent on a single owner. Decentralized — It is easier to define fine-grained access to data and resources using capability-based security. Granular Creating a capability in Cadence Cadence is the programming language used to create Flow contracts. Below, we’ll talk about the code used to create capabilities in Cadence. Creating capability using a link function The link function of an authorized account (“AuthAccount”) is used to create a capability. fun link<T: &Any>(_ newCapabilityPath: CapabilityPath, target: Path): Capability<T>? is the public or private path identifying the capability newCapabilityPath is any public, private, or storage path that leads to the object that will provide the function defined by this capability target is the type parameter for the capability type T The above function will: return nil if the link for a given capability path already exists return the capability link if the link doesn’t already exist Removing capability using the unlink function The unlink function of an authorized account (“AuthAccount”) is used to remove a capability. fun unlink(_ path: CapabilityPath) is the public or private path of the capability that should be removed path Other important functions getLinkTarget This function can be used to get the target path of a capability. fun getLinkTarget(_ path: CapabilityPath): Path? getCapability This function can be used to get the link to existing capabilities. fun getCapability<T>(_ at: CapabilityPath): Capability<T> check This function is used to check if the target currently exists and can be borrowed. fun check<T: &Any>(): Bool borrow This function is used to borrow the capability and get a reference to a stored object. fun borrow<T: &Any>(): T? Code examples of creating a capability with Cadence We will follow a simple example where: Step 1: We will create a smart contract with a function as a resource. Step 2: We will access the resource. Create a capability to access the resource in that smart contract. Create a reference to that capability using the borrow function. Execute the function resource. Step 1: Creating a car smart contract Explanations are in the comments below: pub contract Car {
    // Declare a resource that only includes one function.
    pub resource CarAsset {
        // A transaction can call this function to get the "Honk Honk!"
        // message from the resource.
        pub fun honkHorn(): String {
            return "Honk Horn!"
        }
    }
    // We're going to use the built-in create function to create a new instance
    // of the Car resource
    pub fun createCarAsset(): @CarAsset {
        return <-create CarAsset()
    }
    init() {
        log("Creating CarAsset")
    }
} Step 2: Accessing the honkHorn() function in the CarAsset resource of Car smart contract The code below includes all three steps: Creating the capability to access the resource from CarAsset Creating a reference by borrowing the capability Executing the HonkHorn function Explanations are in the comments below: import Car from 0x01

// This transaction creates a new capability
// for the CarAsset resource in storage
// and adds it to the account's public area.
//
// Other accounts and scripts can use this capability
// to create a reference to the private object to be able to
// access its fields and call its methods.

transaction {
  prepare(account: AuthAccount) {

    // Create a public capability by linking the capability to
    // a `target` object in account storage.
    // The capability allows access to the object through an
    // interface defined by the owner.
    // This does not check if the link is valid or if the target exists.
    // It just creates the capability.
    // The capability is created and stored at /public/CarAssetTutorial, and is
    // also returned from the function.
    let capability = account.link<&Car.CarAsset>(/public/CarAssetTutorial, target: /storage/CarAssetTutorial)

    // Use the capability's borrow method to create a new reference
    // to the object that the capability links to
    // We use optional chaining "??" to get the value because
    // result of the borrow could fail, so it is an optional.
    // If the optional is nil,
    // the panic will happen with a descriptive error message
    let CarReference = capability.borrow()
      ?? panic("Could not borrow a reference to the Car capability")

    // Call the honkHorn function using the reference
    // to the CarAsset resource.
    //
    log(CarReference.honkHorn())
  }
} If you execute the above function, you should see the message “Honk Honk!” in your console. Refer to to learn how to deploy a contract and execute Cadence code. this tutorial Conclusion In this article, we learned the types of blockchain authorization and the added advantage of using capabilities over other methods of authorization. We also learned how to create, execute, and transfer capabilities in Cadence, the smart contract language of Flow blockchain. These learnings will help you as a developer to write highly secure code when building on Flow. In essence, capabilities open up a new paradigm of blockchain authorization, making it very easy for developers to define access at a granular level. The fact that Flow blockchain uses this paradigm for data access makes it one of the most secure blockchain options out there. And as you probably noticed, it is super easy to create capabilities in Flow. I hope that you enjoyed this deep dive into capability-based security in Flow blockchain. You can refer to the on Capabilities to learn more. I also recommend that you get your hands dirty by going through and this . official docs page Flow Docs tutorial on Capabilities Also published . here

Moving to Capability-Based Security with Flow: A Critical Evolution in Blockchain Security

is a permissionless layer-1 blockchain built to support the high-scale use cases of games, virtual worlds, and the digital assets that power them. The blockchain was created by the team behind CryptoKitties, Dapper Labs, and NBA Top Shot. Flow One of the best features of Flow is that it supports the paradigm of resource-oriented programming. Resource-oriented is a new way of managing memory where resources are held “in-situ” by the resource owner instead of in a separate ledger. This is very relevant for managing scarce and unreplicable digital resources on the blockchain. programming In this article, I’ll do a deep dive into resource-oriented programming—and allow you to better manage your resources in your Flow smart contracts. What is resource-oriented programming? In resource-oriented programming, objects are labeled as “resources.” Resources are a collection of variables and functions that only have exactly one copy at a time. Resources provide better composability than EVM and WASM. When something is called a resource, there are very specific rules for interacting with it. The three rules that apply to resources in resource-oriented programming are as follows: Each resource exists in only one memory location - Resources cannot be duplicated. Ownership of a resource is defined by where it is stored - No central ledger that keeps track of ownership. Only the owner of the resource can access its methods. To explain this better; in the real world, if you claim to own a watch, that ownership is proven by the fact that you possess it yourself. There is no central ledger that people refer to check if you are the owner. However, in programming, when we think of ownership, we think of a mapping somewhere in a ledger of the object ID to the owner ID. For example, in the case of ERC721 smart contracts, the ownership of digital assets is stored in a ledger owned by the main smart contract. Flow changes this paradigm of ownership by storing “resources” in the memory location owned by the owner itself (see image below). This means that if you’re holding a digital asset on the Flow blockchain, it is stored in the memory location of the account that you own. This has several benefits, which we’ll talk about in the coming section. Resources in Cadence is the world’s first high-level resource-oriented programming language. , created for Facebook’s now-defunct Diem, is the only other language that is resource-oriented, but it is more low-level. Cadence Move In Cadence, resources are defined using the “resource” keyword. Within a resource, you can define the attributes of the resource, like variables and functions. This definition of a resource now becomes a type and can be used to create objects of that type.\ An example of creating a resource and creating an instance of that resource is shown below: // Declare a resource that only includes one function.    pub resource CarAsset { // A transaction can call this function to get the "Honk Honk!"        // message from the resource.        pub fun honkHorn(): String {            return "Honk Horn!"        }    } // We're going to use the built-in create function to create a new instance    // of the Car resource    pub fun createCarAsset(): @CarAsset {        return <-create CarAsset()    } Destroy function Resources in Cadence can be explicitly destroyed using the “destroy” keyword. The Move Operator (<-) To make the moves of a resource explicit, the Move operator, such as “<-” must be used when: Initializing the value of a constant or variable with a resource Moving resources to a different variable Moving resources to the argument of a function Returning it from a function Code Example of Creating a Resource in Cadence Below is an example of a Cadence script that creates a CryptoKitty collection as a resource and also stores individual Kitties as a resource. contract CryptoKitties {// Accounts store a collection in their account storage  resource KittyCollection {// Each collection has functions to// move stored resources in and out  fun withdraw(kittyId: int): CryptoKittyfun deposit(kitty: CryptoKitty)}  // The resource objects that can be stored in the collectionresource CryptoKitty {}} transaction(signer: Account) {// Removes the Kitty from signer's collection, and stores it// temporarily on the stack. let theKitty <- signer.kittyCollection.withdraw(kittyId: myKittyId) // Moves the Kitty into the receiver's accountlet receiver = getAccount(receiverAccountId)receiver.kittyCollection.deposit(kitty: <-theKitty)} In the above code, we create a KittyCollection resource that has several CryptoKitty sub-resources within it. We then do a transfer transaction to transfer a Kitty from one user account to another. Other things to keep in mind Resources must be created using the “create” keyword. At the end of a function with resources, the resources should either be moved or destroyed. Accessing a field or a function of a resource does not destroy it. When a resource is moved, the constant or variable currently holding the resource becomes invalid. To make a resource type explicit, the prefix @ must be used in type annotations. Comparison and Benefits Resource-oriented programming versus ledger-based systems A common comparison of the ownership structure in resource-oriented programming is with ledger-based ownership. In the ledger model, like in ERC721 smart contracts, every time you have to update ownership, you need to update the mapping of the ID in a shared ledger. In resource-oriented programming, resources are stored within the account of the owner itself, so transferring a digital asset only means moving the resource from the first party to the second. This does not require updating any ledgers. Resource-oriented programming is more suitable for blockchain use cases like digital assets than the traditional ledger system. Benefits of resource-oriented programming There are several benefits that resource-oriented programming brings to the table. Let’s look at some of them below. Makes capability-based security possible Resource types provide the foundation on which capability-based security can be established. Capabilities are one of the best methods to create highly secure blockchain authorization systems. This brings the utmost security to the Flow blockchain. Eliminates reentrancy attacks Reentrancy attacks are one of the most severe smart contract vulnerabilities often exploited by hackers. In a reentrancy attack, a hacker calls the withdraw function on a smart contract recursively. This way, they are able to drain the entire funds of a smart contract. Since methods within a resource cannot be accessed by anyone but the owner, there is no possibility of a reentrancy attack. Better pricing and cost management In Ethereum, the CryptoKitties contract has 2 million digital assets collectively taking up more than 100 MB of space, living rent-free on the Ethereum blockchain. In an ideal world, it should be possible to charge the owners of Kitties based on how much of this data belongs to them on-chain. In Flow, since the resource is directly stored in the account of the owner, it is clear who needs to pay the cost for that data. Conclusion Resource-oriented programming is a new and innovative programming paradigm that has been brought to the blockchain world by the Flow blockchain. It makes resource management very efficient, easy, and secure. It also helps provide a better cost-sharing model for running blockchain infrastructure. You can refer to the on Resources to learn more. I also recommend that you get your hands dirty by going through and this . official docs page Flow Docs tutorial on Resources

The Power of Resource-Oriented Programming in Flow/Cadence: A Deep Dive

Many alternative blockchains that have emerged recently are classified as “EVM” chains, meaning they operate exactly like but have a different execution layer. This helps the cross-compatibility of smart contracts across chains, but it doesn’t solve some of the crucial problems embedded in the EVM system. In particular, it hasn’t improved how user accounts are handled and protected. Ethereum , a layer-1 blockchain, is trying to change that pattern with its account model. In this article, we’ll look in detail at that new account model, how it works, and how it might be able to solve some of the most difficult UX problems in blockchain. Flow How do Accounts on Ethereum Work? One of the best ways to understand how the Flow account model excels is to compare it to Ethereum. There are two types of accounts on Ethereum: externally owned accounts (EOA), which are your typical consumer wallets, and then smart contract accounts. EOAs have a public and private key pair, where the public key is derived from the private key and works as an address for the account, and the private key signs transactions on the blockchain. They can hold a balance and interact with other accounts, primarily smart contract accounts. These smart contract accounts are compiled byte code that runs on the Ethereum Virtual Machine. What’s really interesting is that any data created by the smart contract, such as tokens or NFTs, is stored in that smart contract. Instead of an EOA truly owning the token, the smart contract simply says who owns what and how much. Ethereum’s potential security gaps Not only is true digital ownership conceded, but smart contracts on Ethereum are hard to read and audit for security. A great number of scams and “rug pulls” have occurred on EVM chains because of this power imbalance. Such a scam would usually look like this: A website, which looks very similar to a popular NFT project, touts a new collection at a reasonable mint price. People visit the site, connect their wallet, and when they click that mint button, they will likely get a screen with a bunch of blockchain byte code that tells them nothing about what will happen if they sign. It could just mint an NFT, or it could completely deplete their wallet. Without the ability to read the transactions well, wallets are not able to give the end user much info as to what will happen when they sign. (Note that Flow, covered in more detail below, has a better transaction format that allows wallets to clearly tell the end user what will happen when they sign, giving more balance and control to the user.) How do Accounts on Flow work? The Flow account model combines the concepts of the EOA and smart contract accounts from Ethereum into a single standard. In this model, the account and the public keys are decoupled. As stated earlier, Ethereum accounts only have a public and private key, and they are tied to the account itself. This is important as it enables better control and reduces potential mistakes made by the end user, ultimately helping protect their assets. With the , you can have a single account with multiple public and private keys. Having multiple keys is a huge advantage because you can revoke or rotate keys that might be compromised, again giving the user better control and security. Not only that, but these keys are weighted keys, giving them the ability to do more complex transactions such as multiple signatures.These signatures are used frequently in blockchain to let multiple users sign one transaction, similar to how you might need two keys to open a bank vault. In the EVM model this has to be built out manually, but with Flow it is readily available. Flow account model Since there can be multiple keys for one account, the way Flow creates addresses is also unique. Unlike Ethereum—where addresses are derived from the public key—Flow account addresses are created with an internal on-chain checksum at the protocol level. This ensures addresses are unique. In addition, Flow gives developers and users the option of different signature and hash algorithm curves, such as secp256k1 (used primarily by Bitcoin and other cryptocurrencies) or the more flexible P-256 (which is adopted by most cell phones and computers). These options provide better flexibility and compatibility with other protocols and ultimately give users top-notch security, all on devices they already use daily. And since encryption and cryptography are always evolving, it’s critical and necessary to adopt the latest standards. Storage with Flow Another thing unique to Flow’s account model is its storage capabilities. On Ethereum, only smart contract accounts have the ability to store data and thus truly own assets. You can think of it like leasing a car: if you lease one, you do get to drive it and park it at your house, but it's not truly yours. There’s a contract saying you own the car under certain terms, and the ultimate power is in that contract— and its terms may not always favor the lessee. On the other hand, Flow accounts allow for asset storage and for accounts to deploy their own smart contracts. The account storage used is calculated by the byte size of data currently stored in the account, and it is directly tied to the balance of Flow tokens on the account. True digital ownership: buy, don’t lease This is truly special as it gives users the ability to truly own the digital items they purchase, rather than a smart contract putting their name on it. Flow manages this storage by the number of Flow tokens the account has, including a minimum storage feed of 0.001 $FLOW, which equates to 100Kb of data. (This is to make sure it can handle any incoming assets.) If, for any reason, the account attempts a transaction that would exceed its storage capacity, then the transaction will fail. In the Flow account model, that car is in your garage with no contracts tied to it! Paid in full. Conclusion Flow is trying to diverge from the normal EVM path. In the Ethereum world, there are many cases of users losing funds partly due to the account model on EVM chains, which makes it difficult for users to read and interpret what will happen when they press a button on a website. Flow aims to empower users to own their digital assets and ensure funds will only leave their accounts with their permission. Flow also gives developers flexibility, making things like multi-signature weighted keys native to the platform, as well as multiple signature and hashing algorithms to choose from for the best compatibility among devices and networks. It’s early, but these kinds of features are needed in Web3 UX and could be a potential game-changer.

Giving Power Back to Your Users with Flow’s Account Model

Blockchain has the potential to revolutionize the way we interact with the digital world. It promises security, transparency, and decentralization. However, for most people, getting started with blockchain can be confusing and intimidating. The need to manage private keys and wallets can be a significant hurdle. To , developers have been exploring ways to simplify the process, and one exciting concept is . In this article, we’ll look at what abstraction is and how it creates a better wallet experience. Later, we’ll take a detailed look at how it is implemented on , a blockchain-focused on mainstream web3 adoption and used by companies such as the NBA, NFT, Ticketmaster, and Mattel. make blockchain more accessible abstraction web3 Flow What is abstraction? In the realm of computer science and software development, abstraction is a fundamental concept. Abstraction simplifies a system by removing certain characteristics to reduce complexity and enhance efficiency. For most blockchain users, dealing with private keys and wallets can be intimidating and inconvenient. Abstraction in blockchain aims to address this issue. There are two primary ways to manage keys and assets in the blockchain: user custody and application custody. User Custody This is considered the safest and most ideal version of blockchain management. With user custody, you hold your own keys on a device like your computer or phone. A special software called a "wallet" helps manage access to your keys. When you use a blockchain application, it asks your wallet for permission to do things like send money, and you get to approve or deny these requests. User custody gives you full control and security over your assets. Application Custody On the other hand, application custody is an approach in blockchain where the responsibility of managing private keys and wallet software is shifted from the user to the application or service provider. Let’s see how it works and why it's valuable: With application custody, the user onboarding process is designed to be extremely user-friendly, similar to how people sign up for traditional online services. Users are not required to install any wallet software or deal with the complexities of managing private keys. They can create an account with the blockchain application just as they would with any other web2 service, using a username and password or other familiar credentials like their Google or Facebook login. User-Friendly Onboarding: In an application custody model, users don't have to worry about onerous wallet management, such as securely storing private keys or making backups. This simplification is especially attractive to users who are new to blockchain technology and may find the concept of wallets and private keys confusing. No Wallet Management: Application custody also enables blockchain applications to accept traditional payment methods, such as credit cards for web-based applications or native in-app purchases for mobile apps. This means that users can pay for blockchain-based services using methods they are already familiar with, making the payment process seamless and comfortable. Traditional Payment Methods: Another advantage of application custody is that applications can manage the assets within the user's account directly, all without needing to request user consent for every action. For example, if a user purchases an item within a mobile game using in-app purchases, they don't have to repeatedly approve each transaction through their wallet. This streamlines the consent process and feels more like the traditional web2 user experience. Reduced User Consent: Application custody isn’t just convenient; it also prioritizes a user-friendly onboarding experience by handling key management and wallet complexities on behalf of the user. However, it limits the portability of assets outside of the application, which is where the concept of account abstraction (specifically account delegation) comes into play. Abstraction bridges the portability gap and offers users more control and flexibility over their . blockchain assets The Solution - Connecting both worlds with abstraction To solve this issue and to create a balance between user custody and application custody, developers are turning to something called "account abstraction," specifically, "account delegation." Account delegation refers to a dynamic in which any account that has a valid capability to another account object in the storage can access it. This feature allows one blockchain account to delegate control to another. The account that delegates (the "child" account) still uses cryptographic keys, but the owner of the other account (the "parent" account) gains access to its assets. Importantly, the child account must give permission for this access, and it can take it back at any time. This connection between accounts forms a hybrid custody model that combines the benefits of both user and application custody. How it works Here's how it works in simple terms: New users, who might find the idea of managing keys intimidating, can sign up for an account without dealing with wallets. It's similar to signing up for any other online service. Easy Start: As users become more familiar with blockchain and gain confidence in managing their keys, they can delegate control of their app-custody account to their self-custody account. Growing Confidence: With their own keys on their own devices, users can access all their assets in both accounts. They keep control while still letting the application manage assets in the child account, reducing the need for constant interactions with wallets. Full Control: Because this delegation relationship is tracked on the blockchain, the application can recognize it and access the assets in the parent account when necessary. This makes it easy for users to move assets between accounts for seamless access. Interoperability: Deep dive into walletless building Before moving forward, it's important to understand the concept of account linking, a unique Flow concept that enables the sharing of ownership over accounts. (the smart contract programming language for Flow) provides two ways to access Flow accounts: Cadence This gives you access to public account info like address, balance, and storage, but you can't make changes. PublicAccount: With AuthAccount, you get the same access plus the ability to make changes, like adding/removing keys and managing contracts. AuthAccount: With Cadence, you can create permissions to share access to account storage. This means if an account has valid permission to access another account's storage, it can get in. You can also control what parts of the storage can be accessed with these permissions. Account linking is doable by adding these permissions to the AuthAccount object. Just like storage permissions allow access to data stored in an account, AuthAccount permissions enable access to the AuthAccount itself. When we talk about "account linking," it's like a parent account sharing a special access card (AuthAccount capability) with another account, making it their child account. This happens in two simple steps on Flow: The child account creates and shares the AuthAccount capability with the parent account. Implementation in code: Create Capability transaction {
    prepare(signer: AuthAccount) {
        let capability = signer.linkAccount(/private/accountCapA)!
        signer.inbox.publish(capability, name: "accountCapA", recipient: 0x1)
    }
} The parent account can then use this capability to access the child's account easily. Implementation in code: Claim Capability transaction {
    prepare(signer: AuthAccount) {
Let capability = signer.inbox.claim<&AuthAccount>("accountCapB", provider: 0x2)!
        let accountRef = capability.borrow()!
    }} Why is account linking useful? Account linking was created to help users easily join your Flow-based app without needing a wallet first. This makes it simple for everyone to use Flow apps without technical issues or the need to install a wallet. You can enjoy apps right away and also have the option to own your data later on. With account linking, users can connect multiple app accounts together. You don't need to worry about the complexities of accessing these accounts because it's all managed through one main account. The best part? Assets can move freely between these accounts without any extra transactions. Your app account can now interact with the broader Flow ecosystem seamlessly. With this feature, users can have full control over their digital items in their in-app account. This means they truly own these items, not just within the app but also outside it. They can easily view their inventory using their parent account and even use these items in other apps, like a marketplace or a game. The best part is they can do all this without the hassle of transferring items between accounts, making it super convenient to use multiple apps at once. Conclusion Blockchain development is evolving to make it easier for everyone to get involved. Abstraction, through account delegation, is a key part of this evolution. It combines the safety of user custody and the convenience of application custody, allowing users to transition smoothly from beginners to experts in . As blockchain technology continues to grow, these innovative ideas will help make it more accessible to everyone. the blockchain world Have a really great day! Also published . here

Simplifying Blockchain: How Abstraction is Revolutionizing the Web3 Wallet Experience on Flow

Welcome to the final step in creating your Collectibles portal! of this short series focused on building the collections portal. In this part, we'll focus on building the front end—the last piece of the puzzle. Here's what we'll achieve: Part one Connect with Flow Wallet: You'll be able to link your Flow Wallet. Create NFTs (Mint): You can make your very own by confirming the transaction. NFTs View NFTs: You'll be able to see your NFTs by asking the blockchain. We will work with React.js and an existing smart contract on Flow's testnet. This smart contract is the same Collectibles contract we crafted in part 1. Here are the steps we will follow to get there: : Setting things up and getting ready to go. Installation : Getting everything in order for a smooth operation. Configuration : Making sure you're securely connected. Authentication : Asking the blockchain for information. Querying the Flow Blockchain : Preparing your account for action. Setting up the Account : Modifying the blockchain as needed. Mutating the Flow Blockchain : Keeping track of your code. Final Step Are you ready to dive into creating your Collectibles Portal's front end? Let's get started! 1. Installation First, we need to create a React app using a tool called Yarn. To do this, open your terminal and type: yarn create react-app web After pressing Enter, your computer will begin creating a new React app inside your project. When it's done, you can open your new app. This is what your React app looks like. 2. Configuration We'll use the to manage wallet connections, run scripts, and send transactions in our application. Flow Client Library (FCL) To get started, let's install FCL for our app by running the following command: npm install @onflow/fcl --save After installing FCL, we need to configure it. Here's what you need to do: Create a file named config.js in the src folder. In this file, set up the configuration for the FCL, such as specifying the Access Node and wallet discovery endpoint. This helps you choose between using a testnet or a local emulator. Add the following code to the config.js file: import { config } from "@onflow/fcl";

config({
  "accessNode.api": "https://rest-testnet.onflow.org", // Mainnet: "https://rest-mainnet.onflow.org"
  "discovery.wallet": "https://fcl-discovery.onflow.org/testnet/authn" // Mainnet: "https://fcl-discovery.onflow.org/authn"
}) Now, you're all set up to use the FCL in your app. 3. Authentication To verify a user's identity in an app, you can use several functions. For logging in use . fcl.logIn() For signing up use . fcl.signUp() For logging out call . fcl.unauthenticate() After logging in, an object named is set up. This object allows you to watch for changes in user data, perform transaction signings, and more. Let's add several buttons for sign up/login and also subscribe to changes on the . When the user is updated (which will happen after authentication), we'll set the user state in our component to reflect this. To demonstrate user-authenticated sessions, we'll conditionally render a component based on whether the user is or is not logged in. Your code should look like this: fcl.currentUser currentUser import React from "react";
import './styles/App.css';
import "./config";
import * as fcl from "@onflow/fcl";

const App = () => {

  const [user, setUser] = useState({loggedIn: null})

  useEffect(() => fcl.currentUser.subscribe(setUser), [])

  const AuthedState = () => {
    return (
      <div>
        <div className="sub-text">Wallet Address: {user?.addr ?? "No Address"}</div>
        <button className="cta-button connect-wallet-button" onClick={fcl.unauthenticate}>
          Log Out
        </button>
      </div>
    )
  }

const UnauthenticatedState = () => {
    return (
        <button className="cta-button connect-wallet-button" onClick={fcl.logIn}>
          Log In
        </button>
    )
  }
  return (
    <div className="App">
      <div className="container">
        <div className="header-container">
          <p className="header gradient-text">Flow Collectibles Portal</p>
          <p className="sub-text">Upload your favorite collectibles to the Flow Blockchain</p>
          {user.loggedIn ? <AuthedState /> : <UnauthenticatedState />}
        </div>
      </div>
    </div>
  );
};

export default App; Now, you can either log in or sign up as a user and then log out. When you log in or sign up, a small window will pop up. In that window, you can pick a wallet provider. For this instance, let's pick the Blocto wallet to make an account. After you successfully prove it's you, you will see your wallet address on the screen like this: 4. Querying the Flow Blockchain When you're , a key task is to retrieve data from the blockchain and the smart contracts it holds. Let's understand how we can query a contract to find out about a specific NFT. Here's a simplified breakdown of the steps involved: building a dapp Import Contracts: First, you need to import the relevant contracts used in your dapp. In this example, we're interested in querying the NFTs, so we're importing the NonFungibleToken and Collectibles contracts. Use FCL: You create a function called queryNFT, which is asynchronous. Inside this function, you use the fcl.query function to query the blockchain. Set the result of the script to the app state in React so we can display the NFT in our browser. Display: Display "No NFT" if nothing was found. Take a look at the new code. We'll explain each new piece as we go. const [user, setUser] = useState({loggedIn: null})
const [nft, setNFT] = useState() //NEW

useEffect(() => fcl.currentUser.subscribe(setUser), [])

  // NEW
  const queryNFT = async () => {
    const nft = await fcl.query({
      cadence: `
        import NonFungibleToken from 0x631e88ae7f1d7c20
        import Collectibles from 0x490b5c865c43d0fd

        pub fun main(user: Address, id: UInt64): &NonFungibleToken.NFT? {
          let collectionCap= getAccount(user).capabilities
                      .get<&{Collectibles.CollectionPublic}>(/public/NFTCollection) 
                      ?? panic("This public capability does not exist.")

          let collectionRef = collectionCap.borrow()!

          return collectionRef.borrowNFT(id: id)
        }
      `,
      args: (arg, t) => [arg(user.addr, t.Address)]
    })

    setNFT(nft ?? 'No NFT')
  }

const AuthedState = () => {
    return (
      <div>
        <div className="sub-text">Wallet Address: {user?.addr ?? "No Address"}</div>
        <div className="sub-text">NFT: {nft ?? "--"}</div>
       <button className="cta-button" onClick={queryNFT}>View NFT</button>
       <button className="cta-button connect-wallet-button" onClick={fcl.unauthenticate}>
          Log Out
        </button>
      </div>
    )
  } A few things happened. In our AuthedState component, we added a button to send a query to view the NFT and a div to display the result above it. You can see the corresponding useState initialization at the top of the component. We also built out the actual query inside of the queryNFT method. Let's take a look at it more closely. await fcl.query({
      cadence: `
        import NonFungibleToken from 0x631e88ae7f1d7c20
        import Collectibles from 0x490b5c865c43d0fd

        pub fun main(user: Address, id: UInt64): &NonFungibleToken.NFT? {
          let collectionCap= getAccount(user).capabilities
                      .get<&{Collectibles.CollectionPublic}>(/public/NFTCollection) 
                      ?? panic("This public capability does not exist.")

          let collectionRef = collectionCap.borrow()!

          return collectionRef.borrowNFT(id: id)
        }
      `,
      args: (arg, t) => [arg(user.addr, t.Address)]
    }) Inside the query, you'll see we set two things: cadence and args. Remember that the Cadence code is specific to Flow's smart contract language, and you don't need to dive too deep into it unless you're working on writing more complex smart contracts. The key takeaway is that you're querying the blockchain to get NFT information based on the user's account address and the NFT ID. When you click the "View NFT" button, you'll see the NFT details, or if the NFT doesn't exist, it will display "No NFT". 5. Setting up the Account We use a process called "collection initialization” to set up a Collection resource in the user’s account. (We covered what a resource is in Part 1. You can review that here.) To make this happen, we’ll add a new function called "initAccount.” We'll use a code that asks, "Hey, does this account already have a Collection? If not, let's create one." We use something called a "transaction" to do this. Think of a transaction as a special task we want the system to do for us. Now, let's talk about how we write this code. Instead of saying "query," we use the word "mutate" for transactions. Since doing this task has a cost, we need to provide some information to Flow. We tell Flow who is suggesting the task, who is approving it, who is paying for it, and how much they're willing to pay. These parts are called "proposer," "authorizer," "payer," and "limit." Let's take a look at what the function to set up an account looks like. const initAccount = async () => {
  const transactionId = await fcl.mutate({
    cadence: `
    import Collectibles from 0x490b5c865c43d0fd

    transaction {
    prepare(signer: AuthAccount) {
        if signer.borrow<&Collectibles.Collection>(from: Collectibles.CollectionStoragePath) == nil {
            let collection <- Collectibles.createEmptyCollection()
            signer.save(<-collection, to: Collectibles.CollectionStoragePath)
            let cap = signer.capabilities.storage.issue<&{Collectibles.CollectionPublic}>(Collectibles.CollectionStoragePath)
            signer.capabilities.publish( cap, at: Collectibles.CollectionPublicPath)
        }
    }
    `,
    payer: fcl.authz,
    proposer: fcl.authz,
    authorizations: [fcl.authz],
    limit: 50
  })

  const transaction = await fcl.tx(transactionId).onceSealed()
  console.log(transaction)
} You can see the new fields we talked about. You'll also notice , which is shorthand for "use the current user to authorize this transaction.” You could also write it as . fcl.authz fcl.currentUser.authorization For this example, we'll keep it simple with the user being each of these roles. You'll also notice we are awaiting a response with our transaction data by using the syntax . This will return when the blockchain has sealed the transaction and it's complete in processing and verifying it. Now, your App.js file should look like this. (we also added a button for calling the function in the ): fcl.tx(transactionId).onceSealed() initAccount AuthedState const App = () => {

  const [user, setUser] = useState({loggedIn: null})
  const [nft, setNFT] = useState() //NEW
  const [txnStatus, setTxnStatus] = useState(null)

  useEffect(() => fcl.currentUser.subscribe(setUser), [])

  // NEW
  const queryNFT = async () => {
    const nft = await fcl.query({
      cadence: `
        import NonFungibleToken from 0x631e88ae7f1d7c20
        import Collectibles from 0x490b5c865c43d0fd

        pub fun main(user: Address, id: UInt64): &NonFungibleToken.NFT? {
          let collectionCap= getAccount(user).capabilities
                      .get<&{Collectibles.CollectionPublic}>(/public/NFTCollection) 
                      ?? panic("This public capability does not exist.")

          let collectionRef = collectionCap.borrow()!

          return collectionRef.borrowNFT(id: id)
        }
      `,
      args: (arg, t) => [arg(user.addr, t.Address)]
    })

    setNFT(nft ?? 'No NFT')
  }

  // NEW
  const initAccount = async () => {
  const transactionId = await fcl.mutate({
    cadence: `
    import Collectibles from 0x490b5c865c43d0fd

    transaction {
    prepare(signer: AuthAccount) {
        if signer.borrow<&Collectibles.Collection>(from: Collectibles.CollectionStoragePath) == nil {
            let collection <- Collectibles.createEmptyCollection()
            signer.save(<-collection, to: Collectibles.CollectionStoragePath)
            let cap = signer.capabilities.storage.issue<&{Collectibles.CollectionPublic}>(Collectibles.CollectionStoragePath)
            signer.capabilities.publish( cap, at: Collectibles.CollectionPublicPath)
        }
    }
    `,
    payer: fcl.authz,
    proposer: fcl.authz,
    authorizations: [fcl.authz],
    limit: 50
  })

  const transaction = await fcl.tx(transactionId).onceSealed()
  console.log(transaction)
}

  const mintNFT = async () => {
  const transactionId = await fcl.mutate({
    cadence: `
      import Profile from 0xProfile

      transaction(name:String, image:String){
        let receiverCollectionRef: &{NonFungibleToken.CollectionPublic}
        prepare(signer:AuthAccount){
          self.receiverCollectionRef = signer.borrow<&Collectibles.Collection>(from: Collectibles.CollectionStoragePath)
              ?? panic("could not borrow Collection reference")
        }
        execute{
          let nft <- Collectibles.mintNFT(name:name, image:image)
          self.receiverCollectionRef.deposit(token: <-nft)
        }
      }
    `,
    args: (arg, t) => [arg("Pikachu", t.String),arg("https://cdn.pixabay.com/photo/2020/08/29/16/08/pikachu-5527377_640.jpg",t.String)],
    payer: fcl.authz,
    proposer: fcl.authz,
    authorizations: [fcl.authz],
    limit: 50
  })

  fcl.tx(transactionId).subscribe(res => setTxnStatus(res.status))
}


    const AuthedState = () => {
    return (
      <div>
        <div className="sub-text">Wallet Address: {user?.addr ?? "No Address"}</div>
        <div className="sub-text">NFT: {nft ?? "--"}</div>
        <div className="sub-text">Transaction Status: {txnStatus ?? "--"}</div>
        <button className="cta-button" onClick={queryNFT}>View NFT</button>
        {/*NEW*/}
        <button className="cta-button" onClick={initAccount}>Create Collection</button>
        <button className="cta-button" onClick={mintNFT}>Mint</button>
        <button className="cta-button connect-wallet-button" onClick={fcl.unauthenticate}>
          Log Out
        </button>
      </div>
    )
  }


  const UnauthenticatedState = () => {
    return (
        <button className="cta-button connect-wallet-button" onClick={fcl.logIn}>
          Log In
        </button>
    )
  }

  return (
    <div className="App">
      <div className="container">
        <div className="header-container">
          <p className="header gradient-text">Flow Collectibles Portal</p>
          <p className="sub-text">Upload your favorite collectibles to the Flow Blockchain</p>
          {user.loggedIn ? <AuthedState /> : <UnauthenticatedState />}
        </div>
      </div>
    </div>
  );
};

export default App; Click the "Init Account" button. This will prompt your wallet to ask for permission to complete a transaction. Once you give permission, you'll notice a message about the transaction in the console. (Make sure the console is open.) This might take a short while. Once the message shows the result of the transaction, you can use the transactionId to find out more details about the transaction using a . block explorer 6. Mutating the Flow Blockchain After initializing the account and setting up the collection resource into it, we now and store it in the collection. To do this, we will write another transaction that allows us to mint the NFT. Everything else looks the same in the following code except for one thing: We'll subscribe to the status changes instead of waiting for them to be sealed after the mutate function returns. It looks like this: mint the NFT const executeTransaction = async () => {
const transactionId = await fcl.mutate({
    cadence: `
      import NonFungibleToken from 0x631e88ae7f1d7c20
      import Collectibles from 0x490b5c865c43d0fd

      transaction(name:String, image:String){
        let receiverCollectionRef: &{NonFungibleToken.CollectionPublic}
        prepare(signer:AuthAccount){
          self.receiverCollectionRef = signer.borrow<&Collectibles.Collection>(from: Collectibles.CollectionStoragePath)
              ?? panic("could not borrow Collection reference")
        }
        execute{
          let nft <- Collectibles.mintNFT(name:name, image:image)
          self.receiverCollectionRef.deposit(token: <-nft)
        }
      }
    `,
    args: (arg, t) => [arg("Pikachu", t.String),arg("https://cdn.pixabay.com/photo/2020/08/29/16/08/pikachu-5527377_640.jpg",t.String)],
    payer: fcl.authz,
    proposer: fcl.authz,
    authorizations: [fcl.authz],
    limit: 50
  })

  fcl.tx(transactionId).subscribe(res => setTransactionStatus(res.status))
} Here you can see our two arguments which are "Pikachu” and image URL “ ”. At the bottom, we've called the subscribe method instead of onceSealed. Let's see how that works inside our whole app.js file. Let’s also set the status to our React component's state so we can see what state we're in on screen. https://cdn.pixabay.com/photo/2020/08/29/16/08/pikachu-5527377_640.jpg Conclusion Well done! You've finished part 2 of the Collectibles portal project. In summary, we focused on building the front end of our Collectibles portal. We did this by: Creating an app with React.js Connecting with Flow Wallet Creating our very own NFTs for minting Viewing NFTs by asking the blockchain Now you have a better understanding. Keep up the fantastic effort! Have a really great day! Also published . here

Build an NFT Website Using The Flow Blockchain and Cadence [Part 2]

Build an NFT Website Using The Flow Blockchain and Cadence [Part 1]

If you’re a developer working on a web3 app, you know that onboarding mainstream users into web3 is difficult. Even with the promise of truly owning your data, making near-free worldwide payments, and using a censorship-free system, the current process of creating and using a digital wallet is just too hard. Fortunately, there’s a better way. promises to streamline the process, making user onboarding seamless and simple. —a decentralized, public, layer-one blockchain designed for building web3 experiences for mainstream users—has used account abstraction to combine a model with to create an onboarding that is easy, simple, and as straightforward as traditional apps. Account abstraction Flow hybrid custody walletless onboarding Let's dive into the details to see how Hybrid Custody and Walletless Onboarding work together: the architecture, the code, and what we can expect moving forward. Why web3 onboarding is so difficult Digital wallets bring all the benefits of web3, including the assurance that no one can control your assets. There are no middlemen such as banks taking a percentage of your money, or third parties dictating what you can do. However, because most wallets are “self custody” (meaning only you have access), you—and only you—are in charge of your keys. There is no customer support if you make a mistake. This means you must store your keys safely. Don’t store them in clear text on your computer where they can be hacked. And don’t write them down where someone can read them. And don’t lose them, because there is no reset password in web3, so you’ll lose . You can see the issues. everything In addition to the challenges of self custody, you also need to understand tokens and payments. How do you pay for your transactions? What tokens do you need? How do you move from fiat to tokens? How do you transfer the tokens once you have them? Oh, you made a typo when you sent your tokens? Sorry, they’re lost forever. Again, you can see how difficult this all is. With all these obstacles, it’s easy to see why many people don’t make it past step one of signing up for your app. Custodial wallets: great UX, lacking ownership Developers tried to solve this issue with . These wallets manage the keys for you and have many benefits. custodial wallets Signing up is easy. You can use an email and password, as you would for a traditional service, and the wallet provider takes care of the rest. If you lose your login credentials, your keys are still accessible on the provider's servers – you can simply request a password reset. Since the wallet software runs on their servers, providers can even pay your fees. You don’t have to understand tokens, funding, and transfers. transaction But as the saying in web3 goes: “Not your keys, not your coins!” While custodial wallets solved many onboarding issues, the wallet providers, in the end, owned the keys. We’re right back to the problems we wanted to get away from: a centralized entity that can prevent you from using your tokens, can close your account at a whim, or can shut down completely, taking your funds with them. Wouldn’t it be nice if you could have the best of both worlds? Account abstraction to the rescue! solves one of the fundamental issues of blockchain networks: the distinction between externally owned accounts and contract accounts. Account abstraction An (EOA) is an account controlled by the user with a private key. These are the traditional web3 wallets that we talked about above. An EOA has a public address and initiates transactions (such as sending tokens) with the blockchain. externally owned account A (which is also just a smart contract) is a program deployed on-chain and executed by the network nodes. Contract accounts don’t initiate transactions. Instead they respond to a transaction with an action of their own. They have no private key—they are controlled by their code. This type of account could be said to have . contract account app-custody Account abstraction combines app-custody and self-custody into a new user experience (UX), giving users the benefits of both: control of their wallets, while abstracting away the wallet (and blockchain) altogether. On Flow, account abstraction is the basis for Walletless Onboarding using Hybrid Custody. Hybrid Custody gives you the best of both worlds allows developers to create an onboarding experience for users that is nearly seamless. Walletless Onboarding The walletless user journey (from flow.com) The hybrid custody model uses account abstraction to allow —where a child account delegates control to a parent account through a , essentially allowing one account to control another. account delegation Capability Now, the self-custody account can be a parent account, giving permissions to the app account, which is now a child account. With this setup, the accounts work together, and your app can work like this: Your app creates the wallets for the users. There is no barrier to entry here—no key management, no signing transactions, no understanding of blockchain. Users can use your app, and buy and sell assets, without knowing or caring about the technical details. Your app can even subsidize transaction fees or let them fund their account with fiat such as USD. And it all happens invisibly to the user. Once the user comes back with their own wallet-managed account, your app can delegate access to the user’s account. Once linked, the user has hybrid custody – their wallet manages their main (now “parent”) account which secondarily maintains access on the app-created (now “child”) account. Since their main account now has access on the app-created account, they can bring app assets anywhere their wallet-managed account goes. They can trade your app’s assets on marketplaces or share them with friends. Yet, at the same time, since the app also has access to the account, it can still facilitate seamless UX that acts on their behalf. With this hybrid custody model, users get to experience your app right away, with minimal barriers and no risk. And later on, if they choose, they can take control of the self-custody account themselves, enjoying all the real ownership and self-sovereignty it brings. Technical details of hybrid custody and account abstraction Account Creation How does all this work? On and many other blockchain networks, an EOA is created from a public key. The key is hashed, and the first 160 bits of this hash become the address of the account controlled by that key. This makes account creation independent from the network but irrevocably ties an account to that key. Ethereum Flow uses a particular on-chain function to create account addresses. You can then add any number of keys to a Flow account, adding and removing access based on the custodian of each key. This means a transaction is required to create a new address—so you can’t create accounts offline—but it also makes Flow account ownership much more flexible. You can see , but let’s check out the crucial parts here: a full account creation example on GitHub FromPrivateKey(userPrivateKey).
  SetHashAlgo(crypto.SHA3_256).
  SetWeight(flow.AccountKeyWeightThreshold) examples.ServiceAccount(flowClient) []*flow.AccountKey{userPublicKey}, 
  nil, 
  serviceAccountAddress
)


createAccountTx.SetProposalKey(
  serviceAccountAddress,
  serviceAccountKey.Index,
  serviceAccountKey.SequenceNumber
)


createAccountTx.SetReferenceBlockID(
  examples.GetReferenceBlockId(flowClient)
)


createAccountTx.SetPayer(serviceAccountAddress)

_ = createAccountTx.SignEnvelope(
  serviceAccountAddress,
  serviceAccountKey.Index,
  serviceSigner
)
_ = flowClient.SendTransaction(ctx, *createAccountTx) userPrivateKey := examples.RandomPrivateKey() userPublicKey := flow.NewAccountKey(). serviceAccountAddress, serviceAccountKey, serviceSigner := createAccountTx, _ := templates.CreateAccount( First, the user creates a key pair. Pretty basic stuff. Because on Flow, you create accounts by sending an account creation transaction, we need an existing account to send this transaction. This housekeeping is the job of the . ServiceAccount The receives the user’s public key to control the new account later, but the , which signs and pays for the transaction, handles the rest. In the case of your app, you would own this service account so you could sign account creation transactions on behalf of your user, also funding the account’s creation. createAccountTx ServiceAccount Hybrid Custody Let’s get back to the hybrid custody model. Your app can create app accounts for your users and link them to a public key that your app controls. The app can then handle your user's transactions and assets and even sponsor their transaction fees, just like any custodial account would do. Later, when a user decides to dive deeper into the web3 ecosystem and get their own wallet, you can create and save a link to the app-custodied account’s , and delegate control to the user’s wallet-managed account. AuthAccount Capability You can see an example of this in the where a multisig transaction is executed by the app to link a user's account to a walletless onboarding, dapp-custodied account to the signing user’s wallet-managed account. walletless arcade example Summary It’s worth driving the point home that delegating access on the app-created account is done via a linked Capability on the account which is then provided to the user. This mechanism for account delegation is completely new to blockchain accounts, and is only possible because of the account abstraction that’s been native to Flow for years now. This language API account linking feature is a huge advantage to accounts on Flow, in addition to many other features – m-of-n multisig, re-keying accounts, etc. – which are only now beginning to be realized on other chains with their nascent, non-native account abstraction implementations. Account abstraction is a powerful feature. On , it enables a hybrid custody model that allows users to enjoy the benefits of a custodial account when they sign up, while enabling them to take the account into self-custody at any time. It’s a new – and vastly improved – user experience that hopefully brings millions more users into web3. Flow Also published here .

Web3 Onboarding is Terrible — Make it Better With Account Abstraction and Flow

Throughout this article series, we’ve its , and some of the most , all while comparing and contrasting to Ethereum. introduced you to the Flow blockchain, smart contract language Cadence essential tools developers should know In this article, we will talk about best practices and patterns that should be followed when using the Cadence language and developing solutions on the Flow network, as well as patterns to avoid. Best practices Use Flow Test Network and Flow Emulator One of the most important steps in developing on any blockchain is testing your projects in a simulated environment. Flow blockchain is no different. For this purpose, the and are both crucial components to include in your development process. Not only do they allow you to understand how your dapp will perform, but they will also help you catch any critical bugs before deploying to mainnet. Flow testnet Flow Emulator Use Standard Contracts Two of the most common use cases for any blockchain are digital currencies and providing proof of digital ownership through NFTs. Instead of trying to rewrite the necessary contracts from scratch, Flow developers should always import the official core contracts to ensure user safety and consistency with the rest of the network. There are currently three standard contracts you should use: — Used to create new tokens Fungible Token — Used to create NFTs Non-Fungible Token — Used as a metadata pattern for NFTs Metadata Views These contracts are essentially interfaces that force whoever is implementing them to add their variable and method declarations, enabling them to be interoperable with other smart contracts in the Flow ecosystem. They already exist on both testnet and mainnet networks, so be sure to import from the official addresses linked above when implementing them in your contract. You can find other core contracts . in the Flow documentation Create Tests for Your Smart Contracts, Transactions, and Scripts The is crucial for testing deployment scenarios for your contracts. However, it’s important to note that you’ll need the running in the background for full functionality. With these, you can test creating new accounts, sending transactions, running queries, executing scripts, and more. Additionally, it integrates with the Flow Emulator so you can create, run, and stop emulator instances. Flow JavaScript Testing Framework Flow CLI Add Your Contract to the Flow NFT Catalog The exists as a database to store NFT contracts and metadata. By uploading your contract, your NFTs become interoperable with the rest of the Flow ecosystem, and other developers can easily support your collection in their marketplaces or other dapps. Flow NFT Catalog You can by completing a simple four-step process. add your contract to the catalog Be Specific With Types Cadence is a and typed language that allows the developer to specify which types contain or return variables, interfaces, and functions. Therefore, you should be as specific as possible when making declarations; use generic types only in necessary situations. Not doing so can result in clumsy errors. strong statically Access Control Whenever possible, you should be deliberate with access control. Luckily, on the Flow blockchain, a caller cannot access objects in another user’s account storage without a reference to it. This is called reference-based security, and it means that nothing is truly public by default. However, when writing Cadence code, care must be taken when declaring variables, structs, functions, resources, and so on. There are four levels of access control a developer can include in their declarations: — accessible/visible in all scopes pub/access(all) — only accessible in the entire account where it’s defined (other contracts in the same account can access) access(account) — only accessible in the scope of the contract in which it is defined (cannot be accessed outside of the contract) access(contract) — only accessible in current and inner scopes priv/access(self) Avoid using pub/access(all) whenever possible. Check out the Flow documentation for . more information on access control Create StoragePath and PublicPath Constants Inside Your Contract The paths to your contract’s resources are extremely important and must be consistent across all transactions and scripts. To ensure uniformity, you should create constants for both PublicPath and StoragePath. pub contract BestPractices {
	pub let CollectionStoragePath: StoragePath
	pub let CollectionPublicPath: PublicPath

	init(){
		self.CollectionStoragePath = /storage/bestPracticesCollection
		self.CollectionPublicPath = /public/bestPracticesCollection
	}
} When you create a transaction that uses one of these paths, you only need to call its respective variable with the imported contract to reference the required path. //This script checks if a user has the public Collection from BestPractices contract
import BestPractices from 0x...

pub fun main(addr: Address): Bool {
	return getAccount(addr).getLinkTarget(BestPractices.CollectionPublicPath) != nil
} Admin Resource It’s good practice to create an administrative resource that contains specific functions to perform actions under the contract, such as a mint function. This convention ensures that only accounts with that resource or capability can perform administrative functions. pub contract BestPractices {
	pub let CollectionStoragePath: StoragePath
	pub let CollectionPublicPath: PublicPath
	pub let AdminStoragePath: StoragePath

	pub resource AdminResource {
		pub fun mintNFT(){
			//your mint NFT code here! 
		}
	}

	init(){
		self.CollectionStoragePath = /storage/bestPracticesCollection
		self.CollectionPublicPath = /public/bestPracticesCollection
		self.AdminStoragePath = /storage/bestPracticesAdmin
		
		//Create the adminResource and store it inside Contract Deployer account
		let adminResource <- create AdminResource()
		self.account.save(<- adminResource, to: self.AdminStoragePath)
	}
} Create Custom Events Events are values that can be emitted during the execution of your Cadence code. For example, when defining important actions in your contracts, you can emit events to signal their completion or deliver a specific value. As a result, transactions that interact with your smart contracts can receive additional information through these events. pub contract BestPractices {
	pub let CollectionStoragePath: StoragePath
	pub let CollectionPublicPath: PublicPath
	pub let AdminStoragePath: StoragePath

//Create your own events
pub event AdminCreated()
	

	pub resource AdminResource {
		pub fun mintNFT(){
			//your mint NFT code here! 
		}
	}

	init(){
		self.CollectionStoragePath = /storage/bestPracticesCollection
		self.CollectionPublicPath = /public/bestPracticesCollection
		self.AdminStoragePath = /storage/bestPracticesAdmin
		
		//Create the adminResource and store it inside Contract Deployer account
		let adminResource <- create AdminResource()
		self.account.save(<- adminResource, to: self.AdminStoragePath)
	}
} Patterns on Cadence/Flow Blockchain Be Specific With Types in Type Constraints One of the most powerful features of the Cadence language is undoubtedly . Through capabilities, the scope of resource access expands. capabilities An important point when creating a capability is to specify which features of your resource should be available to others. This can be done at the time of link creation using type constraints. In this example, we use the to create a basic functionality where any account that wants to receive an ExampleNFT must have a collection. ExampleNFT contract import NonFungibleToken from 0x...
import ExampleNFT from 0x...

transaction{
	prepare(acct: AuthAccount){
		let collection <- ExampleNFT.createEmptyCollection()
    // Put the new collection in storage
	  acct.save(<-collection, to: ExampleNFT.CollectionStoragePath)
    // Create a public Capability for the collection
    acct.link<&ExampleNFT.Collection{ExampleNFT.CollectionPublic}>(ExampleNFT.CollectionPublicPath, target: ExampleNFT.CollectionStoragePath)
	}
} The & symbol in specifies that we are using a . After the reference symbol, we add the type to which the capability we are creating will have access. At this point, we need to be as specific as possible. &ExampleNFT reference This pattern strengthens security and limits the functionality that the user calling the function of this capability can use. borrow Omitting the type will give you access to all the functions that exist in the reference, including the withdraw function, so that anyone can access the user's collection and steal their NFTs. {ExampleNFT.CollectionPublic} ExampleNFT.Collection Use the Borrow Function To use the resource’s features, you could call the function to remove the resource from the account, use its features, and call the function to save it again. However, this approach is costly and inefficient. Load Save To avoid this, use the function instead. It allows you to use a reference to the resource you are calling. This method makes your transaction much more efficient and cost-effective. borrow Use the check and getLinkTarget Functions When building applications on the Flow blockchain, you will discover the user’s account plays a vital role. Unlike other blockchains, such as Ethereum, Flow stores resources, assets, and more directly in the user’s account rather than as a reference to an address on a public digital ledger. This approach requires the account to have a specific storage location, such as a collection or vault for fungible tokens. However, this also adds complexity. One must be sure that the user either does or does not have the collection in their account. Both the function (which checks whether a capability exists in a given path) and the function (which returns the path of a given capability) must be used when adding collections and capabilities to the user account. These functions ensure that the transaction executes without problems. check() getLinkTarget() Use Panic Panic is a built-in function in Cadence that allows you to terminate a program unconditionally. This can occur during the execution of your smart contract code and returns an error message, which makes it easier to understand when something does not go as expected. When declaring variables, it is possible to define them as optional; meaning, if they are not of the specified type, they have a value of nil. Thus, in Cadence, it is possible to use two question marks followed by the function when querying the value of a particular variable or function that returns an optional. panic("treatment message") let optionalAccount: AuthAccount? = //...
let account = optionalAccount ?? panic("missing account") This command attempts to return the value with the specified type. If the returned value is the wrong type, or nil, the execution aborts, and the selected treatment message displays on the console. ??panic("treatment message") Anti-Patterns Although Cadence is designed to avoid many of the potential bugs and exploits found in other blockchain ecosystems, there are some anti-patterns developers should be aware of while building. Listed below are a few important ones to consider. For a complete list of anti-patterns, . check out the Flow documentation Failing to Specify the Type When Using the Borrow Function Developers should use the borrow function mentioned above to take advantage of the features available in a capability. However, it should be clear that users can store anything in their memory. Therefore, it is vital to make sure that what is borrowed is of the correct type. Not specifying the type is an anti-pattern that can end up causing errors or even breakage in your transaction and application. //Bad Practice. Should be avoided
let collection = getAccount(address).getCapability(ExampleNFT.CollectionPublicPath)
                    .borrow<&ExampleNFT.Collection>()?? panic("Could not borrow a reference to the nft collection")

//Correct! 
let collection = getAccount(address).getCapability(ExampleNFT.CollectionPublicPath)
                    .borrow<&ExampleNFT.Collection{NonFungibleToken.CollectionPublic}>()
                    ?? panic("Could not borrow a reference to the nft collection") Using AuthAccount as a Function Parameter For a transaction in the preparation phase, it is possible to access the AuthAccount field of the user. This object allows access to the memory storage and all other private areas of the account for the user who provides it. Passing this field as an argument is not recommended and should be avoided, as cases where this method is necessary are extremely rare. //Bad Practice. Should be avoided

transaction() {
	prepare(acct: AuthAccount){
		//You take sensitive and important user data out of the scope of the transaction prepare phase
		ExampleNFT.function(acct: acct)
	}
} Using Public Access Control on Dictionaries and Arrays By storing dictionaries and array variables in your contract with scope, your smart contract becomes vulnerable, as anyone can manipulate and change these values. pub/access(all) Creating Capabilities and References Using the Auth Keyword Creating capabilities and references with the keyword exposes the value to downcasting, which could provide access to functionality that was not originally intended. auth //AVOID THIS!
signer.link<auth &ExampleNFT.CollectionPublic{NonFungibleToken.Receiver}>(
    /public/exampleNFT,
    target: /storage/exampleNFT
) Conclusion When developing on the Flow blockchain using Cadence, it helps to be aware of design patterns, anti-patterns, and best practices. By following these best practices, we can ensure a consistent level of security throughout the Flow ecosystem, thus providing the best experience for users. For a more thorough understanding, . read through the Flow documentation Have a really great day!

FLOW

proflow.ai

-- employees

Since n.d.

COMPANY RANKING

FLOW

EVERGREEN INDEX #5615

Representing this company? Click here to claim and customize this page!

Flow WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!

FLOW

proflow.ai

-- employees

Since n.d.

COMPANY RANKING

FLOW

EVERGREEN INDEX #5615

RELATED COMPANIESRANK

STORIES ABOUT FLOW

Representing this company? Click here to claim and customize this page!

Flow WIKI

Apply to get your Tech Company News Page live on HackerNoon.com today!