Проблема заключается в том, что не каждый получает транзакцию.
И даже если они делают, они не могут хранить в своей памяти пула.

Имея узнав о новом блоке (что в эти дни, как правило, содержит более тысячи Txs), то, скорее всего, всегда отсутствовать некоторые из них - даже если ваш узел был онлайн в течение нескольких недель.
Вы должны каждую отдельную транзакцию, чтобы проверить новый блок, и именно поэтому протокол посылает вам все Txs вместе с каждым блоком.

Существует, очевидно, пространство для некоторой оптимизации здесь, но проблема на самом деле довольно сложно, и я думаю, именно поэтому никто не реализовал какое-либо решение для нее еще.

Просто подумайте о конкретной ситуации:
Ваш узел получает уведомление объявляя новый блок. Вы знаете, что это новый блок, но вы еще не знаете, какие транзакции внутри нее. Таким образом, вы должны спросить пира, кто знает, что блок уже в списке tx_ids внутри него - лучший сценарий, он вернется после того, как время пинг, плюс время, необходимое для передачи данных (которые часто будут превышать 100 КБ).
Теперь, имея список tx_ids уже, то есть вероятность, что вам будет не хватать некоторых передатчиках и вам нужно будет просить партнёра для них. Для этого требуется другое время звона плюс время для передачи данных обратно - и это проблема.

То, что я хочу сказать, что в этом случае вам нужно два запрос на приобретение содержания блока: первый для Txs списка, второй для передатчиков вы не знали.
Вы не можете сделать эти два параллельно - нужно proocess ответа на первый запрос, выдать вторую.

И в настоящее время требуется только один запрос: просить весь блок, со всеми операциями.

Это, очевидно, зависит от специфики подключения к партнеру (пинг против пропускной способности), но в общем-то сомнительно, что сценарий с двумя запросами даст вам все содержимое блока быстрее (так называемый блок скорости распространения). Это, скорее всего, потребуется, чтобы отправить меньше данных, но вызывает дополнительные пинг-долго задержки для дополнительного запроса.