Підписування й перевірка повідомлень гаманцем Blocknet

Використовуйте підпис повідомлення Blocknet, щоб підтвердити контроль адреси без здійснення платежу. Посібник спирається на офіційний CLI v1.2.0 і core v0.22.0, перевірені 27 жовтня 2026 року. Ви підготуєте зрозумілий перевірочний запит, підпишете його потрібним гаманцем і перевірите разом повну адресу, повідомлення та підпис.

Як підписати й перевірити повідомлення Blocknet?

Узгодьте значення підписаного повідомлення

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

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

Відкрийте потрібний повний гаманець

Підключіться з термінала до запущеного core основної мережі:

blocknet attach mainnet

В інтерактивній оболонці завантажте гаманець і перевірте адресу:

load
address

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

Розглянутий core підписує повідомлення приватним ключем витрачання гаманця. Гаманець лише для перегляду цього не може. Залиште повний гаманець на призначеному комп’ютері; перевіряльнику потрібні лише отриманий підпис і публічні відомості. Для підписування не потрібно надсилати кошти чи експортувати файл гаманця.

Підготуйте точний текст до підписування

Прочитайте весь запит і переконайтеся, що погоджуєтеся з його метою. Офіційний клієнт читає один рядок, прибирає початкові й кінцеві пробільні символи та відхиляє порожнє повідомлення або текст понад 1024 байти. Межа рахує байти, тому символи поза ASCII можуть займати кілька. Використовуйте короткий однозначний рядок і збережіть точно надісланий текст.

Зберігайте регістр, розділові знаки та внутрішні пробіли під час передавання повідомлення. Редактор чи месенджер може замінити лапки або змінити скопійований текст; якщо перевірка не вдалася, порівняйте фактичне повідомлення. Для входу або операцій з обліковим записом дотримуйтеся формату запиту з документації сервісу. Не переписуйте текст непомітно: перевіряти слід саме виданий запит.

Підпишіть повідомлення в офіційній оболонці

Запустіть введення в інтерактивній оболонці:

sign

Клієнт попросить текст. Вставте узгоджене однорядкове повідомлення та натисніть Enter. У разі успіху буде виведено шістнадцятковий підпис. Скопіюйте весь результат, зберігаючи кожен символ. Реалізація клієнта надсилає повідомлення до методу підписування гаманця; ця операція не створює й не транслює транзакції.

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

Як інша людина перевіряє підпис?

Вона використовує команду перевірки офіційної оболонки із запущеним сумісним core:

verify

Спочатку введіть повну адресу, потім точне повідомлення, далі шістнадцятковий підпис. Довідник оболонки описує цей порядок. Завантажений гаманець не потрібний: можна перевірити докази без імпорту гаманця підписувача й без доступу до приватних ключів.

Розглянутий клієнт показує Signature is VALID, якщо поєднання проходить перевірку, і Signature is INVALID, якщо ні. Помилка формату введення — окремий результат: перевірте всі поля та збережіть початкові докази перед повтором. Якщо повідомлення або адреса відрізняються від очікуваного запиту, з’ясуйте причину навіть за математично дійсного підпису для наданих значень.

Тлумачте успіх у контексті запиту

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

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

Зберігайте зрозумілий запис перевірки

Якщо процес потребує журналу аудиту, зберігайте разом адресу, точний текст, підпис, контекст запиту та результат. Записуйте час перевірки окремо від часової позначки, доданої підписувачем. Уникайте зайвих персональних відомостей: кожен одержувач підписаного тексту може прочитати й скопіювати його. Передавайте докази потрібному перевіряльнику узгодженим каналом.

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