Зелёные смарт-контракты: блокчейн потребляет больше энергии, чем консенсус

Источник · Перевод автора

10 миллионам человек, размещающим один гипотетический заказ картофеля фри на Эфириуме, требуется достаточно энергии для питания 5,67 миллионов домов в США в течение 1 дня.

Слишком знакомая критика блокчейн-технологии заключается в том, что она потребляет слишком много энергии. Как только люди узнают, что одна биткойн-транзакция потребляет столько энергии, сколько требуется для питания 18 домов в США в течение полных 24 часов, либо что ежегодное энергопотребление сети Ethereum превышает энергопотребление всей страны Боливия, они отключаются. По праву так.

Для тех, кто решит начать задавать вопросы, есть те, кто быстро предложит простую поправку: расточительное доказательство механизмов консенсуса в работе, используемых лидерами рынка Биткойн и Эфириум, не является неотъемлемым свойством технологий блокчейн. На самом деле, с 2013 года существуют надежные механизмы «зеленого» консенсуса, работающие с публичными цепочками блоков, такие как доказательство заинтересованности.

На этом разговор об энергетических отходах заканчивается.

Тем не менее, Ethereum, как и любой другой общедоступный блокчейн, использующий умные контракты, сталкивается с еще одной бомбой замедленного действия, связанной с энергией: умные контракты — это огромные энергетические боровы.

Насколько огромный? Что ж, для 10 миллионов человек, размещающих один гипотетический заказ картофеля фри на Ethereum, требуется достаточно энергии для питания 5,67 миллионов домов в США в течение 1 дня.

Это не обязательно должно быть так, но для того, чтобы иметь возможность решить эту проблему, разговору о структурах смарт-контрактов нужно больше нюансов.

Виновник: состояние исполнения контракта

На высоком уровне проблема заключается в том, как выполняются умные контракты. Стандарт рынка на данный момент был установлен Ethereum в 2015 году, и это то, что я называю «исполнение контракта с соблюдением состояния».

Выполнение с отслеживанием состояния означает, что каждый узел или компьютер в сети по отдельности выполняет каждый контракт или программу и сравнивает их результаты с другими. Предполагая, что более 50% сети достигает того же результата, это изменение записывается в цепочку блоков.

Этот пуристический дизайн имел смысл для ранних блокчейн-проектов. Самый простой способ доверять распределенной бухгалтерской книге — это знать, что расчеты каждого умного контракта, который влияет на базовые данные, записанные в цепочку блоков, выполняются и проверяются всеми остальными. Трудно обмануть, если бы мы все делали одинаковую работу.

Хотя это максимизирует доверие к тому, что программа будет функционировать так, как ожидается, это означает, что сеть работает так же быстро, как и ее самый медленный узел, потому что каждый узел должен выполнять свою собственную работу, прежде чем согласовывать изменения. Помимо скорости, это напрямую влияет на потребление энергии. Вместо того, чтобы просто обрабатывать простые транзакции, каждый узел должен выполнять программы полного контракта.

Другими словами, вместо простой проверки транзакции путем объявления «принять» или «отклонить», узлы должны проходить блок-схему логики «если это, то это», чтобы принять решение о том, «принимать» или «Отклонить» изменение.

Затраты энергии на транзакции и смарт-контракты

По оценке Digiconomist, для одной обычной транзакции в сети Ethereum требуется 22 кВт-ч электроэнергии. Для справки, данные Управления энергетической информации США показывают, что в течение 30 дней в месяц средняя семья в США потребляла 28,9 кВт-ч электроэнергии в день в 2017 году.

Смарт-контракты в сети Ethereum измеряются с использованием Gas, стандартной платы за различные типы вычислений. Если вы новичок в концепции газа, читайте больше здесь и здесь.

После запроса общественного мнения и получения обратной связи непосредственно от Digiconomist было решено, что наиболее точный способ преобразования газа в энергопотребление будет включать в себя просмотр общей энергии, потребленной сетью за предыдущий день, и сравнение ее с общим газом, потребленным за этот период. тот же период. Объединяя данные из индекса потребления энергии Эфириума Digiconomist и etherchain.org, мы можем прийти к оценке, что:

1 Gas = 0,0004 кВтч электроэнергии

Следует отметить, что этот расчет является приблизительным приближением, поскольку он учитывает только потребление энергии валидаторами майнинга. Из-за нехватки данных это не учитывает энергопотребление не-майнинговых, полностью проверяющих узлов. Дальнейший сбор данных и исследования рекомендуется для целостной оценки энергопотребления умного исполнения контракта.

Мы также знаем, что каждая стандартная операция в сети Ethereum, например добавление или умножение чисел, измеряется в газе по следующим показателям:

  • 3 Gas для каждого вычисления, которое требует сложения или вычитания целых чисел
  • 5 Gas для каждого вычисления, которое требует умножения или деления целых чисел
  • 20000 Gas для каждого вычисления, требующего, чтобы одно 256-битное слово (обычный текст) было передано на хранение

Уравнение для расчета вашего газа для выполнения конкретного контракта:

21000 Gas для проверки вашей транзакции + сумма, необходимая для покрытия расчетов в вашем контракте.

Потребность в энергии 1 «приложения-убийцы» равна 5,67 млн домов в США в течение 1 дня

Представьте себе сеть, подобную Ethereum, с существующими 8000 узлов и 1 убийственным приложением, которое неожиданно привлекает 10 миллионов пользователей.

Допустим, каждый человек делает 1 запрос, который включает в себя написание одного 256-битного слова, выполнение 1 вычисления, сложение нескольких целых чисел и выполнение 1 вычисления, умножая несколько чисел вместе.

Просто чтобы сделать его сопоставимым с реальной жизнью, подумайте о том, чтобы написать на квитанции слово «картофель фри», сложить столбец этой единой стоимости (0 долларов США + стоимость картофеля фри), а затем умножить эту промежуточную сумму на соответствующий налог с продаж. Это не обязательно умный контракт, который вы бы написали, но давайте просто используем его для легкой визуализации.

Результатом этого простого запроса является то, что каждому человеку требуется 41 008 газов, что соответствует 16,4 кВтч электроэнергии на человека.

16,4 кВт · ч x 10 000 000 взаимодействий = 164 000 000 кВт · ч

Вспомните цифры, приведенные выше, и мы можем оценить, что 10 миллионов заказов картофеля фри в этом приложении соответствуют энергии, достаточной для питания 5,67 млн домов в США в течение 1 дня по стандартной ставке 2017 года, равной 28,9 кВт / ч в день.

Зеленые смарт-контракты как альтернатива

До недавнего времени я считал, что основа для исполнения контрактов с состоянием — единственный способ сделать что-то. Оказывается, в начале 2019 года появился альтернативный «зеленый» подход, который я бы назвал исполнением контракта без гражданства.

Основная идея заключается в том, что смарт-контракты хранятся в блокчейне, однако контракты выполняются только одним узлом. Основной рабочий процесс заключается в том, что кто-то отправляет триггерную транзакцию с некоторой входной информацией, которая указывает на узел, на котором выполняется контракт, этот узел «исполнитель контракта» выполняет некоторые вычисления, а затем отправляет выходную транзакцию для консенсуса. Никаких сложных вычислений по всей сети, просто обычная транзакция для проверки.

Доверительный компромисс и Смягчение

Это означает, что вам нужно доверять узлу, на котором выполняется определенная программа или контракт, а это означает, что этот подход предполагает снижение степени доверия по сравнению с выполнением контракта с отслеживанием состояния. Тем не менее, меры по смягчению могут быть встроены в систему.

Например, платформа Ardor включает возможность запуска узла бегуна контракта по схеме утверждения с несколькими подписями. Если код контракта сделан с открытым исходным кодом, то несколько дополнительных узлов проверки также могут работать параллельно и проверять работу узла бегуна контракта, отмечая нечестную игру.

Юрист на недавней конференции SCIT 2019 в Нью-Йорке говорил, что многие регуляторы подавляют технологии «черного ящика», которые наносят вред потребителям, и что произошел заметный сдвиг в сторону открытого кода. Неизменность блокчейна практически требует открытых технологий в качестве меры защиты ответственности.

Если эта тенденция сохраняется, то модель исполнения контракта без сохранения состояния получает существенную выгоду от этого сдвига, поскольку, как представляется, она обеспечивает прозрачные, масштабируемые и устойчивые средства обеспечения целостности данных. Это также значительно повышает способность предприятий осуществлять реальное управление жизненным циклом контракта, поскольку все, что требуется для обновления контракта, — это развертывание нового кода на одном узле и обновление ссылок в будущих триггерных транзакциях, а затем отключение другого узла со старым контрактом.

Заключительные мысли

Ключевой вопрос в конце дня заключается в том, действительно ли всем узлам в данной сети, таким как Ethereum с 8000 узлов, действительно необходимо выполнить полное вычисление каждого умного контракта, или может ли один узел, который находится под управлением мульти-подписи, обеспечить тот же уровень целостности данных путем завершения самого вычисления и отправки окончательной транзакции для консенсуса. Выполнение контракта без гражданства все еще является относительно новым явлением в пространстве блокчейна, но, учитывая очевидные энергетические потери текущего отраслевого стандарта, это абсолютно необходимо для дальнейшего изучения и обсуждения.

Техническое Приложение

Я основываю весь свой анализ на технологии в ее нынешнем виде. К этому моменту я приветствую любые отзывы о том, как повысить точность расчетов выше; однако любой, кто делает заявление об «исправлении» этих проблем в Ethereum 2.0, должен признать, что на самом деле ни одно из решений Ethereum не изменит проблему с состоянием или отсутствием состояния. Даже если вы разрабатываете приложение на шарде Ethereum, все узлы на этом шарде должны выполнять контракт. Кроме того, у Ethereum есть фрагменты кода для доказательства механизма согласования ставок на GitHub с 2015 года, и он еще не достиг основной сети, несмотря на многочисленные заявления о том, что запуск был всего через несколько месяцев. Если у вас есть комментарии или исправления, пожалуйста, сосредоточьтесь на обсуждении технологии, которая фактически работает в общедоступной сети.