CAP: 0017 Title: Update LastModifiedLedgerSeq If and Only If LedgerEntry is Modified Author: Jonathan Jove Status: Accepted Created: 2019-02-01 Discussion: https://groups.google.com/forum/#!topic/stellar-dev/hzemjh1aIwc Protocol version: TBD
This proposal makes specifying and implementing the protocol easier by simplifying the semantics of
It is currently possible for
LedgerEntry.lastModifiedLedgerSeq to be updated by an operation even
if that operation did not make any modifications to the underlying data of that
document proposes changing the semantics of
lastModifiedLedgerSeq to be updated by an operation
if and only if the underlying data of that
LedgerEntry has changed.
The main benefit of this proposal is that implementing the protocol would be simpler. The current
behavior forces implementers to carefully manage whether
lastModifiedLedgerSeq should or should
not be updated in any given circumstance. The only reliable way for an implementer to determine
lastModifiedLedgerSeq should be updated in the current protocol version is by referring to
an existing implementation. This proposal would unambiguously specify when
should and should not be updated.
For example, using
AllowTrust to authorize a trustline that is already authorized will update the
lastModifiedLedgerSeq of the trustline without making any other modifications. In contrast, a
tentative winner of
Inflation that ends up winning nothing (due to, for example, having excessive
native asset liabilities) is unchanged and does not receive an updated
The value of
lastModifiedLedgerSeq should be updated by an operation if and only if the net
effect of that operation includes updating the underlying data of a
LedgerEntry. Specifically, if
leAfter are the
lastModifiedLedgerSeq) before and after
the operation has been applied, respectively, then
lastModifiedLedgerSeq should be updated to
LedgerHeader.ledgerSeq if and only if
leBefore != leAfter.
This proposal is to be applied at the operation level as it guarantees that if the net effect of
any operation in a transaction set includes updating the underlying data of a
the value of
lastModifiedLedgerSeq will be updated. This behavior is desirable from an
implementation perspective because it allows each operation to correctly determine whether
lastModifiedLedgerSeq should be updated without any knowledge of whether the
been or will be modified by other operations in the same transaction set.
Downstream systems which rely on
lastModifiedLedgerSeq could be effected as the semantics of that
field will change.
No implementation yet.