-
Notifications
You must be signed in to change notification settings - Fork 266
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
Implementation of EthSwap mechanism #2276
base: master
Are you sure you want to change the base?
Conversation
65340c0
to
bc2c954
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very good job, I have a few suggestions to simplify some functions and ideas to avoid some changes that could be skipped.
Let me know your thoughts. 🙂
rskj-core/src/main/java/co/rsk/core/bc/TransactionPoolImpl.java
Outdated
Show resolved
Hide resolved
rskj-core/src/main/java/co/rsk/core/bc/TransactionPoolImpl.java
Outdated
Show resolved
Hide resolved
rskj-core/src/test/java/org/ethereum/util/EthModuleTestUtils.java
Outdated
Show resolved
Hide resolved
rskj-core/src/test/java/org/ethereum/vm/program/NestedContractsTest.java
Outdated
Show resolved
Hide resolved
pipeline:run |
rskj-core/src/integrationTest/java/co/rsk/snapshotsync/SnapshotSyncIntegrationTest.java
Outdated
Show resolved
Hide resolved
rskj-core/src/main/java/co/rsk/core/bc/ClaimTransactionInfoHolder.java
Outdated
Show resolved
Hide resolved
rskj-core/src/main/java/co/rsk/core/bc/TransactionPoolImpl.java
Outdated
Show resolved
Hide resolved
rskj-core/src/main/java/co/rsk/net/handler/TxPendingValidator.java
Outdated
Show resolved
Hide resolved
rskj-core/src/main/java/co/rsk/net/handler/txvalidator/TxValidatorStep.java
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good refactor. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added some comments, most of then related with the utility class but I'm still reviewing the PR.
rskj-core/src/main/java/co/rsk/core/bc/ClaimTransactionInfoHolder.java
Outdated
Show resolved
Hide resolved
6baeb88
to
ef3f0d4
Compare
pipeline:run |
1 similar comment
pipeline:run |
4c74307
to
8c3fc89
Compare
rskj-core/src/integrationTest/java/co/rsk/snapshotsync/SnapshotSyncIntegrationTest.java
Outdated
Show resolved
Hide resolved
420ae1c
to
bd8b9a1
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good job mate, it's a complex issue and I know you had to change it lots of time.
Congrats!
:)
rskj-core/src/test/java/co/rsk/util/ClaimTransactionValidatorTest.java
Outdated
Show resolved
Hide resolved
Quality Gate passedIssues Measures |
logger.warn("block: [{}] discarded claim tx: [{}], because the funds it tries to claim no longer exist in contract", | ||
block.getNumber(), | ||
tx.getHash()); | ||
continue; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
may cause an issue if just skipped. should be analyzed in more detail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I used this approach is that it aligns with the existing logic in the BlockExecutor
. Just like how invalid transactions are managed there, invalid Claim
transactions are discarded if discardInvalidTxs
is set to true. If not, the execution is stopped
For General Transactions, the handling is similar:
if (!acceptInvalidTransactions && !transactionExecuted) {
if (discardInvalidTxs) {
logger.warn("block: [{}] discarded tx: [{}]", block.getNumber(), tx.getHash());
continue;
} else {
logger.warn("block: [{}] execution interrupted because of invalid tx: [{}]",
block.getNumber(), tx.getHash());
profiler.stop(metric);
return BlockResult.INTERRUPTED_EXECUTION_BLOCK_RESULT;
}
}
Just as we discard invalid general transactions, we also discard invalid Claim transactions based on specific validation criteria. This ensures we maintain consistency in handling invalid transactions across the code
Let me know if you have any further questions!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But Claim
transactions that don't have locked funds !claimTransactionValidator.hasLockedFunds(tx, track))
would be just discarded without interrupting the execution regardless of discardInvalidTxs
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, invalid claim transactions (those without locked funds) are indeed discarded without interrupting block execution, regardless of the discardInvalidTxs
value. This behavior is intentional and aligned with the design outlined in the TDD and Sergio's proposal
The logic was implemented to ensure that claim transactions, which don't meet the requirement of having locked funds, are simply discarded to prevent them from affecting the overall block processing. This ensures that the chain execution continues smoothly without being interrupted by these invalid claim transactions. The proposal specifies that invalid claims should not stop the block execution but rather be skipped to maintain stability and performance. You can find the detailed reasoning behind this in the initial Sergio's proposal document here
Happy to explain further if needed!
5bb1765
to
f56c49d
Compare
f56c49d
to
99712db
Compare
Quality Gate passedIssues Measures |
Description
This pull request is not intended to be merged, its purpose is to review the proof of contect of the EthSwap mechanism.
Motivation and Context
How Has This Been Tested?
Types of changes
Checklist: