Opération injectée au nœud, mais non ajoutée à Blockchain | Erreur de compteur de portefeuille

Question

Opération injectée au nœud, mais non ajoutée à Blockchain | Erreur de compteur de portefeuille

- 0
- 169 2019-12-08
J'utilisemonproprenœud Babbylonet j'ai déjà ajouté duportefeuille du robinet Tezoset envoyez despièces àmonportefeuillegénéré avec Tezos-Client:

./Tezos-Client Transfert 8500 de Test_w1 à TZ1B3RXJP2TDQZEVMDBTOBCZ6QPCBHSYS6XA --BURN-CAP 258

Envoyer viaeztz.js

Maintenant,j'essaie d'envoyer destezos d'unportefeuillegénéré à un autre avec Eztz.js lib. Utilisez ce code:

ASYNC Fonction Envoyer (Tadrable,Touches,Montant,Frais) { //Fonction (contrat,àpartir de,touches,montant,paramètre,frais,gaslimite,stockageelimit) attendreeztz.contract.send (toaddress,keys.pkh,clés,montant,"",frais,20000,20000); } attendreenvoyer ( "TZ1QHRFZJCPJONIQWQNUUUHHAMKLN7ADUMSN", { PK: "EDPKVVBT6JFIT2MHKEP9BEVUBXMENK7GUYO3IRWXWY3Y4RK8VRRACA", PKH: "TZ1B3RXJP2TDQZEVMDBTOBCZ6QPCBHSYS6XA", SK: "EDSKRNY9TBJRJFCKS1TWEQFM789RHBHDSCHRUSM4HUVQOYQNQSPEUPLQAHC8QAXMY7VMOV5GFTTTT1PXBVMU8EIGRUOCE3HB8TQ" }, 300000000, 10000000 );

Quandje l'exécutepour lapremièrefois - lenœudinjectemonfonctionnementet même l'adresse de retour de latransaction,mais cetransfertne s'estpas ajouté à Blockchain,mon solden'apas été changé. Première opération defonctionnement:

Lorsque vous avezessayé d'envoyer la deuxièmefois - obtenez l'erreur du compteur:

Erreur lors de l'application de l'opération OnnQhbu5BIGTJBCRZD8HYPTVZKSYITIONSM2TBVGMS9UNMVSFHNBG: \ NBranch refusée (erreur: \n compteur 128324 déjà utilisépour le contrat TZ1B3RXJP2TDQEVMDBTOBCZ6QPCBHSYS6XA (attendu 128326) \n) "}]

Logs de deuxièmefois:

Si définitmanuellement le compteur sur 128326 - recevoir uneerreur compteur_in_the_future .

L'erreur du compteur disparu après une demi-heure,maistoujours sij'essaie d'envoyer despièces demonnaie - l'opérationne serapasincluse à Blockchainet je recevrai denouveau contre l'erreur.

Envoyer via Tezos-Client

J'aiimportéma cléprivéegénérée commetest_w2et essayer d'envoyer despièces avec Tezos-Client:

./Tezos-Client Transfert 8500 de Test_w2 à Tz1uqBubMBktevpn6JKNQWC3TAOBNDTMTIC --BURN-CAP 258

premièrefois quej'ai lamêmeerreur de compteur:

Mais après une demi-heure,celafonctionnait:

Cela signifie donc,uneerreurpas dans lesportefeuillesgénérant ou lenœud Tezos,uneerreurpeut être uniquement dans le client EZTZ.JS ou les valeurs réussies. Peut-être quej'aipassé demauvaisfrais/gas_limit/montant?

Commentpuis-je résoudre ceproblème?

note. Enfait,j'utilise labibliothèque Tz.Net Forked (C #),maiselle a lemêmeflux detravail que Eztz.jset je reçois lesmêmeserreurs.
I use my own babbylon node and previously i have added some wallet from tezos faucet and send some coins to my generated wallet with tezos-client:

./tezos-client transfer 8500 from test_w1 to tz1b3RxJP2TDQZEvmdBtobCZ6QpcBHSYs6xA --burn-cap 258

Send via eztz.js

Now i'm trying to send tezos from one generated wallet to another with eztz.js lib. Use this code:

async function send(toAddress, keys, amount, fee) { //function (contract, from, keys, amount, parameter, fee, gasLimit, storageLimit) await eztz.contract.send(toAddress, keys.pkh, keys, amount, "", fee, 20000, 20000); } await send( "tz1QHRFZJcPJoNiqWQnuUuHHAmKLN7AdUmSN", { pk: "edpkvVbT6jFiT2MHKEp9BeVubxmEnK7GUYo3iRwxWWY3Y4Rk8VrRcA", pkh: "tz1b3RxJP2TDQZEvmdBtobCZ6QpcBHSYs6xA", sk: "edskRny9Tbjrjfcks1TWEQfM789RHbhdscHRuSm4huvQoYqNQsPeupLqahC8q2Xmy7vmov5gfTTT1PxBVmu8EigRuocE3hB8tQ" }, 300000000, 10000000 );

When i execute it first time - node inject my operation and even return address of transaction, but this transfer wansn't added to blockchain, my balance wasn't changed. First time operation logs:

When tried to send second time - get counter error:

Error while applying operation onnqHbU5bigtJbCRZD8HYPtVZKsyioNSM2tbvGMS9unMVsfhnBG:\nbranch refused (Error:\n Counter 128324 already used for contract tz1b3RxJP2TDQZEvmdBtobCZ6QpcBHSYs6xA (expected 128326)\n)"}]

Second time logs:

If manually set counter to 128326 - will receive error counter_in_the_future.

Counter error gone after half an hour, but still if i try to send coins - operation will be not included to blockchain and i will receive counter error again.

Send via tezos-client

I imported my generated private key as test_w2 and try to send coins with tezos-client:

./tezos-client transfer 8500 from test_w2 to tz1UqBubMBKtEVpN6jkNQwc3TAoBNdtmtiyM --burn-cap 258

First time i've get same counter error:

But after half an hour it worked:

So it means, error not in wallets generating or tezos node, error can be only in eztz.js client or passed values. Maybe i've passed wrong fee / gas_limit / amount?

How can i fix this?

Note. Actually, i use forked Tz.Net library (c#), but it has same workflow as eztz.js and i receive same errors.
transactions operation transfer eztz offline

1 réponses

votes

vbot · Answer 1 · 2020-01-02

0

2020-01-02

TLDR : lapremière opération que vous avezinjectée dans votrenœudest validemaisne serajamaisinjectéepar d'autresnœuds/boulangers caril a desfraistropbas. Ilestensuitebloqué dans lamémoire MEMPOOLet effectuez les opérations suivantes que vousessayez deforger unproblèmenon valide car leprochain compteur valide que vous souhaitez utiliserest déjàprispar l'opération defraistropbasse. Vouspouvez redémarrer votrenoeud ou attendre 60blocs depasserpour déverrouiller la situation.

Ce queje crois arriveici,c'est que lapremière opération que vous avezinjectéeest considérée commeinvalidepar vos autrespairs. Comme vous l'avez dit,ilpeut être rejetépourplusieurs raisons (pas suffisamment defrais étant la case laplus courante).

Donc,vous avezforgé une opération valide concernant leprotocoleet donc valable dans lamémoire MEMPOOL. Votrenoeud a accepté l'injection de l'opération car certainsboulangerspourraient accepteret y compris les opérations de 0 redevances. Cependant,par défaut,cen'estpas le cas. L'opération que vous avezinjectée dans lenœud vit ainsi dans lamémoire MEMPOOL d'attendre unboulanger l'inclure dans unbloc.

vient donc lapartietechnique. Lorsque vous demandez aunœud deforger une opérationpour vous,le client (ou l'API que vous utilisez) demandera aunœud du compteur associé à votre compte (Note latérale: le compteuresticipourempêcher les attaques de replay). Pour saisir cetteinformation,lenœudinterrogera les données à l'aide de l'état actuel de la chaîne (c'est-à-dire que l'état résultant de l'application du dernierbloc reçu)et reviendra,parexemple, 1000 . Pour l'opération que vous avezforgéepour être valide,son compteur doit alors être 1001 . Si cen'estpas le cas,cela vous donnera un compteur dans le député ou dans l'erreurfuture lorsque lenœudtente de le valider.

Dans votre cas,vous avezinjecté une opération Fraistropbas avec un compteur 128324 . Votrenoeudestime que vous savez ce que vousfaites (parexemple,essayer d'obtenir unboulanger àfaiblefraispour l'injecter)et ne vérifie doncpas lesfrais. S'iln'y apas deboulangerbasse-fraisen cours d'exécution dans le réseau,votre opérationne serajamaisincluseet bloquée dans lamémoire MEMPOOLpour 60 (20minminimum à Babylonnet). Après ces 60blocs,l'opération sera considérée commetrop ancienneet purgée de lamémoiremémoire. C'estpourquoi,aprèsparfois,la situation a été déverrouillée.

Maintenant,alors que cette opérationnon valideestbloquée dans lamémoire MEMPOOL,laprochaine opération que vous avezforgée à l'aide du client demandera également le compteur dunœudet que votre dernière opérationn'apas étéincluse,le compteurprécédent 128324 sera utilisé ànouveau qui collime avec latransactionprécédente. Lorsque cela seproduit,lamémoire MEMPOOLn'estpas heureuse carelleessaiera de valider les opérations l'une après l'autre. Comme votrepremière opérationest valide (même siellene serajamaisincluse),il sera appliqué sur son étatinterne quiest un étatintermédiaire où votrepremière opération a été appliquée ainsi leprochain contrain attendu augmentépar une. Laprochainefois qu'une opérationest reçue (pour lemême compte),lamémoire MEMPOOL s'attendra à ce que le compteur soit augmenté à 128325 . Si cen'estpas le cas,alorsil le rejetera avec un compteur dans lepassé . Si vousessayez d'augmentermanuellement le compteur,vouspourriez obtenir compteur à l'avenir .

Comment sortir de cette situation:

Vouspouvez attendre que 60pâtés demaisons réussissentpuis que votretransaction soit suppriméepour êtretrop âgée;

Vouspouvez redémarrer votrenoeud si vous le contrôlez. Lamémoiremempoolesteffacée lorsque lenœud s'arrête;

Vouspouvezforgeret injecter votretransactionen utilisant un autrenoeud. Un,quin'aurapas l'opérationinvalidebloquée dans samémoire MEMPOOL.

Dans laprochaine version Shell,nous visons àinclure un RPC d'administrateur qui sera utilisépour supprimer une opération spécifique de lamémoire MEMPOOL.

P.s. Vouspouvez vérifier quelles opérations vivent dans lamémoire MEMPOOL à l'aide du RPC /CHAKINES/MAIN/MEMPOOL/PENDING_OPERATIONS

TLDR: the first operation you injected in your node is valid but will be never be injected by other nodes/bakers because it has too low fees. It is then stuck in the mempool and make the the next operations you're trying to forge invalid because the next valid counter you want to use is already being taken by the too low fee operation. You can restart your node or wait for 60 blocks to pass to unlock the situation.

What I believe happens here is that the first operation you injected is considered invalid by your other peers. As you said, it can be rejected for multiple reasons (not enough fees being the most common case).

So, you forged an operation which is valid regarding the protocol and therefore valid in the mempool. Your node accepted injecting the operation because some bakers might be accepting and including 0 fees operations. However, by default, this is not the case. The operation you injected in the node is thus living in the mempool waiting for a baker to include it in a block.

So now comes the technical part. When you request the node to forge an operation for you, the client (or the API you're using) will request from the node the counter associated to your account (side note: the counter is here to prevent replay attacks). To grab this information, the node will query the data using the current state of the chain (i.e. the state that results from the application of the last block received) and will return, for example, 1000. For the operation you're forging to be valid, its counter must then be 1001. If this is not the case, it will give you a counter in the past or counter in the future error when the node is trying to validate it.

In your case, you injected a too low fee operation with a counter 128324. Your node considers that you know what you're doing (e.g. trying to get a low-fee baker to inject it) and thus does not check for the fees. If there are no low-fee baker running in the network, your operation will never be included and stuck in the mempool for 60 blocks (20min minimum in babylonnet). After those 60 blocks, the operation will considered too old and purged from the mempool. This is why, after some times, the situation was unlocked.

Now, while this invalid operation is stuck in the mempool, the next operation you forge using the client will also request the counter from the node and as your last operation was not included, the previous counter 128324 will be used again which collides with the previous transaction. When this happens, the mempool is not happy because it will try to validate the operations one after the other. As your first operation is valid (even if it will never be included), it will be applied on its internal state which is an intermediate state where your first operation was applied thus making the next expected counter increased by one. The next time an operation is received (for the same account) the mempool will expect the counter to be increased to 128325. If that's not the case, then it will reject it with a counter in the past error. If you try to manually increase the counter, you might get counter in the future.

How to get out of this situation:

you may wait for 60 blocks to pass by and then your transaction will be discarded for being too old;

you can restart your node if you have control over it. The mempool is erased when the node stops;

you can forge and inject your transaction using another node. One, which will not have the invalid operation stuck in its mempool.

In the next shell release, we aim to include an admin RPC that will be used to remove a specific operation from the mempool.

P.S. You may check which operations live in the mempool using the RPC /chains/main/mempool/pending_operations

la source

vbot

Commentenverriez-vousplusieurstransactions dans lemêmebloc?Celane signifie-t-ilpas quetant que l'ancienne opérationn'estpasencore confirmée,nousne pouvons diffuser aucunenouvelle opération à cause de cetteinadéquation là-bas?

How would you then send multiple transactions in the same block? Doesn't that mean that as long as the old operation is not yet confirmed, we can't broadcast any new operation because of this mismatch there?

0

2020-05-09

CherryDT

Opération injectée au nœud, mais non ajoutée à Blockchain | Erreur de compteur de portefeuille

Envoyer viaeztz.js

Envoyer via Tezos-Client

Send via eztz.js

Send via tezos-client

1 réponses