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

83 4.3. Доступ к сервисам TON
TON-сайты, TON-сервисы или смарт-контракты с помощью подходящих (TON) URL- адресов. В этом случае, как только пользователь заполняет и отправляет эту настраиваемую форму, соответствующее действие предпринимается либо сразу, либо после явного подтверждения.
4.3.23. Сеть TON WWW. Все вышеперечисленное приведет к созданию целой сети объектов с перекрестными ссылками, находящихся в сети TON, которые будут доступны конечному пользователю через тонкий браузер, предоставляя пользователю возможность просмотра веб-страниц в стиле WWW. Для конечных пользователей это, наконец, сделает приложения блокчейна принципиально похожими на веб-сайты, к которым они уже привыкли.
4.3.24. Преимущества TON WWW. Этот «TON WWW» сетевых и автономных сервисов имеет некоторые преимущества перед своим традиционным аналогом.
Например, платежи по своей сути интегрированы в систему. Идентификационные данные пользователя всегда могут быть предоставлены сервисам (посредством автоматически сгенерированных подписей на транзакциях и сгенерированных запросов RPC) или скрыты по желанию. Сервисам не нужно будет перепроверять учетные данные пользователя; эти учетные данные могут быть опубликованы в блокчейне раз и навсегда. Анонимность пользователей в сети может быть легко сохранена с помощью TON Proxy, а все сервисы будут всегда доступными. Также будут доступными микроплатежи, потому что TON-браузеры могут быть интегрированы с системой TON Payments.

84 5.1. Каналы оплаты чтобы фиксировать каждый платеж как транзакцию в блокчейне, они создают общий
«денежный пул» (или, возможно, небольшой частный банк с ровно двумя счетами) и вносят в него некоторые средства: A вносит a монет, B вносит b монет. Это достигается путем создания специального смарт-контракта в блокчейне и отправкой на него средств.
Перед созданием «денежного пула» стороны соглашаются на определенный протокол. Они будут отслеживать состояние пула, то есть свои балансы в общем пуле.
Первоначально состоянием является (a, b), что означает, что монеты на самом деле принадлежат A, а b монет принадлежат B. Затем, если A хочет заплатить d монет в пользу B, они могут просто согласиться с тем, что новое состояние - (a’, b’) = (a - d, b
+ d). Впоследствии, если, скажем, B хочет заплатить d' монет в пользу A, состояние станет (a”, b”) = (a' + d', b' - d') и так далее.
Все это обновление балансов внутри пула происходит полностью вне сети. Когда две стороны решают снять причитающиеся им средства из пула, они делают это в соответствии с окончательным состоянием пула. Это достигается путем отправки специального сообщения в смарт-контракт, содержащего согласованное конечное состояние (a *, b *) вместе с подписями как A, так и B. Затем смарт-контракт отправляет a * монет в A, b * монеты в B и самоуничтожается.
Этот смарт-контракт вместе с сетевым протоколом, используемым A и B для обновления состояния пула, представляет собой простой платежный канал между A и
B. Согласно классификации, описанной в 4.1.2, это смешанный сервис: часть его состояние находится в блокчейне (смарт-контракте), но большая часть соответствующих обновлений состояния выполняется вне сети (по сетевому протоколу). Если все идет хорошо, две стороны смогут выполнить столько платежей друг другу, сколько захотят (с единственным ограничением, что не должна быть превышена «пропускная способность» канала, т. е. их остатки на платежном канале не будут отрицательными), совершая только две транзакции в блокчейне: одна для открытия (создания) платежного канала (смарт-контракт), а другая для его закрытия
(уничтожения).
5.1.2. Не требующие доверия каналы оплаты. Предыдущий пример был несколько нереалистичным, так как он предполагает, что обе стороны готовы сотрудничать и никогда не обманывают друг друга, чтобы получить какое-либо преимущество.
Представьте, например, что A решит не подписывать окончательный баланс (a', b’) с a' Чтобы защитить пользователей от таких сценариев, обычно разрабатываются «не требующие доверия» протоколы каналов оплаты, которые не требуют от сторон доверия друг к другу, и предусматривают наказание любой стороны, которая попытается обмануть другую сторону.
Обычно это достигается с помощью подписей. Смарт-контракт платежного канала знает открытые ключи A и B и при необходимости может проверять их подписи.
Протокол платежного канала требует, чтобы стороны подписали промежуточные состояния и отправили подписи друг другу. Затем, если одна из сторон обманывает - например, делает вид, что какое-то состояние платежного канала никогда не существовало, - ее некорректное поведение можно доказать, поставив свою подпись на этом состоянии. Смарт-контракт платежного канала выступает в роли «сетевого арбитра», способного обрабатывать жалобы двух сторон друг на друга и наказывать виновную сторону, конфисковав все ее средства и передав их другой стороне.
5.1.3. Простой двунаправленный синхронный канал оплаты, не требующий
доверия. Рассмотрим следующий, более реалистичный пример: Пусть состояние платежного канала описывается тройкой (б i
, i, о i
, где i - порядковый номер состояния
(изначально он равен нулю, а затем увеличивается на единицу при последующем

85 5.1. Каналы оплаты появляется состояние), б i
- дисбаланс канала (это означает, что A и B владеют монетами a + б i
и b - б i
соответственно), а o i
- сторона, которой разрешено генерировать следующее состояние (либо A, либо B). Каждое состояние должно быть подписано как А, так и B, прежде чем будет достигнут какой-либо дальнейший прогресс.
Теперь, если A хочет передать d монет B внутри платежного канала, а текущее состояние - S
i
= (б i
, i, o i
) с o i
= A, то он просто создает новое состояние S
i
+ 1 = (б i
- d , i + 1, o i
+ 1), подписывает его и отправляет B вместе со своей подписью. Затем B подтверждает это, подписывая и отправляя копию своей подписи A. После этого обе стороны получают копию нового состояния с обеими своими подписями, и может произойти новая передача.
Если A хочет передать монеты B в состоянии S
i с o i
= B, то сначала он просит B зафиксировать последующее состояние S
i+1 с таким же дисбалансом б i+1
= б i
, но с o i+1
= A После этого, A сможет Выполнить передачу.
Когда две стороны соглашаются закрыть платежный канал, они ставят свои специальные окончательные подписи на состояние S
k
, которое они считают окончательным, и вызывают чистый или двусторонний метод финализации смарт- контракта платежного канала, отправив ему окончательное состояние вместе с обеими окончательными подписями.
Если другая сторона не соглашается предоставить свою окончательную подпись или просто перестает отвечать, есть возможность закрыть канал в одностороннем порядке.
Для этого сторона, желающая сделать это, вызывает метод односторонней финализации, отправив смарт-контракту свою версию конечного состояния, свою окончательную подпись и самое последнее состояние, имеющее подпись другой стороны. После этого смарт-контракт не сразу воздействует на полученное конечное состояние. Вместо этого он ждет в течение определенного периода времени
(например, одного дня), пока другая сторона не представит свою версию окончательного состояния. Когда другая сторона отправляет свою версию, и она оказывается совместимой с уже представленной версией, «истинное» конечное состояние вычисляется смарт-контрактом и используется для соответствующего распределения средств. Если другая сторона не может представить свою версию конечного состояния смарт-контракту, то деньги перераспределяются в соответствии с единственной представленной копией конечного состояния.
Если одна из двух сторон обманывает - например, подписывая два разных состояния как окончательные, подписывая два разных следующих состояния S
i+1 и S'
i+1
, либо подписывая недопустимое новое состояние S
i+1
(например, с дисбалансом б i+1
< -a или
> b) - тогда другая сторона может предоставить доказательство этого неправомерного поведения третьему методу смарт-контракта. Виновная сторона немедленно наказывается полной потерей своей доли в платежном канале.
Этот простой протокол платежного канала справедлив в том смысле, что любая сторона всегда может получить должное, при сотрудничестве или без сотрудничества с другой стороной, и, вероятно, потеряет все свои средства, переданные в платежный канал, если попытается обмануть.
5.1.4. Синхронный платежный канал как простой виртуальный блокчейн с
двумя валидаторами. Приведенный выше пример простого синхронного платежного канала можно изменить следующим образом. Представьте, что последовательность состояний S
0
, S
1
,...,S
n на самом деле является последовательностью блоков очень простого блокчейна. Каждый блок этого блокчейна содержит по существу только текущее состояние блокчейна и, возможно, ссылку на предыдущий блок (то есть его хэш). Обе стороны A и B выступают в роли валидаторов для этого блокчейна, поэтому каждый блок должен собирать обе подписи. Состояние S
i блокчейна определяет назначенного производителя c ^ для

86 5.1. Каналы оплаты следующего блока, поэтому между A и B нет гонки за создание следующего блока.
Производителю A разрешено создавать блоки, которые переводят средства от A к B
(т. е. уменьшают дисбаланс: б i+1
≤
б i
), а B может переводить средства только от B к A
(т. е. увеличивать б).
Если два валидатора согласовывают окончательный блок (и окончательное состояние) блокчейна, он завершается сбором специальных «окончательных» подписей двух сторон и отправкой их вместе с последним блоком в смарт-контракт канала для обработки и соответствующее перераспределение средств.
Если валидатор подписывает недействительный блок, создает форк или подписывает два разных финальных блока, он может быть наказан. При этом доказательство некорректного поведения валидатора предоставляется смарт-контракту, который действует как «ончейн-арбитр» для двух валидаторов; тогда нарушившая сторона теряет все свои деньги, хранящиеся в платежном канале, что аналогично тому, как валидатор теряет свою долю.
5.1.5. Асинхронный платежный канал как виртуальный блокчейн с двумя
воркчейнами. Синхронный платежный канал, описанный в 5.1.3, имеет определенный недостаток: нельзя начать следующую транзакцию (перевод денег средств внутри платежного канала) до того, как предыдущая будет подтверждена другой стороной. Это можно исправить, заменив единый виртуальный блокчейн, описанный в 5.1.4, системой из двух взаимодействующих виртуальных воркчейнов
(или, скорее, шардчейнов).
Первый из этих воркчейнов содержит только транзакции A, а его блоки могут быть сгенерированы только A. Его состояния: S
i
= (i, ф i
, j, ψ
j
), где i - порядковый номер блока (т. е. количество транзакций или денежных переводов, выполненных A на данный момент), ф
і
- это общая сумма, переведенная от A к B на данный момент , j - порядковый номер самого последнего действительного блока в блокчейне B’s котором известно A, ψ
j
- сумма денег, переданная от B к A в его j транзакциях.
Подпись B, помещенная в его j-й блок, также должна быть частью этого состояния.
Также могут быть включены хэши предыдущего блока этой воркчейна и j-го блока другой воркчейна. Условия применимости для S
i включают ф
і
≥
0 ф
і
≥
ф
і-1
, если i > 0,
ψ
j
≥
0, и -a
≤
ψ
j
- ф i
≤
b.
Точно так же второй воркчейн содержит только транзакции B, а его блоки генерируются только B. Его состояния: T
j
= (j, ψ
j
, i, φ
i
) с аналогичными условиями выполнения.
Если A хочет перевести средства B, он просто создает новый блок в своем воркчейне, подписывает его и отправляет B, не дожидаясь подтверждения.
Платежный канал завершается подписанием A (его версией) конечного состояния своего блокчейна (со специальной «окончательной подписью»), подписанием B конечного состояния своего блокчейна и представлением этих двух конечных состояний методу чистой финализации смарт-контракта платежного канала.
Одностороннее завершение также возможно, однако в этом случае смарт-контракт должен будет дождаться, пока другая сторона представит свою версию окончательного состояния, по крайней мере, в течение некоторого периода отсрочки.
5.1.6. Однонаправленные платежные каналы. Если только A необходимо произвести платежи для B (например, B является поставщиком услуг, а A - его клиентом), то может быть создан канал односторонних платежей. По сути, это просто первый воркчейн, описанный в 5.1.5, без второго воркчейна. И наоборот, можно сказать, что асинхронный платежный канал, описанный в 5.1.5, состоит из двух однонаправленных платежных каналов или «полуканалов», управляемых одним и тем же смарт-контрактом.

87 5.1. Каналы оплаты
5.1.7. Более сложные каналы оплаты. «Обещания». Позже в 5.2.4 мы увидим, что
«сеть мгновенных платежей» (см. 5.2), которая обеспечивает мгновенные денежные переводы через цепочки из нескольких платежных каналов, требует более высокой степени сложности задействованных платежных каналов.
В частности, мы хотим иметь возможность давать «обещания» или совершать
«условные денежные переводы»: A соглашается отправить c монет B, но B получит деньги только при выполнении определенного условия, например, если B может представить некоторую строку u с HASH(U) = v для известного значения v. В противном случае A может вернуть деньги через определенный период времени.
Такое обещание может быть легко реализовано в сети с помощью простого смарт- контракта. Однако мы хотим, чтобы обещания и другие виды условных денежных переводов были возможны оффчейн, в платежном канале, потому что они значительно упрощают денежные переводы по цепочке платежных каналов, существующих в
«сети мгновенных платежей» (см. 5.2. 4).
Схема «платежный канал как простой блокчейн», описанная в 5.1.4 и 5.1.5, здесь становится очень удобной. Рассмотрим более сложный виртуальный блокчейн, состояние которого содержит набор таких невыполненных «обещаний» и количество средств, заблокированных в таких обещаниях. Этот блокчейн - или два воркчейна в асинхронном случае - должны будут явно ссылаться на предыдущие блоки по их хэшам. Тем не менее, общий механизм остается прежним.
5.1.8. Проблемы при использовании сложных смарт-контрактов платежных
каналов. Обратите внимание, что, хотя конечное состояние сложного платежного канала все еще невелико, а «чистое» завершение является простым (если две стороны согласовали свои причитающиеся суммы, и обе подписали соглашение, больше ничего не нужно делать), метод одностороннего завершения и метод наказания мошенничества должны быть более сложными. Действительно, они должны иметь возможность принимать доказательства Меркла при неправомерном поведении и проверять, правильно ли были обработаны более сложные транзакции блокчейна платежного канала.
Другими словами, смарт-контракт платежного канала должен иметь возможность работать с доказательствами Меркла, проверять их «хеш-валидность» и должен содержать реализацию функций ev_trans и ev_block (см. 2.2.6) для платежного канала
(виртуального) блокчейна.
5.1.9. VM TON поддерживает «умные» каналы оплаты. Виртуальная машина TON, используемая для запуска кода смарт-контрактов блокчейна TON, справляется с задачей выполнения смарт-контрактов, необходимых для «умных» или сложных каналов оплаты (см. 5.1.8),
На этом этапе парадигма «все есть мешок ячеек» (см. 2.5.14) становится чрезвычайно удобной. Поскольку все блоки (включая блоки блокчейна канала мгновенного платежа) представлены как мешки ячеек (и описываются некоторыми алгебраическими типами данных), и то же самое верно для сообщений и доказательств
Меркла, доказательство Меркла может быть легко встроено во входящее сообщение, отправленное на смарт-контракт платежного канала.
«Условие хеширования» доказательства Меркла будет проверяться автоматически, и когда смарт-контракт получит доступ к предоставленному «доказательству Меркла», он будет работать с ним, как если бы это было значение соответствующего алгебраического типа данных - хотя и неполное, в котором некоторые поддеревья дерева заменены специальными узлами, содержащими хэш Меркла пропущенного поддерева. Затем смарт-контракт будет работать с этим значением, которое может предоставлять, например, блок (виртуального) блокчейна платежного канала вместе с его состоянием, и будет оценивать функцию ev_block (см. 2.2.6) этого блокчейна в