Перевод Кластер критической децентрализации 36c3 - Интероперабельность блокчейнов (NIPoPoW и сайдчейны)

Тема в разделе "Журналы о Monero", создана пользователем Mr. Pickles, 3 июл 2021.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    970
    Симпатии:
    246

    Аннтотация

    Мы поговорим о различных механизмах связи между блокчейнами с подтверждением выполенной работы, такими как суперблоки NIPoPoW, и о том, как их использовать для создания одностороннего и двустороннего канала передачи информации между цепочками без доверенной третьей стороны.


    Стенограмма выступления

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

    Костис: Привет всем! Всё работает, отлично. Меня зовут Костис, я работаю в IHK. Я проведу это выступление вместе со своим коллегой, Дионисом Зиндросом, бакалавром Афинского университета. Давайте начнём, у меня есть пульт, да, так лучше.

    В рамках этого выступления мы поговорим о том, что такое сайдчейн. Было много выступлений, уже было много сказано о сайдчейнах, но я дам определение того, что такое сайдчейн. Я собираюсь показать, что можно построить на основе сайдчейна, как построить двустороннюю привязку, которая, по сути, является активом, которым обмениваются два блокчейна. И для того, чтобы сделать это эффективно, мы используем доказательство работы, о котором расскажет уже Дионис. Но сначала кратко о сайдчейнах.

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

    И вот что мы имеем. Для примера я использую Ethereum и Ethereum Classic. Так будет проще. Итак, что происходит в этих блокчейнах? Они растут с течением времени, и в некоторой точке происходит какое-то событие, которое мы обозначили такой вот лягушкой. В нашем случае событие происходит в блокчейне Ethereum, и мы хотим сделать так, чтобы об этом событии стало известно в блокчейне Ethereum Classic. И здесь, используя ещё одно изображение лягушки, мы указываем на тот факт, что нам известно о событии, и мы можем отреагировать на такое событие каким-либо образом в блокчейне Ethereum. И в этом состоит основная идея интероперабельности. Мы хотим иметь возможность как-то реагировать на события в другом блокчейне.

    А сейчас давайте разберёмся с терминологией, которая пригодится нам в дальнейшем. В нашем случае Ethereum является исходным блокчейном, то есть блокчейном, в котором происходит событие, а Ethereum Classic — целевым блокчейном. В связи с этим существуют определённые требования. Нам хотелось бы, чтобы блокчейны использовали доказательство работы, но это не строгое требование, но сегодня мы рассмотрим именно такой случай — есть примеры некоторых криптовалют, использующих доказательство работы. Затем, чтобы сделать нечто более продвинутое, а именно это мы и собираемся сделать, требуется, чтобы криптовалюты также поддерживали смарт-контракты. И мы сделаем нечто продвинутое, то, что будет использовать возможности смарт-контрактов. И это будет отличаться от того, что говорилось в других выступлениях, посвящённых Monero. Monero не обладает возможностями смарт-контрактов. Это будет хорошим отклонением от общей темы.

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

    И есть ещё одна важная вещь. Кто-то может сказать: «Я могу делать это, имея майнер в целевом блокчейне, я могу следить за исходным блокчейном, и майнер или майнеры будут подтверждать, что там происходит». Но нам не хотелось бы переносить это бремя на майнеров. И мы пытаемся реализовать всё так, чтобы никак не затронуть базовый уровень без необходимости в изменениях, постоянных изменениях. И мы вводим свойство, которое называем «изоляция майнеров», которое довольно важно, и всё, о чём я буду говорить, обладает свойством изоляции майнеров.

    Итак, начнём со смарт-контракта, называемого crosschain-контрактом. На этом слайде показано, что он выполняется в целевом блокчейне, и суть нашей работе заключается в том, чтобы смарт-контракт получил информацию о том, что некоторое событие имело место в исходном блокчейне. И всё начинается с того, что смарт-контракт получает информацию о генезис-блоке исходного блокчейна. Это всё, что ему нужно для работы, и мы указываем здесь на это. Мы как бы создаём смарт-контракт с генезис-блоком исходного блокчейна.

    Теперь нам известно, что событие имело место, и теперь нам нужно больше информации о таком событии. И здесь есть два важных аспекта: само событие, то есть нам нужно какое-то описание события, и доказательство того, что событие действительно произошло. Когда происходит событие, оно сохраняется, и мы можем использовать его в дальнейшем, а как, я расскажу позже.

    Теперь о том, для чего нужно доказательство работы. Сейчас мы говорим о простых доказательствах, таких как SPV. Для тех, кто незнаком с термином, поясню: это необходимо, когда в блоке происходит какое-то событие, и мне нужно доказать вам, что этот блок находится в лучшем исходном блокчейне, и такое событие или транзакция в результате включается в этот блок. Для этого я предоставляю вам ряд заголовков и доказательство Меркла для включения нужного мне блока. Но мы не собираемся останавливаться на этом, поскольку данный метод недостаточно эффективен, и он может быть улучшен, о чём позже вам расскажет Дионис.

    Но этого недостаточно, прежде всего, потому что информация, содержащаяся в смарт-контракте, довольно ограничена, и кто-нибудь может исказить её, кто-нибудь может представить недействительный блокчейн, в котором будет содержаться транзакция, не принадлежащая лучшему исходному блокчейну. И чтобы избежать этого, мы говорим: «Хорошо, вы заявляете, что имело место данное событие, но мы предлагаем запустить период разрешения спорной ситуации». И если кто-то не согласится с вами, то у него будет возможность сказать: «Я не согласен с вами, и вот почему…» И такая сторона должна предоставить своё доказательство, с которым можно будет сравнить ваше доказательство, и если окажется, что предоставившая такое доказательство сторона права, она получит некоторый залог. В противном случае ничего не произойдёт, и когда закончится период разрешения спорной ситуации… тут я возвращаюсь к понятию залога, поскольку это тоже важно. Тут важно то, что в том случае, если другая сторона пыталась обмануть вас, будет использовано четыре доказательства.

    Мы снова возвращаемся к протоколу SPV. У нас есть две доказывающие стороны, которые вносят что-то в смарт-контракт, обе предоставляют свои блокчейны, которые сравниваются довольно простым способом: проверяется, какой из блокчейнов длиннее или же в котором из блокчейнов значение доказательства работы выше, как это происходит в случае с Bitcoin и так далее.

    Теперь давайте рассмотрим контракт. Это функция, вызываемая смарт-контрактом, когда кто-нибудь хочет указать на то, что в другом блокчейне произошло событие. И доказательство здесь обозначено как π, и оно подтверждает, что событие действительно имело место быть, а событием может быть транзакция, переведённая на этот адрес. И прежде чем перейти дальше, важно отметить, что если кто-то заявляет о событии, он также вносит залог, который можно будет забрать у такой стороны, если это окажется ложью, о чём я, собственно, и хотел вам сказать. Это заявление, вот здесь, говорит о том, что сторона внесла залог, и мы сохраняем событие, и мы можем определить лицо, которое внесло предложение, то есть вызвало всю эту функцию. Это и есть доказательство, которое использует такая сторона, и после этого мы можем запустить период разрешения спорной ситуации, который закончится через K блоков. И вся эта функция называется «доказательством сообщения о событии».

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

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

    Когда происходит подобное, мы допускаем, что кто-то сообщил о событии, и это действительно так, поскольку событие произошло, но время идёт, и период разрешения спорной ситуации заканчивается. Таким образом, мы даём возможность начальному заявителю или кому-то другому сказать: «Хорошо, период разрешения закончился, ничего не произошло, поэтому давайте заканчивать». Нет, на самом деле это делает только тот, кто сообщил о событии, прошу прощения. Точно. Это делает только заявитель, поскольку ему нужно вернуть свой залог. Таким образом, когда период разрешения спорной ситуации заканчивается, что проверяется таким вот образом, оригинальный заявитель вызывает функцию завершения события, а событие после этого добавляется к ряду завершённых событий. И запрашивающая сторона получает свой залог обратно. И это успешный сценарий. А что касается этого смарт-контракта, конкретно этого контракта, о котором мы говорим в рамках данного выступления, данный crosschain-контракт будет использоваться нами как основа для других смарт-контрактов. Он обеспечивает прекрасный API, который обозначает, что событие действительно существует, и мы передаём информацию об интересующем вас событии, чтобы вы знали, что оно действительно произошло.

    Теперь, когда с этим разобрались, рассмотрим, как создаётся двусторонняя привязка и что это такое в принципе. Представьте, что у вас есть монеты Ethereum в блокчейне Ethereum, и по какой-то причине вы хотите воспользоваться ими, но в блокчейне Ethereum Classic, поскольку, не знаю, поскольку вы хотите воспользоваться методом X, который применяется в Ethereum Classic. Не важно. Суть в том, что вы хотите использовать свой Ethereum в блокчейне Ethereum Classic. Вы можете перевести свой актив в Ethereum Classic, а потом использовать его как обычный токен: передавать его другим людям, вносить в смарт-контракт, то есть делать с ним что угодно. А затем вы говорите: «Отлично, я сделал то, что хотел в Ethereum Classic, и хочу вернуть всё в Ethereum и пользоваться этим блокчейном». В этом суть двусторонней привязки, и сейчас мы рассмотрим, как мы реализуем её.

    Для этого нам требуется два смарт-контракта, основанных на crosschain-контракте, о котором я уже говорил. Первый контракт мы обозначаем как X, и он принадлежит блокчейну Ethereum, а второй обозначаем как Y, и этот контракт находится в блокчейне Ethereum Classic. Итак, смарт-контракт Y, по сути, представляет токен ERC-20, обозначающий Ethereum в Ethereum Classic. Таким образом, мы хотим, чтобы у нас был токен, который бы был равносилен тому, как если бы у вас был один Ethereum. И вы можете получить такой токен, за исключением варианта, когда кто-то пришлёт его вам, вы можете получить его, заморозив Ethereum в смарт-контракте X. Когда вы включаете свой Ethereum в смарт-контракт, ETH блокируется, и если у вас есть токены Ethereum, токены ETH-20, как мы называем их, в блокчейне Ethereum Classic, вы можете забрать их обратно, восстановить их в блокчейне Ethereum, уничтожив их там.

    Это тот же слайд, что я показывал ранее, но теперь с некоторыми подробностями. Итак, допустим, у меня есть Ethereum, и я перемещаю его в этот контракт, а затем переношу это неким образом, и мы увидим, как это происходит, переношу в Ethereum Classic, то есть речь идёт о токенах ETH-20. А затем мы уже можем передать их кому-то другому, не важно. Но вот в этой точке кто-то, обладающий ими, может сказать: «Так, я собираюсь уничтожить их и получить Ethereum».

    И давайте на секунду предположим, что это можно легко сделать, а это можно легко сделать. Когда вы сжигаете X Bitcoin или любую другую сумму, когда вы сжигаете, скажем, пять Bitcoin, пять Ethereum, прошу прощения, вы получаете пять токенов ETH-20, а когда вы сжигаете пять ETH-20, то получаете пять ETH.

    Если мы допускаем, что так оно и происходит, а так оно и есть, что будет нами показано, то тут появляется независимая переменная, предполагающая, что цена токена будет такой же. То есть они будут соответствовать один к одному. И причина заключается в том, что в том случае, если цена будет как-либо отличаться, для этого будет предусмотрена возможность арбитража. Таким образом, если цена Ethereum окажется выше, чем цена приобретённого вами токена, токен будет переведён в Ethereum, а затем продан и наоборот. Это с нашей точки зрения гарантирует, что у этих токенов будет одинаковая цена. И теперь мы берём ETH и переносим его в Ethereum Classic и обратно. А теперь давайте более подробно рассмотрим, как происходит передача, как работает эта часть.

    Я рассматриваю эти блокчейны начиная с их генезис-блока, и предположим, что у Ethereum и Ethereum Classic разные генезис-блоки. Опять же, эти два блокчейна должны обладать свойством полноты по Тьюрингу, и здесь мы делаем важный допуск, согласно которому эти блокчейны сами по себе безопасны. И это действительно важный и единственный допуск, который нам необходимо сделать. Мы делаем это, чтобы показать, что мы создаём токен, который отражает токен Ethereum, но здесь мы называем его G1, мы обозначаем Ethereum как G1.

    А здесь показан код для данного смарт-контракта. И снова это Ethereum, сайдчейн 1, и в основе лежит crosschain-контракт. И снова нам необходимо знать, что генезис-блок Ethereum Classic имеется здесь, в другом блокчейне, где он обозначен как G2. А также необходимо знать адрес того же смарт-контракта в Ethereum Classic. И это снова подтверждает, что генезис-блок был записан. А инициализация может быть совершена лишь единожды, после чего это появится в другом контракте, который можно будет выполнить ещё раз.

    Таким образом, мы хотим записать определённое событие, которое происходит здесь. Событие происходит, когда мы хотим получить средства в целевой блокчейн из Ethereum Classic и хотим убедиться в том, что кто-то заплатил деньги в соответствии с контрактом X, что средства были заблокированы и что транзакция действительно была проведена, что она была включена в блок, что блок стабилен и что он был добавлен к блокчейну Ethereum. Таким образом, у нас есть событие Solidity, которое происходит в контракте X, и событие, по сути, становится доказательством того, что это произошло в Ethereum Classic.

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

    Давайте посмотрим, как это работает. Сначала средства вкладываются в Ethereum. Это, по сути, платёжная функция (payable function), поэтому у нас нет необходимости в том, чтобы указывать здесь сумму или что-то иное. Нам достаточно сказать: «Хорошо, мы берём эти деньги, сумма которых указана в сообщении, и направляем их на этот адрес», после чего происходит простой расчёт, происходит событие, и подобная вещь происходит и здесь, в блокчейне Ethereum Classic, где есть некоторый токен, который должен перейти в Ethereum. Мы размещаем его, это токен ERC20, и мы берём сумму, которую хотим уничтожить, чтобы получить средства в Ethereum. Она снимается с нашего баланса, и происходит это событие. И это уже другое событие. Это снова инициализация, которую мы уже обсудили.

    А теперь посмотрим, что происходит с другой стороны. Мы обсудили, как мы можем положить деньги, а теперь разберёмся, как можно снять их. Когда кто-нибудь уничтожает свои токены, токены ETH20 в блокчейне Ethereum Classic, включается функция выведения средств. Это гарантирует активацию события, которое мы рассмотрели ранее, а также, что средства будут отправлены. И, по-моему, здесь у нас ошибка, это должен быть целевой блокчейн. И здесь, во второй цепочке, в Ethereum Classic кто-то вызывает эту функцию, если кто-то в блокчейне Ethereum заплатил деньги по контракту X, и это гарантирует активацию надлежащего события с передачей нужной суммы, как в случае с токеном ETH20.

    А здесь показан полностью весь контракт, что нам не нужно. А теперь на сцену выйдет Дионис и расскажет о доказательствах NIPoPoWs, которые позволяют улучшить эту схему.

    Дионис: Привет всем! Меня зовут Дионис. Слишком громко? Хорошо. Выйти на свет? Да, спасибо, конечно. Когда Костис рассказывал вам о смарт-контрактах, он говорил об их центральной части, которая называется «наличием события» и которая служит для того, чтобы проверить, не произошло ли чего в удалённом блокчейне, и мы оставляем эту часть скрытой. Костис объяснил, как это работает, то есть у нас есть «родительский» смарт-контракт, служащий основой для всех остальных, а в сам смарт-контракт включается следующее, и таким образом поддерживается цепочка всех блоков, всех заголовков блоков удалённого блокчейна. То есть наличие сообщения требует, чтобы каждый заголовок удалённого блока передавался в блокчейн для верификации. В нашем случае речь идёт о блокчейне Ethereum, которому необходимо знать каждый заголовок, имеющийся в Ethereum Classic. Очевидно, что это не очень эффективно, если реализовать эту схему на практике, так как превысит любые лимиты по газу, прежде чем вы достигните точки, когда будет можно запустить такую проверку.

    Очевидно, что это неэффективно или даже вовсе не будет работать. Поэтому нам нужно найти способ, при котором не пришлось бы пересылать весь блокчейн. Прежде чем я перейду к доказательствам NIPoPoWs, позволяющим решить эту проблему, хотелось бы спросить у зала, есть ли вопросы по схеме, о которой говорилось до этого, потому что сейчас мы углубимся в технически подробности. Итак, есть ли вопросы по смарт-контрактам, о которых говорилось до этого? Хорошо, тогда переходим к NIPoPoWs.

    Суть NIPoPoWs состоит в том, что у нас имеется ситуация, в которой произошло событие, в нашем случае это смарт-контракт, и у нас есть несколько доказывающих сторон, некоторые из которых являются честными, а некоторые действуют со злым умыслом. И все они вносят какую-то информацию в смарт-контракт. Как мы уже показали ранее, они добавляют цепочку всех заголовков удалённого блокчейна. Однако нам нужно как-то оптимизировать этот процесс. И здесь мы пытаемся ответить на вопрос: можем ли мы обойтись без того, чтобы отправлять каждый заголовок, или же нам неизбежно придётся отправлять каждый заголовок, или же это можно сделать каким-то сжатым образом, можем ли мы передавать меньше данных между двумя доказывающими сторонами, участвующими в смарт-контракте, можно ли это делать каким-то более эффективным способом, соответствующим требованиям по газу существующих блокчейнов? Мы не хотим строить новый блокчейн — это было бы странно. Мы хотим построить наше решение поверх уже существующих систем. И в рамках рассматриваемого нами протокола мы отправляем короткие доказательства π1 и π2, не являющиеся самими по себе блокчейнами, но представляющие сжатую форму блокчейна, свидетельствующую о том, что в блокчейне была совершена какая-то работа, но не раскрывающую всех подробностей. И верификатор должен как-то узнать, действительно ли произошло событие, которое он пытается верифицировать. И здесь верификатор делает запрос относительно события, о чём рассказывал Костис, была ли это транзакция или конкретный платёж, или же это было событие в рамках смарт-контракта, и принадлежит ли это событие самому длинному блокчейну, соответствующему базовому протоколу. Как бы то ни было, в данном случае мы не хотим отправлять все заголовки. Поэтому возникает вопрос, что эти доказывающие стороны должны добавить в смарт-контракт, чтобы смарт-контракт мог произвести своего рода сравнение между ними и узнать, произошло или нет событие?

    В реальности мы имеем дело со злоумышленником, который может заниматься майнингом и расширить таким образом исходный блокчейн. Такая доказывающая сторона может попытаться вычислить блоки, создать форки и так далее. Тем не менее у нас как верификаторов должна быть возможность отклонить их запросы, если они не связаны с самым большим блокчейном в нашей системе, если они принадлежат к блокчейну, который короче самого большого на данный момент блокчейна, такие события должны отклоняться. И тут возникает вопрос: как это сделать?

    Базовая идея состоит в расширении уравнения доказательства работы, которое используют Bitcoin, Monero и Ethereum. Оно одинаково во всех случаях, но давайте я вам напомню, как оно выглядит. Вспомним, что в случае с Bitcoin мы используем хеш-функцию SHA-256. Мы передаём ей заголовок блока, а затем проверяем, не превышает ли его значения какое-либо заданное значение T. Если значение меньше, значит, уравнение считается успешно решённым, а блок и доказательство работы действительными. И необходимо учесть, что хеш-функция работает как случайный оракул. То есть это означает, что если вы передаёте какие-то новые данные, которые не запрашивались ранее, можно предположить, что результат применения этой хеш-функции будет единообразно и случайным образом распределён по соответствующему пространству.

    Это интересный аспект, который учитывается нами и служит основой для построения конструкции, позволяющей сжать блокчейн. И в данном случае мы хотим построить такие вот суперблоки, по сути, не создавая новый тип блоков. Вместо этого мы просматриваем существующие блоки в блокчейне и ищем определённые блоки, называемые суперблоками, если у них имеется определённый атрибут. И это касается блоков исходного блокчейна, и мы называем блок «суперблоком», если он соответствует данному уравнению. Давайте разберёмся с этим. Итак, все блоки соответствуют этой части уравнения, то есть их значение меньше T, значение хеша блока меньше или равно T, но часть блоков, с которыми мы имеем дело, действительно идеально соответствуют уравнению, гораздо в большей степени, чем того требует протокол консенсуса. В частности, если рассматривать блоки, хеш которых состоит из ряда нулей, в контексте суперблоков это будут блоки с большим количеством нулей в начале хеша, чем требуется. В частности, это будут блоки с μ нулей, которые будут ненужными. Мы называем этот параметр «μ-суперцелью», и если блок соответствует данному уравнению, обладая μ количеством нулей, мы называем его новым «μ-суперблоком». Если у блока один дополнительный ноль, мы называем его 1-суперблоком, если 10 дополнительных нулей — 10-суперблоком. И, чтобы быть более точными, это лишь вероятность, что блок окажется суперблоком уровня μ, учитывая, что это действительный блок. И если блок является действительным, вероятность, что он достигнет этого свойства нового суперблока, составляет 2-μ. Таким образом, все блоки являются 0-суперблоками, половина из них — 1-суперблоками, четверть становятся 2-суперблоками, и одна восьмая — 3-суперблоками. По сути, получается, что мы ожидаем, что количество блоков, перешедших на следующий уровень, составит половину от блоков, имеющихся на предыдущем уровне. Вот что мы имеем в виду, когда говорим о суперблоках.

    В случае с нашим блокчейном это то, что мы называем уровнем суперблока. Это можно записать и математически, но это именно то, что я описал. Именно так выглядит блокчейн, если рассматривать его в контексте суперблоков. Блокчейн остаётся на нулевом уровне, ничего не меняется, мы не меняем протокол консенсуса, но мы интерпретируем его ровно таким вот образом. И мы можем увидеть, что некоторые из блоков являются 1-суперблоками, некоторые — 2-суперблоками, а некоторые 3-суперблоками. То есть, как показано здесь, половина являются 1-суперблоками, половина из них — 2-суперблоками, а половина этих 3-суперблоками. И по мере перехода на более высокий уровень они становятся более редкими. И они являются простой интерпретацией блокчейна, а не новыми блоками, вычисленными поверх других. Блокчейн остаётся тем же.

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

    Таким образом, идея таких NIPoPoW или сжатых доказательств, предоставляемых доказывающими сторонами верификаторам, состоит в том, что мы отправляем только суперблоки, а не всю цепочку заголовков. То есть мы передаём некоторые образцы блоков или заголовков блоков, которые некоторым образом отражают тот факт, что доказательство работы имело место, не высылая при этом самого доказательства работы. И поэтому мы называем это «доказательствами доказательства работы», ведь они доказывают, что доказательство работы было сделано без отправления доказательства работы. То есть сокращённо это называется PoPoW, а NI в сокращении NIPoPoW означает «неинтерактивное», поскольку мы генерируем такое доказательство, отправляем его для включения в смарт-контракт, а затем сам смарт-контракт верифицирует его.

    В этом состоит основная идея: мы выбираем определённый уровень μ, допустим, мы выбираем уровень μ, равный десяти, а затем мы говорим: «Отлично, я не стану отправлять вам весь блокчейн и всю цепочку заголовков, но я просто найду блоки, являющиеся 10-суперблоками, и размер этих 10-суперблоков составит лишь одну тысячную от размера всего блокчейна, и я отправлю только их заголовки». И после этого смарт-контракту останется только сравнить, чьи суперблоки будут больше, а не смотреть, кто прислал больше блоков. И в результате можно определить, чьё доказательство работы будет длиннее и кто победил.

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

    Одной из проблем данной конструкции, как я уже демонстрировал ранее, является то, что отправляемые суперблоки не упорядочены, так как отсутствует указатель, используемый в Bitcoin и Monero, когда каждый блок указывает на свой родительский блок. Таким образом, нам необходим механизм, который бы сортировал эти блоки так, чтобы они располагались в хронологическом порядке, в том же порядке, в котором они были созданы. Если мы не сделаем этого, то злоумышленник сможет изменить порядок блоков так, чтобы мы думали, что в блокчейне они идут не в том же порядке, что на самом деле.

    Таким образом, нам надо расширить структуру так, чтобы она выглядела подобным образом. Мы хотим, чтобы в блокчейне вместо указателя между двумя блоками, каждый блок так же указывал на последний блок на том же уровне. Здесь видно, что каждый блок на нулевом уровне указывает на последний нулевой блок, но каждый 1-суперблок при этом указывает на последний 1-суперблок, каждый 2-суперблок — на последний 2-суперблок и так далее. Кроме того, если блок является 3-суперблоком, он также является и 2-суперблоком, поскольку он начинается с трёх нулей, то есть и с двух нулей тоже.

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

    Теперь мне хотелось бы сказать несколько слов о том, как это работает, поскольку я пропустил некоторые технически подробности, которые следовало бы упомянуть для точности, так как недостаточно просто отправить суперблоки. Проблема заключается в том, что если вы пытаетесь сравнить два блокчейна, происходит следующее: есть один блокчейн Ethereum, самый длинный блокчейн Ethereum, и есть другой, который является форком Ethereum, и при отправке суперблоков может оказаться так, что к концу эти два доказательства могут сильно расходиться, ближе к самым последним блокам. И проблема состоит в том, что у нас не получится честно сравнить блокчейны, что представляет собой проблему уже с точки зрения безопасности. И при построении таких доказательств нам необходимо сделать так, чтобы верификатор мог сравнить их на любом выбранном им уровне μ. И здесь представлена конструкция, которую мне хотелось бы вам показать, а после этого я уже перейду к самому процессу сравнения.

    Итак, вот как доказывающая сторона строит доказательство, которое передаётся для включения в смарт-контракт. Берётся фактический блокчейн, то есть цепочка старых заголовков блоков, имеющихся в блокчейне, требующем доказательства, то есть в исходном блокчейне берётся определённое количество блоков с конца, k блоков, количество, которое, например, может быть равно 6, и эти блоки отправляются в доказательство. Таким образом, всегда отправляется 6 блоков из блокчейна. Это называется суффиксом доказательства. А теперь что касается префикса, который является стабильной частью блокчейна — это значительная часть, требующая сжатия. У нас есть некоторый параметр безопасности m, и этот параметр m может быть равен 3. Я для примера привожу значение m, равное 3, но если вы хотите, то из соображений безопасности вы можете увеличить этот параметр, скажем, до 100. Таким образом, мы начинаем с блокчейна, с уровня суперблоков, в который входит по крайней мере m блоков. В нашем случае m равно 3, и мы хотим включить суперблоки верхнего уровня, то есть по крайней мере три блока. В нашем примере это будет только 3-суперблок, и мы делаем следующее: мы не хотим включать ничего, кроме верхнего уровня, где m равно 3 блокам, и в нашем случае это уровень два, и мы хотим включить его полностью. А затем мы проверяем верхний уровень, где имеется по крайней мере m, что равно трём суперблокам, проверяем суффикс, который имеет длину, равную трём, и пытаемся заполнить все блоки на уровне ниже, которые соединяют два конца этого уровня, в нашем случае это уровень два. Итак, это блоки, которые были взяты нами с уровня один, и мы делаем то же самое на уровне один: мы ищем по крайней мере три блока на уровне один и заполняем их суперблоками нулевого уровня. Конечно же, это простой пример. В случае с реальным блокчейном Bitcoin у нас будет тридцать, тридцать семь уровней. Мы начинаем с верхнего уровня и заполняем их. Но при этом мы берём m блоков с конца, вот здесь, на этом уровне, и мы включаем только три блока. Этот блок охватывает эти блоки, этот — эти блоки. То есть я хочу донести две вещи: во-первых, я хочу, чтобы вы поняли, как происходит сравнение, а во-вторых, я хочу объяснить, почему доказательство получается коротким. Почему нам не требуется множество блоков, когда мы отправляем доказательство.

    Сначала про вторую часть. Эти блоки, которые я выделил здесь, являются частью доказательства, то есть это именно то, что передаётся для включения в смарт-контракт. Нам нужно, чтобы это было небольшое количество блоков, поскольку требуется обеспечить эффективный расход газа. Итак, на верхнем уровне мы включаем примерно m блоков, поскольку это верхний уровень, где должно быть по крайней мере m блоков. Таким образом, тут будет от m до 2m блоков. И давайте разберёмся, почему это так. Сначала здесь было десять блоков, поскольку это требование — у нас должно было быть десять блоков. Но я утверждаю, что должно быть не более чем 2m блоков, так как если бы здесь было более чем 2m блоков, поскольку на этом уровне должна быть примерно половина блоков от этого уровня, то тогда, если бы здесь было 2m блоков, на более высоком уровне было бы m блоков. Таким образом, он был бы включён как верхний уровень. Таким образом, на верхнем уровне должно быть от m до 2m блоков, скажем, примерно m блоков. Теперь на каждом следующем заполняемом уровне у нас будет 2m блоков. Почему? Потому что если на этом уровне у нас будет суффикс, имеющий длину m, и мы внесём его, то на нижнем уровне нам придётся удвоить количество блоков сверх того, что есть на уровне выше. Если здесь будет m, то на уровне ниже будет 2m блоков. Мы берём другой суффикс, имеющий длину m, и вносим его вместе с блоками на предыдущем уровне. И снова мы получаем 2m. И если мы продолжим, то снова возьмём m блоков с конца, заполним их и так далее. Таким образом, на каждом уровне мы будем брать примерно 2m блоков. И мне хотелось бы подчеркнуть, что здесь мы имеем дело с небольшим количеством уровней. Почему так? Если в сам блокчейн входит C блоков, то в сайдчейн будет входить половина C блоков, в два сайдчейна — четверть C блоков и так далее, пока мы не достигнем значения, равного одному блоку. И тогда мы достигнем цели. Но сколько раз нам нужно поделить C на 2, чтобы получить 1? Это просто двоичный логарифм размера блокчейна. Количество уровней, которое показано здесь, является логарифмом количества блоков, которые были включены в сам блокчейн. Таким образом, оно растёт логарифмически с течением времени. Количество уровней растёт логарифмически со временем. Но оно растёт очень и очень медленно.

    Таким образом, в данном случае аргументом является количество блоков, которое мы выбираем в качестве постоянного значения на каждом уровне. Оно может быть равно ста. Количество уровней — значение, которое растёт очень медленно. Поэтому данные доказательства будут очень короткими. На самом деле у нас есть некоторые результаты измерений, которые изложены в наших работах и которые доказывают, что всё обстоит именно так. Мы называем это «сжатостью». Данное понятие предполагает, что доказательства экспоненциально лучше, чем отправка всей цепочки заголовков. И если вам интересно асимптотическое обозначение этого, то здесь приводится выражение. Это логарифм, это размер блокчейна, помноженный на m, это количество уровней, это блоки, которые мы включаем на каждом уровне, а это фиксированное количество блоков, которое мы отправляем в конце. Поэтому размер доказательства действительно невелик — это полилогарифм, логарифм размера блокчейна. То есть мы имеем экспоненциальное улучшение. Если сравнивать с отправкой всего блокчейна.

    С точки зрения безопасности нам необходимо сравнить два доказательства NIPoPoW, которые были отправлены двумя верификаторами. Одно NIPoPoW было отправлено злоумышленником, а другое — честной стороной. И нам необходимо узнать, чей блокчейн длиннее, чей исходный блокчейн длиннее. Но для этого необходимо, чтобы все вы понимали, зачем мы делаем всё это с множеством уровней, зачем мы заполняем нижний уровень, используя блоки, находящиеся на уровне выше.

    Итак, мы проводим сравнения после того, как в смарт-контракт будут внесены π1 и π2. π1 и π2 — это просто цепочки блоков, некоторые из которых пропущены, большинство из них пропущено, и смарт-контракт пытается найти общий префикс между этими двумя цепочками. И такой префикс не должен быть пустым. Вот что это обозначает — просто общие блоки между этими двумя блокчейнами. Эти блокчейны будут иметь по крайней мере один общий блок, поскольку у них один общий генезис-блок. И среди этих общих блоков мы находим самый последний. Вот что это значит. Таким образом, из этой цепочки общих блоков между двумя доказательствами мы берём последний. И теперь мы сравниваем их и говорим: «Этот парень прав, а этот ошибается». Один из них обманывает в отношении самого длинного блокчейна. То есть мы берём самый последний общий блок, а затем я использую это странное обозначение, и я попробую объяснить, что оно значит. Для каждого уровня μ… для каждого из двух доказательств π1 и π2 мы берём только часть общего блока. Мы берём часть общего блока и проверяем только один выбранный нами уровень μ, а в качестве μ мы выбираем самый высокий уровень, самую высокую часть блокчейна, в которой есть по крайней мере m блоков. Таким образом, длина доказательства начиная с блока B и дальше на этом уровне μ будет по крайней мере m блоков. Если посмотреть на нашу конструкцию, то становится ясно, что такое всегда можно сделать, и мы доказываем это математически, и я надеюсь, что вам понятно, о чём идёт речь. После того как мы выбираем уровень μ, где это происходит в обоих блокчейнах, мы сравниваем длину после определённого блока. Сравнение длины происходит после общего блока, который обе стороны вычислили независимо друг от друга, и одна из сторон может использовать доказательство работы, которое было сохранено другой стороной. Я понимаю, что формула слишком длинна, чтобы полностью рассмотреть её в рамках короткого выступления, но я надеюсь, что это мотивирует вас к тому, чтобы ознакомиться с подробностями, которые содержатся в наших работах.

    Я пропущу эту часть, но предложу вам некоторые ссылки, чтобы вы могли ознакомиться с подробностями. Итак, прежде всего, это конструкция «Неинтерактивных доказательств доказательства работы». Это статья
    опубликована в Financial Crypto в феврале. В ней приводятся все математические решения, о которых мы говорили, показано, как строятся доказательства, как производится сравнение и почему это безопасно. Затем следуют «Сайдчейны с доказательством работы». По сути, этому была посвящена вся первая часть выступления, которую провёл Костис. В статье рассматривается, как работают смарт-контракты, а опубликована она была в Financial Crypto в прошлом году. Думаю, в ней понятным языком описаны смарт-контракты, и вы даже сможете попробовать реализовать их. Затем следует статья «Доказательство сожжения», в которой рассказывается, как можно уничтожить средства в одном блокчейне и, используя ранее упомянутые механизмы, доказать, что деньги были уничтожены, и перевести их в другой блокчейн. И вот ещё одна интересная работа: «Компактное хранение суперблоков для доказательств NIPoPoW», а также «Применение доказательств NIPoPoW в Bitcoin Cash». Это практический вариант реализации наших идей, который был сделан в Bitcoin Cash. Мы использовали Bitcoin Cash из-за низких комиссий, но это не важно. Вы можете сделать всё в Bitcoin. А мы пока сделали в тестовой сети Bitcoin Cash. По сути, это была диссертация Костиса, и всё было сделано без разработки какого-либо программного обеспечения и без хардфорков, так что это довольно интересная работа. И ещё одна прошлогодняя диссертация, в которой показано, как создаются смарт-контракты Ethereum. В ней также приводятся интересные цифры, свидетельствующие об эффективности расходования газа, если сравнивать с отправкой всего блокчейна.

    Да, я понимаю — слишком много математики, поэтому мы и включили в презентацию эти ссылки, и я надеюсь, вы воспользуетесь ими и погрузитесь в детали того, чем мы занимаемся. У нас также есть сайт, nipopows.com, который вы можете посетить. Там также можно найти все эти ссылки и несколько видео, в которых подробно показано, как всё это можно реализовать. На этом всё. Большое вам спасибо. И сейчас у нас осталось время, чтобы ответить на несколько вопросов.

    Вопрос из зала: Есть ли какая-нибудь формула для вычисления размера залога при размещении средств? Просто я боюсь, что если размещаемая сумма будет слишком велика, если майнер будет работать слишком долго, никто не захочет осуществлять проверку, так как это никогда не будет выгодно, а это, с моей точки зрения, тоже проблема.

    Дионис: Да, это хороший вопрос. Здесь у нас где-то был слайд, связанный с залогами. Посмотрим. Да, здесь есть определённая мотивация — этого должно быть достаточно, чтобы покрыть ложные доказательства. Я согласен с вашим утверждением, что если этого будет недостаточно по экономическим причинам, то никто этого делать не будет — их и так всегда смогут поймать. На BitPaper предлагаются некоторые более эффективные механизмы, придуманные не нами, позволяющие делать это в одностороннем порядке, когда вы можете самостоятельно раскрыть ложное доказательство и получить вознаграждение за его обнаружение. Таким образом, люди стимулируются, чтобы находить их, поскольку это гарантирует, что иногда будут находиться ложные доказательства, которые будут покрываться вознаграждением, но они будут скрываться до момента подобного раскрытия. То есть есть ряд идей, которыми можно воспользоваться. На BitPaper предлагается хорошая конструкция, которую мы не реализовали в рамках этой работы. Но мы планируем сделать это, так что впереди у нас много интересной работы. Спасибо всем за внимание.

    ---

    Источник: Critical Decentralisation Cluster 36c3 - Blockchain Interoperability: NIPoPoWs & Sidechains

    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
    #1 Mr. Pickles, 3 июл 2021
    Последнее редактирование: 27 июл 2021
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.