Большая история крипты

Блокчейн хранит историю или текущее состояние? На самом деле это разные вещи Мы часто говорим: блокчейн — это история транзакций. Это правильно. Но для работы сети одной истории недостаточно. Ей ещё нужно знать, что существует прямо сейчас. Допустим, за десять лет по банковскому счёту прошло миллион операций. История — это все миллион переводов. Состояние — это ответ на вопрос: «Сколько денег на счёте сейчас?» Ethereum можно представить как машину, которая постоянно переходит из одного состояния в другое. Была определённая картина: у Алисы один баланс, у Боба другой, у смарт-контракта хранятся определённые данные. Приходит набор транзакций. Они выполняются. И система получает новое состояние. Поэтому текущий state Ethereum включает не только балансы. Там есть данные аккаунтов, счётчики nonce, код контрактов и их хранилища. Представь шахматную партию. История — это запись всех ходов с самого начала. Текущее состояние — расположение фигур на доске прямо сейчас. Чтобы сделать следующий ход, тебе прежде всего нужна сегодняшняя доска. Теоретически её можно восстановить, если взять начальную позицию и заново проиграть всю партию. Но делать это перед каждым новым ходом было бы совершенно неразумно. Поэтому узлы поддерживают актуальное состояние сети. И здесь появляется ещё одно интересное различие — между обычным полным узлом и архивным. Для нормальной работы сети не каждому компьютеру необходимо мгновенно хранить доступ к каждому историческому состоянию Ethereum за все годы. Full node проверяет цепочку и следит за актуальным состоянием. Часть старых промежуточных состояний может очищаться — это называют pruning. А archive node специально сохраняет исторические состояния, чтобы можно было спросить, например: «Как выглядел баланс или хранилище контракта на определённом старом блоке?» Это значительно тяжелее по объёму хранения. И здесь важно не перепутать понятия. Удаление старых состояний из рабочей базы конкретного узла — не то же самое, что «стереть историю блокчейна». Блоки и транзакции — один тип исторической информации. Полный снимок состояния на каждом прошлом шаге — другой. Можно хранить все чеки магазина, но не хранить отдельную фотографию склада после каждого проданного батона. Если понадобилось, прошлую картину можно восстановить из истории — просто это требует вычислений. Поэтому блокчейн — не статичная книга. Он гораздо ближе к огромной машине состояний, где каждая транзакция является командой: «Возьми текущую картину мира, выполни правило и получи новую». #состояниесети #Ethereum #блокчейн #ноды #большаяисториякрипты

Как проверить одну запись, не скачивая весь блокчейн: дерево Меркла Представь склад на миллион коробок. Тебе нужно доказать, что коробка №583 421 действительно входит в сегодняшнюю опись. Самый примитивный способ — прислать тебе список всех миллиона коробок. Работает. Но неудобно. А можно сделать намного умнее. Именно для таких задач используются конструкции семейства Merkle tree — деревьев Меркла. Если совсем просто, данные разбивают на части и получают для каждой части криптографический хеш. Затем хеши объединяют попарно и снова хешируют. Потом полученные значения снова соединяют. Так продолжается, пока наверху не останется одно единственное значение — корень дерева, Merkle root. Представь чемпионат на выбывание. Внизу тысячи участников. После каждого раунда их становится вдвое меньше. В самом конце остаётся один победитель. Только вместо игроков здесь хеши. Зачем такая конструкция нужна? Потому что теперь для доказательства наличия конкретной записи не обязательно показывать весь массив данных. Достаточно предоставить саму запись и небольшую цепочку соседних хешей, которая позволяет подняться от неё к известному корню. Проверяющий самостоятельно пересчитает несколько значений. Если в итоге получился правильный корень, запись согласуется с тем набором данных, которому этот корень соответствует. Это как если бы вместо всего архива склада тебе дали одну коробку, несколько контрольных печатей и способ самостоятельно проверить, что цепочка печатей приводит к официальной печати всего склада. Почему это особенно важно для блокчейнов? Потому что блокчейн постоянно пытается совместить две вещи: огромный объём данных и возможность проверять их относительно компактно. Ethereum использует криптографические древовидные структуры для представления состояния сети — аккаунтов, балансов, контрактов и других данных. Корневое значение становится своеобразным коротким обязательством относительно огромного количества информации. Измени один элемент внизу — изменятся хеши по пути вверх, а затем изменится и корень. И здесь деревья Меркла красиво продолжают идею предыдущего поста. Хеш позволяет сделать отпечаток данных. А дерево Меркла позволяет построить из множества таких отпечатков проверяемую систему, где отдельный элемент связан с единым корнем. Это один из тех механизмов, которые пользователь почти никогда не видит. В приложении есть одна кнопка и баланс. Но под этой простой картинкой работают структуры, позволяющие маленьким доказательством проверять кусочек огромного цифрового мира. Иногда блокчейну не нужно показать тебе всю библиотеку. Достаточно доказать, что нужная страница действительно принадлежит правильной книге. #MerkleTree #криптография #Ethereum #блокчейн #большаяисториякрипты

Что такое хеш и почему блокчейн без него практически невозможно представить Слово «хеш» встречается в крипте буквально повсюду. Хеш транзакции. Хеш блока. Хеш кода. Но что это вообще такое? Если совсем просто, хеш можно представить как цифровой отпечаток данных. Берём некоторую информацию и пропускаем её через специальную математическую функцию. На выходе получаем строку фиксированного формата. Изменили исходные данные — изменился и результат. Представь машину, которая умеет превращать любую книгу в короткий уникальный отпечаток. Можно засунуть туда страницу текста. Можно «Войну и мир». Можно огромную базу данных. На выходе размер отпечатка будет одинакового типа. Самое интересное начинается, если изменить в книге буквально один символ. Хорошая криптографическая хеш-функция даст уже совсем другой результат. Именно поэтому хеш удобен для проверки целостности. Допустим, тебе передали огромный файл и отдельно сообщили его правильный хеш. Ты вычисляешь хеш полученного файла. Совпал? Очень сильный признак того, что данные не изменились. Не совпал? Значит, перед тобой уже не тот же набор информации. Важно: хеширование — это не шифрование. Шифрование предполагает, что данные можно расшифровать с помощью ключа. Хеш не является упакованной копией исходного текста. По нормальному криптографическому хешу нельзя просто нажать кнопку «назад» и получить первоначальную информацию. В блокчейне эта идея используется постоянно. Транзакции получают идентификаторы. Блоки криптографически связываются между собой. Состояние системы можно представить через компактные хеш-обязательства. Код и данные можно проверять на неизменность. Представь длинную цепочку запечатанных коробок. На каждой коробке указан цифровой отпечаток предыдущей. Если кто-то вскроет старую коробку и заменит содержимое, её отпечаток изменится. Следующая коробка уже будет ссылаться на другое значение. Чтобы незаметно переписать историю, придётся согласовать изменения дальше по цепочке и одновременно преодолеть правила консенсуса сети. Сам хеш не создаёт всю безопасность блокчейна. Но он даёт системе чрезвычайно важное свойство — изменение данных становится заметным математически. Это фундаментальная разница между обычной записью и криптографически связанной историей. Можно переписать цифру в Excel. А блокчейн пытается устроить хранение так, чтобы изменение старой цифры начало конфликтовать со всей системой доказательств вокруг неё. Хеш ничего не говорит о смысле данных. Он говорит другое: перед тобой всё ещё те же данные или уже нет. #хеш #криптография #блокчейн #крипта #большаяисториякрипты

Зачем каждой транзакции нужен свой номер Допустим, ты подписал перевод и отправил его в сеть. Что помешает кому-нибудь взять ту же самую подписанную транзакцию и отправить её ещё десять раз? Если система видит корректную подпись, разве она не должна каждый раз выполнять команду? Именно здесь появляется маленькое поле под названием nonce. Если совсем просто, nonce — это последовательный номер операции конкретного аккаунта. Первая транзакция получает один номер, следующая — следующий и так далее. Представь обычную чековую книжку. Ты выписал чек №25 на определённую сумму. Банк видит, что этот чек уже использован. Если кто-то принесёт его ещё раз, система не должна списать деньги повторно. Примерно ту же проблему решает nonce. Для аккаунта Ethereum сеть хранит счётчик. Транзакция должна иметь правильный следующий номер. Когда она выполняется, счётчик меняется. Поэтому одну и ту же старую подписанную команду нельзя бесконечно повторять как новую операцию. Но nonce делает ещё кое-что важное — создаёт порядок. Допустим, аккаунт последовательно отправил транзакции №40, №41 и №42. Сеть не может сначала нормально выполнить №42, забыв про №40 и №41. Состояние аккаунта должно меняться последовательно. Представь очередь талонов в государственном учреждении. На табло сейчас номер 40. Человек с талоном 42 уже пришёл и сидит в зале, но сначала система должна разобраться с предыдущими номерами. Из-за этого иногда возникает странная ситуация: одна зависшая операция способна задержать следующие транзакции того же аккаунта. Сами следующие операции могут быть вполне корректными. Проблема в том, что перед ними отсутствует нужное звено последовательности. И здесь становится видно, зачем nonce вообще встроен на уровень аккаунта. Блокчейн должен решить сразу две задачи: — не позволять повторно исполнять старую подписанную транзакцию; — точно понимать порядок изменений одного аккаунта. Одна маленькая цифра помогает делать и то и другое. Причём nonce — это хороший пример того, как блокчейн обеспечивает безопасность не одной гигантской системой защиты, а множеством небольших правил. Подпись отвечает на вопрос: «Действительно ли владелец ключа разрешил операцию?» Nonce добавляет второй: «А действительно ли именно эта операция сейчас следующая?» Вместе они превращают набор цифровых команд в последовательную историю. #nonce #транзакции #Ethereum #блокчейн #большаяисториякрипты

Куда попадает транзакция до того, как попадёт в блок Ты нажал «Отправить», кошелёк показал хеш транзакции, но перевод ещё висит со статусом «ожидает». Где он находится в этот момент? Не в блокчейне — по крайней мере пока. Сначала подписанная транзакция распространяется между узлами сети и попадает в пул ожидающих транзакций, который часто называют mempool. Если совсем просто, mempool — это зал ожидания перед блокчейном. Представь аэропорт. Ты уже прошёл регистрацию, получил посадочный талон и находишься у выхода. Но это ещё не означает, что самолёт взлетел. С транзакцией похожая история. Она уже существует, подписана твоим ключом и передана сети. Но пока производитель блока не включит её в блок, окончательного изменения состояния сети не произошло. Причём есть важная деталь: единого огромного «главного mempool», который хранится где-то на сервере Ethereum, нет. У разных узлов есть свои локальные наборы ожидающих транзакций. Они обмениваются ими друг с другом, поэтому информация постепенно расходится по сети. Из этого следует интересная вещь. Статус «транзакция отправлена» и статус «транзакция попала в блок» — два разных состояния. Между ними существует настоящая очередь. Почему одна операция проходит быстрее другой? На это влияет несколько факторов: доступное место в блоках, правила сети, размер комиссии и то, какие транзакции производитель блока выбирает для включения. Поэтому pending не означает «сломалось». Иногда сеть просто ещё не включила операцию в подтверждённый блок. Можно представить ресторан с открытой кухней. Официант принял заказ — транзакция создана. Заказ появился у кухни — сеть его получила. Повар взял его в работу — операция вошла в блок. Блюдо вынесли — состояние изменилось. Mempool — это пространство между «заказ уже существует» и «заказ уже выполнен». И этот маленький технический слой объясняет много вещей, которые иначе выглядят странно: почему транзакции могут ожидать, почему порядок операций имеет значение и откуда вообще появляется возможность конкурировать за более раннее место в блоке. Блокчейн начинается не в момент нажатия кнопки. Между кнопкой и записью в общей истории существует очередь. #mempool #транзакции #Ethereum #крипта #большаяисториякрипты

Почему криптокошелёк будущего может перестать быть страшной связкой ключей Одна из самых неудобных вещей в классическом криптокошельке — ответственность устроена почти бинарно. Есть приватный ключ — есть контроль. Потерял ключ без возможности восстановления — можешь потерять доступ. Ключ украли — злоумышленник может получить возможность распоряжаться активами. Для идеологически чистой системы это выглядит логично: никто, кроме владельца, не контролирует счёт. Для обычного человека — довольно сурово. Поэтому разработчики давно пытаются сделать криптоаккаунт программируемым. Эта идея называется account abstraction. Если совсем просто, обычный криптоаккаунт можно сравнить с дверью, у которой есть один механический ключ. Account abstraction пытается превратить эту дверь в современную систему доступа. Например: можно предусмотреть несколько способов восстановления; установить лимиты; требовать дополнительные подтверждения для крупных операций; объединять несколько действий в одну операцию; позволять другому механизму оплачивать комиссию; менять правила безопасности без создания нового адреса. Ethereum описывает account abstraction именно как путь к более гибким smart contract wallets, где правила доступа и безопасности можно программировать в самом аккаунте. Представь банковскую карту. Если её украли, банк может заблокировать карту и выпустить новую. Можно установить дневной лимит. Можно подтверждать крупную покупку дополнительным кодом. Можно добавить родственника с ограниченными правами. В классическом криптокошельке многое из этого исторически было значительно сложнее. Smart-account позволяет сказать: «Для обычного перевода достаточно одного подтверждения. Для крупного — двух». Или: «Если основной ключ потерян, несколько заранее выбранных доверенных участников смогут помочь восстановить доступ». Или: «Пользователь совершает действие, а комиссию оплачивает приложение». Последний пункт особенно интересный. В обычном Ethereum-аккаунте пользователю традиционно нужен ETH для оплаты gas. В account-abstraction-моделях специальные механизмы, включая paymaster, могут оплачивать комиссию от имени пользователя. Это кажется мелочью, но для массового использования очень важно. Представь приложение, которым можно пользоваться только после того, как ты сначала купил специальное топливо на другой площадке. Технически логично. Для обычного пользователя — лишний барьер. Account abstraction пытается спрятать такие барьеры под более понятным интерфейсом. Но есть и обратная сторона. Чем сложнее логика аккаунта, тем больше кода, который должен работать правильно. Механизм восстановления тоже нужно защищать. Лимиты нужно корректно настроить. Смарт-контракт кошелька может иметь свои уязвимости. То есть account abstraction не отменяет безопасность. Он меняет её модель. Раньше логика была примерно такой: «Не потеряй один главный секрет». Теперь она может становиться такой: «Заранее запрограммируй, что система должна делать в разных ситуациях». И это очень важный переход для крипты. Потому что массовая технология редко становится массовой, пока пользователь должен постоянно чувствовать себя системным администратором собственного банка. Возможно, будущее криптокошельков будет выглядеть гораздо менее «криптовым», чем сегодня. Человек просто будет видеть понятный аккаунт. А сложная криптография, восстановление, подписи и комиссии постепенно уйдут туда, куда и должна уходить зрелая инфраструктура, — под капот. #accountabstraction #криптокошелек #Ethereum #крипта #большаяисториякрипты

Что такое доступность данных и почему правильного доказательства иногда недостаточно Есть технический термин, который звучит скучнее, чем его реальное значение: data availability — доступность данных. Но если понять его через обычную жизнь, тема становится довольно очевидной. Представь бухгалтера, который говорит: «Я всё посчитал правильно. Вот итог: компания заработала миллион». Хорошо. Но где исходные документы? Если накладные, операции и записи исчезли, независимо проверить расчёт уже невозможно. Можно поверить бухгалтеру или даже проверить какое-то математическое доказательство, но восстановить полную картину без данных сложно. С блокчейнами и особенно решениями второго уровня возникает похожая задача. Rollup может обработать множество транзакций вне основной сети и затем передать результат обратно. Это помогает масштабированию. Но другим участникам важно иметь доступ к достаточному объёму данных, чтобы восстановить состояние системы, проверить необходимые свойства или при необходимости продолжить работу даже при проблемах у оператора. Вот это и есть проблема доступности данных. Ethereum прямо указывает, что гарантии доступности данных особенно важны для Layer 2 rollups и лёгких узлов: недостаточно знать только итоговое состояние, если нужные для проверки или восстановления данные недоступны. Если совсем по-бытовому, представь большой склад. Начальник присылает тебе сообщение: «Внутри сейчас ровно десять тысяч товаров». Допустим, у тебя даже есть способ убедиться, что расчёт сделан корректно. Но если завтра начальник исчезнет, а вся подробная ведомость движения товаров находится только на его закрытом компьютере, продолжить работу будет трудно. Надёжная система хочет, чтобы критически необходимые данные были доступны не только одному оператору. Именно поэтому rollups публикуют данные или специальные объекты данных в базовом слое. Ethereum, например, использует для масштабирования механизм blobs, рассчитанный прежде всего на публикацию данных rollup-системами. Зачем хранить столько информации, если уже есть доказательство? Потому что «доказательство корректности» и «возможность восстановить текущее состояние системы» — не одно и то же. Можно доказать, что бухгалтер правильно получил итоговую сумму. Но если завтра нужно понять баланс конкретного клиента, понадобятся исходные записи. Это очень важная тема для масштабирования. Блокчейн хочет одновременно: обрабатывать больше операций, не заставлять базовую сеть выполнять каждую из них, и при этом не создавать нового хозяина данных, без которого система перестанет работать. И именно здесь доступность данных становится одной из несущих конструкций. Она почти незаметна обычному пользователю. Никто не открывает приложение со словами: «Как хорошо, что сегодня обеспечена data availability». Но это как фундамент здания. Люди редко любуются фундаментом. Однако именно он определяет, можно ли доверять этажам сверху. #dataavailability #L2 #блокчейн #крипта #большаяисториякрипты

Как доказать что-то, не показывая сам секрет: что такое Zero-Knowledge Proof Представь странную ситуацию. Тебе нужно доказать человеку, что ты знаешь пароль от сейфа. Но сам пароль показывать нельзя. Как это сделать? Можно открыть сейф так, чтобы человек увидел результат, но не увидел сам пароль. Логика zero-knowledge proof — доказательства с нулевым разглашением — в чём-то похожа. Если совсем просто, такая криптографическая технология позволяет доказать истинность определённого утверждения, не раскрывая всю информацию, на которой это утверждение основано. Именно так zero-knowledge proofs описывает документация Ethereum. Например, в теории можно доказать: «Мне больше определённого возраста» не раскрывая точную дату рождения. Или: «У меня есть правильный секретный ключ» не показывая сам ключ. Звучит почти как фокус. Но здесь нет магии. Есть математика, которая позволяет одной стороне сформировать доказательство, а другой — проверить его. Почему это вообще стало интересно крипте? Потому что блокчейн исторически любит проверяемость. Сеть должна иметь возможность убедиться, что действие корректно. Но проверяемость создаёт проблему: если для проверки каждый раз нужно раскрывать все исходные данные, приватность быстро исчезает. Zero-knowledge proofs пытаются разделить две вещи, которые раньше казались неразделимыми: проверить факт и увидеть все данные за этим фактом. Можно представить паспортный контроль. Обычная схема: ты отдаёшь весь паспорт. Сотрудник видит имя, фамилию, дату рождения, номер документа, место рождения — даже если ему нужно проверить только одно: достиг ли человек определённого возраста. Zero-knowledge-подход в идеальной аналогии позволил бы показать цифровое доказательство: «условие выполнено», не раскрывая лишнего. Но приватность — не единственное применение. Такие доказательства используются и для масштабирования блокчейнов. Например, ZK-rollup может выполнить множество операций вне основного слоя, а затем передать Ethereum компактное криптографическое доказательство того, что изменение состояния рассчитано корректно. Основная сеть проверяет доказательство вместо повторного выполнения всей работы. Это довольно сильный поворот. Обычно для доверия хочется увидеть всё. Zero-knowledge cryptography предлагает другую мысль: иногда можно получить математическую уверенность, не получая весь исходный набор информации. Конечно, сама технология сложная. Разные схемы доказательств имеют разные свойства, требования и компромиссы. Но для понимания большой истории крипты достаточно главного. Раньше цифровые системы часто ставили человека перед выбором: либо приватность, либо проверяемость. Zero-knowledge proofs показали, что этот выбор не всегда обязателен. Иногда можно доказать, что ты прав, не рассказывая при этом всё, что ты знаешь. #ZK #криптография #блокчейн #крипта #большаяисториякрипты

Узел и валидатор — это одно и то же? Нет. И вот в чём разница В крипте постоянно встречаются слова «узел», «нода», «валидатор». И новичку легко решить, что это примерно разные названия одного компьютера, который каким-то образом поддерживает блокчейн. Но роли здесь отличаются. Начнём с узла. Если совсем просто, узел — это участник сети, который хранит, получает и проверяет информацию по правилам конкретного блокчейна. Представь большой клуб, у которого есть общий свод правил и общая история решений. У каждого серьёзного участника лежит собственная копия документов. Когда приходит новая запись, он не обязан верить соседу на слово. Он может сам проверить: соответствует ли запись правилам клуба. Вот узел делает примерно это. Он получает данные от других узлов, проверяет транзакции и блоки и помогает распространять корректную информацию дальше. Из-за этого блокчейн и не зависит от одной центральной базы: независимые участники сами могут проверять состояние сети. А валидатор? Валидатор — это уже более специальная роль. В Proof of Stake валидаторы участвуют непосредственно в консенсусе: подтверждают блоки, а некоторые в определённый момент получают возможность предложить новый блок. Чтобы выполнять эту роль, они связывают с системой экономический залог. То есть можно быть узлом и при этом не быть валидатором. Это важная деталь. Представь выборы. Обычный наблюдатель может получить протокол, сверить данные и убедиться, что правила соблюдены. Но это не означает, что именно он входит в комиссию, которая официально формирует результат. Узел похож на независимого проверяющего участника сети. Валидатор — на участника, который дополнительно включён в механизм формирования и подтверждения общей версии истории. В Ethereum, например, запуск полноценного узла сам по себе полезен сети, даже если этот узел не участвует в валидации. Официальная документация прямо разделяет эти роли: к узлу можно добавить валидаторное ПО, чтобы участвовать в защите сети через Proof of Stake. Зачем вообще нужно столько независимых узлов? Потому что иначе возникает неприятный вопрос: если все получают информацию только от одного сервера, чем такая система принципиально отличается от обычной централизованной базы? Независимый узел позволяет сказать: «Я не обязан верить чужой версии блокчейна. Я могу сам проверить её по тем же правилам». И это одна из фундаментальных идей крипты. Децентрализация — это не просто большое количество компьютеров. Гораздо важнее, что достаточно много независимых участников способны сами проверять правила, а не получать готовую истину от одного главного источника. #ноды #валидаторы #блокчейн #крипта #большаяисториякрипты

Что значит «транзакция финальная» и почему одного попадания в блок иногда мало Допустим, ты отправил криптовалюту. Через несколько секунд кошелёк показывает: транзакция попала в блок. Вроде всё — деньги ушли, история записана. Но тут возникает нормальный вопрос: а может ли эта запись потом измениться? И вот здесь появляется понятие финальности. Если совсем просто, финальность — это момент, после которого сеть считает конкретный блок настолько окончательным, что изменить записанную в нём историю уже практически невозможно в рамках нормальной работы системы. Представь кассу в магазине. Сначала кассир пробил чек. Операция уже появилась в системе. Но затем данные ещё уходят в центральную базу, сверяются и окончательно закрепляются. Есть разница между «операцию увидели» и «операция окончательно стала частью учёта». В блокчейне похожая логика, только без единого кассира. Новый блок появляется, узлы сети его получают, проверяют и начинают строить следующую историю поверх него. Чем глубже запись оказывается внутри подтверждённой цепочки, тем труднее её изменить. Но разные блокчейны решают эту задачу по-разному. В Proof of Work традиционно говорят о подтверждениях: поверх блока появляются новые блоки, и вероятность того, что старая ветка будет заменена другой, становится всё меньше. Это называют вероятностной финальностью. В Proof of Stake могут использоваться специальные механизмы, при которых валидаторы коллективно подтверждают контрольные точки. В Ethereum финальность — отдельное свойство консенсуса: после финализации изменение блока потребовало бы крайне серьёзного нарушения работы валидаторов и экономических последствий для их залога. Зачем обычному человеку вообще знать эту разницу? Потому что надпись «транзакция подтверждена» не во всех сетях означает одно и то же. Есть момент, когда транзакция просто включена в блок. Есть количество дополнительных подтверждений. А есть момент, когда сеть уже считает историю финальной. Это особенно важно для крупных переводов, бирж и сервисов. Поэтому они могут ждать не просто первого появления транзакции, а дополнительной уверенности, прежде чем считать операцию завершённой. Можно представить железную дорогу. Поезд уже прошёл первую станцию — значит, поездка началась. Но если тебе важно точно знать, что состав дошёл до конечного пункта, одного факта отправления недостаточно. Финальность — это примерно тот момент, когда сеть говорит: «Эта часть маршрута уже не просто случилась. Она стала окончательной частью нашей общей истории». И здесь хорошо видно, почему блокчейн — это не просто запись данных. Главная задача сети — не только записать, что произошло, но и договориться о том, какая версия прошлого считается окончательной. А без этого цифровые деньги просто не могли бы нормально работать. #блокчейн #финальность #крипта #консенсус #большаяисториякрипты