Файл token что это
JSON Web Token (JWT) — это открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON. Как правило, используется для передачи данных для аутентификации в клиент-серверных приложениях. Токены создаются сервером, подписываются секретным ключом и передаются клиенту, который в дальнейшем использует данный токен для подтверждения своей личности.
В этой статье разберу, что такое Access токен, Refresh токен и как с ними работать.
Для дальнейших разборов будет использован токен:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9.E4FNMef6tkjIsf7paNrWZnB88c3WyIfjONzAeEd4wF0
После того, как посетитель прошел авторизацию в нашей системе, указав свой логин и пароль, система выдает ему 2 токена: access token и refresh токен.
После чего посетитель, когда хочет получить с сервера данные, например, свой профиль, вместе с запросом он передает Access токен, как на примере выше. Сервер, получив его проверяет, что он действительный (об этом чуть ниже), вычитывает полезные данные из него (тот же user_id) и, таким образом, может идентифицировать пользователя.
Токен разделен на три основные группы: заголовок, полезные данные и сигнатура, разделенные между собой точкой.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9 - это первая часть токена - есть заголовок. Она закодирована в Base64 и если её раскодировать, получим строку:
Это можно проверить прям в браузере, выполнив в консоле или js коде:
const header = atob('eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9'); console.log(header);typ - это наш тип токена JWT. Alg - алгоритм шифрования HMAC-SHA256. Их может быть несколько, но здесь буду говорить именно об этом алгоритме.
Вторым блоком идет eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9
Это есть полезные данные, так же закодированные в Base64. После раскодирования получим:
Данные могут быть любыми. Главное, чтобы по ним можно было идентифицировать пользователя. В нашем случае - это user_id и exp - время окончания действия текущего токена.
Поскольку необходимо ограничивать токен по времени, поле exp обязательно. По нему можно проверить, актуален ли токен или нет.
Последняя часть токена - наиболее важная. У нас это E4FNMef6tkjIsf7paNrWZnB88c3WyIfjONzAeEd4wF0
Как вы уже могли заметить - первые данные передаются практически в открытом виде и раскодировать их может любой. Но шифровать их нет необходимости. Цель токена - подтвердить, что эти данные не были изменены. Вот для этих целей и выступает сигнатура. И чтобы её сгенерировать нужен приватный ключ. Ну или некая секретная фраза, которая находится только на сервере. Только с помощью этого ключа мы можем создать сигнатуру и проверить, что она была создана именно с помощью его.
Она получается примерно следующим образом:
Берем заголовок, например и кодируем его в base64, получаем ту самую часть eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Тоже самое проделываем с данными eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9
После этого склеиваем их и получаем eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9
Далее эти данные шифруем с помощью нашего алгоритма HMAC-SHA256 и ключа.
const header = '<"alg":"HS256","typ":"JWT">' // строка const payload = '' // строка // кодируем заголовок и данные в base64 const headerBase64 = base64urlEncode(header) const payloadBase64 = base64urlEncode(payload) // склеиваем точкой полученные строки const data = headerBase64 + '.' + payloadBase64 // кодируем алгоритмом шифрования нашим ключем шифрования const secret = '123456' const sig = HMAC-SHA256(data, secret) // и, наконец, получаем окончательный токен const jwt = data + '.' + sigДля проверка токена необходимо проделать ту же операцию.
Берем склейку заголовок + данные, кодируем с помощью алгоритма HMAC-SHA256 и нашего приватного ключа. А далее берем сигнатуру с токена и сверяем с результатом кодирования. Если результаты совпадают - значит данные подтверждены и можно быть уверенным, что они не были подменены.
Основной токен, про который шла речь выше, обычно имеет короткий срок жизни - 15-30 минут. Больше давать не стоит.
Как только время выйдет, пользователю снова придется проходить авторизацию. Так вот чтобы этого избежать, существует Refresh токен. С помощью него можно продлить Access токен.
В действительности, Refresh токен обязательно должен быть одноразовым. Его задача - получить новую пару токенов. Как только это было сделано, предыдущий токен будет считаться недействительным. Срок жизни Refresh токена уже может быть большим - до года, а может даже и больше.
У него, обычно, нет какой-то структуры и это может быть некая случайная строка.
Генерируется Access токен и после случайная строка, например T6cjEbghMZmybUd_fhE
С нашего нового Access токена eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyX2lkIjoxLCJleHAiOjE1ODEzNTcwMzl9.E4FNMef6tkjIsf7paNrWZnB88c3WyIfjONzAeEd4wF0 беру последние шесть знаков, получаю Ed4wF0
Склеиваю и получаю рефреш токен T6cjEbghMZmybUd_fhEEd4wF0
Это сделано для привязки Access токена к Refresh. Для получения новых токенов необходимо передать эти два токена. Делается проверка на их связку и только после валидируется Access токен. Если и второй этап прошел успешно, тогда получаем с базы данных по текущему user_id рефреш токен и сверяем с тем, что к нам пришел. Если они совпадают, тогда генерируются новые токены и в базе данных обновляется Refresh токен на новый.
Refresh токен хранится в LocalStorage и используется только когда Access токен перестал быть актуальным.
Представим ситуацию, когда у нас каким-то образом украли Access токен. Да, это уже плохо и где-то у нас брешь в безопасности. Злоумышленник в этом случае сможет им воспользоваться не более чем на 15-30 минут. После чего токен "протухнет" и перестанет быть актуальным. Ведь нужен второй токен для продления.
Если украли Refresh токен, то без Access токена (который недоступен в JS) продлить ничего нельзя и он оказывается просто бесполезным.
Самая неприятная ситуация - это когда удалось увести сразу 2 токена. В этом случае злоумышленник сможет пользоваться системой неограниченное время. Точнее когда пользователь попытается войти в систему, его не пустит, т.к. его Refresh токен уже будет неактуальным, и ему придется вводить логин и пароль. Только в этом случае злоумышленник потеряет контроль над чужой учетной записью.
В своей реализации Refresh токена использовал общую длину 24 знака. Первые 6 знаков - это дата его "протухания", следующие 12 знаков - случайно сгенерированные данные. И в конце 6 знаков - это часть Access токена последней части сигнатуры.
Дату протухания внедрил прям в токен с той целью, чтобы не хранить эту информацию где-то в другом месте, например, в базе данных.
Дата содержит год, месяц, день, час и минуты. Хранится в ASCII
Кодирование даты на Golang:
// приводим к целочисленному числу uint32. Итого 32 бита. // расчет простой: год 12 бит, месяц 4 бита, день 5 бит и т.д. Таким образом в аккурат умещаемся в 32 бита или 4 байта. date := uint32(year<<20) | uint32(month<<16) | uint32(day<<11) | uint32(hour<<6) | uint32(minute) // в цикле кодируем байты в ASCII. 1 знак это шесть бит. Итого и получаем шесть знаков даты по таблице ASCII - печатные знаки. for n := 0; n < 6; n++ < b6Bit = byte(date>>i) & 0x3F sBuilder.WriteByte(byte8bitToASCII(b6Bit)) . >Всю реализацию на Go можно изучить на Github-е
В этой статье попытался рассказать о взаимодействии двух токенов и как ими пользоваться. В сети достаточно много информации о Access токенах, однако мало, как мне показалось, информации о Refresh токенах.
Когда вы входите в веб-приложение, браузер получает файл cookie с сервера, сохраняет его и отправляет с каждым последующим запросом, чтобы сервер мог убедиться, что запросы поступают от одного и того пользователя.
Чтобы лучше понять, как работают файлы cookie, разобьем этот процесс на 5 частей.
1. Пользователь входит в приложение со своими учетными данными
2. Сервер проверяет учетные данные и создает сеанс в базе данных
Хотя сеанс можно создать в памяти, он не масштабируется.
3. Сервер отправляет файл cookie браузеру, включая его в заголовок Set-Cookie
В дополнение к этому в cookie могут храниться такие сведения, как дата истечения срока действия, домен и возраст. Пример ответа с несколькими заголовками cookie будет выглядеть следующим образом:
4. Браузер сохраняет cookie в хранилище и отправляет его с последующими запросами
Найти все сохраненные в браузере файлы cookie можно в хранилище файлов cookie в разделе приложения с помощью инструментов разработчика (devtools).
5. Когда пользователь выйдет из системы, сервер удалит сеанс из базы данных
Как только пользователь выйдет из системы, у сервера истечет срок действия файла cookie и сеанс в базы данных будет очищен. Браузер делает то же самое, удаляя файл cookie из хранилища.
Мы разобрались, как работает аутентификация на основе cookie, теперь рассмотрим фичи, плюсы и минусы этой схемы.
Это полностью автоматизированный процесс
Если вы используете файлы cookie для аутентификации, вам не нужно ничего больше разрабатывать для добавления их в запросы. Браузер позаботится об обработке файлов и автоматически добавит cookie для всех запросов.
Хотя этот автоматизированный процесс облегчает труд разработчиков, здесь есть несколько недостатков. Например, некоторые запросы не требуют никакой аутентификации, но при таком подходе куки будут отправляться в каждом запросе.Безопасность
Cookie не имеют надежной защиты от атак, и они в основном уязвимы для атак с использованием межсайтового скриптинга (XSS) и подделки межсайтовых запросов (CSRF) .
Мы можем явно изменить заголовки файлов cookie, чтобы защитить их от таких атак.Кроме того, можно использовать атрибут SameSite в заголовке файла cookie для эффективного предотвращения CSRF-атак.
Есть 3 значения, которые можно использовать для атрибута SameSite :
- SameSite = Lex гарантирует, что браузер не будет отправлять файлы cookie по межсайтовым запросам (это поведение по умолчанию, если атрибут SameSite не определен).
- SameSite = Strict будет следить за тем, чтобы браузер отправлял cookie только для запросов с того же сайта.
- SameSite = None позволит отправлять куки как с межсайтовыми, так и с внутрисайтовыми запросами.
Обычно работают в одном домене
Файлы cookie работают только в одном домене, если вы специально их не настроили.Хотя со стороны это выглядит как ограничение, но это одна из самых сильных функций для обеспечения единого источника.
Если ваш фронтенд и бэкенд лежат в разных доменах или поддоменах, необходимо явно указать это в файле cookie в белом списке. В противном случае браузер не отправит куки вместе с запросом.
Не подходит для API
Если вы создаете API для предоставления услуг клиентам, cookie – это не лучший вариант. Если клиент не является браузером, это усложнит работу.Например, если вы разрабатываете мобильное приложение, наличие файлов cookie усложнит управление файлами по сравнению с токеном.
Могут возникнуть проблемы с масштабируемостью
Как уже объяснялось, сервер отвечает за конфигурацию файлов cookie, и нам нужно сохранить сеансы в базе данных для каждого пользователя.Хотя существуют хорошо зарекомендовавшие себя способы управления масштабируемостью (например, использование для хранения сеансов СУБД наподобие Redis), это все равно добавляет сложности. По мере роста количества пользователей, могут возникнуть проблемы с масштабированием и управлением сеансами.
Подходит для хранения дополнительных данных
Поскольку этот подход поддерживает отдельные сессии для каждого пользователя, мы можем хранить прикрепленные к ним данные.С помощью файлов cookie и сессий можно хранить дополнительные данные персонализации, контроля доступа и сами сессии – это позволяет использовать их для последующих запросов.
Все эти манипуляции можно провести и с помощью токенов. Например, токены JWT позволяют хранить Claim-объекты. Поскольку это увеличит размер токена, сохранение большего их количества повлияет на нагрузку сети.Это не имеет смысла, если речь идет об одном запросе, но преимущества становятся заметны, когда все агрегируется и масштабируется.
Аутентификация на основе токенов
Этот способ был введен для устранения основанного на куках аутентификации. Особенности подхода – требуется ручная реализация и токены сохраняются на стороне клиента.Когда вы входите в веб-приложение, сервер проверяет учетные данные и отправляет зашифрованный токен в браузер. Браузер сохраняет токен и добавляет его в заголовок авторизации будущих запросов.
Стандартные реализации токен-подхода в разы сложнее описанных выше. Например, в OpenID Connect применяется несколько потоков аутентификации для различных сценариев использования. Чтобы лучше понять, как работают токены, разобьем процесс на четыре части и в качестве примера используем JWT (JSON Web Token) – наиболее широко используемый стандарт.
1. Пользователь входит в приложение со своими учетными данными
2. Сервер проверяет учетные данные, генерирует токен, подписывает его секретным ключом и отправляет в браузер
При передаче о бычно необходимо использовать шифрование (например, SSL) для защиты канала.
На стороне сервера можно использовать библиотеку NPM (такую как jsonwebtoken) для создания токенов:
Сгенерированный с помощью jsonwebtoken токен будет выглядеть следующим образом:
Токен состоит из 3 частей: header , payload и signature ( header . payload . signature ). Они разделены символом . , и вы можете использовать этот сервис для анализа информации.
3. Сохранение токена в хранилище браузера и добавление в запросы с помощью JavaScript
Кроме того, можно использовать функцию jwt.decode() из библиотеки jsonwebtoken для декодирования токена.
4. При выходе пользователя из системы токен вручную удаляется из хранилища
Как только пользователь выйдет из системы, необходимо вручную очистить находящийся в хранилище токен, чтобы сделать его недоступным для дальнейших запросов.Мы разобрались, как работает аутентификация на основе токенов, теперь рассмотрим фичи, плюсы и минусы этой схемы.
Это stateless-механизм
В отличие от cookie-подхода, вариант с токенами не имеет состояния. Это означает, что он не сохраняет никакой информации о пользователях в базе данных или на сервере. Сервер отвечает только за создание и проверку токенов, что позволяет реализовывать более масштабируемые решения.
Проблемы безопасности
Сохраненные в браузере токены могут быть уязвимы для атак XSS, если приложение позволяет внедрять внешние сценарии JavaScript.Токен не имеет состояния и если он установлен снаружи, то его невозможно отозвать до истечения срока жизни. Поэтому важно, чтобы он имел минимальный срок годности.
Заключение
Подходы, основанные на токенах и файлах cookie – два наиболее часто используемых в веб-приложениях механизма аутентификации. В этой статье мы выяснили, как они работают, а также разобрали их особенности, плюсы и минусы.Ни один из этих методов не является на 100% совершенным, и каждый имеет свои недостатки. При выборе метода аутентификации стоит использовать наиболее соответствующий требованиям проекта и допилить его, а не стремиться к идеалу.
Статьи из этого цикла публикуются бесплатно и доступны всем. Мы убеждены, что каждый имеет право на базовые знания о защите своих данных.
Другие статьи цикла:
Если для тебя эти материалы тривиальны — отлично! Но ты сделаешь доброе дело, отправив ссылку на них своим друзьям, знакомым и родственникам, менее подкованным в технических вопросах.
Подписываемся под данными
И людям, и программам нужно знать, что данные были созданы доверенным источником и остались неизменными. Для этого была придумана технология генерации специального хеша (подписи), который подтверждает целостность информации и достоверность ее отправителя/создателя. Для создания этой самой подписи используется схема из нескольких шагов, цель которых — защитить данные от подделки.
Придумываем коды доступа
Создание безопасных одноразовых паролей состоит из двух этапов:
- Первичная настройка — включение двухфакторной аутентификации.
- Использование пароля — непосредственный ввод кода и отправка для проверки.
В таком случае пользователь с помощью приложения, доступного на любом устройстве, сможет генерировать коды в соответствии со всеми стандартами.
Первоначальная настройка приложения заключается в обмене секретным ключом между сервером и приложением для аутентификации. Затем этот секретный ключ используется на устройстве клиента, чтобы подписать данные, которые известны и серверу, и клиенту. Этот ключ и служит главным подтверждением личности пользователя при вводе пароля на сервере.
На самом деле весь секрет — последовательность из случайных символов, которые закодированы в формате Base32. Суммарно они занимают не меньше 128 бит, а чаще и все 190 бит. Эту последовательность и видит пользователь как текст или QR-код.
Так выглядит код QR для обмена секретом
Тот же самый секрет, только текстом
Как приложение создает одноразовые коды? Все просто: приложение с помощью ключа хеширует какое-то значение, чаще всего число, берет определенную часть получившегося хеша и показывает пользователю в виде числа из шести или восьми цифр.
С самого начала для этого числа разработчики использовали простой счетчик входов. Сервер считал количество раз, которое ты заходил, например, на сайт, а приложению было известно, сколько раз ты запрашивал одноразовый пароль. Именно это значение и использовалось для создания каждого следующего одноразового кода. В современных приложениях вместо счетчика берется текущее время — и это намного удобнее для пользователя: счетчики входов часто сбивались, и их приходилось настраивать заново.
Теперь давай попробуем посчитать код для авторизации самостоятельно. Для примера представим, что мы решили прямо в Новый год опубликовать фотографию красивого фейерверка и, чтобы это сделать, нужно войти в свой аккаунт, а значит, нам не обойтись без одноразового пароля.
Возьмем время празднования Нового года в формате UNIX ( 1577811600000 ) и посчитаем порядковый номер нашего пароля: поделим на 30 секунд — 52593720 . Воспользуемся нашим секретом и вычислим хеш — по стандарту RFC 6238 это функция SHA-1:
Не забудь про аргумент -n для команды echo , чтобы в ее выводе не было ненужного перевода строки, иначе хеш будет другим.
Теперь дело за малым: нужно получить шесть цифр, которые мы и будем отправлять на сервер при авторизации. Возьмем последние четыре бита хеша — сдвиг, — это будет число a , или 10. Именно по этому сдвигу расположен наш код, который пока в виде байтов, — 03b08b12 = 61901586 . Отбросим все цифры этого числа, кроме шести последних, и получим наш новенький, готовый к использованию одноразовый код — 901586 .
Ни одно современное приложение не спрашивает пароль у пользователя постоянно, поскольку пользователей это раздражает. Именно поэтому разработчики и ученые-криптографы придумали токены, которые могут заменить собой пару логин — пароль. Перед учеными стояла задача не столько скрыть какую-то информацию, сколько создать общий стандарт для ее хранения и подтверждения ее надежности. Для всего этого была придумана технология JSON Web Token (JWT).
Как работает JWT?
Если есть данные, достоверность которых следует подтвердить, нам надо подписать их секретным ключом, используя HMAC. Для этого применяется такой же способ хеширования, что и для одноразовых паролей, только вместо шести цифр берется весь хеш целиком. Единственная разница — это сам алгоритм хеширования: в таких токенах SHA-1 считают слишком коротким и небезопасным, поэтому обычно используют SHA-256.
Главная задача JWT — подтверждение личности создателя токена и сопутствующих данных. Обычно содержимое токена — логин или другой идентификатор пользователя.
Давай попробуем создать свой токен. Продолжим нашу маленькую историю с публикацией фотографии фейерверка в соцсети: мы ввели одноразовый пароль, сервер подтвердил нашу личность и хочет выдать токен, чтобы мы смогли с его помощью открыть наше приложение.
Любой токен состоит из трех частей: заголовка со служебной информацией, данных и подписи. Так как стандартом безопасности считается SHA-256, то мы запишем его в наш заголовок.
Внутри самого токена будет храниться информация об идентификаторе аккаунта, в который мы только что вошли.
Этот хеш нам тоже надо перевести в кодировку Base64 и затем присоединить к уже имеющейся строке из заголовка и данных: eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjogMTIzNDU2fQ.4Ka0ipYe4/x-s4r82xqO8i77BXLh1TM7hdsqpmkZ6Y4 — это и есть наш токен. Можно пользоваться!
Так выглядит наш токен
Подробнее про стандарт JWT можно почитать на сайте организации RFC, а про реализацию для своего любимого языка — на сайте jwt.io.
Заключение
Теперь ты знаешь, что происходит каждый день, когда ты открываешь браузер и заходишь в какой-нибудь веб-сервис. Понимая, как это работает, ты сможешь лучше защитить свои данные, а возможно, даже решишь применить какой-то из этих методов в своих разработках.
Согласно статистике «Яндекса», число поисковых запросов по аббревиатуре NFT в этом октябре выросло по сравнению с тем же месяцем прошлого года в 100 раз: с 1940 до почти 200 тыс. раз. «Известия» разобрались, как и когда появились первые NFT-токены, чем они отличаются от криптовалют, что дают своему владельцу и как создать такой токен самостоятельно.
Что такое NFT-токен простыми словами
NFT-токены — новое явление для широкой аудитории, на которое возлагают большие надежды в разных отраслях экономики. В беседе с «Известиями» учредитель цифровой экосистемы DBX Игорь Захаров отметил, что интерес к этой технологии сейчас проявляют на рынке недвижимости. Благодаря некоторым особенностям в ближайшем будущем они могут использоваться для практически мгновенной передачи прав на объекты имущества, минуя привычные «бумажные» процедуры. «NFT-зация», вероятнее всего, коснется и сферы защиты интеллектуальной собственности, где станет одним из основных инструментов. Уже сейчас такие токены используются в онлайн-играх и виртуальных мирах, при защите доменов, идентификации и сертификации цифровых объектов.
Директор Binance в Восточной Европе Глеб Костарев объясняет, что всё дело в уникальности и незаменимости NFT-токенов. Хотя они построены на технологии блокчейна, как и криптовалюты, именно эти два качества в корне отличают NFT от «крипты».
«Взаимозаменяемость — это способность актива быть взаимозаменяемым с активами того же типа. Например, один биткоин равен и может быть обменен на другой биткоин. В то же время, карточка № 1 / 99 Keldon Johnson Holo Icon Top Shot не является взаимозаменяемой, поскольку существует в единственном экземпляре», — говорит собеседник «Известий».
Чисто технически выпустить собственный NFT-токен несложно. В общем виде, рассказывает Игорь Захаров, нужно сделать файл, выбрать платформу для «чеканки монет» и подключить к ней свой электронный кошелек. Затем следует загрузить файл на платформу, установить характеристики сделки и создать описание цифрового актива. После этого владелец может начать «чеканку», на оплату которой придется потратить некоторое количество цифровой валюты.
Руководитель финтех-компании Exantech Денис Восквицов приводит более конкретный пример на основе одной из самых популярных мировых блокчейн-сетей Etherium.
«Технически, при реализации на сети Ethereum, это смарт-контракт, соответствующий стандарту ERC721. Разница заложена в названии — non fungible token — невзаимозаменяемый. В случае с обычным токеном или криптовалютой каждая единица равнозначна любой другой. Каждый NFT-токен уникален и просто так его, по условиям смарт-контракта, нельзя заменить на другой», — говорит он.
Свои решения есть и у некоторых криптобирж. Так, Глеб Костарев рассказывает, что на маркетплейсе Binance NFT поддерживается большинство графических и аудиоформатов: JPG, PNG, GIF, PDF, MP4, MP3, MPEG, AVI, WAV и SVG. После загрузки информации пользователем команда маркетплейса утверждает контент (обычно в течение 4–8 часов), после чего он может быть выставлен на аукцион или продан по фиксированной цене.
«Создателям важно помнить, что NFT не может быть изменен или исправлен после создания, чтобы создать исправленный/новый NFT, будет необходимо начать процесс заново», — говорит Костарев.
Откуда ноги растут
Собеседники «Известий» рассказывают, что единого мнения по поводу того, кто и когда выпустил первый в истории NFT-токен, в экспертном сообществе нет. Однако можно с уверенностью упомянуть несколько исторически важных для актива точек.
По словам Дениса Восквицова, эксперименты по созданию NFT начались еще в 2013 году, но долгое время оставались «игрушкой» для разработчиков. Первый более-менее массовый проект возник в 2017 году — это были Crypto Punks, выпущенные американской студией Larva Labs.
«Это были просто уникальные изображения мультяшных персонажей, которые можно было покупать, продавать, передавать. В том же 2017 году вышла полноценная блокчейн-игра Crypto Kitties, которая привлекла самое большое внимание в этой сфере. Там можно было выращивать котят с помощью NFT-токенов, скрещивать или продавать. Проект привлек много денег и стал заметным шагом к дальнейшей популяризации NFT», — рассказывает Восквицов. Игорь Захаров добавляет, что этот проект был создан в сети Etherium, за внутреннюю валюту которой и покупались NFT-животные.
Глеб Костарев вспоминает еще несколько проектов: Colored Coins и Counterparty, написанные на скриптовом языке блокчейна Bitcoin.
«Некоторые называют первым в истории полноценным NFT проект Etheria, его даже показали вживую на DEVCON, первой конференции разработчиков Ethereum в Лондоне. А кто-то говорит, что первыми стали CryptoPunks и CryptoKitties», — перечисляет собеседник «Известий».
Как продают NFT-искусство
Денис Восквицов объясняет, что миллионные ценники в реальной валюте на NFT-токены появляются из-за того, что, как и для любого коллекционного предмета, цену определяют рынок и число желающих его купить.
«Тут токены ничем не отличаются от картин. Права сильно зависят от условия выпуска токенов. На данный момент не существует юридических рамок, которые позволяли бы однозначно заявить права на основе владения такими токенами», — говорит он.
Глеб Костарев соглашается с этим мнением, добавляя, что криптоискусство похоже на любой другой вид искусства: имеет значение, кто создал NFT, какова художественная ценность этого произведения и насколько оно может быть востребовано другими коллекционерами.
«Если NFT является частью ограниченного тиража или серии, то одни числа часто обладают большей ценностью, чем другие. Например, число 1 является самым популярным. Числа 13 или 7 также часто становятся желанными предметами коллекций. Ценность и редкость зависят от комбинации нескольких факторов», — говорит Костарев.
Однако пока еще не существует единых юридических норм, определяющих правовой статус таких токенов и объем прав, которые передаются вместе с ним покупателю.
Денис Восквицов объясняет, что после продажи цифровой картины, в теории, от автора можно потребовать удалить файл изображения. Но нужно помнить, что цифровые объекты искусства очень легко изменяются, и та же самая картина может быть, например, обрезана. Технически она станет другим изображением — да, производным, но не тем, что было изначально «зашито» в токене.
«Если это не было предусмотрено изначально как токенизация реальных произведений искусства, то с правами достаточно туманно — нет общепринятого процесса в этой сфере. Но, наверняка, они уже скоро появятся и, скорее всего, уже прорабатываются», — объясняет собеседник «Известий».
Глеб Костарев добавляет, что неопределенный правовой статус — временное явление, поскольку сама технология находится в самом начале своего развития и применения в разных сферах. И этот вопрос в правовом поле будет однозначно урегулирован, особенно когда использование NFT станет массовым в сделках, относящихся к финансовой сфере.
«Я думаю, что уже в ближайшее время нас ждут интересные проекты с использованием NFT. Это и протоколы для передачи метадаты кросс-чейн, и инструменты для изменения метадаты, и NFT, дающие ранний доступ или более высокие лимиты для протоколов децентрализованного финансирования DeFi, проекты с целью разделения роялти, урегулирования споров по распределению доходов или доле владения и многие другие», — подытожил Костарев.
Читайте также: