search

AntelopeIO / leap

C++ implementation of the Antelope protocol
Other
116 stars 70 forks source link

Deferred trx id and deep-mind plugin #163

Closed YaroShkvorets closed 2 years ago

YaroShkvorets commented 2 years ago

Deep-mind plugin seems to be logging wrong transaction ids. Specifically, when replacing existing deferred transaction.

I used this script to boot up Leap 3.1 node and push these 2 transactions. Each of them create a deferred inline transaction delayed by 1 second that's instructed to fail.

Here's the resulting deep-mind log file

I then used this go program based on the StreamingFast utility to decode it into this json file

Here's what I'm seeing in this json file:

Deferred transaction with id be5965379e5922621c861fc5e27bfb9011caf5f6deb2fffeb0dd9bd31e6f61c8 is 1) created - OPERATION_CREATE op 2) canceled - OPERATION_MODIFY_CANCEL op 3) recreated - OPERATION_MODIFY_CREATE op 4) fails - TRANSACTIONSTATUS_HARDFAIL status

First question is why it is recreated with the same id? Shouldn't it have the new id since it's pushed in a different block?

Second thing is, I'm seeing another transaction with id = dc7cf846e67f0dd2a7310221b7a5dfa79fc67df6644aaba05faad12958119ed5 This transaction fails with TRANSACTIONSTATUS_SOFTFAIL status and it appears to be the one that replaced first deferred transaction in 3) above?

Note, that there is no OPERATION_CREATE for that trx id. As if it was never created by the node and just materialized out of nowhere and then failed.

YaroShkvorets commented 2 years ago

OK, after activating "REPLACE_DEFERRED" feature as suggested by @heifner, transaction ids seem to match what I'm expecting, so that's good.

However, networks that choose not to have that feature activated would see these orphan trx ids in their deepmind logs like dc7cf846e67f0dd2a7310221b7a5dfa79fc67df6644aaba05faad12958119ed5 in the example above.

Not sure if it's a bug or not. 🤔

heifner commented 2 years ago

The issue here is that REPLACE_DEFERRED & NO_DUPLICATE_DEFERRED_ID are bug fix protocol features. They were introduced to address this issue of non-unique deferred transaction ids. Without the activated protocol features it is not possible to distinguish between these types of deferred transactions by transaction id.

Since it is recommended that all new chains activate all protocol features, this should only be an issue when trying to deep mind log old portions of old chains before the addition of these protocol features. It is our understanding that is not a use case for deep mind logging. Therefore, it does not seem worth the effort to add additional deep mind logging around the cases where REPLACE_DEFERRED & NO_DUPLICATE_DEFERRED_ID protocol features are not activated.