Ausstehende Transaktionen aus txpool in Geth entfernt

Wir haben daran gearbeitet, unser privates Blockchain-Netzwerk mit Geth und Web3j zu testen. Die Transaktionen werden über Web3j gesendet.

Wir senden 100 Transaktionen, wobei jeder Block Platz für etwa 25 davon hat (wegen Gaslimit). Wenn Transaktionen auf unserem lokalen Knoten empfangen werden, wird dies gedruckt:

TRACE[07-26|10:15:53] Pooled new future transaction            hash=20453e…f2ec96 from=0x992a03b1bb4cc56929f2d21eaf34779d0562c9a7 to=0x32f1e2e74122efd01bd666750c5afc18c4ce3f91
TRACE[07-26|10:15:53] Promoting queued transaction             hash=20453e…f2ec96
INFO [07-26|10:15:53] Submitted transaction                    fullhash=0x20453ef67cba4d3549603f7a0bc0505d170a8fc2adeac849dc1a8c2fa3f2ec96 recipient=0x32f1e2e74122efd01bd666750c5afc18c4ce3f91
TRACE[07-26|10:15:53] Broadcast transaction                    hash=20453e…f2ec96 recipients=2
DEBUG[07-26|10:15:54] Transaction pool status report           executable=43 queued=0 stales=9

Wenn alle Transaktionen gesendet wurden, ist unser Transaktionspool der lokalen Knoten txpool.status:

{
  pending: 100,
  queued: 0
}

Wir beginnen dann mit dem Mining auf unserem lokalen Knoten.

INFO [07-26|10:20:41] Starting mining operation 
TRACE[07-26|10:20:41] Gas limit exceeded for current block     sender=0x992a03b1bb4cc56929f2d21eaf34779d0562c9a7
INFO [07-26|10:20:41] Commit new mining work                   number=8383 txs=25 uncles=0 elapsed=18.063ms
TRACE[07-26|10:20:41] Started ethash search for new nonces     miner=0 seed=4567440808604611913
DEBUG[07-26|10:20:42] Transaction pool status report           executable=100 queued=0 stales=8
TRACE[07-26|10:20:48] Ethash nonce found and reported          miner=0 attempts=313611  nonce=4567440808604925524
INFO [07-26|10:20:48] Successfully sealed new block            number=8383 hash=774d72…ba62fc
DEBUG[07-26|10:20:48] Trie cache stats after commit            misses=11 unloads=2
INFO [07-26|10:20:48] 🔗 block reached canonical chain          number=8378 hash=81b120…f0867f
INFO [07-26|10:20:48] 🔨 mined potential block                  number=8383 hash=774d72…ba62fc
TRACE[07-26|10:20:48] Transaction failed, will be removed      hash=05c537…979f0b err="invalid nonce: have 731, expected 756"
INFO [07-26|10:20:48] Commit new mining work                   number=8384 txs=0  uncles=0 elapsed=957.166µs
TRACE[07-26|10:20:48] Propagated block                         hash=774d72…ba62fc recipients=1 duration=2562047h47m16.854s
TRACE[07-26|10:20:48] Announced block                          hash=774d72…ba62fc recipients=2 duration=2562047h47m16.8

Nach dem Abbau eines Blocks mit 25 Transaktionen ist unser Txpool jetzt leer

{
  pending: 0,
  queued: 0
}

Nur 25 der insgesamt 100 Transaktionen wurden abgebaut und der Rest wurde gelöscht (sie scheinen als alte ausstehende Transaktionen deklariert zu sein). Meine Frage ist dann. Ist dies das beabsichtigte Verhalten oder übersehen wir etwas? Wenn es beabsichtigt ist, hat jemand Tipps, wie das Senden mehrerer Transaktionen von derselben Adresse und demselben Knoten gelöst werden kann?

BEARBEITEN:

Wir haben einen Supervisor eingerichtet, der nach bestätigten Transaktionen sucht und versucht, die Transaktionen erneut zu senden, wenn sie verloren gegangen sind. Beim erneuten Senden der Transaktionen erhalten wir den Fehler:

-32000 know transaction: transaction_hash

Beim manuellen Senden von eth.getTransactionReciept(transaction_hash) wird jedoch null zurückgegeben.

Wo werden bekannte Transaktionen gespeichert und warum werden sie nicht abgebaut? (Sie sind nicht in txpool)

Werden die Transaktionen von derselben Adresse gesendet? Wenn ja, ist es vielleicht ein nicht damit zusammenhängendes Problem.
Die Transaktionen werden von derselben Adresse gesendet, aber da sie alle den Status "ausstehend" haben, würde ich denken, dass die Ankündigungen korrekt sind? Vielleicht entscheidet sich Geth dafür, die neuesten Transaktionen zu minen, und daher sind die Ankündigungen der anderen Transaktionen veraltet?
Ich sehe ähnliche Ergebnisse mit dem folgenden Code: var arr = [] ; for (i = 1 ; i<= 110; i++){ arr.push(eth.sendTransaction({from: eth.coinbase, to: eth.accounts[1], value: web3.toWei( i/1000 + 1 , 'szabo')}))}erstellt 110 ausstehende txns, aber wenn das Mining abgeschlossen ist, werden nur etwa 105 abgebaut. Also eth.getTransactionReceipt(arr[100]) wird mir ein Ergebnis geben, aber dasselbe mit arr[109] wird eine Null geben. Diese fehlenden txns sind verwaist - nicht in txpool etc. Nonces unterscheiden sich.
Ich konnte ähnliche Symptome erleben und sie im Protokoll abfangen. Siehe dieses Problem: github.com/ethereum/go-ethereum/issues/14893

Antworten (2)

das ergebnis ist in ordnung. Zuerst sende ich 110 txs, das Ergebnis von txpool.status

{
    pending: 110,
    queued: 0
}

und dann mit dem Abbau beginnen, alle Transaktionen wurden abgebaut. Wie folgt Geben Sie hier die Bildbeschreibung ein, damit der tx_pool keine Transaktionen löscht. In Go-Ethereum-Quelldateien befasst sich die Datei tx_pool.go mit der Transaktionslogik, einige Transaktionen werden entfernt, wenn tx_pool voll ist, dass die Poolgröße über 4096 + 1024 liegt, die Quelle wie folgt:

// If the transaction pool is full, discard underpriced transactions
if uint64(len(pool.all)) >= pool.config.GlobalSlots+pool.config.GlobalQueue {
    // If the new transaction is underpriced, don't accept it
    if pool.priced.Underpriced(tx, pool.locals) {
        log.Trace("Discarding underpriced transaction", "hash", hash, "price", tx.GasPrice())
        underpricedTxCounter.Inc(1)
        return false, ErrUnderpriced
    }
    // New transaction is better than our worse ones, make room for it
    drop := pool.priced.Discard(len(pool.all)-int(pool.config.GlobalSlots+pool.config.GlobalQueue-1), pool.locals)
    for _, tx := range drop {
        log.Trace("Discarding freshly underpriced transaction", "hash", tx.Hash(), "price", tx.GasPrice())
        underpricedTxCounter.Inc(1)
        pool.removeTx(tx.Hash())
    }
}

also kein überlauf.

Waren alle Transaktionen in einem einzigen Block enthalten, oder mussten Sie mehrere Blöcke abbauen, um sie alle einzuschließen?
Ich bin auf dieses Problem beim Überlauf 210 gestoßen. Aber ich finde, dass dies eine Beziehung zu gasLimit hat, jeder Block enthält txs = gasLimit / per_tx_gas (test 21000), wenn es mehr txs gibt, wird es in den nächsten neuen Block gepackt. Also konfiguriere ich ein großes gasLimit in der Datei genesis.json:{ "config": { "chainId": 10, "homesteadBlock": 0, "eip155Block": 0, "eip158Block": 0 }, "difficulty": "0x400000", "gasLimit": "2100000000000000000", "alloc": { "0xf85209fa42a3445362d82636c470b6e1e4bc7a33": { "balance": "30000000000000000000000" } } }
und ich sende 10249 txs, beginne dann mit dem Mining, alle Transaktionen enthalten einen neuen Block. wegen zu viel txs wird das Ergebnis von getBlock (blockNum) außerhalb des Bildschirms sein, also verwende ich das JSON RPC-Druckergebnis: curl -X POST --data '{"jsonrpc":"2.0","method":"eth_getBlockTransactionCountByHash ","params":["0x5e678f610a98799edaf8664ddc988332af6301513aace6a92b65a823491afcc0"],"id":1}' localhost:8545 {"jsonrpc":"2.0","id":1,"result":"0x2809"} finden Sie Detaillogik auf tx_pool.demoteUnexecutables-Methode.

Sieht aus wie ein Fehler, der gerade behoben wurde: https://github.com/ethereum/go-ethereum/issues/14893

Ausstehende Transaktionen aus txpool in Geth entfernt
AntwortenHierDatenschutz-Bestimmungen1y, 0v