угу. Ну можно выбрать из кучи форков эфира, например. Я люблю xDAI например (просто знаю сколько нужного софта ребята написали для экосистемы). Там быстро и дешево. Ну и решение на эфире можно вообще сделать сразу во всех эфирных БЧ :) Если используется один и тот же тип адресов, то один и тот же адрес может быть использован в нескольких БЧ.
1) это определяет чисто рынок, предсказать невозможно. Куча пользователей и ботов размещают ежедневно разное количество транзакций. Каждая из транзакций стоит от 21 000 до 10 000 000 gas (условные попугаи). Цену за газ ставит отправляющий, если майнеры долго не берут транзакцию, цену можно повысить. Поэтому там просто ауцкцион получается на каждом блоке. Бывают дни, когда твоя транзакция стоит 1$ и майнится 30 сек, бывает что 20$ и надо ждать 15 минут. Здесь не стоит ждать какой-то то надежности, если не готов платить и конкурировать с другими проектами, увы. Если про ковид-паспорт, то, если хранить в БЧ самый минимум, например bool (вакцинирован), или timestamp c каким нить битовым полем, то это в Ethereum минимум модификация слота размером 256 бит (там любая опреация в storage квантуется блоками по 256bit). Апдейт ячейки стоит 5000 gas, создание новой ячейки - 20000 gas. Key-value c адресом это что-то типа двух ячеек (под ключ и под значение) - значит в районе 40000 gas за тразакцию (вообще это точно оценивается для конкретного контракта, но лень).
Текущие цены на газ (на сегодняшний день, смотрю на https://ethgasstation.info/) - это 17gwei (1 wei это 1 * 10 ^(-18) ETH), соответственно цена транзакции примерно 40 000 * 17 * 10^6 wei * 10^(-18) ETH. Но вообще я сегодня делал простенький approve в эфире - стоило 1.5$, так что цена где-то такая будет
блокчейнов без оплаты транзакций не существует. Даже если нативный токен не имеет никакой реальной стоимости, он все равно нужен для обеспечения безопасности сети - им оплачивается сложность транзакций, и он все равно есть (команда просто делает его "техническим", печатая и раздавая кому надо). Без токенов делают блокчейны корпораты, но, имхо, это просто понты, реально такие блокчейны нафиг не нужны никому. Зачем заменять быструю и эффективную БД медленным и тормозным БЧ при том же уровне безопасности? В блокчейнах возможность ОДНОМУ участнику всё сломать считается дырой в безопасности, а без оплаты транзакций любой ОДИН взломанный участник может заспамить БЧ бесплатным мусором. В случае своего БЧ нативные токены можно "печатать" сколько хочется и раздавать универам просто так, вообще не присваивая токену никакой финансовой ценности (да ее и не будет, если сказать, что команда в любой момент может напечатать кому угодно ахулиард токенов). Тем не менее с точки зрения безопасности все строго - если у спамера нет токенов - он ничего не сделает, а универ просто так их никому не даст.
Про "стоимость" архитектуры не очень понял вопроса, попробую ответить как понял. Web-часть поддерживается как обычный web проект, единствено, что для БЧ это могут быть крайне легковесные frontend-ы, которые можно чуть ли не в виде html файлов распространять. А вот про блокчейн-часть:
Если делать свой блокчейн - то суммарно всей сети придется платить реальные деньги за работающие блокчейн-ноды, зарплату админам, за доработаку клиентского софта, обновления и т.п. Похоже на разработку форка какой нибудь опенсорсной СУБД.
Если использовать готовые сети типа Ethereum, то можно вообще ничего не поддерживать кроме нескольких своих нод для надежности, с минимальной поддержкой, но за каждую операцию придется платить в ETH.
Можно использовать testnet Ethereum и вообще не платить за ноды (их уже держат раработчики), а для транз использовать тестовый эфир(можно получить его себе бесплатно). Цена владения такой системой вообще почти нулевая (рекомендую, если вы студенческий проект делаете)
Ну, любые текущие системы требуют также танцев с бубуном - например владения почтовым ящиком, который может исчезнуть, или начать класть в спам письма, или телефона. Я в конце написал, что никаких "забыл пароль" в этих схемах не будет - этот функционал изначально хромой - как был хромым функционал "выслать пароль на email". "Менять пароль" должен сам пользователь, а не сервис, без малейших дейсттвий на стороне сервиса, это его аккаунт и только ему им управлять. Проблема угнанных аккаунов решается созданием двухуровневых identity - master ключа и рабочих аккаунтов, которые master всегда может заменить. Это долгая дискуссия, если кратко - это да, другая схема, которая сильно отличается от привычной. Но почему-то W3C ее принимает и развивает, а SSI и VC - это уже существующие тренды развития интернета. Ну и как то в DeFi крутятся десятки млрд $ в день без всяких восстановлений паролей, здесь первым делом в любых сервисах пишут огромными буквами "нет seed phrase, нет и мультиков"
про 72 млн первых эфиров тоже гонево — везде написано, что это банально те, кто вложился в BTC в ICO эфира — они и получили эти 72 млн. Напомню еще, что когда они их получили, это не была «вторая криптовалюта» — а был эфир пока никому не известными фантиками — и инвесторы сильно рисковали. То же самое, что в Теслу вложиться в первый месяц ее существования… Эх, жалко, конечно, что такой фон вокруг криптовалют. Жалко что вообще BFT p2p сети вообще превратились в банальные криптовалюты — ибо Ethereum — это больше распределенный компьютер, и ваша аналогия с бинарями довольно точная. То что его начали использовать как станок для печати фантиков — проблема бизнеса, а не самого Ethereum.
точно, зависит от state блокчейна, в чем проблема-то? С точки зрения разработчика совершенно честно — газ считается ровно по тому, какие опреации выполнялись. Количество газа можно предсказать без соменения, как минимум на майнинговой машине. Вы сами привели всего 3 варианта — это ни в какое сравнение не идет с предсказаниями тактов процессора — тут все полностью детерминированно.
В общем со стороны пользователя — действительно, есть какие-то проблемы.
С точки зрения алгоритмов — все в порядке: и с газом и с кодом контракта, уж не знаю чем вам байт-код не угодил, ибо на JS, к сожалению ничего детерминированного не напишешь, увы — и байт-код — это тот же исходник, в EVM он элементарно декомпилится в довольно осмысленный код. Код можно проверить, изучить, то что это нельзя сделать кому угодно — это лишь техническая проблема. Не доверяйте неверифицированным контрактам — делов то…
Ладно, дискуссия совсем тухлая стала
Имея один и тот же блокчейн, и накатывая одну и ту же транзакцию, количество газа 100% не меняется. Иначе это был бы не блокчейн. Количество газа будет зависеть от многих параметров (инициализирован ли уже баланс, в какую логическую ветку пойдет исполнение) — но оно строго детерминировано. Но для простого юзера действительно кажется что меняется
Байт-код контракта, который вы прислали: 0x6060604052361......91b4b7370029, можно посмотреть по ссылке: etherscan.io/address/0xbcc394d45c3613530a83cae62c716dc23b7f2152#code
То, что вам не написали его в виде, похожем на JS, не значит что его нет. Это полноценный код, инструкции EVM, которые нельзя подделать, вместе с параметрами конструктора, и стоимость процессинга этого кода строго детерминирована.
Так что вы неправы и в том, что «количество газа на вызов нельзя определить» и в том что «код контракта недоступен», не вводите в заблуждение людей.
ну давайте останемся каждый при своем. Ибо в банке если будет баг, вы про это и не узнаете (также как и есть ли в банке деньги вообще) и никакие аудиторы вам не помогут. Я лучше доверюсь алгоритму, пускай и потенциально дырявому, зато открытому и проверяемому, чем закрытому софту внутри банка. Допускаю, что большинству людей этот факт пофигу, я им и не навязываюсь…
Описано по большей части неправильно, автор видимо по верхам прошелся. Про газ — неверно, разумеется можно оценить количество газа и довольно точно (не во всех случаях, но в большинстве случаев это несложно). Код контрактов открыт полностью — можно изучить, если скилла нет — нанять аудиторов. Балансы, операции — всё можно проверить самому. То, что это неудобно, сыро, дорого и проще с внешнего сайта — не меняет сути, централизованные сервисы такого попросту не могут предоставить.
Пожалуй соглашуть только с тем, что производные криптовалюты типа USDT могут реализовывать всякие скамные штуки — но это также публично(!) проверяемо.
Всему этому обычные централизованные финансовые сервисы могут противопоставить только слова и бумажки, а «современные банковские сервисы» с точки зрения смарт-контрактов — это примитивные простейшие алгоритмы, которые может реализовать любой студент
Да, mininet похоже развитый весьма, спасибо за наводку! Просмотрел его, к сожалению, видимо не нашел в поиске ибо искал софт, который и сеть разворачивает, и бенчмарки запускает, и репорты генерит и метрики собирает. Изучим-с…
github.com/DaoCasino/DAObet — собственно нода запускаемого БЧ (кстати сильно помогли с поиском багов и запуском сети те, кто не пользовался инструкциями, докером, а сами все собрали и автоматизировали)
github.com/mixbytes/tank — тулза для оркестрирования блокчейнами и бенчмаркинга, которую мы использовали для запуска тестнета (точнее аж трех тестнетов, в т.ч. и для игры валидаторов), запуска Prometheus/Grafana и сбора метрик
github.com/mixbytes/tank.bench-common — базовый модуль для проведения бенчмарков (умеет в много потоков подписывать и швыряться транзакциями в ноды)
github.com/mixbytes/tank.bench-haya — бенчмарк на основе tank.becnch-common для тестирования блокчейна Haya (на базе которого построен БЧ, в котором проводится игра валидаторов)
бенчмарки, нагружающие разные подсистемы контрактов в приватных репах сходу не нашел, может мы из и не открывали. Но запускали точно — в наших интересах было посмотреть как справятся валидаторы…
ну и еще всякие доп. тулзы: block explorer, голосовалка, еще там что-то — под EOS можно найти много.
Что значит абстрактный список? Весь приведенный в статье код открыт и валяется в гитхаб репозитариях mixbytes и DaoCasino (просто линки на гитхабы фиг знает, можно ли размещать, как рекламу могут расценить). Там и бенчмарки, и скрипт, считающий Validator Points, и ноды, и инструкции по раскатке всего этого добра и еще много всего а в течение игры появилось наверное с десяток разных инструкций как все собирать и запускать. Ну и про Ethereum неправда, здесь я рассказывал про форк EOS, а EOS — это третье поколение как раз Bitshares — та же команда делала
а полная нагрузка зависит сильно от характера действий пользвателей. В случае сетей все просто — задача доставить данные дальше. В блокчейнах надо сначала запроцессить, а потом, если данные ок — передать дальше. И вот это «запроцессить» может быть как простейшей транзакцией по переводу криптовалюты, так и довольно тяжеловесным вызовом смарт-контракта, который занимает по полсекунды на исполнение, а может чатсью атаки на консенсус, которая вызовет активную «переписку» между валидаторами блокчейна. Поэтому внутри аналога «магистральной» в p2p сети все куда менее предсказуемо и сильнее зависит от характера клиентской нагрузки. Ну и «включаете систему на полную нагрузку» здесь трудно определить — какой профиль нагрузки считается «на полную»?
В теоретическом плане — да, в теории интернет может предоставить неограниченное количество tps. Но что если я строю блокчейн, в котором клиент выполняет множество сложных вычислений, и при этом измеряю кучу метрик быстродействия? Для клиента важно, что его компьютер не успевает вычислять содержимое транзакций и отправлять их вовремя. Как мне не перепутать ситуацию, когда я уперся в блокчейн часть, с той, когда клиент тупо не успевает формировать запросы? Кроме того у многих проектов есть промежуточные сервера, например в LIghtning или Plasma. С точки зрения обычных сетей — наверное метрики клиентов не важны. Но в сетях, где клиенты выполняют большую часть процессинга надо измерять и на клиентах, также, уже виднеются на горизонте сети, где общая производительность будет почти складываться из производительностей клиентов, и там роль этих метрик еще возрастет.
я считаю это не совсем честно по отношению к клиенту сети. Почему «последняя миля» не учитывается? Если взять например блокчейн, где клиенты выполняют массивные вычисления, или при получении некоторых данных должны их расшифровать, накатить на свои базы, или пообщаться с другими клиентами — то это может быть значимый кусок производительности всей сети. Вы можете получить ситуацию «алло шеф, у меня транзакции по полминуты висят», а в ответ: «ничего не знаем, у нас по графику 1000 tps в магистральной сети».
Есть еще проекты где клиенты соединяются между собой, а еще есть L2 решения — когда одна цепочка коммитит изменения и диспуты в вышестоящую L1 цепочку — в этих случаях с производителностью все совсем сложно. Так что клиентскую часть в децентрализованных сетях имеет смысл учитывать. В традиционных системах клиент обычно ничего серьезного не делает, шлет мелкие запросы да качает данные, поэтому их и не измеряют.
Спасибо за коммент — действительно стоило рассказать про этот вид алгоритмов, я, честно говоря, был ограничен объемом статьи, слишком большая получалась, поэтому все что хотелось не удалось затолкать. Тоже изучали VDF, по сути proof-of-work эфира или биткоина это тоже в некотором роде VDF и для мелочевки можно и его использовать. У нас еще очень важным требованием является быстрая финальность, поэтому сходу подобрать VDF под необходимость выдавать строго надежный beacon каждую секунду-две нам не удалось и мы решили разбить задачу на две: сначала сделать быструю и предсказуемую генерацию PVRB из наждежного seed, а вот генерацию seed — вынести в отдельную, возможно медленную и асинхронную задачу, и вот там, возможно, VDF будут к месту.
Сгенерированный хеш, конечно же влияет на исторические данные системы, собственно он и есть эти данные, но его замена невозможно без атаки на консенсус сети, кроме того финальность сильно помогает в этом вопросе.
В случае рандома — как только появится железо, умеющее что-то сбрутить, сеть может хардфоркнуться на другой алгоритм, устойчивый к этой железяке. Кроме того, если такое железо появится, то скорее всего атаковать рандом не будет смысла — проще будет напрямую вывести криптовалюту с адресов.
что касается причины попыток найти PVRB, то как я сказал, PVRB в блокчейнах — то же самое что генераторы псеводслучайных последовательностей для симметричной криптографии на отдельных компьютерах. Эти генераторы — техническая основа огромного числа протоколов, поточных шифров, протоколов расширения ключа, даже хеширования.
И в блокчейнах происходит развитие этих концепций, по сути блокчейн-технологии — это про создание распределенных компьютеров, в которых недоверенные узлы объединяются для решения одной задачи. Поэтому merkle tree в них — аналог хеширования, PVRB — аналог ГПСП, транзакции — вызовы функций, и т.п. К сожалению, нюансов и атак очень много, поэтому нельзя взять и быстро на коленке запилить что угодно на блокчейне.
действительно, PoW — один из способов реализации PVRB — если затраты на подбор хеша огромны, то «перемайнивать» блок, ради нового значения рандома будет слишком дорого. Но все равно, если на кону возможность с гарантированной вероятностью больше 50% удваивать ставку, просто удвоив майнинговые мощности (выбирая между хотя-бы двумя рандомами), такой PVRB можно атаковать. Поэтому в таких PVRB все равно приходится делать протокол коллективной генерации — все должны потрудиться, отдать свои PoW хеши (или использовать иную Verifiable Delay Function), и из них сконструировать результат. Причем важно, что результат должен быть unbiasable — один и только один, вне зависисмости от действий сговорившейся группы участников.
Тут некоторое недопонимание — в криптографии вообще нет «доказанно стойких» (кроме XOR :)). Имеется в виду доказанно стойки при некоторых условиях. В реальности эти условия не соблюдаются, либо не имеют смысла. Поэтому приходится стараться максимально приближаться к «доказанно стойким» схемам. Например, когда мы гененрируем одноразовый ключ для симметричного шифрования, мы полагаемся на то, что наш генератор — стойкий. Это, возможно не так, но анализируя алгоритм, криптографы говорят, что «он стойкий, при условии что гененратор непредсказуем, и открытый текст непредсказуем, и т.д. и т.п.» Cardano занимается как раз реализацией различных практических вариантов PVRB, выбирая наиболее надежный. Учитывая опыт их команды, желающие могут просто подождать пока они это сделают и тупо забирать хороший рандом прямо из из блокчейна. Сначала они использовали одну схему, использующую Fiat-Shamir secret sharing, сейчас вроде стали другую, не смотрел пока, но буду писать следующую статью — постараюсь описать
угу. Ну можно выбрать из кучи форков эфира, например. Я люблю xDAI например (просто знаю сколько нужного софта ребята написали для экосистемы). Там быстро и дешево. Ну и решение на эфире можно вообще сделать сразу во всех эфирных БЧ :) Если используется один и тот же тип адресов, то один и тот же адрес может быть использован в нескольких БЧ.
1) это определяет чисто рынок, предсказать невозможно. Куча пользователей и ботов размещают ежедневно разное количество транзакций. Каждая из транзакций стоит от 21 000 до 10 000 000 gas (условные попугаи). Цену за газ ставит отправляющий, если майнеры долго не берут транзакцию, цену можно повысить. Поэтому там просто ауцкцион получается на каждом блоке. Бывают дни, когда твоя транзакция стоит 1$ и майнится 30 сек, бывает что 20$ и надо ждать 15 минут. Здесь не стоит ждать какой-то то надежности, если не готов платить и конкурировать с другими проектами, увы.
Если про ковид-паспорт, то, если хранить в БЧ самый минимум, например bool (вакцинирован), или timestamp c каким нить битовым полем, то это в Ethereum минимум модификация слота размером 256 бит (там любая опреация в storage квантуется блоками по 256bit). Апдейт ячейки стоит 5000 gas, создание новой ячейки - 20000 gas. Key-value c адресом это что-то типа двух ячеек (под ключ и под значение) - значит в районе 40000 gas за тразакцию (вообще это точно оценивается для конкретного контракта, но лень).
Текущие цены на газ (на сегодняшний день, смотрю на https://ethgasstation.info/) - это 17gwei (1 wei это 1 * 10 ^(-18) ETH), соответственно цена транзакции примерно 40 000 * 17 * 10^6 wei * 10^(-18) ETH. Но вообще я сегодня делал простенький approve в эфире - стоило 1.5$, так что цена где-то такая будет
блокчейнов без оплаты транзакций не существует. Даже если нативный токен не имеет никакой реальной стоимости, он все равно нужен для обеспечения безопасности сети - им оплачивается сложность транзакций, и он все равно есть (команда просто делает его "техническим", печатая и раздавая кому надо). Без токенов делают блокчейны корпораты, но, имхо, это просто понты, реально такие блокчейны нафиг не нужны никому. Зачем заменять быструю и эффективную БД медленным и тормозным БЧ при том же уровне безопасности? В блокчейнах возможность ОДНОМУ участнику всё сломать считается дырой в безопасности, а без оплаты транзакций любой ОДИН взломанный участник может заспамить БЧ бесплатным мусором.
В случае своего БЧ нативные токены можно "печатать" сколько хочется и раздавать универам просто так, вообще не присваивая токену никакой финансовой ценности (да ее и не будет, если сказать, что команда в любой момент может напечатать кому угодно ахулиард токенов). Тем не менее с точки зрения безопасности все строго - если у спамера нет токенов - он ничего не сделает, а универ просто так их никому не даст.
Про "стоимость" архитектуры не очень понял вопроса, попробую ответить как понял.
Web-часть поддерживается как обычный web проект, единствено, что для БЧ это могут быть крайне легковесные frontend-ы, которые можно чуть ли не в виде html файлов распространять. А вот про блокчейн-часть:
Если делать свой блокчейн - то суммарно всей сети придется платить реальные деньги за работающие блокчейн-ноды, зарплату админам, за доработаку клиентского софта, обновления и т.п. Похоже на разработку форка какой нибудь опенсорсной СУБД.
Если использовать готовые сети типа Ethereum, то можно вообще ничего не поддерживать кроме нескольких своих нод для надежности, с минимальной поддержкой, но за каждую операцию придется платить в ETH.
Можно использовать testnet Ethereum и вообще не платить за ноды (их уже держат раработчики), а для транз использовать тестовый эфир(можно получить его себе бесплатно). Цена владения такой системой вообще почти нулевая (рекомендую, если вы студенческий проект делаете)
Ну, любые текущие системы требуют также танцев с бубуном - например владения почтовым ящиком, который может исчезнуть, или начать класть в спам письма, или телефона.
Я в конце написал, что никаких "забыл пароль" в этих схемах не будет - этот функционал изначально хромой - как был хромым функционал "выслать пароль на email". "Менять пароль" должен сам пользователь, а не сервис, без малейших дейсттвий на стороне сервиса, это его аккаунт и только ему им управлять. Проблема угнанных аккаунов решается созданием двухуровневых identity - master ключа и рабочих аккаунтов, которые master всегда может заменить.
Это долгая дискуссия, если кратко - это да, другая схема, которая сильно отличается от привычной. Но почему-то W3C ее принимает и развивает, а SSI и VC - это уже существующие тренды развития интернета. Ну и как то в DeFi крутятся десятки млрд $ в день без всяких восстановлений паролей, здесь первым делом в любых сервисах пишут огромными буквами "нет seed phrase, нет и мультиков"
В общем со стороны пользователя — действительно, есть какие-то проблемы.
С точки зрения алгоритмов — все в порядке: и с газом и с кодом контракта, уж не знаю чем вам байт-код не угодил, ибо на JS, к сожалению ничего детерминированного не напишешь, увы — и байт-код — это тот же исходник, в EVM он элементарно декомпилится в довольно осмысленный код. Код можно проверить, изучить, то что это нельзя сделать кому угодно — это лишь техническая проблема. Не доверяйте неверифицированным контрактам — делов то…
Ладно, дискуссия совсем тухлая стала
Байт-код контракта, который вы прислали: 0x6060604052361......91b4b7370029, можно посмотреть по ссылке: etherscan.io/address/0xbcc394d45c3613530a83cae62c716dc23b7f2152#code
То, что вам не написали его в виде, похожем на JS, не значит что его нет. Это полноценный код, инструкции EVM, которые нельзя подделать, вместе с параметрами конструктора, и стоимость процессинга этого кода строго детерминирована.
Так что вы неправы и в том, что «количество газа на вызов нельзя определить» и в том что «код контракта недоступен», не вводите в заблуждение людей.
Пожалуй соглашуть только с тем, что производные криптовалюты типа USDT могут реализовывать всякие скамные штуки — но это также публично(!) проверяемо.
Всему этому обычные централизованные финансовые сервисы могут противопоставить только слова и бумажки, а «современные банковские сервисы» с точки зрения смарт-контрактов — это примитивные простейшие алгоритмы, которые может реализовать любой студент
github.com/DaoCasino/Game-of-Stakes — общая репа для участников игры, где:
github.com/DaoCasino/Game-of-Stakes/tree/master/dao-vp-counter — скрипт публичного подcчета VP
github.com/DaoCasino/Game-of-Stakes/tree/master/run-producer — инструкции и скрипты для запуска и управления нодой валидатора
github.com/DaoCasino/DAObet — собственно нода запускаемого БЧ (кстати сильно помогли с поиском багов и запуском сети те, кто не пользовался инструкциями, докером, а сами все собрали и автоматизировали)
github.com/mixbytes/tank — тулза для оркестрирования блокчейнами и бенчмаркинга, которую мы использовали для запуска тестнета (точнее аж трех тестнетов, в т.ч. и для игры валидаторов), запуска Prometheus/Grafana и сбора метрик
github.com/mixbytes/tank.bench-common — базовый модуль для проведения бенчмарков (умеет в много потоков подписывать и швыряться транзакциями в ноды)
github.com/mixbytes/tank.bench-haya — бенчмарк на основе tank.becnch-common для тестирования блокчейна Haya (на базе которого построен БЧ, в котором проводится игра валидаторов)
бенчмарки, нагружающие разные подсистемы контрактов в приватных репах сходу не нашел, может мы из и не открывали. Но запускали точно — в наших интересах было посмотреть как справятся валидаторы…
ну и еще всякие доп. тулзы: block explorer, голосовалка, еще там что-то — под EOS можно найти много.
Есть еще проекты где клиенты соединяются между собой, а еще есть L2 решения — когда одна цепочка коммитит изменения и диспуты в вышестоящую L1 цепочку — в этих случаях с производителностью все совсем сложно. Так что клиентскую часть в децентрализованных сетях имеет смысл учитывать. В традиционных системах клиент обычно ничего серьезного не делает, шлет мелкие запросы да качает данные, поэтому их и не измеряют.
В случае рандома — как только появится железо, умеющее что-то сбрутить, сеть может хардфоркнуться на другой алгоритм, устойчивый к этой железяке. Кроме того, если такое железо появится, то скорее всего атаковать рандом не будет смысла — проще будет напрямую вывести криптовалюту с адресов.
И в блокчейнах происходит развитие этих концепций, по сути блокчейн-технологии — это про создание распределенных компьютеров, в которых недоверенные узлы объединяются для решения одной задачи. Поэтому merkle tree в них — аналог хеширования, PVRB — аналог ГПСП, транзакции — вызовы функций, и т.п. К сожалению, нюансов и атак очень много, поэтому нельзя взять и быстро на коленке запилить что угодно на блокчейне.