You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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.
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: