000. Журнал изменений — 13–18.10.2026

Этот документ фиксирует пересмотр спецификации Lagrix, согласованный 12–18 октября 2026 года. По каждому изменению сказано, что спецификация говорила раньше, что говорит теперь и почему. Документы, названные в каждой записи, переписаны под неё; если где-то уцелела старая фраза, верен этот журнал.

Записи 12–19 согласованы позже 13 октября, после разбора вопросов регуляторов. Если они меняют прежнюю запись, та говорит об этом, и верна более поздняя.

Записи 20–37 согласованы 14 октября, когда миссия сети встала на первое место; их собственный вопрос назван перед записью 20. Записи 38–45 согласованы 15 октября, запись 46 — 16 октября, записи 47–50 — 17 октября, записи 51–55 — 18 октября.

За пересмотром стоял один вопрос: может ли сеть жить сама, как биткоин, без органа, у которого есть власть над ней? Каждое изменение ниже отвечает на него.

1. Советов нет: неизменяемые контракты и протоколы, которые объявляет сам узел

Пересмотрена записью 49: одно решение — может ли агент нести метку «Официальный» — принимает голосование случайной выборки супер-узлов. Больше ни о чём не голосуют.

Было. Совет супер-узлов из всех операторов выбирал протоколы сети и менял её параметры — порог входа и ставку комиссии — двумя третями голосов (документы 09, 18). Совет Хранителей с мультиподписью и временными шлюзами защищал этот Совет от захвата (документы 00, 18). Документ 07 допускал исправление развёрнутого контракта «процедурой управления».

Стало.

• Нет ни Совета супер-узлов, ни Совета Хранителей.
• Контракты неизменяемы: нет ключа администратора, нет ключа обновления, нет параметра, который кто-то может поменять после развёртывания.
• Новые правила приходят только новой версией контрактов, на которую участники переходят добровольно, — как обновление биткоина распространяется ровно настолько, насколько люди решают его запустить.
• Каждый супер-узел сам объявляет, какие протоколы поддерживает (A2A, F2F, любой следующий) и какие виды объявлений (теги) берёт в индекс, — по образцу поля supported_nips в описании ретранслятора Nostr (NIP-11). Супер-узел, который не хочет нового протокола, теряет клиентов, которые им пользуются; остальную сеть он заблокировать не может.

Почему. Совет был нужен только чтобы добавлять протоколы и двигать параметры. Протоколам голосование не нужно: каждый супер-узел просто говорит, что поддерживает, и клиенты выбирают. Параметрам тоже, когда каждый из них — формула или константа в коде (записи 5 и 7 ниже). Когда решать нечего, захватывать тоже нечего, — поэтому уходит и Совет Хранителей, который существовал только для охраны Совета супер-узлов. Орган, способный менять правила, можно давить, подкупить или обвинить; сеть без такого органа работает, кем бы ни были её авторы.

Документы: 00, 07, 09, 17, 18, 19, 20, README.

3. Место в выдаче — по оплаченной работе за последний год

Пересмотрено записями 23 и 30: считается только сетевая часть сделки, а четвёртое место идёт по очереди.

Было. Подходящие агенты упорядочивались «открытым аукционом видимости» (документ 17, раздел 17.2; README «Как работает поиск»).

Стало.

• Подходящие агенты упорядочиваются по весу их чеков в USDC за последние 12 месяцев. Более старая работа выпадает из окна.
• Каждое четвёртое место по-прежнему выбирается случайно среди подходящих агентов.
• Лайки и дизлайки агента и число его сделок видны другой стороне, и ничто из этого не двигает место в выдаче.

Почему. Однажды купленное место — это запас, который не тает: кто купил рано, держал бы лучшие места вечно, не работая, — конец честной конкуренции и приглашение скопировать сеть с чистого листа. Место по недавней оплаченной работе уравнивает любой год: считается то, что вы делаете сейчас, а вес чека в USDC одинаков в любой год.

Документы: 05, 17, README.

5. Плата за поиск: $0,001 за одну выдачу

Цена пересмотрена записями 19 и 29; ваучеры пересмотрены записью 52.

Было. Платы за обнаружение не было. Супер-узлы зарабатывали только долю комиссии сделок.

Стало.

• Тот, кто ищет, — агент или человек, — платит $0,001 в USDC за одну выдачу супер-узлу, который её собрал.
• Цена — константа в коде, одинаковая в любой точке мира.
• Оплата идёт из предоплаченного баланса в контракте: ищущий подписывает ваучер на каждый поиск ровно на эту сумму, а супер-узел обналичивает ваучеры пачками.
• Плата за поиск не рождает чеков.
• Контакты остаются открытыми: объявление несёт node_id агента, его визитку и ключ шифрования, и любой может бесплатно читать ретрансляторы Nostr напрямую и строить свой индекс. Плата — за услугу сборки выдачи, а не за доступ к человеку.
• Повторная работа сторон, которые уже знают друг друга, ничего не стоит: они не ищут снова.
• Сам Nostr остаётся бесплатным.

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

Документы: 17, 18, README.

7. Комиссия 5 % идёт другим супер-узлам, навсегда

Пересмотрено записями 12 и 25: комиссия теперь платит супер-узлам за работу сети.

Было. Комиссия возвращалась по кругу в очередь активных исполнителей, одна выплата на исполнителя, и лишь постепенно переходила к супер-узлам (документы 05, 09). Ставку мог менять Совет супер-узлов.

Стало.

• Комиссия — 5 % каждой сделки, константа в коде навсегда.
• Она делится поровну между всеми супер-узлами, кроме того, через который прошла сделка.
• Если других супер-узлов ещё нет, она копится в контракте для тех, кто войдёт позже.
• Очередь исполнителей удалена.

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

Документы: 04, 05, 09, README.

11. Люди говорят через своих агентов: H2A и H2H

Было. Ни один документ не описывал, как общаются люди. Сайт описывал H2H как мессенджер, в котором человек находит владельца агента и пишет ему напрямую, без агента в разговоре, — как децентрализованный Telegram или WhatsApp.

Стало.

• Три связи, у каждой своё правило: H2A — человек говорит только со своим агентом; A2A — агенты говорят с агентами; H2H — люди говорят друг с другом только после того, как агент другой стороны проверил обращение, а его владелец согласился.
• Агент никогда не соединяется с владельцем на другой стороне; человек не выходит на незнакомца иначе как через агента этого незнакомца.
• Агент советует, человек решает: контакт открывается только после «да» его владельца.
• Единого шлюза нет, и разговоры не разносятся по сети: они живут только на узлах участников.

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

Документы: 21 (новый), README.

12. Комиссия платит свидетелям

Согласовано позже 13 октября, после разбора вопросов регуляторов. Пересматривает запись 7. Пересмотрено записями 24 и 25: свидетелей нет.

Было. Комиссия 5 % делилась поровну между всеми супер-узлами, кроме того, через который прошла сделка (запись 7).

Стало.

• Комиссия идёт свидетелям: супер-узлам, выбранным случайно для каждой сделки, которые проверяют её чек и подписывают его. Супер-узел, обслуживший сделку, свидетелем по ней не бывает.
• Её размер — постоянная в коде, определяется моделированием и не выше 5 %. До моделирования — 5 %.
• С первой сделки комиссия идёт свидетелям этой сделки. В контракте ничего не копится.

Почему. Равная доля с каждой сделки платила каждому супер-узлу с чужой работы, делал он что-то для этой сделки или нет, — доход от усилий других, ровно то, что ищут регуляторы. Копилка в контракте выплачивалась бы позже тем, кто тогда держит супер-узлы, и тот, кто её наполнил, мог бы вернуть себе потраченное. Свидетелю платят за работу, которую он действительно делает по этой сделке, и выбирается он случайно, поэтому никто не выбирает, кто проверит его собственные сделки. Потолок 5 % держит комиссию там, где её поставила запись 7; моделирование может опустить её до того, сколько на самом деле стоит проверка чека.

Документы: 00, 04, 05, 06, 09, 17, README.

13. Основатель и связанные с ним лица не держат супер-узлов

Пересмотрено записью 18: основатель участвует на общих правилах.

Было. Основатель мог держать супер-узлы и называл их публично.

Стало.

• Основатель и связанные с ним лица, включая Fractera, Inc., не держат супер-узлов и не бывают свидетелями.
• Они заранее публично называют свои адреса, и контракты не допускают эти адреса к роли супер-узла и свидетеля.

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

Документы: 00, 05, 06, 15, README.

15. Вход супер-узлов: бесплатно, по приглашению, затем по перегрузке

Отвечает на открытый вопрос о входе после первых супер-узлов. Пересмотрено записью 30: места занимают по очереди. Пересмотрено записью 31: этапов нет, случайный выбор среди исполнителей около медианы. Пересмотрено записью 40: минимум десять мест, приглашение и 48 часов, правило перегрузки.

Было. Вход после первых супер-узлов был открыт — порог приведённых участников, возможно, аукцион мест.

Стало.

• Места 1–100 — открыты заявителям, чей сервер прошёл проверку.
• Места 101–1 000 открываются независимо от нагрузки сети, по приглашению — только владельцам агентов-исполнителей с оплаченной работой за последний год. Один билет на адрес.
• Сервер заявителя измеряют случайные агенты, а не супер-узлы. Места назначаются случайным выбором среди заявителей, чей сервер прошёл проверку, с разнообразием сетей и регионов, чтобы один заявитель с множеством серверов не занял много мест.
• После 1 000 новые места открываются, только когда сеть перегружена — сделок на супер-узел больше постоянной, — по два места сразу, тем же случайным выбором.
• Правило «приведи участников» и аукцион мест сняты.
• Постоянную перегрузки задаёт моделирование.

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

Документы: 00, 01, 05, 06, 15, README.

16. Ротация и минимум качества

Новое. Пересмотрено записью 30: уходит тот, кто дольше всех на месте, а проверки идут по очереди. Пересмотрено записью 40: ротация с передачей; при перегрузке уходит супер-узел с худшими результатами под нагрузкой.

Было. Супер-узел держал своё место сколько хотел.

Стало.

• Раз в 1 год / N, где N — число супер-узлов, выбывает один случайно выбранный супер-узел. Штрафа нет. Его место назначается случайным выбором записи 15. В среднем супер-узел остаётся около года.
• При перегрузке сети открываются ещё два места тем же случайным выбором (запись 15).
• Каждый период случайные агенты проверяют каждый супер-узел по минимуму качества: прошёл или не прошёл. Супер-узел, не прошедший несколько периодов, выбывает.

Почему. Вечное место — это запас, который не тает, та же беда, которую запись 3 решила для поиска: кто вошёл рано, держал бы место всегда. Ротация держит дверь открытой для тех, кто делает оплаченную работу сейчас. Выбыть по ротации — не провинность, поэтому это ничего не стоит. Минимум — одно «прошёл / не прошёл», а не оценка, поэтому гнаться не за чем.

Документы: 05, 06, 15, README.

17. Слова: узел — это сервер

Новое. Пересмотрено записью 21.

Было. Глоссарий называл узел «собственным пространством человека для агентов: обычным компьютером».

Стало. Узел — сервер, который запускает агентов и отдаёт их сети. Чаще всего на нём работают агенты одного человека, но он может служить многим людям; у каждого агента свой владелец. Узел — не супер-узел. Две стороны сделки — агент-заказчик и агент-исполнитель.

Почему. Службы, которые запускают агентов для многих людей, — тоже узлы; называя узел «компьютером человека», мы описывали только один случай.

Документы: README.

18. Доли основателя нет; основатель участвует на общих правилах

Согласовано позже 13 октября. Пересматривает запись 13.

Было. Основатель и связанные с ним лица, включая Fractera, Inc., не держали супер-узлов и не бывали свидетелями, а их названные адреса к этим ролям не допускались (запись 13).

Стало.

• Доли основателя нет ни в чём: ни его порций, ни блокировки, которая существовала бы только для него.
• Основатель и связанные с ним лица, включая Fractera, Inc., участвуют только на тех же условиях, что и все: место супер-узла — только тем же случайным выбором и на тех же условиях, свидетель — только когда выбран, как любой, агенты-исполнители — по тем же правилам. Нет ни льгот, ни исключений, поэтому называть адреса не нужно.
• Лицензия. lagrix и lagrix-contracts открыты под лицензией MIT, чтобы никто — включая основателя — не стоял у ворот сети.

Почему. Доля основателя связывала бы его с доходом сети на весь её срок — самый явный признак центральной стороны, о котором регуляторы спрашивают первым. Без доли связывать нечего, а основатель зарабатывает, если зарабатывает, как обычный участник. Запрет основателю участвовать был нужен, только чтобы основатель с долей не собирал больше; без доли общие правила честнее и сохраняют возможность его работы. Лицензия, по которой коммерческое использование разрешает только автор, сделала бы автора воротами сети.

Документы: 00, 05, 07, 09, 15, 18, 22, README.

19. Плата за поиск — $0,01

Согласовано позже 13 октября. Пересматривает запись 5. Пересмотрено записью 29; ваучеры пересмотрены записью 52.

Было. Одна выдача стоила $0,001 в USDC (запись 5).

Стало. Одна выдача стоит $0,01 в USDC и платится супер-узлу, который её собрал. Остальное в записи 5 сохраняется: постоянная в коде, одинаковая везде, предоплаченные ваучеры обналичиваются пачками, чека нет, контакты открыты, Nostr бесплатен.

Почему. Плата защищает индекс от выкачивания, и десятикратная цена делает выкачивание в десять раз дороже: миллион поисков стоит теперь $10 000. Для того, кто ищет партнёра, это по-прежнему небольшая разовая цена: найденный партнёр сохраняется в контактах агента и больше не ищется.

Документы: 00, 13, 17, 18, README.

Пересмотр 14 октября: миссия первой. Записи 20–30 согласованы 14 октября 2026 года. За ними стоял один вопрос: служит ли правило двум целям сети — обнаружению и честной репутации? Если они меняют прежнюю запись, та говорит об этом, и верна более поздняя.

20. Миссия первой: обнаружение и честная репутация

Было. README открывался вызовом закрытым ассистентам, а миссией был гарантированный шанс быть найденным через одно место из каждых четырёх. Репутация была одним пунктом списка, и ни один документ не называл её целью.

Стало.

• У сети одна миссия и две цели. Обнаружение: агент для любого дела и прямая связь с любым человеком через его агента, без посредника. Честная репутация: строится только из настоящих оплаченных сделок; её нельзя купить, дёшево подделать или переписать.
• Каждое правило сначала проверяется на эти две цели. Супер-узлы и контракты — средства, а не цель.

Почему. Без названной миссии правила уходили от этих целей. Две цели — то, ради чего люди приходят: найти того, кто нужен, и знать о нём правду.

Документы: README, 00, 17, 18.

21. Слова: узел, элемент, агент; сущность — это элемент

Пересматривает запись 17.

Было. Узел был сервером, который запускает агентов, а репутация агента была привязана к его ключу (документы 18, 19).

Стало.

• У человека может быть много узлов. Узел — его домашний компьютер или, по его выбору, VPS-сервер. В узле один или несколько элементов, в элементе — один или несколько агентов.
• Элемент — сущность сети: его сделки, отзывы и репутация принадлежат ему. У элемента один владелец.
• Интегратор — человек, который добровольно, без особой роли в контрактах, даёт другим людям запустить агентов на своём узле — чтобы учиться или построить свой сервис. Для сети такой узел — обычный узел, и каждый элемент на нём — своя сущность.

Почему. Элемент — это то, что делает работу и что оценивает другая сторона. Узел может нести элементы одного человека или многих; протоколу не нужны ни личность человека, ни отдельный счёт для каждого агента.

Документы: README, 17, 19, 20, 21.

22. Кошелёк регистрирует узел

Было. У каждого агента был свой ключ, и ничто не отличало узел, который участвует в записи сети, от узла, который только смотрит.

Стало.

• Один кошелёк регистрирует узел и все его элементы. Через него идут все платежи элементов узла, и каждый платёж записан за тем элементом и тем агентом, который его заработал.
• Без кошелька агенты любого элемента видны в сети, но искать другие элементы могут только за повышенную плату (запись 29), и ни один элемент узла не участвует в репутации.

Почему. Одна регистрация на узел проста для человека, а чек сохраняет репутацию за элементом. Кошелёк и делает узел частью записи сети; без него репутации не на чем стоять.

Документы: README, 04, 17, 19.

23. Сделку можно разделить; сеть считает только свою часть

Было. Вся оплата сделки шла через эскроу.

Стало.

• Стороны могут заплатить часть сделки вне сети, любым обычным способом, а часть — через эскроу сети.
• Сеть видит, записывает и защищает только ту часть, что прошла через неё. Чеки, комиссия, вес отзывов и место в выдаче считают только эту часть.
• Часть, оплаченную вне сети, защищает закон страны, где прошла сделка, а не Lagrix.

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

Документы: README, 04, 05, 09, 17, 22.

24. Сеть не проверяет услуги; свидетелей нет

Пересматривает запись 12. Пересмотрена записью 49: случайная выборка супер-узлов решает, может ли агент нести метку «Официальный»; услуги сеть по-прежнему не проверяет. Пересмотрена записью 53: срок сдачи и окно спора задаёт каждая сделка.

Было. Свидетели — супер-узлы, выбранные для каждой сделки, — проверяли и подписывали её чек и получали комиссию.

Стало.

• Свидетелей и валидаторов нет.
• Сеть не судит, оказана ли услуга. Приёмка — за заказчиком: его подпись открывает оплату, или истекает окно приёмки (документ 04). О качестве говорят отзывы обеих сторон (запись 26).

Почему. Большинство услуг сеть проверить не может вовсе, а проверку самой записи уже делает контракт эскроу: он сам сверяет подпись заказчика. Орган, который судил бы услуги, стал бы судом, который можно подкупить, который может ошибиться и на который можно подать в суд.

Документы: README, 04, 05, 06, 07, 09, 17, 18, 22.

25. Комиссия — плата супер-узлам за работу сети

Пересматривает записи 7 и 12. Пересмотрена записью 51: 20 % комиссии получает разработчик элемента, полученного по F2F.

Было. Комиссия шла свидетелям каждой сделки (запись 12).

Стало.

• Комиссия — не больше 5 % сетевой части каждой сделки, в USDC: постоянная, заданная моделированием, до него 5 %. Стороны сделки её никогда не получают.
• Комиссии периода складываются и делятся поровну между супер-узлами, прошедшими минимум качества в этом периоде.
• У комиссии две задачи. Она платит супер-узлам за работу, которую они делают всегда: поиск, соединения, индекс чеков и отзывов. И она делает фальшивую сделку платной: отзыв весит ровно уплаченную по сделке комиссию (запись 42), поэтому единица веса отзыва обходится фальшивой сделке в доллар комиссии.

Почему. Если платить по сделке, комиссию можно направить: сторона подгадала бы сделку так, чтобы её собрал свой супер-узел. Когда комиссия складывается за период, группа, которая держит k из M супер-узлов, возвращает себе только k/M своей комиссии. Комиссию никогда не делят по объёму сделок — это вернуло бы каждому плательщику ровно то, что он заплатил, — и никогда не платят узлам агентов: узлы легко размножить, а мест супер-узлов ограниченное число.

Документы: README, 04, 05, 07, 09, 18, 22.

26. Отзывы и репутация

Пересмотрено записями 42 и 43: отзыв весит уплаченную по сделке комиссию, а каждый показатель — число и сумма.

Было. Каждая сторона закрытой сделки могла поставить другой один лайк или дизлайк; карточка агента показывала число сделок, лайков и дизлайков, и ничто из этого не двигало выдачу (документ 17).

Стало.

• Отзыв — лайк или дизлайк, который каждая сторона оплаченной сделки ставит другой: исполнитель — заказчику, заказчик — исполнителю. Его вес равен сетевой части сделки, делённой на 10.
• Репутация — данные для агента-контрагента. Она есть у элемента в обеих ролях — как у исполнителя и как у заказчика, и в каждой роли это два числа: вес лайков и вес дизлайков.
• Два числа никогда не складываются и не вычитаются. Контрагент учитывает их на своё усмотрение и сам принимает решение.
• Репутация не влияет на место в выдаче, и переписать её не может никто.
• Число сделок в репутацию не входит.

Почему. Весит только то, за что заплачено. Единая оценка скрыла бы, из чего она сложена, и звала бы к накрутке; число сделок дёшево раздуть, и оно показывает активность, а не доверие. Считаются обе роли, потому что хороший заказчик может быть плохим исполнителем, и наоборот.

Документы: README, 07, 17, 18, 22.

27. Карма живёт вне сети

Пересмотрена записью 49: сеть по-прежнему видит ключи; метка «Официальный» добавляет к ключу только то, что выборка установила о человеке или организации за ним.

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

Почему. Сеть видит ключи, а не людей. Связать несколько своих узлов — дело самого человека, и доказывает это он сам; протокол от этого не меняется, какой бы инструмент карму ни показывал.

Документы: README, 17.

28. История элемента с ним не переходит

Стало.

• Элемент, переехавший на другой узел или переданный другому владельцу, начинает там с чистой историей. Прежняя история навсегда остаётся там, где заработана.
• Элемент, переданный по F2F, никогда не несёт свои ключи (документ 20).

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

Документы: README, 17, 20.

29. Плата за поиск: $0,10 без кошелька, $0,01 с кошельком

Пересматривает запись 19.

Было. Одна выдача стоила $0,01 для всех.

Стало.

• Узел с кошельком платит $0,01 за одну выдачу из предоплаченного баланса в контракте.
• Тот, у кого нет кошелька, платит $0,10 за одну выдачу тем способом, каким супер-узел принимает обычные деньги.
• Цена одинакова везде; плата за поиск не создаёт чека.

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

Документы: README, 13, 17, 18.

30. Очередь вместо случайного выбора

Пересматривает записи 15 и 16 и проверяемую случайность документа 17.

Было. Места супер-узлов назначались случайным выбором, при ротации уходил случайно выбранный супер-узел, серверы и минимум качества проверяли случайно выбранные агенты, а одно место из каждых четырёх в выдаче получал случайно выбранный подходящий агент.

Стало.

• Места супер-узлов занимают по очереди заявок, чьи серверы прошли проверку, в порядке подачи, с разнообразием сетей и регионов.
• Раз в «1 год / N» без штрафа уходит супер-узел, который дольше всех на месте, и его место занимает следующий по очереди заявок.
• Серверы и минимум качества проверяют агенты зарегистрированных узлов, взятые по очереди.
• В каждой группе из четырёх мест выдачи одно место получают подходящие агенты по очереди: они упорядочены по ключу, а интервал времени, заданный в коде, сдвигает очередь. Так своё место получает каждый подходящий агент, включая новичка без единой сделки, а пересчитать, чья была очередь, может любой.

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

Документы: README, 05, 06, 15, 17.

Места супер-узлов пересмотрены записью 31.

31. Места супер-узлов: случайный выбор среди исполнителей около медианы

Пересматривает записи 15 и 30 в части мест супер-узлов. Ротация, проверка серверов агентами по очереди и очередь в выдаче из записи 30 остаются.

Было. Места открывались в три этапа: 1–100 первыми, 101–1 000 по приглашению владельцам агентов-исполнителей с годом оплаченной работы, после 1 000 — по перегрузке; места занимали по очереди заявок.

Стало.

• Ни этапов, ни номеров мест. Ни у одного места нет льготы, которой нет у другого, и условия одинаковы в любой день.
• Претендовать может только владелец агента-исполнителя. Заявку подаёт узел — одна заявка на кошелёк узла.
• Мера — оплаченная работа узла как исполнителя: сумма сетевых частей сделок в USDC, в которых его элементы были исполнителями, за последние 12 месяцев (или с начала сети, если она моложе). Это то же число, за которым идёт выдача. Карма в расчёт не входит: она живёт вне сети (запись 27).
• Окно вокруг медианы. Когда место открывается, берутся все узлы с ненулевой мерой и находится их медиана M. Претендовать могут узлы с мерой от 0,75 × M до 1,25 × M.
• Случайный выбор с разнообразием. Среди претендентов из окна, чьи серверы прошли проверку агентами по очереди, место получает случайно выбранный, с разнообразием сетей и регионов. Случайность считает сам контракт по схеме «обязательство и раскрытие»: подавая заявку, претендент публикует хеш своего секрета; после закрытия приёма раскрывает секрет; выбор определяют все раскрытые секреты вместе. Пока последний секрет не раскрыт, результат не знает никто; кто не раскрыл свой, выбывает из этого выбора.
• Сколько мест. Начальное число мест задаёт моделирование; дальше места открываются, только когда сеть перегружена, по два сразу.
• Старт. Пока ни у одного узла нет оплаченной работы, окно пусто, и претендовать может любой, чей сервер прошёл проверку. Это не льгота: эти операторы дольше всех на местах и поэтому первыми уходят по ротации, а их места открываются уже по окну.
• Ротация и вакансии. Раз в 1 год / N уходит супер-узел, который дольше всех на месте; освободившееся место открывается тем же случайным выбором по окну того дня, когда оно открылось.

Почему.

• Окно вокруг медианы не пускает в инфраструктуру самых крупных исполнителей: тот, кто больше всех зарабатывает в сети, не держит ещё и её поиск. Медиана, а не среднее: несколько очень крупных исполнителей сдвигают среднее вверх, а медиану — нет.
• Очередь записи 30 награждала того, кто подал заявку раньше, и её можно было занять заранее. Случайный выбор даёт каждому подходящему равный шанс. Запись 30 отказалась от случайности, потому что источник, который никто не может предсказать или направить, трудно стандартизировать. «Обязательство и раскрытие» не требует ни оракула, ни внешней службы: случайность складывается из того, что опубликовали сами претенденты.
• Номера мест создавали ранних, чьи условия лучше, чем у пришедших позже. Теперь их нет.
• Цена, которую не скрываем. Крупный игрок может разделить работу между несколькими узлами около медианы и подать несколько заявок. Без проверки личности этого не закрыть, но каждая лишняя заявка стоит года настоящей оплаченной работы с комиссией 5 % на объём медианы.

Документы: 00, 05, 06, 15, 22, README; README lagrix-supernode.

Пересмотрено записью 40: минимум десять мест, проверка после приглашения, ротация с передачей, правило перегрузки.

32. Ограничения обнаружения: три слоя, совета нет

Новое. Отвечает на вопрос, как сеть без эмитента соблюдает требования властей; совета по-прежнему нет (запись 1).

Было. Каждый супер-узел сам объявлял, какие теги берёт в индекс (документы 17, раздел 17.9; 18, раздел 18.4). Ни общего списка запрещённого, ни сведений о том, откуда пришёл запрос, ни адреса, по которому власть может обратиться к оператору, спецификация не называла.

Стало.

• Слой 1 — запрещённые по умолчанию теги. Короткий список того, что запрещают международные договоры или уголовное право каждой страны: сексуальная эксплуатация детей, торговля людьми, терроризм и его финансирование, оружие массового поражения, насилие по заказу, краденые данные и доступы, вредоносные программы. Список закреплён в версии протокола; изменить его можно только новой версией, на которую участники переходят добровольно (запись 1). Супер-узел не берёт объявления с этими тегами в индекс и убирает из индекса объявление, о котором узнал, что оно относится к этим видам; супер-узел, который отдаёт их в выдаче, не проходит минимум качества.
• Слой 2 — региональные ограничения. Каждый супер-узел сам применяет законы страны своего оператора и может применять ограничения по стране запроса. Его охват объявлен (документ 18, раздел 18.4), поэтому видно, что он показывает, а чего нет.
• Слой 3 — открытые списки ограничений. Подписанный список тегов может опубликовать кто угодно — орган власти, правозащитная организация, сами операторы. Супер-узел подписывается на списки добровольно и объявляет, какие применяет. Власть, которой нужен новый запрет, публикует свой список или направляет приказ операторам в своей юрисдикции.
• Запрос обнаружения несёт страну и флаг «взрослый». Их объявляет узел и сам отвечает за их верность; валидатора нет, и других персональных данных запрос не несёт. Исполнитель, чья услуга только для взрослых, помечает объявление тегом adult.
• Точка контакта. Каждый супер-узел объявляет страну оператора и точку контакта для органов власти; оператор, который оказывает услуги в ЕС и не имеет там представительства, называет законного представителя (Регламент (ЕС) 2022/2065, статьи 11 и 13).

Почему.

• Совет, который расширяет запретный список для всей сети, стал бы единой цензурой для всего мира, первым адресатом каждого регулятора и кандидатом в определимого эмитента — ровно то, от чего ушла запись 1.
• Власть обращается к тому, кто оказывает услугу. Приказы DSA адресованы поставщику посреднической услуги (статьи 9 и 10); в Lagrix это оператор супер-узла, а не сеть и не автор протокола. Общей обязанности следить за всем DSA не налагает (статья 8).
• Точные возраст и место были бы персональными данными у каждого супер-узла; DSA прямо не требует обрабатывать дополнительные персональные данные, чтобы выяснить, несовершеннолетний ли пользователь (статья 28(3)). Валидатор возраста и места сделал бы сеть зависимой от того, кто проверяет.
• Чего слои не делают, и мы это не скрываем. Подписанное объявление в Nostr остаётся на тех реле, которые его хранят: супер-узел убирает его из своего индекса и своей выдачи, но стереть его из сети не может никто. Слой 1 работает на тегах и на том, о чём супер-узел узнал; содержание зашифрованных разговоров сеть не видит (документ 03).

Документы: 17, 18, 19, 22, README; README lagrix-supernode.

33. H2H на MLS, ключ узла подписан его кошельком, доставка сообщений супер-узлом

Новое. Отвечает на открытые вопросы документа 21 о доставке, когда одна сторона не в сети, и об оплате пересылки — для сообщений H2H. Пересмотрено записью 52: один ваучер с нарастающей суммой; через супер-узел — только текст до 64 КБ, хранение до 30 дней и не больше 1 МБ на получателя; вложения остаются у отправителя.

Было. Ключ шифрования создавался один раз на соединение (ECDH при рукопожатии, документ 03): украденный ключ открывал всю переписку этого соединения. Доставка сообщения тому, кто не в сети, и плата за пересылку оставались открытыми вопросами.

Стало.

• Разговоры H2H шифруются по MLS — открытому стандарту IETF RFC 9420. Ключ меняется с каждым сообщением: ключ, украденный сегодня, не открывает вчерашнюю переписку, а после следующего обновления ключей не открывает и будущую. MLS работает и для групп.
• Ключ узла подписан его кошельком. Публичный ключ, которым узел начинает разговор, подписан кошельком узла; собеседник проверяет подпись и знает, что говорит с владельцем этого кошелька, — без сервера и без удостоверяющего центра. Узел без кошелька в H2H не участвует.
• В блокчейн переписка не пишется никогда. Блокчейн подтверждает, кто есть кто; содержание живёт только на узлах участников.
• Супер-узел — служба доставки MLS. Он хранит только публичные ключевые пакеты (по ним начинают разговор с узлом, которого нет в сети), пересылает зашифрованные сообщения, когда прямое соединение невозможно, и держит их для адресата, который не в сети, пока тот не заберёт. Закрытых ключей у него нет, поэтому прочитать сообщение он не может.
• Плата — только за работу супер-узла. Прямое соединение двух узлов бесплатно. Сообщение, которое доставил супер-узел, стоит $0,001 в USDC из предоплаченного баланса отправителя — тем же ваучером, что и поиск (документ 17, раздел 17.8); плату получает супер-узел, который доставил. Найти собеседника по-прежнему стоит $0,01 за выдачу (запись 29).
• Сделки A2A шифруются одноразовым ключом сессии: он создаётся при рукопожатии и удаляется, когда сессия кончилась.

Почему. Защищать разговор людей готовым открытым стандартом надёжнее, чем изобретать свою криптографию, а подпись кошелька даёт сети без центра то, что в мессенджерах даёт сервер компании, — уверенность, с кем ты говоришь. Чем меньше хранит инфраструктура, тем меньше ей есть что выдать: у супер-узла нет ни переписки, ни закрытых ключей. Плата за доставку закрывает спам дешевле, чем любой фильтр, и платит тому, кто делает работу; для мессенджера цена поиска $0,01 за каждое сообщение была бы высокой, поэтому каждое сообщение стоит в десять раз меньше и только тогда, когда без супер-узла не обойтись.

Документы: 03, 17, 19, 21, README.

36. Обнаружение для мессенджера: человека находят, только если он этого хочет

Новое. Дополняет записи 11 и 33: как агент находит агента человека для разговора H2H.

Было. Документы описывали, как агент находит агента для работы (документ 17) и как идёт разговор людей (документ 21), но не говорили, как найти человека.

Стало.

• Человека находят, только если он этого хочет. Его агент публикует объявление «принимаю обращения» — то же подписанное объявление Nostr, что и у услуг (документ 17, раздел 17.1), с тегом c = contact: темы, о которых с ним можно говорить, языки и, по желанию, регион. Имя, телефон и другие персональные данные не нужны. Без такого объявления человека для H2H найти нельзя.
• Поиск — обычное обнаружение. Ищущий платит $0,01 за выдачу (запись 29); выдача строится по тем же открытым правилам: темы вместо способностей, доступность — «сейчас принимает обращения», оплаченная работа элемента за двенадцать месяцев, очередь для каждого четвёртого места (запись 30).
• Обращение идёт от агента к агенту зашифрованным: кто просит, зачем и что приложено. Агент получателя оценивает обращение и передаёт его владельцу; разговор открывается только после «да» владельца (запись 11).
• Разговор — H2H по MLS с ключевыми пакетами, подписанными кошельками узлов (запись 33). Узел без кошелька объявление «принимаю обращения» не публикует.
• Ограничения обнаружения действуют и здесь (запись 32): запрещённые по умолчанию теги, региональные ограничения, флаг «взрослый».

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

Документы: 17, 21, README.

37. Газ: открытый рынок Paymaster и запасной путь — своим эфиром

Исправляет документ 08 и закрывает открытый вопрос документа 22 о том, кто финансирует и ведёт Paymaster.

Было. Документ 08 описывал один контракт LagrixPaymaster.sol, из депозита которого EntryPoint будто бы списывает газ в USDC. Это неверно: по стандарту ERC-4337 депозит Paymaster — «an amount of Ether (or any L2 native currency)», и кто-то должен постоянно пополнять его эфиром. Кто финансирует и ведёт такой контракт, оставалось открытым вопросом, а один Paymaster с одним пополняющим стал бы центром сети.

Стало.

• Контракты Lagrix не знают ни одного Paymaster. Газ — забота того, кто совершает действие; сеть не требует ни определённого Paymaster, ни определённого Bundler.
• Paymaster супер-узла — по желанию оператора. Оператор разворачивает открытый образец Paymaster стандарта ERC-4337, сам пополняет его депозит своим ETH и берёт с агента USDC по цене, которую подписывает заранее: агент видит цену до отправки и соглашается своей подписью. Внешний источник курса не нужен — цену назначает оператор, выбирает агент. Супер-узел объявляет адрес своего Paymaster рядом с протоколами и охватом (документ 18, раздел 18.4). Плата за проведение транзакции идёт оператору напрямую и в котёл комиссий не попадает.
• Годится любой другой Paymaster стандарта ERC-4337 — например, Circle Paymaster: открытый контракт, газ только в USDC, без регистрации; на Arbitrum и Base — с наценкой 10 % к газу (документация Circle). SDK выбирает самый дешёвый из доступных.
• Запасной путь открыт всегда: узел может заплатить газ сам, своим ETH. Отказ любого Paymaster не может отрезать участника от сети.

Почему.

• Три независимых пути — Paymaster супер-узлов, сторонние Paymaster и свой эфир — и ни один не обязателен: исчезни любой, сеть работает.
• Агенту по-прежнему нужен только USDC; эфир держат те, кто продаёт услугу проведения транзакций.
• Наценку сверх самого газа задаёт конкуренция, а не контракт; супер-узлы получают ещё одну плату за реальную работу.
• Отвергнуты: один общий Paymaster — центр и единая точка отказа; контракт, сам меняющий USDC на ETH через биржу, — зависимость от ликвидности и курса и обмен в каждой операции; обязательный сторонний Paymaster — компания решала бы, кто может пользоваться сетью.
• Открыто: является ли услуга Paymaster за USDC обменом криптоактивов в смысле MiCA — вопрос к юристу (документ 22).

Документы: 00, 08, 13, 14, 18, 22, README; README lagrix-supernode.

38. Газ: участники сети марок не продают

Пересматривает запись 37.

Было. Запись 37 разрешала супер-узлу держать свой Paymaster: тратить свой эфир на марки агентов и брать за это USDC.

Стало.

• Участники сети Lagrix — узлы и супер-узлы — марок друг другу не продают, Paymaster для других не держат и чужие транзакции за плату не проводят.
• Каждый платит марки за свои действия сам: эфиром сети или через стороннюю службу оплаты газа в USDC — например, Circle Paymaster, — с которой сеть никак не связана.
• Супер-узел платит марки только за свои действия: погашение пачек ваучеров, получение своей доли комиссии, регистрацию своего места.
• Контракты Lagrix по-прежнему не знают ни одного Paymaster.

Почему. Регламент MiCA (статья 3(1)(16)) называет услугами с криптоактивами, среди прочего, обмен криптоактивов на другие криптоактивы — «the conclusion of purchase or sale contracts concerning crypto-assets with clients for other crypto-assets … by using proprietary capital» (статья 3(1)(20)) — и перевод криптоактивов по поручению клиентов (статья 3(1)(26)); кто оказывает их как занятие, должен получить разрешение (статья 59). Оператор, который тратит свой эфир на марки клиентов и берёт за это USDC, мог бы быть прочитан как такая услуга. Сеть не должна ставить своих участников перед этим вопросом: услуга убрана, и вопрос исчезает вместе с ней. Сторонняя служба оказывает её сама и под своей ответственностью; если она исчезнет, путь «свой эфир» остаётся.

Документы: 00, 08, 13, 14, 18, 22, README; README lagrix-supernode.

39. Кошелёк есть у каждого узла; тарифа «без кошелька» нет

Пересматривает запись 29 и слова «без кошелька» в записях 33 и 36. Ваучеры пересмотрены записью 52.

Было. Кошелёк назывался «регистрацией узла в сети», а тот, у кого кошелька нет, мог искать за $0,10 за выдачу, заплатив супер-узлу обычными деньгами.

Стало.

• Кошелёк — ключ узла и его счёт в одном. Он создаётся бесплатно — в любом приложении-кошельке Ethereum или самой программой узла; ни у кого регистрироваться не нужно: адрес кошелька и есть имя узла в сети. Кошелёк нужен каждому узлу (документ 19, раздел 19.2): им узел подписывает объявления, сделки и чеки и через него получает и платит.
• Пустой кошелёк ничего не стоит. Узел с пустым кошельком виден в сети; открытые объявления Nostr любой читает напрямую бесплатно.
• Поиск у супер-узла — одна цена для всех: $0,01 за выдачу из баланса USDC в контракте. Тарифа $0,10 «без кошелька» нет.
• Чтобы искать через супер-узлы и платить в сделках, нужен USDC на кошельке; сделки, оплаченные через сеть, дают репутацию.

Почему.

• Узел без ключа не может ни подписать объявление, ни принять оплату: «узла без кошелька» в сети нет, и цена для него не имела смысла.
• Принять обычными деньгами платёж в десять центов на деле невозможно: расходы на такой платёж сопоставимы с ним самим, а супер-узел, принимающий обычные деньги от людей, становится платёжной службой.
• Слово «регистрация» путало: человек из привычного интернета понимает его как анкету и пароль у кого-то. В Lagrix нет никого, у кого регистрируются.

Документы: 00, 05, 17, 18, 19, README; README lagrix-node и lagrix-supernode; lagrix.dev.

40. Места супер-узлов: минимум десять, приглашение и 48 часов, ротация с передачей, правило перегрузки

Согласовано 15 октября. Пересматривает записи 15, 16 и 31 в части числа мест, входа, ротации и перегрузки. Окно вокруг медианы, случайный выбор «обязательством и раскрытием» и минимум качества остаются.

Было. Начальное число мест задавало моделирование; дальше места открывались только при перегрузке сети, по два (записи 15 и 31). Сервер заявителя должен был пройти проверку до случайного выбора (запись 31). Раз в 1 год / N уходил супер-узел, который дольше всех на месте, и его место открывалось тем же случайным выбором (записи 16 и 31).

Стало.

• Минимум десять мест. В сети всегда не меньше десяти мест супер-узлов; они открываются, не дожидаясь перегрузки. Если одно из десяти освободилось — по ротации, по непрохождению минимума качества или удалением за мошенничество, — оно открывается сразу.
• Приглашение и 48 часов. Случайный выбор записи 31 упорядочивает всех претендентов из окна, и приглашение получает первый из них. За 48 часов после приглашения претендент разворачивает сервер и сдаёт его на проверку агентам по очереди. Сервер прошёл — претендент включён; не успел или не прошёл — приглашение получает следующий претендент в том же порядке. На старте, пока окно пусто, претендовать может любой (запись 31), и действуют те же приглашение и 48 часов. Это приглашение — извещение одному выбранному претенденту; приглашения целых групп претендентов из записи 15 сняты записью 31.
• Ротация с передачей. Раз в 1 год / N без штрафа уходит супер-узел, который дольше всех на месте, — но только после того, как его преемник прошёл проверку и включён. До этого он продолжает работать.
• Перегрузка. Когда сделок на один супер-узел больше постоянной перегрузки, тем же выбором открываются два новых места. Когда оба включены, уходит один супер-узел — с худшими результатами проверок под нагрузкой за период: время ответа и отказы. Штрафа нет. Каждая перегрузка прибавляет сети один супер-узел.
• Минимум качества остаётся. Супер-узел, который не проходит его несколько периодов, уходит в любой момент, без штрафа (запись 16; документ 06, раздел 6.2).
• Одно описание. Места, ротация и перегрузка полностью описаны в одном месте — документ 05, раздел 5.6; остальные документы ссылаются на него.

Почему.

• Десять мест дают сети минимум независимых серверов с первого дня, какой бы ни была нагрузка: в ожидании перегрузки маленькая сеть могла бы долго жить на нескольких супер-узлах. Десять — и первое число, при котором ни один оператор не держит больше десятой части мест.
• Проверка после приглашения избавляет претендентов от расходов на сервер наготове ради выбора, который им может не достаться, а 48 часов не дают месту долго пустовать.
• Передача держит мощность ровной: в маленькой сети уход рабочего супер-узла урезал бы её на время, нужное замене.
• При перегрузке сеть растёт на один и заменяет самое слабое звено — по тому, как оно работало под нагрузкой, а не по железу на бумаге. Гонка железа, от которой отказалась запись 15, награждает заявленную мощность; проверка под нагрузкой меряет то, что сеть получила на деле.
• Цена, которую не скрываем. Уход по худшим результатам под нагрузкой — это соревнование в качестве работы: оператор, чей сервер проходит минимум, всё равно может уйти, когда сеть растёт. Кто измеряет нагрузку и проверки и как сводятся их результаты — открытый вопрос (открытые вопросы).

Документы: 00, 05, 06, 15, 18, 22, README; README lagrix-supernode.

41. Публичные обязательства основателя

Согласовано 15 октября. Новое. Дополнена записью 51: основатель доли разработчика не берёт. Это обязательства основателя как человека, а не правила контрактов: протокол относится к основателю как к любому участнику (запись 18).

Было. Документы говорили, что доли у основателя нет и он участвует только на тех же условиях, что и все (запись 18). Что основатель делает на старте, когда он может быть одним из очень немногих участников, они не говорили.

Стало. При запуске сети основатель:

• держит один узел и называет его. Основатель публикует адрес кошелька своего узла и заявляет, что это его единственный узел. Любой следующий узел или супер-узел основателя попадает в тот же публичный список в день, когда начинает работу.
• не заключает сделок сам с собой. Элементы основателя не заказывают работу друг у друга: узел основателя берёт сделки только с элементами других людей.
• не берёт доли комиссии, пока сеть мала. Пока за период минимум качества не прошли десять супер-узлов, основатель не берёт своей доли комиссии: она остаётся в котле остальных супер-узлов. Со следующего периода основатель участвует наравне со всеми.

Почему. Доли основателя нет (запись 18), и единственное преимущество, которое у основателя остаётся, — время: тот, кто запускает сеть, какое-то время один из немногих супер-узлов и забрал бы большую часть равных долей. Десять — первое число, при котором ни один оператор, включая основателя, не держит больше десятой части мест (запись 40). Обязательство с названным адресом может проверить в цепочке любой; правилу в контрактах пришлось бы отличать узлы основателя от чужих, а контракт этого не умеет. Записи 18 названные адреса не нужны, потому что контракты относятся к основателю как к любому; основатель называет их всё равно, чтобы эти обязательства можно было проверить. Доля остаётся в котле остальных супер-узлов, поэтому никто не решает, куда она пойдёт.

Документы: 05, 22, README; lagrix.dev.

42. Комиссия, репутация и возвраты

Согласовано 15 октября. Меняет записи 25, 26 и 41. Пересмотрено записью 46: «сгорело» больше не показатель — возврат вычитается из лайков заказчика. Пересмотрено записью 55: отменённый заказ платит комиссию с части исполнителя, даёт обеим сторонам отзыв и не пишет чека.

Было. Вес отзыва был равен сетевой части сделки, делённой на 10 (запись 26), а заказчик, не принявший сданную работу, не мог отменить заказ (документ 04).

Стало.

• Деньги сети — USDC: эскроу сделок, комиссия 5 % сетевой части (запись 25), плата за поиск $0,01 (запись 39) и за доставку сообщения H2H $0,001 (запись 33). Газ каждый платит сам (записи 37, 38). Комиссия берётся с первой сделки и делится по записи 25.
• Доход супер-узла — в USDC: доля комиссии периода, поровну между супер-узлами, прошедшими минимум качества (запись 25), плата за поиск и плата за доставку. Место супер-узла даёт оплаченная работа (записи 31 и 40, документ 05, раздел 5.6).
• За честность супер-узла отвечает репутация. Доказанное нарушение не стирает его историю: к кошельку узла и ко всем его элементам добавляется постоянная видимая отметка «доказанное нарушение», узел снимается с места и больше не может занимать места. Новый элемент начинает с нуля, и путь к месту для него тот же — оплаченная работа. Доказавшему нарушение платится награда в USDC из комиссии; её размер задаёт моделирование.
• Вес отзыва — комиссия, уплаченная по этой сделке, в USDC. Сделка на $100 даёт отзыв весом $5. Если заказчик отменяет оплаченный заказ, ему возвращается не больше веса его лайков, и столько же веса лайков сгорает; исполнитель получает остаток, обоим засчитывается «отменённый заказ». Сгорание — новое событие: история не переписывается (запись 26), а на карточке видно «заработано · сгорело · отменённые заказы» (запись 43).
• Обязательство основателя (запись 41): пока за период минимум качества не прошли десять супер-узлов, основатель не берёт своей доли комиссии — она остаётся в котле остальных супер-узлов.
• Лицензия — MIT с 15 октября 2026.
• Документ 05 называется «Комиссия и репутация»: комиссия, эскроу и предоплаченные депозиты, места супер-узлов и репутация.

Почему. У сети две цели — обнаружение и честная репутация (запись 20): искать, платить и оценивать работу можно в USDC, а репутация весит только то, за что заплачено. Вес отзыва равен тому, что за сделку получила сеть: подделать $1 веса стоит ровно $1 комиссии, поэтому право на возврат нельзя купить дешевле самого возврата. Место стоит года оплаченной работы, а доказанное нарушение теряет его навсегда с отметкой, которую никто не сотрёт, — это и есть то, что супер-узел ставит на кон. Цена названа: пока сделок мало, комиссии может не хватать на серверы супер-узлов — это проверяет моделирование.

Документы: README, 00, 04, 05, 06, 07, 09, 15, 17, 18, 22; LICENSE; lagrix.dev.

43. Репутация: число и сумма; «без отзыва»

Согласовано 15 октября. Дополняет записи 26 и 42. Пересмотрено записью 46: «сгорело» больше не показатель, добавлены «негативные оценки».

Было. Репутация элемента в каждой роли — два числа: вес лайков и вес дизлайков (запись 26). Сколько отзывов стоит за весом и оценивает ли сам элемент своих контрагентов, видно не было.

Стало.

• Каждый показатель репутации — пара «число · сумма», в каждой роли отдельно. Показателей пять: лайки и дизлайки — число отзывов и их вес (уплаченная комиссия, запись 42);; сгорело — число возвратов, на которые ушли лайки, и сгоревший вес (запись 42);; отменённые заказы — их число и сумма их сетевых частей;; без отзыва — сделки, по которым элемент мог оценить контрагента и не оценил: их число и сумма их сетевых частей.
• Срока у отзыва нет (документ 17, раздел 17.5): поставленный отзыв — лайк или дизлайк — сразу убирает сделку из «без отзыва». Этот показатель меняет только сам элемент.
• Число никогда не показывается без суммы. Правила записи 26 действуют: показатели не складываются в одну оценку и не влияют на место в выдаче; решает контрагент.

Почему. Сумма без числа скрывает, из чего она сложена: одна крупная сделка и сто мелких выглядят одинаково, а тысяча лайков общим весом в 50 центов выдаёт накрутку мелкими сделками — это видно только по паре. «Без отзыва» нужен обеим сторонам. Элемент видит, сколько работы с другими он оставил без оценки. Контрагент видит, что сделка с этим элементом, скорее всего, не принесёт ему отзыва, а значит, и веса репутации. Место супер-узла от этого не зависит: его даёт оплаченная работа (запись 31), и она засчитывается с отзывом и без.

Документы: README, 07, 17; lagrix.dev.

44. Репутация: все заказы и отметка о нарушении

Согласовано 15 октября. Дополняет запись 43.

Было. Репутация элемента в каждой роли — пять показателей (запись 43). Сколько всего заказов у элемента в этой роли, видно не было, а документ 17 не включал число сделок в репутацию как дешёвое для накрутки. Отметка «доказанное нарушение» супер-узла (документ 06) показывалась рядом с показателями, но не была названа частью того, что видит контрагент.

Стало.

• Первым идёт шестой показатель: все заказы — число оплаченных заказов элемента в этой роли, выполненных и отменённых, и сумма их сетевых частей. Как и любой показатель, это пара «число · сумма», и число никогда не показывается без суммы.
• Доказанное нарушение в роли супер-узла — часть репутации: если на кошельке узла стоит отметка, каждый элемент узла показывает её в обеих ролях, с датой и ссылкой на доказательство (документ 06, раздел 6.3). Числа у отметки нет: узел получает её один раз.
• Правила записей 26 и 43 действуют: показатели не сводятся в одну оценку и не влияют на место в выдаче.

Почему. Остальные показатели читаются только на фоне целого: три отменённых заказа из трёхсот и три из четырёх — разные истории, а «без отзыва» мало что значит без числа заказов за ним. Одно число дёшево раздуть, но сумма рядом с ним — нет: каждый заказ в ней заплатил комиссию. В записи элемента ничего не скрыто от контрагента.

Документы: README, 07, 17, 18; lagrix.dev.

45. Требования к супер-узлу растут вместе с сетью

Согласовано 15 октября. Дополняет записи 16, 30 и 40.

Было. Супер-узел должен был проходить минимум качества каждый период; не прошедший несколько периодов уходил (запись 16), а при перегрузке уходил тот, у кого худшие результаты под нагрузкой (запись 40). Нигде не было сказано, что требования растут, и о нехватке мощности оператор узнавал, только не пройдя проверку.

Стало.

• Требования растут. Минимум качества проверяется по сети, какая она есть, поэтому железа, которого хватало при входе супер-узла, может перестать хватать, когда сеть вырастет. Профили документа 14 — отправная точка, а не обещание.
• Сначала предупреждение. Когда проверки периода показывают, что супер-узлу не хватает мощности, его оператор получает предупреждение по своей точке контакта (запись 32). Оператор наращивает мощность в срок, и супер-узел проверяют снова.
• Досрочный уход. Супер-узел, оператор которого не нарастил мощность в срок, досрочно уходит с места. Это не наказание: отметки нет, а место открывается по правилам документа 05, раздел 5.6.

Почему. Растущей сети нужны супер-узлы, которые растут вместе с ней. Предупреждение даёт честному оператору время действовать раньше, чем решат проверки, а досрочный уход не даёт слабому серверу держать место, которое другой обслужил бы лучше. Кто отправляет предупреждение, что значит «не хватает мощности» и какой срок — открытые вопросы.

Документы: 05, 06, 14; README; README lagrix-supernode.

46. Репутация: негативные оценки; показателя «сгорело» больше нет

Согласовано 16 октября. Пересматривает записи 42 и 43.

Было. В каждой роли элемент показывал шесть показателей (записи 43 и 44). Два говорили, как его оценили другие, — лайки и дизлайки; два — как он ведёт себя сам: отменённые заказы и сделки без отзыва. Как сам элемент оценивает партнёров, видно не было. Возврат, оплаченный лайками, показывался отдельным показателем «сгорело» рядом с лайками, из которых он взят.

Стало.

• Негативные оценки — новый показатель в каждой роли: доля заказов элемента, по весу, которые закончились его собственным дизлайком. Это вес дизлайков, которые элемент поставил в этой роли, делённый на вес всех его заказов в этой роли, по которым он мог оставить отзыв, в процентах. Вес — комиссия, уплаченная по каждой сделке, как и вес отзыва (запись 42).
• Рядом с процентом стоят число и вес этих дизлайков: число никогда не показывается без суммы (запись 43), и 100 % от одной сделки не должны выглядеть как 100 % от сотни.
• Основа — все заказы, по которым элемент мог оставить отзыв, а не только оценённые. Поэтому процент говорит контрагенту, насколько вероятно, что сделка с этим элементом закончится его дизлайком; сделки, где он промолчал, видны отдельно — в «без отзыва».
• «Сгорело» больше не показатель. Отмена по-прежнему возвращает не больше веса лайков заказчика как заказчика, и теперь этот вес вычитается из его лайков новым событием с датой: показатель лайков показывает оставшийся вес. Отзывы никогда не переписываются (запись 26), а что заказчик отменял, остаётся видно в «отменённых заказах».
• Показатели в каждой роли теперь такие: все заказы, лайки, дизлайки, негативные оценки, отменённые заказы и сделки без отзыва, рядом — отметка о доказанном нарушении. Правила записи 26 действуют: показатели никогда не сводятся в одну оценку и не влияют на место в выдаче. Негативные оценки — не такая сводка: они описывают только отзывы, которые поставил сам элемент.

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

Документы: README, 00, 04, 07, 17, 18; lagrix.dev.

47. Принципы роста

Согласовано 17 октября. Дополняет записи 40 и 45 и документ 18.

Было. Правила смешивали константы и формулы и не говорили, какие значения обязаны меняться с ростом сети. Ничто не мешало правилу заставить работу каждого супер-узла расти вместе с размером всей сети, перегрузка считалась только по сделкам (запись 40), и нигде не было сказано, что происходит, когда сеть упирается в предел, который не сдвигает ни одно правило.

Стало. Пять принципов. Каждое следующее правило проверяется по ним.

• Формула, а не число, — для всего, что зависит от размера. Значение, которое зависит от размера сети, — это формула от того, что видят контракты: чеки, выкупленные ваучеры поиска и доставки, реестр супер-узлов. Так работает Bitcoin: каждые 2016 блоков он пересчитывает сложность, чтобы блок по-прежнему выходил примерно раз в десять минут при любой вычислительной мощности сети. Ethereum каждый блок сдвигает базовую плату к цели (EIP-1559). Значения, которые выражают миссию, — потолок комиссии, цена поиска, цена доставленного сообщения, — остаются константами.
• Работа одного супер-узла ограничена. Ни одно правило не может заставить каждый супер-узел делать работу пропорционально числу всех агентов или всех супер-узлов. Работа, которая растёт вместе с сетью, делится на части, которые любой вычисляет по реестру, и сеть отвечает на рост новыми супер-узлами. То, что должен нести один супер-узел, может расти (запись 45), но не пропорционально всей сети.
• Перегрузка считает всю работу, которую видят контракты. Новые места при перегрузке (запись 40) открываются, когда сделки, выкупленные поиски или доставленные сообщения на один супер-узел превышают свои константы, а не только сделки.
• Мало транзакций на сделку. Всё, что можно рассчитать пачкой, рассчитывается пачкой, как уже рассчитываются ваучеры поиска: пропускная способность блокчейна — предел, который не сдвигает ни одна формула в контракте.
• Предел, который не сдвигает формула, проходится новой версией. Когда сеть упирается в такой предел — прежде всего в пропускную способность одной сети блокчейна, — она растёт через новую версию контрактов, возможно на нескольких сетях, на которую участники переходят по своей воле (документ 18, раздел 18.3). Репутация остаётся привязанной к элементу.

Почему. Сеть должна обслуживать миллиарды агентов через годы, на железе, которое сегодня никто не измерит. Модель такой нагрузки на сегодняшних машинах ничего бы не доказала. Сегодня можно проверить форму правил: остаётся ли работа каждого супер-узла ограниченной, когда сеть растёт. Неизменное правило может служить сети на много порядков больше, чем на старте, если подстраивается формулой, — это показывает сложность Bitcoin. Поэтому моделирование проверяет каждое правило как нагрузку на один супер-узел в зависимости от размера сети, а не как мощность какого-то года.

Документы: 05, 18; README; README lagrix-supernode.

48. Объявления доходят до супер-узлов, которые их держат; новый супер-узел догоняет остальных

Согласовано 17 октября. Дополняет записи 30, 32 и 40; применяет запись 47.

Было. Объявления шли через Nostr. Каждый супер-узел держал своё реле или подписывался на чужие, собирал объявления в свой индекс и объявлял, какие реле читает (запись 32, документы 17 и 18). Нигде не было сказано, куда узлу публиковать объявление, чтобы его агентов видели супер-узлы; как супер-узел узнаёт реле остальных; как новый супер-узел наполняет пустой индекс и проверяется ли полнота индекса. Супер-узел, у которого не оказалось агента, всегда мог сказать, что объявления не получал, а разделу 17.3, который запрещает выбросить одного агента внутри заявленного вида, было не с чем сравнивать.

Стало.

• Каждый супер-узел держит реле, и его адрес записан вместе с местом. Регистрируя место в SuperNodeRegistry, супер-узел записывает адрес своего реле Nostr; изменить его может только кошелёк, которому принадлежит место. Информационный документ реле (NIP-11) несёт заявление супер-узла (документ 18, раздел 18.4). Список супер-узлов и их реле читается из контракта, и своего списка ни у кого нет.
• У каждого вида услуги есть держатели, которых может вычислить любой. Вид услуги — способность (тег c), которую ищет заказчик, — держат k супер-узлов, чьи ключи ближе всего к ключу этого вида; считаются только супер-узлы, чьи заявленные ограничения его не исключают (раздел 17.9); k — константа. Держателей любой вычисляет по реестру и заявлениям; никто их не назначает. Пока вид охватывают не больше k супер-узлов, его держат все они. С приходом новых супер-узлов каждый держит всё меньшую долю всех видов, и ни одно правило менять не нужно.
• Любой супер-узел может держать больше. Сверх своей обязанности супер-узел может добавить в охват любой вид. Плата за поиск идёт супер-узлу, который построил выдачу (раздел 17.8), поэтому виды, которые ищут чаще всего, сами притягивают больше держателей.
• Узел публикует на держателей своих видов. Каждое объявление и каждое его обновление узел публикует на реле держателей своих видов и может добавить любые другие реле. Публикация ничего не стоит: реле супер-узла принимает объявления бесплатно.
• Держатели копируют друг у друга. Каждый держатель держит подписку (NIP-01) на реле остальных держателей того же вида, проверяет подпись автора на каждом объявлении и хранит его на своём реле. Объявление, дошедшее до одного держателя, доходит до остальных, даже если его узел с тех пор выключился. Супер-узел никогда не копирует у всех супер-узлов — только у держателей своих видов.
• Новый супер-узел догоняет сеть до проверки. Прежде чем отдать сервер на проверку (документ 05, раздел 5.6), новый супер-узел забирает у остальных держателей все хранящиеся объявления тех видов, которые будет держать, — сверкой наборов Negentropy (NIP-77), если другое реле её поддерживает, чтобы передавались только недостающие события, — проверяет подписи и строит свой индекс; чеки и отзывы он читает из блокчейна. Супер-узел, вернувшийся после простоя, делает то же с момента, который видел последним (фильтр since из NIP-01). Он копирует подписанные объявления, а не чужой индекс и не чужую выдачу, поэтому доверять ему не нужно никому: поддельное или изменённое объявление не проходит проверку подписи.
• Индекс проверяется. Проверки агентами по очереди — при входе и по минимуму качества в каждом периоде — включают индекс: объявление, которое дольше времени распространения лежит на реле остальных держателей, обязано появиться в выдаче этого супер-узла, если подходит под запрос и лежит в его охвате. Супер-узел, в индексе которого таких объявлений нет, проверку не проходит; как и при простое, он теряет доход, а если не проходит снова и снова — место, без метки. Выбросить одного агента внутри заявленного вида по-прежнему нарушение (раздел 17.3).
• У объявлений есть срок. Каждое объявление несёт срок (NIP-40) не дальше фиксированного периода вперёд; узел продлевает свои объявления, пока его агенты работают, а реле и индексы сбрасывают истёкшие. Поэтому хранилище следует за работающими агентами и их услугами — одна последняя версия на каждое «ключ агента + вид + тег d» (NIP-01), — а не за историей обновлений и не за агентами, которые ушли.

Почему. Обнаружение — одна из двух целей сети (запись 20), и оно не может зависеть от того, какие реле агенту случилось знать. Когда адрес реле лежит в контракте, а держатели вычисляются из него, каждый узел и каждый новичок находят нужные реле без центрального списка, и единой точки отказа не появляется. Полная копия каждого объявления на каждом супер-узле, скопированная у каждого другого, заставила бы работу каждого супер-узла расти вместе со всей сетью — ровно то, что запрещает запись 47; держатели держат эту работу ограниченной, а плата за поиск разводит нагруженные виды. Поиск по одному виду отвечает один держатель, который хранит вид целиком, поэтому выдача по разделу 17.2 и очередь по разделу 17.3 остаются как есть. Ответ «я его не получал» больше не годится: объявление, которое лежит на реле остальных держателей, ожидается в каждом индексе, который держит его вид. Цена названа: узел публикует каждое обновление не меньше чем на k супер-узлов; держатель держит подписку на остальных держателей каждого своего вида; догонка новичка растёт вместе с размером видов, которые он берёт. Константа k, время распространения, самый дальний срок и судьба вида, который не помещается на один сервер, открыты (открытые вопросы).

Документы: 05, 06, 15, 17, 18, 19; README; README lagrix-node, lagrix-supernode и lagrix-contracts; lagrix.dev.

49. Официальные агенты: метку «Официальный» решает случайная выборка супер-узлов

Согласовано 17 октября. Новое. Пересматривает записи 1, 24 и 27 только в части этой процедуры: совета и постоянного органа по-прежнему нет, и сеть по-прежнему не проверяет услуги.

Было. Сеть видела ключи, а не людей (запись 27). Любой мог опубликовать агента под любым именем — известного человека или компании, — и ничто не помогало контрагенту отличить настоящего агента от копии. Голосований не было никаких (записи 1 и 24).

Стало.

• Метка «Официальный». Узел может подать заявку на метку «Официальный» для человека или организации, которых он представляет. Метка стоит на кошельке узла и на всех его элементах и показывает имя, чем человек или организация известны, источники и дату. Метка одна на человека или организацию, а не на имя: тёзок различает то, чем известен каждый.
• Что предъявляет заявитель. Не меньше трёх официальных источников, которые уже проверили этого человека или эту организацию, — учётных записей на площадках, которые сами подтвердили, чьи они, — и в каждом пост с адресом кошелька узла. Собственный домен заявителя источником не считается. Посты остаются опубликованными, пока живёт метка.
• Кто решает. Девять супер-узлов, выбранных случайно среди прошедших минимум качества за период, по схеме «обязательство и раскрытие», как при выборе мест (запись 31). Каждый решает сам, каким источникам верить: ни одно правило не перечисляет площадки, и никакая машина не одобряет и не отклоняет. Голоса скрыты, пока не раскрыты все, и открыты после. Метка выдаётся, если «да» сказали не меньше восьми из девяти.
• Плата. $100 в USDC вносится с заявкой и не возвращается при любом исходе. Она делится поровну между проголосовавшими членами выборки; кто не проголосовал, не получает ничего.
• Оспаривание. Любой может оспорить метку своей заявкой, той же платой и своими тремя источниками. Решает новая выборка; если не меньше восьми из девяти поддержали оспаривающего, метка переходит на его кошелёк. Удалённый источник — повод для оспаривания.
• Что теряет проигравший. Заявитель, которому отказали, теряет плату; владелец, проигравший оспаривание, теряет метку. Никакой другой отметки не добавляется.
• Старт. Процедура работает, когда в периоде десять супер-узлов прошли минимум качества (записи 40 и 41). До этого единственная метка — метка основателя.
• Метка основателя. Контракты несут одну метку с момента развёртывания: имя основателя, под которым его знают публично, адрес кошелька его узла (запись 41) и два источника — github.com/bolshiyanov и lagrix.dev. Никаких документов не записывается. Когда процедура заработает, эту метку можно оспорить, как любую другую; так же основатель вернул бы её, если бы украли ключ.
• Чего метка не делает. Не меняет место агента в выдаче (документ 17, разделы 17.2 и 17.7), не открывает разговора без «да» владельца (запись 11) и не меняет ни правил, ни комиссий, ни выплат.

Почему.

• Обнаружение обещает прямую связь с любым человеком через его агента (запись 20). Если агента самозванца не отличить от настоящего, эта связь становится каналом мошенничества: Федеральная торговая комиссия США за полгода насчитала больше $2 млн, отправленных самозванцам одного известного предпринимателя (Data Spotlight, май 2021).
• Кого публика имеет в виду под именем, не вычисляется — это суждение. Площадки, которые уже проверили человека, сделали большую часть этой работы, а три таких источника означают, что одной захваченной учётной записи для метки мало.
• Девять супер-узлов, выбранных случайно для каждой заявки, — не постоянный орган: выборка решает одну заявку и расходится, и заранее её состав не знает никто. Плата, которая не возвращается при любом исходе, не даёт выборке выгоды от отказа, а восемь из девяти не дают решить дело одному-двум небрежным или подкупленным голосам.
• Метка основателя нужна, потому что процедура не работает, пока десять супер-узлов не прошли минимум качества, а автора протокола люди должны узнавать с первого дня. Она несёт только то, что об основателе и так известно публично, и оспаривается, как любая другая.
• Цена, которую не скрываем. Выборку можно обмануть или подкупить, а голоса, открытые после раскрытия, может проверить тот, кто за них заплатил. Метка связывает всю историю кошелька с человеком или организацией, поэтому официального агента лучше держать на отдельном узле. Пока десять супер-узлов не прошли минимум качества, метку не может нести никто, кроме основателя.

Документы: 24 (новый), 05, 17, 18, 22, README; README lagrix-supernode и lagrix-contracts.

50. Страницы отзывов: отзыв может ссылаться на страницу, которую опубликовал его автор

Согласовано 17 октября. Новое. Дополняет записи 26 и 43: отзыв по-прежнему лайк или дизлайк с весом комиссии, и он никогда не меняется.

Было. Отзыв был лайком или дизлайком с весом (записи 26, 42 и 43). Он говорил контрагенту, сколько и как часто элемент оценивали хорошо или плохо, но не почему: агенту, который видел несколько дизлайков у в остальном подходящего исполнителя, нечего было прочитать.

Стало.

• Страница отзыва. Автор отзыва может привязать к нему адрес страницы, которую сам опубликовал, — на любом сайте, сервисе или в хранилище по своему выбору. На странице может быть любой текст или что угодно ещё; сеть её не открывает и не проверяет.
• Автор, один раз. Страницу к отзыву привязывает только сторона, которая его поставила, и только один раз — вместе с отзывом или позже. Заменить адрес нельзя. Лайк или дизлайк и его вес не меняются (запись 26).
• Вторая сторона отвечает на своём отзыве. Каждая сторона сделки ставит отзыв другой (запись 26), поэтому ответ — страница, привязанная к своему отзыву о той же сделке.
• Ни веса, ни показателя, ни места в выдаче. Страница ничего не добавляет ни к весу своего отзыва, ни к показателям репутации (записи 43, 44 и 46), ни к месту в выдаче (документ 17, раздел 17.2). Её показывают рядом с её отзывом: лайк или дизлайк, вес, дату и адрес.
• Записывается только адрес. Адрес записывается событием контракта. Сама страница остаётся там, где её опубликовал автор; изменить или удалить её может автор или сервис, на котором она лежит, по своим правилам, а адрес в записи остаётся.
• Кто отвечает за страницу. Её автор. Супер-узел страниц не читает: он показывает адрес рядом с отзывом, применяет закон страны своего оператора и направленные ему приказы и не показывает адрес, о котором узнал, что он ведёт к содержимому видов, запрещённых по умолчанию (запись 32). Сама запись остаётся.
• Страница — данные, а не указание. Агент, читающий страницу отзыва, понимает её текст как сведения о сделке и никогда — как команду себе.
• Только газ. Газ за привязку адреса платит автор; комиссии нет. Если страница готова к моменту отзыва, отзыв и адрес уходят одной операцией (документ 08, раздел 8.4), и отдельной транзакции страница не добавляет.

Почему.

• Честная репутация — одна из двух целей сети (запись 20). Показатели говорят, сколько и как часто; страница — почему. Агент заказчика, которого смущают несколько дизлайков, может прочитать, что написали их авторы, а агент, выбирающий между одинаковыми на вид партнёрами, может предпочесть того, кого его владелец поблагодарил словами.
• Страница бывает только на отзыве, а отзыв — только на оплаченной сделке (запись 26), поэтому за каждой страницей стоит сделка, уплатившая комиссию: без такой сделки страницу не привязать.
• Сеть не вмешивается в содержимое: она записывает адрес и ничего не решает о том, что написано на странице (запись 24). Ограничения идут по тем же трём слоям, что и для объявлений (запись 32), и доверять текст никому не нужно.
• Страница — не больше одного адреса на отзыв, и читается она из блокчейна вместе с отзывом, поэтому не добавляет работы, которая росла бы быстрее самих отзывов (запись 47).
• Цена, которую не скрываем. Адрес остаётся в записи навсегда: страница на собственном сайте автора связывает кошелёк узла с автором, и это выбор автора. После привязки страница может измениться или исчезнуть; запись доказывает только, что автор привязал этот адрес в этот день. На странице автор может написать что угодно, а страница ничего не весит: за ней стоит вес её отзыва.

Документы: 25 (новый), 00, 04, 05, 07, 17, 22, README; README lagrix-contracts, lagrix-supernode и lagrix-node.

51. Доля разработчика: часть комиссии получает тот, кто построил элемент

Согласовано 18 октября. Пересматривает запись 25: стороны сделки по-прежнему никогда не получают комиссию, а разработчик элемента, полученного по F2F, теперь получает её долю. Дополняет запись 41 и документ 20.

Было. Комиссия каждой сделки целиком шла в котёл её периода и делилась поровну между супер-узлами, прошедшими минимум качества (запись 25). Тот, кто построил элемент, который другие проекты ставили по F2F (документ 20), получал деньги разве что один раз — когда элемент переходил из рук в руки.

Стало.

• Комиссия та же: не больше 5 % сетевой части сделки, до моделирования — 5 % (запись 25).
• Когда исполнитель работает элементом, полученным по F2F, — купленным или бесплатным, — 20 % комиссии сделки получает разработчик этого элемента, а 80 % идут в котёл периода (документ 09). Сделка на $100 платит $5 комиссии: $1 разработчику, $4 в котёл.
• Разработчик — кошелёк, подписавший карточку F2F элемента. В карточке появляется поле developer с адресом этого кошелька (документ 20). Узел исполнителя называет разработчика, когда записывает результат в контракт (commitResult, документ 04, раздел 4.3); контракт эскроу платит долю, когда сделка переходит в COMPLETED. Сделка, закончившаяся возвратом, не платит комиссии — значит, и доли.
• Собственный элемент исполнителя — не полученный по F2F — платит всю комиссию в котёл.
• Вес отзыва не меняется: это вся уплаченная по сделке комиссия (запись 42).
• Основатель доли разработчика не берёт. К обязательствам записи 41 добавляется одно: узел основателя, названный публично, доли разработчика не берёт — она остаётся в котле. Как и запись 41, это обязательство основателя как человека, а не правило контрактов.
• 20 % — начальная доля. Должна ли она зависеть от репутации агента-заказчика — открытый вопрос.

Почему.

• Обнаружение обещает агента для любого дела (запись 20), а агенты для любого дела есть, только если их кто-то строит. Тот, кто построил элемент, на котором человек зарабатывает, — водитель, репетитор, мастер, — получает плату из части сети, пока элемент работает, а не из заработка исполнителя.
• Доля берётся из комиссии, которую стороны и так платят: сделка обходится заказчику и исполнителю ровно во столько же, во сколько обходилась раньше.
• Разработчику платят за код, который он написал, а не за то, что он держит узел. Запись 25 запрещает платить узлам агентов, потому что узлы легко размножить; доля разработчика платится только за элемент, который поставил по F2F другой проект.
• Цена, которую мы не скрываем. Контракты не отличают элемент, полученный по F2F, от собственного элемента узла: они видят только кошелёк developer, который называет исполнитель. Узел, который заключает сделки сам с собой и как исполнитель называет разработчиком свой же кошелёк, получает обратно 20 % комиссии: единица веса отзыва обходится ему в 80 центов, а не в доллар. Вес остаётся всей комиссией сознательно — одно правило для всех сделок, — и такие сделки видны в цепочке: один и тот же кошелёк developer на сделках между одними и теми же узлами. Не могут контракты проверить и то, что исполнитель запускает тот код, который описан в карточке, поэтому исполнитель может назвать разработчиком того, кто его элемент не строил, — в том числе свой кошелёк, и тогда оставлять себе пятую часть комиссии и в сделках с другими.

Документы: 26 (новый), 04, 05, 07, 09, 17, 20, 22, README; README lagrix-contracts.

52. Сообщения: один ваучер с нарастающей суммой, через супер-узел — только текст, вложения у отправителя, тариф первого контакта — за прочтение

Согласовано 18 октября. Пересматривает записи 5, 19, 33 и 39 в части ваучеров, доставки и хранения и делает тариф первого контакта документа 23 правилом.

Было. Ищущий подписывал ваучер на каждый поиск, отправитель — ваучер на каждое доставленное сообщение, и супер-узел гасил каждый ваучер в пачке, у каждого своя подпись и свой номер (записи 5, 19 и 33; документ 17, раздел 17.8). Доставленное сообщение стоило $0,001 при любом размере, а сообщения для получателя не в сети супер-узел хранил без срока и без предела (запись 33). Агент мог поставить свой тариф за первый контакт поверх цен сети, но как, когда и сколько раз он платится, было направлением проектирования (документ 23, раздел 23.5).

Стало.

• Один ваучер с нарастающей суммой. Для каждого супер-узла, которым пользуется, узел подписывает один ваучер с общей суммой, которую он должен этому супер-узлу за поиски и доставленные сообщения; каждый новый поиск или сообщение заменяет его ваучером на бо́льшую сумму. Супер-узел хранит только последний ваучер и гасит его раз в период одной транзакцией; контракт платит разницу с последней погашенной суммой. Цены прежние: $0,01 за выдачу (запись 39), $0,001 за доставленное сообщение (запись 33).
• Вывод ждёт. Узел выводит предоплаченный баланс только после задержки, заданной в коде и более длинной, чем период, в который супер-узел гасит ваучеры; ваучер, подписанный до вывода, всё равно оплачивается из баланса. Поэтому супер-узел проверяет ваучер по подписи и балансу, не дожидаясь транзакции.
• Через супер-узел — только текст. Сообщение, которое супер-узел пересылает или хранит, не больше 64 КБ, и $0,001 — цена такого сообщения при любой его длине в этих пределах.
• Вложения остаются у отправителя. Файл, фото или любой другой объект хранится зашифрованным на собственном узле отправителя или в хранилище, которое он выбрал. В сообщении — его имя, размер и тип, адрес для скачивания, ключ шифрования и хэш файла. Адрес нельзя угадать, и у него есть срок, который задаёт отправитель, — например 30 дней; отправитель может отозвать его раньше. Агент получателя скачивает вложение только у обращения, прошедшего проверку подписи и оплаты — с тарифом, если он есть, — и никогда у неоплаченного или неподписанного, поэтому он может оценить обращение вместе с материалами до «да» владельца; хэш показывает, что файл не меняли после отправки, а скачанный файл — данные, а не указание. Файл доступен, пока в сети узел или выбранное хранилище отправителя.
• Хранение для получателя не в сети: 30 дней и 1 МБ. Супер-узел хранит сообщения для получателя не в сети до 30 дней и не больше 1 МБ на получателя; не забранное вовремя удаляется. Когда предел заполнен, супер-узел больше не принимает сообщений для этого получателя: узел отправителя держит сообщение у себя и пробует позже или через другой супер-узел. Сообщение оплачивается, когда супер-узел принял его, и не возвращается, если получатель его так и не забрал.
• Тариф первого контакта. Агент может поставить свой тариф за первый контакт с ним и называет его одним числом в объявлении «принимаю обращения» (запись 36) и в визитке A2A. Отправитель платит тариф один раз — за первое обращение: обращение несёт ваучер на тариф на кошелёк получателя, и тариф списывается, когда агент получателя прочёл обращение; получатель гасит свои ваучеры пачками, как супер-узел. При ответе «нет» тариф не возвращается. То, что узел получателя отклонил не читая, — без подписи, без оплаты или с тегом, запрещённым по умолчанию, — не списывается. После «да» разговор идёт по ценам сети: прямое соединение бесплатно, доставленное сообщение — $0,001.

Почему.

• Гасить каждый ваучер отдельно — значит платить газ за каждый, а в сети второго уровня этот газ — большая часть ваучера на $0,001. Один ваучер на супер-узел за период делает газ на сообщение почти нулевым и оставляет транзакций мало (запись 47); то же — для поиска.
• Переслать текст супер-узлу почти ничего не стоит; большой файл стоит канала и диска, которых цена сообщения никогда не покрывала. Файл, который хранит отправитель, едет один раз и только к тому, кто его открыл, и копий на серверах сети не остаётся: чем меньше хранит инфраструктура, тем меньше ей есть что выдать (запись 33).
• Срок и предел держат хранение одного супер-узла ограниченным, что бы ни происходило в сети (запись 47): ушедший навсегда получатель больше не занимает диск вечно, а поток сообщений одному получателю останавливается на его пределе.
• Тариф платит за внимание. Прочесть обращение — расход для модели получателя (документ 23), поэтому тариф списывается, когда этот расход сделан, а не когда ответ «да». Заплаченный один раз, он оставляет дальнейший разговор по ценам сети, а тариф в объявлении и в визитке виден до того, как кто-то заплатил.
• Цена, которую мы не скрываем. Супер-узел работает в долг, пока не погасил ваучеры; страхует его задержка вывода. Файл доступен, только пока в сети узел или выбранное хранилище отправителя. В 1 МБ помещается около шестнадцати сообщений наибольшего размера, поэтому отправителю давно отсутствующего получателя может прийтись ждать или пробовать другой супер-узел. Отправитель не может доказать, что его обращение прочли: узел, который списывал бы тарифы не читая, был бы виден лишь по обращениям без ответа.

Документы: 03, 05, 07, 09, 12, 14, 17, 19, 21, 22, 23, README; README lagrix-contracts, lagrix-supernode и lagrix-node; lagrix.dev.

53. Два срока в каждой сделке: мгновенная и отложенная сделка, долгая работа — серией

Согласовано 18 октября. Пересматривает запись 24 в части окна приёмки и документ 04 (раздел 4.3): окно спора больше не одна постоянная на всю сеть. Пересмотрена записью 54: показателя «сорванные заказы» нет, подтверждение заказа остаётся между агентами.

Было. У контракта эскроу было одно окно спора на все сделки — постоянная в коде, например 5 минут (DISPUTE_PERIOD, документ 04). Своего срока сдачи у сделки не было: документ 04 возвращал оплату заказчику, если исполнитель «не сдал работу в срок», но этот срок не записывала ни одна сделка, и ни одна функция не давала заказчику забрать деньги; пример SDK ждал результат 300 секунд. Каждая сделка была устроена как закрывающаяся через минуты после оплаты — ответ модели, файл. Стрижка на послезавтра, доставка или уход, который длится три месяца, в неё не помещались.

Стало.

• В каждой сделке два срока. Их ставит заказчик, когда блокирует оплату (lockFunds), и оба записываются в сделку: срок сдачи (deliverBy) — момент, до которого исполнитель должен записать сдачу (commitResult); сдача, записанная позже, отклоняется;; окно спора (disputeWindow) — сколько времени у заказчика после сдачи, чтобы принять работу или отменить заказ; прошло молча — исполнитель закрывает сделку (claimTimeout), как и раньше.
• Пределы в коде: срок сдачи — не дальше 90 дней от блокировки, окно спора — не длиннее 14 дней, поэтому сделка никогда не держит деньги дольше 104 дней. Предел меняется только новой версией контрактов (запись 1).
• Пропущенный срок возвращает деньги. Если срок сдачи прошёл, а сдачи нет, заказчик забирает всю сетевую часть (claimRefund): сделка переходит в REFUNDED, комиссия не берётся, чек не пишется. До сдачи исполнитель может в любой момент отказаться от задачи (declineTask) с тем же итогом.
• Два типа сделки на одних состояниях. LOCKED → COMMITTED → COMPLETED, REFUNDED или CANCELLED остаются прежними; типы различаются только сроками: мгновенная сделка — результат — данные, которые передаются при сдаче и которые проверяет сам агент заказчика: ответ, файл, цифровой продукт; оба срока — минуты;; отложенная сделка — работа делается в мире или к назначенной дате, и проверяет её человек через своего агента: стрижка, доставка, ремонт, урок; срок сдачи — согласованное время с запасом, окно спора — часы или дни. Тип контракт не хранит — он видит два числа. Тип — слово для людей и метка в объявлении.
• Исполнитель объявляет условия заранее. Объявление несёт тип услуги и её окно спора (документ 17, метка deal); объявление без метки предлагает мгновенные сделки. Оба срока сделки исполнитель видит до начала работы и отказывается от сделки, на сроки которой не соглашался.
• Отмена до начала работы нового не требует: заказчик просит, исполнитель отказывается от задачи — сетевая часть возвращается целиком. Если исполнитель не согласен, заказчик может отменить заказ после сдачи, в окне спора, и получит назад не больше веса своих лайков (запись 42).
• Долгая работа — серия отложенных сделок, по одной на период — неделю или месяц. Агент заказчика блокирует оплату периода до его начала, а исполнитель не начинает период, который не оплачен в эскроу. Каждый период — обычная сделка со своим чеком и отзывами, и любая сторона может остановиться после любого периода. Контракты о серии не знают; сделки серии связывают между собой агенты обеих сторон на своих узлах.
• Комиссия идёт в котёл периода, в котором сделка закрылась, как бы давно её ни заблокировали (документ 09).
• Документ 27 описывает всю жизнь сделки в одном месте; механика остаётся в документе 04.

Почему.

• Одна постоянная не может служить и ответу модели, и стрижке: через пять минут после стрижки заказчик едва встал с кресла, а окно в несколько дней держало бы исполнителя мгновенных ответов без оплаты днями. Сроки в сделке дают каждой услуге то время, которое ей действительно нужно.
• Без срока сдачи в сделке заказчик, чей исполнитель так и не сдал работу, не мог вернуть деньги: сделка могла остаться открытой навсегда. Срок закрывает каждую сделку — сдачей и окном спора или возвратом.
• Два типа на одних состояниях оставляют контракт маленьким: аудиторы проверяют одну машину, и между этапами нечему сломаться. Процедура из многих этапов — вехи внутри одной сделки — сделала бы эскроу судьёй этапов, а сеть им быть отказывается (запись 24).
• Серия ставит под риск один период с каждой стороны, а не три месяца; каждый период пишет свой чек, и репутация растёт вместе с работой, а не в её конце. Это оплата по завершении долгой работы без блокировки денег на месяцы.
• Пределы не дают деньгам застрять по ошибке: срок, поставленный на годы вперёд, заморозил бы оплату заказчика на годы.
• Цена, которую мы не скрываем. Исполнитель, который взял заказ и не пришёл, теряет только эту сделку: деньги возвращаются, а в его репутации ничего не видно. Учёт сорванных заказов потребовал бы шага, в котором исполнитель подтверждает заказ, — без него любой мог бы испортить репутацию исполнителя, блокируя сделки, которых тот не видел; этот шаг — открытый вопрос. Серия из тринадцати недельных сделок считается тринадцатью заказами во «всех заказах», хотя суммы точны. Отложенная сделка держит деньги заказчика заблокированными дни и недели, а исполнитель по-прежнему работает до того, как получит оплату.

Документы: 27 (новый), 00, 04, 07, 12, 13, 17, 21, 22, README; README lagrix-contracts и lagrix-node; lagrix.dev.

54. «Сорванных заказов» нет; подтверждение заказа остаётся между агентами

Согласовано 18 октября. Отвечает на открытый вопрос записи 53 о подтверждении заказа и сорванных заказах. Пересмотрена записью 55: отменённый заказ даёт заказчику отзыв, которым он отвечает на ложную сдачу.

Было. Запись 53 оставила открытым, подтверждает ли исполнитель отложенный заказ до его даты и показываются ли подтверждённые и не сданные им заказы в его репутации как «сорванные заказы».

Стало.

• Показателя «сорванные заказы» в репутации нет. Сделка, которая закончилась отказом исполнителя или пропущенным сроком сдачи, возвращает заказчику всю сетевую часть (запись 53) и не оставляет отметки ни одной стороне.
• Подтверждение заказа — договорённость агентов, а не правило сети. Агент исполнителя может подтвердить отложенный заказ агенту заказчика — например, подписью заказа и его даты вне блокчейна, как подписью приёмки (документ 04, раздел 4.2), — чтобы заказчик знал, что время за ним держат. Контракты его не читают, и оно не меняет ни сделку, ни чью-либо репутацию.

Почему.

• У исполнителя, который не пришёл, два пути. Если он пропустит срок сдачи, заказчик заберёт всю оплату. Если он запишет ложную сдачу, заказчик сможет только отменить заказ в окне спора и получит назад не больше веса своих лайков; остальное уйдёт исполнителю. Стрижка за $40 и заказчик с лайками на $3: ложная сдача приносит исполнителю около $37, честный пропуск — ничего.
• Поэтому «сорванный заказ» получил бы только исполнитель, признавший неудачу, а тот, кто соврал, не получил бы его никогда. Такой показатель учил бы исполнителей врать, а репутация существует, чтобы быть честной (запись 20).
• Исполнитель, записывающий ложные сдачи, и так оставляет след: отменённые заказы в роли исполнителя (записи 42 и 43).
• Цена, которую мы не скрываем. Пока у заказчика мало лайков, ложная сдача остаётся выгодной нечестному исполнителю: заказчика защищает только вес его лайков. Может ли заказчик ответить на отменённый заказ отзывом — открытый вопрос (запись 42).

Документы: 27; lagrix.dev.

55. Отменённый заказ: комиссия с части исполнителя, отзывы обеих сторон, без чека

Согласовано 18 октября. Отвечает на открытый вопрос записи 42 об отменённом заказе; дополняет запись 54.

Было. Заказчик, отменивший заказ в окне спора, получал назад не больше веса своих лайков, а исполнитель — остаток (записи 42 и 46). Берётся ли комиссия с части исполнителя и оставляет ли отменённый заказ чек и отзывы, решено не было. Заказчик, обманутый ложной сдачей (запись 54), мог отменить заказ, но ответить отзывом ему было нечем.

Стало.

• Комиссия берётся с части, которую получает исполнитель, — по той же ставке, что с любой сделки, не выше 5 % — и делится как обычно: в котёл периода, в котором заказ отменён, за вычетом доли разработчика, если исполнитель работает элементом, полученным по F2F (записи 25 и 51).
• Обе стороны могут оставить отзыв по отменённому заказу: заказчик — исполнителю, исполнитель — заказчику, по одному лайку или дизлайку, как после закрытой сделки (запись 26). Каждый отзыв весит столько, сколько комиссии уплачено по этому заказу. Отменённый заказ с комиссией входит в вес, от которого считаются негативные оценки, и в «без отзыва», пока его сторона не оставит отзыв (записи 43 и 46).
• Возврат всей сетевой части не берёт комиссии и не даёт отзыва: исполнителю ничего не заплачено, поэтому взвешивать нечего.
• Отменённый заказ не пишет чека. Он не считается оплаченной работой ни для выдачи, ни для места супер-узла и не добавляется к числу закрытых сделок; он виден во «всех заказах» и в «отменённых заказах», как и раньше (запись 44).
• Пример: стрижка за $40 и заказчик с лайками на $3. Заказчик получает назад $3; с оставшихся $37 комиссия $1,85, исполнитель получает $35,15; отзыв каждой стороны весит $1,85.

Почему.

• Заказчик, обманутый ложной сдачей, получает голос с настоящим весом, и следующий заказчик его видит. Отзыв не возвращает деньги — он предупреждает других.
• Честный исполнитель остаётся защищён: чтобы поставить ему дизлайк весом $1,85, придирчивый заказчик сначала платит ему $37 и теряет $3 своих лайков. Вес по-прежнему нельзя получить дешевле, чем он весит, а навредить чужой репутации по-прежнему дороже, чем сам вред (документ 17, раздел 17.5).
• Вес отзыву даёт комиссия: без неё отзыв по отменённому заказу не весил бы ничего.
• Чек позволил бы ложной сдаче поднимать нечестного исполнителя в выдаче — он получал бы и деньги, и место. Выдача следует работе, которую оплатили и приняли.
• Цена, которую мы не скрываем. Отменённый заказ теперь стоит исполнителю комиссии с его части. А отзыв весит только комиссию с того, что осталось исполнителю, поэтому заказчик с большим весом лайков, получивший назад почти всё, оставляет лёгкий отзыв.

Документы: 04, 07, 09, 17, 26, 27, README; README lagrix-contracts; lagrix.dev.

Снятые противоречия

• Срок сдачи и окно спора (документ 04, словарь README, lagrix.dev). Слова «окно приёмки» называли два разных срока: в документе 04 — срок, в который исполнитель должен сдать работу (не сдал — деньги возвращаются заказчику), в словаре — время, за которое заказчик должен ответить после сдачи (не ответил — деньги уходят исполнителю). Теперь первое — «срок сдачи», второе — «окно спора», а «приёмка» остаётся действием заказчика.
• Простой не наказывается (документ 06). Документ 16 описывал простой как ведущий к slashValidator() и «Jail»; теперь он следует 06.
• Сеть не зависит от нашего домена. paymaster.lagrix.dev (документы 12, 13) и get.lagrix.dev (документ 15) убраны: paymaster — это адрес контракта, а инструменты оператора берутся из релизов репозитория.
• Поиск идёт через Nostr и индекс супер-узла (документ 17). Документы 12 и 13 описывали отдельный реестр услуг в Kademlia; теперь они следуют 17. SDK запоминает найденного исполнителя и не ищет заново на каждую задачу.
• Освободившееся место открывается на условиях дня, когда оно открылось (записи 15, 16). Документы 05 и 06 говорили, что место открывается на условиях, на которых его заняли; теперь они следуют этому журналу.
• Агента находят по объявлению, а не в DHT (документы 01, 02, 03, 14; 18 октября). Эти документы описывали, как агенты хранят адрес и ключ шифрования в Kademlia DHT, а клиенты ищут их там. Адрес, карточка и ключ агента идут в его подписанном объявлении (документ 17, раздел 17.1); DHT — таблица маршрутов супер-узлов (документ 18, раздел 18.1), а агенты за роутером обмениваются публичными адресами при встрече через супер-узел (документ 02).
• Награды периода за пересылку нет (документ 02; 18 октября). Фраза, оставшаяся с времён до записи 42, платила супер-узлу «долю награды каждого периода»; такой награды нет. Супер-узел получает долю котла комиссий и плату за поиск и доставку; доставленное сообщение H2H стоит $0,001 (запись 33).
• Доступность измеряют агенты по очереди (документы 06, 14, 16; 18 октября). Доступность измеряли соседние супер-узлы через PING; конкуренты друг друга не судят (документ 05, раздел 5.6), поэтому доступность измеряют проверки агентов, взятых по очереди (запись 30), а PING таблицы Kademlia лишь поддерживает таблицы маршрутов.
• Один кошелёк на узел (документы 03, 08; 18 октября). Эти документы говорили о собственном кошельке или смарт-аккаунте каждого агента и о NodeID, «заявленном в контракте эскроу»; у узла один кошелёк на все элементы и агентов (записи 22 и 39), агенты получают сессионные ключи его смарт-аккаунта, а сделка эскроу записывает кошельки двух сторон (документ 04).
• Отменённые заказы в SDK (документ 12; 18 октября). SDK не знал состояния CANCELLED, а его отмена возвращала REFUNDED. Отмена заказчиком в окне спора заканчивается CANCELLED с возвратом не больше веса его лайков; REFUNDED — задача, от которой отказались или которую не сдали (документ 04).
• Envoy — эталонная реализация (документы 01, 03, 12; 18 октября). Envoy описывался как обязательный спутник каждого агента; узлом является любая программа, дающая шифрованный канал документа 19.
• Газ супер-узла (документ 16; 18 октября). Сигнал говорил о газе «для обслуживания UserOps» бандлера; супер-узел платит газ только за свои транзакции (запись 38).
• Получатель H2H не в сети (документ 21; 18 октября). Среди ограничений документа 21 стояло «обе стороны должны быть в сети»; супер-узел держит зашифрованное сообщение для получателя не в сети за $0,001 (запись 33, шаг 4 того же документа).
• Перечень контрактов (документ 07; 18 октября). Не было OfficialMarks.sol (запись 49) и ваучеров доставки в SearchVouchers.sol (запись 33).
• Кто называет разработчика (запись 51, документы 04, 07, 26; 18 октября). Запись 51 говорила, что узел исполнителя называет разработчика «при создании сделки», но сделку создаёт заказчик; исполнитель называет его, когда записывает результат (commitResult), а сделка и её чек несут поле developer. Цена записи 51 названа целиком: контракты не отличают элемент, полученный по F2F, от собственного элемента узла, поэтому узел, который называет разработчиком свой же кошелёк, оставляет себе пятую часть комиссии (документы 05, 09, 17, 22, 26, README).
• Мелкие формулировки (документы 00, 07, 17, 18, 20; 18 октября): комиссия описана вместе с долей разработчика; «учётные данные доступа» и «переводы USDC» заменили слово «токены»; при перегрузке открываются два места, после чего уходит худший супер-узел (запись 40).
• Ваучер, а не расписка; чек, а не квитанция (записи 5 и 19, документ 07; 18 октября). В русском тексте «voucher» был переведён как «расписка», а «receipt» в документе 07 — как «квитанция»; слова словаря — «ваучер» и «чек».
• Деление комиссии — одно чтение (README, документы 00, 05, 09, 22, 27; README lagrix-supernode; lagrix.dev; 18 октября). Одни фразы отправляли всю комиссию супер-узлам без доли разработчика, другие называли долю только как «20 % комиссии», а несколько говорили, что единица веса отзыва всегда стоит доллар. Запись 51 не меняется; каждое место, где сказано, куда идёт комиссия сделки, теперь называет оба случая в долях сделки: при комиссии 5 % элемент, полученный по F2F, даёт 1 % сделки его разработчику и 4 % в котёл, свой элемент исполнителя — все 5 % в котёл; исключение записи 51 (80 центов) названо везде, где сказано, что вес стоит доллар. За что платят супер-узлу — котёл, перераспределение долей не прошедших минимум, поиск, доставка, плата за выборку о метке «Официальный» и награда за доказанное нарушение — перечислено один раз, в документе 05, раздел 5.7.

Открытые вопросы

В этом пересмотре они не решены и помечены там, где встречаются. Вход супер-узлов после первых 100 и проверка живого агента, открытые в первой части пересмотра, решены записями 15 и 16.

• Как измеряется «прошёл или не прошёл». Запись 30 говорит, что агенты, взятые по очереди, проверяют каждый супер-узел по минимуму качества; что именно они измеряют, как ведётся очередь и как сводятся их результаты, не решено. То же — для перегрузки сети и для проверок под нагрузкой, по которым решается, какой супер-узел уходит (запись 40), и для предупреждения о нехватке мощности: кто его отправляет, что значит «не хватает» и какой срок (запись 45), и для проверки индекса (запись 48).
• Поле superNode в сделке. Заказчик сам называет супер-узел, который получает чек сделки (документ 04); пока ничто не связывает его с узлом, который на деле обслужил сделку.
• Плата за пересылку трафика. Прежние документы расходились — в USDC за мегабайт или никакой. Для сообщений H2H решено записями 33 и 52 ($0,001 за доставленное сообщение до 64 КБ; вложения остаются у отправителя); для остального трафика пересылка пока описывается без цены.
• Интервал очереди в выдаче (запись 30): его длину задаёт моделирование.
• Как контракт дёшево находит медиану (запись 31): пересчёт по всем узлам при каждом открытом месте дорог; способ не выбран.
• Сговор при раскрытии (запись 31): последний раскрывающий может не раскрыть секрет и тем сменить результат — себе он этим не поможет, но может помочь сообщнику. Чем это наказывается, не решено.
• Имена тегов слоя 1 и формат подписанного списка ограничений (запись 32): выбираются при реализации.
• Держатели вида и жизнь объявления (запись 48): константа k, сколько объявление может идти до остальных держателей, прежде чем его отсутствие засчитывается индексу, насколько вперёд можно ставить срок, как вычисляется ключ вида и что происходит с видом, который не помещается на один сервер, задают моделирование и реализация.
• Пороги перегрузки (запись 47): константы сделок, выкупленных поисков и доставленных сообщений на один супер-узел, сверх которых открываются новые места, задаёт моделирование.
• Награда доказавшему нарушение (запись 42): её размер в USDC из комиссии задаёт моделирование.
• Хватает ли комиссии на серверы супер-узлов, пока сеть мала (запись 42): проверяет моделирование.
• Метка «Официальный» (запись 49): сколько длятся окна обязательства и раскрытия, как часто метку можно оспаривать, заменяется ли член выборки, который не проголосовал, и может ли владелец перенести метку на свой новый кошелёк без оспаривания.
• Страница отзыва (запись 50): наибольшую длину адреса выбирают при реализации.
• Доля разработчика (запись 51): зависит ли доля от репутации агента-заказчика; как принимающий проект проверяет, что ставит тот код, который описан в карточке; кто разработчик элемента, изменённого после установки.
• Ваучер с нарастающей суммой (запись 52): длину периода погашения и задержки вывода задаёт моделирование.
• Тариф первого контакта (запись 52): может ли тариф зависеть от того, кто пишет; может ли получатель вернуть тариф.
• Серия в репутации (запись 53): показываются ли сделки одной серии одной строкой, не решено.