Stellar: SCP consensus, anchors, assets и path payments

Stellar часто описывают как «сеть дешёвых переводов», но эта формула скрывает почти всю архитектуру. Consensus здесь не Proof of Work и не Proof of Stake: Stellar Consensus Protocol строится на Federated Byzantine Agreement, где каждый validator выбирает собственный quorum set и threshold. Платёжные assets существуют как комбинация asset code + issuer, пользователи явно создают trustlines, anchors соединяют blockchain с банками и cash rails, а path payment умеет в одной атомарной операции поменять один asset на другой через встроенную liquidity. XLM связывает всё это fees, account reserves и native settlement utility.

Stellar — payment network, где consensus и asset layer разделены

Stellar Core validators согласуют ledger state, но не определяют, какие внешние валюты «настоящие». Issuer создаёт asset, account решает доверять ему через trustline, а anchor обеспечивает off-chain deposit и withdrawal.

Это важное разделение responsibilities. Consensus отвечает за то, что все nodes применили один и тот же набор операций. Issuer отвечает за обязательство своего token. Anchor отвечает за вход/выход между blockchain и banking/payment rails. Wallet отвечает за identity, trustline и user authorization.

XLM — единственный asset без issuer и trustline

Native lumen не имеет issuer account и не требует ChangeTrust operation. Все обычные Stellar assets вроде USD token определяются code и issuer public key.

Asset code сам по себе не идентифицирует деньги

Два разных issuers могут выпустить asset с code USD. Это два разных assets, даже если wallet показывает одинаковый ticker.

Payment UX скрывает несколько независимых trust boundaries

Пользователь видит «получить 100 USD», но инженер должен спросить: какой issuer, есть ли trustline, какой anchor конвертирует fiat, какой path payment используется и какой ledger подтвердил transaction.

SCP: quorum sets и quorum slices вместо mining или stake weight

Stellar Consensus Protocol — implementation Federated Byzantine Agreement. Core node сам выбирает, какие другие validators считает достаточными для достижения agreement. Этот набор называется **quorum set**.

Node также задаёт threshold — сколько участников или nested sets должны согласиться. Конкретная комбинация trusted nodes, достаточная для этого node, называется **quorum slice**.

Quorum не является фиксированным committee из protocol constant

Сеть не хранит один всем навязанный список validator keys. Каждый operator конфигурирует trust relationships самостоятельно. Global safety возникает, когда quorum sets разных nodes достаточно хорошо пересекаются.

Quorum intersection — центральное security property

Если сеть распадётся на две независимые группы validators, каждая из которых способна сформировать quorum без другой, появляется риск safety failure. Поэтому topology quorum sets имеет не меньшее значение, чем количество validators.

Node blocking set влияет на liveness

Если threshold требует 3 из 4 trusted nodes, отказ двух может заблокировать progress конкретного node. SCP сознательно приоритизирует safety и fault tolerance, поэтому при плохой connectivity сеть может остановиться вместо того, чтобы согласовать несовместимые ledgers.

В SCP вопрос «сколько у атакующего stake?» заменяется вопросом «какие validators входят в quorum slices и насколько их trust graph пересекается у независимых operators».

Validators не получают protocol monetary reward

Current Stellar Docs прямо указывает: monetary rewards за validator role нет. Organizations запускают validators ради security и resilience инфраструктуры, от которой зависят их services.

Assets и trustlines: consent встроен в ledger model

Stellar asset обычно идентифицируется **asset code + issuer public key**. Issuer account может выпускать asset, а holder account должен иметь trustline, чтобы его держать, если это не native XLM.

Trustline создаётся ChangeTrust operation и хранится как отдельная ledger entry.

Trustline — не просто запись «я доверяю бренду»

Это explicit ledger object с asset identity, balance limit и authorization state. Account без trustline обычно не может получить соответствующий issued asset.

Trustline потребляет reserve

Current Stellar base reserve — **0.5 XLM**. Обычный account должен держать минимум две base reserves, то есть **1 XLM**. Каждая дополнительная subentry, включая обычную trustline, увеличивает minimum balance ещё на одну base reserve — сейчас 0.5 XLM.

Sponsored reserves позволяют другому account взять этот reserve burden на себя, что важно для wallet onboarding.

Issuer controls могут ограничивать transferability

Issuer может использовать authorization flags, clawback-related controls и другие protocol features в зависимости от asset design. Поэтому self-custody private key не всегда означает отсутствие issuer policy.

Trustline limit ограничивает balance

Holder может задать maximum amount для asset. Incoming payment, который превысит limit, fail-ится вместо silent overflow.

Anchors соединяют Stellar ledger с fiat и внешними payment rails

Anchor — organization, которая принимает external asset или fiat и выдаёт corresponding Stellar asset, либо делает обратный withdrawal. В modern docs их также называют ramps.

Классический пример: пользователь отправляет деньги банковским transfer anchor-у, anchor проходит required compliance process и после получения funds отправляет issued asset на Stellar account пользователя.

SEP standards уменьшают integration fragmentation

Stellar Ecosystem Proposals задают interoperable contracts между wallet и anchor. Часто встречаются:

• **SEP-1** — discovery через stellar.toml;
• **SEP-10** — web authentication;
• **SEP-24** — interactive deposit/withdraw flow;
• **SEP-6** — programmatic deposit/withdraw API;
• **SEP-31** — cross-border payments;
• **SEP-38** — quotes и exchange information.

KYC может происходить вне wallet UI

SEP-24 позволяет wallet открыть interactive flow anchor-а. User identity data может обрабатываться anchor-ом напрямую, а wallet получает status и transaction metadata.

Anchor risk не является SCP risk

Если конкретный fiat issuer перестал redeem asset, Stellar consensus может продолжать закрывать ledgers совершенно нормально. Token solvency и network consensus — отдельные failure domains.

Один ticker может иметь несколько anchors

Разные anchors могут выпускать свои USD assets. Path payment и exchange liquidity способны связать их экономически, но issuer obligations остаются разными.

Path Payments: payment и exchange могут быть одной atomic operation

Одна из наиболее характерных функций Stellar — path payment. Sender может потратить один asset, receiver получить другой, а network использует offers в Stellar DEX и/или liquidity pools для conversion path.

Strict Send фиксирует amount отправителя

Path Payment Strict Send задаёт точное количество send asset. Destination amount меняется в зависимости от найденного route и available liquidity. destMin защищает sender от слишком плохого exchange result.

Strict Receive фиксирует amount получателя

Path Payment Strict Receive задаёт точный amount destination asset. Source amount меняется, а sendMax ограничивает maximum spend.

Settlement происходит атомарно

Intermediate conversions и final payment входят в одну operation. Если acceptable path не существует или price protection нарушена, operation fail-ится целиком вместо частичного исполнения.

Receiver всё равно должен уметь держать destination asset

Если destination asset не XLM, recipient обычно требует соответствующую trustline. Exchange route не обходит ledger authorization model.

Pathfinding не гарантирует хороший рынок

Механизм может найти route, но shallow order book или liquidity pool даст плохую цену. Wallet обязан показывать quote, slippage boundary и asset issuer, а не только зелёную кнопку Send.

XLM: fees, reserves и native network utility

Lumen нужен не потому, что каждый payment обязан быть номинирован в XLM. Он оплачивает transaction fees, account/subentry reserves и smart-contract resource/rent-related costs.

Minimum balance защищает ledger от дешёвого state spam

Base reserve сейчас 0.5 XLM. Account baseline — две reserves = 1 XLM. Trustlines, offers, signers и data entries добавляют subentries и увеличивают reserve requirement.

Закрытие subentry возвращает соответствующую reserve amount в available balance. Sponsored reserves позволяют product provider оплатить reserve behalf user-а.

Minimum inclusion fee — 100 stroops per operation

Один stroop = 0.0000001 XLM. Network minimum для обычной operation сейчас **100 stroops = 0.00001 XLM**. Transaction с несколькими operations платит inclusion fee по числу operations.

При surge pricing effective fee может стать выше, если demand превышает configured ledger capacity.

Validator не получает эти fees как block reward

Fees собираются в protocol fee pool; Stellar validators не получают mining/staking rewards. Поэтому XLM fee utility и validator incentive model нужно рассматривать отдельно.

Soroban добавляет resource fee/rent model

Smart-contract transactions используют inclusion fee плюс resource costs за computation, IO и ledger state. Это отдельная economics layer поверх классических payment operations.

Ledger и explorer: Stellar transaction содержит несколько operations

Stellar transaction — envelope, который может содержать несколько operations. Все operations применяются atomically: failure одной может сделать всю transaction unsuccessful в зависимости от semantics.

Ledger close фиксирует agreed transaction set после SCP round. New ledger криптографически ссылается на previous ledger.

Sequence number защищает account ordering

Source account transaction использует sequence number. Повторное использование или stale sequence приводит к failure, что предотвращает replay обычного account-authorized transaction.

Memo важен для pooled custody flows

Exchange может использовать один Stellar deposit account и различать клиентов memo. Отправить asset на правильный public key без required memo иногда означает manual recovery у custodian.

Explorer должен показывать operations, а не только один payment label

Transaction может содержать ChangeTrust, ManageSellOffer, PathPayment, Payment и другие operations. Для debugging нужно раскрывать весь operation list.

Close time — consensus field, а не атомные часы

Docs отмечает, что close time зависит от system clock proposing validator и может немного отличаться от wall-clock. Ledger sequence/hash надёжнее использовать как ordering identity, чем считать timestamp идеальной measure latency.

Failure modes: быстрый payment path состоит из нескольких систем

Stellar payment stack способен быть быстрым и дешёвым, но end-to-end transfer может зависеть от компонентов вне Core consensus.

• **SCP/quorum risk:** плохая quorum topology или недоступные validators могут остановить progress.
• **Issuer risk:** issued asset зависит от issuer policy и reserves.
• **Anchor risk:** deposit/withdrawal зависит от banking rails, compliance и operational availability.
• **Liquidity risk:** path payment может fail или получить плохой quote.
• **Trustline risk:** receiver не authorizes asset или достиг balance limit.
• **Custody/memo risk:** exchange deposit требует правильный memo.
• **Reserve risk:** account не хватает XLM для новой subentry.

Network success не означает fiat settlement success

On-chain asset может прийти за несколько секунд, а withdrawal через bank занять гораздо дольше. Это не contradiction: blockchain transfer и off-chain settlement — разные systems.

Atomic path payment уменьшает partial-execution risk

Если route перестал удовлетворять sendMax/destMin, operation fail-ится вместо того, чтобы оставить пользователя с intermediate asset.

Issuer identity нужно проверять так же строго, как contract address в EVM

Asset code USD недостаточен. Wallet должен показывать issuer domain/public key и использовать verified metadata.

Stellar и XRP Ledger: похожий payment intent, разная consensus/asset architecture

Stellar и XRP Ledger часто ставят рядом, потому что обе сети ориентированы на payments, issued assets, встроенную exchange/pathfinding functionality и быстрый final settlement без Proof of Work mining.

Но implementation details различаются.

Stellar формализует FBA через quorum sets и slices

Каждый Stellar Core node конфигурирует quorum set и threshold. Network safety зависит от quorum intersection across operators.

XRPL consensus также использует trusted validator relationships и не основан на stake weight, но validator selection/trust configuration и consensus rounds реализованы своей protocol model. Нельзя считать SCP и XRPL Consensus одним алгоритмом только из-за похожего product goal.

Trustline semantics похожи по назначению, но assets имеют разную ledger identity

Обе systems используют issuer relationships для non-native assets. В Stellar canonical asset identity — code + issuer, а trustline явно создаётся ChangeTrust operation.

Path payment в Stellar является first-class operation

Stellar Strict Send/Strict Receive явно соединяет payment с DEX/liquidity route. XRPL тоже имеет pathfinding/autobridging concepts, но transaction types и liquidity semantics другие.

Главный вывод

Stellar — это не просто дешёвая chain для XLM transfer. Это **payment graph**, где SCP согласует ledger, issuers создают assets, trustlines задают holder consent, anchors соединяют fiat rails, а path payments используют liquidity, чтобы sender и receiver могли работать с разными assets.

Для инженера ключевой вопрос звучит так: **какой issuer создаёт asset, доверяет ли ему receiver, какой route конвертирует value, где находится anchor risk и какие quorum relationships обеспечивают settlement ledger.**

FAQ

Stellar использует Proof of Stake?

Нет. SCP основан на Federated Byzantine Agreement. Validators выбирают quorum sets и thresholds; stake XLM не определяет voting weight consensus-а.

Нужна ли trustline для XLM?

Нет. XLM — native asset Stellar и не имеет issuer. Trustlines нужны для обычных issued assets.

Сколько XLM нужно обычному account?

Current base reserve составляет 0.5 XLM. Baseline account требует две base reserves, то есть 1 XLM, если reserve не sponsored. Subentries вроде trustline увеличивают requirement.

Что делает anchor?

Anchor/ramp соединяет Stellar asset с внешними money rails: принимает deposit, выпускает/передаёт corresponding asset и обрабатывает withdrawal согласно KYC, banking и issuer rules.

Чем Strict Send отличается от Strict Receive?

Strict Send фиксирует source amount и ограничивает minimum destination result через destMin. Strict Receive фиксирует destination amount и ограничивает maximum source spend через sendMax.

Получают ли Stellar validators награды в XLM?

Нет. Current Stellar Docs прямо говорит, что protocol monetary reward за validator role отсутствует.

Материал носит образовательный характер и не является финансовой рекомендацией или гарантией issuer/anchor liquidity.