Художник выпускает серию цифровых работ и хочет выставить их на собственном сайте. Каждая работа это изображение, анонс, описание и запись о принадлежности. Через год выясняется, что часть ссылок на файлы перестала открываться, потому что внешнее хранилище изменило правила, а покупатели считают, что вместе с записью получили и права на изображение. Обе проблемы технические, и обе решаются заранее.
Цифровая метка подтверждает запись, но не подтверждает права
Разберёмся с терминологией, потому что путаница здесь дорого обходится.
Уникальная цифровая метка представляет собой запись в общем реестре, удостоверяющую принадлежность и подлинность. Она содержит ссылки на файлы: изображения, видео, звук. От обычных денежных единиц отличается тем, что не делится на части и не заменяется другой такой же записью.
История началась в 2014 году. Первую такую метку создали два разработчика, связав видео с записью в реестре и продав её за четыре доллара во время публичного выступления. Затем в 2015 году появился проект, показавший возможность выпуска коллекций, а в 2017 году тема стала массовой.
Дальше случился рост и падение. Оборот вырос с восьмидесяти двух миллионов долларов в 2020 году до семнадцати миллиардов в 2021. А в 2022 году рынок обвалился, и число сделок упало более чем на девяносто процентов. К сентябрю 2023 года, по одному из обзоров, свыше девяноста пяти процентов коллекций не имели денежной ценности.
Теперь главное для разработчика галереи. Метка удостоверяет владение записью в реестре. Она не передаёт авторские права на изображение, не запрещает копирование файла и не мешает выпустить другую метку со ссылкой на тот же файл. Права определяются условиями выпуска, и их нужно прописывать явно.
Отсюда практическое правило: если галерея показывает работы, стоит отдельно и однозначно указать, какие права передаются покупателю. Отсутствие условия означает отсутствие прав, и это худший вариант для всех сторон.
Файлы хранятся отдельно и требуют устойчивой адресации
Вторая техническая проблема связана с местом хранения. Запись в реестре маленькая, а изображение большое, поэтому файл лежит вне реестра.
Обычный адрес указывает на место. Если файл переместили или сервер отключили, ссылка перестаёт работать. Для галереи, которая должна жить годами, это неприемлемо.
Альтернатива называется адресацией по содержимому. Адрес вычисляется из самих данных, и потому не зависит от того, где файл лежит. Любой, у кого есть файл, может его предоставить, и адрес остаётся верным.
Такая схема реализована в распределённой файловой системе, появившейся в феврале 2015 года. Она использует таблицу распределённого хранения и позволяет участникам обмениваться файлами напрямую.
// сохранение изображения и получение адреса по содержимому
import { create } from "ipfs-http-client";
const client = create({ url: "http://127.0.0.1:5001" });
async function publishArtwork(file) {
const added = await client.add(file);
return {
address: "ipfs://" + added.path,
size: added.size,
};
}
async function loadArtwork(address) {
const cid = address.replace("ipfs://", "");
const chunks = [];
for await (const chunk of client.cat(cid)) {
chunks.push(chunk);
}
return new Blob(chunks);
}Практические выводы из этой схемы.
Первое: файл нужно закрепить. Пока его кто-то хранит, адрес работает. Если все узлы отключатся, файл станет недоступен, несмотря на верный адрес.
Второе: адрес стоит зафиксировать при выпуске. Запись в реестре хранит его, и менять адрес задним числом нельзя без выпуска новой записи.
Третье: обычный адрес тоже полезен как запасной путь. Многие браузеры не умеют открывать ссылки такого вида напрямую, и нужен промежуточный шлюз.
Четвёртое: размер имеет значение. Несколько изображений высокого разрешения с несколькими копиями занимают сотни мегабайт, и это влияет на скорость галереи.
Интерфейс галереи показывает происхождение и историю
Отдельная задача это честное отображение сведений. Покупатель и зритель должны понимать, что перед ними.
Первое, что стоит показывать, это автор. Имя, ссылка на профиль, примеры других работ. Проверяемость авторства важнее любых обещаний.
Второе это история переходов. Кто владел работой и когда. Записи реестра открыты, и их можно показать списком.
Третье это условия использования. Что можно делать с изображением: показывать, печатать, использовать в рекламе. Условия пишутся простым текстом, а не отсылкой к юридическому документу.
Четвёртое это происхождение файла. Указание, что изображение создано автором, а не сгенерировано автоматически или скопировано.
Пятое это состояние доступности. Работает ли ссылка на файл, есть ли копии на запасных узлах.
const artworkView = {
title: "Северный ветер",
author: { name: "Ирина Соколова", verified: true },
file: {
address: "ipfs://bafy...",
gateway: "https://gateway.example.net/ipfs/bafy...",
pinned: true,
},
history: [
{ event: "выпуск", at: "2026-02-11" },
{ event: "передача", at: "2026-05-03" },
],
rights: "Показ в личных целях, коммерческое использование по согласованию",
};Такой набор сведений закрывает большую часть вопросов, которые иначе задают в поддержку.
Просмотрщик должен работать при медленной связи
Третья задача техническая. Изображения высокого разрешения грузятся долго, а посетитель хочет увидеть работу сразу.
Первое решение это предварительный просмотр. При выпуске создаётся уменьшенная копия, которая показывается мгновенно. Полное изображение подгружается по требованию.
<picture>
<source srcset="/preview/north-wind.avif" type="image/avif" />
<img
src="/preview/north-wind.jpg"
width="1200"
height="800"
loading="lazy"
alt="Северный ветер"
data-full="ipfs://bafy..."
/>
</picture>Второе решение это современные форматы. Сжатие без потерь качества даёт выигрыш в разы по сравнению с устаревшими форматами.
Третье решение это отложенная загрузка. Показываются только те работы, которые видны на экране. Для галереи из сотни изображений это критично.
Четвёртое решение это проверка целостности. Если адрес вычисляется по содержимому, можно убедиться, что полученный файл совпадает с ожидаемым. Это защищает от подмены.
async function verifyContent(expectedAddress, bytes) {
const digest = await crypto.subtle.digest("SHA-256", bytes);
const hash = [...new Uint8Array(digest)]
.map((b) => b.toString(16).padStart(2, "0"))
.join("");
return hash === expectedAddress;
}Пятое решение это отказ от автозапуска тяжёлых элементов. Видео и трёхмерные модели стартуют только по нажатию.
Взаимодействие с браузером требует понятных шагов
Если галерея предполагает покупку или передачу, добавляется работа с реестром. Здесь важна простота.
Первое: подключение расширения. Приложение должно проверить наличие и объяснить, что делать, если его нет. Пустой экран недопустим.
Второе: подтверждение операции. Пользователь должен видеть, что именно подписывает и сколько платит. Скрытые условия разрушают доверие.
Третье: ожидание. Операция подтверждается не мгновенно. Интерфейс обязан показывать состояние и не давать нажимать повторно.
Четвёртое: разбор ошибок. Отказ пользователя, недостаток средств, неверная сеть. Каждый случай требует своего сообщения.
async function buy(contract, tokenId) {
const provider = window.ethereum;
if (!provider) {
return { state: "нет расширения", hint: "Установите расширение для работы с реестром" };
}
const [account] = await provider.request({ method: "eth_requestAccounts" });
const data = contract.methods.purchase(tokenId).encodeABI();
try {
const tx = await provider.request({
method: "eth_sendTransaction",
params: [{ from: account, to: contract.options.address, data }],
});
return { state: "отправлено", hash: tx };
} catch (error) {
if (error.code === 4001) {
return { state: "отклонено пользователем" };
}
return { state: "ошибка", message: String(error.message) };
}
}Пятое: история операций. Простой список последних действий помогает человеку убедиться, что ничего не потерялось.
Оформление экспозиции влияет на восприятие сильнее украшений
Четвёртая задача это собственно подача. Галерея отличается от каталога тем, что работы нужно смотреть.
Первое: фон. Нейтральный фон не отвлекает и не искажает цвета. Яркая подложка уместна только для конкретной серии.
Второе: масштаб. Работа должна занимать заметную часть экрана. Мелкие превью в сетке удобны для навигации, но плохи для просмотра.
Третье: подписи. Название, год, техника. Минимум текста рядом с изображением, подробности на отдельной странице.
Четвёртое: переходы. Плавная смена кадров без резких скачков. Движение должно быть медленным, чтобы не отвлекать.
Пятое: доступность. Альтернативные описания обязательны, навигация с клавиатуры работает, контраст текста достаточен.
Шестое: отсутствие навязчивых элементов. Всплывающие окна и мигающие кнопки несовместимы с задачей рассматривания.
Организационные вопросы определяют долгосрочную судьбу галереи
Пятая задача лежит вне кода.
Первое: описание прав. Чёткое условие для каждой коллекции, оформленное заранее и одинаковое по смыслу.
Второе: резервное хранение. Файлы стоит держать в нескольких местах, включая обычный сервер. Распределённая сеть не заменяет резервную копию.
Третье: план на случай отказа сервисов. Что делать, если внешнее хранилище закрылось или расширение перестало поддерживаться.
Четвёртое: документирование выпуска. Дата, автор, адрес файла, условия. Простая таблица спасает при спорах.
Пятое: готовность к убыткам. Рынок цифровых работ непредсказуем, и рассчитывать на устойчивый рост не стоит. Галерея имеет смысл как площадка для показа, а не как способ заработка.
Числовой пример показывает, во что обходится хранение
Полезно посчитать затраты, потому что они неочевидны.
Пусть галерея содержит сто работ. Каждая представлена тремя файлами: полное изображение весом пять мегабайт, уменьшенная копия весом триста килобайт и миниатюра весом пятьдесят килобайт. Итого на сто работ приходится около пятисот тридцати пяти мегабайт.
Теперь учтём резервирование. Если каждая работа хранится у трёх независимых сторон, объём утраивается до полутора гигабайт.
Добавим шлюз, который отдаёт файлы посетителям. Через него проходит трафик, и при тысяче просмотров полного изображения в день это пять гигабайт в сутки, то есть около ста пятидесяти гигабайт в месяц.
Становится понятно, почему крупные галереи показывают уменьшенные копии и предлагают скачать оригинал по отдельному действию. Экономия достигается на раздаче, а не на хранении.
Второй вывод из расчёта касается миниатюр. Уменьшенные копии весят немного, и ими можно пренебречь при планировании места. Основной объём приходится на оригиналы.
Третий вывод: устаревшие форматы стоит перевести в современные. Одно и то же изображение в новом формате весит в полтора-два раза меньше без заметной потери качества.
Сравнение с обычной галереей помогает выбрать подход
Полезно понять, когда сложная схема оправдана, а когда нет.
Обычная галерея работает на собственном сервере. Просто, дёшево, предсказуемо. Минус один: доверие держится на слове владельца.
Галерея с записями в реестре добавляет проверяемую историю. Выпуск, передача, текущий владелец видны любому. Минусы: сложность, стоимость операций, неопределённость с правами, зависимость от внешних сервисов.
Галерея с распределённым хранением спасает от пропажи файлов при отказе одного узла. Минус: файл доступен, пока его кто-то хранит, а это требует усилий.
Практическое решение обычно гибридное. Основные файлы лежат на своём сервере, копия размещается в распределённой сети, а записи о принадлежности публикуются в реестре. Такая схема даёт устойчивость и проверяемость, не отдавая всё на откуп внешним системам.
Проверка перед публикацией серии
Первое: указаны ли права для каждой работы простым текстом.
Второе: закреплены ли файлы и есть ли резервная копия на своём сервере.
Третье: работают ли ссылки в браузере без специальных расширений.
Четвёртое: проверены ли уменьшенные копии и миниатюры.
Пятое: добавлены ли описания для людей, пользующихся вспомогательными технологиями.
Шестое: посчитан ли ожидаемый трафик и хватит ли пропускной способности.
Седьмое: описан ли порядок действий при отказе внешнего сервиса.
Эти проверки занимают полдня, а предотвращают ситуацию, когда серия открывается наполовину или не открывается вовсе.
Галерея цифровых работ получилась задачей, где технология решает половину проблем и создаёт вторую половину. Метка подтверждает запись, файловая адресация защищает от пропажи ссылок, но права и ответственность остаются на людях. Тот, кто продумывает обе части заранее, получает площадку, которая работает годами. Тот, кто полагается только на техническую сторону, через год обнаруживает пустые рамки вместо работ.