Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Consensus upgrade to avoid transaction ID collision of deferred transactions #6115
A contract-generated transaction (a deferred transaction), which is provided by the contract using the
Nevertheless, in the current implementation of
While the likelihood of transaction ID collision is low (given certain assumptions about producer behavior), it would be desirable for transaction ID collision to be virtually impossible regardless of the policy set by producers about how to retire deferred transactions. In the context of this document, "virtually impossible" means no more likely than getting a hash collision by taking a SHA256 cryptographic hash of two distinct bit streams.
Another potentially desirable property for scheduling contract-generated transactions is to make it possible for the contract to determine what the ID of the scheduled deferred transaction will actually be. However, while that is a desirable property, it is not a property we require since there really should be no need for a contract to know that information since they already have a
Of the various candidate solutions considered, two of them stand out.
The first candidate (referred to as "Global deferred sequence number as TaPoS field") is to add a new global sequence number which tracks the new deferred transactions that were successfully scheduled as of the end of an action. The sequence number would be used for the TaPoS fields of the deferred transaction to provide collision resistance. This method makes it virtually impossible for collisions to occur. However, it does not make it possible for a contract to determine what the transaction ID will be (it is not acceptable to add an intrinsic to access that sequence number).
The second candidate (referred to as "Required transaction extension for contract-generated transactions only") is to use the transaction extensions feature to provide the necessary bits to make each potentially-colliding deferred transaction unique. This method makes it virtually impossible for collisions to occur, and it also makes it possible for a contract to determine what the transaction ID will be.
The details of these two candidate solutions are discussed in the subsections below.
Global deferred sequence number as TaPoS field
Under this approach, a new
Required transaction extension for contract-generated transactions only
Under this approach, the expiration and TaPoS fields are all reset to zero, and uniqueness of the deferred transaction is provided through a new transaction extension with a
This means input transactions (whether delayed or not) would still not be allowed to include transaction extensions even after the consensus upgrade feature was activated (and also would never be allowed to use an extension with an type of 0).
Contract-generated transactions would be expected to have exactly one of this transaction extension with type 0 in the
The payload data for this transaction extension would include in order: the ID of the transaction in which the contract that called
This payload data provides the uniqueness needed to ensure that it is virtually impossible for the ID of contract-generated transaction to collide with any other transaction ID. A contract that sends an identical transaction with the same
Finally, it is possible for the sending contract to compute the transaction ID of the deferred transaction that will ultimately be scheduled. The contract would know that the expiration and TaPoS fields must all be 0. To calculate the payload data of the transaction extension it would need to know the
Consensus upgrade feature
The main goal of the consensus upgrade feature described in this document is to ensure that it is virtually impossible for deferred transactions to end up with a transaction ID that collides with the ID of any other transaction that is scheduled/retired in the blockchain. A secondary goal is to make this transaction ID predictable by the contract that sent the deferred transaction.
A new consensus protocol upgrade feature will be added to trigger the changes described in this consensus upgrade proposal. The actual digest for the feature understood at the blockchain level is to be determined. For the purposes of this proposal the codename
To ease the code changes and upgrade process required, this proposal avoids the first candidate solution ("Global deferred sequence number as TaPoS field"). That approach would require a replay from genesis and adds a new field to an existing index (which requires a change to the
That leaves the second candidate solution ("Required transaction extension for contract-generated transactions only") as the method used to satisfy the goals of this consensus upgrade feature.
A transaction extension with a
An input transaction (whether delayed or not) is never allowed to have an extension with a type of 0.
referenced this issue
Feb 13, 2019
Note that for deferred transactions scheduled after this feature is activated, the transaction that can be read (with
This is relevant information to any BPs considering when/if to activate this protocol feature on a live blockchain, since it is a (subtle and hopefully rare) backwards incompatibility for contracts. However, deserializing the packed transaction with the extension into an
referenced this issue
Apr 4, 2019
This protocol feature depends on the