승인

In this tutorial you'll learn the basics of an approval management system which will allow you to grant others access to transfer NFTs on your behalf.

This is the backbone of all NFT marketplaces and allows for some complex yet beautiful scenarios to happen. If you're joining us for the first time, feel free to clone this repository and go to the nft-contract-basic/ folder to follow along.

cd nft-contract-basic/

If you wish to see the finished code for this Approval tutorial, you can find it on the nft-contract-approval/ folder. :::

## 소개

Up until this point you've created a smart contract that allows users to mint and transfer NFTs as well as query for information using the enumeration standard. As we've been doing in the previous tutorials, let's break down the problem into smaller, more digestible, tasks.

Let's first define some of the end goals that we want to accomplish as per the approval management extension of the standard. We want a user to have the ability to:

다른 계정에 토큰별로 NFT를 전송할 수 있는 액세스 권한을 부여합니다.
계정에 특정 토큰에 대한 액세스 권한이 있는지 확인합니다.
특정 계정의 NFT 전송 승인을 취소합니다.
NFT를 전송할 수 있는 다른 모든 계정의 승인을 취소합니다.

If you look at all these goals, they are all on a per token basis. This is a strong indication that you should change the Token struct which keeps track of information for each token.

계정에서 NFT 전송 허용

Let's start by trying to accomplish the first goal. How can you grant another account access to transfer an NFT on your behalf?

The simplest way that you can achieve this is to add a list of approved accounts to the Token struct. When transferring the NFT, if the caller is not the owner, you could check if they're in the list.

Before transferring, you would need to clear the list of approved accounts since the new owner wouldn't expect the accounts approved by the original owner to still have access to transfer their new NFT.

문제점

On the surface, this would work, but if you start thinking about the edge cases, some problems arise. Often times when doing development, a common approach is to think about the easiest and most straightforward solution. Once you've figured it out, you can start to branch off and think about optimizations and edge cases.

Let's consider the following scenario. Benji has an NFT and gives two separate marketplaces access to transfer his token. By doing so, he's putting the NFT for sale (more about that in the marketplace integrations section). Let's say he put the NFT for sale for 1 NEAR on both markets. The tokens list of approved account IDs would look like the following:

Token: {
    owner_id: Benji
    approved_accounts_ids: [marketplace A, marketplace B]
}

Josh then comes along and purchases the NFT on marketplace A for 1 NEAR. This would take the sale down from the marketplace A and clear the list of approved accounts. Marketplace B, however, still has the token listed for sale for 1 NEAR and has no way of knowing that the token was purchased on marketplace A by Josh. The new token struct would look as follows:

Token: {
    owner_id: Josh
    approved_accounts_ids: []
}

Let's say Josh is low on cash and wants to flip this NFT and put it for sale for 10 times the price on marketplace B. He goes to put it for sale and for whatever reason, the marketplace is built in a way that if you try to put a token up for sale twice, it keeps the old sale data. This would mean that from marketplace B's perspective, the token is still for sale for 1 NEAR (which was the price that Benji had originally listed it for).

Since Josh approved the marketplace to try and put it for sale, the token struct would look as follows:

Token: {
    owner_id: Josh
    approved_accounts_ids: [marketplace A, marketplace B]
}

If Mike then comes along and purchases the NFT for only 1 NEAR on marketplace B, the marketplace would go to try and transfer the NFT and since technically, Josh approved the marketplace and it's in the list of approved accounts, the transaction would go through properly.

해결책

Now that we've identified a problem with the original solution, let's think about ways that we can fix it. What would happen now if, instead of just keeping track of a list of approved accounts, you introduced a specific ID that went along with each approved account. The new approved accounts would now be a map instead of a list. It would map an account to it's approval id.

For this to work, you need to make sure that the approval ID is always a unique, new ID. If you set it as an integer that always increases by 1 whenever u approve an account, this should work. Let's consider the same scenario with the new solution.

Benji puts his NFT for sale for 1 NEAR on marketplace A and marketplace B by approving both marketplaces. The "next approval ID" would start off at 0 when the NFT was first minted and will increase from there. This would result in the following token struct:

Token: {
    owner_id: Benji
    approved_accounts_ids: {
        marketplace A: 0
        marketplace B: 1
    }
    next_approval_id: 2
}

When Benji approved marketplace A, it took the original value of next_approval_id which started off at 0. The marketplace was then inserted into the map and the next approval ID was incremented. This process happened again for marketplace B and the next approval ID was again incremented where it's now 2.

Josh comes along and purchases the NFT on marketplace A for 1 NEAR. Notice how the next approval ID stayed at 2:

Token: {
    owner_id: Josh
    approved_accounts_ids: {}
    next_approval_id: 2
}

Josh then flips the NFT because he's once again low on cash and approves marketplace B:

Token: {
    owner_id: Josh
    approved_accounts_ids: {
        marketplace B: 2
    }
    next_approval_id: 3
}

The marketplace is inserted into the map and the next approval ID is incremented. From marketplace B's perspective it stores it's original approval ID from when Benji put the NFT up for sale which has a value of 1. If Mike were to go and purchase the NFT on marketplace B for the original 1 NEAR sale price, the NFT contract should panic. This is because the marketplace is trying to transfer the NFT with an approval ID 1 but the token struct shows that it should have an approval ID of 2.

`Token` 및 `JsonToken` 구조체 확장

Now that you understand the proposed solution to the original problem of allowing an account to transfer your NFT, it's time to implement some of the logic. The first thing you should do is modify the Token and JsonToken structs to reflect the new changes. Let's switch over to the nft-contract-basic/src/metadata.rs file:

Loading...

## 소개​

계정에서 NFT 전송 허용​

문제점​

해결책​

Token 및 JsonToken 구조체 확장​

계정 승인​

내부 함수​

NFT 전송 제한 변경​

전송 시 스토리지 환불​

nft_core.rs 내 변경 사항​

계정 승인 확인​

계정 해지​

모든 계정 해지​

새 변경 사항 테스트​

Deployment and initialization​

Minting​

계정 승인​

승인된 계정으로 NFT 전송​

결론​

## 소개

계정에서 NFT 전송 허용

문제점

해결책

`Token` 및 `JsonToken` 구조체 확장

계정 승인

내부 함수

NFT 전송 제한 변경

전송 시 스토리지 환불

`nft_core.rs` 내 변경 사항

계정 승인 확인

계정 해지

모든 계정 해지

새 변경 사항 테스트

Deployment and initialization

Minting

계정 승인

승인된 계정으로 NFT 전송

결론