Ein Starknet-Transaktions-Batcher

Abstrakt

In diesem Artikel wird der Transaktions-Batcher vorgestellt, der in Metacube verwendet wird, um von Spielern verdiente NFTs sofort zu versenden. Es erklärt die skalierbare akteurbasierte Architektur des Batchers und bietet eine detaillierte Implementierung in Go.

Alle Codeausschnitte sind im zugehörigen GitHub-Repository verfügbar.

Architektur

Der Batcher besteht aus zwei Hauptakteuren:

• Der Builder empfängt die Transaktionen, bündelt sie in einer einzigen Multicall-Transaktion und sendet sie an den Sender-Akteur.
• Der Absender schließt die Transaktion mit den entsprechenden Feldern (Nonce, Höchstgebühr usw.) ab, signiert sie, sendet sie an das Starknet-Netzwerk und überwacht ihren Status.

Diese Akteurstrennung ermöglicht einen skalierbaren und effizienten Batcher. Der Builder bereitet die Transaktionen vor, während der Absender sie sendet, und ermöglicht so einen kontinuierlichen und effizienten Transaktionsfluss.

Durchführung

Die folgende Implementierung ist spezifisch für Go, aber die Konzepte können leicht an andere Sprachen angepasst werden, da die Funktionalitäten gleich bleiben.

Beachten Sie außerdem, dass diese Implementierung speziell für den Versand von NFTs aus demselben Vertrag gilt. Ein allgemeinerer Ansatz wird jedoch später im Artikel erwähnt.

Schließlich basiert der Code auf der von Nethermind entwickelten Bibliothek starknet.go.

Batcher

Beginnen wir mit dem Batcher selbst:

type Batcher struct {
    accnt           *account.Account
    contractAddress *felt.Felt
    maxSize         int
    inChan          <-chan []string
    failChan        chan<- []string
}

Das Konto (acnt) ist das Konto, auf dem sich die NFTs befinden. Es wird zum Signieren der Transaktionen verwendet, mit denen sie übertragen werden. Diese NFTs sind Teil desselben Vertrags, daher das Feld „contractAddress“. Das Feld maxSize gibt die maximale Größe eines Batches an und inChan ist der Kanal, über den die Transaktionen an den Batcher gesendet werden. Der failChan wird verwendet, um die Transaktionen zurückzusenden, die nicht gesendet werden konnten.

Beachten Sie, dass in dieser Implementierung die später genannten Transaktionsdaten ([]string) ein Array aus zwei Elementen sind: der Empfängeradresse und der NFT-ID.

Der Batcher führt sowohl die Builder- als auch die Sender-Akteure gleichzeitig aus:

type TxnDataPair struct {
    Txn  rpc.BroadcastInvokev1Txn
    Data [][]string
}

func (b *Batcher) Run() {
    txnDataPairChan := make(chan TxnDataPair)

    go b.runBuildActor(txnDataPairChan)
    go b.runSendActor(txnDataPairChan)
}

Der definierte Kanal txnDataPairChan sendet die Transaktionsdatenpaare vom Builder an den Sender. Jedes Transaktionsdatenpaar umfasst die Stapeltransaktion, und die Daten für jede Transaktion sind darin eingebettet. Die Daten für jede Transaktion werden mit der Batch-Transaktion gesendet, sodass die fehlgeschlagenen Transaktionen an die Entität zurückgesendet werden können, die den Batcher instanziiert.

Baumeister

Lassen Sie uns den Build-Akteur analysieren. Beachten Sie, dass der Code zur besseren Lesbarkeit vereinfacht ist (vollständiger Code):

type Batcher struct {
    accnt           *account.Account
    contractAddress *felt.Felt
    maxSize         int
    inChan          <-chan []string
    failChan        chan<- []string
}

Die runBuildActor-Funktion ist die Ereignisschleife des Builder-Akteurs. Es wartet darauf, dass Transaktionen an den Batcher gesendet werden, und erstellt eine Batch-Transaktion, wenn der Batch voll ist oder eine Zeitüberschreitung erreicht ist. Die Batch-Transaktion wird dann an den Absender-Akteur gesendet.

Absender

Lassen Sie uns nun den Sender-Akteur analysieren. Beachten Sie, dass der Code zur besseren Lesbarkeit vereinfacht ist (vollständiger Code):

type TxnDataPair struct {
    Txn  rpc.BroadcastInvokev1Txn
    Data [][]string
}

func (b *Batcher) Run() {
    txnDataPairChan := make(chan TxnDataPair)

    go b.runBuildActor(txnDataPairChan)
    go b.runSendActor(txnDataPairChan)
}

Die runSendActor-Funktion ist die Ereignisschleife des sendenden Akteurs. Es wartet darauf, dass der Builder Batch-Transaktionen sendet, signiert sie, sendet sie an das Starknet-Netzwerk und überwacht ihren Status.

Ein Hinweis zur Gebührenschätzung: Sie können die Gebührenkosten der Sammeltransaktion vor dem Senden abschätzen. Der folgende Code kann nach der Unterzeichnung der Transaktion hinzugefügt werden:

// 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)
        }
    }
}

Dies kann nützlich sein, um vor dem Senden der Transaktion sicherzustellen, dass die Gebühr nicht zu hoch ist. Wenn die geschätzte Gebühr höher als erwartet ist, muss möglicherweise auch das Feld „Maximale Gebühr“ der Transaktion neu angepasst werden, wenn die geschätzte Gebühr höher als erwartet ist. Beachten Sie jedoch, dass bei jeder Änderung der Transaktion diese erneut unterzeichnet werden muss!

Beachten Sie jedoch, dass bei der Schätzung der Gebühren Probleme auftreten können, wenn der Transaktionsdurchsatz recht hoch ist. Dies liegt daran, dass es bei der gerade genehmigten Transaktion zu einer gewissen Verzögerung bei der Aktualisierung der Konto-Nonce kommt. Daher kann es bei der Schätzung der Gebühr für die nächste Transaktion zu einem Fehlschlag kommen, da man davon ausgeht, dass es sich bei der Nonce immer noch um die vorherige handelt. Wenn Sie also dennoch die Gebühren schätzen möchten, müssen Sie möglicherweise zwischen den einzelnen Transaktionen etwas Ruhe einplanen, um solche Probleme zu vermeiden.

Auf dem Weg zu einem generischen Batcher

Der vorgestellte Batcher ist speziell für den Versand von NFTs aus demselben Vertrag gedacht. Die Architektur kann jedoch problemlos angepasst werden, um jede Art von Transaktion zu senden.

Erstens müssen die an den Batcher gesendeten Transaktionsdaten allgemeiner sein und daher mehr Informationen enthalten. Sie müssen die Vertragsadresse, den Einstiegspunktselektor und die Anrufdaten enthalten. Anschließend muss die buildFunctionCall-Funktion angepasst werden, um diese Informationen zu analysieren.

Man könnte auch noch einen Schritt weiter gehen und das Absenderkonto generisch gestalten. Dies würde mehr Refactoring erfordern, da die Transaktionen pro Absenderkonto gebündelt werden müssen. Es ist jedoch machbar und würde einen vielseitigeren Dosierer ermöglichen.

Denken Sie jedoch daran, dass vorzeitige Optimierung die Wurzel allen Übels ist. Wenn Sie also nur NFTs oder einen bestimmten Token wie ETH oder STRK senden müssen, ist der bereitgestellte Batcher mehr als ausreichend.

CLI-Tool

Der Repository-Code kann als CLI-Tool verwendet werden, um eine Reihe von NFTs stapelweise zu versenden. Das Tool ist einfach zu bedienen und Sie sollten es nach dem Lesen dieses Artikels an Ihre Bedürfnisse anpassen können. Weitere Informationen finden Sie in der README-Datei.

Abschluss

Ich hoffe, dass dieser Artikel Ihnen geholfen hat, besser zu verstehen, wie Metacube NFTs an seine Spieler sendet. Der Batcher ist eine wichtige Infrastrukturkomponente und wir freuen uns, ihn mit der Community zu teilen. Wenn Sie Fragen oder Feedback haben, können Sie gerne einen Kommentar abgeben oder sich an mich wenden. Vielen Dank fürs Lesen!

Das obige ist der detaillierte Inhalt vonEin Starknet-Transaktions-Batcher. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!