Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixInnerObjTemplate: Add STObject constructor to explicitly set inner object template #4906

Merged
merged 12 commits into from
Feb 7, 2024

Conversation

gregtatcam
Copy link
Collaborator

@gregtatcam gregtatcam commented Jan 29, 2024

High Level Overview of Change

Add an STObject constructor overload that includes an additional bool argument to set the inner object template. Set the argument to true if the constructed object is an inner object and if the fixInnerObjTemplate amendment is enabled.

Context of Change

Currently, the inner object template is not set upon object creation. If the object contains an soeDEFAULT field, and this field is initially set to the default value, accessing the field results in tefEXCEPTION error. Conversely, if the top object's soeDEFAULT field, initially set to the default value, is accessed, it returns the default value since top objects have the template set during construction. This fix aims to make the inner object behavior consistent with the top object behavior. The inner object must be explicitly constructed, as described in the summary, for this fix to work.

Currently, two AMM fields, sfTradingFee and sfDiscountedFee, included in the inner objects sfVoteEntry and sfAuctionSlot respectively, are declared as soeDEFAULT fields. This fix employs the new STObject constructor when constructing inner objects that include these fields.

Type of Change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • Refactor (non-breaking change that only restructures code)
  • Performance (increase or change in throughput and/or latency)
  • Tests (you added tests for code that already exists, or your new feature included in this PR)
  • Documentation update
  • Chore (no impact to binary, e.g. .gitignore, formatting, dropping support for older tooling)
  • Release

Test Plan

AMM unit-test is extended with a test, which demonstrates the behavior before and after this fix.

@codecov-commenter
Copy link

codecov-commenter commented Jan 30, 2024

Codecov Report

Attention: 10 lines in your changes are missing coverage. Please review.

Comparison is base (6d3c21e) 61.50% compared to head (f2677a3) 61.47%.

Files Patch % Lines
src/ripple/app/tx/impl/AMMBid.cpp 14.28% 3 Missing and 3 partials ⚠️
src/ripple/app/misc/impl/AMMUtils.cpp 88.88% 0 Missing and 1 partial ⚠️
src/ripple/app/tx/impl/AMMVote.cpp 75.00% 0 Missing and 1 partial ⚠️
src/ripple/protocol/impl/STObject.cpp 92.30% 0 Missing and 1 partial ⚠️
src/ripple/rpc/handlers/AMMInfo.cpp 0.00% 0 Missing and 1 partial ⚠️
Additional details and impacted files
@@             Coverage Diff             @@
##           develop    #4906      +/-   ##
===========================================
- Coverage    61.50%   61.47%   -0.04%     
===========================================
  Files          797      797              
  Lines        70132    70156      +24     
  Branches     36245    36261      +16     
===========================================
- Hits         43137    43127      -10     
- Misses       19756    19786      +30     
- Partials      7239     7243       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

@intelliot intelliot added Bug Amendment Perf impact not expected Change is not expected to improve nor harm performance. labels Jan 30, 2024
@intelliot intelliot added this to the 2.1.0 (Mar 2024) milestone Feb 1, 2024
@gregtatcam gregtatcam mentioned this pull request Feb 1, 2024
12 tasks
src/ripple/app/misc/impl/AMMUtils.cpp Outdated Show resolved Hide resolved
src/ripple/protocol/impl/STObject.cpp Outdated Show resolved Hide resolved
src/ripple/protocol/impl/STObject.cpp Show resolved Hide resolved
src/ripple/protocol/SOTemplate.h Show resolved Hide resolved
* Add comment to InnerObjectFormats
* Use if initializer in makeInnerObject()
* Add assert to STObject::set()
Copy link
Collaborator

@ximinez ximinez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. One optional comment to consider.

src/ripple/app/misc/impl/AMMUtils.cpp Outdated Show resolved Hide resolved
@danielwwf
Copy link

danielwwf commented Feb 3, 2024

After talking with some people, we would like to see a 2.0.2 for this fix that gets pushed ASAP. Waiting for 2.1.0 seems too long IMHO.

Departing AMM and putting up an AMMv2 seems the best way forward to avoid another XLS20d situation.

* Create AuctionSlot on AMMCreate and update on AMMDeposit
* Add assert to check for AuctionSlot
@gregtatcam
Copy link
Collaborator Author

Looks good. One optional comment to consider.

There is another update. Please re-review. Thanks.

src/ripple/app/misc/impl/AMMUtils.cpp Outdated Show resolved Hide resolved
src/ripple/app/misc/impl/AMMUtils.cpp Outdated Show resolved Hide resolved
src/ripple/app/tx/impl/AMMBid.cpp Outdated Show resolved Hide resolved
src/ripple/app/tx/impl/AMMBid.cpp Outdated Show resolved Hide resolved
src/ripple/app/tx/impl/AMMVote.cpp Outdated Show resolved Hide resolved
src/ripple/protocol/impl/STObject.cpp Outdated Show resolved Hide resolved
src/ripple/rpc/handlers/AMMInfo.cpp Outdated Show resolved Hide resolved
* Remove comments
* Refactor amendment changed code
* Change STObject::set() arg to rvalue ref
Copy link
Collaborator

@seelabs seelabs left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@dangell7
Copy link
Collaborator

dangell7 commented Feb 7, 2024

Why don't we just make these fields soeOPTIONAL? Whats the purpose of these being soeDEFAULT?

Also you stated If the object contains an soeDEFAULT field, and this field is initially set to the default value, accessing the field results in tefEXCEPTION error.

Isn't this exactly what default behavior is supposed to be? soeDEFAULT // optional, if present, must not have default value

Thanks

@gregtatcam
Copy link
Collaborator Author

Why don't we just make these fields soeOPTIONAL? Whats the purpose of these being soeDEFAULT?

Also you stated If the object contains an soeDEFAULT field, and this field is initially set to the default value, accessing the field results in tefEXCEPTION error.

Isn't this exactly what default behavior is supposed to be? soeDEFAULT // optional, if present, must not have default value

Thanks

Changing the field's style is risky and it's a lot more code changes.

soeDEFAULT field saves space. If it has the default value then it should not be present. But if it is accessed then it should return the default value if it's not present.

@dangell7
Copy link
Collaborator

dangell7 commented Feb 7, 2024

Why don't we just make these fields soeOPTIONAL? Whats the purpose of these being soeDEFAULT?
Also you stated If the object contains an soeDEFAULT field, and this field is initially set to the default value, accessing the field results in tefEXCEPTION error.
Isn't this exactly what default behavior is supposed to be? soeDEFAULT // optional, if present, must not have default value
Thanks

Changing the field's style is risky and it's a lot more code changes.

soeDEFAULT field saves space. If it has the default value then it should not be present. But if it is accessed then it should return the default value if it's not present.

Ah I see thank you

src/ripple/app/misc/impl/AMMUtils.cpp Outdated Show resolved Hide resolved
src/test/jtx/impl/AMM.cpp Show resolved Hide resolved
src/test/jtx/impl/AMM.cpp Outdated Show resolved Hide resolved
* Refactor auction slot amendment creation on initialize
* Update a comment in amm test utils
@intelliot
Copy link
Collaborator

Suggested commit message:

`fixInnerObjTemplate`: set inner object template (#4906)

Add `STObject` constructor to explicitly set the inner object template.
This allows certain AMM transactions to apply in the same ledger:

There is no issue if the trading fee is greater than or equal to 0.01%.
If the trading fee is less than 0.01%, then:
- After AMM create, AMM transactions must wait for one ledger to close
  (3-5 seconds).
- After one ledger is validated, all AMM transactions succeed, as
  appropriate, except for AMMVote.
- The first AMMVote which votes for a 0 trading fee in a ledger will
  succeed. Subsequent AMMVote transactions which vote for a 0 trading
  fee will wait for the next ledger (3-5 seconds). This behavior repeats
  for each ledger.

This has no effect on the ultimate correctness of AMM. This amendment
will allow the transactions described above to succeed as expected, even
if the trading fee is 0 and the transactions are applied within one
ledger (block).

@intelliot intelliot merged commit be12136 into XRPLF:develop Feb 7, 2024
17 checks passed
@gregtatcam gregtatcam mentioned this pull request Feb 7, 2024
1 task
@intelliot intelliot changed the title Add STObject constructor to explicitly set inner object template fixInnerObjTemplate: Add STObject constructor to explicitly set inner object template Feb 8, 2024
@intelliot
Copy link
Collaborator

sophiax851 pushed a commit to sophiax851/rippled that referenced this pull request Jun 12, 2024
Add `STObject` constructor to explicitly set the inner object template.
This allows certain AMM transactions to apply in the same ledger:

There is no issue if the trading fee is greater than or equal to 0.01%.
If the trading fee is less than 0.01%, then:
- After AMM create, AMM transactions must wait for one ledger to close
  (3-5 seconds).
- After one ledger is validated, all AMM transactions succeed, as
  appropriate, except for AMMVote.
- The first AMMVote which votes for a 0 trading fee in a ledger will
  succeed. Subsequent AMMVote transactions which vote for a 0 trading
  fee will wait for the next ledger (3-5 seconds). This behavior repeats
  for each ledger.

This has no effect on the ultimate correctness of AMM. This amendment
will allow the transactions described above to succeed as expected, even
if the trading fee is 0 and the transactions are applied within one
ledger (block).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Amendment Bug Perf impact not expected Change is not expected to improve nor harm performance. Testable
Projects
Status: 🚢 Released in 2.2.0
Development

Successfully merging this pull request may close these issues.

8 participants