5.1.9. TON VM поддерживает интеллектуальные платежные каналы.
Виртуальная машина TON, используемая для запуска кода смарт-контрактов TON
Blockchain
, способна выполнять смарт-контракты , необходимые для интеллектуальных или сложных платежных каналов (см. 5.1.8).
В этот момент парадигма "все-мешок клеток" (см. 2.5.14) становится чрезвычайно удобной. Поскольку все блоки (включая блоки
блокчейна эфемерного платежного канала) представлены в виде пакетов ячеек (и описываются некоторыми алгебраическими типами данных), а также для сообщений и доказательств Меркла, доказательство Меркла может быть легко встроено в 116 5.1. Платежные каналы входящее сообщение отправляется в платежный канал смарт-контракта. Условие хэша доказательства Меркла будет проверено автоматически, и когда смарт-контракт получит доступ к представленному доказательству Меркла, он будет работать с ним, как если бы это было значение соответствующего алгебраического типа данных, хотя и неполное, с некоторыми поддеревьями дерева, замененными специальными узлами, содержащими хэш Меркла опущенногоподдерево. Тогда смарт-контракт будет работать с этим значением, которое может представлять собой, например, блок платежного чанаnel (виртуальный) блокчейн вместе с его состоянием и будет оценивать функцию ev_block (см. 2.2.6) этого блокчейна в этом блоке и предыдущем состоянии. Тогда либо вычисление завершается, и конечное состояние может быть сравнено с утвержденным в блоке, либо при попытке доступа к отсутствующему поддереву возникает исключение отсутствующего узла, указывающее на то, что доказательство Меркля недействительно. Таким образом, реализация кода проверки для блокчейнов смарт -платежных каналов оказывается довольно простой с использованием смарт-контрактов TON Blockchain. Можно сказать, что виртуальная машина TON поставляется со встроенной поддержкой проверки валидности других простых блокчейнов. Единственным ограничивающим фактором является размер доказательства Merkle, которое должно быть включено во входящее сообщение в смарт-контракт (т. Е. В транзакцию). 5.1.10. Простой платежный канал внутри интеллектуального платежного канала. Мы хотели бы обсудить возможность создания простого (синхронного или асинхронного) платежного канала внутри существующего платежного канала. Хотя это может показаться несколько запутанным, его не намного сложнее понять и реализовать,чем обещания, обсуждаемые в 5.1.7. По сути, вместо того, чтобы обещать заплатить c монет другой стороне, если будет представлено решение какой -либо хэш-проблемы, A обещает заплатить до c монет B в соответствии с nalрасчет какого-то другого (виртуального) платежного канала блокчейн. Вообще говоря, этот другой платежный канал blockchain даже не должен быть между A и B; он может включать некоторые другие стороны, скажем, C и D, желающие передать монеты c и d в свой простой платежный канал соответственно. (Эта возможность используется позже в 5.2.5.) Если охватывающий платежный канал асимметричен, два обещания должны быть зафиксированы в двух рабочих цепочках: A пообещает заплатить монеты −δ B, если окончательное урегулирование внутреннего простого платежного канала приведет к отрицательному конечному дисбалансу δ с 0 ≤ - δ ≤ c; и B должен будет пообещатьобратите δ на A, если δ положительно. С другой стороны, если охватывающее 117 5.2. Сеть платежных каналов, или Lightning Network платежный канал симметричен, это можно сделать, совершив одну простую транзакцию создания платежного канала с параметрами (c, d) в блокчейн единого платежного канала по A (которая заморозит c монет , принадлежащих A), а затем совершив специальную транзакцию подтверждения по B (которая заморозит d монетиз B). Мы ожидаем, что внутренний платежный канал будет чрезвычайно простым (например, простой синхронный платежный канал, обсуждаемый в 5.1.3), чтобы минимизировать размер доказательств Меркля, которые будут представлены. Внешний платежный канал должен быть интеллектуальным в смысле, описанном в 5.1.7. 5.2 Сеть платежных каналов, или Lightning Network Теперь мы готовы обсудить Lightning network платежей TON, которая позволяет мгновенные денежные переводы между любыми двумя участвующими узлами. 5.2.1. Ограничения платежных каналов. Платежный канал полезен для сторон, которые ожидают много денежных переводов между ними. Однако, если нужно перевести деньги только один или два раза конкретному получателю, создание платежного канала с ней было бы нецелесообразно. Помимо прочего, это означало бы замораживание значительной суммы денег в платежном канале и в любом случае потребовало бы как минимум двух транзакций блокчейна. 5.2.2. Сети платежных каналов или сети Lightning . Сети платежных каналов преодолевают ограничения платежных каналов, позволяя осуществлять денежные переводы по цепочкам платежных каналов. Если A хочет перевести деньги на E, ей не нужно устанавливать платежный канал с E. Было бы достаточно иметь цепочку платежных каналов, связывающих A с E через несколько промежуточных узлов, скажем, четыре платежных канала: от A до B , от B до C, от C до D и от D до E. 5.2.3. Обзор сетей платежных каналов. Напомним, что сеть платежных каналов, известная также как lightning network, состоит из набора участвующих узлов, некоторые из которых установили между собой долгоживущие платежные каналы. Вскоре мы увидим, что эти платежные каналы должны быть умными в смысле 5.1.7. Когда участвующий узел A хочет перевести деньги любому другому участвующему узлу E, он пытается найти путь, связывающий A с E внутри сети платежных каналов. Когда такой путь найден, она выполняет цепной денежный перевод по этому пути. 118 5.2. Сеть платежных каналов, или Lightning Network 5.2.4. Цепочка денежных переводов. Предположим, что существует цепочка платежных каналов от A до B, от B до C, от C до D и от D до E. Предположим далее, что A хочет перевести x монет в E. Упрощенным подходом было бы перевести x монет B по существующему платежному каналу и попросить его переслать деньги дальше в C. Однако непонятно, почему B просто не взял бы деньги для себя. Поэтому необходимо использовать более сложный подход, не требующий от всех вовлеченных сторон доверия друг другу. Это может быть достигнуто следующим образом. A генерирует большое случайное число u и вычисляет его хэш v = Hash (u). Затем она создает обещание заплатить x монеты в B если представлено число u с хэшем v (ср. 5.1.7), то внутри нее платежный канал с B. Это обещание содержит v, но не u, который до сих пор держится в секрете. После этого B создает аналогичное обещание C в своем платежном канале. Он не боится дать такое обещание, потому что знает о существовании подобного обещания, данного ему А. Если C когда-либо представит решение хэш -задачи для сбора x монет, обещанных B, то B немедленно отправит это решение A для сбора x монет от A. Затем создаются аналогичные обещания от C до D и от D до E. Когда все обещания выполнены, A запускает передачу, сообщая решение u всем вовлеченным сторонам или только E. Некоторые незначительные детали в этом описании опущены. Например, эти обещания должны иметь разное время истечения срока действия, и обещанная сумма может незначительно отличаться по цепочке (B может обещать только x − монеты для C , где это небольшая предварительно согласованная транзитная плата). Такие детали мы пока игнорируем, потому что они не слишком актуальны для понимания того, как работают платежные каналы и как их можно реализовать в TON. 5.2.5. Виртуальные платежные каналы внутри цепочки платежных каналов. Теперь предположим,что A и E ожидают сделать много платежей друг другу. Они могут создать новый платежный канал между ними в блокчейне, но это все равно будет довольно дорого, потому что некоторые средства будут заблокированы в этом платежном канале. Другим вариантом было бы использовать цепные денежные переводы , описанные в 5.2.4 для каждого платежа. Однако это потребует большой сетевой активности и большого количества транзакций в виртуальных блокчейнах всех задействованных платежных каналов. Альтернативой является создание виртуального платежного канала внутри цепочки , связывающей A с E в сети платежных каналов. Для этого A и E создают 119
5.2. Сеть платежных каналов, или Lightning Network
(виртуальный) блокчейн для их платежей, как если бы они собирались создать платежный канал в блокчейне. Однако вместо создания смарт-контракта платежного канала в блокчейне они запрашивают все промежуточные платежные каналы, которые связывают A с B, B с C и т. Д. создать внутри них простые платежные каналы, привязанные к виртуальному блокчейну, созданному A и E
(см. 5.1.10). Другими словами, теперь обещание перевести деньги в соответствии с окончательным расчетом между A и E существует внутри каждого промежуточного платежного канала.
Если виртуальный платежный канал является однонаправленным, то такие обещания могут быть реализованы довольно легко, поскольку конечный дисбаланс δ будет непозитивным, поэтому простые платежные каналы могут быть созданы внутри промежуточных платежных каналов в том же порядке, что и описано в 5.2.4.
Таким же образом можно установить и время их истечения.
Если виртуальный платежный канал является двунаправленным, ситуация несколько сложнее. В этом случае следует разделить обещание перевести δ монет в соответствии с окончательным расчетом на две половины-обещания, как объяснено в 5.1.10: перевести δ
−
= max (0, - δ) монеты в прямом направлении, и к передача δ
+
= max (0, δ) в обратном направлении. Эти полуобещания могут быть созданы в промежуточных платежных каналах независимо, одна цепочка полуобещаний в направлении от А до Е, а другая цепочка в противоположном направлении.
5.2.6. Поиск путей в сети Lightning.
До сих пор остается неясным один вопрос: как A и E найдут путь, соединяющий их в платежной сети? Если платежная сеть не слишком велика, можно использовать OSPF- подобный протокол: все узлы платежной сети создают оверлейную сеть (см. 3.3.17), а затем каждый узел распространяет всю доступную информацию о канале (т. Е. участвующем платежном канале) своим соседям по протоколу сплетен. В конечном итоге все узлы будут иметь полный список всех платежных каналов
, участвующих в платежной сети, и смогут найти самый короткий пути сами по себе, например, применяя версию алгоритма Дейкстры, модифицированную для учета пропускной способности задействованных платежных каналов (т. е. максимальных сумм, которые
могут быть переведены по ним).
Как только путь-кандидат найден, его можно прощупать специальной дейтаграммой ADNL, содержащей полный путь, и попросить каждый промежуточный узел подтвердить существование рассматриваемого платежного канала и переслать эту дейтаграмму дальше в соответствии с путем. После этого может быть построена цепочка и протокол для цепных переводов (см. 5.2.4) или для создания виртуального платежа
120 5.2. Сеть платежных каналов, или Lightning Network канал внутри цепочки платежных каналов (см. 5.2.5) может быть запущен.
5.2.7. Оптимизация. Некоторые оптимизации могут быть сделаны здесь.
Например, только транзитные узлы сети lightning должны участвовать в
OSPF-подобном протоколе, обсуждаемом в 5.2.6. Два конечных узла, желающих подключиться через сеть lightning, будут передавать друг другу списки транзитных узлов, к которым они подключены (т. Е. С которыми они установили платежные каналы, участвующие в сети Lightning).платежная сеть). Затем пути
, соединяющие транзитные узлы из одного списка с транзитными узлами из другого списка, могут быть проверены, как описано выше в 5.2.6.
5.2.8. Заключение. Мы рассказали, насколько блокчейн и сетевые технологии проекта TON адекватны задаче создания TON
Payments-платформы для мгновенных денежных переводов и микроплатежей o-chain
. Эта платформа может быть чрезвычайно полезна для сервисов, находящихся в экосистеме TON, позволяя им легко собирать микроплатежи, когда и где это необходимо.
121
Заключение
Заключение
Мы предложили масштабируемую мультиблоковую архитектуру, способную поддерживать массово популярную криптовалюту и децентрализованные приложения с удобными интерфейсами.
Для достижения необходимой масштабируемости мы предложили блокчейн TON- тесно связанную мультиблоковую систему (см. 2.8.14) с восходящим подходом к шардингу (см. 2.8.12 и 2.1.2). Для дальнейшего повышения потенциальной производительности мы ввели механизм 2-blockchain для замены недействительных блоков (ср. 2.1.17) и мгновенную маршрутизацию гиперкуба для более быстрой связи между шардами (ср. 2.4.20). Краткое сравнение блокчейна TON с существующими и предлагаемыми блокчейн - проектами (см. 2.8 и 2.9) подчеркивает преимущества такого подхода для систем, которые стремятся обрабатывать миллионы транзакций в секунду.
Сеть TON, описанная в главе 3, охватывает сетевые требования предлагаемой инфраструктуры с несколькими блокчейнами. Этот сетевой компонент также может быть использован в сочетании с блокчейном для создания широкого спектра приложений и сервисов, что невозможно при использовании только блокчейна
(см. 2.9.13). Эти сервисы, рассмотренные в главе 4, включают TON DNS, сервис для преобразования идентификаторов удобочитаемых объектов в их адреса;
TON Storage, распределенную платформу для хранения произвольных файлов; TON Proxy, сервис для анонимизации доступа к сети и доступа к сервисам на базе TON; и TON Payments (см. главу 5), платформа для мгновенных денежных переводов по цепочке o через экосистему TON, которую приложения могут использовать для микроплатежей.
Инфраструктура TON позволяет использовать специализированные приложения light client wallet и tonbrowser для настольных компьютеров и смартфонов, которые обеспечивают браузерный опыт для конечного пользователя (см. 4.3.23), делая криптовалютные платежи и взаимодействие со смарт-контрактами и другими сервисами на платформе TON доступными для массового пользователя.
122
Ссылки
Ссылки
[1] К. Бирман, Надежные распределенные системы: технологии, веб-сервисы и приложения, Springer, 2005.
[2] В. Бутерин, Ethereum: смарт-контракт следующего поколения и de- централизованная платформа приложений, https://github.com/ethereum/wiki/wiki/White-
Paper
, 2013.
[3] М. Бен-Ор, Б. Кельмер, Т. Рабин, Асинхронные безопасные вычисления- системы с оптимальной устойчивостью, в Трудах тринадцатого ежегодного симпозиума ACM по принципам распределенных вычислений, стр. 183 192. АКМ,
1994.
[4] М. Кастро, Б. Лисков и др., Практическая византийская отказоустойчивость,
Proceedings of the Third Symposium on Operating Systems Design and
Implementation (1999), p. 173 186, available at http://pmg.csail.mit. edu/papers/osdi99.pdf.
[5] ЭОС.IO, EOS.Техническая белая книга IO, https://github.com/EOSIO/
Документация / blob / master / TechnicalWhitePaper. md, 2017.
[6] D. Goldschlag, M. Reed, P. Syverson, Onion Routing for Anony- mous and Private Internet Connections, Communications of the ACM,
42, num. 2 (1999), http://www.onion-router.net/Publications/CACM-1999.pdf
[7] Л. Лэмпорт, Р. Шостак, М. Пиз, Проблема византийских генералов,
ACM Transactions on Programming Languages and Systems, 4/3 (1982), p. 382 401.
[8] С. Лаример, История BitShares, https://docs.bitshares.org/ bitshares/history.html, 2013.
[9] M. Luby, A. Shokrollahi и др., прямая коррекция ошибок RaptorQ схема доставки объекта, IETF RFC 6330, https://tools.ietf.org/html/rfc6330
, 2011.
[10] П. Маймунков, Д. Мазьер, Кадемлия: Одноранговая информация-
mation system based on the XOR metric, in IPTPS ' 01 revised papers from the First International Workshop on Peer-to-Peer Systems, 123 Ссылки стр. 53 65, доступно по адресу http://pdos.csail.mit.edu/petar/papers/ maymounkov-kademlia-lncs.pdf, 2002. [11] A. Miller, Yu Xia, et al., The honey badger of BFT protocols, Cryptology e-print archive 2016/99, https://eprint.iacr.org/2016/ 199.pdf, 2016. [12] С. Накамото, Биткойн: одноранговая электронная денежная система, https: //bitcoin.org/bitcoin.pdf, 2008. [13] С. Пейтон Джонс, Реализация ленивых функциональных языков на складе аппаратное обеспечение: бесхребетная G-машина, Журнал функционального программирования 2 (2), стр. 127 202, 1992. [14] A. Shokrollahi, M. Luby, Raptor Codes, IEEE Transactions on Теория информации 6, № 3 4 (2006), с. 212 322. [15] М. ван Стин, А. Таненбаум, Распределенные системы, 3-е изд., 2017. [16] Программа унивалентных основ, теория гомотопических типов: Унивалентные основы математики, Институт повышения квалификации, 2013, доступно по адресу https://homotopytypetheory.org/book. [17] Г. Вуд, Полкадо: видение гетерогенной многоцепочечной структуры- работа, проект 1, https://github.com/w3f/polkadot-white-paper/raw/master/PolkaDotPaper.pdf , 2016. 124 Приложение A. Монета TON A Монета TON Основной криптовалютой блокчейна TON, и в частности его мастер - цепи и базовой рабочей цепи, является монета TON. Он используется для внесения депозитов, необходимых для того,чтобы стать валидатором; транзакционные сборы, платежи за газ (т. Е. Плата за обработку сообщений смарт-контракта) и постоянные платежи за хранение также обычно собираются в монетах TON. A. 1. Подразделение и терминология. Тонна монет подразделяется на один миллиард (10 9 ) меньшие единицы, называемые нанотонами, нтонами или просто нанонами. Все переводы и остатки на счетах выражаются в виде неотрицательных целых чисел, кратных nanos. Другие единицы включают: ˆ Нано, нтон или нанотон-это наименьшая единица, равная 10 −9 Тонна монет. ˆ Микро или микротон равен одной тысяче (10 3 ) нанос.
ˆ
Милли - это миллион (10 6
) нано, или одна тысячная часть (10
−3
) из
ТОННАЯ монета.
ˆ
Тонна монет равна одному миллиарду (10 9
) нанос.
ˆ
Килотонна, или кТон, равна одной тысяче (10 3
) Тонна монет.
ˆ
Мегатонна, или МТон, равна одному миллиону (10 6
) ТОННА монет, или 10 15 нанос.
ˆ
Наконец, гигатонна, или ГТон, равна миллиарду (10 9
) ТОННА монет, или 10 18 нанос.
Не будет никакой потребности для более больших блоков, потому что начальная поставка
ТОННЫ количество монет будет ограничено пятью миллиардами (5 * 10 9
) ТОННА монет (т. е. 5 гигатонн).
A. 2. Меньшие единицы для выражения цен на газ. Если возникает необходимость в меньших единицах, то пятнышки равны 2
−16 будут использованы нанотоны. Например, цены на газ могут быть указаны в крапинках. Однако фактическая плата, подлежащая уплате, рассчитанная как произведение цены газа и количества потребленного газа, всегда будет округлена до ближайшего кратного 2 16 пятнышки и выраженные как целое число нано.
125
Приложение A. Монета TON
A. 3. Первоначальные поставки, награды за добычу полезных ископаемых и инвестиции. Общий запас тонных монет первоначально ограничен 5 гигатоннами (т. е. пятью миллиардами тонных монет или 5 * 10 18 нанос).
Это предложение будет увеличиваться очень медленно, так как награды валидаторам за майнинг
новых блоков masterchain и shardchain накапливаются. Эти вознаграждения составят примерно 20% (точное количество может быть скорректировано в будущем) от ставки валидатора в год, при условии, что валидатор добросовестно выполняет свои обязанности, подписывает все блоки, никогда не выходит из строя и никогда не подписывает недействительные блоки. Таким образом, у валидаторов будет достаточно прибыли, чтобы инвестировать в лучшее и более быстрое оборудование, необходимое для обработки постоянно растущего количества транзакций пользователей. Мы ожидаем, что не более 10% 35 из общего предложения монет TON, в среднем, будут привязаны к ставкам валидатора в любой данный момент. Это приведет к росту инфляции на 2% в год и, как следствие, удвоит общее предложение тонных монет (до десяти гигатонн) за 35 лет. По сути, эта операция представляет собой платеж, произведенный всеми членами сообщества валидаторам за поддержание системы в рабочем состоянии. С другой стороны, если валидатор пойман на неправильном поведении, часть или вся его доля будет отобрана в качестве наказания, а большая ее часть впоследствии будет сожжена , уменьшая общий запас монет TON. Это привело бы к гибели. Меньшая часть ne может быть перераспределена валидатору или шерману, который совершил доказательство неправильного поведения виновного валидатора. 35 Максимальная общая сумма ставок валидатора является регулируемым параметром blockchain, поэтому это ограничение может быть применено протоколом при необходимости. 126 |
Скачать 0.79 Mb.