Теперь мы можем обсудить «сеть мгновенных платежей» системы TON Payments, которая обеспечивает мгновенные денежные переводы между любыми двумя участвующими узлами.
5.2.1. Ограничения платежных каналов. Платежный канал полезен для сторон, которые собираются выполнять большое количество денежных переводов между своими учетными записями. Однако если нужно перевести средства только один или два раза конкретному получателю, создание платежного канала с ним будет нецелесообразно. Среди прочего, это повлечет за собой замораживание значительной суммы денег в платежном канале и в любом случае потребует как минимум двух транзакций блокчейна.
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 создают
(виртуальный) блокчейн для своих платежей, как если бы они собирались создать платежный канал в блокчейне. Однако вместо создания смарт-контракта платежного канала в блокчейне они просят все промежуточные платежные каналы - те, которые связывают 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, позволяя им легко собирать микроплатежи, когда и где это необходимо.
Вывод
Мы предложили масштабируемую многоблочную архитектуру, способную поддерживать широко популярную криптовалюту и децентрализованные приложения с удобными интерфейсами.
Для достижения необходимой масштабируемости мы предложили использовать блокчейн 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, доступной массовому пользователю.
