Основные моменты

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

Эта часть — первая запись в серии из нескольких частей, рассказывающей о плазме, написанной Дэниелом Голдманом.

Вступление

Если вы еще не слышали, масштабировать криптовалюту сложно.

В августе 2017 года Виталик Бутерин и Джозеф Пун выпустили Плазменная белая бумагаВнедряя в мир новый, многообещающий подход к увеличению пропускной способности крипто-транзакций и избавлению нас от зла ​​блокчейн-перегрузки. По-видимому, в одночасье Plasma стала самой раскрученной платформой масштабирования Layer 2 в экосистеме Ethereum, а шумиха привела с собой головокружительный хаос, которого мы теперь ожидаем от крипто-пространства — смелые обещания, амбициозные исследования и множество вариантов / предложения / встречные предложения / оптимизации настолько многочисленны, что это в основном стало шутка

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

И в первую очередь: что это, черт возьми?

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

  • теоретические основы плазмы как технологии второго уровня
  • объяснить внутреннюю работу первой конкретной спецификации плазмы «Минимально жизнеспособная плазма»
  • Plasma Cash — вариантная спецификация, которая привлекла большую часть исследований и разработок в области плазменных технологий со времен «MVP»

Обязательный отказ от ответственности: несмотря на то, что не требуется никаких серьезных технических оснований, необходимо придерживаться некоторого базового понимания Ethereum и умных контрактов. Планируйте соответственно.

Фон: слой 2

Семейство протоколов, которое мы называем «Plasma», представляет собой подмножество решений уровня 2 для решения проблемы масштабируемости блокчейна, причем «проблемой» здесь, по сути, является ограниченная пропускная способность транзакций, с которой может справиться открытая, недопустимая блокчейн. Уровень 2 стремится обойти это узкое место, позволяя (некоторым) транзакциям считаться завершенными без необходимости когда-либо касаться самой блокчейна.

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

Общая схема систем уровня 2: изначально некоторые заблокирован на базовом слое блокчейна (здесь мы будем предполагать Ethereum). Затем, некоторые стороны (и не обязательно те же самые стороны, которые внесли депозит) могут затем осуществлять операции вне цепочки с этим капиталом через оверлейную систему, при этом взаимодействуя с основной цепью только изредка (если вообще когда-либо). В любой момент, собственник любого капитала имеет уверенность в своей способности вывести все свои средства обратно на уровень 1.

Определяющим свойством, которое отличает Уровень 2 (как мы используем этот термин) от других внеплановых платежных систем, является то, что, несмотря на избегание постоянного взаимодействия на базовом уровне, транзакции Уровня 2 по-прежнему сохраняют все децентрализованные, ненадежные гарантии безопасности, которые мы ожидаем от Уровень 1. Защищая свои закрытые ключи и запуская необходимое программное обеспечение, вы можете гарантировать хранение ваших собственных средств, независимо от действий или бездействия каких-либо контрагентов — «контрагентов», в том числе других лиц, учреждений, механизмов консенсуса или чего-либо еще это вне вашего контроля, за исключением самой главной цепи. Даже в кошмарном заговорщическом сценарии Truman Show-esque, где все другие пользователи системы тайно вступают в сговор, пытаясь украсть ваши деньги, они потерпят неудачу.

Что делает плазму плазмой

В последние несколько лет исследований и разработок уровня 2 медленно, но верно появилась таксономия, которая позволяет аккуратно разделить механизмы уровня 2 на две категории: «плазма» или «каналы» (как в «государственные каналы»Или« каналы оплаты »). Хотя не все используют эти термины именно таким образом — и, в конечном счете, ни крипто, ни язык сами по себе не имеют высшего совета для официального урегулирования этих определений для нас — мы тем самым предполагаем достаточно широкие определения «плазмы» и «каналов», так что два охватывают все возможные системы уровня 2.

Одним из способов разграничить эти две категории является минимальное количество транзакций в цепочке, которые им требуются: для того, чтобы транзакция канала считалась завершенной, взаимодействие с главной цепью строго не требуется; для плазменной транзакции, один взаимодействие с главной цепью строго необходимо (вещание осуществляется оператором Plasma, а не пользователями, как мы увидим). Причина, по которой Plasma по-прежнему считается подходом масштабирования 2-го уровня (несмотря на необходимость регулярных внутрисетевых транзакций), заключается в том, что каждая транзакция 1-го уровня может эффективно завершаться много сделки одним махом; Вы можете представить, что пакет транзакций уровня 2 сжимается в одну. Тем не менее, само по себе это выглядит как плюсовая сторона ipso facto для каналов; не требуется никаких подтверждений блоков в цепочке, что означает (практически) мгновенную завершенность, и, как правило, меньшее взаимодействие в цепочке — это хорошая вещь.

С другой стороны, канал требует полного согласия всех его участников для любого обновления состояния канала, что означает, что использование единого канала со многими участниками становится крайне непрактичным. Взаимодействие со сторонами, с которыми вы не Разделение канала требует «ретрансляции» транзакций через ваших партнеров по каналу, ограничивая вашу финансовую активность теми, с кем вы можете найти эти пути ликвидности через график сети канала. В Plasma, однако, только отправитель транзакции должен дать согласие, и никакие блокировки / ограничения ликвидности не требуются для всех вовлеченных сторон, чтобы войти, выйти и свободно заключать сделки друг с другом (вопрос «кто должен дать согласие на обновления состояния », оказывается, эквивалентным способом разграничения« каналов »и« плазменных »дихотомий).

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

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

Минимально жизнеспособная плазма

Хотя в оригинальном техническом документе были представлены общие понятия о плазме, он также был широким и дико амбициозным (и длинным, прямо скажем); некоторые из идей, которые он использует — например, дерево вложенных цепей плазмы, — в настоящее время все еще не входят в рамки каких-либо текущих исследований плазмы и в конечном итоге могут даже оказаться невозможными.

Таким образом, первым большим шагом к получению реального рабочего кода — и, возможно, отправной точкой для того, как мы в настоящее время думаем о плазме, — была спецификация, известная как Минимально жизнеспособная плазма (MVP). Как следует из названия, цель здесь состоит в том, чтобы отфильтровать все причудливые функции и перевести вещи в максимально простую рабочую реализацию. «Работа» здесь означает, что она должна просто удовлетворять фундаментальным требованиям плазменной системы 2-го уровня, как определено выше, и только с минимальными функциональными возможностями, а именно, с выплатами от А до Б какого-либо взаимозаменяемого актива (с этого момента мы примем Ether, но это работает точно так же с любым токеном, совместимым с ERC20).

В настоящее время (и только на время!), мы будем игнорировать любые другие недостатки, которые возникают, даже если указанные недостатки глубоко отстой. И действительно, MVP действительно квалифицируется как функциональное плазменное решение! Хотя минусы … ну, вы решаете.

Как мы видели ранее, ключевым свойством Plasma является то, что многие транзакции сжимаются и завершаются, и только одна транзакция попадает в главную цепочку. В MVP «сжатие» осуществляется через дерево Меркле; транзакции сгруппированы и Merklized вниз в корень, и это все, что нужно поместить на уровень 1. Сами транзакции следуют модели UTXO в биткойн-стиле; т. е. они тратят средства, которые отправитель подтверждает право собственности, и создают новые результаты, связанные с публичным адресом своих новых владельцев. Иными словами, плазменная цепь сама по себе является блокчейном! Используя необходимые данные блочного блока Plasma и корневые данные Merkle, пользователи могут подтвердить право собственности на то, что по праву принадлежит им, полагаясь на умный контракт в цепочке Ethereum для обеспечения соблюдения правил и урегулирования всех споров.

Мы будем называть сущность, которая отвечает за процедуру, описанную выше, то есть, рекламировать транзакции, транслировать корень и делиться данными с пользователями — по сути, «производитель блоков» плазмы — как оператор плазмы. Стоит отметить, что сам плазменный механизм совершенно не зависит от того, какую форму принимает этот Оператор; это может быть единая, «централизованная» организация, федеративная боковая цепь, система блочной аттестации, основанная на коле, и т. д. Основная цель построения Plasma состоит в том, чтобы все управление фондами не осуществлялось, и если мы можем получить Plasma чтобы работать, этот фактор должен оставаться неизменным независимо от того, кто производит блоки для нас. Более «децентрализованные» механизмы вполне могут предложить Другой преимущества, которые мы связываем с распределенными одноранговыми системами, т. е. устойчивость к цензуре, отказоустойчивость и т. д., но не связанные с хранением права остаются неизменными. Таким образом, для простоты, мы будем предполагать, что Оператор — это просто единая сущность, что позволяет нам более явно рассуждать о самом механизме плазмы.

С этим мы можем начать проходить жизненный цикл типичной транзакции Plasma и исследовать, как все обрабатывается в различных возможных сценариях.

Во-первых, Алиса помещает Ether в нашу цепочку Plasma, посылая в контракт транзакцию Ether в цепочке, которую Оператор включает в блок Plasma; этот эфир изначально принадлежит Алисе (очевидно) в форме UTXO. Алиса, как обычно, хочет заплатить Бобу (обратите внимание, что самому Бобу необязательно делать какие-либо депозиты в цепочке самому или еще когда-либо.) Для этого она создает транзакцию, которая тратит ее UTXO, и создает новый один для Боба, и отправляет эту транзакцию оператору плазмы. Оператор берет эту транзакцию вместе с набором других (практически не связанных) транзакций, группирует их в один блок Plasma, «мерклизирует» их до своего корня Merkle и отправляет этот корень — и только этот корень — в основную цепочку.

Оператор затем отправляет этот блок плазмы всем пользователям (включая Алису и Боба). Получив последний блок, Алиса и Боб проверяют его на своем конце; эта проверка подразумевает, что сами транзакции действительны и что блок соответствует корневому корню Merkle. Если все это подтвердится, Алиса, Боб и все остальные пользователи смогут продолжить свою жизнь.

Позже Алиса — чувствуя, что ей достаточно этого безумного, скажем, плазменного бизнеса, — решает, что хочет вернуть свои средства обратно в сеть Ethereum. Она инициирует этот «запрос на снятие средств» с помощью транзакции по цепочке (н.б .: этот запрос на снятие средств не требуется разрешение оператора.) В своей транзакции она включает UTXO цепочки плазмы, который она хотела бы снять, а также номер блока плазмы, которому она принадлежит, и путь Меркля, подтверждающий включение. Теперь, прежде чем она получит доступ к своим средствам, она должна подождать, пока пройдет «период споров» (скажем, одну неделю). В течение этого периода другие пользователи могут бросить вызов ее выходу, если обнаружат нечестную игру.

Что приводит нас к:

Счастливый случай: все ведут себя

После инициирования ее выхода другие пользователи просматривают свою копию цепочки Plasma, чтобы проверить и подтвердить, что да, действительно, UTXO, с которой Алиса пытается выйти, на самом деле все еще принадлежит ей. Они также проверяют, что все блоки действительны любым другим способом (хотя, по-видимому, они уже сделали это). Теперь пользователи могут быть уверены, что Алиса уходит только с деньгами, которые по праву принадлежат ей, а средства других пользователей в безопасности. Жизнь может продолжаться.

Несчастный случай: Злая Алиса

Теперь давайте создадим альтернативное окончание предыдущему сценарию: попытка выхода Алисы является «достаточно правильной», чтобы быть изначально принятой умным контрактом — то есть это действительная транзакция с подтверждением Меркле, которое действительно соответствует старому Меркле. root — но на самом деле это двойные расходы; то есть она пытается выйти с тем же UTXO, который отправила Бобу ранее. Увы, Алиса.

Но не важно! У Боба (или любого другого пользователя, но предположим, Боба) есть одна неделя, чтобы действовать; он проверит UTXO Алисы на свою копию цепочки Plasma и заметит, что это двойные расходы. Чтобы доказать злонамеренность, он представляет «доказательство мошенничества» в форме старой транзакции, в которой Алиса ранее потратила UTXO, о которой идет речь, вместе с доказательством Меркле о его включение в плазменный блок. Боб дал криптографическое доказательство того, что Алиса уже потратила эти деньги; она была поймана на месте преступления, и ее попытка снять эти деньги отменена.

Примечание о «Наказаниях»

На этом этапе мы можем захотеть еще каким-то образом наказать Алису за ее покушение на преступление, создав реальную угрозу больших потерь для нее и в идеале не поощряя такого рода поведение с самого начала. Эти механизмы наказания типичны для построения каналов; в Poon-Dryja платежные каналыНапример, (построение канала платежей, которое в настоящее время используется в сети Биткойн Лайтнинг), когда вы пытаетесь обналичить устаревшие транзакции, ваш контрагент получает все средства вашего канала. Хотя такого рода наказание не является строго необходимым ни в плазме, ни в каналах, оно, возможно, является более строгим требованием в плазме; без какого-либо понятия о наказаниях Алиса могла бы просто неоднократно предпринимать попытки ненадлежащего снятия средств, заставляя Боба (или кого-то еще) тратить плату за бензин при каждом ответе. По иронии судьбы, однако, также менее очевидно, как такие наказания могут быть применены в плазме; Чтобы сократить часть средств Алисы в цепочке Plasma, нам нужно было бы определить, какие средства принадлежат ей, что само по себе потребует своего собственного механизма рассмотрения претензий / споров, что приведет нас к рекурсивному кролику, у которого нет проблем отверстие.

Таким образом, плазменные конструкции обычно требуют, чтобы Алиса разместила «выходную связь», когда она пытается уйти. По сути, она говорит: «Я хотел бы вынуть 5 Эфира, а вот 1 Эфир, который вы можете взять у меня, если мой выход окажется мошенническим». Мы свободны установить условия договора — т.е. необходимые размер залога, а также ответный случай нарушения (отдайте залог успешному претенденту в качестве награды, сократите его в забвение, покройте только расходы на газ претендента и т. д.) — и сделайте их снисходительными / драконовскими, как нам угодно ,

Несчастный случай: злой оператор

Пока что все прошло относительно гладко, в основном потому, что мы сделали чрезвычайно упрощенное предположение о том, что у Оператора есть все наши наилучшие интересы в глубине души. Теперь пришло время подумать о немыслимом: что, если Оператор — лжец и вор?

Скажем, например, что Алиса и Боб занимаются своими делами, когда однажды они обнаруживают, что Оператор отправил им блок — с нотариально заверенным в цепочке корнем Merkle — который включает в себя явно недействительную транзакцию, которая тратит, скажем, 90 % всего эфира, имеющегося в цепочке плазмы; Напомним, что Оператор полностью отвечает за производство блоков и, таким образом, теоретически может включать в них все, что он хочет. Хуже того, скажем, что затем Оператор запрашивает снятие по цепочке с использованием этой недействительной транзакции.

В отличие от попытки мошенничества Алисы в «Несчастном деле», которая была попыткой удвоить расходы, эта транзакция происходит из «UTXO», которого даже не должно существовать. Поэтому метод, который мы использовали ранее для оспаривания и отмены этого отзыва, нам недоступен.

Соблазнительно думать, что мы можем создать другой вид защиты от мошенничества, чтобы справиться с этим другим видом неправильного поведения, то есть: «Что если мы требуем, чтобы Оператор доказал существование входного UTXO? И, эээ… если это тоже «из ниоткуда», мы требуем доказательства этого? А потом, ммм …

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

Прежде чем мы объясним решение, стоит остановиться на этом вопросе: поскольку наша цель — избежать наследования любого риска контрагента, мы не могу Предположим, что Оператор (или кто-либо еще) будет вообще надежным в предоставлении любых данных. И, как выясняется, любая попытка каким-либо образом заставить доступность данных (или, аналогично, доказать недоступность данных), не вводя некоторые новый предположение доверия, само по себе безнадежно. Это было названо «эквивалентность ошибок говорящего / слушателяДилемма; Короче говоря, если мы ожидаем, что Кэрол отправит Деррику некоторые данные, и мы окажемся в ситуации, когда Деррик заявляет: «Я никогда не получал данные!», а Кэрол заявляет: «Да, он это сделал, он просто скрывает это сейчас !! У нас нет объективного способа определить, кто из них лжет. Таким образом, наша плазменная модель угроз должна включать возможность Оператора внезапно, без предупреждения, полностью замолчать.

Что теперь? Как мы можем гарантировать, что наш Оператор не закончит средства, которые по праву не принадлежат ему? В этом ужасном случае мы прибегаем к ядерному варианту MVP: учитывая, что мы не можем напрямую предотвратить выход Оператора, мы вместо этого разрешаем всем остальным выйти первым. Интеллектуальный контракт устанавливает очередь выхода, которая гарантирует, что более ранним UTXO будет предоставлен приоритет; таким образом, до тех пор, пока каждый — это верно, буквально каждый — используя цепочку плазмы, отнимает то, что по праву принадлежит им до того, как массовый вывод Оператора будет завершен, весь Эфир, который Оператор сможет украсть, будет истощен, и, следовательно, его лживая попытка потребовать больше чем его доля в конечном итоге будет напрасной.

Теоретически это работает. Пользователи сохраняют свои средства независимо от действий любой другой стороны; это была наша цель. Но давайте будем откровенны: способность злонамеренного Оператора (или, возможно, более вероятного взломанного / скомпрометированного Оператора) — используя не более одной транзакции — заставлять всех пользователей бегать в главную цепочку до истечения времени, далека от идеальной. , На самом деле, в самом худшем случае, если блоки основной цепочки перегружены достаточно долго, пользователи могут быть не в состоянии выйти вовремя и, таким образом, могут буквально потерять свои средства. Число транзакций, требуемых для этого массового выхода, теоретически может быть уменьшено с помощью более продвинутых стратегий выхода — пакетирования многих транзакций в одну посредством агрегации сигнатур — но это все еще нерешенная исследовательская проблема, и даже рабочее решение потребует координации и сотрудничества между пользователями и, таким образом, все равно будет неоптимальным.

Но есть еще один (возможно) еще больший недостаток конструкции MVP, который я деликатно ходил на цыпочках; даже в более счастливых случаях мы требуем, чтобы все пользователи полностью проверить вся цепочка плазмы под себя. Это ставит нас в удобство использования Catch-22; Plasma полезна в той мере, в которой она может расширить пропускную способность транзакций Ethereum, но чем выше пропускная способность транзакций в секунду, предлагаемая цепочкой Plasma, тем больше нагрузка — с точки зрения пропускной способности и памяти — она ​​накладывает на клиентское программное обеспечение пользователей. , Напомним, что ключевым преимуществом конструкции Plasma является простота поддержки многих пользователей; ограничение его только теми, кто может запустить приложение для тяжелых условий, серьезно подрывает его ценностное предложение.

Конечно, мы можем сделать лучше … правильно?

На пути к лучшему

Возвращаясь к уязвимости принудительного массового выхода: если смотреть определенным образом, источник «проблемы» проистекает из взаимозаменяемости рассматриваемого актива. Скажи, что Боб «должен» 5 Эфир; Так как Эфир является взаимозаменяемым активом, нет смысла говорить о том, «каким конкретным 5 Эфирам» он должен. Таким образом, в нашем несчастном случае, когда Оператор выходит с более чем справедливой долей, нет однозначного ответа на вопрос: «Точно, чей Эфир он крадет?» Эфир — это Эфир, поэтому он черпает из коллективного Плазма Эфирного Горшка, который В каком-то смысле причина, по которой все пользователи должны затем выйти со своими средствами.

Так что, если там было какой-то способ указать владельцев каждого конкретного «куска» эфира? Вместо того, чтобы общий баланс эфира в плазменном контракте был представлен в виде одного (большого) числа, представьте, что баланс представляет собой сумму всех номиналов большой стопки неделимых «счетов эфира». Может ли это решить наши проблемы? (И может ли это ввести новые?)

Введите плазменные деньги!

Плазма наличными представляет собой вариант конструкции плазмы, которая с тех пор стала основой многих исследований в сообществе плазмы. Он использует такой же подход «минимальной жизнеспособности», как мы видели в MVP, но начинается с нового ограничения: все активы в цепочке Plasma Cash являются неуглимируемыми токенами. Один из этих NFT (мы будем называть их «монетами») может представлять что угодно: фиксированные номиналы Ether или токен ERC-20, набор токенов ERC-20, помет криптокит, права стать Оператором плазмы. цепочка на 100 блоков (отказ от ответственности: не продумал последствия этого, не пробуйте дома) и т. д. Единственное требование — это то, что он может быть представлен как актив ERC-721 — что, по сути, означает, что это нечто уникальный, который нельзя разделить или объединить.

Plasma Cash отказывается от модели транзакций UTXO в биткойн-эск стиле от MVP; для неуглеводных монет понятие создания новых выходных данных транзакции больше не применяется. Вместо этого каждая монета учитывается в каждом блоке плазмы: наличие монеты указывает на то, что монета сменила владельцев в этом блоке плазмы (то есть Алиса отправила ее Бобу); отсутствие указывает, что у него все еще есть тот же владелец, что и в предыдущем блоке. Таким образом, полная история монеты может быть описана ее отсутствием или присутствием в каждом блоке плазмы, начиная с текущего блока и заканчивая блоком, в котором она была впервые размещена.

Как мы скоро покажем, полная история монеты — это информация, достаточная для ее владельца, чтобы обеспечить право владения, и, как ни странно, в этой модели эта история не должна включать все данные в каждом блоке плазмы: чтобы Боб мог доказать присутствие его монеты в данном блоке ему нужен только путь транзакции Меркле. Однако, чтобы доказать, что монета была не переданный в данном блоке, Боб требует умения доказать отсутствие данных, функция, не поддерживаемая деревьями Merkle, которые мы знаем и любим.

Таким образом, чтобы включить эту возможность «доказательства отсутствия», Plasma Cash использует усиленную конструкцию дерева Merkle Tree, известную как Sparse Merkle Tree. SMT — это деревья Merkle с дополнительной специальной функцией: каждому из листьев дерева (в нашем случае, монетам) присваивается уникальный идентификационный номер, который определяет, где они находятся в дереве. По сути, на них накладывается отсортированный порядок; каждая монета может находиться только в своем выделенном «слоте». Это означает, что если монета отсутствует, мы знаем, где бы он был, если бы он присутствовал, и, таким образом, мы можем доказать его отсутствие с помощью ветви Меркле, которая показывает, что ее слот «пуст» (т. е. равен некоторому нулевому значению — нулю, «неопределенному» и т. д.).

Итак, теперь, когда мы можем доказать как отсутствие, так и присутствие монеты в каждом блоке, мы можем отследить полную историю монеты, которая может выглядеть примерно так:

И так далее. Ключевым выводом является то, что требование к данным для доказательства этой истории состоит только из одного доказательства Merkle размером с кусочек в расчете на блок, в отличие от полного требования плазменных блоков MVP. Плазменный свет клиента обеспечен!

Давайте теперь рассмотрим утверждение, что этой последовательности доказательств Меркле достаточно для нынешнего владельца монеты, чтобы обеспечить свои средства. Другими словами, пока Стив имеет полную историю своей монеты (в форме, описанной выше), он имеет объективную уверенность в том, что:

1) Если / когда он попытается уйти, у него будет соответствующий ответ на любые вызовы.

2) Если / когда кто-либо еще попытается снять свою монету, он сможет оспорить и успешно отменить снятие.

В приведенном выше примере Стив в блоке 505 является собственником монеты. Этот первый важный момент, который следует подчеркнуть, состоит в том, что для того, чтобы он посчитал свой платеж завершенным (в его случае — платеж, который он получил от Билла в блоке 504), он сначала должен был получить и проверить полную историю монеты (то есть, подтвержденную доказательство Меркле в каждом предыдущем блоке). Тогда и только тогда он мог действительно претендовать на право собственности.

Давайте посмотрим на то, что может случиться, и как Стив может отреагировать (кое-что из этого должно показаться знакомым из MVP):

Блок 504 — это место, где Стив владеет монетой, поэтому в основном есть два способа украсть у него: кто-то может претендовать на владение монетой в предыдущем блоке или в последующем блоке.

Так, например, Алиса пытается получить монету, передавая свое «доказательство присутствия» монеты в блоке 501; при этом Алиса косвенно подтверждает, что перевод в блоке 501 является последней действительной транзакцией с монетой, то есть с тех пор она не потратила монету. Стив отвечает по существу так же, как Боб в случае с MVP Unhappy Case; он показывает передачу Алисы Биллу в блоке 502 (обратите внимание, что Стив не может подделать это доказательство, поскольку транзакция включает в себя подпись Алисы.) Алиса поймана в акте, и ее выход отменен. Опять же, поскольку у Стива есть полная история монеты, он знает, что у него есть готовый ответ на любую такую ​​мошенническую попытку выхода.

Теперь предположим, что Алиса пытается выйти из своей монеты в блоке 506, т.е. после блок, который устанавливает право собственности Стива. Обратите внимание, что для того, чтобы ее подтверждение Merkle о включении даже было принято умным контрактом (т. Е. Чтобы Алиса даже зашла так далеко), Оператору пришлось злонамеренно и обманным путем включить недопустимый платеж в блок 506; но, как обычно, мы предполагаем, что Оператор может быть произвольно злонамеренным.

В этом случае Стив отвечает предоставлением своей транзакции на этапе 504; здесь он показывает, что ему принадлежала монета в этом блоке, и косвенно заявляет, что с тех пор он не потратил монету. Теперь Алиса должна предоставить сделку, в которой Стив отправил монету другой стороне, но Стив знает, что она не сможет этого сделать, поскольку он знает, что он не на самом деле тратить монету (и что он, конечно, защищал свои личные ключи своей дорогой жизнью). Итак, еще раз, выход Алисы отменен.

Пока есть некоторые хитрые крайние случаи скрытые под приведенными выше примерами (которые вы можете использовать в качестве домашнего задания), эти игры на выходе отражают суть того, как Plasma Cash применяет свои правила.

Но подождите, это еще не все! Давайте вернемся к тому, что нас заставили называть жалким делом в MVP; Оператор прекращает предоставлять данные блока и затем предпринимает попытку сделать недействительный вывод. Что ж этот время, в Plasma Cash вывод средств состоит из одной монеты. Таким образом, только фактический владелец эта конкретная монета (и этот человек знает, кто они) должен принять меры; с ограничением не-взаимозаменяемости больше нет риска того, что выведенные средства «перетекут» в какой-либо другой кусок пирога с активами в сети. Это приводит к тому, что риск принудительного вывода равен паритету с канальным концентратором; если цепочка Plasma неработоспособна, пользователи (предположительно) в конечном итоге захотят выйти, но больше нет никакого режима паники, чувствительного ко времени фиаско принудительного массового выхода.

далее

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

Означает ли это, что мы нашли плазменную серебряную пулю, которую мы ищем?

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

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

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

Оставайтесь в курсе.

Daniel Goldman is a software engineer, technical consultant, and independent writer. He is based in Brooklyn, New York.

Thanks to Georgios Konstantopoulos for his valuable feedback.

ЭТО МОЖЕТ БЫТЬ ИНТЕРЕСНОЕЩЕ ОТ АВТОРА