Перевод Журнал встречи исследовательской лаборатории Monero от 2020-02-19

Тема в разделе "Журналы о Monero", создана пользователем Unholy, 22 фев 2020.

  1. Unholy

    Unholy Well-Known Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    180
    Симпатии:
    13
    Когда: Среда, 19 февраля 2020 г., 18:00 UTC
    Где: #monero-research-lab (freenode/matrix)

    Повестка дня:
    1. Приветствия
    2. Круглый стол
    3. Вопросы
    4. Ключевые моменты
    Журнал встречи:

    <sarang> Хорошо, давайте начнем нашу встречу
    <sarang> ПРИВЕТСВИЯ
    <sgp_> привет :)
    <n3ptune> Привет
    needmonero90 запускает волну из рук
    <needmonero90>
    Да-да, я сегодня на встрече!
    <needmonero90> Хотелось бы отметить, что ваши собрания не указаны в календаре
    <needmonero90> нужно полагать, что это не преднамеренно
    <sarang> В каком календаре?
    <UkoeHB_> Hi
    <sarang> и каким местом к нему относятся наши встречи?
    <ArticMine> Hi
    <sarang> Время / повестка дня собрания всегда указываются в разделе проблем на github
    <sarang> в любом случае кто-нибудь хочет начать наш КРУГЛЫЙ СТОЛ?
    <UkoeHB_> Да
    <sarang> Вперёд, UkoeHB_
    <UkoeHB_> Я закончил разработку «протокола для децентрализованной торговой площадки», мы надеемся, что это сможет решить проблемы, с которыми столкнулся rbrunner в своем анализе интеграции openbazaar. В дополнение мы добавили поддержку multisig и txtangle
    <UkoeHB_> https://www.pdf-archive.com/2020/02/19/zerotomoneromaster-v1-0-28/zerotomoneromaster-v1-0-28.pdf
    <sarang> Отлично
    <UkoeHB_> еще у меня появилась идея уменьшить минимальные колебания комиссии и включить антиспам непосредственно в протокол вместо того, чтобы полагаться на увеличение комиссии
    <sarang> у вас уже есть анализ данного решения?
    <UkoeHB_> он описан в проблеме #70
    <UkoeHB_> и ждёт ваших комментариев
    <UkoeHB_> о! Сананг, я представил черновик для обновленной главы о доказательствах в транзакциях
    <sarang> Великолепно
    <UkoeHB_> (но это не исследования :p)
    <sarang> это, скорее, краткое изложение того, что находится в кодовой базе (+ некоторые изменения)
    <sarang> с нетерпением жду возможности прочитать эти обновления, на которые вы ссылаетесь
    <UkoeHB_> ряд тем всё еще нуждается в обзоре: https://github.com/monero-project/research-lab/issues
    <UkoeHB_> я всё
    <sarang> Спасибо, UkoeHB_
    <sarang> Ваши вопросы или комментарии?
    <ArticMine> Да
    <sarang> Пожалуйста, продолжай!
    <ArticMine> Я рассмотрел вопрос #70
    <ArticMine> и это на самом деле имеет серьезные последствия
    <ArticMine> когда LT среда существенно увеличивается
    <ArticMine> и у меня есть идея для ее решения
    <ArticMine> пока все ещё предварительная на данном этапе
    <ArticMine> что касается исправления
    <ArticMine> самое главное — это установка высоких или хотя бы средних комиссий за условное депонирование, которое, как ожидается, добавиться в следующем обновлении
    <ArticMine> у меня будут дополнительные комментарии по этому вопросу в ближайшие две недели
    <ArticMine> всё
    <sarang> спасибо, ArticMine
    <sarang> Есть еще вопросы / комментарии по темам, представленным UkoeHB_?
    <sarang> хорошо
    <sarang> тогда я поделюсь несколькими своими исследованиями
    <sarang> во-первых, прямо сейчас (и в ближайшие несколько дней) проходит Стэнфордская блокчейн-конференция: https://cbr.stanford.edu/sbc20/
    <sarang> во-вторых, я закончил некоторые математические / кодовые тесты, связанные с многопартийностью, для протоколов следующего поколения
    <sarang> в-третьих, я работал над кодом и записями для подтверждения транзакций как для обновленного PR, так и для включения обновлений в Zero to Monero
    <sarang> в-четвертых, я использовал новые данные от n3ptune и его друзей, чтобы лучше оценить кумулятивный эффект протоколов следующего поколения
    <sarang> как рост всей цепочки, так и времени проверки
    <sarang> главное предостережение: они предполагают то же распределение входов / выходов, что и текущая версия
    <sarang> и применимо только к данным из цепочки bulletproof
    <sarang> https://usercontent.irccloud-cdn.com/file/ijaEAI7m/size.png
    <sarang> ^ эта ссылка показывает оценки общего роста цепочек для различных протоколов с различным размером кольца
    <sarang> а именно от 16 до 1024 в степени 2 (только для возможности визуальной оценки)
    <UkoeHB_> Для справки - не хотите ли вы добавить соответствующие точки для MLSAG и CLSAG с размером кольца 11?
    <sarang> Конечно, мне нужно взять эти данные из моей таблицы
    <sarang> подождите, пожалуйста
    <UkoeHB_> какой пологий склон от 11 к 20 lol, прямо выбивается из всего графика
    <sarang> хех, у меня есть эти данные, но я их не включал, потому что они очень линейны
    <sarang> я использую N = 11 для MLSAG / CLSAG
    <sarang> во всяком случае, я еще переделаю данные о времени
    <sarang> https://usercontent.irccloud-cdn.com/file/T7uWoFEp/time.png
    <sarang> ^ оценка времени проверки для _различных_групп_операторов_ при разных размерах кольца
    <UkoeHB_> что интересно, все эти протоколы / схемы подписи имеют одинаковый размер
    <sarang> всё время проверки линейно (вплоть до логарифмического члена)
    <UkoeHB_> а где там прячутся данные tryptich?
    <sarang> под Triptych-single
    <sarang> они, по сути, неразличимы
    <selsta> есть ли у Triptych-single преимущества перед Triptych-multi?
    <sarang> RCT3-multi страдает из-за требований заполнения входов, которые имеют эффект линейной проверки
    <sarang> selsta: полное доказательство надежности :)
    <sarang> обновление оценок размера MLSAG / CLSAG...
    <UkoeHB_> Не могли бы вы сделать отдельный маленький график с данными от 0 до 128? Поскольку этот кажется довольно громоздким
    <sarang> при N=11 MLSAG для этого диапазона примерный размер составит порядка 7,84 ГБ, а CLSAG - 5,84 ГБ.
    <sarang> (фактический размер этой цепочки составляет 7,9 ГБ)
    <sarang> https://usercontent.irccloud-cdn.com/file/DFhClmEe/time-small.png
    <sarang> ^ данные в том же отрезке времени, только увеличенные
    <UkoeHB_> спасибо :) есть ли приблизительные оценки CLSAG / MLSAG?
    <sarang> хех, я просто отмечу, что
    <sarang> у меня есть предварительные оценки, но они не передают всей картины, так как multiexp не применяется, а хеширование тривиально
    <sarang> Оценка MLSAG при N=11 составляет 29,9 часа для всего диапазона цепочки (но я не перепроверял результаты)
    <ArticMine> Какое оборудование использовалось для расчета времени проверки?
    <sarang> одно ядро на Opteron с частотой 2,1 ГГц и с большим количеством оперативной памяти
    <sarang> я бы полагался на временные данные только для сравнения, а не как на абсолютные значения
    <ArticMine> возраст процессора?
    <sarang> Я все еще нахожусь в процессе получения данных для CLSAG, мне потребуются дополнительные тесты
    <sarang> Gen-3 Opteron, если ты это имеешь в виду
    <UkoeHB_> Есть ли какой-то способ симулировать этот тест? другие участники могли бы выполнить аналогичную проверку на своём оборудовании?
    <sarang> только оценки при использовании кода теста производительности
    <sarang> для протоколов следующего поколения это довольно просто
    <ArticMine> отлично, большое спасибо
    <sarang> Ну, это не очень просто
    <sarang> вам нужно получить данные о производительности и использовать линейную интерполяцию, которую вы подключаете к симулятору
    <sarang> для MSLAG / CLSAG вам потребуется дополнительные данные о производительности операций
    <sarang> а вот ссылка на сам симулятор: https://github.com/SarangNoether/skunkworks/blob/sublinear/estimate.py
    Isthmus прикидывается уткой и крякает в течении 30 секунд
    <Isthmus>
    https://usercontent.irccloud-cdn.com/file/HuPcfLdT/image.png
    <sarang> опять же сложно сравнивать MLSAG / CLSAG и протоколы следующего поколения
    Isthmus выключает режим утки
    <sarang>
    воу-воу
    <Isthmus> цифры это одно, но мы все должны быть встревожены тем, что анализ чего-то подобного возможен для стороннего наблюдателя
    <Isthmus> ;-)
    <sarang> Да, и это безусловно интересная тема!
    <Isthmus> Использование субадресов связано с риском для конфиденциальности...
    <Isthmus> в любом случае это просто информация для размышления, извините, я сейчас в дороге
    <sarang> ОК, Isthmus, спасибо, что поделились наблюдением
    <sarang> еще одно напоминание о том, что структура входа / выхода раскрывает некоторую информацию об использовании подадреса
    <sarang> поскольку Isthmus пришлось оставить нашу скромную встречу, есть ли у вас другие вопросы / комментарии к данным, которыми я поделился выше?
    <sarang> UkoeHB_: если вы хотите провести свою череду тестов, то отпишитесь мне после встречи, я расскажу, где взять и куда подставить нужные данные
    <UkoeHB_> Мой компьютер довольно слабый, это так, просто из любопытства :)
    <sgp_> sarang: не могли бы вы напомнить, как обстоят дела по исправлению утечки данных с подадрессов?
    <sarang> минутку
    <sarang> требование о разделении ключей в транзакциях для каждого выхода - хорошая идея, но идея не получила должной поддержки
    <sarang> данные о размерах, которые я представил для следующего поколения протоколов, предполагают использование отдельного ключа для каждого выхода
    <UkoeHB_> Это необходимо для самой концепции протоколов?
    <sarang> вы имеете в виду системы проверки? Нет
    <sarang> им все равно, как вы получаете ключи для подписи
    <UkoeHB_> Можете ли вы оценить дополнительные данные в ключе? Num Out * 32 и Num TX * 32?
    <sgp_> sarang: почему эта реализация не получила поддержки? Какие возникли сложности? Может размер? Или время проверки?
    <sarang> все мои данные для MLSAG/CLSAG уже включают раздельные ключи
    phire вышел (phire@119.252.27.69): *.net *.split
    <sarang>
    данные от n3ptune уже включают в себя публичные ключи
    <sarang> их можно использовать для более детального подсчета
    phire подключился (phire@119.252.27.69)
    <UkoeHB_>
    С учетом только 3% всех субадресов разница составляет порядка 100 МБ
    <UkoeHB_> что равно примерно 2% от общего размера
    <sarang> это, вероятно, хороший показатель
    <sarang> но потребуется дополнительная проверка
    <sarang> так что должна быть корреляция
    <UkoeHB_> думаю, что размер составит ~1 ГБ для 30 миллионов публичных ключей
    <sarang> у moneromooo должно быть лучшее представление о последствиях
    <sarang> а вообще, это отличная идея, не смотря на все её сложности
    <sarang> Хорошо, мы приближаемся к отметке в один час
    <sgp_> Очевидно, что без этого изменения последствия будут весьма негативными для общей конфиденциальности сети........
    <sarang> Это дифференцированные данные, но они не *предполагают* что выходные данные предназначены для субадресов
    <sarang> (и это не причина для сохранения текущего подхода)
    rottensox подключился (~rottensox@unaffiliated/rottensox)
    <UkoeHB_>
    я настроен немного скептически
    <sgp_> получается, что *один из этих выходов попадает на субаддрес?*
    <sarang> UkoeHB_:?
    <UkoeHB_> слишком много фиктивных данных
    <sarang> sgp_: показывает количество выходов для конкретного подадреса
    <UkoeHB_> это показывает, что как минимум один из выходов принадлежит субадресу
    <sarang> Разве это не показывает общее количество выходов?
    <UkoeHB_> Нет
    <sarang> хм
    <UkoeHB_> а в чем тогда загвоздка?
    <UkoeHB_> количество дополнительных публичных ключей всегда равно количеству выходов
    <UkoeHB_> даже если это не субадресс
    <UkoeHB_> и вообще, как продвигается работа над документом CLSAG?
    <sarang> Хм, почему-то я думал иначе
    <sarang> я все еще жду suraeNoether
    <sarang> он хотел продолжить работу над своими новыми идеями для моделей безопасности
    <sarang> так что пока никак
    <sarang> Хорошо, заключительные замечания или мысли
    <sarang> (если у вас есть дополнительные идеи, мы можем продолжить их обсуждение после завершения официальной части встречи)
    <sgp_> следует открыть соответствующий вопрос
    <sarang> Хорошо, спасибо всем за участие
    <sarang> на сегодня мы закончили!

    Источник: Research meeting: 19 February 2020 @ 18:00 UTC #439

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

    Kukima (@Kukima)
     
  • О нас

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