Почему TPS перестал быть главным показателем масштабируемости блокчейна

Повод собрал вокруг себя более прикладные сюжеты: ребрендинг Texas Blockchain Council в digital infrastructure network, интерес Midwest-цепочек поставок к блокчейн-рельсам и сингапурскую встречу AI и блокчейн-команд под флагом digital finance.

Почему TPS — это плоский слайд

TPS как метрика измеряет простую вещь: сколько транзакций сеть переваривает за секунду. Проблема в том, что без контекста это число не сообщает ничего полезного. Анализ исходного кода и наблюдение за поведением нод под нагрузкой показывают: за одним и тем же TPS-значением скрывается и сеть с настоящей финальностью, и L2, агрегирующий пачку свопов в один роллап.

Архитектура консенсуса, размер блока и время до финальности — это три переменные, которые определяют, реальная перед вами инфраструктура или иллюзия пропускной способности. Удвоение TPS за счёт увеличения размера блока в два раза — это не масштабирование, это сдвиг оверхеда на уровень верификации. Удвоение TPS за счёт сайдчейна — это сдвиг оверхеда на доверие к оператору моста.

Что показывает инфраструктурный сдвиг

Параллельная ветка новостей рисует один и тот же паттерн. Texas Blockchain Council, по данным EIN News, переупаковывает себя как digital infrastructure network, пытаясь привязать блокчейн-повестку к энергетике и физическим дата-центрам. По данным fdlreporter.com, американские Midwest-цепочки поставок смотрят на блокчейн-рельсы через трекинг и сеттинг, а не через токеномику. По данным CoinTrust, Сингапур свёл AI и блокчейн-команды под вывеской digital finance — формально финансы, по сути — стек инфраструктурных сервисов.

Географии разные, вертикали разные, но градиент общий: блокчейн съезжает из плоскости «крипто» в плоскость «инфраструктура». В этой плоскости TPS — только входной фильтр, а не итоговая оценка.

Что прогнать на практике

Прежде чем доверять чужому TPS-замеру, прогоняйте три вещи в реальном логе. Смотрите time-to-finality под нагрузкой, а не пиковое значение на бенчмарке от самой команды. Проверяйте, что в счётчик TPS не подмешаны роллапы, сайдчейны или outbox-транзакции без атрибуции. Считайте оверхед на валидацию на одну полезную транзакцию, а не на пакетное перекладывание zk-SNARK-доказательств.

Полезный sanity-check: возьмите заявленный TPS, разделите на количество активных валидаторов и посмотрите на пропускную способность одной ноды. Если число не бьётся с реальной нагрузкой на железо — значит, в замере спрятан слой абстракции, и это нужно явно атрибутировать.

Вердикт короткий: TPS — это слэш-метрика, полезная как индикатор проблемы, но не как её решение. Решение — это архитектура консенсуса, оверхед на верификацию и поведение ноды под нагрузкой. Всё остальное — это булшит из питчдека.