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

Модель акаунтів NEAR — це система протокольного рівня NEAR Protocol для керування ідентифікацією та дозволами акаунтів разом із ончейн-станом. Кожен акаунт у NEAR має людиночитаний ID акаунта, може містити кілька ключів доступу з різними рівнями дозволів і одночасно зберігати як баланс токенів, так і розгорнутий смартконтракт. Блокчейни керують вартістю та ідентифікацією за допомогою різних систем (Bitcoin використовує модель невичерпаного залишку транзакції, або UTXO, тоді як Ethereum і NEAR використовують модель на основі акаунтів, де кожен акаунт безпосередньо зберігає свій стан), і саме дизайн NEAR на основі акаунтів робить можливим функціонування архітектури, яка тут розглядається.

NEAR Protocol — це блокчейн Рівень 1 з механізмом підтвердження долі (стейкінгу), який запустив свою Основну мережу у 2020 році. Його створила компанія NEAR Inc. (нині працює як Pagoda) — організація, що займається інструментами для розробників, яка продовжує підтримувати NEAR SDK та інфраструктуру основного протоколу. NEAR Protocol використовує шардинг Nightshade для розділення мережі на паралельні шарди, а ідентифікатори облікових записів відіграють роль у призначенні шарду, що важливо для розробників, які розглядають патерни міжконтрактних викликів.

Чотири властивості відрізняють модель облікових записів NEAR від інших систем облікових записів Рівня 1:

• Ідентифікатори акаунтів — це людиночитабельні рядки, а не випадкові шістнадцяткові послідовності
• Один акаунт може містити необмежену кількість ключів доступу, кожен із власною сферою дозволів
• Будь-який акаунт може мати як баланс токенів, так і розгорнутий смартконтракт, без архітектурної різниці між «акаунтами користувачів» та «акаунтами контрактів»
• Акаунти повинні підтримувати баланс токенів NEAR, пропорційний їхньому використанню ончейн-сховища — цей механізм називається стейкінгом сховища

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

Перейти до розділу:

• ID акаунтів NEAR: іменовані та неявні акаунти
• Ключі доступу NEAR: як працюють дозволи акаунтів
• Стейкінг сховища: як NEAR пов'язує баланс токенів із ончейн-сховищем
• Субакаунти NEAR: ієрархічні простори імен акаунтів
• Модель акаунтів NEAR проти Ethereum: ключові архітектурні відмінності
• Що означає уніфікована архітектура акаунтів NEAR на практиці
• Часті запитання про модель акаунтів NEAR
• Ключові висновки та наступні кроки

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

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

Іменовані облікові записи: Читабельні для людини ідентифікатори

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

Реєстрація іменованого облікового запису вимагає невеликий депозит токенів NEAR. Щоб створити його, відвідайте інтерфейс гаманця, сумісного з NEAR, такого як MyNEARWallet або Meteor Wallet, оберіть свій ідентифікатор облікового запису та внесіть депозит для реєстрації. Іменовані облікові записи також можуть створювати під-облікові записи у межах свого простору імен (наприклад, alice.near може створити app.alice.near), це тема, яка детально розглядається в розділі про під-облікові записи нижче.

Іменовані облікові записи — це нативна функція протоколу, вбудована безпосередньо в модель облікових записів NEAR Protocol. Це не зовнішня служба імен, накладена поверх протоколу, на відміну від того, як Ethereum Name Service (ENS) працює на Ethereum. ENS — це окрема система смартконтрактів; іменовані облікові записи NEAR є повноцінною частиною самого протоколу.

Неявні облікові записи: Отримані з публічних ключів

Імпліцитний акаунт — це 64-символьний шістнадцятковий ідентифікатор акаунта, отриманий детерміновано з Відкритого ключа Ed25519. Приклад ідентифікатора імпліцитного акаунта виглядає так: 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. Для розробників, які перейшли з Ethereum, це найбільш структурно знайомий тип акаунта, оскільки процес деривації аналогічний тому, як адреси Ethereum обчислюються з відкритих ключів.

Механізм створення неявних (implicit) облікових записів відрізняється від іменованих облікових записів в одному ключовому аспекті: не вимагається жодна транзакція реєстрації. Неявний обліковий запис стає активним у той момент, коли хтось надсилає токени NEAR на його ідентифікатор облікового запису (account ID). Це робить неявні облікові записи добре придатними для програмного створення облікових записів, адрес депозитів на біржах та сценаріїв, де читабельність для людини не є пріоритетом.

Термін «неявний» (implicit) дескриптор стосується механізму створення, а не анонімності. Неявні акаунти повністю належать і контролюються власником приватного ключа, з якого було отримано ідентифікатор акаунта. Ще одна відмінність: ідентифікатор неявного акаунта походить від відкритого ключа, але він не є ідентичним самому відкритому ключу. Ідентифікатор акаунта — це представлення необроблених байтів відкритого ключа у вигляді шістнадцяткового рядка в нижньому регістрі. Розробники Ethereum, знайомі з деривацією адрес, впізнають цю схему, але не повинні вважати, що ці два представлення однакові.

Іменовані акаунти проти неявних: пліч-о-пліч порівняння

Два типи ідентифікаторів облікових записів відрізняються за п'ятьма вимірами:

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

--- ## Ключі доступу NEAR: Як працюють дозволи облікового запису

Ключі доступу NEAR — це рівень авторизації в моделі акаунта. Кожен акаунт NEAR може мати кілька ключів доступу одночасно, і кожен ключ має певну сферу повноважень. Акаунт NEAR може містити необмежену кількість ключів доступу одночасно. Кожен ключ — це незалежна криптографічна пара ключів Ed25519, і ви можете додавати або видаляти ключі, не створюючи новий акаунт. Ключі додаються за допомогою транзакції, підписаної наявним ключем повного доступу (Full Access Key), через NEAR CLI (near add-key) або програмним шляхом за допомогою SDK.

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

Ключі повного доступу: Основні облікові дані

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

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

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

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

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

Коли ви підключаєте свій обліковий запис NEAR до децентралізованої програми (dApp) і схвалюєте ключ доступу до виклику функції, dApp може автоматично надсилати певні транзакції без виклику спливаючого вікна підтвердження гаманця для кожної з них. Це дозволяє використовувати UX на основі сесій в іграх, протоколах DeFi та соціальних додатках. В Ethereum кожна з цих взаємодій вимагала б окремого підтвердження MetaMask. На NEAR користувач схвалює ключ один раз, і dApp працює в межах цієї сфери дії протягом сесії.

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

Поширена помилка: Надання ключа доступу до виклику функцій (Function Call Access Key) децентралізованому додатку (dApp) не дає цьому додатку контроль над вашим акаунтом. Ключ обмежений виключно визначеними методами смарт-контракту та лімітом газу. Він не може переказувати ваш баланс токенів NEAR, не може розгортати контракти, а також не може додавати або видаляти інші ключі у вашому акаунті.

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

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

Ключі повного доступу та ключі доступу для виклику функцій відрізняються за шістьма вимірами:

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

Стейкінг сховища: як NEAR пов'язує баланс токенів із ончейн-сховищем

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

Чому NEAR вимагає баланс токенів для зберігання

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

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

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

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

Стейкінг зберігання на практиці: Що це означає для облікових записів та смарт-контрактів

Стейкінг сховища впливає на акаунти на трьох рівнях:

• Створення акаунта: Вимагає мінімального балансу токенів NEAR. Поточна ставка становить приблизно 0,00182 NEAR за байт стану (перевірте поточні ставки в офіційній документації NEAR щодо стейкінгу сховища) перед прийняттям рішень щодо розробки, оскільки управління протоколом може коригувати цю цифру).
• Розгортання контракту: Вимагає пропорційно більшого депозиту залежно від розміру скомпільованого контракту. Байт-код WASM контракту зберігається ончейн як частина стану акаунта, і депозит за зберігання масштабується відповідно до цього розміру.
• Дані стану контракту: Дані, що зберігаються в стані контракту (наприклад, баланси користувачів у токен-контракті або ігровий стан в ончейн-грі), вимагають постійного балансу, який підтримується тим, хто контролює акаунт контракту.

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

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

Субакаунти NEAR: Ієрархічні простори імен акаунтів

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

Важлива деталь, яку слід уточнити: після створення субакаунта батьківський обліковий запис ЙОГО НЕ контролює. Субакаунт є повністю незалежним: він має власні ключі доступу, власний баланс токенів NEAR та власний ончейн-статус. Єдиний особливий дозвіл батьківського облікового запису — це можливість створювати субакаунти у своєму просторі імен. Окрім цього акту створення, два облікові записи не мають жодних тривалих відносин контролю.

Ієрархія імен нагадує вебдомени та піддомени. alice.near — це як домен, а app.alice.near — як піддомен. Так само як реєстрація домену не надає вам постійного контролю над контентом, розміщеним на його піддоменах, створення субакаунта не дає батьківському акаунту повноважень щодо того, як цей субакаунт використовуватиметься надалі.

Типовий сценарій використання для команд протоколів виглядає так:

myprotocol.near → token.myprotocol.near → staking.myprotocol.near → dao.myprotocol.near

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

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

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

--- ## Модель облікового запису NEAR проти Ethereum: Ключові архітектурні відмінності

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

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

NEAR використовує уніфіковану модель. Будь-який акаунт NEAR може мати баланс токенів і одночасно мати розгорнутий на ньому смартконтракт. Окремого типу «контрактного акаунта» не існує. Акаунт alice.near може зберігати токени NEAR, запускати розгорнутий контракт WASM і мати кілька ключів доступу з різними рівнями дозволів — і все це як єдиний об'єкт протоколу. Будь-який акаунт NEAR може одночасно мати смартконтракт, баланс токенів і кілька ключів доступу.

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

Примітка: Ethereum-сумісні смартконтракти можуть працювати на NEAR через Aurora — рівень сумісності з EVM, розгорнутий як смартконтракт на NEAR. Aurora — це окремий рівень; для нативної розробки на NEAR використовується WebAssembly (WASM), скомпільований із Rust або JavaScript, а не Solidity. Див. документацію про модель акаунтів Ethereum для отримання повної специфікації акаунтів Ethereum.

Що означає уніфікована архітектура облікових записів NEAR на практиці

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

Розглянемо один акаунт NEAR, alice.near. Акаунт Аліси може одночасно:

1. Мати баланс токенів NEAR
2. Мати розгорнутий на ньому смартконтракт, скомпільований до WebAssembly (WASM) з Rust
3. Мати три ключі доступу: Ключ повного доступу, що зберігається на її апаратному гаманці, Ключ повного доступу на її ноутбуці та Ключ виклику функції, наданий dApp DeFi для торгівлі на основі сесій
4. Володіти двома під-акаунтами (app.alice.near для розгорнутого ігрового контракту та vault.alice.near для контракту Накопичення), кожен з яких контролюється незалежно

ID акаунта Alice є читабельним і доступним для поширення. Вона ніколи не копіює 42-символьний шістнадцятковий рядок, щоб отримати токени або взаємодіяти з контрактом.

Для розробників практичне значення є значним. Шаблони сесійних ключів усувають незручності, пов'язані з гаманцем, на рівні транзакцій у іграх та соціальних додатках. Архітектура суб-акаунтів дозволяє командам протоколів розгортати модульні контракти з незалежними шляхами оновлення. Стейкінг сховища створює передбачувану модель витрат для ончейн-даних, які повинні бути враховані в економіці онбордингу. Акаунти також можуть взаємодіяти з Rainbow Bridge для переказу активів між NEAR та Ethereum, і ними керують через інтерфейси гаманців, сумісних з NEAR, такі як MyNEARWallet або Meteor Wallet.

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

Найпоширеніші запитання про модель облікових записів NEAR

Яка різниця між іменованим обліковим записом та неявним обліковим записом на NEAR?

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

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

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

Що таке стекінг сховища (storage staking) у NEAR Protocol?

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

Чи може акаунт NEAR містити смартконтракт?

Так. Будь-який обліковий запис NEAR може мати розгорнутий смартконтракт. На відміну від Ethereum, який розділяє зовнішні облікові записи (External Owned Accounts, облікові записи користувачів, які не можуть зберігати код) від облікових записів контрактів (Contract Accounts, облікові записи, що зберігають код і не мають приватного ключа), NEAR використовує уніфіковану модель облікових записів, де будь-який обліковий запис може одночасно зберігати баланс токенів NEAR і розгорнутий код контракту. Контракти на NEAR компілюються до WebAssembly (WASM) з вихідного коду Rust або JavaScript, а не Solidity. Дивіться розділ Порівняння з Ethereum для повного архітектурного розбору.

Що станеться, якщо мій баланс облікового запису NEAR впаде нижче вимоги до сховища?

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

Що таке субакаунт у NEAR і хто ним керує?

Субакаунт NEAR – це обліковий запис, ідентифікатор якого має префікс ідентифікатора батьківського облікового запису. Наприклад, app.alice.near є субакаунтом alice.near, і лише alice.near може створювати облікові записи в цьому просторі імен. Після створення батьківський обліковий запис НЕ контролює субакаунт. Субакаунт є повністю незалежним, маючи власні ключі доступу, власний баланс токенів NEAR та власний ончейн стан. Право батьківського облікового запису на найменування обмежується актом створення. Див. розділ субакаунтів для повного пояснення.

Чим NEAR Protocol відрізняється від Ethereum з точки зору облікових записів?

Основна архітектурна відмінність полягає в структурі акаунтів. Ethereum має два окремі типи акаунтів: Зовнішні акаунти (контролюються єдиним приватним ключем, без коду) та Контрактні акаунти (контролюються кодом, без приватного ключа). NEAR використовує уніфіковану модель акаунтів, де будь-який акаунт NEAR може одночасно містити як баланс токенів, так і розгорнутий смартконтракт. Акаунти NEAR також підтримують кілька ключів доступу з різними рівнями дозволів, тоді як акаунти Ethereum контролюються одним приватним ключем. ID акаунтів NEAR можуть бути зрозумілими для людини іменами, тоді як адреси Ethereum завжди є шістнадцятковими рядками. Перегляньте повну порівняльну таблицю для детального зіставлення.

Що таке ключ повного доступу порівняно з ключем доступу до виклику функцій у NEAR?

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

Як виглядає ID облікового запису NEAR?

Ідентифікатори облікових записів NEAR бувають двох форм. Іменовані облікові записи виглядають як читабельні імена користувачів або доменні імена: alice.near, myprotocol.near, app.alice.near. Неявні облікові записи — це 64-знакові шістнадцяткові рядки, отримані з відкритого ключа, візуально схожі на адреси Ethereum, але довші: наприклад, 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. Іменовані облікові записи використовують суфікс .near в основній мережі та .testnet у тестовій мережі. Дивіться розділ ідентифікаторів облікових записів для повного опису та порівняльної таблиці.

Чи є NEAR Protocol підтвердженням частки (proof of stake)?

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

Ключові висновки та наступні кроки

Модель облікового запису NEAR об'єднує ідентичність облікового запису з дозволами та управлінням Ончейн-зберіганням в єдиній архітектурі. Замість того, щоб розділяти облікові записи користувачів від контрактних облікових записів, або обмежувати кожен обліковий запис одним Приватним ключем, NEAR створює гнучкість та обмежені дозволи безпосередньо в рівень облікових записів.

Основні висновки:

• NEAR-ідентифікатори акаунтів — це зрозумілі для людей іменовані акаунти (наприклад, alice.near) або 64-символьні неявні акаунти, отримані з відкритого ключа, а не шістнадцяткові адреси
• Іменовані акаунти потребують депозиту в токенах NEAR під час реєстрації; неявні акаунти активуються автоматично після першого отримання токенів
• Кожен NEAR-акаунт може одночасно мати кілька ключів доступу, кожен з яких має окрему область дозволів
• Ключі повного доступу дозволяють усі дії з акаунтом і належать власнику акаунта; ключі доступу до виклику функцій обмежені конкретними методами контрактів і видаються додаткам
• Будь-який NEAR-акаунт може одночасно містити баланс токенів NEAR і розгорнутий смартконтракт. Окремого типу контрактного акаунта не існує
• Стейкінг сховища вимагає заблокованого балансу токенів NEAR, пропорційного обсягу споживання ончейн-сховища. Це депозит з можливістю повернення, а не комісія, і він відрізняється як від комісій за газ, так і від стейкінгу валідаторів
• Субакаунти дотримуються ієрархічної конвенції іменування, але батьківський акаунт не контролює субакаунти після створення. Кожен субакаунт є повністю автономним

Розробники, готові розробляти на NEAR, можуть почати з документації моделі облікових записів NEAR Protocol, яка містить технічну специфікацію та посилання на SDK. Щодо специфіки стейкінгу зберігання та поточних параметрів ставок, зверніться до офіційної документації стейкінгу зберігання NEAR перш ніж приймати архітектурні рішення, оскільки параметри протоколу можуть змінюватися через управління. Користувачі, які створюють свій перший обліковий запис NEAR, можуть зробити це через інтерфейс гаманця, сумісного з NEAR, такий як MyNEARWallet або Meteor Wallet.

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