Прозорість у ланцюжку: що дані блокчейну можуть і не можуть підтвердити

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

Transparency is useful only when we separate on-chain facts, interpretations, and information that exists outside the blockchain.

Ця стаття має виключно освітню мету. Публічні ончейн-дані не гарантують безпечність, доброчесність або дохідність проєкту.

Що означає «ончейн»

Ончейн-дані записуються в історії блокчейну або його поточному стані й можуть бути отримані з вузла мережі. У BNB Smart Chain до них належать:

• хеш, статус, блок і часова позначка транзакції;
• адреси відправника та одержувача;
• переказаний нативний BNB і сплачений gas;
• дані виклику контракту;
• події, або logs, створені під час виконання;
• розгорнутий байткод;
• публічно доступний для читання стан контракту;
• баланси нативного активу й токенів;
• історія транзакцій і переказів.

Addresses are normally pseudonymous. A string beginning with 0x does not, by itself, reveal the legal identity of its controller.

П’ять запитань, на які допомагають відповісти ончейн-дані

1. Чи відбулася конкретна транзакція?

Хеш транзакції дає змогу перевірити, чи включено транзакцію, чи була вона успішною, яка адреса її ініціювала, яку адресу викликано та які журнали створено.

This is stronger evidence than a screenshot. But Успіх confirms technical execution, not the truth of a marketing claim or the economic value of the result.

2. Які активи зараз перебувають на адресі?

An explorer can show native BNB and balances of specific BEP-20 tokens. A standard token balance can also be queried with balanceOf(address).

Видимий баланс не є автоматично «резервом» проєкту. Перш ніж так стверджувати, потрібно встановити, що:

• адреса належить проєкту або контролюється ним;
• усі відповідні адреси розкрито;
• активи вже не обтяжені іншими зобов’язаннями;
• токени мають достатню доступну ліквідність;
• повноваження щодо виведення активів та адміністрування зрозумілі.

3. Як переміщувалися кошти?

Транзакції, події переказу токенів і внутрішні виклики дають змогу простежити переміщення між адресами. Їх можна зіставити з опублікованим процесом платформи.

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

4. Який код було розгорнуто?

Deployed bytecode is always public. If source code has been verified, BscScan can match it to the bytecode and expose Прочитайте договір і Написати договір interfaces.

Верифікація вихідного коду полегшує його перевірку. Вона не є аудитом: верифікований код усе ще може містити помилки або навмисно потужні функції.

5. Хто може змінювати параметри?

Вихідний код і функції читання можуть показувати такі ролі, як owner, admin, operator, pauser або upgrader. Перевірте, чи можуть ці ролі:

• призупиняти операції;
• змінювати комісії або ліміти;
• карбувати токени;
• переказувати активи;
• змінювати implementation proxy;
• надавати нові ролі.

Наявність адміністративної ролі не доводить зловживання. Це залежність від довіри, яку користувачі повинні розуміти.

Що залишається офчейн

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

• особа та правовий статус команди;
• офчейн-договори або зобов’язання;
• якість підтримки користувачів;
• безпека вебсайтів, DNS, серверів або пристроїв команди;
• правдивість маркетингових матеріалів;
• джерело та надійність ціни зовнішнього токена;
• право власності на активи реального світу;
• майбутні рішення адміністраторів;
• дотримання законодавства в юрисдикції користувача.

Частина інформації в блокчейн-оглядачі також є офчейн: назви, логотипи, вебсайти, позначки власників і цінові графіки можуть надходити з поданих метаданих або від зовнішніх постачальників. Сам BscScan зазначає, що сторінки токенів містять і ончейн-, і офчейн-інформацію. Критичні перевірки мають ґрунтуватися на повних адресах і первинних записах, а не на візуальному брендингу.

Спостереження, інтерпретація та припущення

Розрізняйте ці рівні:

Observation:
“In block N, address A sent 100 units of token T to address B.”

Interpretation:
“According to the published architecture, B is the distribution contract.”

Assumption:
“Therefore every participant will certainly receive a future payment.”

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

Практична перевірка прозорості

Крок 1: установіть точні адреси

З офіційної документації випишіть мережу та адреси:

• основний контракт;
• контракти proxy та implementation, якщо вони використовуються;
• відповідний токен;
• казначейство та допоміжні компоненти, якщо їх розкрито.

Зберігайте повні адреси. Назв і скорочених рядків недостатньо.

Крок 2: перевірте код

On BscScan’s Договір tab:

• зафіксувати тип верифікації;
• перевірити, чи є контракт proxy;
• перейти до поточної implementation;
• визначити ролі та функції зміни параметрів;
• зафіксувати інформацію про компілятор і розгортання.

Якщо вихідний код не верифіковано, звичайному користувачеві значно складніше перевірити поведінку контракту.

Крок 3: прочитайте поточний стан

використання Прочитайте договір for read-only queries such as:

• адреси owner і ролей;
• статус паузи;
• поточні комісії та ліміти;
• лічильники та статуси циклів;
• адреси пов’язаних контрактів.

Читання не потребує підпису або gas. Для перегляду публічного стану підключати гаманець не потрібно.

Крок 4: порівняйте кілька транзакцій

Для різних сценаріїв перевірте:

• викликана функція та параметри;
• переміщення токенів;
• внутрішні виклики;
• журнали;
• стан до та після.

Одна транзакція демонструє один шлях виконання, а не всі можливі варіанти поведінки.

Крок 5: перегляньте історію змін

Шукайте адміністративні транзакції та події, пов’язані з:

• передавання права власності;
• надання та відкликання ролей;
• паузи;
• оновлення implementation;
• зміни параметрів;
• виведення активів.

Поточна конфігурація має значення, а історія показує, як повноваження фактично використовувалися.

Поширені помилки

“The address is public, so its owner is known.”
No. Ownership requires separate evidence.

“Funds are visible in a contract, so they are permanently locked.”
No. Code or an administrator may allow them to move.

“The source is verified, so the contract is safe.”
No. Verification matches source to bytecode; it does not assess security.

“An event is named RewardPaid, so returns are guaranteed.”
No. Developers choose event names. Verify actual state and asset movements.

“Transparency removes risk.”
No. It makes some risks observable while technical, administrative, market, and legal risks remain.

Контрольний список

• Точну мережу та адреси опубліковано.
• Тип верифікації вихідного коду відомий.
• Proxy та поточну implementation перевірено.
• Повноваження owner, admin та upgrader зрозумілі.
• Баланси перевіряють за точними адресами токенів.
• Історія транзакцій відповідає опублікованому процесу.
• Ончейн-факти відокремлено від позначень та інтерпретації.
• Запитання, на які блокчейн не може відповісти, наведено окремо.

Джерела та додаткові матеріали

1. BscScan Information Center — Перегляд транзакцій
2. BscScan Information Center — Як читати сторінку токена
3. BscScan Information Center — Типи верифікації контрактів
4. BscScan Information Center — Що таке адреса?
5. Solidity Documentation — Питання безпеки
6. OpenZeppelin Docs — Шаблон оновлення Proxy