once a shadow fork starts to create new blocks, those blocks shouldn't be gossipped outside of the shadow network. Same applies to transactions as well, txns that are signed with the intent of only using them in the shadow fork should not leak to the actual network.
2. PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:
[ ] build: Changes that affect the build system or external dependencies (example scopes: yarn, eslint, typescript)
[ ] ci: Changes to our CI configuration files and scripts (example scopes: vercel, github, cypress)
[ ] docs: Documentation-only changes
[ ] feat: A new feature
[ ] fix: A bug fix
[ ] perf: A code change that improves performance
[ ] refactor: A code change that doesn't fix a bug, or add a feature, or improves performance
[ ] style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
[ ] test: Adding missing tests or correcting existing tests
3. Deployment tag versioning
Has the version in params/version.go been updated?
[ ] This PR doesn't involve a new deployment, git tag, docker image tag, and it doesn't affect traces
omerfirmak
commented
2 months ago
1. Purpose or design rationale of this PR
once a shadow fork starts to create new blocks, those blocks shouldn't be gossipped outside of the shadow network. Same applies to transactions as well, txns that are signed with the intent of only using them in the shadow fork should not leak to the actual network.
2. PR title
Your PR title must follow conventional commits (as we are doing squash merge for each PR), so it must start with one of the following types:
3. Deployment tag versioning
Has the version in
params/version.gobeen updated?4. Breaking change label
Does this PR have the
breaking-changelabel?