Открытая сеть. Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021

• Название: Открытая сеть по материалам работы дра Николая Дурова 26 июля 2021
• Дата: 11.06.2022
• Размер: 0.79 Mb.
• Имя файла: Открытая сеть.pdf
• Тип: Реферат; #585329
• страница: 13 из 14

4.3.20. Гиперссылки. Обратите внимание, что HTML-страницы, возвращаемые ton- сайтами
, могут содержать ton-гиперссылки, то есть ссылки на другие ton-сайты, смарт
-контракты и учетные записи с помощью специально созданных схем URI (см. 4.3.21)
, содержащих либо абстрактные сетевые адреса, идентификаторы учетных записей, либо читаемые человеком DNS- домены TON. Тогда ton-браузер может следовать такому
109 4.3. Доступ к сервисам TON гиперссылка когда пользователь выбирает ее, определяет используемый интерфейс и отображает форму пользовательского интерфейса, как описано в 4.3.15 и 4.3.16.
4.3.21. URL-адреса гиперссылок могут указывать некоторые параметры. URL-адреса гиперссылок могут содержать не только домен DNS (TON) или абстрактный адрес рассматриваемой службы, но также имя вызываемого метода и некоторые или все его параметры. Возможная схема URI для этого может выглядеть следующим образом: тон://<домен > /<метод>?< eld1 > = &< eld2>=.. .
Когда пользователь выбирает такую ссылку в ton-браузере, либо действие выполняется немедленно (особенно если это метод get смарт-контракта, вызываемый анонимно), либо отображается частично заполненная форма, которая должна быть явно подтверждена и отправлена пользователем (это может потребоваться дляплатежные формы).
4.3.22. ОПУБЛИКОВАТЬ действия. Ton-сайт может встраиваться в HTML-страницы, которые он возвращает, некоторые обычные формы сообщений, с действиями POST, ссылающимися либо на ton-сайты, либо на ton-сервисы, либо на смарт-контракты с помощью подходящих
(TON)
URL-адресов. В этом случае, как только пользователь заполняет и отправляет эту пользовательскую форму, соответствующее действие выполняется либо сразу, либо после явного подтверждения.
4.3.23. ТОН WWW. Все вышесказанное приведет к созданию целой сети перекрестных ссылок, находящихся в сети TON, которая будет доступна конечному пользователю через ton-браузер, предоставляя пользователю
WWW-подобный опыт просмотра. Для конечных пользователей это, наконец, сделает приложения blockchain принципиально похожими на веб-сайты, к которым они уже привыкли.

4.3.24. Преимущества TON WWW. Эта ТОННА WWW услуг on-chain и o - chain имеет некоторые преимущества перед своим обычным аналогом. например, платежи по своей сути интегрированы в систему. Идентификатор пользователя может быть всегда представлен сервисам (с помощью автоматически сгенерированных подписей на транзакциях и сгенерированных запросах RPC) или скрыт по желанию. Сервисам не нужно будет проверять и перепроверять учетные данные пользователей; эти учетные данные могут быть опубликованы в блокчейне раз и навсегда. Пользовательская сеть анонимность может быть легко сохранена с помощью TON Proxy, и все сервисы будут эффективно разблокированы. Микроплатежи также возможны и просты, потому что ton-браузеры могут быть интегрированы с платежной системой TON.
110 5.1. Платежные каналы
5
Тонна платежей
Последний компонент проекта TON, который мы кратко обсудим в этом тексте
, - это TON Payments, платформа для (микро) платежных каналов и передачи стоимости lightning network. Это позволит осуществлять мгновенные платежи без необходимости фиксировать все транзакции в блокчейне, оплачивать связанные с ними транзакционные сборы (например, за потребленный газ) и ждать пять секунд, пока блок
, содержащий рассматриваемые транзакции, не будет подтвержден.
Общие накладные расходы на такие мгновенные платежи настолько малы, что их можно использовать для микроплатежей. Например, служба хранения файлов TON может взимать плату с пользователя за каждые 128 Кб загруженных данных, или платный прокси-сервер TON может потребовать небольшой микроплатеж за каждые 128 Кб переданных данных.
Хотя TON Payments, скорее всего, будет выпущена позже, чем основные компоненты проекта TON, некоторые соображения должны быть сделаны в самом начале. Например, виртуальная машина TON (TON VM; ср. 2.1.20), используемая для выполнения кода смарт - контрактов TON Blockchain, должна поддерживать некоторые специальные операции с доказательствами Меркла. Если такая поддержка отсутствует в первоначальном проекте, добавление ее на более позднем этапе может стать проблематичным
(см. 2.8.16). Однако мы увидим, что виртуальная машина TON поставляется с естественной поддержкой интеллектуальных платежных каналов (см. 5.1.9) из коробки.
5.1
Платежные каналы

Мы начнем с обсуждения каналов оплаты точка-точка и того, как они могут быть реализованы в блокчейне TON.
5.1.1. Идея платежного канала. Предположим, две стороны,A и B, знают, что им нужно будет сделать много платежей друг другу в будущем.
Вместо того, чтобы совершать каждый платеж как транзакцию в блокчейне, они создают общий денежный пул (или, возможно, небольшой частный банк с ровно двумя счетами) и вносят некоторый вклад.средства к нему: A вносит a монет, и
B вносит b монет. Это достигается путем создания специального смарт-контракта в блокчейне и отправка денег на него.
Прежде чем создать денежный пул , обе стороны соглашаются на определенный протокол.
Они будут отслеживать состояние пула, то есть свои балансы в общем пуле. Первоначально состояние равно (a, b), что означает, что монеты a фактически принадлежат A, а монеты b принадлежат B. Тогда, если A хочет заплатить d монет
B, они могут просто согласиться с тем , что новое состояние (a, b ) = (a − d, b + d).
111 5.1. Платежные каналы
После этого, если, скажем, B захочет заплатить d монет A, состояние станет
(a, b) = (a + d, b - d ) и так далее.
Все это обновление балансов внутри пула выполняется полностью o - chain.
Когда обе стороны решают вывести причитающиеся им средства из пула, они делают это в соответствии с окончательным состоянием пула. Это достигается путем отправки специального сообщения в смарт-контракт, содержащего согласованное конечное состояние
(a
∗
, б
∗
) вместе с подписями как A, так и B. Затем смарт-контракт отправляет
∗ монеты в A, b
∗ монеты в B и самоуничтожается.
Этот смарт-контракт, наряду с сетевым протоколом, используемым A и B для обновления состояния пула, является простым платежным каналом между A и B.
Согласно классификации, описанной в 4.1.2, это смешанный сервис: часть его состояния находится в блокчейне (смарт-контракт),но большинство обновлений его состояния выполняются o - chain (по сетевому протоколу). Если все пойдет хорошо, обе стороны смогут совершать друг другу столько платежей, сколько захотят (с единственным ограничением-пропускная способность канала не будет переполнена, т. е., их балансы в платежном канале оба остаются неотрицательными), совершая в блокчейн только две транзакции:

одну для открытия (создания) платежного канала (смарт-контракта), а другую для его закрытия (уничтожения).
5.1.2. Каналы безналичных платежей. Предыдущий пример был несколько нереалистичным, потому что он предполагает, что обе стороны готовы сотрудничать и никогда не будут обманывать, чтобы получить какое-то преимущество. Представьте себе, например, что A решит не подписывать окончательный баланс (a, b) с a < a. Это поставило бы B в сложную ситуацию.
Для защиты от таких сценариев обычно пытаются разработать протоколы каналов безналичных платежей, которые не требуют, чтобы стороны доверяли друг другу, и предусматривают наказание любой стороны, которая попытается обмануть.
Обычно это достигается с помощью подписей.
Смарт-контракт платежного канала знает открытые ключи A и B, и при необходимости может проверить их подписи. Протокол платежного канала требует, чтобы стороны подписали промежуточные состояния и отправили подписи друг другу. Затем, если одна из сторон обманывает, например, притворяется, что какое-то состояние платежного канала никогда не существовало, ее неправильное поведение может быть доказано, показав свою подпись на этом состоянии. Смарт-контракт платежного канала действует как сетевой арбитр , способный рассматривать жалобы двух сторон друг на друга и наказывать виновную сторону, конфисковывая все ее деньги и
112 5.1. Платежные каналы вручение его другой стороне.
5.1.3. Простой двунаправленный синхронный доверительный платежный канал.
Рассмотрим следующий, более реалистичный пример: Пусть состояние платежного канала описывается тройкой (δ i
, i, o i
)
, где i - порядковый номер состояния (первоначально он равен нулю, а затем увеличивается на единицу при появлении последующего состояния), δ i является ли дисбаланс канала (это означает, что A и B владеют a + δ i и b - δ i монеты, соответственно), и o i разрешено ли стороне генерировать следующее состояние (A или B). Каждое государство должно быть подписано как A, так и
B
, прежде чем можно будет добиться дальнейшего прогресса.
Теперь, если A хочет перевести монеты d в B внутри платежного канала, и текущее состояние - S

i
= (δ i
, i, o i
) с o i
= А
, то он просто создает новый государства i + 1
= (δ i
- d, i + 1, o i + 1
)
, подписывает его и отправляет в B вместе со своей подписью. Затем Б подтверждает его, подписав и отправив копию своей подписи А.
После этого у обеих сторон есть копия нового государства с обеими их подписями, и может произойти новая передача.
Если A хочет перевести монеты в B в состоянии S i с o i
= B
, тогда это сначала просит B зафиксировать последующее состояние S i + 1 при одинаковом дисбалансе δ i + 1
= δ i
, но с o i + 1
= А
. После этого А сможет сделать свой перевод.
Когда обе стороны соглашаются закрыть платежный канал, они оба ставят их специальные окончательные подписи на государственных k они считают, что это nal, и используют метод чистой или двусторонней финализации смарт-контракта платежного канала, отправляя ему конечное состояние вместе с обеими конечными подписями.
Если другая сторона не соглашается предоставить свою окончательную подпись или просто перестает отвечать, канал можно закрыть в одностороннем порядке. Для этого сторона,желающая сделать это, будет использовать метод односторонней финализации, отправляя смарт-контракту свою версию конечного состояния, свою конечную подпись и самое последнее состояние, имеющее подпись другой стороны. После этого смарт - контракт не сразу действует на полученное конечное состояние.
Вместо этого он ждет определенного периода времени (например, одного дня), пока другая сторона представит свою версию конечного состояния. Когда другая сторона представляет свою версию,и она оказывается совместимой с уже представленной версией,

истинное конечное состояние вычисляется смарт-контрактом и используется для соответствующего распределения денег. Если другая сторона не представляет свою версию конечного состояния смарт-контракту, то деньги перераспределяются в соответствии с единственной представленной копией конечного состояния.
Если одна из двух сторон обманывает, например, подписав два разных государства в качестве окончательных или путем подписания двух различных следующих государств i + 1 и S i + 1
, или по
113 5.1. Платежные каналы подписание недействительного нового состояния Ов i + 1
(например, с дисбалансом δ i + 1
< - а или > b) тогда другая сторона может представить доказательства этого неправильного поведения третьему методу смарт-контракта. Виновная сторона немедленно наказывается полной потерей своей доли в платежном канале.
Этот простой протокол платежного канала справедлив в том смысле, что любая сторона всегда может получить причитающееся,с помощью или без сотрудничества другой стороны, и, скорее всего, потеряет все свои средства, переданные платежному каналу, если попытается обмануть.
5.1.4. Синхронный платежный канал в виде простого виртуального блокчейна с двумя валидаторами. Приведенный выше пример простого синхронного платежного канала можно переделать следующим образом. Представьте, что последовательность состояний S
0
,
S
1
,.. ., S n на самом деле это последовательность блоков очень простого блокчейна.
Каждый блок этого блокчейна содержит по существу только текущее состояние блокчейна и, возможно, ссылку на предыдущий блок (т. Е. Его хэш).
Обе стороны A и B выступают в качестве валидаторов для этого блокчейна, поэтому каждый блок должен собирать обе их подписи. Государство i о блокчейне de nes назначенный производитель o i

для следующего блока, поэтому нет гонки между A и B для создания следующего блока. Производителю A разрешено создавать блоки
, которые переводят средства из A в B (т. е. уменьшают дисбаланс: δ i + 1
≤ δ i
), и
B можно только перевести средства из B в A (т. е. Увеличить δ).
Если два валидатора договариваются о конечном блоке (и конечном состоянии) блокчейна, он завершается путем сбора специальных окончательных подписей двух сторон и отправки их вместе с окончательным блоком в смарт
-контракт канала для обработки и перераспределения денег соответственно.
Если валидатор подписывает недействительный блок, или создает форк, или подписывает два разных конечных блока, он может быть наказан, представив доказательство своего неправильного поведения смарт-контракту, который действует как цепной арбитр для двух валидаторов; тогда конечная сторона потеряет все свои деньгихранится в платежном канале, что аналогично тому, как валидатор теряет свою ставку.
5.1.5. Асинхронный платежный канал в виде виртуального блокчейна с двумя рабочими цепями. Синхронный платежный канал, рассмотренный в 5.1.3
, имеет определенный недостаток: нельзя начать следующую транзакцию ( перевод денег внутри платежного канала) до того, как предыдущая будет подтверждена другой стороной. Это можно исправить, заменив один виртуальный блокчейн
, рассмотренный в 5.1.4, системой из двух взаимодействующих виртуальных рабочих цепей (или, скорее
, шардчейнов).
114 5.1. Платежные каналы
Первая из этих рабочих цепочек содержит только транзакции по A, а ее блоки могут быть сгенерированы только A; его состояниями являются S i
= (i, φ i
, j, ψ j
)
, где i порядковый номер блока (т. е. Количество транзакций или денег переводы, выполненные А до сих пор), φ i это общая сумма, переведенная из A в B до сих пор, j-порядковый номер самого последнего действительного блока в блокчейне B, о котором известно A, и ψ j это сумма денег, переведенная из B в A в его j транзакциях. Сигнатура B, помещенная в его j-й блок
, также должна быть частью этого состояния.
Также могут быть включены хэши предыдущего блока этой рабочей цепочки и j-го блока

другой рабочей цепочки.
Условия действия S i включить φ i
≥ 0, φ i
≥ φ i-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, состоит из двух однонаправленных платежных каналов, или полуканалов, управляемых одним и тем же смарт
-контрактом.
5.1.7. Более сложные платежные каналы. Обещания.
Далее в 5.2.4 мы увидим, что lightning network (см. 5.2), которая позволяет осуществлять мгновенные денежные переводы через цепочки из нескольких платежных каналов, требует более

высокой степени сложности от задействованных платежных каналов.
В частности, мы хотим иметь возможность совершать обещания или условные денежные переводы : A соглашается отправить монеты c B, но B получит деньги
115 5.1. Платежные каналы только если выполняется определенное условие, например, если B может представить некоторую строку u с Hash(u) = v для известного значения v. В противном случае A может получить деньги обратно через определенный период времени.
Такое обещание может быть легко реализовано в цепочке с помощью простого смарт
-контракта. Однако мы хотим, чтобы обещания и другие виды условных денежных переводов были возможны o - chain, в платежном канале, поскольку они значительно упрощают денежные переводы по цепочке платежных каналов, существующих в lightning network (см. 5.2.4).
Платежный канал в виде простой блокчейн-картины, описанной в 5.1.4 и 5.1.5, становится здесь удобным. Теперь рассмотрим более сложный виртуальный блокчейн, состояние которого содержит набор таких невыполненных обещаний , и количество средств, заблокированных в таких обещаниях. Этот блокчейн или две рабочие цепи в асинхронном случае должны будут явно ссылаться на предыдущие блоки по их хэшам. Тем не менее, общий механизм остается прежним.
5.1.8. Проблемы для сложных смарт
- контрактов платежного канала. Обратите внимание, что, хотя конечное состояние сложного платежного канала все еще невелико, а чистая финализация проста (если обе стороны договорились о причитающихся суммах и обе подписали свое соглашение, больше ничего не остается делать), метод односторонней финализации и метод наказания за мошенническое поведениенужно быть более сложным. Действительно, они должны быть в состоянии принять доказательства плохого поведения Меркле и проверить, более сложные транзакции блокчейна платежного канала были обработаны правильно.
Другими словами, смарт-контракт платежного канала должен иметь возможность работать с доказательствами Merkle, проверять их хэш-валидность и должен содержать реализацию функций ev_trans и ev_block (см. 2.2.6) для блокчейна платежного канала (виртуального).