Расчет офлайн-транзакций

Пример использования

Мой вариант использования связан со сценарием, в котором и покупатель, и продавец имеют автономные кошельки с балансом, подтвержденным в блокчейне.

  1. Для начала скажем, что кошельки продавца и покупателя показывают балансы 20 BTC и 10 BTC соответственно. Эти балансы подтверждаются в блокчейне.
  2. Затем пусть между продавцом и покупателем будет несколько транзакций, чтобы баланс всегда обновлялся локально только в кошельках.
  3. Все транзакции в 2 выше происходят в автономном режиме; т.е. нет доступа к сети. Период отсутствия доступа может исчисляться днями.
  4. Когда-нибудь в будущем, когда один или оба кошелька будут онлайн, все офлайн-транзакции будут опубликованы в блокчейне и подтверждены.

Блокчейн Синхронизация

В этот момент могут произойти две вещи.

Во-первых, кошельки настолько безопасны, что все обновления (зачисления и дебетования) происходят локально без необходимости «синхронизироваться» с блокчейном. Единственный раз, когда кошельки могут синхронизироваться с блокчейном, — это публиковать транзакции и их последовательность; а также обновить свой кошелек кредитами, которые произошли с момента последнего выхода кошелька в сеть. Или регулятивное давление требует публиковать данные о транзакциях каждую установленную частоту.

Во-вторых, все обновления кредита выполняются в кошельках через блокчейн. Это требование является достаточной мотивацией для поиска сетевого подключения; даже если это раз в неделю или реже.

Вопрос

В любом случае мы рассматриваем сценарий, в котором значение, подтвержденное блокчейном, используется в транзакциях в автономном режиме для последующего подтверждения онлайн. Как мы это реализуем?

Аналогия

Кондукторы автобусов могут выдавать билеты с помощью автономного автомата пассажирам, которые садятся в автобус в различных точках на протяжении всего пути. Когда автобус достигает пункта назначения, автомат используется в депо для получения списка проданных билетов и собранной суммы. Таким образом, это пример автономной транзакции, в которой транзакции «урегулированы», когда «подключение» в конечном итоге становится доступным.

Порождено: https://bitcoin.stackexchange.com/a/41356/6975

Это очень похоже на то, как реализована сеть Lightning. молния.сеть
Не могли бы вы уточнить? Я читал их pdf-файл здесь — lightning.network/lightning-network-summary.pdf Мой ключевой момент заключается в том, что два кошелька, баланс которых может быть подтвержден бухгалтерской книгой, могут выполнять транзакции без необходимости повторного подключения к сети. После подключения они задним числом получают/отправляют свои транзакции в бухгалтерскую книгу, а также обновляют свои кошельки. Я думаю, Lightning Network — это своего рода условное депонирование.
Итак, что необходимо, так это метод экспорта/импорта подписанных транзакций в мемпул напрямую, минуя широковещательные механизмы. Хорошая идея. Вам следует рассмотреть возможность обсуждения этого на [bitcoin-dev] или опубликовать его под заголовком функции на GitHub .
Кроме того, даже если одна часть решит никогда не подключаться к сети или отказаться от транзакций до их трансляции, узел другой стороны должен быть способен сохранять и транслировать транзакции без их предварительного сброса.
@willtech в точности соответствует моему мнению (о вечеринке, которая никогда не будет онлайн)! Как вы понимаете mempoolи обход трансляции?
Я могу создать транзакцию даже в автономном режиме с помощью Bitcoin Core. Эта транзакция находится в мемпуле. Обычно, когда узел находится в сети, он транслирует транзакции другим узлам, они также поступают в мемпул этих узлов. Все, что требуется, — это экспорт транзакции, который предоставит простой текст подписанной транзакции на одном конце и функцию импорта на другом конце. Каждая сторона может обмениваться транзакциями в автономном режиме, и когда какая-либо из сторон подключается к сети, все транзакции должны транслироваться.
Это означает, что импортированные транзакции должны будут поступать в мемпул по специальным правилам, чтобы они никогда не удалялись. Обычно транзакция удаляется из мемпула через определенный период времени, но обычно ожидается, что транзакция будет подтверждена до этого.
Аналогия плохая: транзакции рассчитываются , когда клиент получает билет, а оператор получает деньги. Транзакции просто подсчитываются , когда плата за проезд возвращается в депо. Это большая разница. Во-первых, никогда не бывает отрицательного баланса, который может повлиять на клиента в результате синхронизации автономного реестра с основным реестром, в отличие от возврата бумажных чеков. Во-вторых, невозможно устранить несоответствие между подсчитанными в депо билетами и фактически проданными билетами (некоторые могли быть утеряны, уничтожены и т. д.). Также: сильный мотиватор для занижения отчетности (кондукторы могут украсть разницу).

Ответы (2)

Я бы сказал, что здесь есть ряд проблем. Если система находится «в автономном режиме», то единственное обновление, которое вам нужно будет сбалансировать, — это то, что было сохранено последним. Здесь предполагается, что оба источника являются надежными, а система в середине является надежной. Можно также сделать это централизованной асинхронной системой. В этот момент у вас будет гораздо больше контроля и меньше зависимости от сторонних инструментов.

Предложенная система была бы «хорошей», но тем временем решением было бы разработать внутреннюю бухгалтерскую книгу. Вы знаете сторону А и сторону Б. Вы знаете их балансы и доверяете их транзакциям. Эта система предполагает, что вы также знаете их ключи или можете получить их по мере необходимости.

На основе самого последнего баланса храните свои транзакции в обычной БД. Текущий баланс, опять же, основанный на самой последней информации. Всякий раз, когда узел может подключиться, обновляйте текущие балансы (доверяйте, но проверяйте), проверяйте любые предыдущие транзакции, которые вы могли отправить, на наличие сбоев (отсутствие газа, неправильная транзакция, нехватка средств и т. д.), а затем обрабатывайте транзакции.

Если есть транзакции A -> B и B -> A, вы можете разрешить балансы транзакций внутренне (при условии, что это законно для того, что предназначено). В противном случае вы можете использовать любую логику для разрешения каждой транзакции. Обобщить:

  1. Используйте внутреннюю систему для отслеживания что к чему. Что оплачено, что должно быть оплачено.
  2. Когда узел соединяется, получите как можно больше информации. Текущий баланс, подтвержденные транзакции из предыдущих представлений, транзакции, которые все еще ждут подтверждения. Выявление транзакций, которые по какой-либо причине полностью завершились неудачно (это предполагает короткое «время безотказной работы» для соединения с узлом. Он не будет оставаться на связи достаточно долго, чтобы транзакции достигли первого блока), все еще находящиеся в мемпуле (недостаточно газа для быть подобранным и черствым) и т. д.
  3. Процесс, основанный на приведенной выше информации. Транзакции в конечном итоге будут разрешены или не разрешены. FIFO можно использовать для разрешения самых старых транзакций, или, если идеальная ситуация состоит в том, чтобы сначала разрешить наибольшее количество транзакций, независимо от возраста, тогда крупная транзакция может остаться незавершенной, в то время как многие другие транзакции будут обработаны.

Все это вопрос баланса между «доверием» и «временем». Если у меня есть 2 кошелька, и только у меня есть ключи, я могу запускать каждую транзакцию в серверной системе, отслеживая, какой она должна быть, и разрешать ее, когда захочу.

Предлагаемое предложение представляет собой баланс между доступными технологиями (и обстоятельствами), безопасностью и точностью.

«Здесь предполагается, что оба источника являются надежными, а система в середине — надежной». Доверие исходит из подтвержденного баланса в блокчейне. Не уверен насчет системы посередине. Суть этого вопроса в том, чтобы устранить центральную систему (как упоминалось в этом ответе).
Мой ответ и предположение основаны на следующем: «Во-первых, кошельки настолько безопасны, что все обновления (зачисления и списания средств) происходят локально без необходимости «синхронизироваться» с блокчейном». Для меня это означает, что доверие может быть получено без взаимодействия с блокчейном. Если это не так, то доверие всегда падает до нуля, если вы не можете сначала отправить цепочку и подтвердить, что транзакция действительна, потому что криптовалюту уже можно потратить в другом месте. Таким образом, это работает только при неявном доверии обоих источников к тому, что средства не будут потрачены, пока эта система находится в автономном режиме.
Подождите, я думаю, что понял вашу точку зрения. Вы говорите, что кошельки не могут взаимодействовать за пределами узла, поэтому они могут заниматься своими делами на этом узле без синхронизации с остальным миром. Почти как внутренняя книга. Я рассматривал это как способ для двух доверенных кошельков разрешать транзакции и использовать блокчейн в качестве «окончательной» записи. Так что я думаю, я понял, что вы намереваетесь сейчас. В целом, из-за необходимости подтверждения того, что транзакция действительна, я не вижу, как это может быть выполнено без чрезвычайного доверия и / или процесса разрешения со стороны центрального органа.
«Почти как внутренняя книга». Бинго! Я знаю, это сильно растягивает. Следовательно, другой вариант обновлений, когда доступно подключение.

Этого можно добиться, используя соединение Bluetooth/NFC с уникальным кошельком (должен быть одинаковым для обеих сторон), способным хранить зашифрованные офлайн-транзакции без их фактической синхронизации с блокчейном. Однако, что касается платной стороны, первоначальные средства должны поступать от покупки и синхронизации с блокчейном.

Насколько мне известно, сеть Lightning все еще находится в стадии разработки. Есть еще проблемы, которые необходимо решить, особенно в отношении возможного введения системы в заблуждение, чтобы она поверила, что вы получили платеж от кого-то, кто на самом деле НЕ отправил его - путем повторения (реальной) предыдущей транзакции, как в «человеке посередине».

Я не думаю, что биткойн работает через Bluetooth или даже любой существующий кошелек позволяет это делать.
Расчет офлайн-транзакций
СпросиСетьПолитика конфиденциальности1y, 0v