Погружение в Core Solidity. Часть 7

Тип Proxy

Последним элементом, необходимым для реализации abi.encode, является тип Proxy:

data Proxy(T) = Proxy;

Как и в определении типа memory, параметр типа здесь является фантомным, однако, в отличие от memory, Proxy не несёт никакой дополнительной информации во время выполнения. Он существует исключительно как маркерный тип, позволяющий передавать информацию на этапе компиляции. Подобные типы полностью «бесплатны» с точки зрения производительности: они полностью элиминируются на этапе компиляции и вовсе не присутствуют в финальной скомпилированной программе.

Хотя Proxy может показаться довольно экзотическим инструментом, он чрезвычайно полезен и даёт нам значительный контроль над выводом типов и выбором экземпляров классов типов без необходимости передавать данные во время выполнения там, где они не нужны. Такой подход часто используется как в Haskell (где он тоже называется Proxy), так и в Rust (std::marker::PhantomData).

abi.encode

Теперь мы готовы реализовать функцию abi.encode из классического Solidity на языке SAIL. Начнём с определения класса типов для метаданных, связанных с ABI. Заметим, что поскольку этому классу не нужно знать фактическое значение передаваемого типа, мы используем Proxy, чтобы сделать реализацию максимально лёгкой.

forall T . class T:ABIAttribs {
    // how many bytes should be used for the head portion of the ABI encoding of `T`
    function headSize(ty : Proxy(T)) -> word;
    // whether or not `T` is a fully static type
    function isStatic(ty : Proxy(T)) -> bool;
}

instance uint256:ABIAttribs {
    function headSize(ty : Proxy(uint256)) -> word { return 32; }
    function isStatic(ty : Proxy(uint256)) -> bool { return true; }
}

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

// types that can be abi encoded
forall T . T:ABIAttribs => class T:ABIEncode {
    // abi encodes an instance of T into a memory region starting at basePtr
    // offset gives the offset in memory from basePtr to the first empty byte of the head
    // tail gives the position in memory of the first empty byte of the tail
    function encodeInto(x : T, basePtr : word, offset : word, tail : word) -> word /* newTail */;
}

instance uint256:ABIEncode {
    // a unit256 is written directly into the head
    function encodeInto(x : uint256, basePtr : word, offset : word, tail : word) -> word {
        let repx : word = Typedef.rep(x);
        assembly { mstore(add(basePtr, offset), repx) }
        return tail;
    }
}

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

// top level encoding function.
// abi encodes an instance of `T` and returns a pointer to the result
forall T . T:ABIEncode => function abi_encode(val : T) -> memory(bytes) {
    let free = get_free_memory();
    let headSize = ABIAttribs.headSize(Proxy : Proxy(T));
    let tail = ABIEncode.encodeInto(val, free, 0, Add.add(free, headSize));
    set_free_memory(tail);
    return memory(free);
}

#core

📟 Прилетело из @solidityset

Всё, что вам нужно знать про HuggingFace
P.S. В этом посте я упомяну "huggingface" 10 раз. Заранее извиняюсь

Тут будет сразу серия статей!!

Обзор huggingface.co

– Что такое huggingface;
– Кто и как использует huggingface;
– Как пользоваться huggingface новичку.

Выбор модели под задачу на huggingface.co

– Какие есть фильтры на huggingface и как ими пользоваться;
– Разберём практические шаблоны для фильтрации.

Обзор карточки модели на huggingface.co

– Разберём все разделы карточки на huggingface;
– Протестируем модель прямо в браузере;
– Узнаем кто и как может подгрузить кастомный код на наше локальное устройство и как этого избежать.

📟 Прилетело из @semolina_code_python

Рынок гуляет - мы вместе с ним. А гулять мы будем на призовой фонд онлайн хакатона Мантл на $150,000

Mantle запустили онлайн хакатон, который идёт прямо сейчас и закончится 7 февраля следующего года. Призовой пул составляет $150,000 и разбит на несколько треков. Я бы особо пригляделся к DeFi-направлению - там можно и выстрелить, и покачать скилы

Если вы давно хотели войти в dev-игру или просто ищете повод попробовать что-то новое — welcome.
Хакатоны особенно круто подходят новичкам, поэтому влетайте, тем более Мантл EVM совместимый чейн, поэтому простор для форков протоколов широк как никогда

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

Больше инфы по ссылке:
https://www.hackquest.io/hackathons/Mantle-Global-Hackathon-2025?utm=ortomich

Учавствуйте и побеждайте!
(Подача заявок закрывается 31 декабря, успевайте)

Статья о PSM MakerDao завтра

📟 Прилетело из @ortomich_main

Токеномика $ZKP проекта ZkPass. Насколько хороша она, и насколько будет перспективен будущий токен?

Он ещё не появился, но токеномику опубликовали в X статье.

zkPass - это технология, которая позволяет доказывать любые данные из Web2 без передачи личной информации. Благодаря zkTLS можно подтвердить факт - например, что у тебя есть аккаунт на бирже с верификацией, что ты совершил определённое количество действий в X или что у тебя есть определённые достижения, - но не раскрывать логин, баланс или другие детали. Всё работает прямо через браузер, без доступов проекта к сайтам.
По сути, zkPass - это приватный оракул, который превращает данные в криптографическое доказательство, чтобы их можно было использовать в Web3 безопасно и анонимно.

Распределение:

Всего: 1 МЛРД.

1. Community - 48.5%
12.5% разблокировано на TGE. 6% начисляется линейно в течение первых 3 месяцев с момента TGE, 30% начисляется ежемесячно в течение 5 лет, начиная с TGE.
Многовато будет выделяться первые полгода. Это 2% в месяц, что может привести к просадке при небольшом спросе.
Плюс, распределяется 0.5% в месяц. - это уже норм.
Но если суммарно с первым будет 6 месяцев, то это вообще будет 2.5% - дофига!

2. Early Investors - 22.5%
0% на TGE, 12-месячный перерыв, за которым следует 18-месячное линейное распределение.
22.5% / 18 = 1.25% в месяц - многовато.
Инвесторам много распределяют (> 10%) - может привести к просадке после разлоков.

3. Core Contributors - 14%
0% на TGE, 24-месячный перерыв, за которым следует 24-месячный линейный вестинг.
14% / 24 = 0.583% в месяц - нормально, но суммарно получится многовато.
Это, как понимаю, команде. Здесь более-менее нормально. Конечно выше допустимого максимума в 10%, но редко когда вижу это значение. А тут укладывается в 15%, которые периодически наблюдаю.

4. DAO Treasury - 10%
Линейный вестинг в течение 5 лет.
10% / 60 = 0.166% в месяц - допустимо.
Смотря на что будут распределять, но в любом случае норм доля выделяется.

5. Liquidity - 5%
100% на TGE.
Зависит от того, как будут использовать, но в целом доля допустимая выделяется.

Итог по вестингу:

В первые 3 месяца разлок составляет примерно 2.16% в месяц.
С 4-го месяца до 12-го он снижается до 0.66%.
Через год после TGE начинается разлок инвесторов - нагрузка повышается до 1.92% в месяц.
А через два года подключаются Core Contributors, и совокупный разлок достигает 2.499% в месяц.
В целом разлоки довольно большие, особенно после первого года - цена может не выдержать такую нагрузку без сильного спроса.

Утилиты $ZKP:

1. Settlement Medium - $ZKP используется как основной расчётный токен внутри zkPass: им оплачивается выполнение доказательств, работа верификаторов и операции zkTLS.
2. Validator Collateral - $ZKP выступает в роли коллатерала для валидаторов, обеспечивая корректность, аптайм и безопасность сети. При нарушениях возможен слэшинг.
3. Network Credits - токен служит сетевыми кредитами для учёта вклада участников, включая вычисления, интеграции и подтверждения данных.
4. Service Access - предприятия и разработчики используют $ZKP для доступа к zk-native verification API и приватной инфраструктуре проверки данных.
5. Governance и координация - $ZKP участвует в управлении через zkPassDAO и служит связующим слоем между проверяемыми системами в экосистеме zkPass.
6. Дефляционная модель - часть комиссий сжигается, а DAO периодически выкупает $ZKP за счёт доходов протокола, что делает модель токена дефляционной.


Общий итог:

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

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

А как вам проект? Напишите мнение в комментариях.
Я пользовался, и показался удобным: понравилось подтверждать верификацию на CEX без повторной отправки данных кому-то непонятному.

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev

Погружение в Core Solidity. Финал

Совместимость и взаимодействие

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

Как и в предыдущих крупных обновлениях Solidity, совместимость на уровне ABI будет сохраняться между версиями. Это позволит отдельным контрактам, написанным на несовместимых версиях языка, взаимодействовать друг с другом и сосуществовать в рамках одного проекта (аналогичная стратегия применяется в Rust с их функцией «Editions»). Мы также изучаем возможность более глубокого взаимодействия, выходящего за рамки только ABI контрактов. Предполагается, что хотя бы свободные функции и определения интерфейсов можно будет совместно использовать между версиями языка.

Хотя изменения затронут как синтаксис, так и семантику, мы намерены свести их к минимуму и применять только в тех случаях, когда это строго необходимо или приносит существенные преимущества, оправдывающие затраты на миграцию. Мы ожидаем, что простой код без наследования будет выглядеть и ощущаться практически одинаково в обеих версиях языка, с лишь незначительными синтаксическими отличиями (в основном — переход от префиксной записи типов к постфиксной). Мы также рассматриваем возможность переработки или замены некоторых функций, которые на практике оказались проблемными или ограничивающими (например, try/catch, библиотеки, указатели на функции, области данных). Пользователи могут ожидать, что для адаптации кода, использующего эти возможности, потребуются умеренные изменения. Разумеется, код, активно использующий наследование, потребует наиболее значительных переделок.

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

Избежать раскола по типу «Python 2 → Python 3» — наша главная задача. Мы считаем, что обновления должны быть управляемыми и возможными для поэтапного внедрения.

Путь к использованию

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

У нас уже есть прототип, реализованный в отдельном репозитории: solcore. Мы можем выполнять проверку типов программ на SAIL и имеем конвейер генерации кода до уровня Yul. Однако до окончательной фиксации системы типов нам ещё предстоит реализовать как минимум вычисления на этапе компиляции и модульную систему. У нас есть базовая стандартная библиотека и достаточное количество этапов «десахаризации» (desugaring) для реализации самых фундаментальных возможностей классического Solidity. Мы уже можем генерировать контракты, совместимые по ABI, с поддержкой диспетчеризации, кодирования/декодирования ABI и доступа к хранилищу.

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

Как только мы убедимся в стабильности прототипа, работа разделится на два параллельных направления:

📟 Прилетело из @solidityset

1. Продакшн реализация: мы перепишем проверку типов, этапы десахаризации и генерацию Yul на системном языке (например, Rust, C++ или Zig) и интегрируем это в основной компилятор solc. Эта реализация будет ориентирована на корректность, производительность и обеспечение максимально качественных диагностических сообщений и ошибок.

2. Исполняемая формальная семантика: мы формализуем наше существующее описание на LaTeX в среде автоматического доказательства теорем (вероятно, Lean). Это позволит укрепить доверие как к данной реализации, так и к самой стандартной библиотеке и системе типов.

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

#core

📟 Прилетело из @solidityset

Откуда берутся стейблкоины? Обзор на PSM в MakerDao/Sky Protocol

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

Ставьте реакции, оставляйте комментарии и подписывайтесь, поддержка оч роляет

А теперь к прочтению!
Линк Линк Линк

📟 Прилетело из @ortomich_main

Не опять, а снова

Как они заебали уже, дайте спокойно поработать

Чат | Support | Market
Pelican | HiddenCode [EN]

📟 Прилетело из @hidden_coding

Вышел Solidity 0.8.31

Команда Solidity объявила о выходе компилятора Solidity версии 0.8.31. Обновление приносит поддержку новых возможностей EVM, представленных в сетевом апгрейде Fusaka, расширяет функциональность спецификаторов раскладки хранилища и запускает первый этап отказа от устаревших возможностей, которые будут окончательно удалены в версии 0.9.0. Кроме того, теперь официально публикуются сборки компилятора для Linux на архитектуре ARM.

Одним из ключевых изменений стало то, что версия EVM с кодовым названием osaka теперь используется по умолчанию. При необходимости разработчики по-прежнему могут указать более старую версию виртуальной машины через настройки компилятора. В новой версии также добавлена поддержка опкода CLZ, реализующего стандарт EIP-7939. Эта инструкция позволяет считать количество ведущих нулей в 256-битном слове и открывает новые возможности для оптимизаций, битовых операций, алгоритмов сжатия и работы со структурами данных на уровне приложений.

В ближайшее время этот опкод найдет активное применение в популярных библиотеках, включая solady и OpenZeppelin, где сможет заменить существующие реализации вроде Math.clz(). Пока в самом компиляторе область применения CLZ ограничена, но команда изучает способы использовать его для будущих оптимизаций генерации байткода.

С точки зрения инфраструктуры релиза произошло важное обновление: начиная с этой версии, Solidity официально выпускается в виде бинарных сборок для Linux на ARM. Ранее такие версии существовали либо в виде сборок под macOS, либо в виде самостоятельной компиляции из исходников. Теперь ARM-билды встроены в систему CI и проходят тот же цикл тестирования, что и остальные платформы, гарантируя идентичность байткода и метаданных на всех архитектурах.

Также введён формат предварительных релизов. Если раньше существовали только ночные сборки и полноценные релизы, то теперь появились pre-release версии, позволяющие получать доступ к новым фичам раньше официального релиза. Именно в pre-release впервые стала доступна поддержка CLZ, и эта практика будет использоваться дальше для постепенного внедрения экспериментальных возможностей.

Одновременно команда начала оптимизировать каналы распространения компилятора. В частности, официально прекращена поддержка Ubuntu PPA, так как этот канал оказался маловостребованным. Docker-сборки пока сохраняются, но в будущем тоже могут быть убраны, если их использование останется незначительным. При этом контейнеры уже перенесены из DockerHub в реестр GitHub, и новые версии будут публиковаться именно там.

Наконец, версия 0.8.31 открывает фазу активной подготовки к релизу 0.9.0, который станет несовместимым с предыдущими версиями. В компилятор добавлены предупреждения об устаревании send() и transfer(), устаревшего ABI coder v1, виртуальных модификаторов, сравнений контрактов без явного приведения к адресу и специального комментария memory-safe-assembly. Всё это сигнализирует о переходе Solidity к более строгой типизации, более прозрачной семантике и сокращению исторически сложных и небезопасных конструкций, которые долгое время тянулись из ранних версий языка.

#solidity

📟 Прилетело из @solidityset

https://www.reddit.com/r/lotrmemes/comments/1peb8sm/well_thats_one_way_to_take_it_i_guess/

📟 Прилетело из @dev_in_ruby_colors

Приболел, поэтому пока бубут только посты про токеномику.

😎 Незрячий web3 программист (подписаться)
Чат | бот

📟 Прилетело из @blind_dev