Separate block production from Tendermint #171
Labels
Comments
Closed
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.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Tendermint does designate a specific proposer and can never fully align with Substrate's separated view. What Tendermint can do is redefine the proposal from a locally built block to a hash of a (externally) proposed block. It'd reduce the scope of Tendermint, may help with #137, and may offer more functionality than previously imagined.
This doesn't solve problems with Tendermint such as #134. Even if we use BABE for production, there'd still be a single proposer for which of the proposed blocks to use. We also can't fully remove block production from Tendermint as we set the best chain to be the finalized one, not the longest one (which other libs may expose?).
This may not be worth it or may be. Tracking issue to explain it and enable consideration.
The text was updated successfully, but these errors were encountered: