Мой сосед водит доставку для приложения и клянётся, что вся работа сводится к тому, чтобы вы просто вовремя отметились. Я однажды спросил его, проверяет ли кто‑нибудь, что он доставил правильный заказ к правильной двери, и он рассмеялся и сказал, что никто этого не делает: системе важно только, чтобы приложение отметило доставку. Это различие между тем, чтобы доказать, что событие произошло, и тем, чтобы доказать, что оно произошло правильно, осталось со мной дольше, чем сам разговор.
Сети хранилищ вроде Gelato, Keep3r и Chainlink Automation существуют, чтобы запускать заранее определённое действие, когда выполнено условие: ребалансировать пул, ликвидировать позицию, исполнить лимитный ордер. Они действительно хорошо делают свою работу. Но ни одна из них не доказывает, что лежавшее в основе решения срабатывания триггера само по себе было корректным: они подтверждают, что функция отработала, а не то, что запуск был правильным решением с учётом всего остального, что происходило в ончейне в тот момент. Операторская сеть Newton, напротив, подкрепляет каждое решение allow, reject или cap проверяемым доказательством — и это уже совсем другой вопрос, не связанный напрямую с тем, сработало ли действие по расписанию.
Вся презентация Keep3r всегда сводилась к оплате кэперам за газоэффективное, надёжное выполнение: там важны скорость и стоимость, а не оценка. Операторская сеть Newton, напротив, должна собрать кворум и выдать доказательство прежде, чем вердикт вообще начнёт считаться — это намеренно медленнее и стоит соответственно.
Так они конкурируют? Только отчасти. Хранилище может использовать сеть кэпера, чтобы выполнить ребаланс, и при этом использовать Newton, чтобы решить, вообще стоит ли разрешать этот ребаланс. И ни одна из них не заменяет работу другой. Вопрос лишь в том, насколько это различие важно для разработчика, выбирающего инфраструктуру сегодня, — или становится заметным только тогда, когда что-то пошло не так и кто‑то спрашивает, почему технически успешная транзакция оказалась неправильной. Реальное применение Newton пока ещё не дало этому однозначного ответа. Я склоняюсь к мысли, что это важнее в тот момент, когда на кону реальные деньги, но это предположение, а не установленный факт.
@NewtonProtocol $NEWT #Newt $LAB $EVAA
Сети хранилищ вроде Gelato, Keep3r и Chainlink Automation существуют, чтобы запускать заранее определённое действие, когда выполнено условие: ребалансировать пул, ликвидировать позицию, исполнить лимитный ордер. Они действительно хорошо делают свою работу. Но ни одна из них не доказывает, что лежавшее в основе решения срабатывания триггера само по себе было корректным: они подтверждают, что функция отработала, а не то, что запуск был правильным решением с учётом всего остального, что происходило в ончейне в тот момент. Операторская сеть Newton, напротив, подкрепляет каждое решение allow, reject или cap проверяемым доказательством — и это уже совсем другой вопрос, не связанный напрямую с тем, сработало ли действие по расписанию.
Вся презентация Keep3r всегда сводилась к оплате кэперам за газоэффективное, надёжное выполнение: там важны скорость и стоимость, а не оценка. Операторская сеть Newton, напротив, должна собрать кворум и выдать доказательство прежде, чем вердикт вообще начнёт считаться — это намеренно медленнее и стоит соответственно.
Так они конкурируют? Только отчасти. Хранилище может использовать сеть кэпера, чтобы выполнить ребаланс, и при этом использовать Newton, чтобы решить, вообще стоит ли разрешать этот ребаланс. И ни одна из них не заменяет работу другой. Вопрос лишь в том, насколько это различие важно для разработчика, выбирающего инфраструктуру сегодня, — или становится заметным только тогда, когда что-то пошло не так и кто‑то спрашивает, почему технически успешная транзакция оказалась неправильной. Реальное применение Newton пока ещё не дало этому однозначного ответа. Я склоняюсь к мысли, что это важнее в тот момент, когда на кону реальные деньги, но это предположение, а не установленный факт.
@NewtonProtocol $NEWT #Newt $LAB $EVAA