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

core,eth,internal/cli,internal/ethapi: add --rpc.allow-unprotected-txs flag to allow txs to get replayed (for shadow node) #705

Merged
merged 4 commits into from
Mar 16, 2023

Conversation

Raneet10
Copy link
Member

Description

This PR introduces rpc.allow-unprotected-txs flag to facilitate replaying of transactions from a different network to a shadow node (i.e a node producing blocks in isolation with the state of the network from which transactions are being relayed).

Changes

  • Bugfix (non-breaking change that solves an issue)
  • Hotfix (change that solves an urgent issue, and requires immediate attention)
  • New feature (non-breaking change that adds functionality)
  • Breaking change (change that is not backwards-compatible and/or changes current functionality)
  • Changes only for a subset of nodes

Nodes audience

Currently, this flag is only meant to be enabled if we are running a shadow node.

Checklist

  • I have added at least 2 reviewer or the whole pos-v1 team
  • I have added sufficient documentation in code
  • I will be resolving comments - if any - by pushing each fix in a separate commit and linking the commit hash in the comment reply

Testing

  • I have added unit tests
  • I have added tests to CI
  • I have tested this code manually on local environment
  • I have tested this code manually on remote devnet using express-cli
  • I have tested this code manually on mumbai
  • I have created new e2e tests into express-cli

@Raneet10 Raneet10 requested a review from a team January 27, 2023 12:20
@codecov
Copy link

codecov bot commented Jan 27, 2023

Codecov Report

Base: 56.55% // Head: 56.49% // Decreases project coverage by -0.06% ⚠️

Coverage data is based on head (4917fde) compared to base (d6899d7).
Patch coverage: 50.00% of modified lines in pull request are covered.

Additional details and impacted files
@@             Coverage Diff             @@
##           develop     #705      +/-   ##
===========================================
- Coverage    56.55%   56.49%   -0.06%     
===========================================
  Files          610      610              
  Lines        71129    71289     +160     
===========================================
+ Hits         40230    40278      +48     
- Misses       27443    27533      +90     
- Partials      3456     3478      +22     
Impacted Files Coverage Δ
consensus/bor/bor.go 7.53% <0.00%> (-0.12%) ⬇️
core/types/transaction_signing.go 67.23% <0.00%> (-2.37%) ⬇️
eth/backend.go 0.00% <0.00%> (ø)
core/tx_pool.go 76.97% <14.28%> (-0.44%) ⬇️
consensus/bor/valset/validator_set.go 49.62% <100.00%> (ø)
internal/cli/server/config.go 68.45% <100.00%> (+0.32%) ⬆️
internal/cli/server/flags.go 100.00% <100.00%> (ø)
miner/fake_miner.go 89.61% <100.00%> (ø)
core/state_prefetcher.go 85.18% <0.00%> (-7.41%) ⬇️
log/root.go 4.34% <0.00%> (-4.75%) ⬇️
... and 35 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

@pgebheim
Copy link

pgebheim commented Feb 8, 2023

This patch is also useful for testing 4337 so that deterministic deployer contracts can be deployed at the correct address for testing.

cc: @pratikspatil024

@Raneet10
Copy link
Member Author

Raneet10 commented Feb 9, 2023

This patch is also useful for testing 4337 so that deterministic deployer contracts can be deployed at the correct address for testing.

cc: @pratikspatil024

I'm afraid I don't have much context. But perhaps you could enlighten me on this :)

@Raneet10 Raneet10 marked this pull request as ready for review February 15, 2023 15:01
Copy link
Member

@pratikspatil024 pratikspatil024 left a comment

Choose a reason for hiding this comment

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

Please update all the TOML config files.

@Raneet10
Copy link
Member Author

Done: 4917fde

@temaniarpit27 temaniarpit27 requested a review from a team February 16, 2023 06:53
@github-actions
Copy link

This PR is stale because it has been open 21 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the Stale label Mar 10, 2023
@Raneet10 Raneet10 removed the Stale label Mar 14, 2023
@Raneet10 Raneet10 merged commit c917e6f into develop Mar 16, 2023
@kaber2
Copy link

kaber2 commented Jul 19, 2023

Just noticed this gem while merging the latest changes. Does anyone actually review these patches?

`
// Exclude transactions with invalid signatures as soon as
// possible and cache senders in transactions before
// obtaining lock

if pool.config.AllowUnprotectedTxs {
pool.signer = types.NewFakeSigner(tx.ChainId())
`

Why the hell is this changing global pool configuration inside the transaction add path?

@Raneet10
Copy link
Member Author

Hey @kaber2 , firstly let's please try to watch our tone in these conversations; we're all trying to collaborate here. Secondly, the signer change happens only when AllowUnprotectedTxs is set to true (mostly when you're running a shadow forked node) and we override the signer with the chain ID of the network from which the transaction is coming (instead of the local network's) since we're allowing transactions from a different network to be replayed. We can maybe make this change on an upper level of the call stack, which would be logically sound though my initial assumption was that this might result in some repetitive code. Of course, open to your mild thoughts as to where this condition should be placed!

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.

7 participants