Помилки транзакцій Solana: прострочений blockhash і транзакції без включення

2026-08-24

Одну транзакцію Solana можна водночас описувати на кількох рівнях. Повідомлення описує запропоновані інструкції та їхній контекст, підписана транзакція містить авторизацію для цього повідомлення, відповідь RPC повідомляє, що прийняв або спостерігав один сервіс, а запис кластера є свідченням на вказаному рівні commitment. Ці рівні можуть породжувати різні формулювання стану, не суперечачи одне одному. Тому читання повідомлення про закінчення строку чи невключену транзакцію починається з визначення рівня, який його створив. Локальний тайм-аут, помилка RPC, відповідь про стан і фіналізований запис описують різні точки шляху надсилання, а не один універсальний висновок про результуючий стан.

Схема станів транзакції Solana від повідомлення до зафіксованого результату

Стан транзакції та шлях надсилання

Транзакція Solana містить інструкції, підписи облікових записів, що авторизують зміни, і recent blockhash. Під час обробки мережа розглядає її інструкції як єдине атомарне ціле: збій будь-якої інструкції не дозволяє спільно зафіксувати передбачені зміни стану. До появи такого результату транзакція може проходити окремі етапи формування повідомлення, підписання, передавання вузлу RPC, отримання учасниками мережі, обробки та спостереження на рівні commitment. Позначка стану має зміст лише тоді, коли зрозумілий її етап.

Метод RPC sendTransaction повідомляє перший підпис транзакції, коли служба RPC приймає підписане корисне навантаження для ретрансляції. Офіційна документація прямо відокремлює це негайне прийняття від обробки або підтвердження кластером. У звичайній мові dropped transaction часто означає відсутність пізнішого запису кластера після ранньої події, пов'язаної з надсиланням. Це не єдиний консенсусний стан з однією сталою причиною. Вислів може вживати клієнт, служба RPC або спостерігач, і кожен із них може мати на увазі інший відсутній перехід на шляху.

Роль blockhash

Recent blockhash у повідомленні транзакції є наданим мережею посиланням на свіжість. Метод getLatestBlockhash повертає і blockhash, і lastValidBlockHeight, пов'язуючи це посилання з межею висоти, а не з гарантованою тривалістю за настінним годинником. Це дає протоколу змогу оцінювати, чи транзакція з таким посиланням усе ще перебуває у вікні обробки. Blockhash є частиною оцінюваного повідомлення, тому він належить до ідентичності транзакції та контексту перевірки, а не до пізнішого відображення в оглядачі.

Висота блока, просування слотів і минулий час пов'язані, але їх не слід вважати взаємозамінними годинниками. Точний параметр віку обробки, кількість слотів, описана в документації, і час, який представляють ці слоти, залежать від відповідної версії протоколу та програмного забезпечення, а також від умов мережі. Тому recent blockhash найкраще розуміти як залежне від версії вікно чинності. Стійким фактом є наявність межі; точна тривалість не є універсальною обіцянкою.

Прострочений і не знайдений — різні поняття

Прострочення описує результат чинності: recent blockhash більше не придатний для обробки транзакції за застосовними правилами. Це стосується обмеженого в часі посилання транзакції, а не є загальною позначкою для кожної невдалої ретрансляції чи відсутнього запису. Коли люди використовують пошукову фразу solana transaction expired, вони часто називають видимий у клієнті результат, що відповідає цій межі життєвого циклу. Сама фраза не визначає, що отримав конкретний вузол RPC, і не описує окремий результат переказу.

Blockhash not found solana — це пошукова фраза, яка часто поєднує рядок інтерфейсу з назвою мережі. Справжнє повідомлення blockhash-not-found може означати, що вузол у своєму поточному баченні та на відповідному рівні commitment не може розв'язати зазначений хеш для належного контексту перевірки. Таке спостереження не є автоматично доказом того, що остання дійсна висота минула всюди. Стан вузла, commitment, версія API, момент часу та формулювання клієнта можуть змінювати подання однієї широкої умови, тож ці дві фрази не слід зводити до одного незмінного діагнозу.

Підписана, але не включена до блока

Підпис є авторизацією для конкретного повідомлення; він не є записом про те, що повідомлення досягло блока. Так само прийняття корисного навантаження службою RPC для ретрансляції не є записом про його обробку кластером. Отже, підписану транзакцію можна описувати як підписану, але вона все одно може не мати обробленого, підтвердженого або фіналізованого спостереження. Сам цей розрив не показує, чи навантаження ніколи не було отримане значущим учасником, не зберігалося у видимій області стану або стало недійсним до обробки.

Методи стану JSON-RPC явно показують межі спостереження. getSignatureStatuses повертає поточні стани для наданих підписів, а його стандартний пошук обмежений недавнім кешем станів, якщо не включено пошук історії транзакцій. getTransaction повертає підтверджену транзакцію за підписом або null, коли її не знайдено чи не підтверджено на запитуваному рівні commitment. Отже, відповідь null має визначену область, а не є універсальним твердженням, що жодна подія ніколи не існувала у збереженому баченні кожного вузла.

Відмінності між спостереженнями RPC, клієнта та мережі

Клієнтський інтерфейс зазвичай стискає кілька технічних сигналів у коротке речення для людини. Відповідь RPC, навпаки, є звітом конкретного вузла з контекстним слотом, версією API, конфігурацією та запитуваним commitment. Спостереження мережі стосується стану, який відповідний commitment робить видимим. Ці спостереження пов'язані, але не є тим самим об'єктом і не мусять ставати видимими в той самий момент.

Залежність від версії важлива на кожному рівні. Програмне забезпечення вузла Solana, клієнтські бібліотеки, конфігурація RPC, підтримка версій транзакцій, значення commitment за замовчуванням, зберігання станів і формулювання інтерфейсу можуть розвиватися. Тому обґрунтоване тлумачення спочатку визначає спостерігача та область спостереження, а потім надає значення позначці помилки. Воно не припускає, що фраза з одного інтерфейсу є переносним описом кожного вузла, кожного commitment або кожного випуску програмного забезпечення.

Чому повторне надсилання не є універсальною відповіддю

Повторне надсилання не є однією технічною подією. Воно може означати повторну ретрансляцію тих самих підписаних байтів, подання іншого повідомлення або створення пізнішого повідомлення з іншим контекстом перевірки. Ці випадки мають різні ідентифікатори, моменти часу та можливі наслідки для стану. Транзакція, яку мережа вже розглядає, і окрема пізніша транзакція зі схожим наміром не стають взаємозамінними лише через подібність наміру. Повторення може ускладнити тлумачення зв'язку між видимим підписом, записом стану та передбаченою зміною стану.

З тієї самої причини загальна настанова повторити спробу змішала б отримання, поширення, перевірку, виконання та commitment в одне поняття. Формулювання про прострочення саме по собі не встановлює, що пізніше повідомлення має ту саму ідентичність або ефект, що й раніше. В аналітичному сенсі важлива відмінність полягає в тому, чи наявні докази стосуються того самого повідомлення транзакції, окремого повідомлення або лише локальної спроби ретранслювати дані. Предметом статті є ця відмінність, а не процедура надсилання іншої транзакції.

Стійка діагностична лексика та межі ризику

Стійка лексика допомагає не змішувати рівні. Повідомлення називає інструкції, облікові записи, recent blockhash та інші дані, що авторизуються. Підпис ідентифікує підписану транзакцію для API, орієнтованих на стан. Надсилання називає подію ретрансляції RPC, тоді як обробка, підтвердження та фіналізація називають різні рівні спостереження мережі. Commitment — це запитуваний поріг видимості, який використовують методи RPC. Прострочення стосується посилання на свіжість, а dropped зазвичай описує неповний спостережуваний шлях, а не вердикт протоколу з одним стандартизованим значенням.

Межі цих термінів такі ж важливі, як їхні визначення. Технічний стан не встановлює право власності на обліковий запис, намір відправника, баланс активів, поведінку сервісу або засіб усунення відсутнього запису. Він також не перетворює повідомлення клієнта на доказ того, що спостерігав кожен валідатор чи кожна система зберігання даних. Мова станів є свідченням про обмежений шлях обробки і тлумачиться через версію, спостерігача, commitment і час. Збереження цієї межі не дозволяє перетворювати вузький мережевий сигнал на ширше твердження.

Схожі матеріали

Інші матеріали Bitbase на цю тему:

- MEV у Solana та ончейн-атаки

- Kamino у Solana: пояснення

- Комісії та продуктивність Solana

Застереження: Ця стаття є освітнім матеріалом Bitbase Academy і надається лише для інформації. Вона не є інвестиційною, торговою, податковою чи фінансовою порадою. Криптоактиви волатильні — оцінюйте ризики самостійно. Написано станом на серпень 2026 року; орієнтуйтеся на найновішу офіційну інформацію.