[[389053]]

本文轉載自微信公眾號「區塊鏈研究實驗室」，作者鏈三豐。轉載本文請聯系區塊鏈研究實驗室公眾號。

隨著不可替代令牌(NFT)市場達到高潮，回顧一下相對較早的NFT并記住CryptoKitties面臨的挑戰是很有趣的。由Dapper Labs團隊構建的平臺是潛在大規模采用的第一個真實示例，也是以太坊區塊鏈上的第一個真實壓力。

從那時起，NFT開始興起，諸如Rarible，OpenSea，Foundation和Sorare之類的平臺也開始興起。這些平臺每月有數百萬美元的資金流向。盡管有早期的掙扎，但大多數情況還是在以太坊區塊鏈上發生的。但是，Dapper Labs的團隊在使用CryptoKitties的經驗之后，著手建立一個新的區塊鏈，該區塊鏈將是通用的，但也非常適合NFT用例。這樣做的目的是解決以太坊上的NFT所遇到的許多問題，同時為該領域的開發商和收藏家提供更好的體驗。

今天我們討論如何在由IPFS支持的Flow上創建NFT。Flow區塊鏈的主要早期應用之一是NBA Top Shot。我們將構建NFT鑄造過程的非?；镜母北?，然后在IPFS上備份NFT元數據和資產。

這是一個包含以下三部分的教程：

• 創建合約并鑄造代幣
• 創建一個應用以查看通過此合同創建的NFT
• 創建一個市場以將NFT轉讓給其他人，同時也轉讓NFT在IPFS上的基礎資產

今天讓我們開始第一個教程。

配置

我們需要安裝Flow CLI：

蘋果系統：

brew install flow-cli 

Linux：

sh -ci “$(curl -fsSL https://storage.googleapis.com/flow-cli/install.sh)" 

Windows：

iex “& { $(irm ‘https://storage.googleapis.com/flow-cli/install.ps1') }” 

我們將在IPFS上存儲資產文件。為了簡化操作，我們可以使用Pinata。您可以在此處注冊一個免費帳戶，并在此處獲取API密鑰。在本教程的第二篇文章中，我們將使用API，但在這篇文章中，我們將使用Pinata網站。

我們還需要安裝NodeJS和文本編輯器，以幫助突出顯示Flow智能合約代碼(以Cadence語言編寫)的語法。您可以在此處安裝Node。Visual Studio Code具有支持Cadence的擴展。

安裝好之后，讓我們創建一個目錄來容納我們的項目：

mkdir pinata-party 

轉到該目錄并初始化一個新的流程項目：

cd pinata-party 
flow project init 

現在，在您喜歡的代碼編輯器中打開項目(同樣，如果您使用Visual Studio Code，請抓住Cadence擴展)，然后開始工作。

您會看到一個flow.json文件，我們將很快使用它。首先，創建一個名為的文件夾cadence。在該文件夾中，添加另一個名為的文件夾contracts。最后，在contracts名為的文件夾中創建一個文件PinataPartyContract.cdc。

在繼續前進之前，重要的一點是要指出，從現在開始，我們對Flow區塊鏈所做的一切都將在模擬器上完成。但是，將項目部署到testnet或mainnet就像更新flow.json文件中的配置設置一樣簡單。現在讓我們為仿真器環境設置該文件，然后就可以開始編寫合同了。

更新合同對象，flow.json如下所示：

"contracts": { 
     "PinataPartyContract": "./cadence/contracts/PinataPartyContract.cdc" 
} 

然后，更新該deployments文件中的對象，如下所示：

"deployments": { 
     "emulator": { 
          "emulator-account": ["PinataPartyContract"] 
     } 
} 

這是在告訴Flow CLI使用仿真器來部署我們的合同，它還引用了該帳戶(在仿真器上)和我們即將寫的合同。

合約

Flow提供了有關創建NFT合約的出色教程。這是一個很好的參考點，但是正如Flow指出的那樣，他們尚未解決NFT元數據問題。他們想在鏈上存儲元數據。那是個好主意，他們一定會提出一個合乎邏輯的方法。但是，我們現在想用元數據創建一些令牌，并且我們希望與NFT相關聯的媒體文件。元數據只是一個組成部分。我們還需要指出令牌最終代表的媒體。

如果您熟悉以太坊區塊鏈上的NFT，您可能會知道這些令牌返回的許多資產都存儲在傳統數據存儲和云托管提供商中。可以，除非不是。過去我們曾寫過關于內容可尋址內容的天才之處，以及在傳統云平臺上存儲與區塊鏈相鄰的數據的弊端。歸結為兩點：

• 資產應該是可驗證的
• 維護職責的轉移應該很容易

IPFS照顧了這兩個方面。然后，Pinata以一種簡單的方式分層，以將該內容長期固定在IPFS上。這正是我們想要支持NFT的媒體所需要的，對嗎?我們要確?？梢宰C明所有權(NFT)，提供有關NFT(NFT)的數據，并確保我們對基礎資產(IPFS)(介質或其他)擁有控制權，而不是某些副本的控制權。

考慮到所有這些，讓我們寫一個合約，創建NFT，將元數據與NFT相關聯，并確保元數據指向存儲在IPFS上的基礎資產。

打開PinataPartyContract.cdc，讓我們開始工作。

pub contract PinataPartyContract { 
  pub resource NFT { 
    pub let id: UInt64 
    init(initID: UInt64) { 
      self.id = initID 
    } 
  } 
} 

第一步是定義我們的合同。我們將為此添加更多的內容，但是我們首先定義PinataPartyContract并在其中創建一個resource。資源是存儲在用戶帳戶中的項目，可以通過訪問控制措施進行訪問。在這種情況下，NFT資源最終是因為擁有用于表示NFT的事物而擁有的。NFT必須是唯一可識別的。該id屬性使我們能夠識別令牌。

接下來，我們需要創建一個資源接口，該接口將用于定義哪些功能可供其他人(即不是合同所有者的人)使用：

pub resource interface NFTReceiver { 
  pub fun deposit(token: @NFT, metadata: {String : String}) 
  pub fun getIDs(): [UInt64] 
  pub fun idExists(id: UInt64): Bool 
  pub fun getMetadata(id: UInt64) : {String : String} 
} 

將其放在NFT資源代碼下方。此NFTReceiver資源接口表示，我們定義為有權訪問該資源的任何人都可以調用以下方法：

• deposit
• getIDs
• idExists
• getMetadata

接下來，我們需要定義我們的令牌收集接口?？梢詫⑵湟暈槿菁{所有用戶NFT的錢包。

pub resource Collection: NFTReceiver { 
    pub var ownedNFTs: @{UInt64: NFT} 
    pub var metadataObjs: {UInt64: { String : String }} 
 
    init () { 
        self.ownedNFTs <- {} 
        self.metadataObjs = {} 
    } 
 
    pub fun withdraw(withdrawID: UInt64): @NFT { 
        let token <- self.ownedNFTs.remove(key: withdrawID)! 
 
        return <-token 
    } 
 
    pub fun deposit(token: @NFT, metadata: {String : String}) { 
        self.metadataObjs[token.id] = metadata 
        self.ownedNFTs[token.id] <-! token 
    } 
 
    pub fun idExists(id: UInt64): Bool { 
        return self.ownedNFTs[id] != nil 
    } 
 
    pub fun getIDs(): [UInt64] { 
        return self.ownedNFTs.keys 
    } 
 
    pub fun updateMetadata(id: UInt64, metadata: {String: String}) { 
        self.metadataObjs[id] = metadata 
    } 
 
    pub fun getMetadata(id: UInt64): {String : String} { 
        return self.metadataObjs[id]! 
    } 
 
    destroy() { 
        destroy self.ownedNFTs 
    } 
  } 

此資源中有很多事情要做，但是應該很快就有意義。首先，我們有一個名為的變量ownedNFTs。這很簡單。它跟蹤該合同中用戶擁有的所有NFT。

接下來，我們有一個名為的變量metadataObjs。這一點有點獨特，因為我們正在擴展Flow NFT合同功能，以存儲每個NFT的元數據映射。此變量將令牌ID映射到其關聯的元數據，這意味著我們需要先設置令牌ID，然后才能進行設置。

然后，我們初始化變量。對于Flow中資源中定義的變量，這是必需的。

最后，我們擁有NFT收集資源的所有可用功能。請注意，并非所有這些功能都可以使用。如果您還記得的話，我們在NFTReceiver資源界面的前面定義了任何人都可以使用的功能。

我確實要指出deposit功能。正如我們將默認的Flow NFT合同擴展為包括metadataObjs映射一樣，我們也在擴展默認deposit函數以采用的附加參數metadata。我們為什么在這里這樣做?我們需要確保只有令牌的鑄造者才能將該元數據添加到令牌中。為了保持私密性，我們將最初添加的元數據限制在鑄造執行中。

我們的合同代碼幾乎完成了。因此，在Collection資源下方，添加以下內容：

pub fun createEmptyCollection(): @Collection { 
    return <- create Collection() 
} 
 
pub resource NFTMinter { 
    pub var idCount: UInt64 
 
    init() { 
        self.idCount = 1 
    } 
 
    pub fun mintNFT(): @NFT { 
        var newNFT <- create NFT(initID: self.idCount) 
 
        self.idCount = self.idCount + 1 as UInt64 
 
        return <-newNFT 
    } 
} 

首先，我們有一個函數，該函數在調用時會創建一個空的NFT集合。這樣，首次與我們的合同進行交互的用戶將具有一個創建到Collection我們定義的資源的存儲位置。

之后，我們再創建一個資源。這很重要，因為沒有它，我們將無法鑄造代幣。該NFTMinter資源包括idCount其遞增，以確保我們從來沒有對我們的NFT重復的ID。它還具有實際創建我們的NFT的功能。

在NFTMinter資源下方，添加主合同初始化程序：

init() { 
      self.account.save(<-self.createEmptyCollection(), to: /storage/NFTCollection) 
      self.account.link<&{NFTReceiver}>(/public/NFTReceiver, target: /storage/NFTCollection) 
      self.account.save(<-create NFTMinter(), to: /storage/NFTMinter) 
} 

僅在部署合同時才調用此初始化函數。它做三件事：

• 為集合的部署者創建一個空的集合，以便合同的所有者可以創建該合同的NFT并擁有該NFT。
• Collection參考NFTReceiver我們在開始時創建的界面，該資源在公共位置發布。這就是我們告訴合同的方式，NFTReceiver任何人都可以調用上定義的功能。
• 該NFTMinter資源被保存在賬戶儲存合同的創造者。這意味著只有合同的創建者才能鑄造代幣。

完整的合同可以在這里找到。

現在我們準備好了合同，讓我們部署它，對吧?好吧，我們可能應該在Flow Playground上對其進行測試。轉到那里，然后單擊左側邊欄中的第一個帳戶。用我們的合同代碼替換示例合同中的所有代碼，然后單擊“部署”。如果一切順利，您應該在屏幕底部的日志窗口中看到這樣的日志：

flow project start-emulator 

現在，我們準備將合同部署到本地運行的模擬器。在命令行中，運行以下命令：

flow project deploy 

現在，在仿真器運行且flow.json文件配置正確的情況下，我們可以部署合同。只需運行以下命令：

flow project deploy

如果一切順利，您應該會看到類似以下的輸出：

Deploying 1 contracts for accounts: emulator-account

PinataPartyContract -> 0xf8d6e0586b0a20c7

現在，我們在Flow仿真器上有一個合同，但是我們想要鑄造一個令牌。

鑄造NFT

在本教程的第二篇文章中，我們將致力于通過應用程序和用戶界面使鑄造過程更加用戶友好。為了說明問題，并顯示元數據如何與Flow上的NFT一起使用，我們將使用Cadence腳本和命令行。

讓我們在pinata-party項目的根目錄下創建一個新目錄，并將其稱為transactions。創建該文件夾后，在其中創建一個名為的新文件MintPinataParty.cdc。

為了編寫交易，我們需要在提供給NFT的元數據中引用一個文件。為此，我們將通過Pinata將文件上傳到IPFS，您可以上傳任何想要的視頻文件。您可以真正上載任何資產文件并將其與NFT關聯。

上傳文件后，系統會為您提供IPFS哈希(通常稱為內容標識符或CID)。復制此哈希，因為我們將在鑄造過程中使用它。

現在，在MintPinataParty.cdc文件內添加以下內容：

import PinataPartyContract from 0xf8d6e0586b0a20c7 
 
transaction { 
  let receiverRef: &{PinataPartyContract.NFTReceiver} 
  let minterRef: &PinataPartyContract.NFTMinter 
 
  prepare(acct: AuthAccount) { 
      self.receiverRef = acct.getCapability<&{PinataPartyContract.NFTReceiver}>(/public/NFTReceiver) 
          .borrow() 
          ?? panic("Could not borrow receiver reference")         
 
      self.minterRef = acct.borrow<&PinataPartyContract.NFTMinter>(from: /storage/NFTMinter) 
          ?? panic("could not borrow minter reference") 
  } 
 
  execute { 
      let metadata : {String : String} = { 
          "name": "The Big Swing", 
          "swing_velocity": "29",  
          "swing_angle": "45",  
          "rating": "5", 
          "uri": "ipfs://QmRZdc3mAMXpv6Akz9Ekp1y4vDSjazTx2dCQRkxVy1yUj6" 
      } 
      let newNFT <- self.minterRef.mintNFT() 
 
      self.receiverRef.deposit(token: <-newNFT, metadata: metadata) 
 
      log("NFT Minted and deposited to Account 2's Collection") 
  } 
} 

這是一個非常簡單的事務，這在很大程度上要感謝Flow為使事情變得容易而進行的工作，但讓我們逐步進行一下。首先，您會在頂部注意到import語句。如果您還記得的話，當我們部署合同時，我們會收到一個帳戶。這就是我們需要參考的內容。因此，請替換0xf8d6e0586b0a20c7為您部署中的帳戶地址。

接下來，我們定義交易。這里發生的一切都與我們計劃執行的交易有關。

我們在交易中要做的第一件事是定義兩個參考變量receiverRef和minterRef。在這種情況下，我們既是NFT的接收者又是NFT的鑄造者。這兩個變量引用了我們在合同中創建的資源。如果執行事務的人無權訪問該資源，則事務將失敗。

接下來，我們有一個prepare功能。此功能獲取嘗試執行交易的人員的帳戶信息并進行一些驗證。我們嘗試“借用”我們定義的NFTMinter和兩種資源上的可用功能NFTReceiver。如果執行交易的人沒有訪問這些資源的權限，那么事情將會失敗。

最后，我們有我們的execute功能。此功能是我們為NFT建立元數據，創建NFT，然后關聯元數據，然后再將NFT存入我們的帳戶的地方。如果您注意到的話，我創建了一個元數據變量。在該變量中，我添加了一些有關令牌的信息。由于我們的代幣表示在聚會上砸了一個披薩的事件，并且由于我們試圖復制您在NBA Top Shot中看到的大部分內容，因此我在元數據中定義了一些統計信息。孩子揮動棍子打皮納塔的速度，揮桿角度和等級。我只是在玩這些統計數據。但是，您將以類似的方式輸入對您的令牌有意義的任何信息。

您會注意到，我也在uri元數據中定義了一個屬性。這將指向承載與NFT關聯的資產文件的IPFS哈希。在這種情況下，這是被擊中的Pi?ata的實際視頻。您可以使用之前上傳文件后收到的哈希值替換哈希值。

ipfs://出于幾個原因，我們為哈希添加前綴。這是IPFS上文件的正確參考，可以與IPFS的桌面客戶端和瀏覽器擴展一起使用?，F在，我們為IPFS內容提供了本機支持，我們也可以將其直接粘貼到Brave瀏覽器中。

我們調用mintNFT創建令牌的函數。然后，我們必須調用該deposit函數以將其放入我們的帳戶。這也是我們傳遞元數據的地方。請記住，我們在deposit函數中定義了一個變量關聯，該關聯將元數據添加到關聯的令牌ID。

最后，我們簡單地注銷令牌已鑄造和存放的事實。

現在，我們幾乎準備發送交易并創建NFT。但是首先，我們需要準備我們的賬戶。從項目的根文件夾中的命令行，讓我們創建一個用于簽名的新私鑰。

運行以下命令：

flow keys generate 

這將為您提供一個公鑰和一個私鑰。**始終保護您的私鑰**

我們將需要私鑰來簽署交易，因此我們可以將其粘貼到我們的flow.json文件中。我們還需要指定簽名算法。這是文件中的accounts對象flow.json現在應如下所示：

"accounts": { 
  "emulator-account": { 
     "address": "YOUR ACCOUNT ADDRESS", 
     "privateKey": "YOUR PRIVATE KEY", 
     "chain": "flow-emulator", 
     "sigAlgorithm": "ECDSA_P256", 
     "hashAlgorithm": "SHA3_256" 
  } 
}, 

如果您打算將此項目中的任何一個存儲在github或任何遠程git存儲庫上，請確保不包括私鑰。您可能想要.gitignore全部flow.json。即使我們僅使用本地仿真器，還是保護您的密鑰的一種很好的做法。

現在我們已經更新了，我們可以發送交易了。這樣做就像運行以下命令一樣簡單：

flow transactions send --code ./transactions/MintPinataParty.cdc --signer emulator-account 

我們從中引用了我們編寫的交易文件和簽名人帳戶flow.json。如果一切順利，您應該會看到類似以下的輸出:

Getting information for account with address 0xf8d6e0586b0a20c7 ...

Submitting transaction with ID 4a79102747a450f65b6aab06a77161af196c3f7151b2400b3b3d09ade3b69823 ...

Successfully submitted transaction with ID 4a79102747a450f65b6aab06a77161af196c3f7151b2400b3b3d09ade3b69823

現在，我們要做的最后一件事是驗證令牌是否在我們的帳戶中并獲取元數據。這樣做，我們將編寫一個非常簡單的腳本并從命令行調用它。

在項目的根目錄中，創建一個名為的新文件夾scripts。在其中創建一個名為的文件CheckTokenMetadata.cdc。在該文件中，添加以下內容：

import PinataPartyContract from 0xf8d6e0586b0a20c7 
 
pub fun main() : {String : String} { 
    let nftOwner = getAccount(0xf8d6e0586b0a20c7) 
    // log("NFT Owner")     
    let capability = nftOwner.getCapability<&{PinataPartyContract.NFTReceiver}>(/public/NFTReceiver) 
 
    let receiverRef = capability.borrow() 
        ?? panic("Could not borrow the receiver reference") 
 
    return receiverRef.getMetadata(id: 1) 
} 

可以以類似于以太坊智能合約上的只讀方法的方式來考慮該腳本。他們是免費的，只需從合同中返回數據。

在我們的腳本中，我們正在從部署的地址導入我們的合同。然后，我們定義一個main函數(這是運行腳本所需的函數名稱)。在此函數內部，我們定義了三個變量：

• nftOwner：這只是擁有NFT的帳戶。我們從也部署了合同的帳戶中鑄造了NFT，因此在我們的示例中，這兩個地址是相同的。取決于將來的合同設計，這可能并不總是正確的。
• 功能：我們需要從已部署的合同中“借用”可用的功能(或功能)。請記住，這些功能是受訪問控制的，因此，如果某功能對于嘗試借用它的地址不可用，則腳本將失敗。我們正在從NFTReceiver資源中借用能力。
• receiverRef：該變量只是利用我們的能力，并告訴腳本從已部署的合同中借用。

現在，我們可以調用函數(可用的函數)了。在這種情況下，我們要確保所討論的地址實際上已收到我們鑄造的NFT，然后我們要查看與令牌關聯的元數據。

讓我們運行我們的腳本，看看我們得到了什么。在命令行上運行以下命令：

flow scripts execute ./scripts/CheckTokenMetadata.cdc 

對于元數據輸出，您應該看到類似以下的輸出：

{"name": "The Big Swing", "swing_velocity": "29", "swing_angle": "45", "rating": "5", "uri": "ipfs://QmRZdc3mAMXpv6Akz9Ekp1y4vDSjazTx2dCQRkxVy1yUj6"} 

恭喜你!您已成功創建Flow智能合約，鑄造了令牌以及與該令牌相關的元數據，并將該令牌的基礎數字資產存儲在IPFS上。接下來第二個部分的教程將構建一個簡單的React應用程序，該應用程序與Flow智能合約對接，以進行身份驗證并獲取用戶擁有的NFT，敬請期待。