Перевод Журнал встречи исследовательской лаборатории Monero от 2019-12-16

Тема в разделе "Журналы о Monero", создана пользователем Unholy, 20 дек 2019.

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    138
    Симпатии:
    12
    Когда: Понедельник, 16 декабря 2019 г., 17:00 UTC
    Где: #monero-research-lab (freenode/matrix)

    Повестка дня:
    1. Приветствия
    2. Круглый стол
    3. Вопросы
    4. Ключевые моменты
    <sarang> ПРИВЕТСТВИЯ
    <suraeNoether> привет!
    <suraeNoether> предполагаю, что мы можем сразу перейти к круглому столу?
    <sarang> почему бы и нет
    <sarang> кто хочет начать?
    <suraeNoether> пропингую isthmus
    <suraeNoether> надеюсь, что он сможет поделиться своей работой
    <Isthmus> n3ptune и я занимаемся анализом награды за блок
    <Isthmus> и есть много забавных моментов
    <sarang> каких?
    Isthmus копается в цифрах
    <Isthmus>
    вот кое-что из наших графиков моделирования
    <Isthmus> https://usercontent.irccloud-cdn.com/file/f9F4XDd3/image.png
    <Isthmus> ось x - это высота блока
    <Isthmus> ось y – награда, которую получают майнеры
    <Isthmus> (награда + сборы)
    <Isthmus> тренд — это наша текущая хвостовая эмиссия
    <Isthmus> точки данных выше тренда - это майнеры, которым посчастливилось найти блоки с очень большой наградой
    <suraeNoether> экспоненциальная форма распада на графике строиться на нашей эмиссии (сборы связаны с вознаграждением за блок). Разрыв на графике, это нужно полагать, момент внедрения bulletproofs?
    <Isthmus> аномалии ниже линии, вот что на самом деле интересно
    <Isthmus> с этим связано несколько событий, которые случались ранее
    <Isthmus> для каждого из них мы можем вынести несколько предположений:
    <Isthmus> какие именно блоки были найдены конкретно майнерами / пулом / ПО
    <Isthmus> (связываемость)
    <Isthmus> и сколько времени им потребовалось, чтобы заметить, что они создают *неоптимальные* блоки для сети, и исправить это?
    <Isthmus> график получится немного нагляднее, если все раскрасить в соответствующие цвета
    <Isthmus> https://usercontent.irccloud-cdn.com/file/HUoctx7I/image.png
    <Isthmus> от синего к желтому
    <Isthmus> это удивляет
    <Isthmus> если взглянуть на полосу с 1225000 по 1275000
    <Isthmus> блоки, в которых находится * меньшее* вознаграждение, чем в пустых блоках, имеют примерно тот же размер, что и другие
    <suraeNoether> братан, этот график великолепен!
    <Isthmus> спасибо :- )
    <sarang> весьма странное поведение
    <sarang> если выделить субоптимальное значение, вы могли бы сказать...
    <Isthmus> да, их размеры примерно такие же, как и у других блоков, и у нас есть два предположения о том, почему это может происходить
    <Isthmus> возможно, что другие майнеры специально генерируют блоки с большими транзакциями, а те, кто ниже тренда, это *пиявки*, которые, в свою очередь, генерируют блоки после того, как mempool был выпущен для установки высоких сборов за транзакции
    <Isthmus> основываясь на том, как построен второй (аномальный) пример, я полагаю, что это может быть простая ошибка программного обеспечения
    <Isthmus> я обнаружил это 20 часов назад и еще не успел сделать соответствующее исследование
    <Isthmus> думаю, что я смогу докопаться до сути
    <Isthmus> (чем, собственно, я сейчас и занят)
    <sarang> да, действительно, как-то всё слишком *чётко*
    <suraeNoether> большое спасибо, isthmus; мне кажется, что я читал по крайней мере одну статью о манипуляции с вознаграждением
    <suraeNoether> постараюсь найти ее
    TheoStorm вышел (~TheoStorm@host-p8vu8h.cbn1.zeelandnet.nl): (Причина: Удаленный хост разорвал подключение)
    <suraeNoether>
    у меня так много вопросов
    <sarang> было бы неплохо узнать, какое именно программное обеспечение (если это оно) приводит к этому и насколько распространенным оно может оказаться
    <sarang> suraeNoether: чем сегодня богат ваш круглый стол?
    <suraeNoether> да, конечно, я *думаю*, что есть *одна* ошибка в полученных данных, которые я сейчас анализирую. И я веду диалог с одним человеком из Insight Data Science, чтобы побудить его к аналогичному моделированию и помочь мне выработать более точные рекомендации
    <suraeNoether> моя текущая ошибка весьма наивна — я не взял в расчет узлы и рёбра, которые ожидались моим программным обеспечением. Первоначально я думал, что это была проблема с вычислением количества доступных участников кольца или что-то подобное
    <sarang> У вас есть код, который может воспроизвести это?
    <suraeNoether> это случается в testSimulator.py, а не в любом из моих детерминированных тестов
    <suraeNoether> я все еще выискиваю причины, которые приводят к ошибке, и как только я их найду, я попытаюсь выделить ее в качестве отдельного юнит-теста
    <suraeNoether> компонент теории графов работает великолепно, компонент анализа, исследующий пространство параметров, работает отлично, но симуляция продолжает *трещать по швам*
    <endogenic> оууу, я здесь
    <suraeNoether> добро пожаловать
    <endogenic> suraeNoether: Вы не думаете, что V мог сделать все эти маски сам, даже через 20 лет?
    <sarang> suraeNoether: текущий код является рабочей версией?
    <suraeNoether> да, включая коммит, который я спушил утром
    <suraeNoether> ветка buttercup
    <suraeNoether> еще кто-то поднял вопрос о том, что я должен повторно реализовать симуляции в Rust в надежде, что ссылки в новой редакции Rust помогут найти ошибки
    <sarang> Вы подозреваете, что это может быть причиной ошибок?
    <suraeNoether> я думаю, что рефакторинг всей кодовой базы — самое последнее усилие по поиску ошибок
    <sarang> Если это просто алгоритмические ошибки, переход на Rust ничего не даст
    <suraeNoether> нет, я думаю, что простое предсказывание количества узлов и ребер неправильно, особенно если оно основывается на общем наборе узлов
    <endogenic> вы пробовали читать записи в журнале?
    <endogenic> секретное оружие
    <suraeNoether> да, конечно, это первое, что я проверил
    <Isthmus> Не могли бы вы настроить симуляцию длиной в 3 блока или 2 транзакции на блок с шаблоном траты и алгоритмом выбора участника кольца из предыдущего блока
    <Isthmus> будет ли эта проблема сохраняться, и как легко можно будет заметить ее?
    <sarang> endogenic: ваше предложение напомнило мне – https://xkcd.com/451/ :p
    Dean_Guss вышел (~dean@gateway/tor-sasl/deanguss): (Причина: Удаленный хост разорвал подключение)
    <endogenic>
    действительно
    <endogenic> :p
    <sarang> Что-то точно должно быть в логах!
    <sarang> Извините
    <suraeNoether> я считаю, что проблема может быть в алгоритме выбора кольца
    <suraeNoether> но я пытаюсь найти что-то еще
    <suraeNoether> или поработать через отладку
    <suraeNoether> sarang, как насчет тебя?
    <endogenic> операторы журнала хороши тем, что вы можете отслеживать записи во время работы кода
    <sarang> Да, у меня есть несколько моментов, чтобы сказать
    <endogenic> отладка… как сладко звучит это слово
    <sarang> Я изменил определения связываемости и неразличимости в Triptych и хотел бы посмотреть, можно ли их напрямую использовать их в CLSAG
    <sarang> также я сделал вариацию с определением связываемости Backes
    <sarang> и еще я обновил определение связываемости CLSAG, а также его доказательство
    <sarang> сделал обзор документа от Zcoin об иерархических доказательствах обязательствах Groth
    <sarang> в ходе чтения документа я нашел несколько изменении, которые Zcoin сделали, чтобы исправить проблему, связанную с доказательствами Groth (не относится к Triptych)
    <sarang> в дополнение разработан пример кода для выполнения инверсии через MPC при вычислении определенных конструкций тегов
    <sarang> и выписал несколько простых идей MPC для RCT3 и Triptych
    <suraeNoether> здорово!
    <sarang> Хорошей новостью для MPC является то, что возможно совместное реверсивное вычисление образов ключей, используемых в проверочных системах
    <sarang> плохая новость заключается в том, что для этого требуется шифрование по типу Paillier, что приведёт к потерям в вычислительных мощностях
    <suraeNoether> хммм... Вы планируете использовать MPC для связывания конструкций тегов из-за его возможности связывания тегов в Triptych?
    <sarang> (прошу обратить внимание, что мой пример кода *не должен* рассматриваться как безопасная и практичная реализация Paillier)
    <sarang> Да, MPC должен обрабатывать теги в Triptych, RCT3 и Omniring
    <sarang> Несмотря на то, что Omniring может использовать теги, эта конструкция все еще требует базовой инверсии
    <sarang> есть также соответствующие аффинные величины для вычисления
    <suraeNoether> освежите мою память - какие, если они вообще имеются здесь, требуют самостоятельной отправки?
    <sarang> Ни один из этих вариантов
    <sarang> DLSAG и Lelantus, да
    <endogenic> LELANTUS
    <suraeNoether> хорошо, значит, что где-то в глубине души вы всё еще надеетесь на возможность связывания тегов?
    <sarang> проблема заключалась в том, что было неясно, как реализовать поддержку multisig , когда теги связывания требуют инверсии секретного ключа
    silur подключился (silur@gateway/vpn/nordvpn/silur)
    <suraeNoether>
    аааааар
    <sarang> теперь, когда есть MPC для вычисления всего этого, это означает, что поддержка multisig вполне реальна
    <suraeNoether> понял-понял
    <suraeNoether> у вас был какой-то вопрос ко мне в ключе multisig
    <sarang> недостатком MPC является то, что Paillier не может воспользоваться библиотеками, на которых реализована наша кривая
    <suraeNoether> мы можем поговорить об этом после встречи
    <silur> простите за опоздание
    <Isthmus> привет
    <suraeNoether> давно не виделись, silur
    <endogenic> как дела, silur?
    <sarang> Paillier требуется модуль RSA
    <sarang> шифрование и, следовательно, дешифрование требуют отдельного возведения в степень с переменным модулем
    <sarang> таким образом, устройства с ограниченными характеристиками должны иметь возможность поддерживать его для полноценной работы
    <suraeNoether> поэтому мы и надеемся, что MPC будет высчитывать образы ключей на основе инверсии... чтобы MPC больше соответствовал *истории разработки* monero / cryptonote? То есть на основе надстройки DL в Ed25519, вместо RSA?
    <suraeNoether> или по крайней мере одному из этих пунктов
    <sarang> было бы замечательно... Но, как вы указали, получение требуемой гомоморфности означало бы несоответствие DL
    <silur> Можете ли вы уточнить, что подразумевает «образ ключа на основе инверсии»?
    <silur> или это уже фигурировало немногим ранее?
    <sarang> образ ключа / теги в новых системах проверки используют форму `(1/x)*U`
    <suraeNoether> а не проверенную временем x*H(X)
    <suraeNoether> U ведь уже исправлена, да?
    <sarang> деление является обратным, `x` является секретным ключом, а `U` фиксировано либо зависит от самого доказательства
    <sarang> если я не ошибся
    <suraeNoether> хммм... минутку
    <sarang> оно фиксировано в более поздних версиях систем доказательства
    <suraeNoether> мой комментарий был взаимосвязан с эффективным групповым скалярным отображением, в котором была реализована хоть какая-то гомоморфность
    <suraeNoether> оу оу оу
    <suraeNoether> теперь понял
    <sarang> вот: https://github.com/SarangNoether/skunkworks/tree/inverse-mpc
    <sarang> inverse.py показывает, как работает этот процесс, и документ markdown описывает одно из возможных использований в ключе RCT3 / Triptych
    <sarang> Гомоморфность шифрования важна для MPC
    <suraeNoether> поэтому, как правило, у каждого человека есть секретный x_i, и есть функция f, позволяющая вычислить f(x_1, ..., x_n)*U. А вы использовали f(x_1, ..., x_n) = 1/sum(x_i)?
    <suraeNoether> знаете что? давайте поговорим об этом после встречи
    <sarang> Да, поддерживаю
    <suraeNoether> Итак, isthmus, я и sarang закончили со своими исследованиями. Кто-нибудь еще хочет поговорить о каких-либо исследованиях, связанных с Monero?
    <silur> разве мы не можем использовать внутреннее шифрование?
    <silur> если отдельные выходы бесполезны
    <silur> и на последнем шаге сводить произведение для последнего вектора к Z_p?
    DeanGuss подключился (~dean@gateway/tor-sasl/deanguss)
    <sarang>
    я не знаю, как именно применить это к Gennaro
    <sarang> я подразумеваю мультипликативный метод для аддитивной доли
    <sarang> (что является одной из точек их протокола на основе Paillier)
    <silur> Ааа… Метод Genaroo-Goldfeder является обязательным требованием
    <silur> тогда всё понятно :)
    <silur> я не знал, что это обязательно
    <sarang> нам не нужно использовать Gennaro-Goldfeder
    <sarang> это кажется весьма эффективным, если вы можете согласиться с требованиями гомоморфности
    <sarang> В интересах экономии времени давайте перейдем к КЛЮЧЕВЫМ МОМЕНТАМ
    <sarang> Мои задачи: продолжить работу над MPC, перенести определения CLSAG(также хотелось бы всё это обсудить с suraeNoether) и получить обзор моего черновика Triptych перед публикацией на IACR.
    <silur> triptych? o_O
    <sarang> ?
    <suraeNoether> моя задача: выследить и устранить мою последнюю ошибку, закончить работу над отчетом о вспенивании, прочитать черновой вариант triptych (наконец-то!) и продолжить переписку с isthmus о том, как заставить его коллегу поработать со мной над сопоставлением / вспениванием
    <silur> Отлично, я тоже гляну черновик
    <suraeNoether> Это документ, над которым сейчас работает sarang
    <silur> я пропустил слишком много встреч :D
    <sarang> silur: Triptych это связываемая кольцевая подпись, основанная на доказательствах Groth
    <silur> <3
    <sarang> черновик почти закончен
    <sarang> своего рода *суперэффективная* версия, для которой я не могу понизить значения эффективности до известного предположения о прочности конструкции
    <sarang> так что если вы хотите взглянуть на всё это, silur, добро пожаловать!
    <silur> да, конечно!
    <sarang> здоровски!
    <sarang> Хорошо, я полагаю, мы можем закрыть официальную часть встречи и продолжить дальнейшее обсуждения по желанию

    Источник: Research meeting: 16 December 2019 @ 17:00 UTC

    Перевод:
    Unholy (@Unholy)
    Редактирование:
    Mr. Pickles (@v1docq47)
    Коррекция:
    Kukima (@Kukima)
     
  • О нас

    Наш сайт является одним из уникальных мест, где русскоязычное сообщество Monero может свободно общаться на темы, связанные с этой криптовалютой. Мы стараемся публиковать полезные мануалы и статьи (как собственные, так и переводы с английского) о криптовалюте Monero. Если вы хорошо владеете английским (или можете писать собственные статьи/мануалы) и хотите помочь в переводах и общем развитии Monero для русскоязычной аудитории - свяжитесь с одним из администраторов.