Questions about Counterparty consensus and validation

I’m having difficulty conceptualizing how counter party prevents or handles bad transactions.  Bitcoin has a couple of notable features that help.  Full nodes wont propagate bad transactions.  Miners reject bad transactions.  Nodes check blocks for validity before they accept them from miners. 

Counterparty however doesn’t seem to have those same safeguards.  Bitcoin nodes and miners don’t check the validity of counter party transactions before propagating transactions or publishing blocks.

What prevents different counterparty nodes from interpreting counterparty transactions differently?

How does counterparty efficiently sort through bad transaction bloat that has been published to a block?

What is stopping users or organizations that have high volumes of transactions from adding bogus xcp transaction information in their new btc transactions in order to disrupt counterparty?

If counterparty forks happen, how will they be distinguished since they are both on top of bitcoin?

The Counterparty protocol is encoded fully in the counterpartyd project and as long as two nodes are running the same software which the build process verifies down to exact versions of libraries, then they should be in agreement. That being said, one might wish for a protocol to have multiple implementations and I can’t really see that being viable unless they use the same core ruleset. In Bitcoin you have the miners and users to figure out which version of reality is correct, with Counterparty you just really have the users. What Bitcoin does do is take out any chance for dispute over the sequence of events.

I think it would be good for there to be a hash that can be compared between instances to quickly verify that their state is 100% exactly the same.

If a transaction is invalid, it gets skipped, simple as that. Trying to add bogus transactions should fail or else somebody found a bug in the validation code.

A fork would have to be defined as a disagreement between two nodes and the difference would be seen by some transactions existing on one node vs. another or that balances or owners disagreed. Again some sort of state hash would help because then third parties could query each node that provides a service ( and for example) to make sure they are in agreement.

Ultimately consensus is a social phenomenon. No two people agree on everything so if there were a fork, the community would likely need to discuss it and each make their own choice on which branch to follow.