本文介紹了 Metacube 中使用的交易批次程序，用於即時發送玩家賺取的 NFT。它解釋了批次程式基於參與者的可擴展架構，並提供了 Go 中的詳細實作。
所有程式碼片段都可以在關聯的 GitHub 儲存庫中找到。
巴徹由兩位主要演員組成：
這種參與者分離可以實現可擴展且高效的批次程序。建構器在發送者發送交易時準備交易，從而實現連續且高效的交易流。
以下實作特定於 Go，但這些概念可以輕鬆適應其他語言，因為功能保持不變。
此外，請注意，此實作特定於從同一合約發送 NFT。然而，本文後面提到了一種更通用的方法。
最後，程式碼是基於Nethermind開發的starknet.go函式庫。
讓我們從 Batcher 本身開始：
type Batcher struct {
accnt *account.Account
contractAddress *felt.Felt
maxSize int
inChan <-chan []string
failChan chan<- []string
}
帳戶（accnt）是持有NFT的帳戶，它將用於簽署轉移NFT的交易。這些 NFT 是同一合約的一部分，因此有合約地址欄位。 maxSize 欄位是批次的最大大小，inChan 是將交易傳送到 Batcher 的通道。 failChan 用於發回發送失敗的交易。
請注意，在這個實作中，後面所說的交易資料（[]string）是一個由兩個元素組成的陣列：接收者位址和 NFT ID。
Batcher 同時執行 Builder 和 Sender Actor：
type TxnDataPair struct {
Txn rpc.BroadcastInvokev1Txn
Data [][]string
}
func (b *Batcher) Run() {
txnDataPairChan := make(chan TxnDataPair)
go b.runBuildActor(txnDataPairChan)
go b.runSendActor(txnDataPairChan)
}
定義的通道 txnDataPairChan 將交易資料對從 Builder 傳送到 Sender。每個交易資料對都包含大量交易，每個交易的資料都嵌入其中。每筆交易的資料都與大量交易一起發送，以便失敗的交易可以發送回實例化 Batcher 的實體。
讓我們來分析一下Build actor。請注意，為了更好的可讀性，程式碼已被簡化（完整程式碼）：
type Batcher struct {
accnt *account.Account
contractAddress *felt.Felt
maxSize int
inChan <-chan []string
failChan chan<- []string
}
runBuildActor 函數是 Builder actor 的事件循環。它等待事務發送到批次程序，並在批次已滿或達到逾時時建置批次事務。然後批量交易被發送到 Sender actor。
現在讓我們來分析一下Sender actor。請注意，為了更好的可讀性，程式碼已被簡化（完整程式碼）：
type TxnDataPair struct {
Txn rpc.BroadcastInvokev1Txn
Data [][]string
}
func (b *Batcher) Run() {
txnDataPairChan := make(chan TxnDataPair)
go b.runBuildActor(txnDataPairChan)
go b.runSendActor(txnDataPairChan)
}
runSendActor 函數是傳送者 Actor 的事件循環。它等待 Builder 發送批量交易，對它們進行簽名，將它們發送到 Starknet 網絡，並監控它們的狀態。
關於費用估算的說明：可以在發送之前估算批量交易的費用成本。交易簽名後可加入以下程式碼：
// This function builds a function call from the transaction data.
func (b *Batcher) buildFunctionCall(data []string) (*rpc.FunctionCall, error) {
// Parse the recipient address
toAddressInFelt, err := utils.HexToFelt(data[0])
if err != nil {
...
}
// Parse the NFT ID
nftID, err := strconv.Atoi(data[1])
if err != nil {
...
}
// The entry point is a standard ERC721 function
// https://docs.openzeppelin.com/contracts-cairo/0.20.0/erc721
return &rpc.FunctionCall{
ContractAddress: b.contractAddress,
EntryPointSelector: utils.GetSelectorFromNameFelt(
"safe_transfer_from",
),
Calldata: []*felt.Felt{
b.accnt.AccountAddress, // from
toAddressInFelt, // to
new(felt.Felt).SetUint64(uint64(nftID)), // NFT ID
new(felt.Felt).SetUint64(0), // data -> None
new(felt.Felt).SetUint64(0), // extra data -> None
},
}, nil
}
// This function builds the batch transaction from the function calls.
func (b *Batcher) buildBatchTransaction(functionCalls []rpc.FunctionCall) (rpc.BroadcastInvokev1Txn, error) {
// Format the calldata (i.e., the function calls)
calldata, err := b.accnt.FmtCalldata(functionCalls)
if err != nil {
...
}
return rpc.BroadcastInvokev1Txn{
InvokeTxnV1: rpc.InvokeTxnV1{
MaxFee: new(felt.Felt).SetUint64(MAX_FEE),
Version: rpc.TransactionV1,
Nonce: new(felt.Felt).SetUint64(0), // Will be set by the send actor
Type: rpc.TransactionType_Invoke,
SenderAddress: b.accnt.AccountAddress,
Calldata: calldata,
},
}, nil
}
// Actual Build actor event loop
func (b *Batcher) runBuildActor(txnDataPairChan chan<- TxnDataPair) {
size := 0
functionCalls := make([]rpc.FunctionCall, 0, b.maxSize)
currentData := make([][]string, 0, b.maxSize)
for {
// Boolean to trigger the batch building
trigger := false
select {
// Receive new transaction data
case data, ok := <-b.inChan:
if !ok {
...
}
functionCall, err := b.buildFunctionCall(data)
if err != nil {
...
}
functionCalls = append(functionCalls, *functionCall)
size++
currentData = append(currentData, data)
if size >= b.maxSize {
// The batch is full, trigger the building
trigger = true
}
// We don't want a smaller batch to wait indefinitely to be full, so we set a timeout to trigger the building even if the batch is not full
case <-time.After(WAITING_TIME):
if size > 0 {
trigger = true
}
}
if trigger {
builtTxn, err := b.buildBatchTransaction(functionCalls)
if err != nil {
...
} else {
// Send the batch transaction to the Sender
txnDataPairChan <- TxnDataPair{
Txn: builtTxn,
Data: currentData,
}
}
// Reset variables
size = 0
functionCalls = make([]rpc.FunctionCall, 0, b.maxSize)
currentData = make([][]string, 0, b.maxSize)
}
}
}
這可能有助於確保在發送交易之前費用不會太高。如果估計費用高於預期，則可能還需要重新調整交易的最大費用欄位。但請注意，當交易發生任何更改時，必須重新簽名！
但請注意，如果交易吞吐量相當高，您在估算費用時可能會遇到一些問題。這是因為當給定的交易剛剛被批准時，更新帳戶的隨機數字會有一點延遲。因此，在估計下一筆交易的費用時，它可能會失敗，認為隨機數字仍然是前一筆交易。因此，如果您仍然想估算費用，那麼您可能需要在每筆交易之間提供一些睡眠以避免此類問題。
所提供的批次程式專門用於從同一合約發送 NFT。然而，該架構可以輕鬆適應發送任何類型的交易。
首先，發送到 Batcher 的交易資料必須更加通用，因此包含更多資訊。它們必須包含合約位址、入口點選擇器和呼叫資料。然後必須調整 buildFunctionCall 函數來解析此資訊。
還可以更進一步，將寄件者帳戶設為通用。這將需要更多的重構，因為必須針對每個發送者帳戶對交易進行批次處理。然而，它是可行的，並且可以實現更通用的批次機。
但是，請記住，過早的最佳化是萬惡之源。因此，如果您只需要發送 NFT 或特定代幣（例如 ETH 或 STRK），那麼提供的批次程式就足夠了。
儲存庫程式碼可以用作 CLI 工具來批次發送一堆 NFT。該工具易於使用，閱讀本文後您應該能夠根據您的需求進行調整。請參閱 README 以了解更多資訊。
我希望這篇文章可以幫助您更好地了解Metacube如何向其玩家發送NFT。批次程序是一個關鍵的基礎設施組件，我們很高興與社區分享它。如果您有任何問題或回饋，請隨時發表評論或與我聯繫。感謝您的閱讀！
以上是Starknet 交易批量處理程序的詳細內容。更多資訊請關注PHP中文網其他相關文章！
