Technical Paper

Web3-инфраструктура: проверяемые публичные данные и программируемый расчёт

6.1 Инженерная задача

Yumo Yumo должен сохранять чеки приватными, публиковать цены, проверяемые без API, и финансировать распределение до подписи claim. Размещение всего в цепи раскрыло бы данные, обложило бы обычную обработку комиссиями и затруднило исправления; хранение всего в центральной базе потребовало бы доверять Yumo Yumo как единственному источнику результата.

Публичный путь и путь расчёта встречаются у verifier, а не в изображении чека. Сырые чеки не попадают в Arweave или Solana.

6.2 Почему три слоя

РешениеПричинаПроверяемый результат
Частная обработка вне цепиПриватность, исправление, отсутствие wallet и комиссии при загрузкеДетерминированный snapshot до публикации
Ценовые артефакты в ArweaveДатасет и метод доступны без инфраструктуры Yumo YumoID, manifest, каталог и рецепт
Обязательство в SolanaСвязывает версию, корень, хэш и ID публикацииПубличный Memo с порядком во времени
INT через distributorClaim ограничен опубликованным корнем и профинансированным vaultDistributor, funding, claim и clawback

Solana — слой исполнения и полномочий, Arweave — слой публичных артефактов, база приложения — слой частной обработки.

Почему Solana и почему Arweave

Выбор начинается с операционных требований, а не с утверждения, что одна сеть подходит любой нагрузке. Yumo Yumo нужен публичный record полного воспроизводимого epoch, путь settlement, по которому wallet проверяет и получает allocation, след одобрения treasury и проверка вне приложения. Эти требования разделяют крупные неизменяемые artefacts и компактные stateful transactions.

ТребованиеSolana: роль исполненияArweave: роль публикации
Публичный reviewRPC-доступные accounts и transactions показывают commitments, funding, approvals и claimsContent-addressed artefacts содержат catalogue, manifest, specification и proof material
Economic settlementWallet-directed claims, token accounts, distributor state и multisig approvalПолный epoch доступен для расчёта без переноса catalogue в transaction data
Version integrityCompact commitment связывает epoch ID, root, manifest digest и порядок transactionTransaction ID определяет byte-версию dataset и verification recipe
Independent accessReviewer выбирает RPC providerReviewer выбирает gateway или local mirror

Solana используется для state transitions: settlement опубликованного allocation, wallet-authorised claim, evidence treasury approval и упорядоченного commitment sealed epoch. On-chain payload содержит roots, digests, identifiers, authority state, funding references и claim state. План использует опубликованные protocol components Solana; конкретные mainnet instances будут зафиксированы в release registry при активации release.

Arweave используется для долговечной публикации полного price catalogue, manifest, правил canonicalisation и материалов для rebuild root. Conventional object storage распространяет те же файлы, но continuity и access policy остаются у account оператора. Content-addressed distribution идентифицирует bytes, а долгосрочная доступность определяется выбранным retention arrangement. Arweave даёт artefact собственный transaction ID для связи с Solana commitment.

Совместное использование даёт cross-check: verifier получает artefact через выбранный Arweave gateway, пересчитывает digest и Merkle root, затем читает Solana transaction или account через выбранный RPC. Оба records должны совпасть по epoch и root. Независимая команда может mirror artefacts, rebuild tree и verify commitment без инфраструктуры Yumo Yumo. Arweave несёт evidence масштаба публикации, Solana — экономические и authority consequences этого evidence.

6.3 От чека к проверяемой записи

Manifest публикует товар, магазин, место, дату и цену, но не изображения, IDs чеков, кошельки, аккаунты, OCR или сигналы доверия. Владелец может пересчитать keccak256("price-receipt:v1|receipt_id|content_hash|wallet"), применить proof включения и сравнить корень с Memo. Подпись с nonce вне цепи доказывает текущий контроль кошелька. Это доказывает включение, а не завершение платежа банком или магазином.

6.4 От проверенного вклада к claim INT

bINT — учётный кредит вне цепи. Подходящие записи проверяются, превращаются в отдельное от ценового дерева Jito SHA-256 дерево и сравниваются с записанными leaves. Затем distributor настраивается и vault финансируется с одобрением Squads.

подходящий bINT → verifier → корень Jito → профинансированный vault → подписанный claim → перевод INT → clawback

Приложение не создаёт claims изменением видимого баланса, а пользователь не подписывает отправку чека или начисление bINT.

6.5 Доказательства и зрелость

ПоверхностьДоказательствоСтатус для раскрытия
Ценовой реестрПересобираемый manifest, спецификация, скрипт, рецепт Memo и открытый verifierЖивой Solana mainnet с артефактами Arweave; публичный индекс https://yumoyumo.com/ledger; независимая проверка https://github.com/Yumo-Yumo-Inc/price-ledger-verifier
Дерево JitoClean-room TypeScript builder и byte-exact тесты с двумя CLI fixturesDevnet-репетиция; каждый mainnet distributor требует своего адреса, корня, funding и проверки
Казначейство и INTRunbooks, разделение ролей и gate закрытия mintНе заявлять активный mainnet до публикации адресов, порога и authority state

Отрепетированный поток — доказательство реализации, не доказательство существования mainnet instance.

6.6 Границы и путь проверки

Reviewer может проверить hash/root manifest, включение отпечатка и согласованность proof, distributor и vault. OCR, matching, fraud и частная допустимость оцениваются по процессным доказательствам. Задержка gateway, RPC outage, несовпадение proof, отклонённый claim и clawback — наблюдаемые состояния; Web3 не заявляет, что предотвращает их.

Публичная проверка ценового реестра начинается с https://yumoyumo.com/ledger: открыть sealed epoch, перейти по Memo (Solana) и артефакту (Arweave), затем выполнить npx tsx src/verify.ts <epoch> из https://github.com/Yumo-Yumo-Inc/price-ledger-verifier. Проверка reward-пути использует leaves, Jito account, funding и claims. Форматы и контроли описаны в Детали протокола и операционные границы.