Объяснение модели аккаунтов NEAR: ключи и хранилище

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

NEAR Protocol — это блокчейн уровня 1 на базе алгоритма proof-of-stake (PoS), который запустил свой мейннет в 2020 году. Он был создан NEAR Inc. (в настоящее время работающей под названием Pagoda), организацией по разработке инструментов для разработчиков, которая продолжает поддерживать NEAR SDK и инфраструктуру основного протокола. NEAR Protocol использует шардинг Nightshade для разделения сети на параллельные шарды, а идентификаторы аккаунтов играют роль в распределении по шардам, что важно для разработчиков, рассматривающих паттерны межконтрактных вызовов.

Четыре свойства отличают модель аккаунтов NEAR от других систем аккаунтов уровня 1:

• Идентификаторы аккаунтов — это человекочитаемые строки, а не случайные шестнадцатеричные последовательности
• Один аккаунт может содержать неограниченное количество ключей доступа, каждый из которых имеет свою область полномочий
• Любой аккаунт может иметь как баланс токенов, так и развернутый смарт-контракт, без архитектурного различия между «пользовательскими аккаунтами» и «аккаунтами контрактов»
• Аккаунты должны поддерживать баланс токенов NEAR пропорционально объему использования ончейн-хранилища — этот механизм называется стейкингом хранилища

В этой статье последовательно рассматриваются следующие компоненты: типы ID аккаунтов, типы ключей доступа, стейкинг хранилища, субаккаунты, сравнение архитектуры с Ethereum и практический пример.

["Перейти к разделу:","- NEAR Account IDs: Именованные учетные записи и неявные учетные записи","- NEAR Access Keys: Как работают разрешения учетной записи","- Storage Staking: Как NEAR связывает баланс токенов с ончейн-хранилищем","- NEAR Sub-Accounts: Иерархические пространства имен учетных записей","- NEAR Account Model vs. Ethereum: Ключевые архитектурные различия","- Что означает унифицированная архитектура учетных записей NEAR на практике","- Часто задаваемые вопросы об модели учетных записей NEAR","- Ключевые выводы и следующие шаги"]

ID аккаунтов 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 являются полноценной частью самого протокола.

Неявные аккаунты: производные от публичных ключей

Скрытый аккаунт (implicit account) — это 64-символьный шестнадцатеричный идентификатор аккаунта, детерминированно полученный из Ed25519 публичного ключа. Пример идентификатора скрытого аккаунта выглядит следующим образом: 98793cd91a3f870fb126f66285808c7e094afcfc4b4a2ca57271d8b8b6a4a7c0. Для разработчиков, переходящих с Ethereum, это наиболее знакомый тип аккаунта, поскольку процесс его формирования аналогичен тому, как адреса Ethereum вычисляются на основе публичных ключей.

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

Дескриптор "неявный" относится к механизму создания, а не к анонимности. Неявные учетные записи полностью принадлежат и контролируются держателем приватного ключа, от которого был получен идентификатор учетной записи. Одно дальнейшее отличие: идентификатор неявной учетной записи получается из публичного ключа, но не идентичен самому публичному ключу. Идентификатор учетной записи — это шестнадцатеричное представление необработанных байтов публичного ключа в нижнем регистре. Разработчики Ethereum, знакомые с получением адресов, узнают этот шаблон, но не должны полагать, что эти два представления идентичны.

Неявные учетные записи по сравнению с именованными: сравнительная таблица

Два типа идентификаторов аккаунтов различаются по пяти параметрам:

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

Ключи доступа NEAR: как работают разрешения аккаунта

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

Это отличается от Ethereum, где каждый адрес контролируется одним приватным ключом. Архитектура NEAR с несколькими ключами обеспечивает более точный контроль разрешений без ущерба для непрерывности работы аккаунта. NEAR поддерживает два типа ключей: ключи с полным доступом (Full Access Keys) и ключи доступа для вызова функций (Function Call Access Keys). См. документацию NEAR Protocol по ключам доступа для получения полной технической спецификации.

Ключи с полным доступом: мастер-учетные данные

Ключ полного доступа — это ключ доступа с неограниченными правами управления аккаунтом. Он позволяет авторизовать переводы токенов, развертывание смарт-контрактов, добавление или удаление других ключей, а также удаление аккаунта. Представьте, что Ключ полного доступа — это мастер-ключ от вашего дома: он открывает любую дверь. В отличие от обычного ключа, Ключ полного доступа — это криптографическая пара ключей, которая подписывает транзакции в блокчейне NEAR, поэтому к нему применимы те же меры безопасности. Храните его в аппаратном кошельке или в автономном режиме по тем же причинам, по которым пользователи Ethereum защищают свои сид-фразы.

Аккаунт NEAR может иметь несколько Ключей полного доступа. Распространенная практика — по одному ключу на устройство, при этом каждый ключ обладает одинаковым уровнем полных разрешений. Это важный архитектурный момент: в отличие от аккаунтов Ethereum, здесь нет единого «главного приватного ключа». На одном аккаунте одновременно могут существовать несколько Ключей полного доступа.

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

Ключи доступа для вызовов функций: Ограниченные разрешения для dApps

Ключ доступа для вызова функций — это ключ с ограниченными правами, который может вызывать только определенные методы одного конкретного контракта, с необязательным лимитом на токены NEAR, ограничивающим расход газа ключом. Представьте его как токен сессии или ограниченное разрешение OAuth: он предоставляет конкретному приложению право выполнять определенные действия от вашего имени, не давая ему доступа к вашей полной учетной записи. В отличие от токена OAuth, ключ доступа для вызова функций является криптографической парой ключей, хранящейся в блокчейне, а границы его разрешений применяются на уровне протокола, а не приложением.

Когда вы подключаете свой аккаунт NEAR к децентрализованному приложению (dApp) и подтверждаете Ключ доступа к вызову функции (Function Call Access Key), dApp может автоматически отправлять определенные транзакции без вызова всплывающего окна подтверждения кошелька для каждой из них. Это обеспечивает UX (пользовательский опыт) на основе сессий в играх, протоколах DeFi и социальных приложениях. В Ethereum каждое из этих взаимодействий потребовало бы отдельного подтверждения MetaMask. На NEAR пользователь один раз одобряет ключ, и dApp действует в рамках этой области на время сессии.

Ключи доступа к вызову функций (Function Call Access Keys) могут иметь необязательный лимит (allowance) токенов NEAR, который ограничивает общий объем газа, разрешенный к использованию этим ключом. Как только этот лимит исчерпан, ключ больше не может отправлять транзакции до тех пор, пока пользователь не пополнит его или не выпустит новый ключ.

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

Примечание для разработчика: Ключи доступа к вызову функций (Function Call Access Keys) позволяют реализовать паттерны сессионных ключей в dApps. Пользователь может авторизовать ключ для игровой сессии или торговой сессии DeFi, и приложение будет работать в рамках этих полномочий, не требуя подтверждения каждой транзакции. Это одно из наиболее значимых для разработчиков различий в UX между созданием приложений на NEAR и на Ethereum.

Полнофункциональный ключ доступа против ключа доступа к вызову функций: ключевые различия

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

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

Стейкинг хранилища: как NEAR связывает баланс токенов с ончейн-хранилищем

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

Почему NEAR требует баланс токенов для хранения данных

Определение: Хранилищный стейкинг (также называемый стейкингом состояния в некоторых документах NEAR) — это требование к аккаунтам NEAR поддерживать баланс токенов NEAR пропорционально объему данных, которые они хранят ончейн. Этот заблокированный баланс действует как возвратный депозит, а не как комиссия.

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

Одно различие, которое стоит прояснить: стекинг хранения (storage staking) — это не то же самое, что стекинг валидатора (validator staking). Оба механизма блокируют токены NEAR, но служат совершенно разным целям. Стекинг валидатора блокирует токены для участия в производстве блоков и получения вознаграждений за консенсус. Стекинг хранения блокирует токены пропорционально использованию ончейн-хранилища, чтобы предотвратить раздувание состояния (state bloat) и привести стоимость хранения в соответствие с сущностями, которые его потребляют. Это отдельные заблокированные балансы с отдельными целями.

Стейкинг хранилища также отделен от комиссий за газ. Комиссии за газ — это расходы на исполнение каждой транзакции, оплачиваемые токенами NEAR и сжигаемые после каждой транзакции. Стейкинг хранилища — это постоянное требование к балансу, связанное с объемом данных, которые хранит учетная запись, а не с количеством отправляемых транзакций.

Стейкинг хранилища на практике: что это значит для учетных записей и контрактов

Стейкинг хранилища влияет на аккаунты на трех уровнях:

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

Если баланс учетной записи NEAR упадет ниже минимального требования для хранения данных, эта учетная запись не сможет отправлять исходящие транзакции до его пополнения. Учетная запись при этом не удаляется и не теряет свои данные; она просто становится неактивной для исходящих транзакций до тех пор, пока на нее не будет внесено достаточное количество токенов NEAR.

Заметка для разработчика: Решите заранее, будет ли ваше приложение покрывать депозит за хранение для пользователей во время онбординга или требовать от них поддержания собственного баланса. Многие протоколы покрывают расходы на хранение, чтобы снизить трение. Это реальное экономическое решение, связанное с онбордингом, которое влияет на привлечение пользователей, поэтому учитывайте его в модели затрат вашего dApp до запуска.

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

Субаккаунт NEAR — это аккаунт, чей ID содержит ID родительского аккаунта в качестве префикса. Например, 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. Иметь три ключа доступа: Full Access Key, хранящийся на ее аппаратном кошельке, Full Access Key на ее ноутбуке и Function Call Access Key, предоставленный dApp DeFi для торговли на основе сессий
4. Владеть двумя субаккаунтами (app.alice.near для развернутого игрового контракта и vault.alice.near для контракта накоплений), каждый из которых управляется независимо

ID аккаунта Алисы легко читается, и им удобно делиться. Ей никогда не приходится копировать 42-символьную шестнадцатеричную строку, чтобы получать токены или взаимодействовать с контрактом.

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

Для конечных пользователей модель аккаунта означает: читаемые идентификаторы аккаунтов, которые работают как имена пользователей, сессии dApp, не прерывающие взаимодействие всплывающими окнами кошелька, и модель ротации ключей, позволяющая восстановить аккаунт без зависимости от одной сид-фразы.

Часто задаваемые вопросы о модели учетных записей NEAR

В чем разница между именованным аккаунтом и неявным аккаунтом на NEAR?

Именованные аккаунты — это удобочитаемые идентификаторы (например, alice.near), зарегистрированные под доменным именем верхнего уровня, требуют небольшой внесения токенов NEAR при регистрации и выбираются пользователем. Неявные аккаунты — это 64-символьные шестнадцатеричные идентификаторы, полученные из публичного ключа Ed25519, не требуют регистрации и автоматически активируются при отправке токенов NEAR на ID аккаунта. Именованные аккаунты типичны для пользовательских кошельков и развертывания протоколов; неявные аккаунты распространены для бирж и программных инструментов. См. сравнительную таблицу именованных и неявных аккаунтов выше для полного пошагового сравнения.

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

Аккаунт NEAR может одновременно содержать неограниченное количество ключей доступа. У каждого ключа своя область разрешений: либо ключ полнофункционального доступа (Full Access Key) с неограниченными правами, либо ключ доступа к вызову функций (Function Call Access Key), ограниченный определенными методами смарт-контракта. Это позволяет пользователям использовать отдельные ключи для разных устройств или dApps без создания новых аккаунтов. Вы можете добавлять или отзывать отдельные ключи в любое время, не затрагивая остальные. Подробную информацию о каждом типе ключей см. в разделе о ключах доступа.

Что такое стейкинг хранилища (storage staking) в протоколе NEAR?

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

Может ли аккаунт NEAR содержать смарт-контракт?

Да. В любом аккаунте NEAR может быть развернут смарт-контракт. В отличие от Ethereum, где разделяются внешние учетные записи (Externally Owned Accounts — пользовательские аккаунты, которые не могут содержать код) и контрактные аккаунты (Contract Accounts — аккаунты с кодом, у которых нет приватного ключа), NEAR использует унифицированную модель аккаунтов, в которой любой аккаунт может одновременно иметь баланс токенов NEAR и развернутый программный код контракта. Смарт-контракты в NEAR компилируются в WebAssembly (WASM) из исходного кода на Rust или JavaScript, а не на Solidity. Полный сравнительный анализ архитектуры см. в разделе Сравнение с Ethereum.

Что произойдет, если баланс моего аккаунта NEAR опустится ниже требований к хранению данных?

Если баланс учетной записи NEAR опускается ниже минимума, необходимого для использования хранилища, учетная запись не может отправлять исходящие транзакции до тех пор, пока баланс не будет пополнен. Учетная запись не удаляется, и ее данные не теряются; она просто становится неактивной для исходящих транзакций до внесения достаточного количества токенов NEAR. Сохраненные данные остаются неповрежденными в блокчейне. Подробности о требованиях к балансу см. в разделе стейкинг хранилища на практике: что это означает для учетных записей и контрактов.

Что такое суб-учетная запись на NEAR и кто ею управляет?

Суб-аккаунт NEAR — это аккаунт, идентификатор (ID) которого содержит префикс родительского аккаунта. Например, app.alice.near является суб-аккаунтом alice.near, и только alice.near может создавать аккаунты в этом пространстве имен. После создания родительский аккаунт НЕ контролирует суб-аккаунт. Суб-аккаунт полностью независим: у него есть собственные ключи доступа, собственный баланс токенов NEAR и собственное состояние ончейн. Полномочия родителя по именованию ограничены только актом создания. Полное объяснение см. в разделе о суб-аккаунтах.

Чем протокол NEAR отличается от Ethereum с точки зрения аккаунтов?

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

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

Ключ полного доступа предоставляет неограниченные разрешения в отношении аккаунта: он может авторизовать переводы токенов, развертывание контрактов, а также добавление или удаление других ключей. Ключ полного доступа является учетной записью с наивысшим уровнем доверия для владельца аккаунта и должен храниться в аппаратном кошельке или офлайн. Ключ доступа для вызова функций ограничен для вызова конкретных методов на конкретном контракте, с необязательным лимитом токенов NEAR для оплаты газа. Он не может переводить балансы токенов или изменять другие ключи. Ключи полного доступа предназначены для владельцев аккаунтов; ключи доступа для вызова функций выдаются децентрализованным приложениям (dApps) для обеспечения взаимодействий, похожих на сеансы, без необходимости полного доступа к аккаунту. См. таблицу сравнения ключей для подробного сравнения.

Как выглядит идентификатор аккаунта NEAR?

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

Является ли NEAR Protocol proof of stake?

NEAR Protocol использует механизм консенсуса Proof-of-Stake (PoS). Валидаторы вносят NEAR-токены в стейкинг для участия в производстве блоков и получения наград протокола. Аккаунты валидаторов являются стандартными аккаунтами NEAR с развернутыми на них стейкинг-контрактами, что иллюстрирует унифицированную модель аккаунтов на практике. Стейкинг валидаторов — это отдельный механизм от стейкинга хранения; оба блокируют NEAR-токены, но служат совершенно разным целям.

Основные выводы и дальнейшие шаги

Модель аккаунта NEAR объединяет идентификацию аккаунта с правами доступа и управлением ончейн-хранилищем в единой архитектуре. Вместо того чтобы разделять пользовательские аккаунты и аккаунты контрактов, или ограничивать каждый аккаунт одним приватным ключом, NEAR встраивает гибкость и ограниченные права доступа непосредственно в уровень аккаунта.

Ключевые выводы:

• ID аккаунтов NEAR — это читаемые человеком именованные аккаунты (например, alice.near) или 64-символьные неявные аккаунты, полученные из публичного ключа, а не шестнадцатеричные адреса
• Именованные аккаунты требуют внести токены NEAR при регистрации; неявные аккаунты активируются автоматически при первом получении токенов
• Каждый аккаунт NEAR может одновременно хранить несколько ключей доступа, каждый с уникальной областью разрешений
• Ключи полного доступа разрешают все действия аккаунта и принадлежат владельцу аккаунта; ключи доступа к вызову функций имеют область действия для конкретных методов контракта и выдаются приложениям
• Любой аккаунт NEAR может хранить как баланс токенов NEAR, так и развернутый смарт-контракт. Отдельного типа аккаунта контракта не существует
• Стейкинг хранения требует заблокированного баланса токенов NEAR, пропорционального потреблению ончейн-хранилища. Это возвратный депозит, а не комиссия, и он отличается как от комиссий за газ, так и от стейкинга валидаторов
• Суб-аккаунты следуют иерархическому соглашению об именовании, но родительский аккаунт не контролирует суб-аккаунты после создания. Каждый суб-аккаунт полностью автономен

Разработчики, готовые к созданию продуктов на NEAR, могут начать с документации по модели аккаунтов NEAR Protocol,), в которой представлены технические спецификации и справочные материалы по SDK. Для получения подробной информации о стекинге хранилища и текущих параметрах ставок ознакомьтесь с официальной документацией NEAR по стекингу хранилища) перед принятием архитектурных решений, так как параметры протокола могут изменяться в процессе управления. Пользователи, создающие свой первый аккаунт NEAR, могут сделать это через интерфейс кошелька, совместимого с NEAR, такого как MyNEARWallet или Meteor Wallet.

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