NEAR для разработчиков бэкенда: Ваши навыки, децентрализованные

Введение
Если вы сегодня создаете бэкенды, вы уже знаете, как проектировать API, хранить состояние и управлять пользователями. Протокол NEAR позволяет вам использовать те же инстинкты — просто на децентрализованной сети вместо ваших собственных серверов. Думайте о NEAR как о “бэкенде, который вам не нужно хостить”. Ваша бизнес-логика работает как умные контракты (мини-программы), ваши данные находятся в реплицируемом хранилище, управляемом сетью, и подлинность пользователя проверяется криптографией, а не паролями. В этом уроке мы сопоставим знакомые идеи бэкенда с концепциями NEAR, пройдем через простой пример в стиле Twitter и покажем, как работают чтение и запись. В конце вы увидите, что переход от web2 к NEAR — это адаптация, а не переосмысление.

NEAR как децентрализованный бэкенд

Представьте, что вы развертываете сервис, который работает на глобальном кластере, который вы не поддерживаете. Это NEAR. Ваше приложение — это аккаунт (например, twitter-app.yourname.near) с собственным кодом и данными. Независимые валидаторы (узлы сети) хранят эти данные и делают их доступными. Когда пользователи взаимодействуют, сеть достигает окончательности — неоспоримого согласия на результат — обычно за ~1–2 секунды.

Проверка терминов

• Валидатор: узел, который запускает программное обеспечение NEAR, выполняет контракты и участвует в консенсусе.

• Окончательность: момент, когда изменение блокируется и не может быть отменено.

Состояние приложения: пространственное и реплицируемое

На NEAR данные каждого приложения ограничены его аккаунтом — как отдельная схема базы данных или пространство имен.

• Изолированное состояние: Только ваш код контракта может изменять хранилище ключ-значение вашего приложения.

• Журнал аудита: Каждое изменение записывается в цепочку, создавая неизменяемую, проверяемую историю.

• Высокая доступность: Множество валидаторов хранят и обслуживают ваше состояние. Если некоторые отключатся, ваше приложение останется доступным.

• Быстрая окончательная согласованность: Запросы обрабатываются, запускается консенсус, и в течение ~1–2 секунд новое состояние становится окончательным по всей сети.

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

Бэкенд-логика: Умные контракты (Wasm)

Ваши бизнес-правила находятся в умном контракте — небольшой программе, скомпилированной в WebAssembly (Wasm) и хранящейся под аккаунтом вашего приложения.

• Варианты языков: Rust является наиболее распространенным выбором для производительности и безопасности. JavaScript/TypeScript также используются с помощью инструментов NEAR, которые компилируются в Wasm. [подтвердите, если вы хотите подчеркнуть только Rust или включить near-sdk-js/TypeScript явно.]

• Исполнение в песочнице: Wasm эффективен и работает в безопасной, детерминированной среде на валидаторах.

• Четкие границы: Каждый контракт управляет своим состоянием и предоставляет функции, которые вызывают клиенты.

Проверка терминов

• Умный контракт: бэкенд-код, который работает на блокчейне.

• WebAssembly (Wasm): бинарный формат для быстрого, переносимого выполнения.

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

Вместо паролей NEAR использует аккаунты и цифровые подписи.

• Транзакции: Любое изменение состояния — это подписанная транзакция от аккаунта NEAR.

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

• Контроль доступа: Создавайте проверки типа “только этот аккаунт может удалить свой твит”, используя идентификатор аккаунта вызывающего.

Аналогия: Это как JWT без сервера входа — идентификация встроена в платформу.

Простой пример в стиле Twitter (Концептуально)

Предположим, вы моделируете Твит { id, author, text, timestamp, likes }.

• Методы записи (изменение состояния):

  • post_tweet(text): создает твит, автор = predecessor_account_id.

  • like_tweet(id): увеличивает счетчик лайков.

  • delete_tweet(id): только автор твита может удалить.

• Методы чтения (просмотр):

  • get_tweet_by_id(id)

  • get_all_tweets(from, limit)

  • get_tweets_by_author(author, from, limit)

По дизайну думайте “простые, индексированные образцы доступа”. Сложные ад-хок запросы (например, объединения) не существуют в контракте, поэтому планируйте свои структуры данных и итераторы с учетом этого.

Как клиенты вызывают ваш контракт

Существуют два вида вызовов, отраж

Updated: 26 сентября, 2025