✅✅✅
Технология Taproot
⬇️⬇️⬇️
Технология Taproot, ориентированна на повышенную гибкость смарт-контрактов при сохранении достаточно высокого уровня приватности. Предполагается, что пользователи не смогут отличить простые транзакции даже от самых сложных смарт-контрактов.

Изначально Taproot спроектировал разработчик Bitcoin Core и бывший CTO компании Blockstream Грегори Максвелл. На данный момент идет работа над имплементацией подписей Шнорра, которая включает в себя и технологию Taproot.

Taproot основан на следующем утверждении: любая MAST-конструкция, вне зависимости от уровня сложности, должна включать в себя условие, которое позволит всем участникам согласовать результат и подписать транзакцию вместе.

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

Если А знает, что Б все равно получит доступ к средствам на следующей неделе, он может работать с ней сообща, чтобы подписать транзакцию вместе.

Таким образом Taproot по своей структуре напоминает MAST, но всегда предполагает наличие условия, позволяющего всем участникам работать сообща для осуществления траты: так называемое «совместное закрытие».

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

Проблема заключается в том, что Taproot зависит от других технологий, которые также развернуты в Биткоине. Например подписи Шнорра.

Без подписей Шнорра Taproot не сможет работать в полную силу.

#SmartContracts

✅✅✅
Теперь о Graftroot
⬇️⬇️⬇️
Taproot эффективен в случае «совместного закрытия», однако альтернативные варианты предполагают раскрытие ветвей Меркла, что также тянет за собой обработку больших массивов данных.

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

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

Вернемся к ситуации с А и Б, которые могут осуществить трату средств при определенных условиях. У них есть опция «совместного закрытия», то есть А может потратить монеты через неделю или же это может сделать Б, если он задействует секретное число. В этом случае они оба объединяют публичные ключи и создают «пороговый публичный ключ», который позволит им осуществить трату при наличии “пороговой подписи”. Последнюю создадут при непосредственной трате.

Затем оба участника создают и подписывают альтернативные скрипты. А сохраняет «пороговую подпись» для скрипта, который позволит ей осуществить трату через неделю, а Б делает то же для сценария с секретным числом. Отметим при этом, что “пороговых подписей” и соответствующих сценариев для траты недостаточно: они служат лишь подтверждением, что Б и А договорились об условиях. Для осуществления траты необходимо выполнить условия, заложенные в скрипте.

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

Проблемой решения Graftroot является его интерактивность. Участники должны контактировать друг с другом для подтверждения альтернативных скриптов до траты. Кроме того, они должны хранить «пороговые подписи» для каждого из этих скриптов, и при их потере, они лишатся запасных вариантов для траты в случае провала «совместного закрытия».

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

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

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

#SmartContracts

Думал продолжить более подробно рассказать об атомарных свопах, но зачем?

Здесь кратко https://tttttt.me/CryptoBotan/706

Об этом уже и так подробно и ясно написали на хабре. Так что кому интересно прикладываю ссылочку. Я не лентяй, просто не вижу смысла, да и тем более понятнее я бы не написал😁
⬇️⬇️⬇️
https://habr.com/ru/post/458646/

Надеюсь вы еще не устали от постов про решения проблемы масштабируемости биткоина😄

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

Так что на сегодня у нас решение P2SH.
⬇️⬇️⬇️

Для начала.

Существуют такие виды транзакций как P2PKH и P2SH. (Еще был P2PK, но Сатоши решил взять P2PKH по весьма объективным причинам).

Pay-to-Public-Key-Hash (P2PKH) является основной формой совершения транзакции и наиболее распространенной формой транзакции в сети Bitcoin. Транзакции, которые платят на адрес Bitcoin, содержат скрипты P2PKH, которые разрешаются путем отправки открытого ключа и цифровой подписи, созданной соответствующим закрытым ключом.

Биткоин-адрес – это всего лишь хэш, поэтому отправитель не может предоставить полный открытый ключ в scriptPubKey.

При погашении монет, которые были отправлены на адрес Bitcoin, получатель предоставляет как подпись, так и открытый ключ.

Сценарий проверяет, что предоставленный открытый ключ выполняет хэширование для хэша в scriptPubKey, а затем он также проверяет подпись с открытым ключом.

Теперь P2SH (Pay-To-Script Hash) - это лёгкий способ представить scriptPubKey как простой BitcoinScriptAddress.🙁😕🤭

Бла бла бла...Википедия тем и сложна, что ничего не понятно.😄 Но суть уловили. Все дело в scriptPubKey.

А теперь чуть подробнее...

ScriptPubKey - это свойство которое содержит операторы языка и хэш публичного ключа получателя транзакции. Сценарий проверяет транзакцию на валидность.

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

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

Только держатель биткоинов знает, как можно их потратить, а сторонние наблюдатели не осведомлены об условиях траты до ее реализации. Это стало возможным за счет реализации решения P2SH (pay to script hash).

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

Но важно понимать, что при этом пользователи должны раскрывать все условия траты, включая и те, которые не были выполнены. И тут проявляется два основных недостатка:

1) Много данных для обработки
2)Проблемы с приватностью.

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

Кстати именно решение MAST и решило эти проблемы.

Слишком часто всплывает. Нужно будет отдельно поговорить о нем😏

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

Еще подробнее про P2SH по ссылочке
⬇️⬇️⬇️
https://ru.bitcoinwiki.org/wiki/P2SH

А почему бы и нет? Подвергай сомнению все...
⬇️⬇️⬇️
https://m.habr.com/ru/post/452486/

✅✅✅
Собрания мнений и мыслей которые не найдете на других каналах.😉

Агрегатор криптомнений и сборник крипторассказов
⬇️⬇️⬇️
https://tttttt.me/PrimeBlock

Сегодня нет сил писать, поэтому поделюсь мыслЁй, которая пришла мне в голову во время поездки на эскалаторе.🚀

Приведу пример разговора из книги
Тимоти Лири "Теория эволюции"

Эльпино: Как ты можешь заявлять, что человек есть личиночная форма некоего существа с высшим разумом и сознанием?

Филотео: Как ты можешь заявлять, что эволюция остановилась на нервной системе современного человека?

Эльпино: Рассуждать о Высшем Разуме, засевающем Землю запрограммированными генетическими матрицами, — абсурдно.

Филотео: Какова же твоя теория возникновения жизни? Книга Бытия? Случай и статистическая вероятность? Удары молний, инициирующие жизнь в смеси метана с аммиаком? То есть случайное зарождение?

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

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

И об этом стоит задуматься...но вы можете быть не согласны со мной. У каждого из нас есть свое мнение на этот счет😉

​​✅✅✅
Сегодня про решение MAST

Продолжим изучать инструменты по увеличению гибкости смарт-контрактов, а также масштабируемости и приватности сети Биткоин.
⬇️⬇️⬇️
MAST или Merkelized Abstract Syntax Trees (дословно Мерклизованные абстрактные синтаксические деревья)

Решение MAST включает в себя P2S и деревья Меркла

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

Главные функции дерева хэшей:

1) Способность присваивать каждому электронному документу собственный идентификатор (хэш);
2) Проверка целостности документа;
3) Восстановление удаленного файла.

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

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

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

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

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

Так же, как в случае с P2SH, все эти разные скрипты хэшируются. Однако на этот раз они соединяются в дереве Меркла. И в выход транзакции в качестве окончательного блокировщика включается корень Меркла.

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

Решение MAST улучшает Биткоин в трёх основных направлениях:

1) увеличивает гибкость смарт-контрактов
2) улучшает масштабируемость
3) повышает конфиденциальность.

Для более эффективной реализации решения, с ним поставляется Tapscript и Graftroot

#SmartContracts

Свежая статья про IoT и об угрозах таящихся в интернете вещей от компании Dr.Web.

Статистика конечно удручает😕
⬇️⬇️⬇️
https://habr.com/ru/company/drweb/blog/460433/

3 года назад, 20 июля 2016 года над проектом Ethereum был произведён хардфорк, чтобы отменить взлом и вернуть инвесторам средства, похищенные у The DAO.👀

Это было первое ответвление цепочки блоков с целью возвращения похищенных средств инвесторам.💰В результате неприятия частью сообщества отката истории транзакций и изменения правил образовался Ethereum Classic, который продолжает работать как проект «The DAO».

Если вы не в курсе, то вот вам парочка статеек о том, что произошло и как решали эту проблему
⬇️⬇️⬇️
Как хакеру удалось произвести взлом?
https://coinspot.io/analysis/razbiraya-ataku-na-thedao-obzor-koda/

Хронология событий!
https://forklog.com/zahvatyvayushhaya-istoriya-the-dao-rabota-nad-oshibkami/

Баян, но все же акутально)
Хорошего дня всем😄

​​Один доллар 💵

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

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

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

Дело было заведено. Мошеннику дали имя «Мистер 880» из-за номера его дела. В течение месяца в криминалистической лаборатории появилось еще 40 таких же купюр. К середине 1938 года их число выросло до 585. Проблема была в том, что Мистер 880 был неуловим. Большинство фальшивомонетчиков губила жадность, но Мистер 880 никогда не тратил деньги в одном и том же месте дважды. И никогда не тратил более 15 фальшивых долларов в неделю. Следователи повесили огромную карту Нью-Йорка в своем офисе, отмечая место, в котором всплывали подделки, красной кнопкой. И скоро весь Нью-Йорк пламенел. Детективы напечатали и раздали около 200 000 предупредительных листовок. Они проинструктировали более 10 000 магазинов. Все было напрасно.

Годы шли, а поиск Мистера 880 превратился в самое дорогое расследование подделок в истории Секретной службы. Его поймали только в 1948 году. Совершенно случайно. В доме был пожар и пожарные начали выбрасывать на улицу всякий хлам, который мог загореться. Там были и пробные клише, с которых печатали подделки.

Эмерих Юттнер оказался законопослушным гражданином. Он использовал свои фальшивые деньги только для покупки продуктов и предметов первой необходимости. Он никогда не обманывал ни одного продавца больше, чем на один доллар. Суд учел возраст преступника, незначительную сумму его подделок и приговорил Юттнера к штрафу в один доллар и тюремному заключению в один год и один день. Через четыре месяца Эмерих Юттнер вышел на свободу по УДО.

Юттнер стал легендой, и по мотивам его истории в 1950 году сняли фильм «Mister 880». Фильм принес ему больше денег, чем все его фальшивые доллары вместе взятые.

​​​​Пока возьмем паузу и отдохнем от биткоина и его проблем с масштабируемостью.😰

Начнем повесть о смарт-контрактах.

Часть 1. Введение в смарт-контракты для чайников
⬇️⬇️⬇️
Представим группу лиц, которая хочет установить некоторые правила и условия распределения ценностей, плюс ко всему и определенный механизм гарантированности выполнения этого распределения ценностей по заданным правилам и условиям.

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

Короче говоря, каждый из нас сталкивался с такой ситуацией рано или поздно.

А дальше суды, разбирательства и бла бла бла...

Смарт-контракт в помощь.

Коротко:

Терминология была придумана исследователем Nick Szabo. Это ученый в области информатики, криптографии, а также в области права, известный в связи с исследованиями в области умных контрактов и криптовалюты.

Он кстати есть в списке подозреваемых на причастность к личности Сатоши.

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

Из преимуществ я бы выделил:

1) Скорость🚀

Смарт- контракты предполагают автоматизированный процесс и в большинстве случаев не требуют личного участия.

2) Независимость🌐

Смарт-контракты исключают возможность вмешательства третьих сторон. Гарантия на транзакцию — сама программа, которая, в отличие от посредников, не даст основания сомневаться в ее целостности.

3) Надежность🔐

Если одна сторона сделки не выполняет свои обязательства, другая сторона будет защищена условиями интеллектуального договора.

4) Сбережения💰

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

В некотрых статьях можно увидеть пункт "отсутствие ошибок" но тут я поспорю и напишу отдельный пост об этом.

Пример смарт-контракта:

В простых контрактах действует логика «if-then-else», «when-do» — если… то…иначе.

Действие смарт-контракта поясняют на примере торгового автомата. Все просто.

Существуют и более сложные случаи:

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

1) До наступления определенного времени, на соответствующий аккаунт смарт-контракта должны поступить три платежа с определенных адресов на определенную сумму.

2) Если этого не происходит, смарт-контракт прекращает свое выполнение и возвращает монеты всем участникам.

3) Если же условие выполняется, тогда задаются значения идентификаторов арендодателя и медиатора, а также проверяется условие, что все участники согласны с выбором арендодателя и медиатора.

4) Когда все условия будут выполнены, средства будут переведены на указанные адреса.

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

Протокол — это набор правил и действий, согласно которым передаются данные. Например, HTTP и FTP — это протоколы.

Блокчейн Bitcoin является примером "общих протоколов" интернета (TCP/IP, http, SMTP и др.).

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

В отличие от оверлейных сетей интернета, где на вершине — данные и ими владеет FAANG (Facebook, Apple, Amazon, Netflix и Google, термин шведского экономиста Кьелла Нордстрема), на блокчейне, владение данными децентрализовано — возникает "общий слой данных" (shared data layer).

Через сам блокчейн Bitcoin проходит основная масса денег, тогда как в том же стеке интернета — наоборот, все деньги зарабатываются в слое приложений.

Протоколы интернета практически денег не приносят, поэтому Джоэль (работник инвестфонда Union Square Ventures), назвал их thin (тощими) protocols. Однако, с Bitcoin всё происходит с точностью до наоборот, значит, тут протоколы "тучные".

Заинтересовал?

Тогда, нууу прям очень занимательная статейка😉
⬇️⬇️⬇️
https://cryptor.net/kriptovalyuty/vlastelin-protokolov

✅✅✅
Продолжаем долбить смарт-контракты. Хочу сделать целую подборку постов на эту тему.☺️

Часть 1. Введение в смарт-контракты для чайников.
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/725

Часть 2. Недостатки смарт-контрактов и его составные части.
⬇️⬇️⬇️
Как и все вокруг, имеющее перспективы, смарт-контракты имеют свои недостатки.

1) Отсутствие регулирования.

Тут думаю и так понятно, разжевывать не стоит.

2) Отсутствие функциональной гибкости.

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

3) Затраты на разработку

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

4) Человеческий фактор

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

🌴🌴🌴

Сегодня крипторынок предлагает разработку смарт-контрактов для Ethereum, Hyperledger Fabric, Cardano, NEO и других блокчейн платформ. Кто не знал, но и существует разработка смарт-контрактов и для биткоина, но он не содержит маркеров состояний и не дает программистам свободу действий.

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

В 2014 году для записи кода смарт-контрактов Ethereum был спроектирован специальный язык программирования Solidity. Это один из четырех языков (среди Serpent, LLL и Mutan), спроектированных для трансляции в байт код виртуальной машины Ethereum.

Объем смарт-контракта определяется количеством строк с записями. Чем сложней условия, тем больше строк в программном коде. Готовый код смарт-контракта транслируется в байт-код виртуальной машины Ethereum, приводящей контракт в исполнение. По мере выполнения условий контракта компьютеры и узлы блокчейна обновляют регистр.

На примере организации первичного выпуска токенов приведу основные составляющие смарт-контракта

Структура основной части кода представляет собой иерархию контрактов, прописывающих тот или иной завершенный функциональный цикл, и состоит из ключевых элементов:

1) Owned

Контракт должен знать своего владельца и именно за это отвечает контракт «owned».

2) Crowdsale

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

- Общее количество токенов, выпущенных смарт-контрактом;

- Информация о балансах всех держателей токенов;

- Событие Transfer, которое должно испускаться смартконтрактом при каждой операции перемещения токенов между держателями токенов.

- Функция fallback отвечает за порядок действий в случае поступления эфиров на счет смарт-контракта. Она вызывается каждый раз, когда эфир поступает на адрес нашего смартконтракта.

3) EasyToken

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

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

В недалеком будущем😄

​​🌿🌿🌿
Стек приложений Blockchain

"Важная черта этого стека – он растет снизу вверх. Сначала появились майнеры, блокчейн и Bitcoin, а затем – все остальное. Насколько мне известно, важнейшие технологические революции развивались именно таким образом.

Таким образом, возникают очень интересные вызовы для разработчиков, предпринимателей и инвесторов: ведь этот стек адаптирует для широкого потребления очень перспективные вещи. Но, в конечном итоге, выигрывает пользователь, поскольку в таких приложениях действуют сниженные или нулевые входные взносы, издержки переключения невелики, все данные находятся в индивидуальном распоряжении, а рыночная мощность превосходит все ожидания."
⬇️⬇️⬇️
https://habr.com/ru/company/piter/blog/277625/

​​✅✅✅
Как и обещал, пишу про уязвимости и ошибки в истории существования смарт-контрактов. Этот блок я сделаю в нескольких подчастях. Так как интересной и полезной информации довольно много.

Полетели🚀

Часть 3.1. Уязвимости и ошибки в истории смарт-контрактов
⬇️⬇️⬇️
Вот какие ошибки считаются самыми популярными и значимыми в истории смарт-контрактов:

1) The DAO 1.0
2) FirePonzi
3) Казино с публичным RNG-сидом
4) Зависли 1100 ETH из-за нехватки газа
5) Игра The King of the Ether
6) 5800 ETH вывели из токенов ERC-20
7) Rubixi

Самыми крупными хищениями стали 30 миллионов долларов из Parity и 53 миллиона долларов из DAO.

Я постараюсь кратко, но в то же время подробно описать эти уязвимости.

Надеюсь я правильно смог все описать, так как не являюсь кодером. Если вдруг я не прав и допустил ошибку, пожалуйста, напишите мне об, чтобы я не вводил в заблуждение своих читателей. Я пытался максимально упростить и объяснить на простом языке.😉

Начну по порядку.

1) Про уязвимость в DAO.

Атаку назвали
- "Повторный вход, Reentrancy"
- Race-To-Empty
- Recursive call vulnerability, (рекурсивный вызов)
- Call to the unknown (призыв к неизвестному).

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

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

Все дело в функции "withdraw".

Функция «withdraw» имеет модификатор «onlyOwner», т.е. может быть вызвана только владельцем смартконтракта. Единственное, что она делает – переводит весь баланс смартконтракта на адрес владельца смартконтракта.

Почему назвали повторный вход?

Контракт жертвы выполняет функцию для отправки ETH во вредоносный контракт до обновления баланса вредоносного контракта.

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

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

Рекурсивный вызов удается выполнить только один раз; нужные нам балансы в итоге ставятся в 0, и на этом все заканчивается. Однако атакующий смог повторить эту операцию как минимум раз 50.

Если адрес является смарт-контрактом, платеж вызовет резервную функцию fallback () с тем, что осталось от транзакционного газа.

Таким образом, пользователь получит в два раза больше своего баланса из контракта.

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

Самое интересное, что баг в коде был не один. Именно совокупность этих багов и помогла хакеру украсть так много. Ошибка стала результатом плохого программирования, и вероятно типографской ошибки в коде.

Основные векторы атак на ICO👣

​​✅✅✅
Часть 3.1. Про уязвимость в DAO.
⬇️⬇️⬇️
https://tttttt.me/CryptoBotan/730

Часть 3.2. Критическая уязвимость в multisig кошельке Parity
⬇️⬇️⬇️

В 2017 году в кошельке Parity была найдена уязвимость, через использование которой было похищено порядка $30 миллионов. В результате взлома пострадали все пользователи, имевшие дело с кошельками с мультиподписью.

Интересно, что почти сразу после обнаружения взлома, группа энтузиастов, называющих себя The White Hat Group, воспользовалась тем же эксплоитом, чтобы спасти деньги пользователей, переведя их на неподверженный багу кошелек. Суммарно насчитывалось 596 уязвимых кошельков, и основной удар злоумышленников пришелся на три из них. Среди них был кошелек блокчейн-стартапа Aeternity.

Проблема возникла в результате ошибки в отдельном контракте с мультиподписью известном как wallet.sol.

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

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

Взломщик отправил в каждый пострадавший контракт:

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

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

Из-за устройства MultiSig-кошельков Parity, кошелек перенаправляет все вызовы на другой контракт — контракт библиотеки. В библиотеке и «реализована вся функциональность» контракта, что позволяет не писать отдельный код для каждого кошелька.

Метод initWallet, отвечающий за инициализацию (подготовку к использованию) кошелька, был общедоступен.

«Предполагается, что метод будет вызываться только один раз во время создания контракта кошелька. При заведении нового кошелька, транзакция отправляется в Ethereum, где написано "Заведи новый кошелек, который ссылается на эту библиотеку", и автоматически в момент создания контракта кошелька срабатывает функция initWallet в библиотеке, которая и назначает владельца этого кошелька»

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

Parity признали, что взлом стал возможен именно из-за этой ошибки в коде:

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

Дальше еще интереснее...

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

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

Было много предложений для разморозки средств. Вот ссылочка, кому интересно, что это были за предложения. А пока, средства все еще заморожены...Все работают над проблемой масштабируемости сети Ethereum.