Открытая сеть. Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021
 Скачать 0.79 Mb.
|
|
(его производителем), или он должен собирать большинство подписей валидатора с самого начала? Хотя, кажется, 2 4 возможные классы алгоритмов PoS в зависимости от ответов на эти вопросы различие на практике сводится к двум 64 2.8. Классификация блокчейн - проектов основные подходы к PoS. На самом деле большинство современных PoS-алгоритмов, предназначенных для использования в масштабируемых многоцепочечных системах, отвечают на первые два вопроса одинаково: только валидаторы могут создавать новые блоки, и они гарантируют валидность блоков, не требуя, чтобы все полные узлы проверяли валидность всех блоков самостоятельно. Что касается двух последних вопросов, то их ответы оказываются в высшей степени корректными.- lated, оставляя по существу только два основных варианта: ˆ Делегированное доказательство доли (DPOS): Для каждого блока существует общеизвестный назначенный производитель; никто другой не может создать этот блок; новый блок первоначально подписывается только его производящим валидатором. ˆ Византийские отказоустойчивые алгоритмы PoS (BFT): существует известное подмножество валидаторов, любой из которых может предложить новый блок; выбор фактического следующего блока из нескольких предложенных кандидатов, который должен быть проверен и подписан большинством валидаторов перед выпуском на другие узлы, достигаетсяверсия византийского отказоустойчивого консенсусного протокола. 2.8.5. Сравнение DPOS и BFT PoS. Преимущество подхода BFT заключается в том, что вновь созданный блок с самого начала имеет подписи большинства валидаторов, свидетельствующие о его валидности. Еще одним преимуществом является то, что, если большинство валидаторов правильно выполняет консенсусный протокол BFT , вилки вообще не могут появиться. С другой стороны, алгоритмы BFT , как правило, довольно запутаны и требуют больше времени для достижения консенсуса подмножеством валидаторов. Поэтому блоки не могут генерироваться слишком часто. Вот почему мы ожидаем, что блокчейн TON (который является проектом BFT с точки зрения этой классификации) будет производить блок только один раз в пять секунд. На практике этот интервал может быть уменьшен до 2-3 секунд (хотя мы этого не обещаем), но не дальше, если валидаторы разбросаны по всему миру. Преимущество алгоритма DPOS заключается в том, что он довольно прост и понятен. Он может генерировать новые блоки довольно часто, скажем,раз в две секунды, или, может быть, даже раз в секунду, 25 из-за своей зависимости от назначенного блока производители известны заранее. Однако DPOS требует, чтобы все узлы или, по крайней мере, все валидаторы проверяли все полученные блоки, потому что валидатор производит и подписывает новый блок 25 Некоторые люди даже утверждают, что время генерации блоков DPOS составляет полсекунды, что делает не кажется реалистичным, если валидаторы разбросаны по нескольким континентам. 65 2.8. Классификация блокчейн - проектов con проверяет не только относительную валидность этого блока, но и валидность предыдущего блока, на который он ссылается, и всех блоков дальше в цепочке (возможно, до начала периода ответственности текущего подмножества валидаторов). Существует заранее определенный порядок для текущего подмножества валидаторов, так что для каждого блока есть назначенный производитель (т. Е. Ожидается, что валидатор сгенерирует этот блок); эти назначенные производители вращаются циклически. Таким образом, блок сначала подписывается только его производящий валидатор; затем, когда следующий блок добывается, и его производитель выбирает ссылаться на этот блок, а не на одного из его предшественников (в противном случае его блок будет лежать в более короткой цепочке, которая может проиграть самую длинную конкуренцию вилки в будущем), подпись следующего блока по существудополнительная подпись на предыдущем блоке. Таким образом, новый блок постепенно собирает подписи большего количества валидаторов, скажем, двадцать подписей за время, необходимое для генерации следующих двадцати блоков. Полный узел будет либо нужно дождаться этих двадцати подписей, либо валидировать блок сам по себе, начиная с достаточно подтвержденного блока (скажем, двадцать блоков назад), что может быть не так просто. Очевидным недостатком алгоритма DPOS является то, что новый блок (и транзакции, совершенные в нем) достигает того же уровня доверия ( рекурсивная надежность, как обсуждалось в 2.6.28) только после того, как добыто еще двадцать блоков, по сравнению с алгоритмами BFT, которые обеспечивают этот уровень доверия (скажем, двадцать подписей) сразу. Еще одним недостатком является то, что DPOS использует самый длинный подход fork wins для переключения на другие вилки; это делает вилки вполне вероятными, если по крайней мере некоторые производители не производят последующие блоки после интересующего нас (или мы не можем наблюдать эти блоки из-за сетевого раздела или сложной атаки). Мы считаем, что подход BFT, хотя и более сложный в реализации и требующий более длительных временных интервалов между блоками, чем DPOS, лучше адаптирован к тесно связанным (см. 2.8.14) многоцепочечным системам, поскольку другие блокчейны могут начать действовать почти сразу после просмотра зафиксированной транзакции (например, генерации сообщения, предназначенного для них).в новом блоке, не дожидаясь двадцати подтверждений валидности (т. е. следующих двадцати блоков), или не дожидаясь следующих шести блоков, чтобы быть уверенным в отсутствии развилок появляются и верифицируются новые блоки сами по себе (верификация блоков других блокчейнов может стать запретительной в масштабируемой многоцепочечной системе). Таким образом , они могут достичь масштабируемости при сохранении высокой надежности и доступности (см. 2.8.12). С другой стороны, DPOS может быть хорошим выбором для слабосвязанного 66 2.8. Классификация блокчейн - проектов мультицепочечная система, где быстрое взаимодействие между блокчейнами не требуется, например, если каждый блокчейн ( workchain ) представляет собой отдельный распределенный обмен, а взаимодействие между блокчейнами ограничивается редкими передачами токенов из одной рабочей цепочки в другую (или, скорее, торговлей одним альткоином , находящимся в одной рабочей цепочке, на другой в определенное время).ставка приближается к 1 : 1). Это то, что на самом деле сделано в проекте BitShares, который довольно успешно использует DPOS. Подводя итог, хотя DPOS могут генерировать новые блоки и включать в них транзакции быстрее (с меньшими интервалами между блоками), эти транзакции достигают уровня доверия, необходимого для их использования в других блокчейнах и приложениях o-chain как зафиксированных и неизменяемых, гораздо медленнее , чем, скажем, в системах BFT, за тридцать секунд 26 вместо ve. Более быстрое включение транзакции не означает более быстрое обязательство транзакции. Это может стать огромной проблемой, если потребуется быстрое взаимодействие между блокчейнами. В этом случае нужно отказаться от DPOS и вместо этого выбрать BFT PoS. 2.8.6. Поддержка полного кода Тьюринга в транзакциях, т. е. по существу произвольных смарт-контрактов. Блокчейн-проекты обычно собирают некоторые транзакции в своих блоках, которые изменяют состояние блокчейна таким образом, который считается полезным (например, переводят некоторое количество криптовалюты с одного счета на другой). Некоторые блокчейн-проекты могут разрешать только некоторые определенные типы транзакций (например, перевод стоимости с одного счета на другой при условии наличия правильных подписей). Другие могут поддерживать некоторую ограниченную форму сценариев в транзакциях. Наконец, некоторые блокчейны поддерживают выполнение произвольно сложного кода в транзакциях, что позволяет системе (по крайней мере, в принципе) поддерживать произвольные приложения, если производительность системы позволяет. Обычно это связано с полными Тьюринга виртуальными машинами и языками сценариев (это означает , что любая программа, которая может быть написана на любом другом вычислительном языке, может быть переписана для выполнения внутри блокчейна) и смарт-контрактами (которые являются программами, находящимися в блокчейне). Конечно, поддержка произвольных смарт - контрактов делает систему действительно гибкой. С другой стороны, эта гибкость имеет свою цену: код этих смарт-контрактов должен выполняться на какой-то виртуальной машине, и это должно быть сделано каждый раз для каждой транзакции в блоке, когда кто-то хочет 26 Например, EOS, один из лучших проектов DPOS, предложенных на сегодняшний день, обещает 45-секундное подтверждение и задержку взаимодействия между блокчейнами (см. [5], Подтверждение транзакций и латентность участков межцепочечной связи). 67 2.8. Классификация блокчейн - проектов для создания или проверки блока. Это замедляет производительность системы по сравнению со случаем предопределенного и неизменяемого набора типов простых транзакций, которые могут быть оптимизированы путем реализации их обработки на языке, таком как C ++ (вместо некоторой виртуальной машины). В конечном счете, поддержка смарт-контрактов, полных по Тьюрингу, кажется желательной в любом проекте блокчейна общего назначения; в противном случае разработчики проекта блокчейна должны заранее решить, для каких приложений будет использоваться их блокчейн. Фактически, отсутствие поддержки смарт - контрактов в блокчейне биткойнов стало основной причиной создания нового блокчейн - проекта Ethereum. В (гетерогенной; ср. 2.8.8) многоцепочечной системе можно получить лучшее из обоих миров, поддерживая полные по Тьюрингу смарт-контракты в некоторых блокчейнах (т. Е. Рабочих цепочках) и небольшой заранее определенный набор высокооптимизированных транзакций в других. 2.8.7. Классификация многоцепочечных систем. До сих пор классификация была справедлива как для одноцепочечных, так и для многоцепочечных систем. Однако мультицепочечные системы допускают еще несколько классификационных критериев, отражающих взаимосвязь между различными блокчейнами в системе. Теперь обсудим эти критерии. 2.8.8. Типы блокчейнов: гомогенные и гетерогенные системы. В многоцепочечной системе все блокчейны могут быть по существу одного типа и иметь одни и те же правила (т. е. Использовать один и тот же формат транзакций, одну и ту же виртуальную машину для выполнения кода смарт-контракта, совместно использовать одну и ту же криптовалюту и так далее), и это сходство явно используется, нос разными данными в каждом блокчейне. В этом случае мы говорим, что система однородна. В противном случае различные блокчейны (которые в данном случае обычно называются рабочими цепями) могут иметь разные правила . Тогда мы говорим, что система неоднородна. 2.8.9. Смешанные гетерогенно-гомогенные системы. Иногда мы имеем смешанную систему, где существует несколько наборов типов или правил для блокчейнов, но присутствует много блокчейнов с одинаковыми правилами, и этот факт явно используется. Тогда это смешанная гетерогенно-гомогенная система. Насколько нам известно, блокчейн TON является единственным примером такой системы. 2.8.10. Гетерогенные системы с несколькими рабочими цепочками, имеющими одинаковые правила, или конфедерации. В некоторых случаях несколько блокчейнов (работают- 68 2.8. Классификация блокчейн - проектов цепочки) с одинаковыми правилами могут присутствовать в гетерогенной системе, но взаимодействие между ними такое же, как между блокчейнами с разными правилами (т. е. их сходство не используется явно). Даже если кажется , что они используют одну и ту же криптовалюту, на самом деле они используют разные альткоины (независимые воплощения криптовалюты). Иногда можно даже иметь определенные механизмы для конвертации этих альткоинов со скоростью, близкой к 1 : 1. Однако это не делает систему однородной, на наш взгляд, она остается гетерогенной. Мы говорим, что такая разнородная коллекция рабочих цепочек с одинаковыми правилами-это конфедерация. Хотя создание гетерогенной системы, позволяющей создавать несколько рабочих цепочек с одинаковыми правилами (т. Е. конфедерацию), может показаться дешевым способом построения масштабируемой системы, этот подход также имеет много недостатков. получается не большой проект, а скорее множество мелких экземпляров этого проекта. Это похоже на приложение чата (или игру) , которое позволяет иметь не более 50 участников в любой комнате чата (или игры), но масштабируется путем создания новых комнат для размещения большего количества пользователей, когда это необходимо. В результате множество пользователей могут участвовать в чатах или в игре, но можно ли сказать, что такая система действительно масштабируема? 2.8.11. Наличие мастер - цепи, внешней или внутренней. Иногда многосеточный проект имеет выделенную мастер-цепочку (иногда называемую контрольной цепочкой ), которая используется, например, для хранения общей конфигурации системы (набора всех активных блокчейнов, а точнее рабочих цепочек), текущего набора валидаторов (для Proof-of-Stakeсистема) и так далее. Иногда другие блокчейны привязываются к мастер - цепочке, например, фиксируя в ней хэши своих последних блоков (это тоже делает блокчейн TON). В некоторых случаях мастер-цепочка является внешней, что означает, что она не является частью проекта, а какой-то другой уже существующий блокчейн, изначально совершенно не связанный с его использованием новым проектом и агностиком его. Например, можно попытаться использовать блокчейн Ethereum в качестве мастерчейна для внешнего проекта и опубликовать для этого специальные смарт - контракты в блокчейне Ethereum (например, для избрания и наказания валидаторов). 2.8.12. Поддержка шардинга. Некоторые блокчейн-проекты (или системы) имеют встроенную поддержку шардинга, что означает, что несколько (обязательно однородных; см. 2.8.8) блокчейнов рассматриваются как осколки одного (с точки зрения высокого уровня) виртуального блокчейна. Например, можно создать 256 осколков 69 2.8. Классификация блокчейн - проектов блокчейны (shardchains ) с теми же правилами и сохраняют состояние учетной записи ровно в одном выбранном осколке в зависимости от первого байта его account_id . Шардинг-это естественный подход к масштабированию блокчейн-систем, потому что, если он правильно реализован, пользователи и смарт-контракты в системе вообще не должны знать о существовании шардинга. На самом деле, часто хочется добавить шардинг в существующий одноцепочечный проект (например, Ethereum), когда нагрузка становится слишком высокой. Альтернативным подходом к масштабированию было бы использование конфедерации гетерогенных рабочих цепочек, как описано в 2.8.10, позволяющей каждому пользователю хранить свою учетную запись в одной или нескольких рабочих цепочках по своему выбору и переводить средства со своего счета в одной рабочей цепочке на другую рабочую цепочку, когда это необходимо, по существу выполняя операцию обмена альткоинами 1: 1. Недостатки этого подхода уже обсуждались в 2.8.10. Однако шардинг не так просто реализовать быстро и надежно , поскольку он подразумевает множество сообщений между различными цепочками шардов. Например, если счета равномерно распределены между N шардами, и единственными транзакциями являются простые переводы средств с одного счета на другой, то только небольшая часть (1 / N) всех транзакций будет выполняться в рамках одного блокчейна; почти все (1 − 1/N ) транзакции будут включать в себя дваблокчейны, требующие межблочной связи. Если мы хотим, чтобы эти транзакции были быстрыми, нам нужна быстрая система передачи сообщений между шардчейнами. Другими словами, блокчейн-проект должен быть тесно связан в смысле, описанном в 2.8.14. 2.8.13. Динамический и статический шардинг. Шардинг может быть динамическим (если при необходимости автоматически создаются дополнительные шарды) или статическим (когда имеется заданное количество шардов, которое в лучшем случае можно изменить только с помощью хардфорка). Большинство предложений по шардингу статичны; блокчейн TON использует динамическое шардирование (см. 2.7). 2.8.14. Взаимодействие между блокчейнами: слабосвязанные и тесно связанные системы. Мультиблоковые проекты могут быть классифицированы в соответствии с поддерживаемым уровнем взаимодействия между составляющими блокчейнами. Наименьший уровень поддержки - это отсутствие какого-либо взаимодействия между различными блокчейнами. Мы не рассматриваем этот случай здесь, потому что мы бы скорее сказали, что эти блокчейны не являются частями одной блокчейн -системы, а просто отдельными экземплярами одного и того же протокола блокчейна. 70 2.8. Классификация блокчейн - проектов Следующий уровень поддержки-отсутствие какой-либо специальной поддержки обмена сообщениями между блокчейнами, что делает взаимодействие возможным в принципе, но неудобным. Мы называем такие системы слабосвязанными ; в них нужно отправлять сообщения и передавать ценность между блокчейнами, как если бы они были блокчейнами,принадлежащими совершенно отдельным блокчейн-проектам (например, биткойн и Эфириум; представьте, что две стороны хотят обменять некоторые биткойны, хранящиеся в блокчейне биткойнов, на эфиры, хранящиеся в Эфириумеблокчейн). Другими словами, необходимо включить исходящее сообщение (или генерирующую его транзакцию) в блок исходного блокчейна. Затем она (или какая-то другая сторона) должна дождаться достаточного количества подтверждений (например, заданного количества последующих блоков), чтобы считать исходную транзакцию зафиксированной и неизменяемой, чтобы иметь возможность выполнять внешние действия на основе ее существования. Только тогда может быть совершена транзакция, передающая сообщение в целевой блокчейн (возможно, вместе со ссылкой и доказательством существования Merkle для исходной транзакции). Если кто-то не ждет достаточно долго перед передачей сообщения или если форк все равно происходит по какой-то другой причине, объединенное состояние двух блокчейнов оказывается несовместимым: сообщение доставляется во второй блокчейн, который никогда не был сгенерирован в (в конечном счете выбранном форке) первом блокчейне. Иногда добавляется частичная поддержка обмена сообщениями, путем стандартизации формата сообщений и расположения очередей входных и выходных сообщений в блоках всех рабочих цепочек (это особенно полезно в гетерогенных системах). Хотя это в определенной степени облегчает обмен сообщениями, концептуально это не слишком отличается от предыдущего случая, поэтому такие системы все еще слабо связаны . В отличие от этого, тесно связанные системы включают специальные механизмы для обеспечения быстрого обмена сообщениями между всеми блокчейнами. Желаемое поведение-иметь возможность доставить сообщение в другую рабочую цепочку сразу после того, как оно было сгенерировано в блоке исходного блокчейна. С другой стороны, ожидается, что тесно связанные системы также будут поддерживать общую согласованность в случае вилок. Хотя на первый взгляд эти два требования кажутся противоречивыми, мы считаем, что механизмы, используемые блокчейном TON (включение хэшей блоков shardchain в блоки masterchain; использование вертикальных блокчейнов для фиксации недействительных блоков, см. 2.1.17; маршрутизация гиперкубов, см. 2.4.19; Мгновенная маршрутизация гиперкубов, см. 2.4.20) позволяют ей быть тесно связанной системой, возможно, единственной до сих пор. Конечно, построение слабосвязанной системы намного проще; однако, 71 2.8. Классификация блокчейн - проектов быстрое и эффективное сегментирование (см. 2.8.12) требует, чтобы система была жестко связана . 2.8.15. Упрощенная классификация. Поколения блокчейн-проектов. Предложенная нами классификация разбивает все блокчейн - проекты на большое количество классов. Однако используемые нами критерии классификации на практике оказываются вполне коррелированными. Это позволяет нам предложить упрощенный поколенческий подход к классификации блокчейн - проектов, как очень грубое приближение реальности, с некоторыми примерами. Проекты, которые еще не были реализованы и развернуты, выделены курсивом; наиболее важные характеристики поколения выделены жирным шрифтом. ˆ Первое поколение: Single-chain, PoW, без поддержки смарт-контрактов. Примеры: Биткойн (2009) и множество других неинтересных имитаторов (Litecoin, Monero,...). ˆ Второе поколение: одноцепочечная, PoW, поддержка смарт-контрактов. Пример: Ethereum (2013; развернут в 2015), по крайней мере, в своем первоначальном виде. ˆ Третье поколение: одноцепная, PoS, поддержка смарт-контрактов. Пример: future Ethereum (2018 или более поздняя версия). ˆ Альтернативное третье (3) поколение: мультицепочечное, PoS, без поддержки смарт-контрактов, слабо связанное. Пример: Bitshares (2013 2014; использует DPOS). ˆ Четвертое поколение: мультицепная, PoS, поддержка смарт-контрактов, слабосвязанная. Примеры: EOS (2017; использует DPOS), PolkaDot (2016; использует BFT). ˆ Пятое поколение: мультицепочка, PoS с BFT, поддержка смарт-контрактов, тесно связанная, с шардингом. Примеры: TON (2017). Хотя не все блокчейн-проекты попадают именно в одну из этих категорий, большинство из них это делают. 2.8.16. Осложнения изменения генома блокчейн - проекта. Приведенная выше классификация определяет геном блокчейн - проекта. Этот геном довольно жесткий : его практически невозможно изменить, как только проект развернут и используется большим количеством людей. Потребуется серия хардфорков (для чего потребуется одобрение большинства 72 2.9. Сравнение с другими блокчейн-проектами сообщество), и даже тогда изменения должны быть очень консервативными , чтобы сохранить обратную совместимость (например, изменение семантики виртуальной машины может нарушить существующие смарт - контракты). Альтернативой может быть создание новых сайдчейнов с их различными правилами и привязка их каким-то образом к блокчейну (или блокчейнам) исходного проекта. Можно использовать блокчейн существующего проекта с одним блокчейном в качестве внешней мастерчейна для принципиально нового и отдельного проекта. 27 Мы пришли к выводу, что геном проекта очень трудно изменить после его развертывания. Даже начать с PoW и планировать замену его PoS в будущем довольно сложно. 28 Добавление осколков в проект изначально разработанный без поддержки для них кажется практически невозможным. 29 Фактически, добавление поддержки смарт-контрактов в проект (а именно Биткойн) , первоначально разработанный без поддержки таких функций, было признано невозможным (или, по крайней мере, нежелательным большинством биткойн-сообщества) и в конечном итоге привело к созданию нового блокчейн-проекта Ethereum. 2.8.17. Геном блокчейна TON. Поэтому, если вы хотите построить масштабируемую блокчейн-систему, вы должны тщательно выбрать ее геном с самого начала. Если система предназначена для поддержки какой-либо дополнительной специфической функциональности в будущем,неизвестной на момент ее развертывания, она должна поддерживать гетерогенные рабочие цепочки (имеющие потенциально разные правила) с самого начала. Чтобы система была действительно масштабируемой, она должна поддерживать сегментирование с самого начала; сегментирование имеет смысл только в том случае, если система тесно связана (см. 2.8.14), так что это, в свою очередь, подразумевает существование masterchain,быстрой системы обмена сообщениями между блокчейнами, использование BFT PoS и так далее. Если принять во внимание все эти последствия, большинство вариантов дизайна, сделанных для проекта TON Blockchain, кажутся естественными и почти единственно возможными. 27 Например, проект Plasma планирует использовать блокчейн Ethereum в качестве своей (внешней) мастер-цепочки; в противном случае он мало взаимодействует с Ethereum, и он мог бы быть предложен и реализован командой, не связанной с проектом Ethereum. 28 По состоянию на 2017 год Ethereum все еще пытается перейти от PoW к комбинированному PoW+PoS-система; мы надеемся, что когда-нибудь она станет по-настоящему PoS-системой. 29 Существуют предложения по шардингу для Ethereum, относящиеся к 2015 году; неясно, как они могут быть реализованы и развернуты без нарушения Ethereum или создания по существу независимого параллельного проекта. 73 2.9. Сравнение с другими блокчейн-проектами |