Forem: Laruh Development Presents

Что нового в Rust 1.92 beta: LLVM 20 и послабление E0719

Laruh Development Presents — Thu, 27 Nov 2025 11:43:40 +0000

Смотрю, что завезли в Rust 1.92.0 beta (релиз 11 декабря 2025) https://releases.rs/docs/1.92.0/

Что зацепило взгляд:

Минимальный LLVM 20

https://github.com/rust-lang/rust/pull/145071
В компиляторе подняли минимальную поддерживаемую версию внешнего LLVM до 20.

Если коротко, это значит:

собирать rustc со старым LLVM 19 уже нельзя;
официально поддерживаются сборки с LLVM 20 и 21;

Для пользователей rustup это просто ещё один шаг вперёд по части оптимизаций и багфиксов на стороне бэкенда.

Дальше улучшения в синтаксисе.

Allow specifying multiple bounds for same associated item, except in trait objects

PR https://github.com/rust-lang/rust/pull/146593

Этот PR почти полностью снимает ограничение ошибки E0719 (An associated type value was specified more than once https://doc.rust-lang.org/stable/error_codes/E0719.html) и позволяет несколько раз ограничивать один и тот же ассоциированный элемент трейта внутри одного T: Trait<…>, кроме случая с dyn Trait.

Что раньше было нельзя

Примеры из описания PR, которые раньше ломались с E0719:

// было запрещено:
T: Trait<Gat<u32> = u32, Gat<u64> = u64>
T: Iterator<Item = u32, Item = i32>
T: Iterator<Item = u32, Item = u32>
T: Iterator<Item: Send, Item: Sync>
T: Trait<ASSOC = 3, ASSOC = 4>
T: Trait<ASSOC = 3, ASSOC = 3>

Разрешённые обходы выглядели так:

// обходы:
T: Trait<Gat<u32> = u32> + Trait<Gat<u64> = u64>
T: Iterator<Item = u32> + Iterator<Item = i32>
T: Iterator<Item = u32>     // вместо дубля
T: Iterator<Item: Send + Sync>
T: Trait<ASSOC = 3> + Trait<ASSOC = 4>
T: Trait<ASSOC = 3>

То есть формально всё можно было выразить, но запись становилась более шумной.

Еще примеры «до» и «после».

GAT-ы (Generic Associated Types) раньше приходилось "колхозить" вот так:

// раньше приходилось писать так:
fn foo<T>() 
where 
    T: Trait<Gat<u32> = u32> + Trait<Gat<u64> = u64>
{}

// а можно будет компактнее:
fn foo<T>() 
where 
    T: Trait<Gat<u32> = u32, Gat<u64> = u64>
{}

Пример с trait bounds на ассоциированный тип:

// было:
fn foo<T>()
where
    T: Iterator<Item = u32> + Iterator<Item: Send + Sync>
{}

// а можно будет так:
fn foo<T>()
where
    T: Iterator<Item = u32, Item: Send + Sync>
{}

По смыслу это то же самое, что:

fn foo<T>()
where
    T: Iterator,
    <T as Iterator>::Item = u32,
    <T as Iterator>::Item: Send + Sync,
{}

Просто теперь можно всё это собрать в одном Iterator<...>.

Но для dyn Trait всё ещё нельзя обойти E0719

Для dyn Iterator<Item = u32, Item = u32> и аналогичных dyn Trait<…> ошибка E0719 остаётся. В описании PR есть ссылка на комментарий, где это объясняется:

Types like dyn Iterator<Item = u32, Item = u32> will continue to be rejected, however. See #143146 (comment) https://github.com/rust-lang/rust/pull/143146#issuecomment-3274421752 for the reason why.

Если коротко, проблема в следующем:

generic-bound’ы не создают новый «реальный» тип наподобие dyn Iterator<…>, а всего лишь накладывают условия на уже существующий тип-параметр.
А dyn Iterator<…> — это уже конкретный тип времени выполнения с vtable, layout и TypeId. Внутри компилятора он хранится как «трейтовый объект + список ограничений на ассоциированные типы».

У dyn Trait все штуки вида Item = ... входят в само тождество типа: внутренне это «трейтовый объект + список projection bounds». После PR https://github.com/rust-lang/rust/pull/136458 компилятор больше не сливает дубликаты этих bounds «потом», на поздних стадиях.
Если сейчас разрешить записи вроде dyn Iterator<Item = for<'a> fn(&'a ()), Item = for<'b> fn(&'b ())>, то такой тип станет другим по сравнению с интуитивно эквивалентным dyn Iterator<Item = for<'c> fn(&'c ())>, просто потому что список bounds отличается.

Дополнительно это лезет в разницу между старым и новым trait solver’ами: старый просто берёт первый кандидат для Item, новый пытается учесть все и слить их, если результат совпадает. При нескольких Item = ... это может привести к тонким случаям, где старый solver успешно нормализует тип, а новый внезапно видит «лишние» ограничения на лайфтаймы и объявляет неоднозначность.

Comprehensive Rust Resource Guide: Official Docs, Books, Cheat Sheets & More

Laruh Development Presents — Mon, 09 Dec 2024 16:41:29 +0000

UPDATE: 🚀 Rust Resources Hub – Now on GitHub!
Stay up to date with the latest additions in the GitHub repo!

Table of Contents

Official Documentation by rust-lang org
Open Source Books and Various Sites With Guides
Exercises
Podcasts
Algorithms
Cheat Sheets
Serialization
WebAssembly (Wasm)
Blockchain
Interview
Various Rust Articles and Deep Dives

Official Documentation by rust-lang org

Open Source Books and Various Sites With Guides

Exercises

Rust by Practice
Rustlings This project contains small exercises to get you used to reading and writing Rust code. This includes reading and responding to compiler messages.
Rustfinity - challenges

Podcasts

Rust in Production podcasts by corrode.dev Under episodes, you can find a list of links related to the discussion topics.

Algorithms

The Algorithms - Rust Open Source resource for learning Data Structures & Algorithms and their implementation in any Programming Language

Cheat Sheets

Rust Cheatsheet

Serialization

Serde Documentation
- Derive

WebAssembly (Wasm)

Заметка из жизни: пример работы тейкера в обновленном атомарном свопе

Laruh Development Presents — Wed, 04 Dec 2024 16:04:53 +0000

В предыдущем посте Что такое атомарные свопы? описан один из возможных вариантов реализации протокола атомарного свопа. Этот протокол был разработан и реализован командой Komodo Platform. Если интересно, можете скачать приложение или сбилдить проект из исходного кода и потестить.

Сейчас идет активная работа над новой версией протокола атомарного свопа — trading protocol upgrade v2 (TPU v2).

На текущий момент TPU v2 поддерживает атомарные свопы для UTXO-монет (в разработке, еще не в продакшене). Это значит, что уже можно обменивать пары монет формата UTXO<->UTXO (монета мейкера <-> монета тейкера). Поддержка для EVM-совместимых монет также находится в разработке и появится в ближайшее время.

Хочу показать логи примера работы tpu v2 на стороне тэйкера для пар:

MARTY <-> SEPOLIA
SEPOLIA <-> MARTY

MARTY — это UTXO-монета. SEPOLIA — это монета EVM-совместимой сети.

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

Хочу дать пару вводных вопросов на подумать:

Кто первым инициирует своп: мейкер или тейкер?
Отправляется ли DEX fee отдельной транзакцией?

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

Итак MARTY/SEPOLIA

· 2024-12-04 12:57:15 +0700 [] lp_ordermatch:3255] Entering the taker_swap_loop MARTY/SEPOLIA with uuid: 26bbcbbb-9d5b-42e0-ba7d-775220dd3be1
04 05:57:17, mm2_main::lp_swap::taker_swap_v2:991] INFO Taker swap 26bbcbbb-9d5b-42e0-ba7d-775220dd3be1 has successfully started
04 05:57:19, coins::eth:2795] INFO get_gas_price…
04 05:57:21, coins::eth:2767] INFO get_addr_nonce…
04 05:57:21, coins::eth:2805] INFO send_raw_transaction…
04 05:57:22, coins::eth:2812] INFO wait_for_tx_appears_on_rpc…
04 05:57:26, mm2_main::lp_swap::taker_swap_v2:1257] INFO Sent taker funding SEPOLIA tx c32dff86aaf180a9ff56bbe682293a6cf4def88bc0d9803c6802b1dc106065e1 during swap 26bbcbbb-9d5b-42e0-ba7d-775220dd3be1
04 05:57:27, coins::utxo::rpc_clients:130] INFO Waiting for tx 9bbe8789bda3fc0870648b1264a16eda0189c8c52f1a9a42e047c5621a2e7e82 confirmations, now 0, required 1, requires_notarization false
04 05:57:37, coins::utxo::rpc_clients:130] INFO Waiting for tx 9bbe8789bda3fc0870648b1264a16eda0189c8c52f1a9a42e047c5621a2e7e82 confirmations, now 0, required 1, requires_notarization false
04 05:57:48, coins::eth:2795] INFO get_gas_price…
04 05:57:49, coins::eth:2767] INFO get_addr_nonce…
04 05:57:50, coins::eth:2805] INFO send_raw_transaction…
04 05:57:51, coins::eth:2812] INFO wait_for_tx_appears_on_rpc…
04 05:57:56, mm2_main::lp_swap::taker_swap_v2:2023] INFO Sent taker funding spend (taker payment spend) SEPOLIA tx 1ed29e7cd56092647a57e1b7fcc80b7bb2933b17a6c4f268a1df18f1a79f3340 during swap 26bbcbbb-9d5b-42e0-ba7d-775220dd3be1
04 05:58:15, mm2_main::lp_swap::taker_swap_v2:1717] INFO Found taker payment spend SEPOLIA tx 9b234933d8b0f720f233689eae28ca274907a50820e320f116bd9f417d934e40 during swap 26bbcbbb-9d5b-42e0-ba7d-775220dd3be1
04 05:58:15, mm2_main::lp_swap::taker_swap_v2:2119] INFO Spent maker payment MARTY tx a8005fc205fd6e374bb6b70eee47bfad16cea2b1b03c8f2225f2c95b888505f9 during swap 26bbcbbb-9d5b-42e0-ba7d-775220dd3be1
04 05:58:15, coins::utxo::rpc_clients:130] INFO Waiting for tx a8005fc205fd6e374bb6b70eee47bfad16cea2b1b03c8f2225f2c95b888505f9 confirmations, now 0, required 1, requires_notarization false
04 05:58:26, coins::utxo::rpc_clients:130] INFO Waiting for tx a8005fc205fd6e374bb6b70eee47bfad16cea2b1b03c8f2225f2c95b888505f9 confirmations, now 0, required 1, requires_notarization false
04 05:58:36, mm2_main::lp_swap::taker_swap_v2:2355] INFO Swap 26bbcbbb-9d5b-42e0-ba7d-775220dd3be1 has been completed

SEPOLIA/MARTY

· 2024-12-04 13:23:11 +0700 [] lp_ordermatch:3255] Entering the taker_swap_loop SEPOLIA/MARTY with uuid: 9a56a3e8-a54a-49b8-a65d-86593e77d504
04 06:23:14, mm2_main::lp_swap::taker_swap_v2:991] INFO Taker swap 9a56a3e8-a54a-49b8-a65d-86593e77d504 has successfully started
04 06:23:16, mm2_main::lp_swap::taker_swap_v2:1257] INFO Sent taker funding MARTY tx 9ff980cfa9574d9280ee9fc1f686ad4b60f5f5ad851bfa2314de14eacee59f62 during swap 9a56a3e8-a54a-49b8-a65d-86593e77d504
+--- 04 06:23:24 -------
| (0:00/43:06) [SEPOLIA] Waiting for confirmations…
· 2024-12-04 13:23:47 +0700 [SEPOLIA] Waiting for confirmations… Confirmed.
04 06:23:47, mm2_main::lp_swap::taker_swap_v2:2023] INFO Sent taker funding spend (taker payment spend) MARTY tx 8501c52432a4f9cd27090841357ded67c6a948f01c1b67bd2ca4b0935a2496d0 during swap 9a56a3e8-a54a-49b8-a65d-86593e77d504
04 06:24:18, mm2_main::lp_swap::taker_swap_v2:1717] INFO Found taker payment spend MARTY tx c3ac45d45cac571068a6237bc8d976195713949b424a95914ba3d2d7d5f04461 during swap 9a56a3e8-a54a-49b8-a65d-86593e77d504
04 06:24:18, coins::eth:2795] INFO get_gas_price…
04 06:24:19, coins::eth:2767] INFO get_addr_nonce…
04 06:24:20, coins::eth:2805] INFO send_raw_transaction…
04 06:24:21, coins::eth:2812] INFO wait_for_tx_appears_on_rpc…
04 06:24:24, mm2_main::lp_swap::taker_swap_v2:2119] INFO Spent maker payment SEPOLIA tx 0bfb6a18f699e12b3063641a64565f53134798610d46b32f9fb63d390630611b during swap 9a56a3e8-a54a-49b8-a65d-86593e77d504
+--- 04 06:24:25 -------
| (0:00/518:46) [SEPOLIA] Waiting for confirmations…
+--- 04 06:24:48 -------
| (0:23/518:46) [SEPOLIA] Waiting for confirmations…
· 2024-12-04 13:24:58 +0700 [SEPOLIA] Waiting for confirmations… Confirmed.
04 06:24:58, mm2_main::lp_swap::taker_swap_v2:2355] INFO Swap 9a56a3e8-a54a-49b8-a65d-86593e77d504 has been complete

What Are Atomic Swaps?

Laruh Development Presents — Fri, 16 Aug 2024 16:19:58 +0000

Definition

An atomic swap is a cryptocurrency trade that occurs directly between two users, without any intermediaries. These swaps are described as "atomic" because the trade either fully completes—where both parties receive the agreed assets—or fails entirely, with each party retaining their original funds.

Atomic swaps are executed wallet-to-wallet in a fully peer-to-peer (P2P) manner, ensuring that both traders maintain control of their private keys throughout the entire process, making the exchange significantly more secure than trading on centralized platforms.

Introduction to Participants

In an atomic swap, there are two main participants: the Maker (liquidity provider) and the Taker (liquidity receiver). The Maker holds one type of cryptocurrency, while the Taker holds another. The atomic swap process enables them to securely exchange these assets in a decentralized manner without relying on intermediaries.

Step-by-Step Process

Step 0: Market Maker Posts Trade Order
Before the swap begins, the Maker posts a trade order on the platform. This step, although not technically part of the atomic swap process, is essential for initiating the swap.

Step 1: Taker Initiates the Swap
The atomic swap process begins when the Taker sees the Maker’s offer and accepts it. The Taker pays a protocol fee known as the DEX fee. This fee ensures that the Taker is serious about the trade and prevents spamming of the network. Once the DEX fee is paid, the atomic swap officially starts.

Step 2: Maker Sends Payment (Maker Payment)
The Maker then generates a 32-byte secret and creates a hash of this secret. This hash is shared with the Taker, but the secret itself remains unknown to the Taker. The Maker sends the Maker Payment to a secure, temporary holding address. The nature of this address depends on the type of blockchain:

For UTXO-based blockchains (like Bitcoin): The payment is sent to a P2SH (Pay-to-Script-Hash) address. This address is both hash-locked and time-locked.
For ETH/ERC20 blockchains: The payment is sent to an etomic-swap smart contract that similarly locks the payment.

The Maker Payment is time-locked to ensure that if the swap is not completed within a set time frame (e.g., 4 hours and 20 minutes for Bitcoin), the Maker can reclaim their funds.

Step 3: Taker Sends Payment (Taker Payment)
After seeing that the Maker has sent the Maker Payment, the Taker sends their payment to a similar secure, temporary holding address. The Taker Payment is also hash-locked using the same hash provided by the Maker and time-locked, but with a shorter duration (typically half of the Maker’s time lock).

For UTXO-based blockchains: The Taker Payment is sent to a P2SH hash/time locked output.
For ETH/ERC20 blockchains: The Taker Payment is sent to an etomic-swap smart contract.

This step ensures that if the Maker does not proceed with the next step, the Taker can reclaim their funds once the shorter time lock expires.

Step 4: Maker Claims Taker Payment
The Maker sees that the Taker has sent the Taker Payment. To claim it, the Maker reveals the 32-byte secret, which is then broadcast to the blockchain network. This action allows the Maker to unlock and transfer the Taker Payment to their own address. Once the secret is revealed, it becomes publicly visible.

Step 5: Taker Claims Maker Payment
Finally, the Taker, having observed that the Maker has revealed the secret by claiming the Taker Payment, uses the same secret to unlock the Maker Payment. The Taker then transfers the Maker Payment to their own address, completing the swap.

Summary

This atomic swap process ensures a secure and trustless exchange of assets between the Maker and the Taker. The use of cryptographic mechanisms such as hash locks and time locks (HTLC protocol) guarantees that the swap will either be completed as agreed, or both parties will retain their original assets if the swap fails. The process operates in a decentralized manner, with no intermediaries involved, making it a highly secure method for peer-to-peer cryptocurrency exchanges.

ru version

Что такое атомарные свопы?

Laruh Development Presents — Fri, 16 Aug 2024 16:14:22 +0000

Атомарный своп (Atomic Swap) — это прямой обмен криптовалютой между двумя пользователями без участия посредников. Такие свопы называются "атомарными" потому, что сделка либо полностью завершается, и обе стороны получают согласованные активы, либо не происходит вовсе, и каждая сторона сохраняет свои первоначальные средства.

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

Кто участвует?

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

А вот теперь разберем пример выполнения Атомарного протокола

Шаг 0: Размещение торгового ордера Maker-ом

Перед началом свопа Maker размещает торговый ордер на платформе. Этот шаг, хотя и не является частью самого процесса атомарного свопа, необходим для его инициирования.

Шаг 1: Инициация свопа Taker-ом

Процесс атомарного свопа начинается, когда Taker видит предложение от Maker-а и решает его принять. Taker оплачивает протокольный сбор, известный как DEX fee. Этот сбор гарантирует, что Taker серьезно относится к сделке и предотвращает спам в сети. После оплаты DEX fee процесс атомарного свопа официально начинается.

Шаг 2: Отправка платежа Maker-ом (Maker Payment)

Затем Maker генерирует 32-байтный секрет и создает его хеш. Этот хеш передается Taker-у, однако сам секрет остается неизвестным для Taker-а. Maker отправляет свой платеж (Maker Payment) на безопасный временный адрес хранения. Тип этого адреса зависит от типа блокчейна:

Для блокчейнов на основе UTXO (например, Bitcoin): Платеж отправляется на адрес P2SH (Pay-to-Script-Hash). Этот адрес защищен хешем и имеет временную блокировку.
Для блокчейнов ETH/ERC20: Платеж отправляется на etomic-swap смарт-контракт, который аналогично блокирует платеж.

Платеж Maker-а имеет временную блокировку, которая гарантирует, что если своп не будет завершен в течение определенного периода времени (например, 4 часа и 20 минут для Bitcoin), Maker сможет вернуть свои средства.

Шаг 3: Отправка платежа Taker-ом (Taker Payment)

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

Для блокчейнов на основе UTXO: Платеж Taker-а отправляется на P2SH адрес с временной блокировкой.
Для блокчейнов ETH/ERC20: Платеж Taker-а отправляется на etomic-swap смарт-контракт.

Этот шаг гарантирует, что если Maker не продолжит своп, Taker сможет вернуть свои средства после истечения короткого времени блокировки.

Шаг 4: Присвоение платежа Taker-а Maker-ом

Maker видит, что Taker отправил Taker Payment. Чтобы получить его, Maker раскрывает 32-байтный секрет, который затем передается в сеть блокчейна. Это действие позволяет Maker-у разблокировать и перевести Taker Payment на свой адрес. После раскрытия секрет становится общедоступным.

Шаг 5: Присвоение платежа Maker-а Taker-ом

Наконец, Taker, заметив, что Maker раскрыл секрет (revealed the secret), чтобы получить Taker Payment, использует этот же секрет для разблокировки Maker Payment. Затем Taker переводит Maker Payment на свой адрес, завершая своп.

Этот пример протокола атомарного свопа обеспечивает безопасный и децентрализованный обмен активами между Maker-ом и Taker-ом. Использование криптографических механизмов, таких как hash lock и time lock (HTLC protocol), гарантирует, что либо своп будет завершен в соответствии с договоренностью, либо обе стороны сохранят свои исходные активы. Процесс полностью децентрализован и не требует участия посредников, что делает его безопасным методом для одноранговых обменов криптовалют.

eng version