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

88 5.1. Каналы оплаты этом блоке и предыдущем состоянии. Затем либо вычисление завершается, и конечное состояние может быть сравнено с тем, что заявлено в блоке, либо при попытке доступа к отсутствующему поддереву выдается исключение «отсутствующий узел», указывающее, что доказательство Меркла недействительно.
Таким образом, реализация кода проверки для блокчейнов «умных» платежных каналов оказывается довольно простой при использовании смарт-контрактов блокчейна TON. Можно сказать, что виртуальная машина TON имеет встроенную поддержку для проверки валидности других простых блокчейнов. Единственным ограничивающим фактором является размер доказательства Меркла, которое должно быть включено во входящее сообщение для смарт-контракта (т. е. в транзакцию).
5.1.10. Простой платежный канал в «умном» платежном канале. Мы хотели бы обсудить возможность создания простого (синхронного или асинхронного) платежного канала внутри существующего платежного канала.
Хотя это может показаться несколько запутанным, эту схему не намного сложнее понять и реализовать, чем «обещания», описанные в 5.1.7. По сути, вместо обещания заплатить c монет другой стороне, если присутствует некоторое решение задачи с хешем, A обещает выплатить B до c монет в соответствии с окончательным расчетом некоторого другого (виртуального) блокчейна платежного канала. Вообще говоря, этот блокчейн другого платежного канала даже не обязательно должен находиться между A и B; в нем могут быть задействованы другие стороны, например C и D, желающие внести монеты c и d в свой простой платежный канал, соответственно (эта возможность используется позже в 5.2.5.).
Если охватывающий платежный канал асимметричен, два обещания должны быть зафиксированы в двух воркчейнах: A обещает выплатить -б монет B, если окончательный расчет «внутреннего» простого платежного канала дает отрицательный окончательный дисбаланс 6 с 0
≤
-б
≤
c; и B должен будет пообещать заплатить б в пользу A, если б положителен. С другой стороны, если охватывающий платежный канал является симметричным, это может быть выполнено путем фиксации одной транзакции «создания простого платежного канала» с параметрами
(c, d) в блокчейне одного платежного канала с помощью A (который заморозит c монет, принадлежащих A), а затем фиксации специальной «транзакции подтверждения» от B (которая заморозит d монет B).
Мы ожидаем, что внутренний платежный канал будет чрезвычайно простым
(например, простой синхронный платежный канал, описанный в 5.1.3), что позволит минимизировать объем предоставляемых доказательств Меркла. Внешний платежный канал должен быть «умным» в смысле, описанном в п. 5.1.7.

89 5.2. Сеть платежных каналов или «сеть мгновенных платежей» (Lightning)
5.2.2. Сети платежных каналов или «сети мгновенных платежей». Сети платежных каналов преодолевают ограничения платежных каналов, обеспечивая денежные переводы по цепочкам платежных каналов. Если A хочет перевести деньги в E, ему не нужно устанавливать платежный канал с E. Достаточно иметь цепочку платежных каналов, связывающую A с E через несколько промежуточных узлов - скажем, четыре платежных канала: от A до B, от B до C, от C до D и от D до E.
5.2.3. Обзор сетей платежных каналов. Напомним, что сеть платежных каналов, известная также как «сеть мгновенных платежей», состоит из набора участвующих узлов, некоторые из которых установили между собой долговременные платежные каналы. Мы скоро увидим, что эти платежные каналы должны быть «умными» в смысле 5.1.7. Когда участвующий узел A хочет перевести деньги любому другому участвующему узлу E, он пытается найти путь, связывающий A с E внутри сети платежных каналов. Когда такой путь находится, выполняется «цепной перевод денег» по этому пути.
5.2.4. Цепные денежные переводы. Предположим, что существует цепочка платежных каналов от А до В, от В до C к D и от D к E. Предположим также, что A хочет передать x монет E.
Упрощенный подход состоял бы в том, чтобы передать x монет В по существующему платежному каналу и попросить его переслать деньги дальше С. Однако не очевидно, почему В просто не возьмет деньги себе. Следовательно, необходимо использовать более изощренный подход, не требующий от всех вовлеченных сторон доверять друг другу.
Этого можно добиться следующим образом. A генерирует большое случайное число u и вычисляет его хэш v = HASH(u). Затем он создает обещание выплатить x монет В, если в его платежном канале с В присутствует число u с хешем v (см. 5.1.7). Это обещание содержит v, но не u, а значение пока держится в секрете.
После этого B создает аналогичное обещание для C в своем платежном канале. Он не боится давать такое обещание, потому что знает о существовании подобного обещания, данного ему А. Если C когда-либо предоставит решение хеш-задачи по сбору x монет, обещанное В, то В немедленно представит это решение задачи A для сбора x монет у A.
Затем создаются аналогичные обещания от C к D и от D к E. Когда все обещания будут выполнены, A запускает передачу, сообщая решение u всем вовлеченным сторонам или только E.
Некоторые мелкие детали опущены в этом описании. Например, эти обещания должны иметь разное время истечения, а обещанная сумма может немного отличаться по цепочке (В может обещать C только x - e монет, где e - небольшая заранее согласованная плата за транзит). Мы пока игнорируем такие детали, потому что они не слишком актуальны для понимания того, как работают платежные каналы и как их можно реализовать в TON.
5.2.5. Виртуальные платежные каналы внутри цепочки платежных каналов.
Теперь предположим, что A и E рассчитывают выполнять большое количество платежей друг другу. Они могут создать новый платежный канал между собой в блокчейне, но это все равно будет довольно дорого, потому что некоторые средства будут заблокированы в этом платежном канале. Другой вариант - использовать цепные денежные переводы, описанные в 5.2.4, для каждого платежа. Однако это потребует большой сетевой активности и большого количества транзакций в виртуальных блокчейнах всех задействованных платежных каналов.
Альтернативой является создание виртуального платежного канала внутри блокчейна, связывающего A и E в сети платежных каналов. Для этого A и E создают

90 5.2. Сеть платежных каналов или «сеть мгновенных платежей» (Lightning)
(виртуальный) блокчейн для своих платежей, как если бы они собирались создать платежный канал в блокчейне. Однако вместо создания смарт-контракта платежного канала в блокчейне они просят все промежуточные платежные каналы - те, которые связывают A с B, B с C и т. д. - создать внутри них простые платежные каналы, привязанные к виртуальному блокчейну, созданному A и E (см. 5.1.10). Другими словами, теперь обещание перевести деньги в соответствии с окончательным расчетом между A и E существует внутри каждого промежуточного платежного канала.
Если виртуальный платежный канал является однонаправленным, такие обещания могут быть реализованы довольно легко, потому что окончательный дисбаланс 5 будет неположительным, поэтому простые платежные каналы могут быть созданы внутри промежуточных платежных каналов в том же порядке, как описано в 5.2.4. ,
Таким же образом можно установить срок их действия.
Если виртуальный платежный канал является двунаправленным, ситуация становится несколько сложнее. В этом случае следует разделить обещание передать б монет в соответствии с окончательным расчетом на два «полуобещания», как описано в 5.1.10: передать б
-
= max (0, -б) монет в прямом направлении и допередать б
+
= max (0, б) в обратном направлении. Эти полуобещания могут быть созданы в промежуточных платежных каналах независимо, одна цепочка полуобещаний в направлении от A к E, а другая цепочка - в противоположном направлении.
5.2.6. Поиск путей в сети мгновенных платежей. Пока не обсуждается один вопрос: как A и E найдут путь, соединяющий их в платежной сети? Если платежная сеть не слишком большая, можно использовать протокол типа OSPF: все узлы платежной сети создают оверлейную сеть (см. 3.3.17), а затем каждый узел передает всю доступную информацию (т. е. участвующие платежные каналы) своим соседям по протоколу сплетен. В итоге все узлы будут иметь полный список всех платежных каналов, участвующих в платежной сети, и смогут сами найти кратчайшие пути, например, применив версию алгоритма Дейкстры, измененную с учетом
«возможностей» задействованных платежных каналов (т. е. максимальные суммы, которые могут быть переведены по ним). После того, как путь-кандидат будет найден, его можно исследовать с помощью специальной датаграммы ADNL, содержащей полный путь и запрашивающей у каждого промежуточного узла подтверждение существования рассматриваемого платежного канала, и пересылать эту датаграмму дальше в соответствии с путем. После этого можно построить цепочку и запустить протокол для цепных переводов (см. 5.2.4) или для создания виртуального платежного канала внутри цепочки платежных каналов (см. 5.2.5).
5.2.7. Оптимизация. Здесь можно сделать некоторые оптимизации. Например, только транзитные узлы сети мгновенных платежей должны участвовать в протоколе типа
OSPF, описанном в 5.2.6. Два «листовых» узла, желающие подключиться через сеть мгновенных платежей, будут передавать друг другу списки транзитных узлов, к которым они подключены (т. е. с которыми они установили платежные каналы, участвующие в платежной сети). Затем можно проверить пути, соединяющие транзитные узлы из одного списка с транзитными узлами из другого списка, как описано выше в п. 5.2.6.
5.2.8. Вывод. Мы обрисовали в общих чертах, насколько блокчейн и сетевые технологии проекта TON соответствуют задаче создания TON Payments - платформы для мгновенных денежных переводов и микроплатежей вне сети. Эта платформа может быть чрезвычайно полезна для сервисов, находящихся в экосистеме TON, позволяя им легко собирать микроплатежи, когда и где это необходимо.

91
Вывод
Мы предложили масштабируемую многоблочную архитектуру, способную поддерживать широко популярную криптовалюту и децентрализованные приложения с удобными интерфейсами.
Для достижения необходимой масштабируемости мы предложили использовать блокчейн TON, «тесно-связанную» систему с несколькими блокчейнами (см. 2.8.14) с восходящим подходом к сегментированию (см. 2.8.12 и 2.1.2). Чтобы повысить потенциальную производительность, мы ввели механизм с двумя блокчейнами для замены недопустимых блоков (см. 2.1.17), а также мгновенную маршрутизацию в гиперкубе (Instant Hypercube Routing) для более быстрой связи между шардами (см.
2.4.20). Краткое сравнение блокчейна TON с существующими и предлагаемыми проектами блокчейнов (см. 2.8 и 2.9) подчеркивает преимущества этого подхода для систем, которые должны будут обрабатывать миллионы транзакций в секунду.
Сеть TON, описанная в главе 3, покрывает сетевые потребности предлагаемой мультиблокчейн-инфраструктуры. Этот сетевой компонент также может использоваться в сочетании с блокчейном для создания широкого спектра приложений и сервисов, что невозможно при использовании только блокчейна (см.
2.9.13). Эти сервисы, обсуждаемые в главе 4, включают TON DNS, службу для преобразования человекочитаемых идентификаторов объектов в их адреса; TON
Storage, распределенную платформу для хранения произвольных файлов; TON Proxy, сервис для анонимизации доступа к сети и доступа к сервисам на базе TON; а также
TON Payments (см. главу 5), платформу для мгновенных денежных переводов вне сети через экосистему TON, которую приложения могут использовать для микроплатежей.
Инфраструктура TON позволяет создавать специализированные легкие клиентские кошельки и приложения для настольных компьютеров и смартфонов с «TON- браузером», которые позволят конечному пользователю работать по аналогии с работой в браузере (см. 4.3.23), совершать платежи в криптовалюте и взаимодействовать со смарт-контрактами и другими сервисами на платформе TON, доступной массовому пользователю.

92
Список литературы
Список литературы
[1]
К. BIRMAN, Reliable Distributed Systems: Technologies, Web Services and
Applications, Springer, 2005.
[2]
V. BUTERIN, Ethereum: A next-generation smart contract and decentralized application platform, https : //github. com/ethereum/wiki/ wiki/White-Paper, 2013.
[3]
M. BEN-OR, B. KELMER, T. RABIN, Asynchronous secure computations with optimal resilience, in Proceedings of the thirteenth annual ACM symposium on Principles of distributed computing, p. 183-192. ACM, 1994.
[4]
M. CASTRO, B. LISKOV, ET AL., Practical byzantine fault tolerance, 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]
EOS.IO,
EOS.IO technical white paper, https://github.com/EOSIO/
Documentation/blob/master/TechnicalWhitePaper.md, 2017.
[6]
D. GOLDSCHLAG, M. REED, P. SYVERSON, Onion Routing for Anonymous and
Private Internet Connections, Communications of the ACM, 42, num. 2 (1999), http://www.onion-router.net/Publications/ CACM-1999.pdf.
[7]
L. LAMPORT, R. SHOSTAK, M. PEASE, The byzantine generals problem, ACM
Transactions on Programming Languages and Systems, 4/3 (1982), p. 382-401.
[8]
S.
LARIMER,
The history of
BitShares, https://docs.bitshares.org/ bitshares/history.html,2013.
[9]
M. LUBY, A. SHOKROLLAHI, ET AL., RaptorQ forward error correction scheme for object delivery, IETF RFC 6330, https: //tools. ietf . org/ html/rfсбЗЗО, 2011.
[10]
P. MAYMOUNKOV, D. MAZIERES, Kademlia: A peer-to-peer information system based on the XOR metric, in IPTPS ’01 revised papers from the First International Workshop on Peer-to-Peer Systems, p. 53-65, available at 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]
S. NAKAMOTO, Bitcoin: A peer-to-peer electronic cash system, https:
//bitcoin.org/bitcoin.pdf, 2008.
[13]
S. PEYTON JONES, Implementing lazy functional languages on stock hardware: the
Spineless Tagless G-machine, Journal of Functional Pro-gramming 2 (2), p. 127-202, 1992.
[14]
A. SHOKROLLAHI, M. LUBY, Raptor Codes, IEEE Transactions on Information
Theory 6, no. 3-4 (2006), p. 212-322.
[15]
M. VAN STEEN, A. TANENBAUM, Distributed Systems, 3rd ed., 2017.
[16]
THE UNIVALENT FOUNDATIONS PROGRAM, Homotopy Type Theory:
Univalent Foundations of Mathematics, Institute for Advanced Study, 2013, available at https://homotopytypetheory.org/book.
[17]
G. WOOD, PolkaDot: vision for a heterogeneous multi-chain framework, draft 1, https://github.com/w3f/polkadot-white-paper/raw/ master/PolkaDotPaper.pdf, 2016.

93
Приложение A. Монета TON Coin
Монета TON Coin
Основной криптовалютой блокчейна TON и, в частности, его мастерчейна и основного воркчейна, является TON Coin. TON Coin используется для внесения депозитов, необходимых для того, чтобы стать валидатором; комиссии за транзакции, платежи за газ (т. е. сборы за обработку сообщений смарт-контрактов) и платежи за постоянное хранение также обычно собираются в TON Coin.
A.1. Подгруппы и соответствующая терминология. TON Coin подразделяется на один миллиард (10 9
) единиц меньшего размера, называемых нанотонами, нтонами или просто нано. Все переводы и остатки на счетах выражаются в виде неотрицательных целых чисел, кратных нано. Другие единицы включают в себя:
• Нано, нтон или нанотона — наименьшая единица, равная 10
-9
монетам TON.
• Микро или микротон равняется одной тысяче (10 3
) нано.
• Милли — это один миллион (10 6
) нано или одна тысячная часть (10
-3
) монеты
TON.
• Монета TON равняется одному миллиарду (10 9
) нано.
• Килотон, или kTon, равняется одной тысяче (10 3
) монет TON.
• Мегатон, или МТон, равняется одному миллиону (10 6
) монет TON, или 10 15
нано.
• Наконец, гигатон, или GTon, равняется одному миллиарду (10 9
) монет TON, или 10 18
нано.
Необходимость в более крупных единицах будет отсутствовать, поскольку первоначальный запас монет TON будет ограничен пятью миллиардами (5 • 10 9
) монет
TON (то есть 5 гигатон).
А.2. Меньшие единицы для выражения цен на газ. Если возникнет необходимость в более мелких единицах, будут использоваться «спеки» размером от 2
-16
нанотон.
Например, цены на газ могут быть указаны в спеках. Однако фактическая плата, подлежащая уплате, вычисляемая как произведение цены на газ и количества потребленного газа, всегда будет округляться до ближайшего числа, кратного 2 16
, и выражаться целым числом нано.
А.3. Первоначальное предложение, вознаграждение за майнинг и инфляция.
Общее количество монет TON Coin изначально ограничено 5 гигатонами (то есть пятью миллиардами монет TON Coin или 5 • 10 18
нано).
Это предложение будет увеличиваться очень медленно по мере накопления вознаграждений валидаторам за майнинг новых блоков мастерчейна и шардчейна.
Эти вознаграждения будут составлять примерно 20% (точное число может быть изменено в будущем) от доли валидатора в год при условии, что валидатор старательно выполняет свои обязанности, подписывает все блоки, никогда не переходит в автономный режим и никогда не подписывает недействительные блоки.
Таким образом, валидаторы получат достаточно прибыли, чтобы инвестировать в лучшее и более быстрое оборудование, необходимое для обработки постоянно растущего количества транзакций пользователей.
Мы ожидаем, что не более 10%
35
от общего количества монет TON Coin, в среднем, будет привязано к стейкам валидаторов в любой момент времени. Это приведет к росту инфляции в 2% в год и, как следствие, удвоит общее предложение монет TON
Coin (до десяти гигатон) через 35 лет.
35
Максимальная общая сумма стейков валидаторов является настраиваемым параметром блокчейна, поэтому при необходимости это ограничение может быть применено в рамках протокола.