Pull to refresh

Comments 19

Оригинальный пост содержит ошибку валидации двух одинаковых цепочек

Замечательно все. Но зачем для того, чтобы запомнить значение пульса, городить такой огород? Нельзя ли это в json класть или в ближайшее?

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

поправьте "медЕцине" в конце статьи, пожалуйста.

В половине мест BPM, в другой BMP.
На последнем скриншоте у первого блока нет PrevHash
Уже который о счету тутор про «пишем блокчейн в *** строчек кода на ***» и всегда в конце приписка, мол «а про сетевое взаимодействие в следующих частях» и привет. Как правило следующие части так и остаются обещаниями.

Понятное дело, что это перевод и претензий к переводчику нет никаких, но все же. Не менее интересна реализация децентрализации.

ЗЫ.

А почему нет плашки перевод?
Что-то не совсем понятно на счёт решения коллизий. Ну выбрали мы более длинную цепь, я так понимаю объединили в общую цепь. А что делать с более короткой? Куда девается она? Отбрасывается в мусор? Как быть с индексами при объединении цепей? Они же не будут совпадать с порядком индексов общей цепи.
По моему данный пример наглядно иллюстрирует тотальное непонимание системы блокчейн и того, зачем она нужна. В приведенном примере полностью отсутствует майнинг, который как раз гарантирует защиту децентрализованный данных при помощи PoW. Какой смысл хранить последовательные блоки, хранящие хеш предыдущего, если в такой системе можно обновить случайный блок в цепи, а потом за секунду перехешировать всю цепочку? Чем это вообще лучше обычной реляционной БД, которая уже готова, и которая предоставляет уровень «защиты от подтасовки» ровно такой же, то есть нулевой?
Да, вы правы. Авторы статьи хотели простыми словами объяснить, что такое блокчейн. А сетевое взаимодействие будет в последующих постах.
Как мне кажется PoW так же мало что гарантирует (но может я и ошибаюсь).
Да, каждый блок подписан «красивым хэшем», на который нужно потратить усилия.
Проблема в том, что у первых блоков не требовался «сильно красивый хэш».
У первых блоков в цепочке, защита (difficulty) была хороша на тот момент времени, когда они создавались. Иными словами, первые блоки чейна посчитанные на CPU пересчитать нынешними асик майнерами — плевое дело. Единственная но существенная проблема как изменить и пересчитать скажем только первые N блоков и потом присоединить измененные начальные блоки к последующим неизмененным (которые все труднее и труднее пересчитывать)?
Далее с течением времени производительность вычислителей скорее всего будет расти.
То что сейчас невозможно быстро пересчитать будет возможно пересчитать через некоторое время.
Если появится принципиально новый вычислитель с мощностью более 51% всей мощности сети, и он не будет задействован в майнинге, то тогда блокчейну конец. Получится переподписать всю историю с самого начала и создать альтернативную историю. Но тут *скорее всего* сыграет роль огромное количество пользователей блокчейна, которые быстро используют тот же вычислитель в целях майнинга, и тогда такой проблемы не будет.

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

А как у вас Chain interface связан с функциями getBlock, getBlock и др? У вас функции сами по себе, а интерфейс сам по себе… это как минимум странно.

По сути, там Интерфейс не нужен, если говорить о том коде, что сейчас есть. Но есть пару нюансов: это первый проект на Го и я пробовал все, в том числе и Интерфейсы; предполагается, что еще появятся методы для работы по сети и типа Интерфейс про запас :)
UFO just landed and posted this here

Мне кажется, или в функции isBlockValid повторно вычисленных хэш должен совпадать с уже сгенереным?
"if calculateHash(newBlock) = newBlock.Hash "

Там происходит проверка если вновь сгенерированный хэш не равен хэшу этого блока, то возращаем false т.е. блок невалидный.
Sign up to leave a comment.

Articles