Файл: Аннотация Цель данной работы предоставить первое описание блокчейнплатформы ton (The Open Network) и связанных с ней технологий одноранговых сетей, распределенного хранилища и хостинга..pdf

ВУЗ: Не указан

Категория: Реферат

Дисциплина: Не указана

Добавлен: 25.10.2023

Просмотров: 234

Скачиваний: 3

ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.

54 2.8. Классификация блокчейн-проектов
Если не ждать достаточно долго, прежде чем передать сообщение, или если форк все равно произойдет по какой-либо другой причине, объединенное состояние двух блокчейнов окажется противоречивым: во второй блокчейн будет доставлено сообщение, которое никогда не было сгенерировано в (окончательно выбранном форке) первом блокчейне.
Иногда добавляется частичная поддержка обмена сообщениями путем стандартизации формата сообщений и расположения очередей входных и выходных сообщений в блоках всех воркчейнов (это особенно полезно в гетерогенных системах). Хотя это в определенной степени облегчает обмен сообщениями, концептуально он не слишком отличается от предыдущего случая, поэтому такие системы все еще являются «слабо-связанными».
Напротив, "тесно-связанные" системы включают специальные механизмы для обеспечения быстрого обмена сообщениями между всеми блокчейнами. Желаемое поведение - иметь возможность доставить сообщение в другой воркчейн сразу после того, как оно было сгенерировано в блоке исходного блокчейна. Также ожидается, что "тесно-связанные" системы будут в целом оставаться непротиворечивыми в случае форков. Хотя на первый взгляд эти два требования кажутся противоречащими друг другу, мы полагаем, что механизмы, использующиеся в блокчейне TON (включение хэшей блоков шардчейна в блоки мастерчейна; использование «вертикальных» блокчейнов для исправления невалидных блоков, см. 2.1.17; маршрутизация в гиперкубе, см. 2.4.19; мгновенная маршрутизация в гиперкубе, см. 2.4.20) делают ее
«тесно-связанной» системой (возможно, пока единственной в своем роде).
Конечно, построить «слабо-связанную» систему намного проще; однако быстрый и эффективный шардинг (см. 2.8.12) требует, чтобы система была «тесно-связанной».
2.8.15. Упрощенная классификация. Поколения блокчейн-проектов. Предложенная нами классификация разбивает все блокчейн-проекты на большое количество классов.
Однако на практике критерии классификации, которые мы используем, довольно сильно коррелируют между собой. Это позволяет нам предложить упрощенный
«поколенческий» подход к классификации блокчейн-проектов как очень грубое приближение к реальности с некоторыми примерами. Проекты, которые еще не реализованы и не развернуты, выделены курсивом; жирным выделены наиболее важные характеристики поколения.
• Первое поколение: Сингл-чейн, PoW, нет поддержки смарт-контрактов.
Примеры: Bitcoin (2009) и множество других не интересующих нас подражателей (Litecoin, Monero, ...).
• Второе поколение: Сингл-чейн, PoW, поддержка смарт-контрактов. Пример:
Ethereum (2013; развернут в 2015), по крайней мере в его оригинальной форме.
• Третье поколение: Сингл-чейн, PoS, поддержка смарт-контрактов. Пример: будущий Ethereum (2018 или позднее).
• Альтернативное третье (3′) поколение: Мульти-чейн, PoS, нет поддержки смарт-контрактов, слабо-связан. Пример: Bitshares (2013–2014; использует
DPOS).
• Четвертое поколение: Мульти-чейн, PoS, поддержка смарт-контрактов, слабо- связан. Примеры: EOS (2017; использует DPOS), PolkaDot (2016; использует
BFT).
• Пятое поколение: Мульти-чейн, PoS и BFT, поддержка смарт-контрактов, тесно-связан, с шардингом. Примеры: TON (2017).
Хотя не все блокчейн-проекты попадают в одну из этих категорий, большинство из них относится к одной из этих категорий.
2.8.16. Сложности изменения «генома» блокчейн-проекта. Приведенная выше классификация определяет «геном» блокчейн-проекта. Этот геном достаточно


55 2.8. Классификация блокчейн-проектов
«жесткий»: его практически невозможно изменить, как только проект развернут и используется большим количеством людей. Потребуется серия хард-форков (что потребует одобрения большинства сообщества), и даже в этом случае изменения должны быть очень консервативными, чтобы сохранить обратную совместимость
(например, изменение семантики виртуальной машины может сломать существующие смарт-контракты). Альтернативой было бы создание новых
«сайдчейнов» с разными правилами и их привязка каким-либо образом к блокчейну
(или блокчейнам) исходного проекта. Можно использовать блокчейн существующего синглчейн-проекта в качестве внешнего мастерчейна для принципиально нового и отдельного проекта
27
Мы пришли к выводу, что геном проекта очень сложно изменить после его развертывания. Даже начать с PoW и планировать его замену на PoS в будущем – это довольно сложная задача
28
. Добавление шардов в проект, изначально созданный без их поддержки, кажется практически невозможным
29
. Фактически, добавление поддержки смарт-контрактов в проект (а именно, Биткоин), изначально разработанный без поддержки таких функций, было сочтено невозможным (или, по крайней мере, нежелательным для большей части сообщества Биткоин) и в конечном итоге привело к созданию нового блокчейн-проекта - Эфириума.
2.8.17. Геном блокчейна TON. Следовательно, если кто-то хочет создать масштабируемую блокчейн-систему, нужно тщательно выбирать ее геном с самого начала. Если система предназначена для поддержки некоторых дополнительных конкретных функций в будущем, неизвестных на момент ее развертывания, она должна изначально поддерживать «гетерогенные» воркчейны (с потенциально разными правилами). Чтобы система была действительно масштабируемой, она должна поддерживать шардинг с самого начала; шардинг имеет смысл только в том случае, если система «тесно-связана» (см. 2.8.14), а это, в свою очередь, подразумевает наличие мастерчейна, быстрой системы обмена сообщениями между блокчейнами, использование BFT PoS и так далее.
Если принять всё это во внимание, большинство дизайнерских решений, сделанных для блокчейн-проекта TON, кажутся естественными и почти единственно возможными.
27
Например, в проекте Plasma планируется использование блокчейна Ethereum в качестве (внешнего) мастерчейна; в противном случае он мало взаимодействует с Ethereum, и он мог быть предложен и реализован командой, не связанной с проектом Ethereum.
28
По состоянию на 2017 год Ethereum все еще пытается перейти от PoW к комбинированной системе
PoW+PoS; мы надеемся, что когда-нибудь Ethereum станет настоящей системой PoS.
29
Предложения по шардингу в Ethereum появились еще в 2015 году; неясно, как их можно реализовать и развернуть, не нарушая работы Ethereum и не создавая по существу независимого параллельного проекта.


56 2.9. Сравнение с другими блокчейн-проектами
Проект
Год
П.
Конс.
Ск.
Ч.
R.
Ш.
Int.
Bitcoin
2009 1
PoW нет
1
Ethereum
2013, 2015 2
PoW да
1
NXT
2014 2+
PoS нет
1
Tezos
2017, ?
2+
PoS да
1
Casper
2015, (2017)
3
PoW/PoS да
1
BitShares
2013, 2014 30
DPoS нет m ht. нет
L
EOS
2016, (2018)
4
DPoS да m ht. нет
L
PolkaDot
2016, (2019)
4
PoS BFT да m ht. нет
L
Cosmos
2017, ?
4
PoS BFT да m ht. нет
L
TON
2017, (2018)
5
PoS BFT да m mix dyn.
T
Таблица 1: Краткое описание некоторых известных блокчейн-проектов. В столбцах представлены следующие параметры: Проект - название проекта; Год - год анонсирования и год развертывания; П. - поколение (ср. 2.8.15); Конс. - алгоритм консенсуса (см. 2.8.3 и 2.8.4); Ск. - поддержка произвольного кода (смарт-контракты; см. 2.8.6); Ч. – сингл-/мульти-блокчейн-система (см. 2.8.2); R. - гетерогенные/гомогенные мультичейн системы (см. 2.8.8); Ш. - поддержка шардинга (см. 2.8.12); Int. - взаимодействие между блокчейнами, (L)oose или (T)ight – слабо-связанные или тесно-связанные системы (см. 2.8.14).
1   ...   6   7   8   9   10   11   12   13   ...   17

2.9. Сравнение с другими блокчейн-проектами
Мы завершаем наше краткое обсуждение блокчейна TON и его наиболее важных и уникальных функций в попытке найти для него место среди существующих и предлагаемых блокчейн-проектов. Мы используем критерии классификации, описанные в п. 2.8, для обсуждения различных проектов блокчейнов и построения своеобразной «карты блокчейн-проектов». Мы представляем эту карту в виде
Таблицы 1, а затем кратко обсуждаем несколько проектов по отдельности, указывая на их особенности, которые могут не вписываться в общую схему.
2.9.1. Биткоин [12]; https://bitcoin.org/. Биткоин (2009) - первый и самый известный блокчейн-проект. Это типичный блокчейн-проект первого поколения: в нём один блокчейн, используется Proof-of-Work с алгоритмом выбора «побеждает самый длинный форк» и нет Тьюринг-полного скриптового языка (однако поддерживаются простые скрипты без циклов). Блокчейн Bitcoin не имеет понятия аккаунтов; вместо этого он использует модель UTXO (Unspent Transaction Output).
2.9.2. Ethereum [2]; https://ethereum.org/. Ethereum (2015) - первый блокчейн с поддержкой Тьюринг-полных смарт-контрактов. Таким образом, это типичный проект второго поколения и самый популярный среди них. Он использует Proof-of-
Work на одном блокчейне, но имеет смарт-контракты и аккаунты.
2.9.3. NXT: https://nxtplatform.org/. NXT (2014) - это первый блокчейн и валюта на основе PoS. Это по-прежнему синглчейн-проект и он не поддерживает смарт- контракты.

57 2.9. Сравнение с другими блокчейн-проектами
2.9.4. Tezos; https://www.tezos.com/. Tezos (2018 или позже) - то предлагаемый синглчейн-проект на основе PoS. Мы упоминаем его здесь из-за его уникальной особенности: его функция интерпретации блока ev_block (см. 2.2.6) не фиксирована, но определяется модулем OCaml, который можно обновить, отправив новую версию в блокчейн (и собрав голоса для предлагаемого изменения). Таким образом, можно создавать собственные синглчейн-проекты, сначала развернув "ванильный" блокчейн
Tezos, а затем постепенно изменяя функцию интерпретации блоков в желаемом направлении, без каких-либо хард-форков.
Эта идея хоть и является интригующей, но имеет очевидный недостаток, заключающийся в том, что она запрещает любые оптимизированные реализации на других языках, таких как C++, поэтому блокчейн на основе Tezos обречен на низкую производительность. Мы думаем, что аналогичный результат можно было бы получить, опубликовав формальную спецификацию предлагаемой функции интерпретации блока ev_trans без закрепления конкретной имплементации.
2.9.5. Casper.
30
Casper - новый алгоритм PoS для Ethereum; его постепенное развертывание в 2017 (или 2018), в случае успеха, превратит Ethereum в синглчейн
PoS или смешанную систему PoW + PoS с поддержкой смарт-контрактов, сделав из
Ethereum проект третьего поколения.
2.9.6. BitShares [8]; https://bitshares.org. BitShares (2014) — это платформа для распределенных бирж на основе блокчейна. Это гетерогенная мультиблокчейн- система
DPoS без смарт-контрактов; она достигает своей высокой производительности, позволяя использовать только небольшой набор предопределенных специализированных типов транзакций, которые могут быть эффективно реализованы на C++ при условии, что состояние блокчейна умещается в памяти. Это также первый блокчейн-проект, в котором используется Delegated Proof- of-Stake (DPoS), демонстрирующий его жизнеспособность, по крайней мере, для некоторых специализированных целей.
2.9.7. EOS [5]; https://eos.io. EOS (2018 или позже) - это предлагаемая гетерогенная мультиблокчейн-система DPoS с поддержкой смарт-контрактов и некоторой минимальной поддержкой обмена сообщениями (система всё ещё слабо-связана в смысле, описанном в п. 2.8.14). Это разработка той же команды, которая ранее создала проекты BitShares и SteemIt, демонстрирующая сильные стороны алгоритма консенсуса DPoS. Масштабируемость будет достигаться за счет создания специализированных воркчейнов для проектов, которые в этом нуждаются (например, распределенная биржа может использовать воркчейн, поддерживающий специальный набор оптимизированных транзакций, аналогично тому, что сделал BitShares) и путем создания нескольких воркчейнов с одинаковыми правилами (конфедерации, см. п.
2.8.10). Недостатки и ограничения этого подхода к масштабируемости обсуждались в loc. cit. Более подробное описание DPoS, шардинга, взаимодействия между воркчейнами и их значение для масштабируемости системы блокчейнов приведено в
2.8.5, 2.8.12 и 2.8.14.
В то же время, даже если никто не сможет «создать Facebook внутри блокчейна» (см.
2.9.13), с помощью EOS или иным способом, мы думаем, что EOS может стать удобной платформой для некоторых узкоспециализированных слабо взаимодействующих распределенных приложений, подобных
BitShares
(децентрализованная биржа) и SteemIt (децентрализованная платформа для блогов).
30
https://blog.ethereum.org/2015/08/01/introducing-casper-friendly-ghost/


58 2.9. Сравнение с другими блокчейн-проектами
2.9.8. PolkaDot [17]; https://polkadot.io/. PolkaDot (2019 или позже) - один из самых продуманных и детально проработанных мультичейн-проектов Proof-of-Stake; его разработкой руководит один из соучредителей Ethereum. Этот проект является одним из самых близких к TON Blockchain на нашей карте. (Фактически, мы обязаны своей терминологией для «фишерменов» и «номинаторов» проекту PolkaDot.)
PolkaDot - это гетерогенный слабо-связанный мультичейн-проект Proof-of-Stake с консенсусом Byzantine Fault Tolerant (BFT) для генерации новых блоков и мастерчейном (который может быть внешним - например, блокчейн Ethereum). Он также использует гиперкубовую маршрутизацию, похожую на (медленную версию) используемую в TON, как описано в п. 2.4.19.
Его уникальная особенность - это возможность создавать не только публичные, но также приватные блокчейны. Эти приватные блокчейны также смогут взаимодействовать с другими публичными блокчейнами, PolkaDot или применять другие способы взаимодействия.
Таким образом, PolkaDot может стать платформой для крупномасштабных приватных блокчейнов, которые могут использоваться, например, банковскими консорциумами для быстрого перевода средств друг другу или для любых других целей, которые крупная корпорация может достичь с технологией приватного блокчейна.
Однако PolkaDot не поддерживает шардинг и не является тесно-связанной системой.
Это несколько затрудняет её масштабируемость, которая примерно аналогична EOS.
(Возможно, в случае PolkaDot ситуация немного лучше, потому что PolkaDot использует BFT PoS вместо DPoS.)
2.9.9. Universa; https://universa.io. Единственная причина, по которой мы упоминаем здесь этот необычный блокчейн-проект, заключается в том, что пока это единственный проект, в котором есть нечто похожее на нашу парадигму бесконечного шардинга (см. 2.1.2).
Другой его особенностью является то, что он обходит все сложности, связанные с
Byzantine Fault Tolerance, обещая, что только доверенные и лицензированные партнеры проекта будут допущены в качестве валидаторов, поэтому они никогда не будут включать невалидные блоки. Это интересное решение; тем не менее, оно, по сути, делает блокчейн-проект намеренно централизованным, чего блокчейн-проекты обычно стараются избегать (зачем вообще нужен блокчейн для работы в доверенной централизованной среде?).
2.9.10. Plasma; https://plasma.io). Plasma (2019?) - отличный от других блокчейн- проект от другого соучредителя Ethereum. Предполагается, что он смягчит некоторые ограничения Ethereum без введения шардинга. По сути, это отдельный от Ethereum проект, представляющий иерархию (гетерогенных) воркчейнов, привязанных к блокчейну Ethereum (для использования в качестве внешнего мастерчейна) на верхнем уровне. Средства могут быть переведены из любого блокчейна вверх по иерархии (начиная с блокчейна Ethereum в качестве корня) вместе с описанием задания, которое необходимо выполнить. Затем в дочернем воркчейне выполняются необходимые вычисления (возможно, требующие пересылки частей исходного задания дальше вниз по дереву), их результаты передаются вверх, и собирается вознаграждение. Проблема достижения согласованности и проверки этих воркчейнов
Проблема достижения непротиворечивости и валидации этих воркчейнов обходится с помощью (основанного на платежном канале) механизма, позволяющего пользователям в одностороннем порядке выводить свои средства из некорректно функционирующего воркчейна в его родительский воркчейн (хотя и медленно) и перераспределять свои средства и свои задания в другой воркчейн.
Таким образом, Plasma может стать платформой для распределенных вычислений, связанных с блокчейном Ethereum, чем-то вроде «математического сопроцессора».