Запускаем бесплатную программу обучения по Node js в Web3

Привет всем! Мы в MetaLamp давно занимаемся обучение разработчиков, у нас есть свои программы обучения по фронтенду и бэкенду, а недавно мы запустили обучения по смарт-контрактам Solidity и фронтенду в web3.

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

Почему все говорят про Node.js

Node.js уже давно стал одним из главных инструментов для разработки серверной части. Его используют, чтобы строить быстрые и масштабируемые веб-приложения и не только. К примеру, Netflix, LinkedIn и Uber сделали Node.js значимой частью своей инфраструктуры. Так что эта платформа не просто тренд, а эффективный инструмент.

Кроме того, JavaScript (js), на котором базируется Node.js, занимает лидирующие позиции среди языков программирования. И это легко объяснить. Он универсален, используется как на фронтенде, так и на бэкенде, и у него огромное сообщество. Node.js уверенно стоит на первом месте среди серверных технологий. Освоивший ноду, во-первых, станет специалистом по серверным технологиям. Во-вторых, сможет легко изучить фронтенд и перейти в лигу fullstack.

И еще одна приятная деталь: зарплаты в этой сфере радуют. По данным Хабр Карьера, джуниоры на Node получают около 85 тысяч рублей, мидлы — 220 тысяч, а сеньоры могут зарабатывать до 330 тысяч рублей в месяц.

Читайте подробнее о программе в нашей новой статье!

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

Tolk — новый язык для разработки смарт-контрактов на TON, который заменил FunC

Всем привет! Я Александр Смирнов, пишу смарт-контракты на FunC и Solidity в MetaLamp. Хотел рассказать про Tolk, его основные отличия от FunC и свое впечатление о нем.

Tolk больше похож на TypeScript и Kotlin, в отличие от FunC, который выглядит как C или Lisp. Однако он по-прежнему даёт контроль над ассемблером TVM, поскольку внутри него находится ядро FunC.

Основные отличия Tolk и FunC:

1) Объявление функции происходит через fun, геттера — через get;

2) Переменные объявляются через var, неизменяемые (immutable) переменные — через val;

3) Cпецификаторы функций, такие как inline,  записываются как декораторы: @inline;

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

5) Никакого impure: по умолчанию компилятор не будет выкидывать пользовательские вызовы функций;

6) recv_internal, recv_external заменяются на onInternalMessage, onExternalMessage;

7) Поддерживаются люгичесие операции И (&&), ИЛИ (||), отрицание (!);

8) Идентификаторы буквенно-цифровые, 2+2 — это 4 (в отличие от FunC, где это 2+2), нейминг выглядит следующим образом: const OP_INCREASE = 123456; (вместо const op::increase = 123456; в FunC — сейчас компилятор выдаст ошибку);

9) Улучшения в синтаксисе;

10) Функция может быть вызвана до ее объявления: компилятор сначала парсит, а затем сопоставляет вызываемые функции. Сейчас исходный код представляется как абстрактное синтаксическое дерево (AST);

11) Наименование переменных и функций в Tolk в camelCase, в отличие от snake_case в FunC;

12) Никакой тильды (~)! Ее совсем убрали, теперь не нужно возиться с изменением объектов, так как методы возвращают self, аналогично JavaScript;

13) Не нужно импортировать stdlib, однако, если работаете со словарями, нужно импортировать "@stdlib/tvm-dicts";

Для ленивых продвинутых можно воспользоваться удобным инструментом для преобразования FunC в Tolk. На 100% доверять ему не стоит, так как сами разработчики пишут, что необходимы небольшие ручные правки, поэтому лучше освоить Tolk и использовать для ускорения переезда с FunC. Его удобно использовать совместно с Blueprint.

Общее впечатление от Tolk: писать стало комфортнее, но это скорее для тех, кто привык работать с TypeScript. Много упрощений, а также код выглядит более читаемым. Зная FunC, можно за небольшое время перейти на Tolk. Уже есть плагины для VSCode и JetBrains, поэтому подсветка синтаксиса работает.

Больше постов от разработчиков можно найти в нашем телеграм-канале :)

EIP-7549: Move committee index outside Attestation

EIP-7549 является вторым предложением по изменению на уровне консенсуса и предлагает переместить индекс комитета за пределы аттестации. Звучит интересно, но непонятно. Начнём разбираться издалека.

▫️Введение в работу валидатора

Все мы знаем, что валидаторы оставляют 32 ETH в качестве депозита и после этого запускают специальное программное обеспечение, которое состоит из трёх частей:

• Execution Client

• Consensus Client

• Validator Client

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

▫️Структура слотов и эпох в Ethereum

Далее стоит отметить, что сейчас в Ethereum время появления блоков фиксированное и делится на слоты. Один слот — 12 секунд, эпоха — 32 слота. Для каждого слота случайным образом выбирается валидатор, предлагающий блок. В его обязанности входит создание и отправка блока другим участникам. Также в слоте случайным образом выбирается комитет валидаторов, аттестации которых должны подтвердить, что блок действительный. Разделение валидаторов на комитеты необходимо для управления нагрузкой на сеть. Деление на комитеты организовано так, чтобы каждый активный валидатор подтверждал блок в каждой эпохе, но не в каждом слоте.

▫️Понятие финализации блоков

Но это ещё не всё. Чтобы транзакция считалась окончательной, она должна быть частью блока, который уже не может быть изменён без больших затрат. Этот процесс называется финализацией. Управляется это при помощи специальных «checkpoints». Первый блок каждой эпохи — это и есть checkpoint. Требуется две трети от общего застейканного эфира всех валидаторов, которые предоставят свои аттестации.

▫️Разбор полей аттестации

Это всё в теории. Под капотом консенсуса работают два компонента: Casper-FFG и алгоритм выбора форка LMD-GHOST. Первый компонент отвечает за финализацию блоков, получение валидатором вознаграждения или наказания, второй компонент следит за раздвоением сети.

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

• aggregation_bits: Массив бит валидаторов, где каждый индекс соответствует номеру валидатора в комитете.

• data: Сведения для аттестации (подтверждения действительности блока).

• slot: Номер слота, для которого подготовлена аттестация.

• index: Номер, который идентифицирует, к какому комитету принадлежит валидатор в данном слоте.

• beacon_block_root: Хеш блока, за который валидатор голосует.

• source: Последний согласованный чекпоинт.

• target: Целевой чекпоинт текущей эпохи.

• signature: Подпись BLS, которая подписывает данные поля data.

▫️Предлагаемое изменение в EIP-7549

Вот мы и добрались до индекса, который EIP-7549 предлагает вынести за пределы аттестации. Для Casper-FFG это критически важное изменение. Суть в том, что все участники разных комитетов голосуют за одну и ту же информацию,  подписывая данные в поле data аттестации. Зачастую данные одинаковые, за исключением индекса комитета, который не позволяет агрегировать эти подписи в одну. Поэтому предлагается убрать индекс и объединить одинаковые аттестации, что позволит уменьшить их количество.

Вот так, покопавшись в сути этого EIP, который на первый взгляд мог выглядеть странно, я могу сделать вывод, что звучит всё логично, по крайней мере идея становится понятной. Видимо, поэтому мне и не удалось найти каких-то явных противостояний или противников EIP-7549. Отдельно стоит отметить, что этот EIP вносит обратно несовместимые изменения в проверку блоков на уровне консенсуса, поэтому он и включается в хард-форк.

Подписывайтесь на наш телеграм-канал:)

Всем привет!

Мы опубликовали новую статью про нашу карту развития для web3 фронтендеров. В статье подробнее рассказываем, как устроена карта, как возникла идея ее создания и какие карты развития у нас еще есть))

Еще мы ведем свой телеграм-канал, где информация из мира разработки и web3 выходит оперативнее всего, переходите почитать авторские посты и мнение нашей команды, а также похоливарить в комментариях:)

Разбор ERC-6900: Модульные абстрактные аккаунты и плагины

ERC-6900 — это стандарт Ethereum, определяющий модульные абстрактные аккаунты (Modular Smart Contract Account — MSCA). Он расширяет функциональность абстрактных аккаунтов ERC-4337 (кто пропустил, мы уже писали о них тут), позволяя выносить дополнительную логику и проверки во внешние модули.

Ключевые аспекты ERC-6900:

• Модульность: позволяет разделить логику аккаунта на отдельные плагины.

• Расширяемость: упрощает добавление новых функций к аккаунтам без изменения основного кода.

• Стандартизация: обеспечивает совместимость между различными реализациями аккаунтов и плагинов.

• Интеграция с ERC-4337: совместим с инфраструктурой Account Abstraction.

Важно! Оба стандарта (ERC-4337 и ERC-6900) находятся в стадии черновика, поэтому возможны изменения. В статье рассматривается AA (ERC-4337) версии v0.6.0 и ERC-6900 (MSCA) версии v0.7.0 (на базе AA v0.6.0). Например, уже есть новая версия AA, в которой изменена работа с validateUserOp, но MSCA пока этого не поддерживает.

Кроме того, ERC-6900 тесно связан с Alchemy, поэтому самые свежие обновления по этому стандарту, скорее всего, будут в их репозиториях, так как они разрабатывают архитектуру для работы с такими аккаунтами. Это один из главных недостатков стандарта — он создается с учетом нужд конкретного протокола, а не всего сообщества.

Читайте продолжение статьи тут:)

Опубликовали новую статью — обзор протокола LayerZero!

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

Велком к прочтению:)

Еще мы ведем свой телеграм-канал, где информация из мира разработки и web3 выходит оперативнее всего, переходите почитать авторские посты и мнение нашей команды, а также похоливарить в комментариях:)

❗️Внимание разработчики

Команда MetaLamp столкнулась со скамером. Рекомендуем изучить, чтобы не стать жертвой мошенников.

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

Решили обсудить это с нашими друзьями-аудиторами из BugBlow и ребята обнаружили стилера (от англ. steal — красть) написали подробный отчет. 

В чем угроза?

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

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

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

Кстати хакер, написавший этот код оставил свой IP адрес, на который украденные данные отправляются 138.201.199.46. 

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

Спасибо Александру Долгавину из BugBlow за отчет! Вступайте в чат про безопасность BugBlow и читайте X команды.

Stay Safe!

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE. Part 2

Part 1 опубликован здесь.

Маленький нюанс: в чем профит условному Lido объединять группу своих валидаторов в одного? Предлагается несколько плюшек: возможность частично изымать сумму стейкинга, а также обсуждаются послабления штрафной системы, плюс, как я понял выбор валидаторов взвешенный уже сейчас, чем больше стейк, тем выше вероятность, что валидатор будет выбран для добавления блока (поправьте меня тут, если я не прав)

Что же остается делать соло валидаторам? Их вероятность добавлять блоки теперь ниже? Кажется именно так. Взамен предлагаются гибкие ставки, например, можно сразу стейкать 40 ETH в одного валидатора и получать больше вознаграждения, а не копить на второго валидатора. Достаточно соло валидаторы ущемлены на благо диверсификации сети? Надеюсь, что в меру, чтобы продолжить быть валидаторами.

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

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE. Part 1

Идея проста! EIP-7251 предлагает валидаторам стейкать больше 32 ETH. Сейчас в коде за это отвечает переменная «MAX_EFFECTIVE_BALANCE». Отсюда и такое название EIP. Тоесть, а давайте увеличим максимальную сумму для стейкинга.

Приводится статистика: на октябрь 2023 года в сети работает свыше 830 000 валидаторов и их число продолжает расти. Однако, есть большое количество «redundant validators» или избыточных валидаторов — это связано с протоколами ликвидного стейкинга, которые объединяют пользователей в группы для совместного управления валидаторами. Сейчас сумма стейка ограничена 32 ETH и такие протоколы запускают множество валидаторов. В результате мы имеем, что определенная группа валидаторов находится в одних руках. На 12 октября доля Lido занимает 29,7%. Пурумпурумпум! Ситуация!

EIP предлагает оставить 32 ETH как нижнюю границу, своего рода входной билет, а верхнюю поднять до 2048 ETH. Рассчет прост, теперь Lido может держать за место 64-х валидаторов со стейкиногом по 32 ETH всего одного на 2048 ETH. Не сложно догадаться, что это должно положительно сказаться на диверсификации сети и снизить количество избыточных валидаторов.

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

Бонус: в конце статьи вы найдете инструкцию как сделать свой мост :)

Если хотите узнавать самые последние новости и интересные тренды из web3, то переходите в наш телеграм-канал, там мы холиварим и обсуждаем все самое интересное и полезное!

EIP-7600: Hardfork Meta - Pectra

Pectra — запланированный хардфорк сети Ethereum на конец 24-го или начало 25-го года. На данный момент, хардфорк включает в себя 8 запланированных и 3 рассматриваемых на включение EIPs.

Consensus Layer

• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

• EIP-7549: Move committee index outside Attestation

Execution Layer

• EIP-2537: Precompile for BLS12-381 curve operations

• EIP-2935: Save historical block hashes in state

• EIP-6110: Supply validator deposits on chain

• EIP-7685: General purpose execution layer requests

• EEIP-7002: Execution layer triggerable exits

• EIP-7702: Set EOA account code for one transaction

Общие 

• EIP-6110: Supply validator deposits on chain

• EIP-7002: Execution layer triggerable exits

Практически все EIPs относятся к внутренним механизмам и затрагивают несколько этапов из роадмапа Ethereum: The Merge (улучшение со стороны консенсуса), The Scourge (решение проблем централизации), The Splurge (fix everything else).

Интересно здесь то, что немалая часть уделяется этапу «The Splurge». Это история про поправим все остальное. Что это означает? Протокол сделал все что хотел и работает над стабилизацией после хардфорка Dencun? Чтобы ответить на этот вопрос предлагаем вместе с нами попробовать разобраться во всех EIPs.

Первый EIP-7251 разберем в следующем посте, а то нас ограничивает количество символов в постах на Хабре:)

Все посты по этой теме можно будет найти по тегу #в_гостях_у_Pectra. Больше интересных тем разбираем в нашем телеграм-канале!

Мы выпустили новую крутую статью! Это технический обзор UniswapX — протокола, который выполняет обмен токенов через сторонних поставщиков ликвидности с применением аукциона. 

Чем интересна эта статья?

• Рассмотрели архитектуру протокола

• Способы его интеграции в существующие системы

• Различные стратегии исполнения ордеров

Велком к прочтению!

Начинаем серию статей про рынок предсказаний и его главного представителя на сегодня Polymarket. В первой статье подробнее разберем, как работает Gnosis Conditional Token Framework, который реализует кодовую базу для токенизации потенциальных исходов на рынке предсказаний.

Приятного прочтения!

 Привет, Хабр!

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

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

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

Сейчас у нас появилась 3-я ветка программы, приглашаем всех, кому интересно обучиться на разработчика смарт-контрактов для EVM-сетей и погрузиться в мир Solidity!

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

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

Welcome!

Привет всем!

Наш Lead Solidity-разработчик Паша Найданов @pnaydanovgoo опубликовал новую статью про Aave: в ней он разбирает работу Flash loans — типа кредитования на базе смарт‑контрактов, который не требует залога для обеспечения займа.

Почему Flash loans так популярны сейчас и какими уникальными характеристиками они обладают, а главное, как их можно использовать — подробности в статье:)

Всем привет! Руководитель нашего отдела дизайна @julyakey09опубликовала статью-кейс про то, как мы разработали дизайн для MVP стартапа всего за 7 дней. Это был тот еще челлендж)) В статье Юля рассказывает о нетипичном подходе к UX/UI дизайну, использовании открытых библиотек и работе без формального ТЗ. Получилось интересно, будем рады прочтениям!