Скамы с ботами и арбитражом
Вчера смотрел видео с канала Патрика Коллинса и одно из них сподвигло написать этот пост.
Уже несколько раз я и сам в чатах встречал сообщения о подобных разводах, и ко мне в личку писали разработчики проверить код бота, который они хотят использовать для некоторых манипуляций в сети. Но давайте чуть подробнее.
Вот само видео, если захотите его посмотреть:
https://youtu.be/xJaPrnI7LAA
В чем собственно проблема?
На Ютуб и в различных статьях в сети можно встретить огромное количество материала о том, как легко и просто зарабатывать $ 1000 - $ 10 000 в день на специальных блокчейн ботах, занимающихся арбитражом или флешзаймами. Там говорят, что "с помощью этого простого контракта вы можете делать нереальные деньги каждый день"! Многие из низ даже показывают на видео как выполняется транзакция и как увеличивается счет на кошельке.
Не ведитесь на это! Это 100% развод!
Конечно, есть люди, которые пишут своих ботов для таких операций, но код там настолько уникальный, что выкладывать его в открытый доступ чревато. Это настолько конкурентная среда, что каждый пользователь, по сути, борется со множеством других таких же пользователей за несколько сотен долларов. Если вы хотите также писать своих ботов, то нужно погружаться в сферу и прицельно изучать не только сам язык Solidity, но и работу Defi протоколов, MEV ботов, и финансовую часть.
При использовании готовых, предлагаемых в сети, контрактов, велик шанс, что при попытке выполнить любую операцию, у вас просто снимут деньги с кошелька. И вы их уже никаким образом не вернете!
Вообще, никогда и ни при каких условиях не используйте чужой код без понимания, что он делает. Даже на своем курсе у учеников было несколько заданий, в которых требовалось сделать комментарии к каждой строке кода в контракте. Вы четко должны понимать, что делает код и какой будет результат его выполнения.
Не ведитесь на легкие деньги с ботами и арбитражом! Не используйте чужие контракты бездумно!
Будьте аккуратны!
#scam
Вчера смотрел видео с канала Патрика Коллинса и одно из них сподвигло написать этот пост.
Уже несколько раз я и сам в чатах встречал сообщения о подобных разводах, и ко мне в личку писали разработчики проверить код бота, который они хотят использовать для некоторых манипуляций в сети. Но давайте чуть подробнее.
Вот само видео, если захотите его посмотреть:
https://youtu.be/xJaPrnI7LAA
В чем собственно проблема?
На Ютуб и в различных статьях в сети можно встретить огромное количество материала о том, как легко и просто зарабатывать $ 1000 - $ 10 000 в день на специальных блокчейн ботах, занимающихся арбитражом или флешзаймами. Там говорят, что "с помощью этого простого контракта вы можете делать нереальные деньги каждый день"! Многие из низ даже показывают на видео как выполняется транзакция и как увеличивается счет на кошельке.
Не ведитесь на это! Это 100% развод!
Конечно, есть люди, которые пишут своих ботов для таких операций, но код там настолько уникальный, что выкладывать его в открытый доступ чревато. Это настолько конкурентная среда, что каждый пользователь, по сути, борется со множеством других таких же пользователей за несколько сотен долларов. Если вы хотите также писать своих ботов, то нужно погружаться в сферу и прицельно изучать не только сам язык Solidity, но и работу Defi протоколов, MEV ботов, и финансовую часть.
При использовании готовых, предлагаемых в сети, контрактов, велик шанс, что при попытке выполнить любую операцию, у вас просто снимут деньги с кошелька. И вы их уже никаким образом не вернете!
Вообще, никогда и ни при каких условиях не используйте чужой код без понимания, что он делает. Даже на своем курсе у учеников было несколько заданий, в которых требовалось сделать комментарии к каждой строке кода в контракте. Вы четко должны понимать, что делает код и какой будет результат его выполнения.
Не ведитесь на легкие деньги с ботами и арбитражом! Не используйте чужие контракты бездумно!
Будьте аккуратны!
#scam
👍13👌2
Пара слов о современном аудите
Уже более полугода я веду отдельный канал, где каждый день публикую разборы уязвимостей по аудиторским отчетам с конкурсных платформ, типа code4rena, codehawks, sherlock и других. И хочу сказать пару слов тем, кто планирует начать свой путь в аудитах и конкурсах.
Не надейтесь на легкие деньги!
Это года два назад можно было получить пару сот долларов за то, что в контракте был использован transferFrom вместо safeTransferFrom и подобные популярные баги. Сейчас это уже прекрасно отлавливают статические анализаторы и боты. Посмотрите на один из лучших ботов сейчас - lightchaser. Он может отловить более 700 популярных багов! Это значит, что как минимум это количество просто уйдет в "невалид" при аудите.
Я бы разбил поиск багов на несколько уровней:
1. Проход ботами и детекторами. Базовая вещь, которая находит мелкие и средние недочеты.
2. Аудит на внимательность. Аудитор проходит код и ищет простые несовпадения по контрактам. Это может быть не правильные хеширования функций для подписи, несоответствия стандартам и другие мелкие ошибки, который бот не сможет найти.
3. Аудит на "нишевые" места. Тут помогает знание других протоколов и их работы. Например, вы прекрасно знаете как работает Uniswap V3: тики, twap, дельта - и можете найти в аудируемом протоколе места, где есть ошибки в коде.
4. Аудит с пониманием кода. Место откуда начинается настоящий аудит. Для того, что понимать код потребуется потрать некоторое время. И я говорю не просто о том, "как работает эта функция", а о том, что вообще происходит внутри нее.
Так, обычный transfer() можно понимать, как перевод токенов с одного адреса на другой. Но аудитор должен учитывать многие другие параметры: как изменятся балансы пользователей, totalSupply, награды, комиссии, изменения в других переменных состояния и многое другое. И чем сложнее функция, тем больше времени уйдет на ее разбор.
5. Аудит с деталями и математикой. Тут аудитор должен понимать не только, что делает код, но и то, что он делать не должен, или что он вообще не делает. Это то место, когда аудитор буквально занимает место разработчика и говорит ему, почему код работает не верно.
2 и 3 пункты этого списка можно усвоить и регулярно практиковать на любых конкурсных аудитах, выделяя по 5-6 часов. Помогут тут и чтение отчетов, и разборы багов, и простое внимание в код. Но и заработок тут будет никакой: 20-30 долларов в лучшем случае за весь конкурс.
На 4 пункт нужно будет потратить достаточно количество времени, более 20-30 часов. В итоге, можно будет заработать пару сотен.
На 5 пункт вы затратите максимум времени: возможно, весь период конкурса. И только тут сможете получить достаточную прибыль.
Аудит - это полноценная работа. Та работа, которая будет занимать у вас 8-9 часов каждый день.
Это уже не легкие деньги, и на курсах этому не научат. Только практика и вникание в код.
Да, изучение отчетов очень помогает, так как ты начинаешь понимать, куда смотреть в код и где могут быть слабые места. Но чтобы подтвердить свои догадки, нужно тратить время на понимание работы функции.
Аудиторы хорошо получают. Но они и времени отдают в профессию очень много.
#audit
Уже более полугода я веду отдельный канал, где каждый день публикую разборы уязвимостей по аудиторским отчетам с конкурсных платформ, типа code4rena, codehawks, sherlock и других. И хочу сказать пару слов тем, кто планирует начать свой путь в аудитах и конкурсах.
Не надейтесь на легкие деньги!
Это года два назад можно было получить пару сот долларов за то, что в контракте был использован transferFrom вместо safeTransferFrom и подобные популярные баги. Сейчас это уже прекрасно отлавливают статические анализаторы и боты. Посмотрите на один из лучших ботов сейчас - lightchaser. Он может отловить более 700 популярных багов! Это значит, что как минимум это количество просто уйдет в "невалид" при аудите.
Я бы разбил поиск багов на несколько уровней:
1. Проход ботами и детекторами. Базовая вещь, которая находит мелкие и средние недочеты.
2. Аудит на внимательность. Аудитор проходит код и ищет простые несовпадения по контрактам. Это может быть не правильные хеширования функций для подписи, несоответствия стандартам и другие мелкие ошибки, который бот не сможет найти.
3. Аудит на "нишевые" места. Тут помогает знание других протоколов и их работы. Например, вы прекрасно знаете как работает Uniswap V3: тики, twap, дельта - и можете найти в аудируемом протоколе места, где есть ошибки в коде.
4. Аудит с пониманием кода. Место откуда начинается настоящий аудит. Для того, что понимать код потребуется потрать некоторое время. И я говорю не просто о том, "как работает эта функция", а о том, что вообще происходит внутри нее.
Так, обычный transfer() можно понимать, как перевод токенов с одного адреса на другой. Но аудитор должен учитывать многие другие параметры: как изменятся балансы пользователей, totalSupply, награды, комиссии, изменения в других переменных состояния и многое другое. И чем сложнее функция, тем больше времени уйдет на ее разбор.
5. Аудит с деталями и математикой. Тут аудитор должен понимать не только, что делает код, но и то, что он делать не должен, или что он вообще не делает. Это то место, когда аудитор буквально занимает место разработчика и говорит ему, почему код работает не верно.
2 и 3 пункты этого списка можно усвоить и регулярно практиковать на любых конкурсных аудитах, выделяя по 5-6 часов. Помогут тут и чтение отчетов, и разборы багов, и простое внимание в код. Но и заработок тут будет никакой: 20-30 долларов в лучшем случае за весь конкурс.
На 4 пункт нужно будет потратить достаточно количество времени, более 20-30 часов. В итоге, можно будет заработать пару сотен.
На 5 пункт вы затратите максимум времени: возможно, весь период конкурса. И только тут сможете получить достаточную прибыль.
Аудит - это полноценная работа. Та работа, которая будет занимать у вас 8-9 часов каждый день.
Это уже не легкие деньги, и на курсах этому не научат. Только практика и вникание в код.
Да, изучение отчетов очень помогает, так как ты начинаешь понимать, куда смотреть в код и где могут быть слабые места. Но чтобы подтвердить свои догадки, нужно тратить время на понимание работы функции.
Аудиторы хорошо получают. Но они и времени отдают в профессию очень много.
#audit
🤔7👍3❤1🔥1
Подведение итогов этого лета
Вот и лето прошло, словно и не бывало...
Да, я в курсе, что последний день лета завтра, но на канале это последний летный пост, поэтому самое время подвести небольшие итоги.
Этот сезон выдался очень активным, как на ведение каналов, так и на запуск курса, так и в жизни вне web3. Очень радуюсь тому, что получилось съездить на море в самом начале лета, без этого короткого отдыха было бы еще сложнее вывозить всю нагрузку.
Жалею о том, что из-за работы с соцсетями, курсом и над собственным проектом, у меня не получилось погрузиться в конкурсные аудиты. Если и заходил в какой-нибудь конкурс, то уделять получалось всего 5-6 часов, а это вообще ничто. Когда теперь к ним вернусь в полную силу вообще не знаю... Осень планируется также крайне нагруженной.
Думаю также, на следующей неделе взять небольшой недельный отпуск. Хочу ни о чем не думать и поиграть в какую-нибудь новую игру, та же Обезьяна выглядит интересной.
А пока, вот содержание летних постов, на случай, если вы что-то пропустили или просто захотите перечитать:
Какие проекты написать для портфолио?
Токен написать и косточкой не подавиться
Небольшой роадмап для начинающих
Контракты и паттерны
Пара слов о современном аудите
Разбираем темы по Solidity
Solidity hints. Часть 1. Работа falkback()
Solidity hints. Часть 2. Send() return value
Solidity hints. Часть 3. Low-level functions
Solidity hints. Часть 4. Delegatecall
Solidity hints. Часть 5. Enum types
Solidity hints. Часть 6. Function existence check
Solidity hints. Часть 7. Extcodesize
Solidity hints. Часть 7. Selfdestruct
Solidity hints. Часть 8. Precompile
Solidity hints. Часть 9. Overflow
Solidity hints. Часть 10. Call & Delegatecall
Solidity hints. Часть 11. Creationcode
Solidity hints. Часть 12. Constructor
Solidity hints. Часть 13. Array
Solidity hints. Часть 14. Payable modifier
Solidity hints. Часть 15. Modifiers
Solidity hints. Часть 16. Immutable / Constant
Solidity hints. Часть 17. Free functions
Solidity hints. Часть 18. Library & storage
Solidity hints. Часть 19. Assembly, pure functions
Solidity hints. Часть 20. Fallback output
Solidity hints. Часть 21. Function overloading
Большой цикл постов по Account Abstraction
Account abstraction (ERC-4337). Часть 1 - 20
Всем приятного отдыха и легкого обучения!
#summer
Вот и лето прошло, словно и не бывало...
Да, я в курсе, что последний день лета завтра, но на канале это последний летный пост, поэтому самое время подвести небольшие итоги.
Этот сезон выдался очень активным, как на ведение каналов, так и на запуск курса, так и в жизни вне web3. Очень радуюсь тому, что получилось съездить на море в самом начале лета, без этого короткого отдыха было бы еще сложнее вывозить всю нагрузку.
Жалею о том, что из-за работы с соцсетями, курсом и над собственным проектом, у меня не получилось погрузиться в конкурсные аудиты. Если и заходил в какой-нибудь конкурс, то уделять получалось всего 5-6 часов, а это вообще ничто. Когда теперь к ним вернусь в полную силу вообще не знаю... Осень планируется также крайне нагруженной.
Думаю также, на следующей неделе взять небольшой недельный отпуск. Хочу ни о чем не думать и поиграть в какую-нибудь новую игру, та же Обезьяна выглядит интересной.
А пока, вот содержание летних постов, на случай, если вы что-то пропустили или просто захотите перечитать:
Какие проекты написать для портфолио?
Токен написать и косточкой не подавиться
Небольшой роадмап для начинающих
Контракты и паттерны
Пара слов о современном аудите
Разбираем темы по Solidity
Solidity hints. Часть 1. Работа falkback()
Solidity hints. Часть 2. Send() return value
Solidity hints. Часть 3. Low-level functions
Solidity hints. Часть 4. Delegatecall
Solidity hints. Часть 5. Enum types
Solidity hints. Часть 6. Function existence check
Solidity hints. Часть 7. Extcodesize
Solidity hints. Часть 7. Selfdestruct
Solidity hints. Часть 8. Precompile
Solidity hints. Часть 9. Overflow
Solidity hints. Часть 10. Call & Delegatecall
Solidity hints. Часть 11. Creationcode
Solidity hints. Часть 12. Constructor
Solidity hints. Часть 13. Array
Solidity hints. Часть 14. Payable modifier
Solidity hints. Часть 15. Modifiers
Solidity hints. Часть 16. Immutable / Constant
Solidity hints. Часть 17. Free functions
Solidity hints. Часть 18. Library & storage
Solidity hints. Часть 19. Assembly, pure functions
Solidity hints. Часть 20. Fallback output
Solidity hints. Часть 21. Function overloading
Большой цикл постов по Account Abstraction
Account abstraction (ERC-4337). Часть 1 - 20
Всем приятного отдыха и легкого обучения!
#summer
3🔥14❤4👍2
Первый донат и 2000 участников
Только увидел, что кто-то поставил лайк-звездочку, это мой самый первый донат вообще) очень приятно) спасибо, кто бы ты не был)
А еще, на канале теперь 2000+ участников! Если не ошибаюсь, мы теперь самый большой канал (не чат) посвященный Solidity в ру сегменте! Это очень здорово!
Всем спасибо за доверие!
#thanks
Только увидел, что кто-то поставил лайк-звездочку, это мой самый первый донат вообще) очень приятно) спасибо, кто бы ты не был)
А еще, на канале теперь 2000+ участников! Если не ошибаюсь, мы теперь самый большой канал (не чат) посвященный Solidity в ру сегменте! Это очень здорово!
Всем спасибо за доверие!
#thanks
20❤27❤🔥7👍3
Solidity hints. Часть 22
Новая рабочая неделя, старт школьного сезона, а у меня небольшой отпуск. Просто хочу немного отдохнуть от контента, постоянной гонки со своим проектом и аудитами, поэтому чуть реже на неделе будут выходить посты.
Однако сегодня мы разберем сразу 3 пункта с репо Chinmaya! Два из них очень похожи, и один является продолжение другого. Звучать они как:
33. Events are inheritable. The Log and its event data is not accessible from within contracts (not even from the contract that created them.
34. it is possible to “fake” the signature (topic0) of another event using an anonymous event
35. Errors are inheritable. the revert data of inner calls is propagated back through the chain of external calls by default. Low-level calls do not throw an exception.
что в переводе:
33. События наследуются. Журнал и его данные о событиях недоступны изнутри контрактов (даже из контракта, который их создал).
34. можно «подделать» подпись (topic0) другого события, используя анонимное событие
35. Ошибки наследуются. Данные о возврате внутренних вызовов по умолчанию передаются обратно по цепочке внешних вызовов. Низкоуровневые вызовы не выбрасывают исключение.
Если мы уже немного знаем о Solidity, то уже должны понимать систему наследований. Банальный пример:
В этом контракте мы создаем токен с наследованием функционала от ERC20. В своих функциях мы можем использовать события, которые были установлены в ERC20 - Transfer и Approval. Если бы там были созданы error, то мы бы могли использовать и их в своем контракте токена.
Если мы говорим об ошибках (error) в контракте, то данные об них должны использоваться только для индикации сбоя, но не как средство управления потоком вызовов между контрактами. Причина в том, что данные о возврате внутренних вызовов по умолчанию распространяются обратно по цепочке внешних вызовов. Это означает, что внутренний вызов может «подделать» данные о return value, которые будут выглядеть так, как будто они могли прийти от вызвавшего его контракта.
Другими словами, если мы делаем вызов из контракта А в контракт В, который в свою очередь вызывает еще несколько контрактов, то вполне может возникнуть ситуация, что контракт В нарочно или нет, имеет такие же ошибки как другие контракты и возвращает информацию, что это в нем был сбой, а не в контрактах ниже.
На практике у меня такое никогда не встречалось, но возможность все таки есть.
С событиями (event) дела также обстоят интересно.
На уровне EVM нет такого понятия как Solidity events. Там есть всего 4 функции записи лога - LOG0, LOG1, LOG2, LOG3 и LOG4. Каждая функция LOG «регистрирует» некоторое количество байтов данных, индексированных от 0 до 4 bytes32 «topic» (те самые поля idexed в событиях). Когда вы создаете «событие» в Solidity, неиндексированные аргументы события кодируются через ABI в байты и передаются как аргумент данных в LOG, а индексированные события передаются как темы.
Однако Solidity также вставляет «подпись события», хэшированную, как дополнительную (первую) тему (чтобы было легко искать все события, например, ERC-20 Transfer(address,uint256,uint256)). Это происходит, если событие не помечено как анонимное, в противном случае он ничего не вставляет.
Таким образом, вывод следующих двух emit на блокчейн неразличим:
Новая рабочая неделя, старт школьного сезона, а у меня небольшой отпуск. Просто хочу немного отдохнуть от контента, постоянной гонки со своим проектом и аудитами, поэтому чуть реже на неделе будут выходить посты.
Однако сегодня мы разберем сразу 3 пункта с репо Chinmaya! Два из них очень похожи, и один является продолжение другого. Звучать они как:
33. Events are inheritable. The Log and its event data is not accessible from within contracts (not even from the contract that created them.
34. it is possible to “fake” the signature (topic0) of another event using an anonymous event
35. Errors are inheritable. the revert data of inner calls is propagated back through the chain of external calls by default. Low-level calls do not throw an exception.
что в переводе:
33. События наследуются. Журнал и его данные о событиях недоступны изнутри контрактов (даже из контракта, который их создал).
34. можно «подделать» подпись (topic0) другого события, используя анонимное событие
35. Ошибки наследуются. Данные о возврате внутренних вызовов по умолчанию передаются обратно по цепочке внешних вызовов. Низкоуровневые вызовы не выбрасывают исключение.
Если мы уже немного знаем о Solidity, то уже должны понимать систему наследований. Банальный пример:
// SPDX-License-Identifier: MIT
// Compatible with OpenZeppelin Contracts ^5.0.0
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
contract MyToken is ERC20 {
constructor() ERC20("MyToken", "MTK") {}
}
В этом контракте мы создаем токен с наследованием функционала от ERC20. В своих функциях мы можем использовать события, которые были установлены в ERC20 - Transfer и Approval. Если бы там были созданы error, то мы бы могли использовать и их в своем контракте токена.
Если мы говорим об ошибках (error) в контракте, то данные об них должны использоваться только для индикации сбоя, но не как средство управления потоком вызовов между контрактами. Причина в том, что данные о возврате внутренних вызовов по умолчанию распространяются обратно по цепочке внешних вызовов. Это означает, что внутренний вызов может «подделать» данные о return value, которые будут выглядеть так, как будто они могли прийти от вызвавшего его контракта.
Другими словами, если мы делаем вызов из контракта А в контракт В, который в свою очередь вызывает еще несколько контрактов, то вполне может возникнуть ситуация, что контракт В нарочно или нет, имеет такие же ошибки как другие контракты и возвращает информацию, что это в нем был сбой, а не в контрактах ниже.
На практике у меня такое никогда не встречалось, но возможность все таки есть.
С событиями (event) дела также обстоят интересно.
На уровне EVM нет такого понятия как Solidity events. Там есть всего 4 функции записи лога - LOG0, LOG1, LOG2, LOG3 и LOG4. Каждая функция LOG «регистрирует» некоторое количество байтов данных, индексированных от 0 до 4 bytes32 «topic» (те самые поля idexed в событиях). Когда вы создаете «событие» в Solidity, неиндексированные аргументы события кодируются через ABI в байты и передаются как аргумент данных в LOG, а индексированные события передаются как темы.
Однако Solidity также вставляет «подпись события», хэшированную, как дополнительную (первую) тему (чтобы было легко искать все события, например, ERC-20 Transfer(address,uint256,uint256)). Это происходит, если событие не помечено как анонимное, в противном случае он ничего не вставляет.
Таким образом, вывод следующих двух emit на блокчейн неразличим:
pragma solidity 0.8.20;
contract Test {
event Value(uint256 value);
event NameDoesntMatter(bytes32 indexed topic0, uint256 value) anonymous;
function test() external {
emit Value(123);
emit NameDoesntMatter(keccak256(bytes("Value(uint256)")), 123);
}
}
Сами события могут быть определены на уровне файлов или как наследуемые части контрактов, включая интерфейсы и библиотеки. При их вызове аргументы сохраняются в журнале транзакции - специальной структуре данных в блокчейне. Эти журналы ассоциируются с адресом контракта, который их вызвал, включаются в блокчейн и остаются там до тех пор, пока блокчейн доступен. Журнал и его данные о событиях недоступны изнутри контрактов (даже из контракта, который их создал).
P.S. Есть вероятность, что в одной из последних версий Solidity (или в ближайших) есть способ читать события из контракта. Я встречал упоминания об этом, только не смог найти источник.
#events #errors
P.S. Есть вероятность, что в одной из последних версий Solidity (или в ближайших) есть способ читать события из контракта. Я встречал упоминания об этом, только не смог найти источник.
#events #errors
Небольшая лекция на тему подготовки протокола к аудиту?
Давно хотел попробовать для себя формат стрим-лекций на тему безопасности и аудита смарт контрактов: делать подборки современных багов и уязвимостей, разбирать нюансы передачи сообщений через мост, правильно подключать сторонние оракулы и протоколы и т.д. Но все как-то не доходили руки и не было свободного времени...
На днях меня смотивировали вернуться к этой идее, и я хотел бы попробовать провести первый стрим-лекцию для участников канала.
Для начала выбрал тему "Подготовка протокола к аудиту", где постараюсь рассказать, как разработчики могут помочь аудитору провести максимально эффективную проверку безопасности проекта: на что обратить внимание, как писать комментарии, зачем нужен АИ и статические анализаторы, как выбрать аудитора и т.д.
Уже около двух лет я периодически захожу на конкурсные аудиты, провел несколько соло-аудитов и просмотрел несколько десятков протоколов и документации, поэтому с уверенностью смогу подсказать, как сделать все в лучшем виде.
P.S. Точно знаю, что не будет лекций о том, как именно проводить аудит и участвовать в конкурсах. Я хоть уже долго занимаюсь этой темой, но не считаю себя топовым аудитором, да и большие призовые пока не получал. Лучше будет пригласить кого-нибудь более опытного аудитора для участия в лекции.
Для меня самого это будет скорее проверкой идеи: как все будет проходить с технической стороны, насколько мне будет комфортен видео формат, много ли сил и времени займет подготовка. Если все пройдет как надо, мы могли бы устраивать такие стримы раз-два в месяц.
В общем, это пока просто "идея на пробу", а там как пойдет.
Первый стрим хочу провести на следующей неделе, скорее всего, в конце.
А так, какие темы в области безопасности и аудита вам были бы интересны?
#video
Давно хотел попробовать для себя формат стрим-лекций на тему безопасности и аудита смарт контрактов: делать подборки современных багов и уязвимостей, разбирать нюансы передачи сообщений через мост, правильно подключать сторонние оракулы и протоколы и т.д. Но все как-то не доходили руки и не было свободного времени...
На днях меня смотивировали вернуться к этой идее, и я хотел бы попробовать провести первый стрим-лекцию для участников канала.
Для начала выбрал тему "Подготовка протокола к аудиту", где постараюсь рассказать, как разработчики могут помочь аудитору провести максимально эффективную проверку безопасности проекта: на что обратить внимание, как писать комментарии, зачем нужен АИ и статические анализаторы, как выбрать аудитора и т.д.
Уже около двух лет я периодически захожу на конкурсные аудиты, провел несколько соло-аудитов и просмотрел несколько десятков протоколов и документации, поэтому с уверенностью смогу подсказать, как сделать все в лучшем виде.
P.S. Точно знаю, что не будет лекций о том, как именно проводить аудит и участвовать в конкурсах. Я хоть уже долго занимаюсь этой темой, но не считаю себя топовым аудитором, да и большие призовые пока не получал. Лучше будет пригласить кого-нибудь более опытного аудитора для участия в лекции.
Для меня самого это будет скорее проверкой идеи: как все будет проходить с технической стороны, насколько мне будет комфортен видео формат, много ли сил и времени займет подготовка. Если все пройдет как надо, мы могли бы устраивать такие стримы раз-два в месяц.
В общем, это пока просто "идея на пробу", а там как пойдет.
Первый стрим хочу провести на следующей неделе, скорее всего, в конце.
А так, какие темы в области безопасности и аудита вам были бы интересны?
#video
🔥14
Solidity hints. Часть 23
Наш первый стрим по теме подготовки протокола к аудиту я планирую провести примерно в следующий четверг в 19:00. Встреча будет либо тут в Телеграмме, либо в Зуме. Еще проверю, где будет удобнее демонстрировать экран для презентаций. Запись не знаю будет или нет, так как не сильно пока уверен в своих способностях спикера.
Ну, а пока что, еще несколько пунктов из репо для общего понимания Solidity. Они, в целом, и так самодостаточно понятны, но мы идем по порядку, поэтому говорим о каждом. Итак:
36. When a contract inherits from other contracts, only a single contract is created on the blockchain, and the code from all the base contracts is compiled into the created contract. This means that all internal calls to functions of base contracts also just use internal function calls (super.f(..) will use JUMP and not a message call
что в переводе:
Когда контракт наследуется от других контрактов, на блокчейне создается только один контракт, а код всех базовых контрактов компилируется в созданный контракт. Это означает, что все внутренние вызовы функций базовых контрактов также используют только внутренние вызовы функций (super.f(...) будет использовать JUMP, а не вызов сообщения
Тут и так все понятно, но дам несколько комментариев.
Solidity поддерживает множественное наследование, включая полиморфизм.
Полиморфизм означает, что вызов функции (внутренней и внешней) всегда выполняет одноименную функцию (и типы параметров) в наиболее ближайшем контракте в иерархии наследования. Это должно быть явно разрешено для каждой функции в иерархии с помощью ключевых слов virtual и override.
Можно вызывать функции дальше по иерархии наследования, явно указывая контракт с помощью ContractName.functionName() или с помощью super.functionName(), если вы хотите вызвать функцию на один уровень выше в сглаженной иерархии наследования.
Грубо говоря, при наличии internal функций в наследуемых нашим контрактов всех остальных, вызовы между ними будут идти с помощью опкода JUMP, и не будут считаться вызовами в другой контракт, где используются такие опкоды как CALL или, скажем, STATICCALL.
Идем далее:
37. The overriding function may only change the visibility of the overridden function from external to public .The mutability may be changed to a more strict one following the order: nonpayablecan be overridden by viewand pure. viewcan be overridden by pure. payableis an exception and cannot be changed to any other mutability
и перевод:
Переопределяющая функция может только изменить видимость переопределяемой функции с external на public. Мутабельность может быть изменена на более строгую в следующем порядке: nonpayable может быть переопределена view и pure. view может быть переопределена pure. payable является исключением и не может быть изменена на любую другую мутабельность
Тут также все просто. Если мы наследуем от контракта, где есть virtual / override функции, которые мы хотим переписать в своем контракте, то сделать это можем только в более "строгую" сторону.
Таким образом мы не сможем переписать функцию, помеченную как view в public или external.
На самом деле, такое крайне редко когда требуется, да и компилятор будет подсвечивать вам проблемное место.
#override #inherit
Наш первый стрим по теме подготовки протокола к аудиту я планирую провести примерно в следующий четверг в 19:00. Встреча будет либо тут в Телеграмме, либо в Зуме. Еще проверю, где будет удобнее демонстрировать экран для презентаций. Запись не знаю будет или нет, так как не сильно пока уверен в своих способностях спикера.
Ну, а пока что, еще несколько пунктов из репо для общего понимания Solidity. Они, в целом, и так самодостаточно понятны, но мы идем по порядку, поэтому говорим о каждом. Итак:
36. When a contract inherits from other contracts, only a single contract is created on the blockchain, and the code from all the base contracts is compiled into the created contract. This means that all internal calls to functions of base contracts also just use internal function calls (super.f(..) will use JUMP and not a message call
что в переводе:
Когда контракт наследуется от других контрактов, на блокчейне создается только один контракт, а код всех базовых контрактов компилируется в созданный контракт. Это означает, что все внутренние вызовы функций базовых контрактов также используют только внутренние вызовы функций (super.f(...) будет использовать JUMP, а не вызов сообщения
Тут и так все понятно, но дам несколько комментариев.
Solidity поддерживает множественное наследование, включая полиморфизм.
Полиморфизм означает, что вызов функции (внутренней и внешней) всегда выполняет одноименную функцию (и типы параметров) в наиболее ближайшем контракте в иерархии наследования. Это должно быть явно разрешено для каждой функции в иерархии с помощью ключевых слов virtual и override.
Можно вызывать функции дальше по иерархии наследования, явно указывая контракт с помощью ContractName.functionName() или с помощью super.functionName(), если вы хотите вызвать функцию на один уровень выше в сглаженной иерархии наследования.
Грубо говоря, при наличии internal функций в наследуемых нашим контрактов всех остальных, вызовы между ними будут идти с помощью опкода JUMP, и не будут считаться вызовами в другой контракт, где используются такие опкоды как CALL или, скажем, STATICCALL.
Идем далее:
37. The overriding function may only change the visibility of the overridden function from external to public .The mutability may be changed to a more strict one following the order: nonpayablecan be overridden by viewand pure. viewcan be overridden by pure. payableis an exception and cannot be changed to any other mutability
и перевод:
Переопределяющая функция может только изменить видимость переопределяемой функции с external на public. Мутабельность может быть изменена на более строгую в следующем порядке: nonpayable может быть переопределена view и pure. view может быть переопределена pure. payable является исключением и не может быть изменена на любую другую мутабельность
Тут также все просто. Если мы наследуем от контракта, где есть virtual / override функции, которые мы хотим переписать в своем контракте, то сделать это можем только в более "строгую" сторону.
Таким образом мы не сможем переписать функцию, помеченную как view в public или external.
На самом деле, такое крайне редко когда требуется, да и компилятор будет подсвечивать вам проблемное место.
#override #inherit
🔥2❤1👍1
Проблема с продвижением проектов?
Пока занимался презентацией на грядущий стрим, дошел до раздела с рекомендациями, как можно использовать процесс аудита вашего dApp в маркетинге и рекламе. Полез в интернет за новыми и идеями, и немного обломался...
Несколько лет назад я сильно увлекался темой стартапов по всему миру: отслеживал инвестиции, разработки, приложения и сервисы, часами сидел на Product Hunt, читал литературу и т.д. И неизменно на пути каждого проекта вставал вопрос его продвижения и рекламы. Кому нужен ваш сногсшибательный проект, когда о нем никто не знает?..
99% всех советов и статей сводилось к паре идеи: ведите сети, прокачайте SEO, закупите рекламу в гугле или других соцсетях. При этом, в тех же 99% случаев это не будет работать.
Представьте себе, мы создали проект, завели для него сайт и соцсети, и хотим рекламироваться. Что у нас получится?
SEO настройка будет работать по релевантным запросам - т.е. если у нас на сайте будет информация по ключевым словам, которые будут искать пользователи. Но вместе с этим мы будем бороться с другими конкурентными сайтами в этом поле. Короче говоря, SEO начнет работать минимум через полгода-год, если у нас все будет настроено супер-правильно. А на каких страницах выдачи? Тут еще тоже очень спорный вопрос...
SEO делать надо, на полагаться на него, как на основной источник пользователей вообще не стоит.
Реклама в поисковых системах, типа Гугла, и в соцсетях работает. Но для регулярной отдачи нужно просчитывать множество параметров: ключевые и игнор слова, конверсии, трафик и т.д. При этом вы тратите уже свои деньги.
С ведением соцсетей вообще ахтунг! Мало того, что делать это надо регулярно, так еще нужно делать это правильно и, что самое главное, интересно и понятно. Да и форматы в них сильно отличаются по характеру и техническим параметрам: в Телеграме - какие-нибудь новостные и экспертные посты, в Инстаграме - сторител и лайфстаил, в Твиттере - короткие текстовые с основной идеей, на Реддит - приближенные к обычным людям... И невозможно один текст переложить одинаково хорошо на разные платформы, сохранив качество.
И получается, что чаще всего мы получаем "голые" соц страницы, слитый бюджет на рекламу и долгие результаты в SEO. И ни дай Бог вы пойдете спамить о своем проекте в чаты других груп или сообществ, это вообще поставит крест на любом продвижении.
И абсолютно также ситуация сейчас в web3.
Ребята создают крутой проект, просят оценить людей в своих группах и сообществах, получают позитивный фидбек, но не пользователей своего протокола. Разработчики пилят свои проекты, им не интересно (чаще всего) использовать сторонний. Отсюда и появляется кладбище пет проектов...
Мне интересно узнать, какие способы продвижения своего протокола вы пробовали? Что получалось и что не особо?
Возможно, мы могли бы прийти к каким-то общим рекомендациям для всех участников канала.
Всем хорошей недели!
#marketing
Пока занимался презентацией на грядущий стрим, дошел до раздела с рекомендациями, как можно использовать процесс аудита вашего dApp в маркетинге и рекламе. Полез в интернет за новыми и идеями, и немного обломался...
Несколько лет назад я сильно увлекался темой стартапов по всему миру: отслеживал инвестиции, разработки, приложения и сервисы, часами сидел на Product Hunt, читал литературу и т.д. И неизменно на пути каждого проекта вставал вопрос его продвижения и рекламы. Кому нужен ваш сногсшибательный проект, когда о нем никто не знает?..
99% всех советов и статей сводилось к паре идеи: ведите сети, прокачайте SEO, закупите рекламу в гугле или других соцсетях. При этом, в тех же 99% случаев это не будет работать.
Представьте себе, мы создали проект, завели для него сайт и соцсети, и хотим рекламироваться. Что у нас получится?
SEO настройка будет работать по релевантным запросам - т.е. если у нас на сайте будет информация по ключевым словам, которые будут искать пользователи. Но вместе с этим мы будем бороться с другими конкурентными сайтами в этом поле. Короче говоря, SEO начнет работать минимум через полгода-год, если у нас все будет настроено супер-правильно. А на каких страницах выдачи? Тут еще тоже очень спорный вопрос...
SEO делать надо, на полагаться на него, как на основной источник пользователей вообще не стоит.
Реклама в поисковых системах, типа Гугла, и в соцсетях работает. Но для регулярной отдачи нужно просчитывать множество параметров: ключевые и игнор слова, конверсии, трафик и т.д. При этом вы тратите уже свои деньги.
С ведением соцсетей вообще ахтунг! Мало того, что делать это надо регулярно, так еще нужно делать это правильно и, что самое главное, интересно и понятно. Да и форматы в них сильно отличаются по характеру и техническим параметрам: в Телеграме - какие-нибудь новостные и экспертные посты, в Инстаграме - сторител и лайфстаил, в Твиттере - короткие текстовые с основной идеей, на Реддит - приближенные к обычным людям... И невозможно один текст переложить одинаково хорошо на разные платформы, сохранив качество.
И получается, что чаще всего мы получаем "голые" соц страницы, слитый бюджет на рекламу и долгие результаты в SEO. И ни дай Бог вы пойдете спамить о своем проекте в чаты других груп или сообществ, это вообще поставит крест на любом продвижении.
И абсолютно также ситуация сейчас в web3.
Ребята создают крутой проект, просят оценить людей в своих группах и сообществах, получают позитивный фидбек, но не пользователей своего протокола. Разработчики пилят свои проекты, им не интересно (чаще всего) использовать сторонний. Отсюда и появляется кладбище пет проектов...
Мне интересно узнать, какие способы продвижения своего протокола вы пробовали? Что получалось и что не особо?
Возможно, мы могли бы прийти к каким-то общим рекомендациям для всех участников канала.
Всем хорошей недели!
#marketing
👍4🤔3❤1
Стрим на тему "Подготовка протокола к аудиту"
Официальное объявление о первом видео стриме на нашем канале. В этот четверг в 19:00 по московскому времени в Зуме будет небольшая, примерно на полчаса-час, встреча, где я расскажу вам о том, как правильно подготовить свой протокол к аудиту: соло, в компании, на конкурсной площадке и т.д.
Мы поговорим зачем вообще нужен аудит, о комментариях к коду, диаграммах, статических анализаторах, самопроверке и ее техниках, об общей документации к протоколу и многом другом.
Не могу сказать с уверенностью, что запись стрима будет, так как это мой самый первый стрим и многое может пойти не так, как планируется. Я вообще пишу гораздо лучше, чем говорю (по сути, потому я и веду канал в Телеграме, а не видео на Ютуб).
Стрим открытый для всех, ссылка будет опубликована позже перед самым стримом.
Итак:
Тема: "Подготовка протокола к аудиту"
Продолжительность: 30-60 минут
Дата: четверг, 12.09.2024
Время: 19:00 мск
Где: zoom
Приглашаю всех!
#video
Официальное объявление о первом видео стриме на нашем канале. В этот четверг в 19:00 по московскому времени в Зуме будет небольшая, примерно на полчаса-час, встреча, где я расскажу вам о том, как правильно подготовить свой протокол к аудиту: соло, в компании, на конкурсной площадке и т.д.
Мы поговорим зачем вообще нужен аудит, о комментариях к коду, диаграммах, статических анализаторах, самопроверке и ее техниках, об общей документации к протоколу и многом другом.
Не могу сказать с уверенностью, что запись стрима будет, так как это мой самый первый стрим и многое может пойти не так, как планируется. Я вообще пишу гораздо лучше, чем говорю (по сути, потому я и веду канал в Телеграме, а не видео на Ютуб).
Стрим открытый для всех, ссылка будет опубликована позже перед самым стримом.
Итак:
Тема: "Подготовка протокола к аудиту"
Продолжительность: 30-60 минут
Дата: четверг, 12.09.2024
Время: 19:00 мск
Где: zoom
Приглашаю всех!
#video
🔥6👍3❤1
Media is too big
VIEW IN TELEGRAM
Запись стрима "Подготовка протокола (dApp) к аудиту"
Прежде всего, спасибо всем, кто пришел меня поддержать вчера на стриме! Как я уже говорил, это был мой самый первый стрим лекция, я очень волновался и, как мне показалось, немного "тараторил". Однако, думаю, все получилось и вот выкладываю саму запись. Я также позже 0добавлю аудиозапись для тех, кто привык слушать лекции в формате подкастов (это одна из классных фишек Zoom, когда он выгружает и видео, и аудио после конференции).
Таймкоды:
01.50 - введение
05.50 - читаемость кода
08.00 - комментарии
14.20 - документация к dApp
24.45 - самостоятельный аудит
42.30 - scope / out-of-scope / setup
53.38 - где искать аудиторов
57.06 - маркетинг dApp во время аудита
Ссылка на презентацию (Goggle Docs)
Стрим и презентация была создана специально для нашего канала - Solidity. Смарт контракты и аудит
Ссылки и ресурсы, которые упоминались в презентации:
1. Стилистика кода - Coinbase Solidity Style Guide
2. Стилистика кода - Inline Yul Style Guide
3. Программа для создания схем и диаграмм - tldraw
4. Программа для создания схем и диаграмм - Whimsical
5. Программа для создания схем и диаграмм - Draw.io
6. Практика с инвариантами - Categorizing_Properties
7. Практика с инвариантами - Properties
8. Практика с инвариантами - Thinking About Properties
Чеклисты:
1. Solodit checklist
2. The Ultimate 100+ Point Checklist
3. The ultimate security checklist
4. Development Guidelines
Примеры протоколов с хорошей документацией:
1. Basin protocol code
2. Panoptic code
3. Lens Protocol V2
4. Tangible Caviar
5. Panoptic
6. UniStaker Infrastructure
7. Ethena Labs
8. Ethereum Credit Guild
9. Ondo Finance
10. PoolTogether
Где искать аудиторов:
1. Code4rena leaderboard
2. CodeHawks leaderboard
3. Sherlock leaderboard
4. Immunefi leaderboard
5. Hat finance leaderboard
Всем приятного просмотра и безопасных протоколов!
#video
Прежде всего, спасибо всем, кто пришел меня поддержать вчера на стриме! Как я уже говорил, это был мой самый первый стрим лекция, я очень волновался и, как мне показалось, немного "тараторил". Однако, думаю, все получилось и вот выкладываю саму запись. Я также позже 0добавлю аудиозапись для тех, кто привык слушать лекции в формате подкастов (это одна из классных фишек Zoom, когда он выгружает и видео, и аудио после конференции).
Таймкоды:
01.50 - введение
05.50 - читаемость кода
08.00 - комментарии
14.20 - документация к dApp
24.45 - самостоятельный аудит
42.30 - scope / out-of-scope / setup
53.38 - где искать аудиторов
57.06 - маркетинг dApp во время аудита
Ссылка на презентацию (Goggle Docs)
Стрим и презентация была создана специально для нашего канала - Solidity. Смарт контракты и аудит
Ссылки и ресурсы, которые упоминались в презентации:
1. Стилистика кода - Coinbase Solidity Style Guide
2. Стилистика кода - Inline Yul Style Guide
3. Программа для создания схем и диаграмм - tldraw
4. Программа для создания схем и диаграмм - Whimsical
5. Программа для создания схем и диаграмм - Draw.io
6. Практика с инвариантами - Categorizing_Properties
7. Практика с инвариантами - Properties
8. Практика с инвариантами - Thinking About Properties
Чеклисты:
1. Solodit checklist
2. The Ultimate 100+ Point Checklist
3. The ultimate security checklist
4. Development Guidelines
Примеры протоколов с хорошей документацией:
1. Basin protocol code
2. Panoptic code
3. Lens Protocol V2
4. Tangible Caviar
5. Panoptic
6. UniStaker Infrastructure
7. Ethena Labs
8. Ethereum Credit Guild
9. Ondo Finance
10. PoolTogether
Где искать аудиторов:
1. Code4rena leaderboard
2. CodeHawks leaderboard
3. Sherlock leaderboard
4. Immunefi leaderboard
5. Hat finance leaderboard
Всем приятного просмотра и безопасных протоколов!
#video
3🔥21❤4
Solidity hints. Часть 24
Новая неделя, а значит новые посты про Solidity и разработку!
Спасибо всем за добрые отзывы по стриму! В целом, ничего страшного не произошло, поэтому, думаю, через недельку можно будет провести что-то новое, например, взять тему по безопасности смарт контрактов и типичных уязвимостях со стандартом EIP4626.
Также скоро будет открываться набор на последний, третий, модуль курса для продолжающих обучение Solidity. Многие ученики уже закончили с летним модулем и пора двигаться дальше!
А пока что, пара пунктов из репо:
39. Public state variables can override external functions if the parameter and return types of the function matches the getter function of the variable. They themselves cannot be overriden
что в переводе:
Публичные переменные состояния могут переопределять внешние функции, если типы параметров и возврата функции совпадают с геттер функцией переменной. Сами они не могут быть переопределены
Вообще, интересный нюанс, чтобы понять который мне пришлось заглядывать в документацию языка. Было сложно понять как такое реализуется в коде, и на примере все гораздо проще. Посмотрите на код:
У нас есть два контракта. В первом - реализуется функция, которая возвращает параметр с определенным значением. Во втором - переменная состояния с таким же именем и типом данных.
Получается, что при вызове f во втором контракте, мы будем обращаться не к функции, а к переменной. Получается, что переменная, как бы переписывает значения функции.
На самом деле, я никогда не встречал в контрактах такую систему и сложно представить необходмый случай для подобного кода, где нельзя было бы обойтись более простым решением. Но такая "штука" есть, и знаеть о ней хорошо.
А мы идем далее и следующий пункт:
40. Before the constructor code is executed, state variables are initialized to their specified value if you initialize them inline, or their default value if you do not.
что в переводе:
Перед выполнением кода конструктора переменные состояния инициализируются в указанное значение, если вы инициализируете их inline, или в значение по умолчанию, если вы этого не делаете.
Тут все просто и изучается на самых первых порах знакомства с Solidity.
Когда мы создаем переменные состояния в контракте, то у них уже по умолчанию есть некоторые значения. Например, у uint это 0, у bool - false.
И в пункте говорится, что до выполнения кода в конструкторе, все переменные состояния получают либо установленное разработчиком значение, либо свое дефолтное. А уже после исполнения конструктора, они записываются в код самого контракта.
#variables #state
Новая неделя, а значит новые посты про Solidity и разработку!
Спасибо всем за добрые отзывы по стриму! В целом, ничего страшного не произошло, поэтому, думаю, через недельку можно будет провести что-то новое, например, взять тему по безопасности смарт контрактов и типичных уязвимостях со стандартом EIP4626.
Также скоро будет открываться набор на последний, третий, модуль курса для продолжающих обучение Solidity. Многие ученики уже закончили с летним модулем и пора двигаться дальше!
А пока что, пара пунктов из репо:
39. Public state variables can override external functions if the parameter and return types of the function matches the getter function of the variable. They themselves cannot be overriden
что в переводе:
Публичные переменные состояния могут переопределять внешние функции, если типы параметров и возврата функции совпадают с геттер функцией переменной. Сами они не могут быть переопределены
Вообще, интересный нюанс, чтобы понять который мне пришлось заглядывать в документацию языка. Было сложно понять как такое реализуется в коде, и на примере все гораздо проще. Посмотрите на код:
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.6.0 <0.9.0;
contract A
{
function f() external view virtual returns(uint) { return 5; }
}
contract B is A
{
uint public override f;
}
У нас есть два контракта. В первом - реализуется функция, которая возвращает параметр с определенным значением. Во втором - переменная состояния с таким же именем и типом данных.
Получается, что при вызове f во втором контракте, мы будем обращаться не к функции, а к переменной. Получается, что переменная, как бы переписывает значения функции.
На самом деле, я никогда не встречал в контрактах такую систему и сложно представить необходмый случай для подобного кода, где нельзя было бы обойтись более простым решением. Но такая "штука" есть, и знаеть о ней хорошо.
А мы идем далее и следующий пункт:
40. Before the constructor code is executed, state variables are initialized to their specified value if you initialize them inline, or their default value if you do not.
что в переводе:
Перед выполнением кода конструктора переменные состояния инициализируются в указанное значение, если вы инициализируете их inline, или в значение по умолчанию, если вы этого не делаете.
Тут все просто и изучается на самых первых порах знакомства с Solidity.
Когда мы создаем переменные состояния в контракте, то у них уже по умолчанию есть некоторые значения. Например, у uint это 0, у bool - false.
И в пункте говорится, что до выполнения кода в конструкторе, все переменные состояния получают либо установленное разработчиком значение, либо свое дефолтное. А уже после исполнения конструктора, они записываются в код самого контракта.
#variables #state
👍3❤2
Solidity hints. Часть 25
А сегодня у нас редко изучаемая тема на курсах и при самостоятельном прохождении: порядок наследования. Об этом, в основном, просто упоминают, но не особо рассказывают почему это работает так.
И в этом нам поможет следующий пункт:
41. The order in which the base classes are given in the is directive is important: You have to list the direct base contracts in the order from “most base-like” to “most derived”
что в переводе:
Порядок указания базовых классов в директиве is очень важен: вы должны перечислить прямые базовые контракты в порядке от «наиболее похожих на базовые» до «наиболее производных».
Вообще, я сначала не очень понял этот пункт и, как обычно, полез в документацию. Давайте разбираться вместе.
Языки, допускающие множественное наследование, сталкиваются с несколькими проблемами. Одна из них - Diamond Problem. Solidity похож на Python тем, что использует «C3-линеаризацию» для принудительного установления определенного порядка в направленном ациклическом графе (DAG) базовых классов (чтобы это не значило). Это приводит к желаемому свойству монотонности, но не позволяет использовать некоторые графы наследования.
Другой более простой способ объяснить это заключается в том, что при вызове функции, которая определена несколько раз в разных контрактах, базовые данные перебираются справа налево (в Python - слева направо) в порядке глубины поиска, останавливаясь на первом совпадении. Если контракт с базой уже был просмотрен, он пропускается.
В следующем коде Solidity выдаст ошибку «Linearization of inheritance graph impossible».
Причина в том, что C просит X отменить A (указывая A, X в таком порядке), но A сама просит отменить X, что является противоречием, которое невозможно разрешить.
Из-за того, что вам придется явно переопределять функцию, которая наследуется от нескольких баз без уникального переопределения, линеаризация C3 не слишком важна на практике.
Одна из областей, где линеаризация наследования особенно важна и, возможно, не так очевидна, - это когда в иерархии наследования есть несколько конструкторов. Конструкторы всегда будут выполняться в линеаризованном порядке, независимо от того, в каком порядке их аргументы предоставляются в конструкторе наследуемого контракта. Например:
Теперь вы знаете чуть больше о линеаризация наследования... Или нет?
#inheritance
А сегодня у нас редко изучаемая тема на курсах и при самостоятельном прохождении: порядок наследования. Об этом, в основном, просто упоминают, но не особо рассказывают почему это работает так.
И в этом нам поможет следующий пункт:
41. The order in which the base classes are given in the is directive is important: You have to list the direct base contracts in the order from “most base-like” to “most derived”
что в переводе:
Порядок указания базовых классов в директиве is очень важен: вы должны перечислить прямые базовые контракты в порядке от «наиболее похожих на базовые» до «наиболее производных».
Вообще, я сначала не очень понял этот пункт и, как обычно, полез в документацию. Давайте разбираться вместе.
Языки, допускающие множественное наследование, сталкиваются с несколькими проблемами. Одна из них - Diamond Problem. Solidity похож на Python тем, что использует «C3-линеаризацию» для принудительного установления определенного порядка в направленном ациклическом графе (DAG) базовых классов (чтобы это не значило). Это приводит к желаемому свойству монотонности, но не позволяет использовать некоторые графы наследования.
Другой более простой способ объяснить это заключается в том, что при вызове функции, которая определена несколько раз в разных контрактах, базовые данные перебираются справа налево (в Python - слева направо) в порядке глубины поиска, останавливаясь на первом совпадении. Если контракт с базой уже был просмотрен, он пропускается.
В следующем коде Solidity выдаст ошибку «Linearization of inheritance graph impossible».
pragma solidity >=0.4.0 <0.9.0;
contract X {}
contract A is X {}
// This will not compile
contract C is A, X {}
Причина в том, что C просит X отменить A (указывая A, X в таком порядке), но A сама просит отменить X, что является противоречием, которое невозможно разрешить.
Из-за того, что вам придется явно переопределять функцию, которая наследуется от нескольких баз без уникального переопределения, линеаризация C3 не слишком важна на практике.
Одна из областей, где линеаризация наследования особенно важна и, возможно, не так очевидна, - это когда в иерархии наследования есть несколько конструкторов. Конструкторы всегда будут выполняться в линеаризованном порядке, независимо от того, в каком порядке их аргументы предоставляются в конструкторе наследуемого контракта. Например:
// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.7.0 <0.9.0;
contract Base1 {
constructor() {}
}
contract Base2 {
constructor() {}
}
// Constructors are executed in the following order:
// 1 - Base1
// 2 - Base2
// 3 - Derived1
contract Derived1 is Base1, Base2 {
constructor() Base1() Base2() {}
}
// Constructors are executed in the following order:
// 1 - Base2
// 2 - Base1
// 3 - Derived2
contract Derived2 is Base2, Base1 {
constructor() Base2() Base1() {}
}
// Constructors are still executed in the following order:
// 1 - Base2
// 2 - Base1
// 3 - Derived3
contract Derived3 is Base2, Base1 {
constructor() Base1() Base2() {}
}
Теперь вы знаете чуть больше о линеаризация наследования... Или нет?
#inheritance
🔥4👍1
Продолжение курса: 3 модуль
Прошел почти месяц с завершения летнего модуля, многие ученики справились с финальным заданием, и пришло время для последней части курса в этом году.
Темы 3 модуля подходят для продолжающих свое обучение в Solidity: кто знает основные стандарты и умеет писать простые и среднесложные контракты.
Обучение займет весь октябрь.
Если вы хотите попасть на курс, прошу проголосовать в опросе ниже. Также прошу НЕ голосовать учеников с текущего летнего модуля, так как хочу узнать, есть ли желающие среди остальных участников канала.
На 3 модуле, так же как и в прошлом году, будет два преподавателя. Второй - намного опытнее меня в практическом плане и работе с памятью контракта и низкоуровневыми языками.
Итак, темы модуля:
Неделя 1
1. Древо Меркла: общее
2. Подписи и стандарты
3. ecrecover и ECDSA
4. Безопасность подписей
Неделя 2
5. Прокси. Общее
6. Transparent и UUPS proxy
7. Beacon proxy, Diamond
8. Безопасность proxy
Неделя 3
9. Работа с памятью: code
10. Работа с памятью: storage
11. Работа с памятью: memory
12. Работа с памятью: calldata
13. Работа с памятью: stack
Неделя 4
14. Опкоды
15. Yul и assembly
16. Побитовые операции
17. Дебаггинг контрактов
Стоимость: 5000 рублей / 60 USDT
Ориентировочный старт: 30 сентября
Стоимость такая же, как и в начале этого года! В следующий раз будет дороже!
Продажи стартуют на следующей неделе!
Материалы с курса остаются с вами навсегда. Задания можно будет сдавать до Нового Года.
#курс
Прошел почти месяц с завершения летнего модуля, многие ученики справились с финальным заданием, и пришло время для последней части курса в этом году.
Темы 3 модуля подходят для продолжающих свое обучение в Solidity: кто знает основные стандарты и умеет писать простые и среднесложные контракты.
Обучение займет весь октябрь.
Если вы хотите попасть на курс, прошу проголосовать в опросе ниже. Также прошу НЕ голосовать учеников с текущего летнего модуля, так как хочу узнать, есть ли желающие среди остальных участников канала.
На 3 модуле, так же как и в прошлом году, будет два преподавателя. Второй - намного опытнее меня в практическом плане и работе с памятью контракта и низкоуровневыми языками.
Итак, темы модуля:
Неделя 1
1. Древо Меркла: общее
2. Подписи и стандарты
3. ecrecover и ECDSA
4. Безопасность подписей
Неделя 2
5. Прокси. Общее
6. Transparent и UUPS proxy
7. Beacon proxy, Diamond
8. Безопасность proxy
Неделя 3
9. Работа с памятью: code
10. Работа с памятью: storage
11. Работа с памятью: memory
12. Работа с памятью: calldata
13. Работа с памятью: stack
Неделя 4
14. Опкоды
15. Yul и assembly
16. Побитовые операции
17. Дебаггинг контрактов
Стоимость: 5000 рублей / 60 USDT
Ориентировочный старт: 30 сентября
Стоимость такая же, как и в начале этого года! В следующий раз будет дороже!
Продажи стартуют на следующей неделе!
Материалы с курса остаются с вами навсегда. Задания можно будет сдавать до Нового Года.
#курс
🔥10👍1
Хотели бы присоединиться к 3 модулю?
Final Results
60%
Да, звучит интересно
21%
Еще подумаю
19%
Нет, не в этот раз
👍3
Кратко про третий, он же четвертый, модуль
В комментариях и в личных сообщениях спрашивали про 3 и другие модули курса: ведь зимой прошел 4 модуль, а сейчас последний - третий. Отвечаю на все вопросы сразу.
На первом потоке курса, который закончился этой зимой, было 4 модуля. На втором - текущем - потоке их 3, так как Летний модуль объединял в себя сразу второй и третий. И сейчас будет проходить последний модуль. Дальше уже возможный перезапуск в следующем году.
Я также упоминал, что будет больше модулей, однако сейчас не вижу в этом особой необходимости. Многие ученики уже с середины курса выбирают понравившееся им направление и сами "добирают" материалы по теме. Так одним нравятся DeFi проекты и они стараются больше учить из чего они состоят, другие выбирают изучение безопасности смарт контрактов и участие в конкурсных аудитах, третьи увлекаются тестированием и т.д.
Получается, что темы новых модулей не будут востребованы. Да, и название курса звучит как: "Начинающий разработчик смарт контрактов на языке Solidity".
И вот с данным третьим модулем будет заканчиваться программа курса, так как эти темы обязательны для изучения и понимания специалиста web3, независимо от обозначенной выше профессии: аудитор, разработчик или тестировщик.
Это уже более продвинутые уроки и для учеников потребуется некоторые знания Solidity и навыки написания контрактов, поэтому с нуля зайти на модуль не получится - будет просто не понятно, что к чему.
Докупить предыдущие модули на данный момент также будет нельзя - я просто не смогу уделить достаточно внимания ученикам последнего модуля и начинающим, а нанимать кураторов значить увеличивать стоимость, чего я совсем не хочу.
Текущий модуль займет весь октябрь. Работы можно будет сдавать до Нового года. Таким образом учиться можно будет в своем темпе.
Завтра чуть больше расскажу о темах модуля и почему они важны, а продажи откроются, по обычаю, в среду и продлятся до полночи воскресенья.
#курс
В комментариях и в личных сообщениях спрашивали про 3 и другие модули курса: ведь зимой прошел 4 модуль, а сейчас последний - третий. Отвечаю на все вопросы сразу.
На первом потоке курса, который закончился этой зимой, было 4 модуля. На втором - текущем - потоке их 3, так как Летний модуль объединял в себя сразу второй и третий. И сейчас будет проходить последний модуль. Дальше уже возможный перезапуск в следующем году.
Я также упоминал, что будет больше модулей, однако сейчас не вижу в этом особой необходимости. Многие ученики уже с середины курса выбирают понравившееся им направление и сами "добирают" материалы по теме. Так одним нравятся DeFi проекты и они стараются больше учить из чего они состоят, другие выбирают изучение безопасности смарт контрактов и участие в конкурсных аудитах, третьи увлекаются тестированием и т.д.
Получается, что темы новых модулей не будут востребованы. Да, и название курса звучит как: "Начинающий разработчик смарт контрактов на языке Solidity".
И вот с данным третьим модулем будет заканчиваться программа курса, так как эти темы обязательны для изучения и понимания специалиста web3, независимо от обозначенной выше профессии: аудитор, разработчик или тестировщик.
Это уже более продвинутые уроки и для учеников потребуется некоторые знания Solidity и навыки написания контрактов, поэтому с нуля зайти на модуль не получится - будет просто не понятно, что к чему.
Докупить предыдущие модули на данный момент также будет нельзя - я просто не смогу уделить достаточно внимания ученикам последнего модуля и начинающим, а нанимать кураторов значить увеличивать стоимость, чего я совсем не хочу.
Текущий модуль займет весь октябрь. Работы можно будет сдавать до Нового года. Таким образом учиться можно будет в своем темпе.
Завтра чуть больше расскажу о темах модуля и почему они важны, а продажи откроются, по обычаю, в среду и продлятся до полночи воскресенья.
#курс
❤6👌3👍1
Да кому вообще нужны прокси и assembly...
На фоне хайпа мемкоинов (типа pump fun) или различных тапалок, можно задать вполне резонный вопрос, а зачем нужны какие-то сложные темы в разработке, по типу прокси, assembly, подписей и некоторых других... Ведь для простого протокола знаний о том, как создавать токены ERC20 или NFT - ERC721 будет вполне достаточно...
Тут "палка о двух концах"... С одной стороны для создания проекта действительно знаний двух-трех стандартов достаточно, с другой - насколько сложные протоколы вы хотите создавать и как планируете строить свою карьеру дальше.
Если уходить в разработку и целенаправленно искать работу в зарубежных компаниях - то лучше иметь полные знания Solidity, так как велика вероятность сложных вопросов на собеседованиях и последующей работе с уже написанным кодом. А там наверняка будут и "подписи" и "yul".
Более того, с каждым годом требования к найму становятся все сложнее. Если пару лет назад знание низкоуровневого языка помогло бы вам стать если не мидлом, то джуном с хорошей зарплатой, то сейчас эти требования уже предъявляются к интернам.
На курсе я стараюсь дать базовые знания по необходимым темам, чтобы при необходимости вы сами могли быстро найти нужную информацию и разобраться, что делает код.
На группе вы сможете задавать вопросы сразу двум преподавателям и изучать материал в своем темпе. Не нужно будет "бегать" по чатам в телеграмме или форумам с вопросами: "а где почитать про это?" или "за что отвечает этот assembly?".
Материалы на курсе - это уроки в текстовом формате с домашними заданиями и дополнительными материалами. Лучший пример уроков можно найти на бесплатном курсе по Foundry, который я выкладывал в прошлом году - https://news.1rj.ru/str/solidityset/962
В общем, этот модуль подойдет для тех, кто хочет научиться полноценной разработке на Solidity, а не просто "писать тапалки" и мемкоинами.
Завтра открытие продаж! А старт курса на следующей неделе!
#курс
На фоне хайпа мемкоинов (типа pump fun) или различных тапалок, можно задать вполне резонный вопрос, а зачем нужны какие-то сложные темы в разработке, по типу прокси, assembly, подписей и некоторых других... Ведь для простого протокола знаний о том, как создавать токены ERC20 или NFT - ERC721 будет вполне достаточно...
Тут "палка о двух концах"... С одной стороны для создания проекта действительно знаний двух-трех стандартов достаточно, с другой - насколько сложные протоколы вы хотите создавать и как планируете строить свою карьеру дальше.
Если уходить в разработку и целенаправленно искать работу в зарубежных компаниях - то лучше иметь полные знания Solidity, так как велика вероятность сложных вопросов на собеседованиях и последующей работе с уже написанным кодом. А там наверняка будут и "подписи" и "yul".
Более того, с каждым годом требования к найму становятся все сложнее. Если пару лет назад знание низкоуровневого языка помогло бы вам стать если не мидлом, то джуном с хорошей зарплатой, то сейчас эти требования уже предъявляются к интернам.
На курсе я стараюсь дать базовые знания по необходимым темам, чтобы при необходимости вы сами могли быстро найти нужную информацию и разобраться, что делает код.
На группе вы сможете задавать вопросы сразу двум преподавателям и изучать материал в своем темпе. Не нужно будет "бегать" по чатам в телеграмме или форумам с вопросами: "а где почитать про это?" или "за что отвечает этот assembly?".
Материалы на курсе - это уроки в текстовом формате с домашними заданиями и дополнительными материалами. Лучший пример уроков можно найти на бесплатном курсе по Foundry, который я выкладывал в прошлом году - https://news.1rj.ru/str/solidityset/962
В общем, этот модуль подойдет для тех, кто хочет научиться полноценной разработке на Solidity, а не просто "писать тапалки" и мемкоинами.
Завтра открытие продаж! А старт курса на следующей неделе!
#курс
👍5
Обучение в группе или самому?
Знаете, почему мне всегда нравилось обучение в группе? Да, сообщество других учеников для общения - это, конечно, здорово, но больше всего мне нравилось ощущение того, что "это может закончиться"!
Сейчас уже третий год, как я сам непрерывно обучаюсь тем или иным штукам из web3 сферы: тестированию, поиску уязвимостей, defi математике и другому. И тут я понятия не имею, сколько у меня это займет и придет ли этому конец... Сложно искать информацию, улавливать основную суть, практиковаться и структурировать свои знания.
На курсах и обучениях все по другому.
Тебе дают материалы и практику дозированными уроками: без воды, без траты времени на ее поиск, с возможностью уточнить тот или иной вопрос у преподавателя. И вы точно знаете сроки, когда это все закончится.
Да, не факт, что я успею все проходить в потоке, но я уверен, что есть ограниченное количество тем и времени, через которое я получу этот набор знаний.
Я сам бы сейчас многое отдал за "душный" курс, где бы мне рассказали все о математических расчетах в DeFi протоколах, структурированный от простого до сложного. И я прекрасно понимаю, что все это можно найти в открытых источниках, но без толкового объяснения порой понять очень и очень сложно.
И даже если вы никогда не будете общаться в чате курса, все равно будете знать, что в случае необходимости, всегда можно обратиться за помощью по нужной теме.
Это и отличает групповое обучение от самостоятельного. А вы как думаете?
#курс
Знаете, почему мне всегда нравилось обучение в группе? Да, сообщество других учеников для общения - это, конечно, здорово, но больше всего мне нравилось ощущение того, что "это может закончиться"!
Сейчас уже третий год, как я сам непрерывно обучаюсь тем или иным штукам из web3 сферы: тестированию, поиску уязвимостей, defi математике и другому. И тут я понятия не имею, сколько у меня это займет и придет ли этому конец... Сложно искать информацию, улавливать основную суть, практиковаться и структурировать свои знания.
На курсах и обучениях все по другому.
Тебе дают материалы и практику дозированными уроками: без воды, без траты времени на ее поиск, с возможностью уточнить тот или иной вопрос у преподавателя. И вы точно знаете сроки, когда это все закончится.
Да, не факт, что я успею все проходить в потоке, но я уверен, что есть ограниченное количество тем и времени, через которое я получу этот набор знаний.
Я сам бы сейчас многое отдал за "душный" курс, где бы мне рассказали все о математических расчетах в DeFi протоколах, структурированный от простого до сложного. И я прекрасно понимаю, что все это можно найти в открытых источниках, но без толкового объяснения порой понять очень и очень сложно.
И даже если вы никогда не будете общаться в чате курса, все равно будете знать, что в случае необходимости, всегда можно обратиться за помощью по нужной теме.
Это и отличает групповое обучение от самостоятельного. А вы как думаете?
#курс
👍9👏1
Мы пройдем курс, а что дальше?
Резонный вопрос любого человека, перед покупкой какого-либо обучения.
Зачем мне этот курс? Что делать после? Получу ли новую работу? Что мне делать для дальнейшего продвижения? Помогут ли мне это знания для достижения моих целей?
Для ответа на каждый из этих вопросов, вы уже изначально должны иметь представление о том, зачем вообще вам это! Абсолютно безрезультатно будет покупка и прохождение любого обучения, просто для галочки...
Наш курс, "Начинающий разработчик смарт контрактов" создан для тех, кто хотел бы попробовать свои силы в web3, но не уверен, что справится и ему хватит упорства и решимости сменить карьеру и уйти полностью в разработку.
Небольшая стоимость самого курса и его модульность, позволяет проверить свою идею с минимальными финансовыми и временными затратами. Если вас все будет устраивать, вы сможете пройти весь курс целиком. Если поймете, что это просто "не ваше", то без труда закончите раньше. Если же вообще загоритесь этой идеей, то, возможно, выберите более профессиональное обучение в более дорогих школах.
Так что же делать после курса?
Как бы это не звучало, но - выбирать специализацию.
Этих трех модулей вполне достаточно, что "копнуть глубоко" в Solidity, научиться писать достойные смарт контракты, изучить базовую безопасность и создать свой первый протокол.
Далее вас по-любому заинтересует одно из направлений:
1. Погружаться в DeFi и пробовать создать свой финансовый протокол;
2. Заинтересоваться работой EVM и запустить свою ноду;
3. Уйти в тестирование и стать pro в этом;
4. Попробовать себя в конкурсных аудитах и заняться безопасностью;
5. Стать фуллстек разработчиком и писать тапалки или даже полноценные игры;
6. Или даже попробовать связать реальный мир с блокчейном;
Каждое из этих направлений требует дополнительного обучения. И в большинстве случаев, оно будет самостоятельным. И вот почему...
Solidity - это основа в данной подборке. Тот фундамент, разобравшись в котором, вы сможете понимать свое профессиональное движение и знать, откуда черпать информацию.
И вот после курса, не бросайтесь рассылать резюме по компаниям, а выберите направление и сфокусируйтесь на нем: поищите сообщества, действующие протоколы, позадавайте вопросы в чатах и форумах.
В сообществе гораздо легче и развиваться и искать работу.
Программа курса
#курс
Резонный вопрос любого человека, перед покупкой какого-либо обучения.
Зачем мне этот курс? Что делать после? Получу ли новую работу? Что мне делать для дальнейшего продвижения? Помогут ли мне это знания для достижения моих целей?
Для ответа на каждый из этих вопросов, вы уже изначально должны иметь представление о том, зачем вообще вам это! Абсолютно безрезультатно будет покупка и прохождение любого обучения, просто для галочки...
Наш курс, "Начинающий разработчик смарт контрактов" создан для тех, кто хотел бы попробовать свои силы в web3, но не уверен, что справится и ему хватит упорства и решимости сменить карьеру и уйти полностью в разработку.
Небольшая стоимость самого курса и его модульность, позволяет проверить свою идею с минимальными финансовыми и временными затратами. Если вас все будет устраивать, вы сможете пройти весь курс целиком. Если поймете, что это просто "не ваше", то без труда закончите раньше. Если же вообще загоритесь этой идеей, то, возможно, выберите более профессиональное обучение в более дорогих школах.
Так что же делать после курса?
Как бы это не звучало, но - выбирать специализацию.
Этих трех модулей вполне достаточно, что "копнуть глубоко" в Solidity, научиться писать достойные смарт контракты, изучить базовую безопасность и создать свой первый протокол.
Далее вас по-любому заинтересует одно из направлений:
1. Погружаться в DeFi и пробовать создать свой финансовый протокол;
2. Заинтересоваться работой EVM и запустить свою ноду;
3. Уйти в тестирование и стать pro в этом;
4. Попробовать себя в конкурсных аудитах и заняться безопасностью;
5. Стать фуллстек разработчиком и писать тапалки или даже полноценные игры;
6. Или даже попробовать связать реальный мир с блокчейном;
Каждое из этих направлений требует дополнительного обучения. И в большинстве случаев, оно будет самостоятельным. И вот почему...
Solidity - это основа в данной подборке. Тот фундамент, разобравшись в котором, вы сможете понимать свое профессиональное движение и знать, откуда черпать информацию.
И вот после курса, не бросайтесь рассылать резюме по компаниям, а выберите направление и сфокусируйтесь на нем: поищите сообщества, действующие протоколы, позадавайте вопросы в чатах и форумах.
В сообществе гораздо легче и развиваться и искать работу.
Программа курса
#курс
👍9🔥5
Merkle-Patricia Trees. Часть 1
Вот и закончилась неделя продаж курса и мы возвращаемся в свое привычное русло!
Когда я пересматривал уроки модуля, где есть темы Древа Меркла, то вспомнил, что уже давно хотел рассмотреть новую для себя тему: Merkle-Patricia Trees. Именно поэтому на канале мы немного "подушним" и разберем, что это такое, как работает и какие проблемы могут возникнуть! Итак, поехали:
В сфере технологии блокчейн передовая структура данных, известная как дерево Меркл-Патриция, является ключевой частью инфраструктуры. Эта структура сочетает в себе свойства деревьев Меркла и деревьев Патриции, что позволяет создать высокоэффективную и безопасную модель представления и проверки данных. Хотя они ассоциируются в первую очередь с Ethereum, их полезность выходит далеко за рамки только этого блокчейна.
Деревья Меркл-Патриция играют важную роль в различных решениях второго уровня, сайдчейнах и других вопросах масштабируемости. Например, решения второго уровня, такие как Rollups, Plasma chains и state channels, используют эти структуры для создания компактных доказательств доступности данных и переходов между состояниями. Аналогичным образом, побочные цепи, представляющие собой отдельные сети блокчейна, предназначенные для работы рядом с основной цепью, также используют деревья Меркл-Патриция для обеспечения согласованности данных и безопасного взаимодействия.
Но что такое деревья Меркл-Патриция и почему они так важны для этих систем? Для того, чтобы ответить на эти и другие вопросы, давайте разберем эту концепцию по частям, изучим их свойства, применение и значение для поддержания безопасности и целостности экосистем блокчейн.
Кратко вспомним, что такое Древо Меркла
Древо Меркла - это разновидность структуры данных, используемой в вычислительной технике. Структура данных - это просто способ организации и хранения данных, чтобы их можно было эффективно использовать.
Давайте разложим определение дерева Меркла на более простые части:
1. Что такое древо в вычислительной технике? Представьте себе семейное дерево, где «предки» находятся вверху, а «потомки» - внизу. Дерево в вычислительной технике похоже на это. Оно начинается с единственного «корневого» узла наверху, который разветвляется на «дочерние» узлы, а каждый из них может иметь свои «дочерние» узлы, и так далее. Узлы в самом низу, у которых нет дочерних узлов, называются «листьями».
2. Что такое криптографический хэш? Хэш - это способ получить любой объем входных данных (например, предложение, документ или целую книгу) и создать из него строку символов фиксированного размера, которая выглядит случайной. Его особенность заключается в том, что любое небольшое изменение входных данных полностью изменит хэш, и вы не сможете вернуться от хэша к исходным данным.
Криптографические хэш-функции - это особые типы хэш-функций, которые отличаются особой безопасностью, то есть их очень сложно перевернуть или найти коллизии (это когда два разных входа дают один и тот же хэш).
3. Как строится дерево Меркла? Вы начинаете с блоков данных в нижней части дерева в качестве «листьев». Каждый из этих блоков данных превращается в хэш. Затем каждая пара этих хэшей объединяется и снова хэшируется, чтобы получить хэш для узла, расположенного над ними. Этот процесс продолжается вверх по дереву, пока не получится один хэш на вершине, который и является «корнем» дерева.
4. Для чего используется дерево Меркла? Деревья Меркла используются там, где нужно быстро и безопасно проверить данные. Например, они используются в технологии блокчейн (которая лежит в основе таких криптовалют, как Bitcoin), чтобы гарантировать, что все транзакции действительны, без необходимости проверять каждую из них.
По сути, деревья Меркла позволяют очень быстро и с высокой степенью достоверности проверить, является ли небольшой фрагмент данных частью большого набора данных. Если у вас есть верхний хэш и возможность двигаться вниз по дереву, вы можете проверить, входит ли часть данных в исходный набор данных, не имея всего набора данных.rd для реверсирования или поиска коллизий.
#merkle #patricia
Вот и закончилась неделя продаж курса и мы возвращаемся в свое привычное русло!
Когда я пересматривал уроки модуля, где есть темы Древа Меркла, то вспомнил, что уже давно хотел рассмотреть новую для себя тему: Merkle-Patricia Trees. Именно поэтому на канале мы немного "подушним" и разберем, что это такое, как работает и какие проблемы могут возникнуть! Итак, поехали:
В сфере технологии блокчейн передовая структура данных, известная как дерево Меркл-Патриция, является ключевой частью инфраструктуры. Эта структура сочетает в себе свойства деревьев Меркла и деревьев Патриции, что позволяет создать высокоэффективную и безопасную модель представления и проверки данных. Хотя они ассоциируются в первую очередь с Ethereum, их полезность выходит далеко за рамки только этого блокчейна.
Деревья Меркл-Патриция играют важную роль в различных решениях второго уровня, сайдчейнах и других вопросах масштабируемости. Например, решения второго уровня, такие как Rollups, Plasma chains и state channels, используют эти структуры для создания компактных доказательств доступности данных и переходов между состояниями. Аналогичным образом, побочные цепи, представляющие собой отдельные сети блокчейна, предназначенные для работы рядом с основной цепью, также используют деревья Меркл-Патриция для обеспечения согласованности данных и безопасного взаимодействия.
Но что такое деревья Меркл-Патриция и почему они так важны для этих систем? Для того, чтобы ответить на эти и другие вопросы, давайте разберем эту концепцию по частям, изучим их свойства, применение и значение для поддержания безопасности и целостности экосистем блокчейн.
Кратко вспомним, что такое Древо Меркла
Древо Меркла - это разновидность структуры данных, используемой в вычислительной технике. Структура данных - это просто способ организации и хранения данных, чтобы их можно было эффективно использовать.
Давайте разложим определение дерева Меркла на более простые части:
1. Что такое древо в вычислительной технике? Представьте себе семейное дерево, где «предки» находятся вверху, а «потомки» - внизу. Дерево в вычислительной технике похоже на это. Оно начинается с единственного «корневого» узла наверху, который разветвляется на «дочерние» узлы, а каждый из них может иметь свои «дочерние» узлы, и так далее. Узлы в самом низу, у которых нет дочерних узлов, называются «листьями».
2. Что такое криптографический хэш? Хэш - это способ получить любой объем входных данных (например, предложение, документ или целую книгу) и создать из него строку символов фиксированного размера, которая выглядит случайной. Его особенность заключается в том, что любое небольшое изменение входных данных полностью изменит хэш, и вы не сможете вернуться от хэша к исходным данным.
Криптографические хэш-функции - это особые типы хэш-функций, которые отличаются особой безопасностью, то есть их очень сложно перевернуть или найти коллизии (это когда два разных входа дают один и тот же хэш).
3. Как строится дерево Меркла? Вы начинаете с блоков данных в нижней части дерева в качестве «листьев». Каждый из этих блоков данных превращается в хэш. Затем каждая пара этих хэшей объединяется и снова хэшируется, чтобы получить хэш для узла, расположенного над ними. Этот процесс продолжается вверх по дереву, пока не получится один хэш на вершине, который и является «корнем» дерева.
4. Для чего используется дерево Меркла? Деревья Меркла используются там, где нужно быстро и безопасно проверить данные. Например, они используются в технологии блокчейн (которая лежит в основе таких криптовалют, как Bitcoin), чтобы гарантировать, что все транзакции действительны, без необходимости проверять каждую из них.
По сути, деревья Меркла позволяют очень быстро и с высокой степенью достоверности проверить, является ли небольшой фрагмент данных частью большого набора данных. Если у вас есть верхний хэш и возможность двигаться вниз по дереву, вы можете проверить, входит ли часть данных в исходный набор данных, не имея всего набора данных.rd для реверсирования или поиска коллизий.
#merkle #patricia
❤3
Merkle-Patricia Trees. Часть 2
1. Основная терминология в дереве Меркла:
- Листовые узлы являются самыми нижними узлами в дереве (у них нет дочерних узлов) и представляют собой блоки данных.
- Родительские узлы помечены криптографическим хэшем их дочерних узлов.
- Корневой узел (верхний узел дерева) известен как корень Меркла.
2. Построение дерева Меркла:
Пусть у нас есть 4 блока данных - L1, L2, L3 и L4.
Шаг 1: Начнем с получения криптографических хэшей блоков данных.
HL1 = Hash(L1)
HL2 = Hash(L2)
HL3 = Hash(L3)
HL4 = Hash(L4)
Здесь 'Hash' может быть любой криптографической хэш-функцией, например SHA256.
Шаг 2: Хэши объединяются в пары и конкатенируются, после чего вычисляется хэш полученной строки.
HL12 = Hash(HL1 + HL2)
HL34 = Hash(HL3 + HL4)
Здесь '+' означает конкатенацию.
Шаг 3: Эти хэши снова конкатенируются и хэшируются для получения корня.
ROOT = Hash(HL12 + HL34)
Этот ROOT является корнем нашего дерева Меркла.
Как и раньше, вы можете использовать это дерево для эффективной и безопасной проверки содержимого этих блоков данных. Процесс точно такой же, но с обновленными именами блоков.
#merkle #patricia
1. Основная терминология в дереве Меркла:
- Листовые узлы являются самыми нижними узлами в дереве (у них нет дочерних узлов) и представляют собой блоки данных.
- Родительские узлы помечены криптографическим хэшем их дочерних узлов.
- Корневой узел (верхний узел дерева) известен как корень Меркла.
2. Построение дерева Меркла:
Пусть у нас есть 4 блока данных - L1, L2, L3 и L4.
Шаг 1: Начнем с получения криптографических хэшей блоков данных.
HL1 = Hash(L1)
HL2 = Hash(L2)
HL3 = Hash(L3)
HL4 = Hash(L4)
Здесь 'Hash' может быть любой криптографической хэш-функцией, например SHA256.
Шаг 2: Хэши объединяются в пары и конкатенируются, после чего вычисляется хэш полученной строки.
HL12 = Hash(HL1 + HL2)
HL34 = Hash(HL3 + HL4)
Здесь '+' означает конкатенацию.
Шаг 3: Эти хэши снова конкатенируются и хэшируются для получения корня.
ROOT = Hash(HL12 + HL34)
Этот ROOT является корнем нашего дерева Меркла.
Как и раньше, вы можете использовать это дерево для эффективной и безопасной проверки содержимого этих блоков данных. Процесс точно такой же, но с обновленными именами блоков.
#merkle #patricia
❤1