I suppose you mean that someone (out of a group G) can commit an instruction saying "the future decision is Y" into the blockchain, and at some time later everyone will be convinced this is the future decision. This is not related to PoS, this will work for pretty much any system that supports smart contracts.

In this situation the decision is not executed in a shared manner - even if one of G gets disconnected from the network, the decision still gets executed by the blockchain. So it is still different from the Two Generals Problem (as stated), where everyone in the group G must participate in executing the decision.

So blockchains still don't solve the Two General Problem. Nor should this be a goal. I think the Two Generals Problem is stupidly strong and really unnecessary in the vast majority of real computing scenarios, including the blockchain.

> Interesting - do you mind providing an exemplary paper or two? I'd like to read them.

It's basically all of them, and I don't think many are worth reading so I don't remember the titles. Search for papers that try to solve the Sybil or Eclipse attacks. (Quite a lot of them rely on trusted authorities, these are not relevant here, I mean the other ones.)

No, I specifically mean a voting protocol in which the "round" will not proceed ("the generals will not attack") unless all voters v in the voting set V come to consensus about the values t in the set of transactions T at the next block height ("the city to be attacked", "the time to attack", etc). Then the voting protocol asserts a proof of stake, such that Byzantine voters are penalized and honest/correct voters are rewarded. Then future decision resolution is provably guaranteed, so long as all activity remains deterministic, the cryptography is secure, all voters in the set V are online and active, and proof of stake is a plausible economic incentive.

The caveat here is - pretty obviously - that it's possible for the consensus system to enter an infinite loop if it fails to reach consensus (just like the original problem). So no, it's not perfect, but it is modeling the Two Generals Problem and compartmentalizing it somewhat, though it can't completely resolve it.

Otherwise, I agree with you - the classical Two Generals problem is an inordinate fault-tolerance ideal.

How do you decide which one is a "Byzantine" voter? A minority is not necessarily dishonest. If you penalise a minority, at each step at most ceil(n/2-1) of the group will lose their stake, even if they were honest. That sounds overly-harsh.

In the original paper by Lamport, Shostak, and Pease, the problem is described this way: "We imagine that several divisions of the Byzantine army are camped outside an enemy city, each division commanded by its own general. The generals can communicate with one another only by messenger. After observing the enemy, they must decide upon a common plan of action. However, some of the generals may be traitors, trying to prevent the loyal generals from reaching agreement."

A common way to describe the participants in such a scenario is simply "honest" and "dishonest". The term "Byzantine" has become used in distributed systems research to refer to situations in which we can't be sure of participants' honesty and intentions. However, it doesn't correctly refer only to the dishonest participants.

Lamport's original paper does seem to treat adversaries appropriately, but I've seen many worse papers from recently failing to consider what happens if a malicious peer specifically tries to exploit your "defence" mechanism.

I wouldn't say this is a problem. It's a useful red flag that you should stop reading this paper, or at the very least question the competency of the authors. Could save hours of your life!

The whole point is that I can't tell if it's a red flag simply by reading the abstract, I have to read the entire paper. The good papers also use the same vague terminology!