Поскольку сеть Ethereum продолжает развиваться и совершенствоваться, понимание концепции различных типов узлов становится все более важным. Однако реальность заключается в том, что большинство пользователей не готовы затрачивать усилия на запуск узла, несмотря на то, что аппаратные требования являются выполнимыми для многих. В «финальной игре» развития Ethereum критически важно, чтобы пользователи могли подтверждать целостность состояния и доступность данных без необходимости обширных технических знаний или ресурсов. В конце концов, блокчейн без верифицируемости, в конечном счете, просто неэффективная база данных.
В этой статье мы рассмотрим три ключевых типа узлов, которые определят будущее сети Ethereum: безсостоятельные узлы, состоятельные узлы и полные/архивные узлы. Мы рассмотрим, как безсостоятельные узлы могут обеспечить доверительную проверку новых блоков с использованием доказательств с нулевым разглашением, как состоятельные узлы могут обеспечить быстрый и доверительный доступ к текущему состоянию Ethereum, и как полные/архивные узлы могут хранить всю историю цепочки от генезиса. Понимая роли и компромиссы каждого типа узла, мы можем работать над более децентрализованной, безопасной и масштабируемой экосистемой Ethereum.
Как мы уже видели сегодня, большинство пользователей не хотят затрачивать много усилий на запуск какого-либо типа узла, хотя аппаратные требования для работы как у Bitcoin, так и у Ethereum достижимы для большинства активных пользователей обеих сетей. Здесь под "активным пользователем" понимается человек с значительным объемом активов в сети, можно считать, что это любой пользователь, для которого стоимость запуска узла не является преградой.
Вероятно, главная причина заключается в том, что подавляющее большинство пользователей не хотят этого делать, не готовы потратить несколько сотен долларов на оборудование или не имеют технических навыков по запуску. Несмотря на то, что Bitcoin и Ethereum сделали большие шаги в упрощении этого процесса, он все еще является довольно сложной задачей для не технического пользователя.
Видение безгосударственной Эфириум
Я считаю, что в "Конечной игре" каждого блокчейна пользователи должны будут проверить целостность состояния и доступность данных, даже не обязательно зная, что это такое. Хорошая новость в том, что эта цель вполне достижима с достаточным инжинирингом (технология нулевого знания и немноговыборка доступности данных).
В этом заключительном этапе практически все кошельки, которыми стоит пользоваться, будут иметь бессостоятельный узел, который для каждого нового блока, добавленного в цепочку, может запрашивать у любого полного узла на уровне p2p последний заголовок блока и zk-доказательство того, что изменения состояния от предыдущего заголовка блока были выполнены правильно, запрашивать некоторые случайные выборки данных у нескольких узлов, чтобы получить близкое к 100% уверенность в том, что все данные (блобы и данные выполнения блока) были опубликованы, а также zk-доказательство, которое доказывает, что сеть пришла к консенсусу и окончательно зафиксировала блок.
Пропускная способность/вычисления для этого очень мала и вполне могут быть выполнены на телефоне (или даже на умных часах, как@drakefjustin""> @drakefjustin любит упоминать).Упомянутый выше тип узла будет классифицирован как тип "бесхозный" узел, поскольку узел может проверять новые блоки без необходимости иметь текущее состояние локально, а вместо этого полагается на различные виды доказательств для проверки новых блоков.
Эти доказательства не обязательно должны быть zk-доказательствами. У нас будет безсостоятельная проверка выполнения задачи задолго до того, как мы сможем сделать то, что я описал выше, с zk-доказательствами для выполнения. На самом деле, безсостоятельное выполнение может быть сделано сегодня, но это ОЧЕНЬ неэффективно с текущей структурой дерева Меркла-Патриция, доказательства свидетелей слишком велики, чтобы быть практичными. (см. @peter_szilagyi's tweet).
См. здесь размер «свидетеля». Это основная проблема, с которой сталкивается безсостоятельное выполнение с текущим деревом Меркла-Патриции, многие блоки на этом скриншоте значительно меньше 100 КБ, и доказательство, необходимое для обеспечения безсостоятельной проверки, часто в 50 раз больше самого блока.
Структура MPT Ethereum m’s
Однако Ethereum обновит свою структуру дерева состояний на что-то другое, чем текущая структура Merkle-Patricia-Tree в будущем. Многие из вас, возможно, слышали о деревьях Verkle, которые были в планах уже несколько лет (если нет, то прочтите нашу статью -Деревья Verkle для нас всех: Часть 1). Они позволят создавать безсостоятельных клиентов, которые являются практическими, поскольку природа структуры дерева Веркля позволяет использовать очень маленькие свидетельства/доказательства.
Merkle дерево против деревьев Verkle
Одной из основных проблем, с которыми сталкиваются деревья Verkle, является их незащищенность от квантовых вычислений, что означает, что они в лучшем случае будут временным решением до тех пор, пока постоянное решение для структуры дерева состояний не станет зрелым и/или достаточно эффективным. Вероятным окончательным решением, вероятно, будет STARK-доказанное бинарное хэш-дерево, и с большой вероятностью деревья Verkle будут пропущены в пользу какого-то варианта STARK-доказанного бинарного хэш-дерева. (соответствующий мем из@VitalikButerin)
Одна очень интересная опция, которую может иметь узел без состояния, — это возможность не быть полностью без состояния. Например, можно было бы локально хранить состояние, которое вы считаете релевантным для вашего варианта использования (при условии, что ваш клиент поддерживает такую функцию).
Предположим, что у вас есть ваши активы, распределенные по нескольким адресам, активам и протоколам DeFi, в этом случае вы можете иметь состояние всего, что имеет отношение к вашему случаю использования, записанное локально на диск, используя при этом только ничтожно малое количество дискового пространства. Даже отслеживание всего состояния нескольких крупных протоколов DeFi займет всего несколько гигабайт, учитывая, что практически все новые телефоны поставляются с объемом памяти 128 ГБ и более, это не только возможно, но потенциально практично для пользователя сохранять все состояние, которое он считает полезным, записанным на флэш-память своего мобильного телефона.
(Краткое замечание о легких клиентах: В мире, где безсостоятельные клиенты могут эффективно проверять переходы состояний и тривиально достигать консенсуса, мне кажется, что действительно не будет потребности в традиционном легком клиенте, который полагается на добросовестное большинство.)
Узлы с сохранением состояния хранят только текущее и очень недавнее состояние, они удаляют все данные, старше определенного возраста (см.eip-4444(предложение). Текущее состояние требует локального построения блоков, а локальное построение блоков - это то, что бессостоятельные узлы не в состоянии сделать.
Узлы с состоянием не следует путать с «полными» узлами, поскольку узел с состоянием не будет содержать полную историю цепочки, потому что в будущем это станет очень интенсивным по данным. Узел с состоянием полезен для любого пользователя, который хочет быстрого и ненадежного доступа к текущему состоянию Ethereum, будь то запрос данных из состояния, построение блоков или использование этого типа узла для ставки.
Сохранение возможности запуска узлов с сохранением состояния на оборудовании потребителя является очень важной целью, которую, на мой взгляд, мы, сообщество Ethereum, должны сохранить, даже когда узлы без состояния становятся очень легкими и зрелыми. Одной из основных причин этого является то, что все узлы без состояния полагаются на узлы с состоянием для создания свидетельства, необходимого для безсостоятельной проверки новых блоков.
Для того, чтобы узнать, действителен ли транзакция, находящаяся в памяти, также требуется доступ к текущему состоянию, поэтому очень важно иметь очень децентрализованный набор узлов с состоянием в сети, который может обеспечить очень сильные гарантии стойкости к цензуре с некоторым видом дизайна списка включений.
Хорошая новость состоит в том, что с истечением срока действия состояния мы можем значительно упростить запуск узла с состоянием, с которым никто не взаимодействовал в течение некоторого времени, может быть удалено с диска узла, кто хочет взаимодействовать со состоянием, которое истекло, должен принести свидетеля (практически доказательство Меркле) для возвращения истекшего состояния в текущее состояние. Любой, у кого есть доступ к истории цепочки, может конструировать эти типы доказательств для возвращения истекшего состояния в доверительном режиме. На момент написания этого текста состояние Ethereum приближается к 300 ГБ, и пока не будет внедрена некоторая форма истечения срока действия состояния, размер состояния будет продолжать расти почти только в одном направлении.
(ЗдесьЭто очень отличная статья от @парадигмакоторое углубляется в тему роста и истечения срока действия государства)
Для целей настоящей статьи я собираюсь объединить полные и архивные узлы, поскольку обычный полный узел может с использованием информации, которую он записал на локальный диск, вычислить все данные, которые архивный узел записал на диск. Разница заключается в том, что полный узел обрезает состояние, которое больше не является последним/последним состоянием. Вы не можете запросить, например, "какой был баланс ETH учетной записи X на блоке Y примерно 5 лет назад" с обычного полного узла, в то время как архивный узел ответил бы на этот запрос за миллисекунду.
Простое руководство по полным узлам Ethereum против архивных узлов от @0xZeeve
Тем не менее, теоретически можно вычислить ответ на этот запрос из данных, которые полный узел записал на диск (вся история цепи), но не многие клиенты выполнения поддерживают эту функцию. Я считаю, что неразумно думать, что многие пользователи, даже опытные, будут запускать полный/архивный узел, скажем, через 10 лет, чтобы это была разумная опция, мы должны ограничить пропускную способность L1 до уровней, которые совершенно неразумны, когда мы можем получить значительно большую пропускную способность на L1 с минимальными компромиссами. Когда большинство пользователей могут легко проверять новые блоки с zk-proof, я считаю, что это стоит того, чтобы преследовать этот компромисс, когда выгоды настолько велики.
Возможно, мы сможем получить Execution-клиентов, способных эффективно работать на HDD и делать практичным хранение даже сотен терабайт архивного состояния относительно недорого. Это может позволить пользователям, которые по какой-либо причине хотят зарегистрировать все Ethereum, сделать это. Я знаю, что одна из целей Erigon - позволить запускать полноархивный узел на HDD.
В конечном итоге, будущее Ethereum будет определяться узлами, которые составляют его сеть. Принимая бессостоятельные узлы как наиболее реалистичный вариант для большинства пользователей, но при этом будучи прагматичными и понимая ценность наличия состоятельных и полных / архивных узлов в сети, мы можем создать идеальный баланс между децентрализацией, безопасностью и масштабируемостью, который будет выгоден для всех пользователей.
Пригласить больше голосов
Поскольку сеть Ethereum продолжает развиваться и совершенствоваться, понимание концепции различных типов узлов становится все более важным. Однако реальность заключается в том, что большинство пользователей не готовы затрачивать усилия на запуск узла, несмотря на то, что аппаратные требования являются выполнимыми для многих. В «финальной игре» развития Ethereum критически важно, чтобы пользователи могли подтверждать целостность состояния и доступность данных без необходимости обширных технических знаний или ресурсов. В конце концов, блокчейн без верифицируемости, в конечном счете, просто неэффективная база данных.
В этой статье мы рассмотрим три ключевых типа узлов, которые определят будущее сети Ethereum: безсостоятельные узлы, состоятельные узлы и полные/архивные узлы. Мы рассмотрим, как безсостоятельные узлы могут обеспечить доверительную проверку новых блоков с использованием доказательств с нулевым разглашением, как состоятельные узлы могут обеспечить быстрый и доверительный доступ к текущему состоянию Ethereum, и как полные/архивные узлы могут хранить всю историю цепочки от генезиса. Понимая роли и компромиссы каждого типа узла, мы можем работать над более децентрализованной, безопасной и масштабируемой экосистемой Ethereum.
Как мы уже видели сегодня, большинство пользователей не хотят затрачивать много усилий на запуск какого-либо типа узла, хотя аппаратные требования для работы как у Bitcoin, так и у Ethereum достижимы для большинства активных пользователей обеих сетей. Здесь под "активным пользователем" понимается человек с значительным объемом активов в сети, можно считать, что это любой пользователь, для которого стоимость запуска узла не является преградой.
Вероятно, главная причина заключается в том, что подавляющее большинство пользователей не хотят этого делать, не готовы потратить несколько сотен долларов на оборудование или не имеют технических навыков по запуску. Несмотря на то, что Bitcoin и Ethereum сделали большие шаги в упрощении этого процесса, он все еще является довольно сложной задачей для не технического пользователя.
Видение безгосударственной Эфириум
Я считаю, что в "Конечной игре" каждого блокчейна пользователи должны будут проверить целостность состояния и доступность данных, даже не обязательно зная, что это такое. Хорошая новость в том, что эта цель вполне достижима с достаточным инжинирингом (технология нулевого знания и немноговыборка доступности данных).
В этом заключительном этапе практически все кошельки, которыми стоит пользоваться, будут иметь бессостоятельный узел, который для каждого нового блока, добавленного в цепочку, может запрашивать у любого полного узла на уровне p2p последний заголовок блока и zk-доказательство того, что изменения состояния от предыдущего заголовка блока были выполнены правильно, запрашивать некоторые случайные выборки данных у нескольких узлов, чтобы получить близкое к 100% уверенность в том, что все данные (блобы и данные выполнения блока) были опубликованы, а также zk-доказательство, которое доказывает, что сеть пришла к консенсусу и окончательно зафиксировала блок.
Пропускная способность/вычисления для этого очень мала и вполне могут быть выполнены на телефоне (или даже на умных часах, как@drakefjustin""> @drakefjustin любит упоминать).Упомянутый выше тип узла будет классифицирован как тип "бесхозный" узел, поскольку узел может проверять новые блоки без необходимости иметь текущее состояние локально, а вместо этого полагается на различные виды доказательств для проверки новых блоков.
Эти доказательства не обязательно должны быть zk-доказательствами. У нас будет безсостоятельная проверка выполнения задачи задолго до того, как мы сможем сделать то, что я описал выше, с zk-доказательствами для выполнения. На самом деле, безсостоятельное выполнение может быть сделано сегодня, но это ОЧЕНЬ неэффективно с текущей структурой дерева Меркла-Патриция, доказательства свидетелей слишком велики, чтобы быть практичными. (см. @peter_szilagyi's tweet).
См. здесь размер «свидетеля». Это основная проблема, с которой сталкивается безсостоятельное выполнение с текущим деревом Меркла-Патриции, многие блоки на этом скриншоте значительно меньше 100 КБ, и доказательство, необходимое для обеспечения безсостоятельной проверки, часто в 50 раз больше самого блока.
Структура MPT Ethereum m’s
Однако Ethereum обновит свою структуру дерева состояний на что-то другое, чем текущая структура Merkle-Patricia-Tree в будущем. Многие из вас, возможно, слышали о деревьях Verkle, которые были в планах уже несколько лет (если нет, то прочтите нашу статью -Деревья Verkle для нас всех: Часть 1). Они позволят создавать безсостоятельных клиентов, которые являются практическими, поскольку природа структуры дерева Веркля позволяет использовать очень маленькие свидетельства/доказательства.
Merkle дерево против деревьев Verkle
Одной из основных проблем, с которыми сталкиваются деревья Verkle, является их незащищенность от квантовых вычислений, что означает, что они в лучшем случае будут временным решением до тех пор, пока постоянное решение для структуры дерева состояний не станет зрелым и/или достаточно эффективным. Вероятным окончательным решением, вероятно, будет STARK-доказанное бинарное хэш-дерево, и с большой вероятностью деревья Verkle будут пропущены в пользу какого-то варианта STARK-доказанного бинарного хэш-дерева. (соответствующий мем из@VitalikButerin)
Одна очень интересная опция, которую может иметь узел без состояния, — это возможность не быть полностью без состояния. Например, можно было бы локально хранить состояние, которое вы считаете релевантным для вашего варианта использования (при условии, что ваш клиент поддерживает такую функцию).
Предположим, что у вас есть ваши активы, распределенные по нескольким адресам, активам и протоколам DeFi, в этом случае вы можете иметь состояние всего, что имеет отношение к вашему случаю использования, записанное локально на диск, используя при этом только ничтожно малое количество дискового пространства. Даже отслеживание всего состояния нескольких крупных протоколов DeFi займет всего несколько гигабайт, учитывая, что практически все новые телефоны поставляются с объемом памяти 128 ГБ и более, это не только возможно, но потенциально практично для пользователя сохранять все состояние, которое он считает полезным, записанным на флэш-память своего мобильного телефона.
(Краткое замечание о легких клиентах: В мире, где безсостоятельные клиенты могут эффективно проверять переходы состояний и тривиально достигать консенсуса, мне кажется, что действительно не будет потребности в традиционном легком клиенте, который полагается на добросовестное большинство.)
Узлы с сохранением состояния хранят только текущее и очень недавнее состояние, они удаляют все данные, старше определенного возраста (см.eip-4444(предложение). Текущее состояние требует локального построения блоков, а локальное построение блоков - это то, что бессостоятельные узлы не в состоянии сделать.
Узлы с состоянием не следует путать с «полными» узлами, поскольку узел с состоянием не будет содержать полную историю цепочки, потому что в будущем это станет очень интенсивным по данным. Узел с состоянием полезен для любого пользователя, который хочет быстрого и ненадежного доступа к текущему состоянию Ethereum, будь то запрос данных из состояния, построение блоков или использование этого типа узла для ставки.
Сохранение возможности запуска узлов с сохранением состояния на оборудовании потребителя является очень важной целью, которую, на мой взгляд, мы, сообщество Ethereum, должны сохранить, даже когда узлы без состояния становятся очень легкими и зрелыми. Одной из основных причин этого является то, что все узлы без состояния полагаются на узлы с состоянием для создания свидетельства, необходимого для безсостоятельной проверки новых блоков.
Для того, чтобы узнать, действителен ли транзакция, находящаяся в памяти, также требуется доступ к текущему состоянию, поэтому очень важно иметь очень децентрализованный набор узлов с состоянием в сети, который может обеспечить очень сильные гарантии стойкости к цензуре с некоторым видом дизайна списка включений.
Хорошая новость состоит в том, что с истечением срока действия состояния мы можем значительно упростить запуск узла с состоянием, с которым никто не взаимодействовал в течение некоторого времени, может быть удалено с диска узла, кто хочет взаимодействовать со состоянием, которое истекло, должен принести свидетеля (практически доказательство Меркле) для возвращения истекшего состояния в текущее состояние. Любой, у кого есть доступ к истории цепочки, может конструировать эти типы доказательств для возвращения истекшего состояния в доверительном режиме. На момент написания этого текста состояние Ethereum приближается к 300 ГБ, и пока не будет внедрена некоторая форма истечения срока действия состояния, размер состояния будет продолжать расти почти только в одном направлении.
(ЗдесьЭто очень отличная статья от @парадигмакоторое углубляется в тему роста и истечения срока действия государства)
Для целей настоящей статьи я собираюсь объединить полные и архивные узлы, поскольку обычный полный узел может с использованием информации, которую он записал на локальный диск, вычислить все данные, которые архивный узел записал на диск. Разница заключается в том, что полный узел обрезает состояние, которое больше не является последним/последним состоянием. Вы не можете запросить, например, "какой был баланс ETH учетной записи X на блоке Y примерно 5 лет назад" с обычного полного узла, в то время как архивный узел ответил бы на этот запрос за миллисекунду.
Простое руководство по полным узлам Ethereum против архивных узлов от @0xZeeve
Тем не менее, теоретически можно вычислить ответ на этот запрос из данных, которые полный узел записал на диск (вся история цепи), но не многие клиенты выполнения поддерживают эту функцию. Я считаю, что неразумно думать, что многие пользователи, даже опытные, будут запускать полный/архивный узел, скажем, через 10 лет, чтобы это была разумная опция, мы должны ограничить пропускную способность L1 до уровней, которые совершенно неразумны, когда мы можем получить значительно большую пропускную способность на L1 с минимальными компромиссами. Когда большинство пользователей могут легко проверять новые блоки с zk-proof, я считаю, что это стоит того, чтобы преследовать этот компромисс, когда выгоды настолько велики.
Возможно, мы сможем получить Execution-клиентов, способных эффективно работать на HDD и делать практичным хранение даже сотен терабайт архивного состояния относительно недорого. Это может позволить пользователям, которые по какой-либо причине хотят зарегистрировать все Ethereum, сделать это. Я знаю, что одна из целей Erigon - позволить запускать полноархивный узел на HDD.
В конечном итоге, будущее Ethereum будет определяться узлами, которые составляют его сеть. Принимая бессостоятельные узлы как наиболее реалистичный вариант для большинства пользователей, но при этом будучи прагматичными и понимая ценность наличия состоятельных и полных / архивных узлов в сети, мы можем создать идеальный баланс между децентрализацией, безопасностью и масштабируемостью, который будет выгоден для всех пользователей.