Are the SDK and Tendermint meant to be resilient to bugs in applications? #13525
peterbourgon
started this conversation in
General
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Tendermint is a formally verified PBFT consensus protocol which provides guarantees about consistency that are resilient to a large class of faults and malicious behavior. The protocol (and its implementation) verify all of their assumptions about third-party data and behavior. If Tendermint says block B at height H is such-and-such, then you know, formally, that this is true. It's not possible for a network partition, or a malicious peer, or a man in the middle, or a state actor, or a bug in an implementation, to affect this guarantee.
Does the SDK provide any similar guarantees? Specifically, is the SDK meant to be resilient to bugs in applications?
I'm increasingly observing code in the SDK which makes deep and complex assumptions about the data it receives from callers, or behavior it expects from applications, but doesn't actually verify that those assumptions are true. And, frequently, violations of those assumptions are catastrophic, resulting in app halts, consensus failures, etc.
One top-of-mind example: the recent SIGN_MODE_TEXTUAL proposal/PR/etc. assumes that the (application-provided) renderer is lossless and invertible. But, if it isn't, then the signatures produced by this sign mode aren't valid. Or, more fundamentally: the BasicKVStore methods don't return an error, which means they assume they will always succeed. But, if they don't — if the disk is full, or if the remote write receiver is down, or etc. — then the application crashes. Or, consider how much code assumes that encoding a protobuf results in a single, canonical, deterministic sequence of bytes — transaction hashing, and so on? But this is only true in a narrow scope; in general, protobuf encoding is nondeterministic. The Coin/Coins type is an enormous minefield of catastrophic assumptions. I could go on.
It's been my assumption that the SDK provides some level of defense against faults in its consumers. But maybe not! It could be the case that the SDK is totally transparent, in this sense, and takes on no responsibility for application bugs. If that's the case, I'd appreciate someone telling me directly, and I'll stop annoying folks on so many PRs and issues 😉
Beta Was this translation helpful? Give feedback.
All reactions