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

Implement caching within the tendermint-machine #170

Closed
kayabaNerve opened this issue Nov 29, 2022 · 1 comment
Closed

Implement caching within the tendermint-machine #170

kayabaNerve opened this issue Nov 29, 2022 · 1 comment
Labels
improvement This could be better tendermint

Comments

@kayabaNerve
Copy link
Member

Right now, every single message reruns every single code path it may effect, with no caching of context. This means every single prevote triggers a full count of all prevotes to then check if we've achieved 2/3rds. We should simply update a cached count. Then, when we've hit 2/3rds, execute the relevant code path.

To provide context, it was written like this in order to not introduce a failure point of the caching layer.

We can also delay commit signature verification until we have enough precommits under this model, enabling batch verification. If the commit signatures are invalid we'd simply create slash events and drop the messages in question.

@kayabaNerve kayabaNerve added improvement This could be better tendermint labels Nov 29, 2022
kayabaNerve added a commit that referenced this issue Mar 26, 2023
Updates to polkadot-v0.9.40, with a variety of dependency updates accordingly.
Substrate thankfully now uses k256 0.13, pathing the way for #256. We couldn't
upgrade to polkadot-v0.9.40 without this due to polkadot-v0.9.40 having
fundamental changes to syncing. While we could've updated tendermint, it's not
worth the continued development effort given its inability to work with
multiple validator sets.

Purges sc-tendermint. Keeps tendermint-machine for #163.

Closes #137, #148, #157, #171. #96 and #99 should be re-scoped/clarified. #134
and #159 also should be clarified. #169 is also no longer a priority since
we're only considering temporal deployments of tendermint. #170 also isn't
since we're looking at effectively sharded validator sets, so there should
be no singular large set needing high performance.
@kayabaNerve
Copy link
Member Author

kayabaNerve commented Mar 26, 2023

we're looking at effectively sharded validator sets, so there should be no singular large set needing high performance.

This improvement isn't worth the complexity since we don't need the performance at this time.

@kayabaNerve kayabaNerve closed this as not planned Won't fix, can't repro, duplicate, stale Mar 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
improvement This could be better tendermint
Projects
None yet
Development

No branches or pull requests

1 participant