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

Jump to bottom

Post-fork transaction validation #879

Merged
merged 4 commits into from Apr 15, 2019
Merged

Post-fork transaction validation #879

merged 4 commits into from Apr 15, 2019

Conversation

AlexandraRoatis
Copy link
Contributor

Description

  • Set the AVM_CREATE_CODE = 0x02;
  • Allowing only transactions with types 0, 1, 2 after the fork;
  • Unit tests for transaction validation before and after the fork.

Type of change

Insert x into the following checkboxes to confirm (eg. [x]):

  • Bug fix.
  • New feature.
  • Enhancement.
  • Unit test.
  • Breaking change (a fix or feature that causes existing functionality to not work as expected).
  • Requires documentation update.

Testing

Please describe the tests you used to validate this pull request. Provide any relevant details for test configurations as well as any instructions to reproduce these results.

  • existing tests
  • two new tests to verify correct transaction validation after the fork

Verification

Insert x into the following checkboxes to confirm (eg. [x]):

  • I have self-reviewed my own code and conformed to the style guidelines of this project.
  • New and existing tests pass locally with my changes.
  • I have added tests for my fix or feature.
  • I have made appropriate changes to the corresponding documentation.
  • My code generates no new warnings.
  • Any dependent changes have been made.

@AlexandraRoatis AlexandraRoatis added the wip Indicates that a PR or issue is Work In Progress, issuer should be notified before any actions label Apr 15, 2019
@AlexandraRoatis AlexandraRoatis added enhancement New feature or request unit tests and removed wip Indicates that a PR or issue is Work In Progress, issuer should be notified before any actions labels Apr 15, 2019
@AlexandraRoatis AlexandraRoatis self-assigned this Apr 15, 2019
@AlexandraRoatis AlexandraRoatis added this to the 0.4.0 milestone Apr 15, 2019
AionJayT
AionJayT reviewed Apr 15, 2019
View reviewed changes
modAionImpl/src/org/aion/zero/impl/blockchain/AionPendingStateImpl.java
@@ -441,7 +441,7 @@ public synchronized TxResponse addPendingTransaction(AionTransaction tx) {
}

public boolean isValid(AionTransaction tx) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

this method can be a static method?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It cannot be changed to static because of the interface for the pending state.

Copy link
Collaborator

Choose a reason for hiding this comment

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

okay.

AionJayT
AionJayT reviewed Apr 15, 2019
View reviewed changes
modMcf/src/org/aion/mcf/types/AbstractTransaction.java
this.type = TransactionTypes.DEFAULT;
// setting the default type depending on use case
if (to == null) {
this.type = TransactionTypes.FVM_CREATE_CODE;
Copy link
Collaborator

Choose a reason for hiding this comment

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

How does the AVM contract create definition?
I thought the AVM contract create address destination is null too

Copy link
Contributor Author

Choose a reason for hiding this comment

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

For AVM contracts the default transaction type value is incorrect. However, our unit tests have already been written to specify the deploy code and not use the default value when testing the AVM contract deployments. This change is mainly for the sake of the old FVM tests that were written without taking the transaction type into account.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I would prefer fully removing the constructor that allows building transactions without specifying the type, but that would be a low priority refactoring that can be applied later.

Copy link
Collaborator

@AionJayT AionJayT Apr 15, 2019 •
edited

Choose a reason for hiding this comment

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

thanks for the explanation.

AionJayT
AionJayT reviewed Apr 15, 2019
View reviewed changes
Copy link
Collaborator

@AionJayT AionJayT left a comment

Choose a reason for hiding this comment

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

left 2 comments might need to change it.

@AlexandraRoatis
distinct transaction type validation for contract deployments and oth…
1b240a9 
…er transactions

 - updated the default setting to differ depending on the use case
 - corrected the type setting in unit tests
@AlexandraRoatis AlexandraRoatis merged commit 2e4bcf7 into master-pre-merge Apr 15, 2019
@AlexandraRoatis AlexandraRoatis deleted the avm-create-code branch April 16, 2019 20:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@AionJayT AionJayT AionJayT approved these changes

Assignees

@AlexandraRoatis AlexandraRoatis

Labels
enhancement New feature or request unit tests
Projects
None yet
Milestone
0.4.0
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@AlexandraRoatis @AionJayT