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

fix: update the Transaction RPC type and fix response of txpool_content RPC #1234

Merged
merged 2 commits into from
Nov 2, 2023
Merged

fix: update the Transaction RPC type and fix response of txpool_content RPC #1234

merged 2 commits into from
Nov 2, 2023

Conversation

koushiro
Copy link
Collaborator

@koushiro koushiro commented Oct 27, 2023

Description

When using txpool_content RPC, I found that its return value is not compatible with geth/nethermind client,
so I try to fix it.

But when I read the implementation code of geth, I found that the transaction RPC type implemented by frontier is also different from other clients, and even different from the description in the ethereum api documentation.

Like
public_key: it's not included in the ethereum api doc, and it could be recovered from signature and raw txn
raw : it's is not included in the ethereum api doc and I think it's redundant
standard_v: it should be named y_parity or v (for compatibility) according to the ethereum api doc
creates: it's not included in the ethereum api doc, but I keep it

What I did

  • fix the response of txpool_content RPC
  • update the Transaction RPC type

Comment on lines -75 to -76
#[cfg_attr(feature = "std", serde(skip_serializing_if = "Option::is_none"))]
pub access_list: Option<Vec<AccessListItem>>,
Copy link
Collaborator Author

@koushiro koushiro Oct 27, 2023

Choose a reason for hiding this comment

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

I don't know why we used #[cfg_attr(feature = "std", ...) here before, maybe it was an error caused by copy c + v

match transaction {
TransactionV2::Legacy(t) => Transaction {
EthereumTransaction::Legacy(t) => Transaction {
transaction_type: Some(U256::from(0)),
Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'm not sure if we should use transaction_type : None for Legacy transaction

Copy link
Member

Choose a reason for hiding this comment

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

It should be 0x0.

From what I see in the RPC spec, this field is never None, so we can probably remove the Option.

@koushiro
Copy link
Collaborator Author

cc @boundless-forest @crystalin @notlesh

- fix the response of txpool_content RPC
- update the `Transaction` response type of some RPC response
@koushiro
Copy link
Collaborator Author

@sorpaas PTAL

Copy link
Member

@sorpaas sorpaas left a comment

Choose a reason for hiding this comment

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

LGTM. Grumble on transaction_type.

@koushiro koushiro requested a review from sorpaas November 1, 2023 15:18
@koushiro
Copy link
Collaborator Author

koushiro commented Nov 2, 2023

@sorpaas PTAL again

@sorpaas sorpaas merged commit 9e9c31b into polkadot-evm:master Nov 2, 2023
5 checks passed
@koushiro koushiro deleted the fix-transaction-type-and-txpool-content branch November 2, 2023 03:25
koushiro added a commit to alt-research/frontier that referenced this pull request Nov 2, 2023
…nt RPC (polkadot-evm#1234)

* fix: update the Transaction type and fix response of txpool_content RPC

- fix the response of txpool_content RPC
- update the `Transaction` response type of some RPC response

* remove Option wrapper of transaction type
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants