Модель акаунта NEAR: імена, ключі та сховище

[{"anchor":"#shcho-take-near-protocol-kratke-vstup","text":"Що таке NEAR Protocol?"},{"anchor":"#tldr-model-oblikovykh-zapisiv-near-odnym-poglyadom","text":"TL;DR: Модель облікових записів NEAR одним поглядом"},{"anchor":"#shcho-take-model-oblikovykh-zapisiv-near","text":"Що таке модель облікових записів NEAR?"},{"anchor":"#imenovani-ta-neyavni-oblikovi-zapisi-yak-near-identifikuie-koristuvachiv","text":"Іменовані та неявні облікові записи: як NEAR ідентифікує користувачів"},{"anchor":"#sub-oblikovi-zapisi-iyerarkhichna-organizatsiia-oblikovykh-zapisiv-na-near","text":"Суб-облікові записи: ієрархічна організація облікових записів на NEAR"},{"anchor":"#kluchi-dostupu-near-povnyy-dostup-proty-dozvoliv-na-vyklyk-funktsiy","text":"Ключі доступу NEAR: повний доступ проти дозволів на виклик функцій"},{"anchor":"#steikinh-zberihannia-chomu-oblikovi-zapisi-near-vymahaiut-minimalnyy-balans","text":"Стейкінг зберігання: чому облікові записи NEAR вимагають мінімальний баланс"},{"anchor":"#model-oblikovykh-zapisiv-near-proty-ethereum-porivniannia-plich-o-plich","text":"Модель облікових записів NEAR проти Ethereum: порівняння пліч-о-пліч"},{"anchor":"#pochato-roboti-stvorennia-ta-keruvannia-vashym-oblikovym-zapysom-near","text":"Початок роботи: створення та керування вашим обліковим записом NEAR"},{"anchor":"#chasti-zapytannia-model-oblikovykh-zapisiv-near","text":"Часті запитання: модель облікових записів NEAR"},{"anchor":"#vysnovok-shcho-model-oblikovykh-zapisiv-near-oznachae-dlia-rozrobliv-ta-koristuvachiv","text":"Висновок: що модель облікових записів NEAR означає для розробників та користувачів"}]

Що таке NEAR Protocol? (Короткий вступ)

NEAR Protocol — це блокчейн рівня 1 на базі proof-of-stake, створений для доступності розробникам, із низькими та передбачуваними комісіями за транзакції та архітектурою шардингу, розробленою для масштабування без втрати зручності використання. Співзасновниками NEAR Protocol є Ілля Полосухін та Олександр Скіданов; проєкт від самого початку розроблявся з орієнтацією на досвід розробників та доступність для кінцевих користувачів як основні цілі, а не шляхом пристосування зручності до архітектури, побудованої для інших цілей.

NEAR масштабується за допомогою шардингу Nightshade — механізму, який розподіляє стан акаунтів та обчислення між паралельними ланцюжками обробки, що дозволяє мережі обробляти великі обсяги транзакцій без пропорційного зростання комісій. Протокол підтримує смарт-контракти, скомпільовані у WebAssembly, і завдяки своїй архітектурі забезпечує низьку вартість газу, на відміну від блокчейнів, де волатильність комісій створює перешкоди як для розробників, так і для користувачів. Розвитком екосистеми опікується NEAR Foundation — некомерційний орган управління, який раніше керував офіційним гаманцем NEAR Wallet до переходу на альтернативи, що підтримуються спільнотою.

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

--- ## Коротко про головне: Огляд облікової моделі NEAR

Короткий огляд для тих, хто читає по діагоналі:

• Облікові записи NEAR використовують читабельні імена (наприклад, alice.near) замість криптографічних хеш-рядків, як адреси Ethereum 0x742d35Cc....
• Кожен обліковий запис може одночасно зберігати кілька ключів доступу, кожен зі своїм рівнем дозволу, від необмеженого контролю до вузькоспеціалізованих взаємодій зі смартконтрактами.
• Будь-який обліковий запис NEAR може розгорнути смартконтракт; немає окремого типу облікового запису для смартконтрактів, як в Ethereum.
• Під-облікові записи дотримуються ієрархічного простору імен (наприклад, contract.myapp.near під myapp.near), працюючи як піддомени для облікових записів блокчейну.
• Облікові записи повинні підтримувати мінімальний баланс токенів NEAR, пропорційний використанню сховища ончейн, механізм, що називається стейкінг сховища.
• Нативна система дозволів NEAR з кількома ключами досягає багатьох цілей, до яких прагне Ethereum за допомогою абстракції облікових записів (EIP-4337), але через інший архітектурний підхід, вбудований з самого початку.

Що таке модель облікових записів NEAR?

Модель акаунтів NEAR — це архітектура ідентифікації та дозволів ончейн, яка визначає, як називаються акаунти, який стан вони зберігають, як здійснюється керування доступом за допомогою гранулярних дозволів ключів і як вони пов’язані зі смартконтрактами в блокчейні NEAR.

У контексті блокчейну «модель акаунтів» означає систему, яку протокол використовує для представлення учасників ончейн: що містить акаунт, як він ідентифікується, як він авторизує транзакції та чи може він виконувати код. Ethereum використовує одну модель акаунтів; Bitcoin використовує зовсім іншу парадигму (модель UTXO, де баланси відстежуються як невитрачені виходи транзакцій, а не як баланси акаунтів). NEAR використовує модель на основі акаунтів, але її реалізація значно відрізняється від моделі Ethereum у аспектах, що мають значення як для зручності використання, так і для розробки застосунків.

Обліковий запис NEAR одночасно містить п'ять елементів: унікальний ідентифікатор облікового запису, баланс токенів NEAR, стан облікового запису (ончейн зберігання даних), необов'язковий розгорнутий смартконтракт, скомпільований до WebAssembly (WASM, що дозволяє використовувати контракти, написані на Rust або JavaScript), та один або кілька ключів доступу з різними рівнями дозволів. Ця уніфікована структура означає відсутність поділу між «обліковими записами користувачів» та «обліковими записами смартконтрактів», як це спостерігається в Ethereum. Будь-який обліковий запис NEAR може опціонально розміщувати смартконтракт, не перетворюючись на об'єкт іншої категорії. Облікові записи без розгорнутих контрактів функціонують як звичайні облікові записи користувачів; облікові записи з розгорнутими контрактами є одночасно обліковими записами користувачів та хостами контрактів.

Практичний контекст для розуміння важливості цього — це децентралізована програма (dApp), програмна програма, яка працює в блокчейн-мережі, а не на централізованих серверах. Архітектура облікових записів NEAR була розроблена для того, щоб зробити взаємодії з dApp безпечнішими та доступнішими, ніж дозволяють існуючі блокчейн-моделі облікових записів. Система ідентифікаторів облікових записів є місцем, де ця філософія дизайну найбільш очевидна, і саме звідти починається огляд архітектури.

Для повної технічної специфікації, дивіться документацію моделі облікових записів NEAR Protocol за адресою docs.near.org/concepts/basics/accounts/model.

Іменовані акаунти та неявні акаунти: Як NEAR ідентифікує користувачів

NEAR ідентифікує користувачів і додатки ончейн за допомогою двох форматів акаунтів: іменовані акаунти, які використовують зрозумілі для людини рядки, як-от alice.near, та неявні акаунти, які є 64-символьними шістнадцятковими рядками, похідними від відкритого ключа.

Іменовані акаунти: зрозумілі для людини ідентифікатори в блокчейні

Іменовані облікові записи на NEAR — це зрозумілі для людини ідентифікатори облікових записів, що мають структуру, подібну до доменних імен. Вони закінчуються на .near в основній мережі та .testnet у тестовій мережі, замінюючи криптографічні хеш-рядки, які використовуються блокчейнами, такими як Ethereum.

Контраст очевидний: alice.near проти 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. Обидва є дійсними ідентифікаторами блокчейну, але один легко читається, а інший потребує ретельної перевірки шляхом копіювання та вставки. Уявіть собі іменований акаунт NEAR як адресу електронної пошти: він читабельний і прив’язаний до особистості, а не є випадковим рядком символів, що потребує посимвольного порівняння для перевірки.

Іменовані акаунти відповідають певним правилам іменування: ідентифікатори акаунтів є буквено-цифровими рядками, можуть використовувати крапки як роздільники, повинні містити від 2 до 64 символів і закінчуватися на .near в Основній мережі або .testnet у тестовій мережі. Структура, розділена крапками, створює ієрархію, схожу на доменну: myapp.near — це іменований акаунт верхнього рівня, а contract.myapp.near — це субакаунт під ним (докладніше про субакаунти в наступному розділі).

Обґрунтування UX щодо іменованих акаунтів виходить за межі естетики. Читабельні ідентифікатори знижують ризик надсилання транзакцій на неправильні акаунти, роблять адреси контрактів доступними для пошуку та зменшують когнітивне навантаження під час управління ончейн-ідентифікаторами. Для кожного, хто тричі перевіряв адресу MetaMask перед надсиланням транзакції, перевага alice.near над 42-символьним шістнадцятковим рядком є цілком відчутною, а не абстрактною. Користувачі реєструють іменовані акаунти та керують ними через MyNEARWallet на mynearwallet.com, основний інтерфейс акаунтів, що підтримується спільнотою (оригінальний wallet.near.org, керований NEAR Foundation, було виведено з експлуатації).

Імпліцитні акаунти: Альтернативний формат акаунтів

Неявні акаунти — це другий формат акаунтів на NEAR: 64-символьні шістнадцяткові рядки в нижньому регістрі, отримані безпосередньо з відкритого ключа, які з’являються, щойно токени NEAR надсилаються на цей ID акаунта, не вимагаючи жодних дій від існуючого акаунта.

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

Одне уточнення, яке варто чітко зазначити: неявні облікові записи не є анонімними. Вони детерміновано виводяться з відкритого ключа і є повністю прозорими ончейн. Слово «неявний» стосується того, як виводиться ідентифікатор облікового запису (з самого ключа, без явного кроку реєстрації), а не будь-якої властивості конфіденційності.

Іменовані та неявні акаунти визначають те, як NEAR ідентифікує учасників ончейн. Акаунти також можуть містити інші акаунти у своєму просторі імен, і саме в цій ієрархічній структурі з’являються субакаунти.

Субакаунти: ієрархічна організація акаунтів на NEAR

Субакаунти в NEAR працюють як піддомени в мережі: так само, як docs.myapp.com та api.myapp.com є окремими адресами в домені myapp.com, token.myapp.near та staking.myapp.near є окремими акаунтами Блокчейн у просторі імен myapp.near.

Суб-акаунт — це обліковий запис, ідентифікатор якого існує в просторі імен батьківського облікового запису. Обліковий запис contract.myprotocol.near є суб-акаунтом myprotocol.near. Тільки батьківський обліковий запис може створити суб-акаунт: myprotocol.near може створити contract.myprotocol.near, але жоден інший обліковий запис не може створити обліковий запис у цьому просторі імен без авторизації батьківського облікового запису.

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

Ця незалежність є поширеним приводом для плутанини. Зв'язок «батьківський-дочірній» діє лише під час створення. Як тільки contract.myprotocol.near створено, він має власні ключі доступу, власний баланс токенів NEAR і свій власний ончейн-стан. Батьківський акаунт myprotocol.near не має над ним жодних спеціальних привілеїв.

Для розробників dApp під-облікові записи (sub-accounts) надають практичний архітектурний шаблон. Оскільки будь-який обліковий запис NEAR може розгортати смартконтракт (скомпільований до WASM), під-облікові записи стають природним способом надання кожному компоненту контракту зрозумілого, організованого ідентифікатора облікового запису. Протокол DeFi може розгорнути token.myprotocol.near для свого токен-контракту, staking.myprotocol.near для свого стейкінг-контракту та governance.myprotocol.near для свого контракту управління. Кожен з них є окремим обліковим записом зі своїм контрактом, своїм станом і своїм керуванням ключами, але простору імен робить взаємозв'язок між компонентами одразу зрозумілим будь-кому, хто читає блокчейн. Щоб отримати покрокові інструкції зі створення під-облікових записів, зверніться до документації NEAR щодо під-облікових записів за адресою docs.near.org/concepts/basics/accounts/model#named-accounts.

Розуміння того, як іменуються та організовуються акаунти, готує підґрунтя для наступного архітектурного рівня: того, як вони захищаються та як надаються права доступу за допомогою ключів доступу.

Ключі доступу NEAR: повний доступ проти дозволів на виклик функцій

Ключі доступу NEAR — це рівень дозволів, який контролює, які дії можна виконувати в обліковому записі NEAR, і найбільш архітектурно відмінна риса системи: один обліковий запис NEAR може одночасно містити кілька незалежних пар ключів, кожна зі своїм рівнем дозволів.

Як працює багатоключова система NEAR

На відміну від більшості облікових записів Блокчейну, де один Приватний ключ контролює все, один обліковий запис NEAR може містити кілька незалежних пар ключів, кожній призначено певний тип дозволу, від необмеженого контролю до вузькоспеціалізованих взаємодій з контрактами.

Ключі доступу NEAR за замовчуванням використовують пари ключів Ed25519 (з підтримкою secp256k1 для сумісності з інструментарієм Ethereum). Система дозволів, побудована на основі цих пар ключів, робить модель NEAR архітектурно відмінною. Уявіть це як брелок: Ключ повного доступу — це майстер-ключ, який відчиняє всі замки; Ключ виклику функції — це спеціально створений ключ, який відчиняє лише одні конкретні двері. Кожна транзакція, підписана будь-яким ключем доступу до акаунту, споживає газ, оплачений токенами NEAR, але комісії за транзакції NEAR за своєю суттю низькі та передбачувані, на відміну від історично мінливих цін на газ в Ethereum.

Щодо деталей додавання та керування ключами доступу програмно, зверніться до довідкової документації за ключами доступу NEAR за адресою docs.near.org/concepts/basics/accounts/access-keys.

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

Ключ із повним доступом на NEAR — це пара ключів, яка може виконувати будь-які дії на обліковому записі, до якого вона прив'язана: переказувати токени, розгортати смарт-контракти, створювати субакаунти, додавати або видаляти інші ключі та видаляти сам обліковий запис.

Оскільки Ключ повного доступу контролює весь обліковий запис, він несе такий самий профіль ризику, як головний пароль. Ключі повного доступу ніколи не слід надавати стороннім застосункам і їх слід зберігати в холодному сховищі (апаратний гаманець або офлайн-сховище) для будь-якого облікового запису, що містить значні кошти. Якщо Ключ повного доступу скомпрометовано, зловмисник отримує повний контроль над обліковим записом без вбудованого механізму відновлення, якщо такий не було налаштовано заздалегідь.

Порівняння з Ethereum є тут показовим. В Ethereum ваш єдиний приватний ключ для Externally Owned Account (EOA) функціонує як ключ повного доступу: він контролює все, і не існує нативного способу надати dApp ключ із нижчим рівнем дозволів для конкретної взаємодії з контрактом. Кожне підключення dApp через MetaMask відкриває ваш повний ключ облікового запису для процесу підписання транзакцій. Це обмеження одного ключа — саме та проблема, яку покликана вирішити абстракція облікових записів EIP-4337 в Ethereum. У NEAR це рішення було вбудоване в базову модель облікових записів.

Ключі доступу до виклику функцій: обмежені дозволи для безпеки dApp

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

Тоді як Ключ повного доступу є необмеженим, Ключ виклику функції є чітко обмеженим. Ключ визначає: один ID контракту, який йому дозволено викликати, які методи цього контракту він може викликати (або всі публічні методи, якщо не обмежено додатково), та опціональний ліміт токенів NEAR, який обмежує, скільки газу може витратити ключ, перш ніж він потребуватиме поповнення. Як тільки ліміт буде вичерпано, ключ не зможе підписувати подальші транзакції, доки його не буде поповнено або замінено.

Варіант використання автентифікації на основі сесій — це те, де ключі доступу до виклику функцій (Function Call Access Keys) демонструють свою практичну цінність для розробки dApp. Коли ви підключаєте dApp до свого акаунта NEAR, dApp запитує ключ доступу до виклику функцій, обмежений його власним смартконтрактом. Цей ключ зберігається в сесії вашого браузера. З цього моменту dApp може надсилати транзакції від вашого імені (підтвердження угоди, мінтинг NFT, взаємодія з ігровим контрактом) без запиту на підписання кожної окремої дії. Ваш ключ повного доступу (Full Access Key) ніколи не залишає ваш безпечний гаманець. Якщо dApp буде зламано або він виявиться зловмисним, збитки будуть обмежені: зловмисник зможе викликати лише певні методи контракту, на які було видано дозвіл ключу, і лише в межах встановленого ліміту (allowance). Ключ доступу до виклику функцій працює як сесійний токен у вебдодатку: він надає тимчасовий, обмежений доступ до певних дій без розкриття повних облікових даних акаунта.

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

Стейкінг сховища: Чому для акаунтів NEAR потрібен мінімальний баланс

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

Механізм працює наступним чином: NEAR виділяє ончейн сховище, виміряне в байтах. За кожен байт стану, що зберігається в обліковому записі (записи балансу, код контракту, збережені дані, ключі доступу), відповідна кількість токенів NEAR має бути заблокована на балансі облікового запису. Ці токени не витрачаються і не знищуються; вони резервуються як заблокований баланс проти обсягу сховища. Якщо ви зменшуєте сховище свого облікового запису, видаляючи стан або дані контракту, відповідні токени розблоковуються та повертаються на ваш доступний баланс. Стейкінг сховища працює як поворотний гарантійний депозит: ви блокуєте пропорційну кількість токенів NEAR для сховища, яке використовує ваш обліковий запис, і отримуєте ці токени назад, якщо зменшуєте обсяг сховища.

Мета цього дизайну є економічною: він запобігає розростанню стану, гарантуючи, що сторона, яка отримує вигоду від ончейн-зберігання, несе витрати за це зберігання. Без такого механізму мережа блокчейну може накопичувати необмежену кількість «мертвого» стану від покинутих акаунтів або контрактів, що погіршує продуктивність для всіх учасників.

Конкретно, ставка стейкінгу зберігання становить приблизно 1 токен NEAR за 10 КБ ончейн-сховища, а щойно створений порожній обліковий запис NEAR потребує мінімального балансу приблизно 0.00182 NEAR для покриття своєї базової площі стану. Перевірте актуальні цифри за документацією зі стейкінгу зберігання NEAR на docs.near.org/concepts/storage/storage-staking), перш ніж покладатися на ці дані для планування розробки, оскільки параметри протоколу змінюються з оновленнями.

Для розробників смартконтрактів, наслідки стейкінгу сховища вимагають активного планування. Коли обліковий запис NEAR розгортає контракт, сам код контракту займає сховище в стані облікового запису. Більший бінарний файл контракту вимагає пропорційно більшого зарезервованого балансу. Якщо ваш контракт зберігає значні дані (записи користувачів, баланси токенів, голоси управління), обліковий запис, що розміщує цей контракт, повинен підтримувати достатній баланс, щоб покрити як код контракту, так і накопичений стан. Це вимога до капіталу, яка масштабується відповідно до використання програми, і її необхідно врахувати у вашій економічній моделі до розгортання.

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

Стейкінг сховища проти стейкінгу валідатора: це два різні механізми в мережі NEAR. Стейкінг сховища блокує токени NEAR відповідно до обсягу ончейн-даних вашого акаунта; ці токени діють як резервний баланс, пропорційний використаному обсягу сховища. Стейкінг валідатора блокує токени NEAR у межах механізму консенсусу, де валідатори вносять токени в стейкінг для участі у створенні блоків та отримання винагород за стейкінг. Ця стаття стосується лише стейкінгу сховища. Не плутайте ці два значення слова «стейкінг».

Комісії за газ (витрати на виконання транзакцій) відрізняються від стейкінгу сховища. Комісії за газ споживаються для кожної транзакції та сплачуються в токенах NEAR під час її підписання; стейкінг сховища — це зарезервований баланс, який залишається з обліковим записом, доки існує пов'язаний стан.

Розуміння стейкінгу сховища завершує картину того, як працюють акаунти NEAR ізольовано. Наступне питання полягає в тому, як ця архітектура порівнюється з архітектурою Ethereum.

Модель акаунтів NEAR проти Ethereum: порівняльний аналіз

NEAR та Ethereum застосовують фундаментально різні підходи до ончейн архітектури облікових записів, і ці відмінності мають значні наслідки для того, як розробники створюють децентралізовані додатки, та як користувачі керують своїми ончейн ідентичностями.

Система двох облікових записів Ethereum проти Єдиної моделі облікового запису NEAR

У таблиці нижче порівнюються дві моделі акаунтів за вісьмома архітектурними параметрами. Найістотніша відмінність полягає в тому, що Ethereum розділяє акаунти користувачів (зовнішні акаунти, або EOA) і акаунти смартконтрактів на два окремі типи, тоді як NEAR використовує єдиний уніфікований тип акаунта для обох.

Розподіл між EOA та контрактними рахунками Ethereum створює незручності на практиці. Більшість взаємодій з dApp вимагають, щоб EOA викликав контрактний рахунок, а це означає, що користувачі мають керувати обома типами як окремими сутностями. EOA керується одним приватним ключем без вбудованого способу обмеження дозволів: будь-який dApp, підключений до акаунта MetaMask, може запитувати підписи, що відкривають доступ до повного ключа акаунта в процесі транзакції. Модель Ethereum має чітке обґрунтування дизайну та добре відповідала своїм початковим цілям, але обмеження одного ключа стало очевидним, коли взаємодії з dApp ставали частішими та різноманітнішими.

Уніфікований тип акаунта NEAR усуває розділення між EOA та контрактами. Кожен акаунт NEAR потенційно є хостом для контрактів, а система з кількома ключами та ключами доступу до виклику функцій (Function Call Access Keys) розв'язує проблему обмеження одного ключа без необхідності окремого рівня протоколу. Як NEAR, так і Ethereum працюють у парадигмі на основі акаунтів, на відміну від моделі UTXO Біткоїна, де баланси відстежуються як невитрачені виходи транзакцій, а не як стан акаунта; різниця між NEAR та Ethereum полягає в тому, як ці акаунти структуровані та як регулюються права доступу до них, а не у фундаментальній парадигмі.

Модель акаунта NEAR та абстракція акаунта Ethereum (EIP-4337)

EIP-4337 (абстракція облікового запису) — це спроба Ethereum надати EOA можливості програмованих дозволів та роботи з сесійними ключами, які були закладені в модель облікового запису NEAR з самого початку.

EIP-4337 — це діючий стандарт Ethereum (не теоретична пропозиція), що дозволяє гаманцям на основі смартконтрактів функціонувати як повноцінні учасники, підтримуючи програмовану валідацію транзакцій, сесійні ключі, соціальне відновлення та спонсоровані транзакції. Для його роботи потрібна спеціальна інфраструктура бандлерів, і він активно розгортається в екосистемі Ethereum, хоча це не універсальне оновлення, яке автоматично застосовується до всіх облікових записів.

Паралель із ключами доступу до виклику функцій NEAR є реальною: обидва підходи вирішують проблему надання dApps обмеженого за областю дії, з обмеженими дозволами доступу для конкретних взаємодій без розкриття повного ключа облікового запису. Розробник, знайомий із сесійними ключами EIP-4337, знайде ключі доступу до виклику функцій NEAR концептуально знайомими. Важливий нюанс полягає в тому, що це архітектурно відмінні реалізації ідей, що перетинаються, а не ідентичні системи. Багатоключова модель дозволів NEAR є нативною для базового протоколу; EIP-4337 додає логіку смартконтрактних гаманців поверх існуючої моделі EOA Ethereum. Проблеми, які вони вирішують, значною мірою перетинаються; механізми відрізняються. Для повної специфікації EIP-4337 див. специфікацію абстракції облікових записів EIP-4337 за адресою eips.ethereum.org/EIPS/eip-4337.

Для розробників Ethereum, які оцінюють NEAR, варто відзначити два мости екосистеми. Aurora на aurora.dev, EVM-сумісне середовище, побудоване на NEAR, дозволяє розробникам Ethereum розгортати контракти Solidity на інфраструктурі NEAR, де акаунти NEAR слугують базовим рівнем ідентифікації. Розробники, які працюють в обох екосистемах, можуть використовувати Rainbow Bridge на rainbowbridge.app для переказу активів між акаунтами NEAR та адресами Ethereum без покладання на централізоване зберігання.

Тепер, коли архітектура зрозуміла, ось що насправді передбачає створення та керування акаунтом NEAR на практиці.

Початок роботи: Створення та керування вашим акаунтом NEAR

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

Якщо ви переходите з Ethereum і MetaMask, варто зрозуміти концептуальну різницю, перш ніж почати. Гаманець MetaMask — це переважно менеджер ключів і підписувач транзакцій для Ethereum EOA: він зберігає ваш приватний ключ і надає його dApp для підписання транзакцій. Обліковий запис NEAR — це повна ончейн-ідентичність із читабельним іменем, ончейн-сховищем стану, програмованими дозволами для ключів і опціональним хостингом контрактів. Програма-гаманець (MyNEARWallet) — це інтерфейс; обліковий запис NEAR — це ончейн-об'єкт. Це різні речі, і ця відмінність має значення для того, як ви думаєте про керування ключами.

Створення облікового запису NEAR вимагає невеликого початкового балансу токенів NEAR для покриття базової вимоги до стейкінгу сховища (приблизно 0,00182 NEAR для порожнього облікового запису, як описано в розділі про стейкінг сховища вище). Цей початковий баланс покриває базовий обсяг даних стану нового облікового запису.

Три ризики, про які варто знати перед початком роботи. По-перше, якщо ви втратите свій ключ повного доступу (Full Access Key) без налаштованого механізму відновлення, обліковий запис буде невідновлюваним. Зберігайте ваш ключ повного доступу в холодній пам'яті та налаштуйте будь-які доступні параметри відновлення до того, як вони вам знадобляться. По-друге, токени NEAR, зарезервовані для стейкінгу сховища, заблоковані доти, доки існує пов'язаний стан; це зобов'язання щодо капіталу, а не комісія. По-третє, видалення облікового запису в мережі NEAR є незворотнім. Для повного покрокового посібника зі створення облікового запису див. документацію розробника NEAR за адресою docs.near.org/concepts/basics/accounts/model.

Нижче наведено відповіді на найпоширеніші запитання щодо моделі облікового запису NEAR.

Поширені запитання: модель акаунтів NEAR

Наведені нижче запитання стосуються найбільш поширених аспектів, що викликають плутанину щодо моделі акаунтів NEAR, з перехресними посиланнями на відповідні розділи вище для читачів, які хочуть отримати повну інформацію.

Чи може будь-який акаунт NEAR розгорнути смартконтракт?

Так. У NEAR будь-який обліковий запис може опціонально розгорнути смартконтракт, скомпільований до WebAssembly (WASM). Немає окремого типу облікового запису контракту, на відміну від Ethereum, де розгортання контракту вимагає створення окремого облікового запису контракту. Обліковий запис без розгорнутого контракту функціонує як стандартний обліковий запис користувача; обліковий запис із розгорнутим контрактом функціонує як обидва одночасно. Див. Що таке модель облікових записів NEAR вище для повного архітектурного пояснення.

Як ключі доступу NEAR роблять dApps безпечнішими для використання?

Ключі доступу до виклику функцій обмежують dApp конкретними методами смарт-контракту з опціональним лімітом на газ. Коли ви підключаєтеся до dApp за допомогою ключа доступу до виклику функцій, область дії якого обмежена контрактом цього dApp, ваш ключ повного доступу (і весь баланс вашого акаунта) ніколи не розкриваються сторонньому застосунку. Якщо dApp буде зламано, шкода обмежиться лімітом газу та зазначеним контрактом. Дивіться розділ NEAR Access Keys для повного опису.

Що станеться, якщо я втрачу свій ключ повного доступу?

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

Чи є комісії за газ такими ж, як стейкінг зберігання?

Ні. Комісії за газ — це витрати на виконання транзакції, які споживаються під час її підписання; вони сплачуються токенами NEAR і не зберігаються після завершення транзакції. Стейкінг зберігання — це мінімальний зарезервований баланс токенів NEAR, який зберігається разом з обліковим записом, доки існує пов'язаний ончейн стан. Обидва передбачають використання токенів NEAR, але вони функціонують як абсолютно окремі механізми. Див. розділ «Стейкінг зберігання» для повного пояснення.

Як модель облікових записів NEAR співвідноситься з абстракцією облікових записів Ethereum (EIP-4337)?

Власна система дозволів NEAR із декількома ключами досягає багатьох цілей, для яких EIP-4337 був розроблений в Ethereum, включаючи обмежені дозволи на основі сесій для взаємодії з dApp та програмовану логіку ключів. Ці дві реалізації є архітектурно відмінними втіленнями схожих ідей: підхід NEAR є нативним для базового протоколу, тоді як EIP-4337 нашаровує логіку гаманця на основі смартконтрактів поверх існуючої моделі EOA в Ethereum. Вони вирішують подібні проблеми за допомогою різних архітектур. Дивіться розділ порівняння NEAR та Ethereum для детального аналізу.

Яка різниця між іменованим та неявним акаунтом у NEAR?

Іменні акаунти — це людиночитані ідентифікатори (наприклад, alice.near), зареєстровані за допомогою транзакції з наявного акаунта, що закінчуються на .near в основній мережі та на .testnet у тестовій мережі. Неявні акаунти — це 64-символьні шістнадцяткові рядки, отримані безпосередньо з відкритого ключа, які з’являються автоматично, коли токени NEAR надсилаються на цей ідентифікатор акаунта, без необхідності транзакції реєстрації. Дивіться розділ про іменні та неявні акаунти для перегляду повної порівняльної таблиці.

Скільки ключів доступу може мати один акаунт NEAR?

Обліковий запис NEAR може одночасно зберігати кілька ключів доступу, причому кожному ключу призначається власний тип дозволу (ключ повного доступу або ключ виклику функції), а для ключів виклику функції — власна область контракту та ліміт газу. Жодного жорстко задокументованого обмеження на кількість ключів на обліковий запис не існує. Ця можливість використовувати кілька ключів відрізняє модель дозволів NEAR від підходу Ethereum з одним ключем на EOA (зовнішній обліковий запис). Детальніше див. у розділі Ключі доступу NEAR.

Чи означає стейкінг зберігання втрату моїх токенів NEAR?

Ні. Токени NEAR, зарезервовані для стейкінгу сховища, заблоковані, але не витрачені. Вони залишаються на вашому акаунті як зарезервований баланс і повертаються на ваш доступний баланс, якщо ви зменшите обсяг ончейн-даних вашого акаунта, видаливши стан. Ці токени є депозитом за використання сховища, а не комісією. Дивіться розділ Стейкінг сховища, щоб дізнатися про механізм і поточні показники.

Висновок: Що модель акаунтів NEAR означає для розробників та користувачів

Модель акаунтів NEAR відображає ряд продуманих архітектурних рішень: людиночитані імена акаунтів знижують поріг входження та зменшують кількість помилок у транзакціях; система дозволів із декількома ключами мінімізує ризики безпеки при взаємодії з dApp, обмежуючи сторонній доступ без розкриття майстер-ключів; стейкінг сховища забезпечує економічну відповідність між використанням ресурсів і витратами; а уніфікована структура акаунт-контракт усуває розділення на EOA та контракти, яке створює труднощі для розробки на Ethereum.

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

Наступні кроки за роллю:

• Розробники: Почніть розробку на NEAR Protocol на docs.near.org/develop
• Користувачі: Створіть свій акаунт NEAR у MyNEARWallet на mynearwallet.com
• Дослідники: Поглиблено вивчіть повну специфікацію моделі акаунта в документації моделі акаунта NEAR Protocol на docs.near.org/concepts/basics/accounts/model

Технічні характеристики в цій статті відображають стан NEAR Protocol на момент написання. NEAR Protocol активно розробляється; перевірте поточні показники на docs.near.org, перш ніж покладатися на конкретні числові значення для розробки або операційного планування. Цей контент призначений виключно для інформаційних цілей і не є фінансовою чи інвестиційною порадою.