————————————————————
Традиционные разветвления блокчейна часто сопровождаются расколом в сообществе, например, разветвление Ethereum и Ethereum Classic (ETC) возникло из-за субъективной оценки "следует ли откатить взломанный контракт DAO".
Это разветвление зависит от социального консенсуса — кто сможет убедить больше людей, тот и "выживет".
Определение Eigenlayer пытается изменить эту ситуацию, с помощью двух ключевых слов "предварительно определенный" и "самопроверяемый", переводя условия для разветвления из неясных моральных или экономических споров в чёткие технические правила.
——предварительно определённый: означает, что условия разветвления не являются результатом споров после факта, а заранее записаны в протоколе, как юридические положения. Это снижает неопределённость, возникающую из временных решений.
——самопроверка: подчеркивает, что проверяемость событий должна быть децентрализована, любой узел (даже легкий узел) должен иметь возможность самостоятельно судить, достигнуты ли условия для разветвления, избегая зависимости от централизованных "авторитетных" интерпретаций.
1)потенциал и недостатки существующих правил Ethereum🔻
Ethereum уже имеет некоторые "предварительно определённые события", которые могут служить основанием для разветвления, такие как отказ в невалидных блоках, отклонение повторной сборки по истечении времени и т. д.
Эти правила действительно отражают определённые характеристики "самопроверки", особенно три первых пункта (отказ в невалидных блоках, отказ в повторной сборке по истечении времени, отказ в недоступных блоках), потому что они могут быть выполнены независимо через локальную проверку узлов. Однако обзор валидаторов и ошибки клиента выявили ограничения текущих правил.
1、проблемы проверки, связанные с обзором валидаторов:
Как вы сказали, обзор валидаторов в настоящее время может полагаться только на "косвенные доказательства", такие как жалобы в социальных сетях. Этот подход явно недостаточно "самопроверяемый", поскольку его легко манипулировать (например, кто-то злонамеренно распространяет слухи) и его нельзя алгоритмизировать. Если вы хотите, чтобы обзор стал основанием для разветвления, необходимо разработать технические показатели, такие как "непрерывные X блоков, не содержащих определённый тип транзакций" как наблюдаемый стандарт. Так можно будет позволить узлам самостоятельно судить, а не полагаться на внешнюю информацию.
2、сложность ошибок клиента:
Хотя ошибки клиента можно проверить с помощью псевдокодовых спецификаций, фактические операционные способности операторов узлов варьируются. Если большинство узлов не могут своевременно выявить ошибки и достичь согласия, этап исполнения разветвления может оказаться в беспорядке. Именно поэтому важно разнообразие клиентов (client diversity) — доминирование одного клиента может привести к ситуации "ошибка — это судьба", тогда как разнообразие снижает риски.

2)разветвления не включают в себя🔻
1、ситуации, когда предложитель разветвления проводит обзор, например, предложитель блока рассматривает некоторые материалы.
2、потому что Lido, Coinbase или кто-то другой имеет 33% ставки, будет разветвление
3、потому что произошло разветвление из-за ошибок на уровне приложения или пользователей.
Разветвление должно сосредоточиться на основных вопросах на уровне протокола, а не на внешних факторах или вторичных ошибках. Это на самом деле определяет границы разветвления, предотвращая его использование в качестве политического инструмента. Например:
——если разветвление происходит из-за того, что Lido или Coinbase владеют 33%, это по сути направлено на экономическую власть, а не на технические сбои, что явно отклоняется от принципа "самопроверки".
——ошибки уровня приложения (например, сбой какого-то DApp) также не должны вызывать разветвление, потому что это выходит за рамки обязанностей базового уровня блокчейна.
Установление этих границ крайне важно, поскольку оно предотвращает превращение разветвления в игру "кто громче, тот и прав", а также защищает дух децентрализации Ethereum.
3)от подготовки к исполнению: идеальный процесс разветвления🔻
Два этапа, упомянутые в белой книге:
——этап подготовки: сообществу Ethereum необходимо достичь консенсуса, записать условия разветвления в код протокола и публично и прозрачно на цепочке. Это не только техническая задача, но и задача управления, которая требует балансировки интересов всех сторон.
——этап исполнения: как только условия срабатывают, узлы автоматически выполняют разветвление на основе локальной проверки, без необходимости в человеческом вмешательстве. Это требует, чтобы условия были разработаны достаточно точно, чтобы избежать двусмысленности.
Но в реальности достижение консенсуса на этапе подготовки может быть самой большой сложностью. Обновления Ethereum (например, переход на PoS) уже показали, что даже технические улучшения могут затягиваться на годы из-за разногласий в интересах. Установление условий для разветвления, боюсь, столкнётся с еще большими спорами.
📍вывод:
Суть разветвления Ethereum заключается в поддержании безопасности, надежности и децентрализации сети, и структура "предварительно определённого и самопроверяемого" пытается сделать этот процесс более объективным и автоматизированным.
Существующие правила являются отличной отправной точкой, но для того, чтобы действительно реализовать это видение, необходимо сделать больше усилий в техническом дизайне (особенно в обнаружении нарушений) и управлении сообществом. В будущем разветвление может больше не быть "гражданской войной", разрывающей сообщество, а стать "хирургическим инструментом" самовосстановления протокола — при условии, что мы сможем установить правила достаточно хорошо.

🔹Ссылка на оригинал: https://x.com/sreeramkannan/status/1893361540759433558?t=nQp5B8x78sBq6Wp9GAewEA&s=19