From 120911a2628ba7b37cf0390eff724291db35b6c6 Mon Sep 17 00:00:00 2001 From: iamveritas Date: Wed, 10 Feb 2021 22:14:21 +0200 Subject: [PATCH] fixes #971 [docs] Deferred transaction collisions and NO_DUPLICATE_DEFERRED_ID --- docs/05_best-practices/09_deferred_transactions.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/docs/05_best-practices/09_deferred_transactions.md b/docs/05_best-practices/09_deferred_transactions.md index 7866fed4cd..82036a6734 100644 --- a/docs/05_best-practices/09_deferred_transactions.md +++ b/docs/05_best-practices/09_deferred_transactions.md @@ -10,3 +10,6 @@ As already mentioned, deferred communication will get scheduled later at the pro | As of [EOSIO 2.0 RC1](https://github.com/EOSIO/eos/releases/tag/v2.0.0-rc1) deferred transactions are deprecated. Due to the above described behaviors it is not recommended to use `deferred transactions`. + +[[warning | Duplicate deferred transaction IDs]] +| In earlier versions, prior to `v1.8.0`, it is possible to observe rare deferred transaction ID collisions because technically the protocol's validation rules allow any number of duplicate deferred transaction IDs. However, the block producing code prior to `v1.8.0` limited this to exactly one duplicate ID in the same block followed by at-most one duplicate ID in the following block. This behavior was mitigated starting with version `v1.8.0` making it functionally impossible to be achieved at the block producing code level. On top of that, the same version `v1.8.0` introduced the optional `NO_DUPLICATE_DEFERRED_ID` protocol feature which, if deployed, it makes this behavior impossible at the protocol layer as well.