Проверяемость — это самое важное преимущество криптовалюты.
Биткойн и Эфириум предоставили нам проверяемые деньги и финансы. Следующий шаг, связанный с проверяемостью, отличается от двух предыдущих шагов.
Дело в том, что инновации Биткойна и Эфириума заключаются в том, что оба этих типа проверяемости существуют в крипто-среде, более точно, в ончейн-среде.
После того как люди действительно исследовали силу ончейн-проверяемости, был момент, когда люди пытались построить все на ончейне. Игры, мессенджеры, утилиты, музыка, новости, каждое классическое приложение было помещено (или почти помещено) на ончейн.
Во время этой мании немногие люди сказали: "Почему это должно быть на блокчейне?".
Многие люди из традиционных финансов и ИТ-секторов начали строить то же самое, что они строили в своих отраслях, но на блокчейне. Большинство из них не сработали, точнее, почти ни одно из них не сработало.
Этот вопрос стал мемом. Главный ответ на этот вопрос был: "это не обязательно должно быть на блокчейне". Я считаю, что и вопрос, и ответ были неверными.
1. Первая причина: люди не понимали основное ценностное предложение криптовалюты.
Основная идея заключалась в том, чтобы просто поместить что-то на ончейн, не задумываясь о преимуществах, которые приносит ончейн-развертывание.
Следовательно, основное ценностное предложение в то время заключалось в том, что что-то на ончейне уже лучше, чем что-то не на ончейне, исключительно потому, что оно построено на децентрализованной инфраструктуре.
• Основное преимущество очевидно — приложение использует децентрализованную архитектуру.
• Основные недостатки также очевидны — дорогие и медленные вычисления по сравнению с централизованной архитектурой.
Так что это всё, верно? Нет.
Основная ценность, которую приложения получают от того, что они находятся на блокчейне, не в самой децентрализованной инфраструктуре, а в проверяемости, которую эта децентрализованная инфраструктура приносит. Строить всю логику приложения на ончейне — это болезненно и нерационально по нескольким причинам:
• Вы ограничены конкретным программным обеспечением, которое работает только в определенной ВМ (виртуальной машине)
• Вы ограничены конкретным оборудованием для нужд вашего приложения
• Вы ограничены консенсусным протоколом блокчейна
• Вы ограничены взаимодействиями с внешним миром и получением внешних данных
Да, смарт-контракты могут получать внешние данные через оракулы, но у них есть свои проблемы с доверием, и эти данные являются публичными. Блокчейны работают на основе прозрачности, поэтому получение внешних публичных данных несложно, но получение частных данных гораздо сложнее (не забывайте о предположениях о доверии).
Следуя этой логике, может показаться, что мы должны придерживаться только того, что предлагает ончейн-индустрия, и строить в этих рамках, верно?
Конечно, нет!
Самое большое преимущество, которое имеет криптовалюта, — это проверяемость: каждый пользователь может независимо проверить правильность, целостность, подлинность каждого действия. Что наиболее важно, они могут быть уверены, что их не обманут, и предотвратить обман других пользователей.
Однако, как я уже говорил ранее, не все можно поместить на ончейн, потому что это либо медленно, дорого, либо просто невозможно.
Вы не можете просто поместить выразительные и сложные инструкции (код) на ончейн. Копировать и вставлять в этом случае не сработает.
Вот почему предыдущие решения не сработали: они пытались поместить всю инфраструктуру на ончейн, что естественным образом ограничивает функциональность приложения, потому что инструменты веб3 гораздо уже, чем инструменты веб2 (по крайней мере, на данный момент).
2. Если мы не можем построить всю инфраструктуру на ончейне, можем ли мы построить хотя бы ее часть?
Нужна ли всем приложениям проверяемость? Нет, но большинству из них.
Давайте возьмем платформу, на которой вы сейчас читаете этот текст — Твиттер. Как отметил @shilpi_jc, Твиттеру нужна проверяемость для:
• расчетов рекламных доходов (потому что создатели хотят быть уверены, что им платят справедливо)
• реальных просмотров пользователей (чтобы убедиться, что просмотры не накручены)
• трендовых тем (потому что это имеет огромное влияние на общественные дискуссии)
• и т.д.
"Почему мы обсуждаем Твиттер? Никто не собирается помещать Твиттер на блокчейн".
Да, никто не собирается это делать, потому что это невозможно:
• вы не можете вызывать API
• вы не можете запускать алгоритмы обнаружения ботов
• вы не можете делать ничего сложного
Что вы можете сделать, так это написать простую функцию, которая рассчитывает выплаты только на основе количества просмотров, которые можно легко накрутить.
Если мы рассмотрим сложные системы, такие как ИИ, @_jasonwei написал о Законе Вертификатора: "Легкость обучения ИИ решать задачу пропорциональна тому, насколько проверяемой является задача".
Если что-то достаточно легко решить (например, переводы), это может быть проверяемо на ончейне. Обучение сложных моделей ИИ требует много ресурсов, поэтому проверка этой модели также потребует много ресурсов, которые текущая блокчейн-инфраструктура просто не готова выделить.
• Мы не можем поместить сложную логику приложения на ончейн, но, возможно, мы можем поместить хотя бы основную часть этой логики для обновления состояния и облегчения передачи ценности?
• Вы не можете запускать алгоритмы обнаружения ботов, чтобы рассчитать реальное количество просмотров, но можем ли мы хотя бы иметь выплаты за эти просмотры на ончейне?
Мы можем, мы также можем хранить и обновлять конечное состояние на ончейне, это не так вычислительно дорого.
Итак, мы решили, что можем сохранить логику, связанную с консенсусом, на ончейне, но что насчет более сложных вычислений?
Чтобы дать вам представление о том, насколько далеко мы от того, чтобы поместить все на ончейн, @0xbodu заметил, что:
• Потребуется 1000 MegaETH цепей, чтобы воспроизвести глобальную функциональность Uber.
• И потребуется 100 MegaETH цепей, чтобы сделать то же самое только для Нью-Йорка.
3. Можем ли мы сохранить основную логику на ончейне и сделать сложную логику проверяемой?
Мы определенно хотим сохранить основную логику на ончейне, но что насчет другой более сложной логики?
Первая естественная мысль — использовать что-то вроде AWS и его микросервисов. Да, мы можем, но это не имеет проверяемости, что критически важно для многих как потребительских, так и инфраструктурных приложений.
Что нам делать?
Мы должны найти способ сделать эту сложную логику проверяемой. У нас уже есть много проверяемости для цифровых активов и смарт-контрактов, но теперь мы хотим применить это к более сложной инфраструктуре.
4. EigenCloud?
@eigenlayer недавно переименовался в EigenCloud, чтобы увеличить акцент на проверяемости. Хотя EigenLayer в основном был известен как протокол повторного стекинга на Эфириуме, это восприятие не совсем верно.
Повторное стекинг подсознательно означает проверяемость, если что-то может быть слэшировано — это может быть проверено. Повторное стекинг — это часть того, почему проверяемость возможна, но добавление слэширования в инфраструктуру не делает ее автоматически проверяемой.
Все приложения состоят из нескольких компонентов. Основное понимание продукта EigenCloud заключается в том, что не каждый компонент приложения должен быть проверяемым, и если им нужна проверка, существуют разные уровни этой проверки.
Существует 3 разных уровня проверяемости в большинстве приложений:
• Простая логика (переводы): ончейн-проверяемость
• Сложная логика (API, алгоритмы, ИИ/МЛ): оффчейн-проверяемость
• Рутинная логика: без проверяемости
EigenCloud сосредоточен на оффчейн-проверяемости, где сложные системы и компоненты сложных систем должны быть проверены.
Существует множество статей о архитектуре EigenCloud, оффчейн-проверяемости и о том, как это работает, и я не хочу их повторять.
Что я хочу сделать, так это привести 3 примера того, насколько важна проверяемость сложных систем и как даже не крипто-системы могут извлечь выгоду из EigenCloud.
Я возьму 3 разных случая: игры, робототехника (вдохновленный @jinglingcookies) и будущее киберпанковских отношений между агентом и человеком.
5. Проверяемость в играх и как сделать игру более справедливой.
Я провел 7 лет своей жизни (точнее 12 000 часов), играя в Team Fortress 2 (TF2), который является многопользовательской шутер-игрой. Я видел достаточно и знаю, как работает каждая механика игры.
Тем не менее, были вещи, которые глубоко меня расстраивали. Я не понимал, почему, пока не начал больше изучать проверяемость и применять ее к своему предыдущему опыту.
• У нас была проблема с хакерскими ботами, заполняющими серверы, и 13 из 24 игроков были ботами.
• Боты выгоняли реальных игроков голосованием, потому что они были большинством.
• Они разрушали серверы и делали игру буквально непригодной для игры в течение определенного времени.
Да, существуют системы античита, но эти системы не могли идентифицировать, что это были боты и хакеры, они продолжали играть в игру нечестно.
Если бы системы античита проверяли, что игрок является ботом, хакером или использует читы, они не смогли бы играть. Если бы системы античита ложным образом обвиняли реальных игроков в читерстве — эти системы были бы слэшированы.
Еще одной интересной особенностью TF2 являются случайные критические удары.
Случайные критические удары происходят случайно, когда игрок стреляет из оружия, и они наносят в 3 раза больше урона, чем они обычно получают от обычного удара.
• Проблема: есть некоторые виды оружия в игре, которые постоянно дают больше случайных критических ударов, чем другие виды оружия.
• Когда базовый шанс случайного критического удара составляет 2%, некоторые виды оружия давали 20% шанс и использовали нечестное преимущество над другими игроками.
Если бы логика, отвечающая за случайные критические удары, была реализована в EigenCloud, она была бы проверяемой, и оружие в конечном итоге было бы ослаблено.
Очевидно, что TF2 не нуждается в проверке всего, но некоторые компоненты действительно нуждаются в этом.
Логика хранения и торговли предметами в игре может быть сохранена на ончейне и быть полностью проверяемой, потому что эта логика довольно тривиальна. Я бы играл еще пару лет, если бы они исправили эти проблемы (возможно).
6. Проверяемость в индустрии робототехники и почему это гораздо важнее, чем вы думаете.
Индустрия робототехники развивается довольно быстро, и существует много проблем, особенно связанных с безопасной совместимостью между 2 роботами.
• Представьте, что у вас есть рободог, который патрулирует ваш дом.
• Рободог обнаруживает что-то странное и подозрительное.
• Рободог сообщает вашему гуманоидному роботу дома о том, что он увидел.
Процесс информирования — это передача данных, эти данные должны быть безопасными и проверяемыми, иначе это может буквально поставить под угрозу вашу жизнь.
В этом случае оба робота могут даже работать как мини-блокчейн, хранящий общее состояние памяти, где каждая часть информации проверяема.
Для процесса проверки (EigenVerify) данные должны храниться где-то (EigenDA), чтобы убедиться, что они доступны для проверки в течение каждого периода времени в рамках временного интервала.
• Когда мы имеем дело с роботами, мы должны быть уверены, что каждый робот проверяем.
• Если мы имеем дело с несколькими роботами, мы должны убедиться, что обмен сообщениями (совместимость) между этими роботами также проверяем.
Несоответствие и нечестное поведение могут иметь гораздо более серьезные последствия, чем боты в компьютерных играх.
7. Проверяемость в будущих компаниях с нулевыми сотрудниками, управляемых ИИ-агентами.
@shayonsengupta написал замечательную статью в начале 2025 года о человеческо-агентских отношениях. Согласно статье, в будущем будут компании с нулевыми сотрудниками, где работают один или несколько агентов.
Они будут финансироваться людьми, а агенты будут выделять капитал для действий, которые они не могут выполнить или не достаточно умны, чтобы подумать о том, что им нужно для роста компании.
Предположение заключается в том, что агенты смогут делать то же самое в будущем и будут настолько умны, что любое человеческое вмешательство испортит результат и приведет к нулю.
(То же самое произошло раньше с шахматными ботами, где минимальное человеческое влияние делает систему менее эффективной, чем она была бы без человеческого вмешательства)
Если действительно существует мир, в котором мы будем жить, нам действительно нужна проверяемость каждого действия, которое агент будет выполнять.
Особенно в этой связи между агентами и людьми. Агенты будут давать задания людям и вознаграждать их после выполнения.
• как проверить, что задание действительно выполнено?
• как проверить, что агент вознаградил человека?
• как проверить, что агент вознаградил правильного человека?
• как проверить, что агент вознаградил правильную сумму денег правильному человеку?
Существует бесконечное количество вопросов и только один ответ:
Все должно быть проверено, чтобы убедиться, что система не является злонамеренной и вредной.
Крипто-структуры являются наилучшим вариантом в этом случае, так как платежи могут быть осуществлены на ончейне, в то время как более сложная инфраструктура агентов и координации между агентами и людьми может быть вне ончейна.
8. Использование проверяемости вне криптоиндустрии.
Инфраструктура будет стремиться к глобальному применению в более широкую криптоэкосистему, а затем за пределами крипто.
• Например: EigenCloud не ограничивается Эфириумом, эта инфраструктура может быть использована для других L1, таких как Solana, или других L2 как с Эфириумом, так и без него.
• То же самое касается EigenDA, это не просто промежуточное ПО между L2 и L1, оно может быть применено к любым компонентам, где входные и выходные данные вычислений должны оставаться доступными для проверки.
Проверяемость криптовалюты может даже быть использована в спортивных судейских событиях.
• В таких видах спорта, как фигурное катание или гимнастика, судьи субъективно оценивают выступления по артистизму и технике, что часто приводит к различным оценкам.
• Выбросы оценок могут вызвать сомнения или обвинения в предвзятости.
• Судьи могут согласовываться с большинством, чтобы избежать критики.
Модель ИИ могла бы стандартизировать оценки, используя заранее определенные метрики (например, отслеживание движений), с наказаниями только для операторов, которые манипулируют входными или выходными данными модели.
Каждое действие этой модели ИИ должно быть проверяемым, иначе оно также может быть предвзятым к определенным результатам, и это просто не имеет смысла.
Существует 3 уровня проверки:
• Блокчейн (ончейн): обрабатывает платежи, некустодиальные и простую логику
• EigenCloud (оффчейн): обрабатывает сложные системы, которым действительно нужна проверяемость
• Традиционное облако: обрабатывает хранение контента, пользовательские интерфейсы и т.д.
Хотя большинству приложений действительно требуется проверяемость, они не обязательно должны быть полностью проверяемыми. Это связано с тем, что некоторые аспекты просто не требуют проверки, и нет необходимости включать это лишь ради проверки.
Основная идея EigenCloud и более широкого преимущества криптовалюты заключается в том, чтобы предоставить проверяемость там, где она действительно нужна, а не для всего, что существует.
Криптовалюта позволила добиться значительного прогресса в доказательствах с нулевым разглашением — концепции, которая существовала ранее, но получала меньше внимания. То же самое произойдет с проверяемостью, на самом деле, это уже происходит.
Показать оригинал
Социальные сети