Открытая сеть. Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021
 Скачать 0.79 Mb.
|
|
2.1.13. Использование masterchain для обеспечения тесной связи рабочих и шардчейнов. Как только хэш блока shardchain включен в блок masterchain, этот блок shardchain и все его предки считаются каноническими , что означает, что на них можно ссылаться из последующих блоков всех shardchain как на нечто фиксированное и неизменяемое. Фактически, каждый новый блок shardchain содержит хэш самого последнего блока masterchain, и все блоки shardchain, на которые ссылается этот блок masterchain , считаются неизменяемыми новым блоком. По сути, это означает, что транзакция или сообщение, зафиксированные в блоке shardchain, могут быть безопасно использованы в самых следующих блоках других shardchain,без необходимости ждать, скажем, двадцати подтверждений (т. Е. Двадцати блоков, сгенерированных после исходного блока в том же блокчейне) перед пересылкой сообщения или сообщения.выполнение других действий на основе предыдущей транзакции, как это принято в большинстве предлагаемых слабосвязанных систем (см. 2.8.14), таких как EOS. Эта возможность использовать транзакции и сообщения в другом осколкецепочки всего через пять секунд после фиксации-это одна из причин, по которой мы считаем, что наша тесно связанная система, первая в своем роде, сможет обеспечить беспрецедентную производительность (см. 2.8.12 и 2.8.14). 9 2.1. Блокчейн TON как набор 2-х блокчейнов 2.1.14. Хэш блока Masterchain как глобальное состояние. Согласно 2.1.13, хэш последнего блока masterchain полностью определяет общее состояние системы с точки зрения внешнего наблюдателя. Не нужно следить за состоянием всех шардчейнов отдельно. 2.1.15. Генерация новых блоков валидаторами; ср. 2.6. Блокчейн TON использует подход Proof-of-Stake (PoS) для генерации новых блоков в цепочках shardchain и masterchain. Это означает, что существует набор,скажем, до нескольких сотен специальных узлов валидаторов, которые внесли ставки (большое количество монет TON) по специальной транзакции masterchain, чтобы иметь право на генерацию и проверку нового блока. Затем каждому осколку (w, s) детерминированным псевдослучайным образом присваивается меньшее подмножество валидаторов, изменяющееся примерно каждые 1024 блока. Это подмножество валидаторов предлагает и достигает консенсуса относительно того, каким будет следующий блок shardchain, собирая подходящие предлагаемые транзакции от клиентов в новые допустимые кандидаты на блок. Для каждого блока существует псевдослучайно выбранный порядок на валидаторах, чтобы определить, чей блок- кандидат имеет наивысший приоритет для фиксации на каждом ходу. Валидаторы и другие узлы проверяют валидность предложенных кандидатов на блок; если валидатор подпишет недействительного кандидата на блок, он может быть автоматически наказан потерей части или всей своей доли или отстранением от набора валидаторов на некоторое время. После этого валидаторы должны прийти к консенсусу по выбору следующего блока, по существу, с помощью эффективного варианта консенсусного протокола BFT (Византийский отказоустойчивый; ср. 2.8.4), аналогичного PBFT [4] или Honey Badger BFT [11]. Если консенсус достигнут, создается новый блок , и валидаторы делят между собой транзакционные сборы за включенные транзакции плюс несколько вновь созданных (отчеканенных) монет. Каждый валидатор может быть выбран для участия в нескольких подмножествах валидаторов; в этом случае ожидается, что все алгоритмы валидации и консенсуса будут выполняться параллельно. После генерации всех новых блоков shardchain или прохождения таймаута генерируется новый блок masterchain, включающий хэши последних блоков всех shardchain. Это делается консенсусом BFT всех валидаторов. 2 Более подробно о подходе TON PoS и его экономичной модели - pro- описано в разделе 2.6. 2 На самом деле двух третей по ставкам достаточно для достижения консенсуса, но делается попытка соберите как можно больше подписей. 10 2.1. Блокчейн TON как набор 2-х блокчейнов 2.1.16. Форки мастерчейна. Сложность, которая возникает из нашего тесно связанного подхода, заключается в том, что переключение на другую вилку в мастер -цепочке почти обязательно потребует переключения на другую вилку по крайней мере в некоторых из шардчейнов. С другой стороны, пока в masterchain нет вилок , никакие вилки в shardchain даже возможны, потому что никакие блоки в альтернативных вилках shardchain не могут стать каноническими , если их хэши будут включены в блок masterchain. Общее правило заключается в том, что если блок masterchain B является предшественником B, B включает hash Hash (B w, s ) of (w, s)-shardchain block B w, s , и B включает в себя hash Hash (B w, s ) , тогда B w, s должно быть предшественником B w, s ; в противном случае блок B masterchain недействителен. Мы ожидаем, что форки masterchain будут редкими, почти несуществующими, потому что в парадигме BFT, принятой блокчейном TON, они могут произойти только в случае неправильного поведения большинства валидаторов (см. 2.6.1 и 2.6.15), что повлечет за собой значительные потери ставок со стороны акционеров. , никаких истинных вилок в цепочках осколков ожидать не следует. Вместо этого, если обнаружен недопустимый блок shardchain, он будет исправлен с помощью вертикального механизма блокчейна 2-blockchain (см. 2.1.17), который может достичь этой цели без разветвления горизонтального блокчейна (т. Е. shardchain). Тот же механизм может быть использован и для исправления несмертельных ошибок в блоках masterchain. 2.1.17. Исправление недопустимых блоков shardchain. Обычно фиксируются только допустимые блоки shardchain, поскольку валидаторы, назначенные для shardchain, должны достичь византийского консенсуса в две трети, прежде чем новый блок может быть зафиксирован. Однако система должна обеспечивать обнаружение ранее зафиксированных недопустимых блоков и их исправление. Конечно, как только недействительный блок shardchain будет найден либо валидатором (не обязательно назначенным этому shardchain), либо шерманом (любым узлом системы, который сделал определенный депозит, чтобы иметь возможность задавать вопросы о действительности блока; см. 2.6.4), заявление о недействительности и его доказательство будут зафиксированы вмастерчейн и валидаторы, подписавшие недействительный блок , наказываются потерей части своей доли и / или временной приостановкой работы из набора валидаторов (последняя мера важна для случая , когда злоумышленник крадет закрытые ключи подписи в противном случае доброкачественного валидатора). Однако этого недостаточно, поскольку общее состояние системы (блокчейн TON) оказывается недействительным из -за ранее зафиксированного недействительного блока shardchain. Этот недопустимый блок должен быть заменен более новым 11 2.1. Блокчейн TON как набор 2-х блокчейнов действительная версия. Большинство систем достигают этого путем отката к последнему блоку перед недопустимым в этой цепочке шардов и к последним блокам, не затронутым сообщениями , распространяемыми из недопустимого блока в каждой из других цепочек шардов, и создания нового форка из этих блоков. Недостатком такого подхода является то, что большое количество корректных и совершенных транзакций внезапно откатывается, и неясно, будут ли они включены позже вообще. Блокчейн TON решает эту проблему, превращая каждый блок каждой шардчейн и мастерчейн ( горизонтальные блокчейны ) в небольшой блокчейн ( вертикальный блокчейн ) сам по себе, содержащий различные версии этого блока или их различия . Обычно вертикальный блокчейн состоит ровно из одного блока, а шардчейн выглядит как классический блокчейн. Однако, как только недействительность блока подтверждена и зафиксирована в блоке masterchain, вертикальная цепочка недействительного блока может увеличьте новый блок в вертикальном направлении, заменив или отредактировав недопустимый блок. Новый блок генерируется текущим подмножеством валидатора для рассматриваемой цепочки осколков. Правила для того, чтобы новый вертикальный блок был действительным, довольно строгие. В частности, если блок цепочки виртуальных счетов (см. 2.1.2), содержащийся в недопустимом блоке, действителен сам по себе, он должен быть оставлен неизменным новым вертикальным блоком. Как только новый вертикальный блок фиксируется поверх недопустимого блока, его хэш публикуется в новом блоке masterchain (или, скорее, в новом вертикальном блоке, лежащем над исходным блоком masterchain, где первоначально был опубликован хэш недопустимого блока shardchain), и изменения распространяются дальше на любой shardchainблоки, ссылающиеся на предыдущую версию этого блока (например, те, которые получили сообщения из неправильного блока). Это фиксировано путем фиксации новых вертикальных блоков в вертикальных блокчейнах для всех блоков , ранее ссылающихся на неправильный блок; вместо этого новые вертикальные блоки будут ссылаться на самые последние (исправленные) версии. Опять же, строгие правила запрещают изменять цепочки учетных записей, которые на самом деле не являются активными (т. Е. Которые получают те же сообщения, что и в предыдущей версии). Таким образом, фиксация неправильного блока генерирует рябь, которая в конечном итоге распространяется на самые последние блоки всех существующих шардчейнов; эти изменения отражаются и в новых вертикальных блоках мастерчейна. Как только рябь перезаписи истории достигает самых последних блоков, новые блоки shardchain генерируются только в одной версии, являясь преемниками только самых новых версий блоков. Это означает, что они будут содержать ссылки на 12 2.1. Блокчейн TON как набор 2-х блокчейнов правильные (самые последние) вертикальные блоки с самого начала. Состояние masterchain неявно определяет карту, преобразующую хэш первого блока каждого вертикального блокчейна в хэш его последней версии. Это позволяет клиенту идентифицировать и найти любой вертикальный блокчейн по хэшу его самого первого (и обычно единственного) блока. 2.1.18. Тонна монет и мультивалютные рабочие цепи. Блокчейн TON поддерживает до 2 32 различные криптовалюты, монеты или токены, отличающиеся 32-битным идентификатором currency_id . Новые криптовалюты могут быть добавлены специальными транзакциями в masterchain. Каждая рабочая цепочка имеет базовую криптовалюту и может иметь несколько дополнительных криптовалют. Существует одна специальная криптовалюта с currency_id = 0, а именно монета TON (см. Приложение A). Это базовая криптовалюта Workchain Zero. Он также используется для комиссий за транзакции и ставок валидатора. В принципе, другие рабочие цепи могут взимать комиссию за транзакции в других токенах. В этом случае должен быть предусмотрен какой-то смарт-контракт для автоматической конвертации этих транзакционных сборов в монеты TON. 2.1.19. Обмен сообщениями и передача ценностей. Цепочки шардов, принадлежащие к одной или разным рабочим цепочкам, могут отправлять сообщения друг другу. Хотя точная форма разрешенных сообщений зависит от принимающей рабочей цепочки и принимающей учетной записи (смарт-контракт), существуют некоторые общие поля, делающие возможным обмен сообщениями между рабочими цепочками. В частности, каждое сообщение может иметь некоторую ценность в виде определенного количества монет TON и/или других зарегистрированных криптовалют, при условии, что они объявлены приемлемыми криптовалютами принимающей рабочей цепочкой. Простейшей формой такого обмена сообщениями является передача стоимости с одного (обычно не смарт-контракта) счета на другой. 2.1.20. Виртуальная машина TON. Виртуальная машина TON, также сокращенно TON VM или TVM,-это виртуальная машина, используемая для выполнения кода смарт-контракта в мастер-цепочке и в базовой рабочей цепочке. Другие рабочие цепи могут использовать другие виртуальные машины наряду или вместо TVM. Здесь мы перечислим некоторые из его особенностей. Они обсуждаются далее в 2.3.12, 2.3.14 и в других местах. ˆ TVM представляет все данные в виде набора ячеек (TVM) (см. 2.3.14). Каждая ячейка содержит до 128 байтов данных и до 4 ссылок на другие ячейки. Как следствие, все-это мешок с клетками. 13 2.1. Блокчейн TON как набор 2-х блокчейнов (см. 2.5.14), это позволяет TVM работать со всеми данными, относящимися к блокчейну TON, включая блоки и глобальное состояние блокчейна, если это необходимо. ˆ TVM может работать со значениями произвольных алгебраических типов данных (см. 2.3.12), представленными в виде деревьев или направленных ациклических графов ячеек TVM. Однако он не зависит от существования алгебраических типов данных; он просто работает с ячейками. ˆ TVM имеет встроенную поддержку хэш-карт (см. 2.3.7). ˆ TVM - это стековая машина. Его стек хранит либо 64-битные целые числа, либо ссылки на ячейки. ˆ Поддерживается 64-битная, 128-битная и 256-битная арифметика. Все n-битные арифметические операции бывают трех видов: для целых чисел без знака, для целых чисел со знаком и для целых чисел по модулю 2 n (никаких автоматических проверок перетока в последний случай). ˆ TVM имеет целочисленное преобразование без знака и знака из n-бита в m-бит для всех 0 ≤ m, n ≤ 256 с проверкой потока. ˆ Все арифметические операции по умолчанию выполняют проверку потока, что значительно упрощает разработку смарт-контрактов. ˆ TVM имеет арифметические операции multiply-then-shift и shift-then-divide с промежуточными значениями, вычисляемыми в большем целочисленном типе; это упрощает реализацию арифметики с фиксированной точкой. ˆ TVM предлагает поддержку битовых и байтовых строк. ˆ Присутствует поддержка 256-битной криптографии эллиптических кривых (ECC) для некоторых предыдущих кривых, включая Curve25519. ˆ Поддержка пар Вейля на некоторых эллиптических кривых, полезная для быстрой реализации zk-SNARKs, также присутствует. ˆ Присутствует поддержка популярных хэш-функций, в том числе sha256. ˆ TVM может работать с доказательствами Меркля (см. 5.1.9). ˆ TVM предлагает поддержку крупных или глобальных смарт-контрактов. Такие смарт -контракты должны быть осведомлены о шардинге (см. 2.3.18 и 2.3.16). Обычные (локальные) смарт-контракты могут быть шардинг-агностическими. 14 2.2. Общие положения о блокчейнах ˆ TVM поддерживает закрытие. ˆ Бесхребетная G-машина [13] может быть легко реализована внутри TVM. В дополнение к сборке TVM можно разработать несколько языков высокого уровня . Все эти языки будут иметь статические типы и будут поддерживать алгебраические типы данных. Мы рассматриваем следующие возможности: ˆ Java-подобный императивный язык, с каждым смарт-контрактом, напоминающим отдельный класс. ˆ Ленивый функциональный язык (подумайте о Haskell). ˆ Нетерпеливый функциональный язык (подумайте о ML). 2.1.21. Контролируемые параметры. Важной особенностью блокчейна TON является то, что многие его параметры контролируются. Это означает, что они являются частью состояния masterchain и могут быть изменены определенными специальными транзакциями предложения / голосования / результата в masterchain без какой-либо необходимости в хардфорках. Изменение таких параметров потребует сбора двух третей голосов валидаторов и более половины голосов всех остальных участников, желающих принять участие в голосовании за предложение. 2.2 Общие положения о блокчейнах 2.2.1. Общее определение блокчейна. В общем случае любой (истинный) блокчейн представляет собой последовательность блоков, каждый блок B содержит ссылку blk- prev(B) на предыдущий блок (обычно путем включения хэша предыдущего блока в заголовок текущего блока) и список транзакций. Каждая транзакция описывает некоторую трансформацию глобального состояния блокчейна; транзакции , перечисленные в блоке, применяются последовательно для вычисления нового состояния, начиная со старого состояния, которое является результирующим состоянием после оценки предыдущего блока. 2.2.2. Актуальность для блокчейна TON. Напомним, что блокчейн TON-это не настоящий блокчейн, а набор 2-блокчейнов (т. е. блокчейнов блокчейнов; ср. 2.1.1), поэтому вышесказанное к нему напрямую не применимо . Однако мы начинаем с этих обобщений на истинных блокчейнах, чтобы использовать их в качестве строительных блоков для наших более сложных конструкций. 15 2.2. Общие положения о блокчейнах 2.2.3. Экземпляр и тип блокчейна. Слово блокчейн часто используется для обозначения как общего типа блокчейна, так и его конкретных экземпляров, определяемых как последовательности блоков, удовлетворяющих определенным условиям. Например, 2.2.1 относится к экземплярам блокчейна. Таким образом, тип блокчейна обычно является подтипом типа Block ∗ списков (т. е. конечных последовательностей) блоков, состоящих из тех последовательностей блоков , которые удовлетворяют определенным условиям совместимости и валидности: Блокчейн ⊂ Блок ∗ (1) Лучший способ определить блокчейн-это сказать, что блокчейн-это зависимый тип пары, состоящий из пар ( B , v) , с первым компонентом B : Блок ∗ быть типа Блок ∗ (т. е. список блоков), а второй компонент v : isValidBc( B ) быть доказательством или свидетелем действительности B . Таким образом, Блокчейн ≡ Σ ( B : Блок ∗ ) isValidBc( B ) (2) Мы используем здесь обозначения для зависимых сумм типов, заимствованных из [16]. 2.2.4. Теория зависимых типов, Coq и TL. Обратите внимание, что мы используем здесь теорию зависимых типов(Martin-Löf), аналогичную той, которая используется в Coq 3 помощник по доказательствам. Упрощенная версия теории зависимых типов также используется в TL (Type Language), 4 который будет использоваться в формальной спецификации блокчейна TON для описания сериализации всех структур данных и компоновок блоков, транзакций и тому подобного. Фактически, теория зависимых типов дает полезную формализацию того, что такое доказательство , и такие формальные доказательства (или их сериализации) могут пригодиться , например, когда нужно предоставить доказательство недействительности для некоторого блока. |