• Что такое игра валидаторов или “как запустить proof-of-stake блокчейн”
    0
    уф, чувствовал, что нарвусь :)

    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 можно найти много. 
  • Что такое игра валидаторов или “как запустить proof-of-stake блокчейн”
    0
    Что значит абстрактный список? Весь приведенный в статье код открыт и валяется в гитхаб репозитариях mixbytes и DaoCasino (просто линки на гитхабы фиг знает, можно ли размещать, как рекламу могут расценить). Там и бенчмарки, и скрипт, считающий Validator Points, и ноды, и инструкции по раскатке всего этого добра и еще много всего а в течение игры появилось наверное с десяток разных инструкций как все собирать и запускать. Ну и про Ethereum неправда, здесь я рассказывал про форк EOS, а EOS — это третье поколение как раз Bitshares — та же команда делала
  • Сколько TPS в вашем блокчейне?
    0
    а полная нагрузка зависит сильно от характера действий пользвателей. В случае сетей все просто — задача доставить данные дальше. В блокчейнах надо сначала запроцессить, а потом, если данные ок — передать дальше. И вот это «запроцессить» может быть как простейшей транзакцией по переводу криптовалюты, так и довольно тяжеловесным вызовом смарт-контракта, который занимает по полсекунды на исполнение, а может чатсью атаки на консенсус, которая вызовет активную «переписку» между валидаторами блокчейна. Поэтому внутри аналога «магистральной» в p2p сети все куда менее предсказуемо и сильнее зависит от характера клиентской нагрузки. Ну и «включаете систему на полную нагрузку» здесь трудно определить — какой профиль нагрузки считается «на полную»?
  • Сколько TPS в вашем блокчейне?
    0
    В теоретическом плане — да, в теории интернет может предоставить неограниченное количество tps. Но что если я строю блокчейн, в котором клиент выполняет множество сложных вычислений, и при этом измеряю кучу метрик быстродействия? Для клиента важно, что его компьютер не успевает вычислять содержимое транзакций и отправлять их вовремя. Как мне не перепутать ситуацию, когда я уперся в блокчейн часть, с той, когда клиент тупо не успевает формировать запросы? Кроме того у многих проектов есть промежуточные сервера, например в LIghtning или Plasma. С точки зрения обычных сетей — наверное метрики клиентов не важны. Но в сетях, где клиенты выполняют большую часть процессинга надо измерять и на клиентах, также, уже виднеются на горизонте сети, где общая производительность будет почти складываться из производительностей клиентов, и там роль этих метрик еще возрастет.
  • Сколько TPS в вашем блокчейне?
    0
    я считаю это не совсем честно по отношению к клиенту сети. Почему «последняя миля» не учитывается? Если взять например блокчейн, где клиенты выполняют массивные вычисления, или при получении некоторых данных должны их расшифровать, накатить на свои базы, или пообщаться с другими клиентами — то это может быть значимый кусок производительности всей сети. Вы можете получить ситуацию «алло шеф, у меня транзакции по полминуты висят», а в ответ: «ничего не знаем, у нас по графику 1000 tps в магистральной сети».
    Есть еще проекты где клиенты соединяются между собой, а еще есть L2 решения — когда одна цепочка коммитит изменения и диспуты в вышестоящую L1 цепочку — в этих случаях с производителностью все совсем сложно. Так что клиентскую часть в децентрализованных сетях имеет смысл учитывать. В традиционных системах клиент обычно ничего серьезного не делает, шлет мелкие запросы да качает данные, поэтому их и не измеряют.
  • Случайные числа и децентрализованные сети: имплементации
    +1
    Спасибо за коммент — действительно стоило рассказать про этот вид алгоритмов, я, честно говоря, был ограничен объемом статьи, слишком большая получалась, поэтому все что хотелось не удалось затолкать. Тоже изучали VDF, по сути proof-of-work эфира или биткоина это тоже в некотором роде VDF и для мелочевки можно и его использовать. У нас еще очень важным требованием является быстрая финальность, поэтому сходу подобрать VDF под необходимость выдавать строго надежный beacon каждую секунду-две нам не удалось и мы решили разбить задачу на две: сначала сделать быструю и предсказуемую генерацию PVRB из наждежного seed, а вот генерацию seed — вынести в отдельную, возможно медленную и асинхронную задачу, и вот там, возможно, VDF будут к месту.
  • Случайные числа и децентрализованные сети: имплементации
    0
    Сгенерированный хеш, конечно же влияет на исторические данные системы, собственно он и есть эти данные, но его замена невозможно без атаки на консенсус сети, кроме того финальность сильно помогает в этом вопросе.

    В случае рандома — как только появится железо, умеющее что-то сбрутить, сеть может хардфоркнуться на другой алгоритм, устойчивый к этой железяке. Кроме того, если такое железо появится, то скорее всего атаковать рандом не будет смысла — проще будет напрямую вывести криптовалюту с адресов.
  • Случайные числа и децентрализованные сети: практическое применение
    0
    что касается причины попыток найти PVRB, то как я сказал, PVRB в блокчейнах — то же самое что генераторы псеводслучайных последовательностей для симметричной криптографии на отдельных компьютерах. Эти генераторы — техническая основа огромного числа протоколов, поточных шифров, протоколов расширения ключа, даже хеширования.
    И в блокчейнах происходит развитие этих концепций, по сути блокчейн-технологии — это про создание распределенных компьютеров, в которых недоверенные узлы объединяются для решения одной задачи. Поэтому merkle tree в них — аналог хеширования, PVRB — аналог ГПСП, транзакции — вызовы функций, и т.п. К сожалению, нюансов и атак очень много, поэтому нельзя взять и быстро на коленке запилить что угодно на блокчейне.
  • Случайные числа и децентрализованные сети: практическое применение
    0
    действительно, PoW — один из способов реализации PVRB — если затраты на подбор хеша огромны, то «перемайнивать» блок, ради нового значения рандома будет слишком дорого. Но все равно, если на кону возможность с гарантированной вероятностью больше 50% удваивать ставку, просто удвоив майнинговые мощности (выбирая между хотя-бы двумя рандомами), такой PVRB можно атаковать. Поэтому в таких PVRB все равно приходится делать протокол коллективной генерации — все должны потрудиться, отдать свои PoW хеши (или использовать иную Verifiable Delay Function), и из них сконструировать результат. Причем важно, что результат должен быть unbiasable — один и только один, вне зависисмости от действий сговорившейся группы участников.
  • Случайные числа и децентрализованные сети: практическое применение
    0
    Тут некоторое недопонимание — в криптографии вообще нет «доказанно стойких» (кроме XOR :)). Имеется в виду доказанно стойки при некоторых условиях. В реальности эти условия не соблюдаются, либо не имеют смысла. Поэтому приходится стараться максимально приближаться к «доказанно стойким» схемам. Например, когда мы гененрируем одноразовый ключ для симметричного шифрования, мы полагаемся на то, что наш генератор — стойкий. Это, возможно не так, но анализируя алгоритм, криптографы говорят, что «он стойкий, при условии что гененратор непредсказуем, и открытый текст непредсказуем, и т.д. и т.п.» Cardano занимается как раз реализацией различных практических вариантов PVRB, выбирая наиболее надежный. Учитывая опыт их команды, желающие могут просто подождать пока они это сделают и тупо забирать хороший рандом прямо из из блокчейна. Сначала они использовали одну схему, использующую Fiat-Shamir secret sharing, сейчас вроде стали другую, не смотрел пока, но буду писать следующую статью — постараюсь описать
  • Случайные числа и децентрализованные сети: практическое применение
    0
    черт, это было указание на опечатку :)
  • Случайные числа и децентрализованные сети: практическое применение
    0
    ну можно сравнить атаку на PVRB в каком нибудь онлайн казино, и атаку на PVRB, работающего в алгоритме консенсуса какого нибудь блокчейна типа EOS. Вторая позволяет сделать double spend и потенциально организовать кидок на десятки миллионов (в зависимости от тоо, сколько в атаку может вложить атакующий). В первом случае — придется обманывать казино, а оно обычно ограничивает размеры ставок, да и с KYC может прижучить. Поэтому игры — это важно, и, наверное, какая нибудь огромная лотерея и может являться вкусной целью, но у блокчейна к PVRB есть и более серьезные запросы. Кстати про арбираж сделок и RandPay там тоже неспроста — эти задачи важны также и с инженерной точки зрения — чтобы поддержать масштабирование блокчейнов и убрать ненужные взаимодействия.
  • Случайные числа и децентрализованные сети: практическое применение
    0
    Имелась в виду доказуемая надежность консенсуса, а не PVRB. Это означает, что если PVRB стойкий, то консенсус доказуемо такой же стойкий, как PVRB. «Доказуемо стойкий» никогда не означает «защищен навсегда от всего», а обычно означает что «при заданных допущениях — взломать ту часть, которая доказуемо стойкая не получится». Ключевое здесь «при заданных допущениях».
    Например есть «доказуемо стойкий» шифр Шеннона, который является в первую очередь моделью, для доказательства стойкости других шифров, а не реальным алгоритмом. В чистом виде он неюзабелен
  • Случайные числа и децентрализованные сети: практическое применение
    0
    имеется в виду доказуемой стойкостью равной стойкости используемого PVRB. Типа «если используемый рандом идеально стойкий, то Ouroboros доказуемо имеет ту же степень стойкости». Это частая история в криптографии — например когда используют хеширование, допускают что оно «идеально стойкое», чтобы оценивать остаток алгоритма. В случае Ouroboros более-менее понятно почему доказуемо стойкое — если «идеально рандомно» выбирать BP, то чаще будут выбираться честные BP если их тупо больше чем нечестных. Но каждый раз когда вы добавляете очередное усложнение в протокол, возможна порча этой доказуемости…
  • Случайные числа и децентрализованные сети: практическое применение
    0
    ну у этой схемы (называется commit-reveal) проблемы с контролем бита. Если я на последнем шаге «говорю свое число», то перед тем как «говорить» я могу решить, стоит мне это делать или нет и тем самым контролирую результат. Прикидываю что получится и в том и в другом варианте (к примеру я играю на «красное-черное» в рулетку и выбираю тот рандом, который приводит именно к «черному»).
    Я уже готовлю следующую статью, там как раз и разберу почему схема на хешах применима, но очень ограничено. Если про «вскрытие-невскрытие», то обычно это решают депозитом на этапе commit, который отнимут, если не будет reveal. Но это ограничивает цену игры и для консенсусов и других важных вещей не годится
  • Случайные числа и децентрализованные сети: практическое применение
    0
    Здесь очень много технических нюансов, и сплетается одновременно и криптография, и архитектура систем, плюс — крайне мало готового кода, гораздо чаще — proof-of-concept или вообще голая статья. Также, ограничения блокчейна все таки крайне серьезные, и все это делает задачу еще сложнее. Статью по конкретным решениям конечно хочется хорошо написать, а инфы крайне мало, и можно легко ошибиться или пропустить что то реально важное. Поэтому я так расплывчато написал когда и про что напишем. Да нам и самим надо понять, стоит ли нам раскрывать сейчас как мы хотим эту задачу решать в ближайшее время, или продолжать мониторить криптографов, пока они не разродятся еще каким нибудь решением, которое «на этот раз уже точно». За похвалу спасибо, будем стараться писать интересно
  • Гайд по автоматическому аудиту смарт-контрактов. Часть 2: Slither
    0
    Спасибо, постараюсь дальше тоже интересно писать :) Про недостаток инфы — правда, найти много хорошей доки по смарт-контрактам в одном месте не получится — молодая крайне область, довольно специфичная и недостаток статей и книг чувствуется.
  • Пять камней в огород блокчейна
    0
    ну NFC в мочке уха это капец несекъюрно, а тату — особенно, сфоткали разок и твой ID слит. Заодно можно и горные лыжи повпаривать. А по поводу «грузится блокчейн» тоже не стоит, он как раз в силу доступности кучи нод в чужих горах понадежней будет традиционных сервисов. Полезете на гору в Тибете, а великий китайский файрвол заблокирует сервера аутентификации для вашего NFC в ухе. Ну а хранение медицинской инфы на блокчейне имхо не вариант вообще, он для другого создан
  • Пять камней в огород блокчейна
    0
    Слишком масштабно для первой пробы технологии. Конечно же нет, и космолеты, запускаемые кучей проектов разумеется сразу не полетят. Ценность блокчейна — в дешевизне и простоте архитектуры. Он не лечит от ошибок и обмана, это просто алгоритмы, в которых целостность данных и неоспоримость исполнения кода стоит на первом месте. Не путайте ее с человеческой «честностью» данных — это совершенно разные вещи. Имхо, сначала всё таки зарботает что то небольшое — типа продажи кофе или каких то информационных услуг, и только после сотен проб технологии мы возможно перейдем к тем самым «неоспоримым реестрам»
  • Пять камней в огород блокчейна
    +1
    Ну вообще то, если говорить об операциях с недвижимостью, то конечно же тупая девочка должна быть не одна, а вместе с валидаторами, которые не дадут ошибиться в фиксации сделки. Кроме того проблемы «девочки» и в государственном реестре точно так же актуальны, ибо эта централизованная инфа растекается по сотням внешних баз, и исправление ошибки в центральной базе не факт что доедет до периферии. Только в случае блокчейна отловить ошибку будет намного проще. Ну и вообще, приведение частной ошибки при обсуждении технологии — не особо правильно — ибо то, что вы описали, можно просто предусмотреть заранее.
  • Погружение в разработку на Ethereum. Часть 0: блокчейн не нужен
    0
    Да, порог входа для обычных юзеров сейчас по прежнему крайне высокий, 90% отваливаются не дойдя до эфира ваще, мы это хорошо видим на проекте. Оппонирую я больше по привычке, на хабре обычно первый комментарий под любой статьей про крипту — хейтерский :) А за статью спасибо, всё по делу и полезно для ознакомления всем блокчейн-разработчикам.
    Кстати, по поводу фейсбука — только вчера читал текст от Цукерберга, где тот грозится изучить вопрос децентрализации очень подробно, и он там явно говорит, что понимает насколько паршивая сейчас ситуация, и что собирается заняться вплотную вопросом.
  • Погружение в разработку на Ethereum. Часть 0: блокчейн не нужен
    0
    Существующие системы тоже не очень то успешно решают вышеописанные проблемы, под каждый ваш пункт можно найти пример из облажавшихся централизованных систем.

    Регистрация на фейсбуке с емейлами-подтверждениями и сливом данных всем кому ни попадя проще чем установка расширения Metamask в два клика (ну а эфир к примеру друг кидает мне на 10$, этого хватит чтобы сотни простых транзакций послать)?

    Биржи зачем записали в «блокчейн»? Они централизованные, и блокчейн там совсем сбоку прикручен.

    Вы описываете проблему публичных данных, в то время, когда в централизованных системах из за утечек тех самых «защищенных» централизованно данных воруют миллионы аккаунтов — не лучше ли сразу делать системы, в которых данные, которые можно своровать отсутствуют?

    С чего это блокчейн должен решить проблему цензуры?

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

    Неохота быть эдаким восторженным фанатом блокчейна (хотя в душе я им являюсь, канеш), действительно, блокчейн не волшебная палочка и за его преимущества надо платить, он точно не под все задачи годится. Но в правильных областях и правильно приготовленный он совершенно точно гораздо привлекательнее любых существующих систем. Всё в точности так же, как было когда появились первый сайты и браузеры, которые потихоньку вытеснили почти весь софт для обмена публичной информацией в компьютерных сетях
  • Делаем web-аутентификацию через блокчейн
    0
    Для эфира точно так же можно использовать web3.js без всякого метамаска. Правда от необходимости иметь эфир для отправки транзакций и ставить подпись на транзакцию это не спасет. Большой разницы на фронтенде между EOS и Etheereum нет.
  • Делаем web-аутентификацию через блокчейн
    0
    В теории может. Тут есть естественная защита, в виде комиссии за любую транзакцию, т.е. спамеру дорого будет стоить любая массированная атака на Ethereum, поэтому просто валить тупыми транзакциями по изменению данных бессмысленно. Но если этот контракт является более сложным, например оплачивает работу валидаторов данных, то атака типа «автматически валидировать всё и получать за каждое действие награду» вполне реальна и опасна, никаких возможностей остановить ее у децентрализованных сетей нет, любая валидная транзакция будет выполнена. Невозможность останавливать такие атаки — одна из серьезных проблем блокчейна.
  • Делаем web-аутентификацию через блокчейн
    0
    Как раз для identity скорость сети эфира вполне себе нормальная — перевыпуск ключа — ситуация крайне редкая и эфир без проблем потянет. Если каждый пользователь перевыпускает ключ раз в полгода, то никаких нагрузок на сеть не будет. А проверяется авторизация off-chain и тут можно как угодно разгонять сервис, хоть до миллиона запросов в секунду — это ж просто проверка подписи, она не требует ходить в эфир.
    Hyperledger для персональных identity — точно не вариант. Ценность identity в том, что я сам контролирую свои аккаунты и никто не забанит мой аккаунт и не отключит. Hyperledger — штука централизованная, я бы ей точно не доверил свою identity. Вместо него можно публичную MySQL поставить — толку будет столько же.

    Ну а про «throughput» — чесгря не очень здорово, когда люди обсуждают количество транзакций в секунду, так, как будто это единственное число, которым блокчейны меряются. Никто из системных архитекторов не оперирует одним лишь числом транзакций в секунду — эта метрика годится для какого нибудь примитивного API с приблизительно одинаковым паттерном использования, во всех остальных случаях количество транзакций в секунду имеет смысл обсуждать только под конкретные задачи, с указанием всех условий и точным описанием того, что считать «концом» транзакции, какова цена отката, и еще десятка важных параметров. Оно зависит от типа транзакций (большие или маленькие), характера транзакций (требуют исполнения серьезных кода или нет), устойчивости к разделению сети, от типа финализации блоков (например в биткоине и эфире математически, пропускная способность может быть 0 транзакций за тысячу лет, ибо алгоритм консенсуса — вероятностный). Никто не спорит про скорость обработки транзакций в блокчейне, разумеется она медленней на порядки, чем в централизованных сервисах, но за это вы получаете независимую от кого бы то ни было и неоспоримую обработку ваших данных, и для identity этот фактор гораздо важнее, чем скорость.
  • Делаем web-аутентификацию через блокчейн
    0
    EmerSSL — классная, давно про нее знаю, она куда изящней и технологичней централизованной системы сертификатов. Мы тоже думаем, что для децентрализованной identity еще рано, равно как и для широкого использования смарт-контрактов. Люди только освоили восстановление аккаунтов по емейлу и не желают тыкать ни во что, сложнее чем лайк или «login with Facebook». Но как прижмет, уверен, научатся быстро.
  • Делаем web-аутентификацию через блокчейн
    0
    Про мартышку было всё таки ближе к истине — очень много тех кто крутит блокчейн и та и сяк, стараясь присобачить хоть как то к своему бизнесу, чтобы срубить бабла.
    А вот на identity зря ругаетесь — здесь как раз блокчейн очень даже применим — крайне удобно самому управлять своими идентификационными данными и аккаунтами, не завися ни от каких внешних сервисов.
  • Делаем web-аутентификацию через блокчейн
    0
    Нужно просто уметь отправить транзакцию в Ethereum. Если использовать тестовую сеть то от начала установки метамаска до первого логина — где то минута, да и то — это чтобы записать seed фразу. Если нужна боевая сеть, то потребуется сам эфир, где то на одну транзакцию (это от нескольких центов до доллара, в зависисмости от нагрузки на сеть)
  • Делаем web-аутентификацию через блокчейн
    0
    ах Моська, знать она сильна…
  • P2P-споры на блокчейне
    0
    как раз пример того, что в теории алгоритм контракта кажется понятным и простым, но на деле приходится множество дополнительных решений принимать. Для реальных сделок приходится добавлять вспомогательный функционал, и его может быть даже больше, чем основного (взять например какой нить простейший вроде-бы invoice).
    Для этого контракта старались максимально упростить его для пользователя. Конечно можно было много всяких условий добавить и оракулы прикрутить, и следить за ними — только это ж отдельный проект. А у нас — конструкторы, которые, в идеале, должны быть представлены на платформе в десятке разных видов от разных разработчиков и с разным функционалом.
  • P2P-споры на блокчейне
    0
    welcome, по сложившейся традиции, первый пост в статье про блокчейн принадлежит хейтерам
  • Управляемые токенами реестры 1.0
    0
    1. раздаются в деканате
    2. через заранее заданное время позиция удаляется из рейтинга (с первой «вытесняющей» транзакцией), замороженные токены освобождаются и позицию надо будет восстановить. Либо использовать gradedTCR с постепенным освобождением токенов и «спуском» позиции вниз
    3. Студенты «голосуют» за любимых преподов, «замораживая» произвольное количество своих токенов. Елси позиция уйдет из реестра, токены автоматически возвращаются
    4. Контроль распределения токенов, обновление контракта реестра (если найдены ошибки). Конечно сотрудники также работают с токеном системы. Поступил студент в ВУЗ — выдали токен. Кто то стырил все токены — обновили контракт и восстановили реестр.
  • Управляемые токенами реестры 1.0
    0
    Окей, давайте обсудим реестр «любимых» преподавателей ВУЗ. Преподаватели, которые находятся в реестре, получают 10% премию к зарплате. Я считаю, что можно было бы организовать эту систему в виде TCR реестра.
  • Управляемые токенами реестры 1.0
    0
    Перед тем, как начать обсуждать алгоритмы не нужны никакие юзкейсы — мы не ТЗ здесь пишем. Мы не забыли про скрипт на Питончике и про «методики, которые наработало научное сообщество»? Что там за методики, которые убедят меня что вы не наврали в сборе статистики, что вас не взломали, что у вас не купили место в реестре, что не накрутили статистику? TCR — это и есть один из БАЗОВЫХ элементов тех самых «методик».
  • Управляемые токенами реестры 1.0
    0
    Я правильно понимаю, что ваш посыл в том что «изначальный посыл дрянь» и не стоит этим заниматься? В таком случае это аргумент для фейсбука, но никак не для хабра. Если есть аргументы относящиеся к алгоритму, описывающие конкретные атаки на TCR — welcome, для нас такие комментарии — чистое золото, т.к. каждый — потенциальная атака на алгоритм. А поговорить «кому оно это всё нужно» — это можно на фейсбуке, мы там такие разговоры уже задолбались вести.
  • Управляемые токенами реестры 1.0
    0
    1. Можно (и нужно) сделать экспоненциальную модель stake-инга, ввести ограничения и лимиты. «отняли здесь, прибавили там» — это про унылый фиат, здесь свобода в плане алгоритмов почти полная
    2. замороженные токены, который можно оспорить и перераспределить — это имхо уже не «исключительное владение». Сам базовый токен — возможно (да и то, если использовать мультисиг, то тоже можно поспорить)
    3. также ограничивается программными методами и может быть исправлено на более справедливые варианты. К примеру передача токена возможна только уже голосовавшим, а остальным — лишь в сильно ограниченном объёме.

    Я как раз за усложнение всех этих моделей и уход от самой примитивной модели токена — она как раз крайне неустойчива к запретам и беготне с пистолетами. К сожалению сейчас придется организовывать это с участием «традиционных ценностей» — спекулянства и pump-ов-dump-ов — и это крайне печалит. Успокаивает то, что были же времена, когда люди к автомобилю на лошади подъезжали, увы, разом на децентрализованные системы не перескочишь.
  • Управляемые токенами реестры 1.0
    0
    Есть куда более порочное в попытке считать токен системы баблом. Именно благодаря этому перекошенному видению развивается спекулянство и торговля криптой, а не технологии, грамотно использующие ее преимущества.
  • Управляемые токенами реестры 1.0
    0
    эти контракты — скорее библиотеки, и TCR — это алгоритм, а не конкретный контракт. Искать в блокчейне контракты, использующие внутри себя TCR — это как искать в интернете сайты, на которых есть «таблица с сортировками». Ну а навскидку, активность там такая же, как и остальных популярных смарт-контрактов — крайне небольшая. Люди пока в основе своей только торговлю токенами освоили, более сложные контракты пока крайне мало кем используются.
  • Управляемые токенами реестры 1.0
    0
    Платить будут те, кто хочет чтобы в реестре появился преступник и кто не боится, что остальные участники реестра его «выкинут», отняв токены. А держателям токена невыгодно, чтобы преступник появился в реестре, т.к. тогда ценность токена упадет. Там много всего можно запрогать под конкретный TCR — и запрет на разовую передачу большой доли токенов, или истекающий time-to-live «голосов», или еще сто разных механизмов.
    Это как минимум честнее любых существующих систем для «честных» реестров. До идеала, ясен пень, еще далеко, но это хороший шаг вперед.
  • Blockchain глазами разработчика
    0
    В IOTA вроде нашли дыру в самописной хеш функции. У всех DAG-ов крайне непонятная ситуация с атаками на консенсус. Атакующий может валить в DAG много собственных транзакций, «прокачивая» собственные, и в IOTA по-моему вначале как раз не было серьезных доводов против таких атак. В ByteBall эту проблему решают с помощью 12 доверенных узлов, а в IOTA вроде уже попробовали несколько вариантов решения, но общее впечатление, что перспективы «голого» DAG
    (без работы с вспомогательной основной цепочкой, как в BURST) пока мутные. Хотя это не отвергает того, что DAG — похоже единственный true способ получить такой блокчейн, чтобы каждая нода хранила не весь объем транзакций, а только те, которые интересуют только ее (ну и вспомогательные, для обеспечения работы консенсуса). Все имхо, канеш