The question is testing your failure model, not your vocabulary. A distributed transaction is atomic commit across participants that each own an independent transaction log — bank A and bank B, two shards, an order service and an inventory service. Atomicity means all commit or all abort. 2PC is the classic protocol for that, and its problems are not performance — they're structural.
The protocol: a coordinator asks every participant to prepare — do the work, hold locks, fsync a prepared record, but don't release anything. Participants vote commit or abort. If all vote commit, the coordinator logs its decision and tells everyone to commit; otherwise it tells everyone to abort.
The blocking problem is the center of the answer. Once a participant has voted yes, it cannot unilaterally decide anything: it must commit if told to, and it can't commit without being told. If the coordinator crashes after prepare but before the decision reaches everyone, participants sit in doubt — locks held, resources pinned, unable to proceed — until a new coordinator reads the decision log and completes the protocol. If the coordinator crashed before logging a decision, the participants are stuck forever unless they break atomicity by guessing. The protocol's correctness literally depends on the coordinator never losing its log. That's the exchange 2PC makes: atomicity in exchange for blocking.
Secondary costs worth naming: the coordinator is a single point of failure; locks are held across the entire multi-round-trip duration, so two 2PC transactions touching overlapping rows serialize and contention goes up with every round trip added; one slow participant makes everyone wait; and aborts cascade — a single no aborts work already done elsewhere.
What you'd say instead: sagas, where each step commits locally and a compensating action undoes it — no locks, no blocking, but no isolation either; outbox tables that make the message and the business write one atomic local transaction; or Spanner-style TrueTime commit, which orders transactions by timestamp intervals instead of waiting for a coordinator. And the deepest answer: the best distributed transaction is the one you don't run — partition your data so the transaction touches a single node, and keep atomic commit where it belongs.