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

Содержание

• Что такое NEAR Protocol?
• TL;DR: Модель учетных записей NEAR в общих чертах
• Что такое модель учетных записей NEAR?
• Именованные и неявные учетные записи: Как NEAR идентифицирует пользователей
• Субаккаунты: Иерархическая организация учетных записей на NEAR
• Ключи доступа NEAR: Полный доступ против разрешений на вызов функций
• Стейкинг хранилища: Почему учетные записи NEAR требуют минимальный баланс
• Модель учетных записей NEAR против Ethereum: Сравнительный анализ
• Начало работы: Создание и управление вашей учетной записью NEAR
• Часто задаваемые вопросы: Модель учетных записей NEAR
• Заключение: Что означает модель учетных записей NEAR для разработчиков и пользователей

Что такое NEAR Protocol? (Краткое введение)

NEAR Protocol — это блокчейн Уровня 1 (Layer-1) на базе алгоритма proof-of-stake, созданный для удобства разработчиков, с низкими и предсказуемыми комиссиями за транзакции и архитектурой шардинга, предназначенной для масштабирования без ущерба для удобства использования. Основанный Ильёй Полосухиным и Александром Скидановым, NEAR Protocol с самого начала разрабатывался с приоритетом на опыт разработчиков и доступность для конечных пользователей, а не на попытку внедрить удобство использования в архитектуру, изначально предназначенную для других целей.

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

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

TL;DR: Краткий обзор модели аккаунта 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](https://docs.near.org/concepts/basics/accounts/model).

Именованные и неявные аккаунты: Как NEAR идентифицирует пользователей

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

Именные аккаунты: человекочитаемые идентификаторы в блокчейне

Именованные аккаунты на NEAR — это удобочитаемые идентификаторы аккаунтов, которые следуют доменно-подобной структуре, заканчиваясь на .near в мейннете и .testnet в тестнете, заменяя криптографические хэш-строки, используемые блокчейнами, такими как Ethereum.

Разница очевидна: alice.near против 0x742d35Cc6634C0532925a3b844Bc454e4438f44e. Оба являются валидными идентификаторами блокчейна, но один читаем, а другой требует тщательного использования для проверки при копировании и вставке. Представьте именованный аккаунт NEAR как адрес электронной почты: читаемый и привязанный к личности, а не случайную строку символов, которая требует сравнения символ за символом для проверки.

Именованные аккаунты следуют определенным правилам именования: ID аккаунтов представляют собой буквенно-цифровые строки, могут использовать точки в качестве разделителей, должны иметь длину от 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 на этот идентификатор аккаунта без необходимости каких-либо действий со стороны существующего аккаунта.

Ключевое практическое отличие: для именованного аккаунта требуется существующий ончейн-аккаунт для спонсирования его регистрации через транзакцию, в то время как имплицитный аккаунт создается автоматически при поступлении средств на производный идентификатор аккаунта. Это делает имплицитные аккаунты полезными в контекстах, где требуется начальная загрузка с нуля, или где человекочитаемые имена не нужны. Криптовалютные биржи обычно используют имплицитные аккаунты при зачислении депозитов 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 суб-аккаунты представляют собой практический шаблон архитектуры. Поскольку любой аккаунт 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.

Ключи полного доступа: Неограниченный контроль над аккаунтом

Ключ полного доступа (Full Access Key) на NEAR — это пара ключей, которая может выполнять любые действия с аккаунтом, к которому она привязана: переводить токены, развертывать смарт-контракты, создавать субаккаунты, добавлять или удалять другие ключи и удалять сам аккаунт.

Поскольку ключ полного доступа управляет всей учетной записью, он имеет тот же профиль риска, что и мастер-пароль. Ключи полного доступа никогда не следует передавать сторонним приложениям; их следует хранить в «холодном» хранилище (аппаратный кошелек или автономное хранилище) для любой учетной записи со значительными средствами. В случае компрометации ключа полного доступа злоумышленник получает полный контроль над учетной записью без встроенного механизма восстановления, если только он не был настроен заранее.

Сравнение с Ethereum здесь весьма показательно. В Ethereum ваш единственный приватный ключ для внешнего аккаунта (EOA) функционирует как ключ полного доступа (Full Access Key): он управляет всем, и не существует нативного способа предоставить dApp ключ с более низким уровнем доступа для взаимодействия с конкретным контрактом. Каждое подключение к dApp через MetaMask задействует ваш полный ключ аккаунта в процессе подписания транзакции. Это ограничение единственного ключа — именно та проблема, для решения которой в Ethereum предназначена абстракция аккаунта EIP-4337. В NEAR это решение было встроено в базовую модель аккаунта.

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

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

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

Сценарий использования сеансовой аутентификации — это то, где ключи доступа для вызова функций демонстрируют свою практическую ценность для разработки dApp. Когда вы подключаете dApp к своей учетной записи NEAR, dApp запрашивает ключ доступа для вызова функций с областью действия, ограниченной собственным контрактом. Этот ключ сохраняется в вашей сессии браузера. С этого момента dApp может отправлять транзакции от вашего имени (одобрение сделки, минтинг NFT, взаимодействие с игровым контрактом) без запроса на подписание каждого отдельного действия. Ваш ключ полного доступа никогда не покидает ваш безопасный кошелек. Если dApp будет скомпрометирован или окажется вредоносным, ущерб будет ограничен: злоумышленник сможет вызывать только те методы контракта, к которым был привязан ключ, и только в пределах установленного лимита. Ключ доступа для вызова функций работает как сессионный токен в веб-приложении: он предоставляет временный, ограниченный доступ к конкретным действиям, не раскрывая полные учетные данные аккаунта.

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

Стейкинг хранения: Почему учетные записи 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 в Bitcoin, где балансы отслеживаются как неизрасходованные выходы транзакций, а не как состояние аккаунта; разница между NEAR и Ethereum заключается в структуре аккаунтов и разграничении прав доступа, а не в фундаментальной парадигме.

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

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

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

Параллель с ключами доступа к вызову функций (Function Call Access Keys) 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: он хранит ваш приватный ключ и предоставляет его dApps для подписи транзакций. Аккаунт 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 более безопасным?

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

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

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

Являются ли комиссии за газ тем же, что и стейкинг хранилища?

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

Как модель аккаунтов NEAR соотносится с абстракцией аккаунтов Ethereum (EIP-4337)?

Собственная система разрешений NEAR с использованием нескольких ключей достигает многих целей, для реализации которых в Ethereum предназначен EIP-4337, включая ограниченные разрешения на основе сессий для взаимодействия с dApp и программируемую логику ключей. Эти два подхода являются архитектурно различными реализациями пересекающихся идей: подход NEAR является нативным для базового протокола, в то время как EIP-4337 наслаивает логику кошелька на базе смарт-контрактов поверх существующей модели EOA в Ethereum. Они решают схожие проблемы через разные архитектуры. Подробный анализ смотрите в разделе сравнения NEAR и Ethereum.

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

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

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

Аккаунт NEAR может одновременно содержать несколько ключей доступа, при этом каждому ключу назначается свой тип разрешений (Full Access Key или Function Call Access Key), а для ключей типа Function Call Access Key — своя область действия контракта и лимит газа. Жестко задокументированного лимита на количество ключей для одного аккаунта не существует. Возможность использования нескольких ключей — это то, что отличает модель разрешений 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, прежде чем полагаться на конкретные числовые значения для разработки или операционного планирования. Данный контент носит исключительно информационный характер и не является финансовой или инвестиционной рекомендацией.