Причина, по которой это правда, заключается в том, что вы не можете точно настроить многосетевое приложение. UX, потоки и т. д. должны быть выполнены для наименьшего общего знаменателя цепей, которые вы поддерживаете, если только у вас нет полных команд для обслуживания каждой из них. У вас тогда есть 2 результата: → Нативные развертывания могут предложить лучший UX для ~одного и того же продукта → Вы теряете добрую волю местных пользователей Существует также накладные расходы на избыточные системы и отслеживание отклонений каждой цепи (к которым вы даже не можете настроить свое приложение). "О, круто, новая функция на MegaETH на уровне протокола, чтобы сделать все приложения лучше!" → "О, ну если мы это реализуем, то это сломает стандарт и будет сложно поддерживать. Лучше остаться в безопасности." Многосетевое приложение может иметь смысл на определенном уровне успеха (Pump, Uni, AAVE и т. д.), но подавляющее большинство приложений должно просто иметь свое место и создавать лучший продукт, который они могут, где они находятся, позволяя депозиты со всех цепей (например, подход Polymarket). Очевидно, что с этим связаны прагматичные соображения, такие как финансирование команды, здоровье экосистемы и т. д., но я все равно выберу одного строителя за $8 SOL, чем 100 многосетевых приложений.