Как устроен блокчейн

[CasinoUpdate]

Давайте выясним, как построена система блокчейн, чтобы по-настоящему эффективно раскрыть весь потенциал того, на что этот самый блокчейн способен. А также постараемся укрепить наше понимание к его будущим мотивам, последствиям и принятию решений для потенциальных вариантов использования и инноваций.

Чтобы постепенно понять общую картину, давайте начнем с простого примера - «сценария с доской».

Три соседа по дому, Алиса, Боб и Чарли живут вместе, снимая квартиру. Примерно каждые две недели они собираются вместе, чтобы оплатить свои счета и долги. Они используют доску для ручной записи всех счетов с указанием задолженностей. Для простоты мы можем назвать линию ввода-вывода транзакцией (TXN), инициированной отправителем.

Все из них могут добавить TXN в любое время. Итак, Алиса должна Бобу 20 фунтов, затем Боб должен Чарли 30 фунтов, затем Алиса должна Чарли 10 фунтов. Все они хорошие друзья и доверяют друг другу. Однажды, младший брат Алисы, Дейв посетил их общую квартиру. Будучи большим шутником, Дейв добавил новую строку, где Боб должен Алисе 50 фунтов стерлингов. К счастью, Алиса вовремя заметила его шалость и стерла эту запись. Иначе, если бы никто не заметил этого, то Боб должен был бы отдать Алисе 50 фунтов безосновательно. А это, в свою очередь, могло бы поставить под угрозу дружбу и доверие друг к другу, особенно если Боб обнаружил бы это позже.

Чтобы этого не случилось, все три соседа по дому согласились, что при авторизации их TXN они поставят подпись, чтобы каждый мог видеть линию ввода-вывода информации полностью, с подписью контрагента-получателя. Однако этот метод не так практичен, так как места на доске вскоре становится недостаточно для записи всех TXN, часто свободное место заканчивается еще до даты расчета.

Затем они подумали, что, возможно, будет лучше записать TXN в электронном виде - в таблицу Excel, чтобы решить проблему с ограниченным пространством на доске. Они могут реализовать этот вариант довольно легко, поскольку все еще живут вместе. Но затем Боб и Чарли должны были уехать на долгие 6 недель, и все друзья согласились, что могут использовать Excel дистанционно, для удаленного добавления TXN. Таким образом, все будут вести учет, и посылать обновленные (распределенные) данные друг другу.

У вас может возникнуть вопрос, как они будут решать проблему с использованием индивидуальной подписи для авторизации TXN. Использование подписи на основе рисунка рядом с TXN больше не работает для обеспечения авторизации, поскольку ее можно легко скопировать с помощью простого действия «вырезать и вставить». Опять же, Дейв добавляет еще одну строку в записи Алисы: 100 фунтов от Чарли Алисе; и копирует подпись Чарли рядом с этой строкой. Именно поэтому друзья должны найти уникальный способ авторизации TXN, который не может быть подделан, в то же время, позволяя обновлять регистр удаленно.

Вскоре они узнали о возможности использования «цифровой подписи». Она обеспечивает уникальную подпись для отдельного TXN, в то же время, позволяя всем проверять и подтверждать как авторизацию, так и содержимое каждого TXN. Более того, пользователи могут делать это удаленно и обновлять электронную таблицу децентрализовано. Фактически, каждая цифровая подпись создается уникально для каждого отдельного TXN и никогда не может повторяться, обеспечивая безопасный способ аутентификации.

Пример с последней строкой показывает, как ложная цифровая подпись немедленно будет отклонена, поскольку Чарли не авторизовал ее. Соответственно, для получения доступа должен использоваться личный ключ Чарли (или пароль) для создания уникальной цифровой подписи, чтобы авторизовать этот конкретный TXN. Подмена Дейвом оригинального TXN фальшивым не сработает, его легко определить (делая проверку остальными) и, в конце концов, удалить из таблицы.

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

Это эффективно, потому что использование цифровой подписи и криптографии обеспечивает защищенный от несанкционированного доступа механизм авторизации и аутентичности (или целостности) каждого TXN, а страница электронной таблицы позволяет каждому отслеживать порядок и периодические расчеты TXN.

Фактически, каждая страница электронной таблицы может рассматриваться как «блок», объединяющий эти подтвержденные TXN.

• Электронная таблица = просто распределенный инструмент записи = бухгалтерская книга

• «периодически» структурировать информацию в последовательном порядке = протокол

• разрешение постоянного обновления / согласование новых TXN = цепочка

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

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

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

Что если сеть вырастет до сотен тысяч узлов и превратится в очень большую распределенную сеть?

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

б) Как узлы могут синхронизироваться между собой? Как они дают согласие на запись?

в) Как предотвратить проблему двойных расходов? ** Двойные расходы – это когда человек может инициировать два TXN одновременно, и при этом он может заплатить только за один из них.

Ответ на все эти вопросы заключается в том, каким способом можно достичь истинного консенсуса. Фактически, разница между централизованным и децентрализованным регистром заключается в необходимости достижения консенсусного соглашения. Задавая себе эти вопросы, мы начали выходить за рамки простой проверки TXN, объединяя основные функции, что необходимы для функциональной децентрализованной системы управления на основе того же консенсуса.

Примечание. Важно отметить, что валидация и согласование TXN - это два совершенно разных процесса. И хотя объединить их в одно целое на более поздней стадии не составит труда, необходимо всё же уметь различать эти два процесса, чтобы не допустить путаницы в понимании ситуации. Такое явление является общей проблемой при идентификации особенностей технологии блокчейна.

Истинный консенсус звучит следующим образом: все согласны только с одной версией истины. Это означает, что я знаю, что я вижу, и в то же время это совпадает с тем, что видите вы. Но как же все узлы такой системы могут прийти к общему согласию? (Абсолютно единодушное согласие - заставить все узлы «однозначно» договориться об истинности записи!)

Чтобы достичь этого единого консенсуса, необходимо наличие достаточного количества времени, чтобы все узлы по отдельности увидели и подтвердили каждую TXN хотя бы один раз. Стоит задать себе вопрос: есть ли веский довод в сегменте Биткоина тому, что Сатоши намеренно дает 10 минут для генерации каждого нового блока? Сделано ли это таким образом, чтобы все TXN имели возможность распространяться узлами по всему земному шару и быть «в синхронизации» на протяжении определенного отрезка времени?

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

Это похоже на «проблему византийских генералов»: «Группа генералов византийской армии расположилась лагерем со своими войсками вокруг вражеского города. Общаясь только через посланника, генералы должны согласовать общий план сражения. Однако один или несколько из них могут быть предателями, которые попытаются сбить с толку других. Задача состоит в том, чтобы найти алгоритм, который обеспечит согласие верных генералов».

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

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

Майнинг в этом контексте представляет собой процесс консенсуса, основанный на испытаниях, который призван мотивировать:

1) рост числа узлов - в сторону поддержки распределенной сети

2) рост бухгалтерской книги - в сторону сохранения истории записи путем создания непрерывной «цепи».

Помните, что в биткоинах этот процесс происходит децентрализовано, при этом достигается консенсус путем решения довольно сложной математической задачи - Proof of Work (алгоритм консенсуса). Математическая составляющая должна быть достаточно сложной, чтобы поддерживать такие постулаты, как «Истина» и «Доверие», а также для обеспечения согласованного «порядка» записи TXN, который должен быть абсолютно неизменным и необратимым с самого момента принятия.

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

а) можно потерять цель и ценность истинного консенсуса

б) системе не хватает времени для того, чтобы регистр синхронизировался в другой части земного шара

c) блокчейн открыт для возможной атаки в уязвимости консенсуса, таким образом, возможны внесения изменений в протокол

г) система не может эффективно решить проблему двойных расходов

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

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

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

Продолжение следует...

 

[CasinoUpdate]

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

Хотя рынок криптодоменов по-прежнему находится на нижних позициях, твердая вера в эту децентрализованную технологию остается непоколебимой. Особенно в отношении концепции взаимной передачи ценностей, а также будущего институционального сотрудничества. Надеемся, что эта лекция может помочь большему количеству людей лучше понять и увидеть более широкую перспективу технологии блокчейна. А также приоткрыть занавес в вопросе о ее потенциальном влиянии на наш будущий мир.

Биткойн. Мы все знали, что все, что следует за блокчейном, является результатом знаменитой публикации Сатоши Накамото. (Никто не мог сказать уверенно, что он действительно понимает блокчейн. (Ведь большинство не могли даже толком осознать основу этой первой идеи).

Первое предложение из презентации данной концепции суммировало общие цели и намерения всей системы. А именно, пиринговые (p2p) «электронные наличные деньги», которые можно отправлять из пункта А в пункт В напрямую, без прохождения через системы идентификации и проверки. Ключевые слова - НАЛИЧНЫЕ и Электронные! Однако позднее стало понятно, что именно децентрализованная технология, стоящая за биткойнами, оказывает гораздо более сильное влияние, чем предполагалось изначально. В биткойнах передача значения p2p происходит в цифровой валюте, хотя в дальнейшем она может быть связана с другими активами в виде различных криптовалют для разнообразия передачи значения p2p.

Итак, давайте сначала посмотрим, как мы можем внедрить и достичь этого эффекта «электронной налички» на высоком уровне. Ниже приведены свойства настоящих наличных:

• Во-первых, наличные деньги являются активом на предъявителя. (Поскольку это мое, единственный способ забрать деньги из моего кармана - конфисковать их у меня).
  
  
• Во-вторых, наличные деньги - это пиринговый инструмент: (Я могу совершить оплату напрямую; нет сторонних организаций, на которых мы должны полагаться; так как физически мы находимся рядом).
  

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

Итак, как же вам нужно эмулировать электронную (или цифровую) p2p-версию системы наличных без постороннего лица на каком-либо расстоянии? - Другими словами, как создать систему без разрешений, без централизованного контроля, позволяющую переводить деньги с помощью системы суверенного управления? Кроме того, как это можно сделать в электронном виде?

Более того, как решить проблему «двойных расходов» и гарантировать надежный процесс перевода денежных средств? (учитывая фактор расстояния). Как отправитель узнает, что платеж доходит до получателя? Или как получатель обеспечивает оплату до отправки товара или совершения каких-либо дальнейших торговых действий?

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

(Очевидно, что свойства наличных также должны быть приняты во внимание, например, долговечность и т. д., но ключевой момент здесь состоит в том, что Биткойн устойчив к взлому. Его защита не была взломана ни разу с момента своего существования. Однако, взлом систем электронных кошельков, это отдельная проблема безопасности обмена при сохранении этих скрытых ключей).

Концепция Биткоина на самом деле довольно революционная и разрушительная. По факту, биткойн-революция позволяет наличным средствам функционировать в электронном виде без централизации этого процесса!

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

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

Фактически мы говорим о будущей потенциальной стандартизации:

1) Автономная передача стоимости / активов - разумный способ глобального управления движением ценностей (т. е. любые формы активов, не только деньги);

2) По-настоящему пиринговая (p2p) система - быстрое внедрение без каких-либо барьеров, быстрый и легкий доступ к осуществлению и получению платежей или передаче ценностей / активов;

3) Альтернативные сервисные активы - Smart Contracts, Token, используемые для передачи альтернативной стоимости в нотариальных сервисах, регистрации фактов владения / покупки;

4) Institutional Collaboration (IC) - решение, основанное на инфраструктуре и деятельности предприятий, позволяющее различным органам / организациям устранять конфликтные ситуации и снижать высокие затраты на обмен услугами. (переход от традиционных IT-услуг к будущим технологиям IC).

Распределенные сети и криптография уже давно существуют индивидуально в своей области. Этим они обязаны гению Сатоши Накамото, который объединил их, чтобы создать модель, позволяющую сетям компьютеров «сотрудничать» по-новому для поддержания общей и в то же время защищенной базы данных.

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

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

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

Использование криптографии (алгоритмов цифровой подписи и хеширования) не только служит для аутентификации и защиты, но также является упрощением подачи данных для целей цифрового представления и шифрования (т. е. Merkle Root или дерево хешей). Короче говоря, биткоин можно рассматривать как распределенную защищенную базу данных с наличием алгоритма консенсуса.

_________________________________________________

 

[CasinoUpdate]

Обзор биткоинов:

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

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

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

_________________________________________________

Как правило, процесс проверки может быть разделен на две категории:

1) Проверка по отдельной трензакции

2) Проверка по периодическим расчетам (группировка нескольких транзакций)

UTXO = неизрасходованный вывод транзакции; TXN = транзакция

Создание транзакции начинается, как правило, с цифрового кошелька в качестве средства для инициирования или принятия платежа. На представленной схеме продемонстрирована взаимосвязь Digital Wallet, пары ключей и нескольких связанных лиц, ссылающихся на конкретного пользователя, и порядок их создания:

Закрытый ключ -> Открытый ключ -> Хэш открытого ключа -> Адрес биткоина

Закрытый ключ (sk) используется для подписания транзакций, чтобы совершить оплату биткоинами путем создания цифровой подписи в процессе хеширования и шифрования, показанном выше. Открытый ключ (pk) используется для заявления прав и получения биткоинов. Очевидно, что этот алгоритм будет автоматически генерироваться в цифровом кошельке после того, как пользователь прошел надлежащий процесс «Know Your Customer» верификации (KYC). Цифровой кошелек может содержать до нескольких пар ключей. Что, в свою очередь, также может служить причиной к созданию нескольких разных адресов. Пользователи Биткоин обычно знают об использовании QR-кода, который ссылается на фактический адрес (его номер обычно начинается с 1 ....).

Как упоминалось ранее в первой части, отправитель использует цифровую подпись (Sig) для авторизации TXN, одновременно позволяя узлу проверять содержимое TXN вместе с открытым ключом (pk), при этом не раскрывая секретный ключ (sk). Каждый узел в сети может проверять и принимать TXN на индивидуальном уровне посредством предоставления как Sig, так и pk, тем самым подтверждая, что лицо, передающее биткоины, имеет соответствующее право собственности.

Возможно, будет полезным привести пример создания транзакции в биткоинах на примере чека. Чек обычно ссылается на конкретную учетную запись в качестве источника, чтобы проверить остаток средств на 1) входе, чтобы заплатить кому-то; на 2) выходе с уточнением; 3) от общей суммы.

Однако в случае с биткоинами вход фактически ссылается (указывает) на конкретную предыдущую транзакцию (или транзакции) в формате вывода неизрасходованных транзакций (UTXO). Это необходимо, чтобы требовать и подтверждать владение (-я) с использованием цифровой подписи (подписей) отправителя и открытый ключ (pk). В то же время процесс Вывода создает новый UTXO, ссылаясь на следующий запрос, указав хеш открытого ключа получателя (pk #) в качестве условия для следующего утверждения.

Таким образом, осуществление платежа в биткоинах означает, что оба действия: а) требовать соответствующего предыдущего UTXO (или нескольких) и b) создать следующий UTXO (или несколько) будут происходить одновременно в создании одного TXN. Фактически, биткоин можно рассматривать как отчет о передаче права собственности от одной стороны другой.

Основным строительным блоком TXN биткоинов является вывод неизрасходованных транзакций (UTXO). UTXO - это неделимый кусок BTC, который привязан к конкретному владельцу. Он записан на блокчейне и распознан всей сетью биткоинов.

• UTXO «потребляется» транзакцией = Ввод.
  
  
• UTXO, «созданный» транзакцией = Вывод.
  

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

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

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

Все транзакции имеют вход и вывод, кроме моноблочной транзакции, которая имеет только вывод. Это показано в первой записи каждого блока, где победивший майнер платит себе вознаграждение после доказательства выполнения работы (PoW). Это работает также, как и создание нового биткоина, которое происходит каждые 10 минут.

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

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

Ввод указывает на предыдущий UTXO (или несколько). Поэтому чтобы требовать его (или их), TXN должен предоставить соответствующий сценарий разблокировки - ScriptSig, который содержит PubKey (открытый ключ) и цифровую подпись.

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

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

Как упоминалось ранее, биткойн-транзакция описывается с использованием ее компонентов ввода и вывода:

1) Ввод: указатели направляют на предыдущие UTXO (или несколько), чтобы использовать или требовать их

2) Вывод: указатели направляют на грядущие UTXO (или несколько) для их создания

Вот быстрый пример, в котором Алиса платит Бобу 10 BTC.

Если Алиса совершает оплату традиционным способом, выписывая чек, то клиринговая система на заднем плане должна будет проконсультироваться с банком Алисы, чтобы выяснить, а) действительно ли Алиса санкционирует проверку путем сравнения подписи; б) у банка Алисы достаточно денег для осуществления процесса корректировки дебета/кредита банковских счетов Алисы и Боба.

Первым делом в системе биткоинов цифровой кошелек Алисы должен удостовериться в достаточной сумме, чтобы заплатить Бобу 10 BTC. Он может это сделать, отыскав информацию о предыдущих платежах (или указав на вывод невостребованных транзакций - UTXO), которые получила Алиса. Мы можем видеть, что Джо и Кен ранее заплатили Алисе 5BTC и 7BTC соответственно, а сумма обоих составляет 12BTC, что достаточно для выплаты 10BTC Бобу. Любые дополнительные средства (2 BTC) будут возвращены отправителю в качестве сдачи. Обратите внимание, что для Боба и самой Алисы на выходе создаются два новых UTXO. Если бы Алиса не получила возврат ее, это могло косвенно считаться платой за транзакцию.

Вот один из примеров транзакции с BTC.com с отображением информации о вводе и выводе, а также соответствующими сценариями (скриптами) ввода и вывода.

скрытый контент

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

В отличие от транзакции по кредитной карте, транзакция в биткоинах не содержит секретной и конфиденциальной информации. Следовательно, она может передаваться и транслироваться любым способом и даже по незащищенным каналам, онлайн или офлайн. (Это только вопрос времени, когда транзакция будет проверена и подтверждена). Фактически, любой может создать и выполнить биткоин-транзакцию!

Вот простой и наиболее распространенный пример для проверки TXN, где используется Pay-to-Public-Key-Hash (P2PKH). Алиса платит Бобу, а Боб платит Чарли. Проверка выполняется одновременно, с помощью простого двухэтапного процесса:

A. Доказательство претензии - EqualVerify (с помощью PubKey #)

B. Доказательство TXN - CheckSig (по цифровой подписи)

Процесс А:

Ранее Алиса получила свой BTC от Джо (в 1-й ячейке слева). Она заявила об этом, предоставив свой PubKey [PA] через скрипт разблокировки вводных данных. Затем она платит Бобу, создавая UTXO вывода с помощью скрипта блокировки. Данный скрипт указывает хеш BobK PubKey, [#PB] в качестве условия для следующего заявителя. Что касается Боба, то для получения предыдущего UTXO (вывод Алисы) Боб должен предоставить свой PubKey [PB] (и цифровую подпись [SigB]) при процессе ввода в качестве сценария разблокировки. (Обратите внимание, что [SigB] создается с закрытым ключом и с использованием данных текущего TXN).

Процесс Б:

Очевидно, что у Боба есть право PubKey, [PB]. Таким образом, когда Боб платит Чарли, единственное, что отличает Боба от других, это то, что Боб - единственный человек, способный подписать данные своим личным ключом (в текущем TXN Боба). Это нужно сделать для того, чтобы создать уникальную цифровую подпись [SigB], которую никто не сможет подделать, не имея данных о секретном ключе Боба. Кроме того, данные в текущем TXN Боба могут просматриваться всеми узлами (то есть любыми верификаторами, а также самим Чарли). Данные можно хешировать, чтобы получить уникальный результат - #data, который не может быть подделан (потому что при внесении любых изменений отобразится другая #data, которая не может быть проверена с помощью цифровой подписи). Это делается на заключительном этапе CheckSig в процессе проверки.

Проверка транзакции на самом деле выполняется с помощью двух составляющих: а) сценариев разблокировки (из текущего ввода) и б) сценариев блокировки (из предыдущего вывода) и объединяет их вместе, как показано в однострочном сценарии проверки. Фактически, каждый UTXO, указанный во входных данных, имеет свой уникальный однострочный сценарий, который дает разрешение на проверку, а каждое требование UTXO должно пройти один и тот же процесс, чтобы вся транзакция стала действительной.

После того, как UTXO заявлены и успешно проверены, Боб может потратить их, создав следующий UTXO для Чарли с помощью CharKie's PubKey # [#PC] - указанного в скрипте блокировки на выводе.

Протокол стека используется для подтверждения биткоин-клиентом, который является базовым процессом, состоящим только из действий Push (добавить) и Pop (удалить).

Ниже представлен алгоритм данной системы:

а) во-первых, Sig Боба - [SigB] (из скрипта разблокировки) следует поместить в стек

b) затем, PubKey Боба [PB] (из скрипта разблокировки) следует поместить в стек

c) [PB] вставьте в b), продублируйте и вставьте в стек

d) Выполните двойное хеширование <hash160> на c), чтобы получить хеш PubKey для проверки [#PB]

e) ** Возьмите желтый [#PB] из предыдущего скрипта блокировки UTXO и нажмите на стек

f) EqualVerify = Проверьте, совпадают ли два верхних [#PB], если да, удалите их. Если нет, отклоните TXN.

g) CheckSig = Выполните 1) хеширование данных TXN и 2) расшифровку с помощью Sig и PubKey, затем получите результат: True / False.

Если True, TXN действителен и может быть передан последующему узлу для повторной проверки. Если какой-либо из вышеперечисленных шагов не удался, то отклоните TXN. Как упоминалось в предыдущих слайдах, на самом деле есть два процесса проверки:

1) e) и f): во-первых, соответствует ли pubkey текущего заявителя «PubK #», указанному в предыдущем сценарии блокировки?

2) g): если так, то подтвердите это, сравнив результаты хеширования. (обсуждалось ранее в разделе Digital Sig)

Первая проверка в 1) имеет решающее значение для «связывания» соответствующего условия (текущий сценарий разблокировки с предыдущим). Если есть совпадение, то 2) проведет дальнейшую проверку данных, предоставленных в текущем TXN. (Двойная проверка обеспечивает надлежащий контроль, потому что заявитель сделал цифровую подпись #data в текущем TXN с закрытым ключом. Пара ключей позволяет любым верификаторам (узлам) использовать только открытый ключ и цифровую подпись, которые предоставляются плательщиком в текущем TXN для дешифровки полученной #data. В то же время верификатор также имеет фактические текущие данные TXN, которые верификатор может хэшировать. Если оба эти результата совпадают, то заявитель является подтвержденным).

<#PB - yellow> на самом деле является условием, установленным в предыдущем скрипте блокировки, где текущий заявитель должен будет подтвердить и доказать правильность, предоставив как открытый ключ, так и цифровую подпись.

На этом слайде объясняется отказоустойчивый тест для процесса проверки транзакции.

Итак, что же остановит Фреда (мошенника), вмешивающегося и модифицирующего TXN и пытающегося потратить UTXO Алисы? Что мешает Фреду притвориться Бобом и попытаться получить UTXO из скрипта блокировки Алисы?

Вот 3 теста, которые проводятся с помощью верификатора (любых узлов) для проверки случаев сбоя.

1) Тест 1: если Фред использует свой PubKey [PF] в сценарии (скрипте) разблокировки (вместе со своей подписью [SigF]), проверка завершится ошибкой стека EqualVerify, поскольку hash160 этого PF; [#PF] не будет совпадать с #PB, предоставленным в предыдущем скрипте блокировки Алисы, который определяет состояние UTXO. Другими словами, Фред НЕ является законным взыскателем. На данном этапе проверка останавливается, а TXN Фреда будет отклонен.

2) Тест 2: На этот раз Фред пытается использовать PubKey Боба в сценарии разблокировки, но у него есть только собственный закрытый ключ [SF] для создания цифровой подписи [SigF]. Хотя Фред может передать EqualVerify, он не сможет выполнить следующий CheckSig, потому что продукт дешифрования (#M) из его [SigF] и BobK PubKey [PB] не будет таким же, как #X (то, что каждый узел способен извлекать из данных в текущем TXN). Расшифровка не будет работать, если применяется не ключевая пара. Правильный #X может быть получен только в том случае, если оба параметра BobKE PubKEy [PB] и Signature [SigB] будут применены на вводе процесса описания для получения одинакового #X.

3) Тест 3: Затем Фред подумал, что если он также изменит содержимое данных (потому что он думает, что может обмануть каждого новым набором хэширования измененных данных - #N) и будет использовать PubKey [PB] Боба (который нужен ему для того, чтобы передать EqualVerify) и новый [SigF] (от нового #N и его закрытого ключа)? Опять же, это приведет к сбою CheckSig (#N не будет таким же, как #M), потому что подпись Фреда [SigF] генерируется его закрытым ключом [SF], и только пара ключей его PubKey [PF] может обеспечить тот же самый результат #N. Но все узлы будут использовать [PB] вместо [PF] во время проверки, что приведет к совершенно другому результату хеширования от #M.

Пока используется [PB] Боба (вместо пары ключей [PF] - [SF]), конечный результат хеширования будет совершенно другим, что является главной особенностью цифровой подписи, защищающей TXN от любых модификаций мошенничества и предоставления единой версии результата хеширования после процесса шифрования + хеширования.

Для тех, кто нуждается в изучении основных понятий криптографии, вот еще одна попытка.

 

[CasinoUpdate]

Общая криптография

1) В основах криптографии, общий процесс шифрования и расшифровки (E & D) всегда требует пары ключей для работы; а именно S и P. Для простоты объяснения на самом деле не имеет значения, какой ключ применяется первым. Если пара ключей совпадает, то сообщение [A] может быть полностью восстановлено. В этом случае [X] может рассматриваться как промежуточный продукт зашифрованного текста. (Скремблирующее сообщение).

2) Это означает, что использование другого ключа [Q] приведет к неправильному сообщению или просто к другому зашифрованному тексту, который не имеет смысла для получателя.

3) Для шифрования с «открытым ключом», конечно, имеет смысл для отправителя зашифровать сообщение открытым ключом получателя, чтобы получатель был единственным, кто способен расшифровать сообщение с помощью закрытого ключа.

4) Но тогда возникают другие проблемы: авторизация и подтверждение целостности

а) Проверка авторизации: как получатель узнает, что сообщение действительно отправлено отправителем? В этом простом процессе E & D нет способа подтвердить авторизацию отправителя сообщения. На самом деле, любой может использовать открытый ключ получателя для шифрования поддельного сообщения и отправки его получателю, притворяясь отправителем (если только получатель не подтвердит самого отправителя).

б) Проверка целостности: как получатель узнает, что содержимое остается неповрежденным и неподдельным? Невозможно проверить, было ли сообщение «математически» перехвачено хакером во время передачи и может ли быть изменено содержимое. Отправитель и получатель могут даже не знать о взломе, если никто не обнаружит или не заметит сам взлом.

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

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

Одним из примеров функции хеширования является SHA256, который представляет собой алгоритм безопасного хэширования. Данный алгоритм создает 256-битный двоичный код фиксированной длины на своем выходе, независимо от того, что применяется к его входу. Кроме того, в SHA256 применение одного и того же ввода всегда приводит к одному и тому же выводу.

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

Другими словами, подделать фиксированные 256-битные выходные данные хеш-функции для Collision Attack действительно трудно, особенно учитывая отсутствие пределенного ввода к хэш-функции, которая и создает этот конкретный вывод.

Это потому, что 2^256 - это, примерно, 4 миллиарда (B) испытаний, умноженные еще 8 раз:

4B x 4B x 4B x 4B x 4B x 4B x 4B x 4B.

Следовательно, рандомизированный эффект, который дает довольно уникальный результат в любой момент времени с хэш-функцией SHA256, буквально неразрывен. (если другая продвинутая математика не превалирует над созданием сверхбыстрого решения; т.е. квантовая математика).

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

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

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

Цифровая подпись осуществляется путем введения функции хеширования в процесс шифрования, а затем (с использованием личного ключа отправителя ) для шифрования хэш-версии сообщения [Strawberry] (клубника) с целью создания уникальной цифровой подписи [Sig]. Вкратце, отправитель должен «подписать» сообщение в цифровой форме, чтобы предоставить проверочную версию авторизации для TXN через [Sig]. Благодаря этому целостность и подлинность сообщения также может быть обеспечена с помощью проверки [Strawberry] позже.

В биткоинах SHA256 используется для хеширования. Изменение содержимого (даже незначительно) приведет к совершенно другому выводу хеша, а это, в свою очередь - к другой версии [Sig]. Используя правильный открытый ключ [P], получатель (или верификатор) может проверять как целостность сообщения, так и авторизацию отправителя одновременно. При этом соблюдается следующая последовательность:

а) Расшифруйте [Sig] с помощью [P], чтобы получить дайджест хеша [#A];

б) Хешируйте видимое сообщение, чтобы создать еще один дайджест хеша [#B].

Если оба выхода [#A] и [#B] одинаковы, то проверка подтверждается.

Обратите внимание, что выходные данные [#A] и [#B] получаются отдельно для перекрестной проверки друг друга верификатором. Кроме того, они должны точно совпадать с [Strawberry] интуитивно (для объяснения на той же странице). Однако в реальности каждый верификатор должен делать это удаленно, не имея сведений о самой [Strawberry] на первом месте, а используя только 3 полученных компонента: [Sig], [P] и сообщение (т.е. содержимое TXN). Таким образом, даже если получено [#A], оно не может быть подтверждено, пока его не сравнят с [#B] или наоборот.

Вкратце

• функция хеширования обеспечивает целостность сообщения через [#B];
  
  
• [Sig] обеспечивает авторизацию и аутентификацию отправителя через [#A].

Подтверждение прохождения процесса верификации означает, что [#A] = [#B], это условие является обязательным всегда. Если данное условие не подтверждено, то проверка не пройдена, и TXN будет отклонен. На самом деле процесс верификации - это просто проверка «Да» или «Нет».

_________________________________________________

** Помните, суть блокчейна заключается в ЦЕПИ

Поскольку предыдущие 4 узла распределенной сети (показанной в части 1) совместно связаны друг с другом, давайте снова посмотрим на верхний уровень связей, анализируя процессы потока транзакций.

1-й узел проверяет свое содержимое после получения, а затем пересылает его другим узлам. Другой узел также может индивидуально принимать другую транзакцию и выполнять процесс проверки и впоследствии транслировать ее. Каждый узел, в свою очередь, проверит это и передаст его соседним узлам, которые, в свою очередь, выполнят процесс проверки. Если транзакция не была проверена или не прошла процесс проверки (на уровне транзакции), она будет отклонена и полностью проигнорирована. (Мы обсудим процесс проверки транзакции подробно позже).

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

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

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

Проще говоря, блок состоит из следующих полей:

1. Заголовок: хэш этого блока (Blk #)

2. Заголовок: хэш предыдущего блока (ex-Blk #) + другие показанные параметры

3. TXN: каждый узел выберет свой собственный список TXN, который будет включен в новый блок

Заголовок является идентификатором блока, полученного благодаря строгим усилиям Proof of Work (объяснение подано ниже). В заголовке, помимо хэша предыдущего блока (ex-Blk #), есть и другие важные параметры, такие как метка времени, сложность, корень маркера и одноразовый номер. Фактически, ex-Blk # является элементом цепочки, связывающей предыдущий блок с текущим блоком.

Поле «Заголовок» используется для контроля, чтобы отслеживать информацию, связанную с конкретным блоком. В последнем поле проверенные транзакции выбираются из пула памяти каждого узла для входа в это поле, чтобы стать подтвержденными транзакциями после того, как они «проверены» в процессе интеллектуального анализа данных. (Проверка TXN, которую мы видели ранее, все еще «неподтверждена», пока данные TXN не будут успешно помещены в новый блок, извлечены и затем станут частью блока истории).

Майнинг выполняется путем нахождения уникального «дампа времени» (красный), который удовлетворяет определенному математическому требованию, и этот процесс называется Proof of Work.

Вопрос: зачем использовать блочную структуру? Какова основная цель этой системы?

Для того чтобы децентрализованный DLT работал, очень важна способность а) сделать «единственную верную версию» бухгалтерской книги и б) разрешить непрерывное обновление информации в бухгалтерской книге, а также в) подтверждать каждое обновление. Эти действия включают в себя делегирование временного процесса проверки TXN каждому участвующему узлу сначала распределенным способом p2p, а затем структурирование процесса включения этих проверенных TXN посредством периодической проверки с помощью интеллектуального анализа с использованием блочного формата. Нужно понимать, что, поскольку это сделано децентрализованным способом, использование «блока» позволяет периодически синхронизировать обширные наборы уже проверенных, но все же «несинхронизированных» транзакций для достижения полностью согласованной и «единственно верной» базы данных. Блочная структура также позволяет лучше управлять и отслеживать записи.

*** Блочная структура преобразует процесс временной проверки в процесс постоянной проверки посредством периодического подтверждения, получаемого с помощью Proof-of-Work через процесс майнинга.

Хороший согласованный протокол должен иметь следующие свойства:

• Свойство соглашения: механизм консенсуса должен обеспечить как можно большее согласие со стороны группы.
  
  
• Свойство коллаборации: все участники должны стремиться работать вместе, чтобы достичь результата, который ставит интересы группы на первое место.
  
  
• Свойство кооперации: все участники не должны ставить свои интересы на первое место и работать в команде больше, чем отдельные лица.
  
  
• Эгалитарное свойство: каждый голос имеет одинаковый вес. Голос одного человека не может быть важнее голоса другого.
  
  
• Включающее свойство: как можно больше людей должны быть вовлечены в процесс консенсуса. Это не должно быть похоже на обычное голосование, когда люди на самом деле не хотят голосовать, потому что считают, что их голосование не будет иметь никакого веса в долгосрочной перспективе.
  
  
• Свойство участия: механизм консенсуса должен быть таким, чтобы каждый мог активно участвовать в общем процессе.

Как уже упоминалось, хэш нового блока определяется PoW как согласованный алгоритм через функцию хеширования. Вся информация заголовка и данных (включая все транзакции) подается в функцию двойного хеширования для поиска уникальной комбинации хеша путем угадывания и изменения одноразового номера, который должен удовлетворять определенному количеству нулей во фронт-энде хеша. Количество нулей регулируется уровнем сложности, установленным в протоколе Биткоин, чтобы гарантировать, что каждый блок создается с интервалом около 10 минут.

В попытке выполнить PoW (или майнинг) все участвующие узлы соревнуются и продолжают «находить» или угадывать правильный дамп времени, пока не будет достигнута цель количества нулей. Нужно знать, что выполнить PoW с помощью SHA256 - довольно трудная задача, когда необходима именно такая цель. Это связано с природой чрезвычайной случайности, когда SHA256 используется для получения одностороннего математического результата - необратимого свойства в SHA256. (Вы можете найти информацию о свойствах SHA256 и хешировании выше в рамках этой лекции). Таким образом, найти подходящий результат, который имеет конкретное хеширование с определенным количеством нулей на своем входном конце, довольно трудная работа, и в некотором смысле это действительно требует немного удачи и так называемой силы «хеширования».

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

Здесь вы можете увидеть, как работает цепь и блок. Первый блок называется блоком Genesis. Как уже упоминалось, каждый блок имеет заголовок, который является хешем этого блока. На самом деле, заголовок - это последнее, что нужно вычислить при формировании нового блока.

Каждый блок состоит из текущего и предыдущего хеша. Новый блок должен всегда присоединять предыдущий хеш к своему заголовку перед определением текущего хеша. Таким образом, формируется цепная система, связывающая предыдущий и следующий блок таким образом, что вся хронологическая последовательность хэшей записывается совместно. Трудно разорвать цепь, поскольку текущий хеш должен пройти огромное усилие, чтобы решить математическую задачу. Это достигается буквальным «угадыванием» правильного значения «дампа времени» (красный) в каждом блоке, чтобы удовлетворить определенные критерии и уровень сложности, установленные протоколом Биткоин для его требований PoW. (Это будет объяснено позже).

Обратите внимание, что горизонтальная линия делит высоту блока в верхней и (заголовок + данные) нижней части блока. Высота блока задает последовательность блока, а заголовок + данные содержат всю оставшуюся информацию, кроме хэша блока.

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

Причина, по которой это называется Proof-of-Work, заключается в том, что участвующий узел должен демонстрировать определенный уровень приверженности в порядке принадлежности к совместному обслуживанию распределенной сети биткоинов, внося свой вклад в жесткий алгоритм и механизм консенсуса посредством инвестирования в вычислительные мощности. Из-за уникальности каждого хэша, его просто невозможно обмануть, переделав все вычислительные усилия.

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

Здесь вы снова можете увидеть, что все майнинговые узлы конкурируют за создание следующего нового блока, стараясь «выиграть» PoW. Чем выше мощность хеширования, тем выше шансы на победу. Мощность хеширования определяется объемом майнинговых машин или пула вычислительных ферм, принадлежащих частному лицу или компании. Посредством делегирования усилий и обеспечения того, чтобы дампы памяти не повторялись, шансы на победу будут еще больше увеличены, но не гарантированы. В настоящее время награда составляет 12.5BTC для победившего майнера, и новый блок победителя, который состоит из TXN, будет записан в следующей цепочке блока.

Таким образом, все майнинговые узлы могут «совместно» помогать в ведении бухгалтерской книги, внося вычислительные усилия для выполнения PoW, обновления и проверки записи, обеспечивая единую версию истинности, достигаемую алгоритмом консенсуса через систему стимулирования Биткоин. Это хорошая причина, из-за которой узлы хотели участвовать и помогать поддерживать/проверять эту единственную истинность бухгалтерской книги и тратить вычислительные усилия на подтверждение и перекрестную проверку, чтобы убедиться, что транзакции фактически не подвержены вмешательству. (Это денежная система, которая не может допустить наличие недостатка, в случае необходимости беспрерывной работы). Без системы стимулирования посредством майнинга у узлов не будет мотивации для поддержки распределенной сети. Без распределенной сети невозможно реализовать понятие «доверие» посредством управления децентрализацией.

 

[Tamgdepravda]

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