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

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

  1. Unholy

    Unholy Well-Known Monerano

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

    Повестка дня
    1. Приветствия
    2. Круглый стол
    3. Вопросы
    4. Ключевые моменты
    <sarang> ОК, время встречи!
    <sarang> Как обычно, мы начинаем с ПРИВЕТСТВИЯ
    <Isthmus> ПРИВЕТСТВИЯ
    <ArticMine> Hi
    <sarang> привет
    — sarang ждет других участников в течение нескольких минут
    <knaccc>
    yo
    → others подключился (43a4fffc@c-67-164-255-252.hsd1.co.comcast.net)
    <knaccc>
    очень хорошо :)
    <sarang> ох, как утонченно!
    <sgp_> привет
    <sarang> Хорошо, давайте перейдем к КРУГЛОМУ СТОЛУ
    <sarang> я начну с нескольких вещей
    <sarang> студенты-исследователи из CMU подготовили препринт по трассировке Monero и Zcash: https://eprint.iacr.org/2020/593
    → adhux0x0f0x3f подключился (~adhux0x0f@gateway/tor-sasl/adhux0x0f0x3f)
    <sarang>
    в нем рассматривались только те данные, которые были предварительно получены до активации протокола Sapling в Zcash (такие независимые проверки ранних работ очень важны)
    <sarang> но в случае с Monero был рассмотрен гораздо более новый период транзакций
    <sarang> выводы заключаются в том, что совершенствование протокола было очень полезным
    <sarang> но я полностью не согласен с их методологией, приводящей к выводу об эффективности обновленного алгоритма выбора выходов
    <sarang> я просто думаю, что у них не получилось сделать рациональные выводы
    <sarang> еще я подготовил несколько заметок и отправил их авторам препринта, дополнив моей благодарностью за их проделанную работу
    <sarang> они разместили свой аналитический код на GitHub, так что я собираюсь посмотреть, какую полезную информацию можно извлечь из этого исследования
    <sarang> в дополнение я сейчас работаю над некоторыми определениями для переноса модели безопасности Omniring в Arcturus
    <sarang> и над верификацией адресов вместе с moneromooo
    <sarang> и еще я написал тестовый код для идеи сканирования тегов
    <knaccc> на каком языке?
    <sarang> Как было предложено UkoeHB_, идея состоит в том, чтобы включить небольшой короткий хэш определения ключа для каждого выхода и использовать его в режиме «быстрого сканирования», который позволяет избежать некоторых операций с кривой
    <sarang> knaccc: временный код написан на C ++
    <sarang> это не финальная реализация, скорее, только тестовая модель для получения информации о времени
    <sarang> в предположении тег представления является одним байтом, и только 1 из каждых 256 тегов проверяет результаты на совпадение
    <sarang> на тестовом компьютере общее время сканирования без просмотра тегов для этих 256 проверок составляет 43,520 мс.
    <sarang> общее время сканирования с просмотром тегов (и одним совпадением в группе) составляет 32,559 мс
    <sarang> это означает, что в этом примере режим быстрого сканирования работает на 75% быстрее
    <knaccc> сколько транзакций в общей сложности вы сканировали?
    <sarang> Это было не настоящим сканированием; это была симуляция, которая выполняла все операции для поддельных выходных данных, сгенерированных тестовым кодом
    <knaccc> я имею в виду, каково было отношение совпадающих выходов к просканированным выходам
    <sarang> Он сопоставил тег просмотра и выходной ключ, а затем рассчитал время сканирования в различных режимах
    <sarang> предположительно 1/256
    <sarang> статистический
    <knaccc> Когда вы подразумеваете 1 из 256, учитываете ли вы стоимость дополнительного сканирования, чтобы затем перепроверить полученные результаты?
    <sarang> Да, позвольте мне объяснить
    <sarang> тест имеет 3 режима
    <sarang> режим 1. стандартное сканирование без просмотра тегов
    <sarang> режим 2. просмотр тега без совпадений (вычисление деривации и просмотр тега, а затем проверка)
    <sarang> режим 3. тег просмотра (после получения и просмотра тега следует его проверка)
    <sarang> таким образом, «отсутствие тегов просмотра» предполагает 256 операций для первого режима
    <sarang> если «да, теги просмотра присутствуют», предполагается 255 операций для всех режимов
    <ArticMine> Есть вопрос и о нестандартной математике
    <sarang> ?
    <sarang> knaccc: тестовый код всегда генерирует совпадающий тег представления и выходной ключ (для проверки работоспособности), но симуляция просто использует режимы, чтобы проверить, произошло ли совпадение или нет
    <knaccc> Ваши результаты примерно совпадают с обратной калькуляцией, но если вы экономите на скалярной базе и скалярное вычисление в переменной базе стоит 25, а скалярное вычисление с фиксированной базой стоит 15, то вы уменьшаете стоимость сканирования со 100% до 25 / (25 + 15) = 62,5%
    <ArticMine> для Arcturus
    <sarang> ArticMine: в Arcturus теги представления полностью экранированы
    <ArticMine> извините
    <sarang> Они обычно применяются в процессе построения выходного ключа
    <sarang> который в любом случае экранирован в Arcturus
    <sarang> риск при использовании тегов заключается в том, что отправляющий кошелек может генерировать любой тег, который он захочет, и получатель не обнаружит нужный ему выход
    <sarang> и вы не можете сделать дополнительное сканирование с помощью этого метода
    <sarang> а плохая реализация тегов может добавить факт дактилоскопии, в том случае если кошелек сделал что-то глупое и установил его в фиксированное значение
    <sarang> конечно, универсальные кошельки-получатели не увидят это, особенно если выполнят только быстрое сканирование. В любом случае это не будет работать для кошелька-отправителя
    MSavoritias подключился (~MSavoriti@44-224-rev.isper.sk)
    <sarang>
    вот временный код: https://github.com/SarangNoether/monero/commit/93172f80b2c25def9aaf40fc30dbee54f92f47a5
    <sarang> (он проходит проверку сборки, но Windows CI не работает)
    <knaccc> мне интересно, где разница между 75% реального и 62,5% теоретического
    <knaccc> я посмотрю код
    <sarang> Существует небольшое увеличение стоимости для каждого вычисления хеша и некоторых нескалярных операций
    <sarang> Да, дайте мне знать, если вы заметите что-то, что я пропустил
    <knaccc> они обычно пренебрежимо малы по сравнению с 0,15 мс или 0,25 мс для мультитула EC
    <sarang> угу
    dubie подключился (~dubie@63.230.70.90)
    <sarang>
    проверка хеша составляет примерно 2-3% от общего времени
    <knaccc> я не вижу в вашем коде ссылки на loop_count
    <sarang> Об этом позаботится предварительный тест
    <sarang> который использует отдельные результаты для выведения статистики
    <knaccc> о как
    <sarang> каждый тест настраивается в non-timed init()
    <sarang> и затем привязывается к test()
    <knaccc> да, в этом есть смысл
    <sarang> если вы хотите проверить, просто запустите `./performance_tests --stats --filter=\*view_tag\*`
    <sarang> флаги `true / false` соответствуют логическим переменным в определении теста
    <sarang> о, еще стоит учитывать преобразование байтов
    <sarang> оно не велико, но и пренебрегать ими тоже не стоит
    <sarang> но я лично склонен игнорировать его во время оценок
    <sarang> на этом у меня, пожалуй, всё
    <sarang> у вас есть вопросы?
    <knaccc> код выглядит отлично
    <sarang> Хорошо, кто-нибудь еще хочет поделиться своим исследованием?
    <sarang> knaccc: отлично
    <Isthmus> Хм, я начал задаваться одним вопросом этим утром...
    <Isthmus> За последние несколько лет мне пришлось отказаться от тонны интересных программных идей, потому что повторяющиеся транзакции с 3 выходами являются эвристически связанными, а альтернативные бизнес-модели (подписки, учетные записи и т. д.) имеют массу недостатков в конфиденциальности по сравнению с простой платой за обслуживание каждой отдельной операции
    <Isthmus> и теперь мне интересно, а не душит ли это внедрение и интеграцию Monero, мешая прямолинейному и приватному методу компенсации для разработчиков, которые хотят внести свой вклад в экосистему.
    <Isthmus> если мы хотим, чтобы Monero использовался не только для двухточечных транзакций и без потенциального риска для пользователей в ключе статистического анализа, то схема с 3 выходами должна выглядеть так: получатель + изменение + дополнительная плата за обслуживание
    <Isthmus> конечно, для многих транзакций третий вывод будет пустышкой (или, как вариант, пользователи могут проявить творческий подход и разделить сдачу на 2 адреса для еще большей гибкости)
    <sarang> Принудительно увеличить до 3?
    <Isthmus> возможно, что имеет смысл объединить это с большими кольцами, поскольку соотношение (# выход) / (# кольцевая подпись) за единицу времени не должно быть слишком большим (поскольку выходы, которые еще никогда не появлялись в кольцевой сигнатуре, имеют известное состояние траты [неизрасходованно] и информируют [с доказуемой уверенностью] отправителя, что средства впоследствии не были перемещены)
    <Isthmus> @sarang, да
    <sarang> разделение изменений означает более высокую вероятность использования нескольких выходных изменений в последующих транзакциях
    <sarang> что плохо для связывания
    <sarang> это главный недостаток всех этих наворотов
    <Isthmus> Да, именно поэтому я всегда выступал против того, чтобы люди разделялись внутри одного кошелька
    <ArticMine> Какой дополнительный размер получится за передачу?
    <Isthmus> 0.22 kB
    <Isthmus> я думаю
    <Isthmus> ой, стоп
    tromp вышел (~tromp@2a02:a210:ca3:2800:39a5:d7db:7b8e:ee59): Удаленный хост закрыл подключение
    <sarang>
    выглядит слишком большим
    <Isthmus> данные не совсем корректны
    <Isthmus> секунду
    <ArticMine> Если мы пойдем на 4?
    <sarang> ArticMine: что 4?
    binaryFate занимает одно из свободных мест в задней части комнаты
    <ArticMine>
    Разве нет bulletproofs доказательств эффективности?
    <ArticMine> для 4 против 3 выходов, которые должны были быть заполнены
    <sarang> заполнение BP не подразумевает дополнительных выходов
    <Isthmus> я смотрю данные на xmrchain и не могу найти ни одной 1/3/e транзакции, а вот 1/3/s довольно много (дайте мне минуту переварить всё)
    <sarang> это просто часть алгебры
    <sarang> ArticMine: это будет означать, что bulletproofs будет немного больше для стандартных транзакций
    <sarang> вы это имели в виду?
    <ArticMine> да
    <sarang> BP с 3 выходами (дополненное до 4) на 64 байта больше, чем BP с 2 выходами
    <sarang> (у BP с 4 выходами тот же самый размер, как и в случае с BP с 3 выходами)
    <ArticMine> это просто моё виденье
    <sarang> понял
    <sarang> Да, вы правы, что это увеличит типичный размер диапазона
    <Isthmus> Да, это делает Monero пригодным для использования в бизнес сегменте, но увеличивает размер транзакции
    <Isthmus> Еще одно пасхальное яйцо:
    MSavoritias вышел (~MSavoriti@44-224-rev.isper.sk): Причина: MSavoritias
    <Isthmus>
    По сути, нет транзакций 1-in-3-out с зашифрованными PID
    <Isthmus> существует только несколько транзакций 1-in-3-out, в которых PID отсутствует вообще
    <Isthmus> и несколько 1-in-3-out с необычным тегом в xmrchain, не уверен, что в именно в поле tx_extra
    Isthmus берёт в расчет данные за последние пару недель
    tromp подключился (~tromp@2a02:a210:ca3:2800:39a5:d7db:7b8e:ee59)
    <jwinterm>
    Я думаю, что это было бы разумно, учитывая, что транзакции с PID, вероятно, созданы пользователями для бирж или сервисов
    <Isthmus> и это выделяется как нестандартное программное обеспечение
    <Isthmus> я думаю, что мы иногда делаем все только хуже, особенно, когда добавляем функцию «для всех транзакций» в кошельке, а не для протокола :(
    <sarang> угу
    MSavoritias подключился (~MSavoriti@44-224-rev.isper.sk)
    <ArticMine>
    есть ли дополнительное увеличение до 64 байт?
    <sarang> Новый выход имеет публичный ключ, обязательство и зашифрованную сумму...
    <sarang> получается порядка 72 байт
    <ArticMine> и 4
    <sarang> 73 байт, если вы добавите тег просмотра
    <sarang> и добавьте еще один публичный ключ, обязательство, сумму и тег для каждого выхода
    <ArticMine> 82 против 73 байт и 4 более 3
    <sarang> нет
    <sarang> в дополнение к возможному увеличению доказательства диапазона каждый дополнительный выход требует еще 73 байта для публичного ключа, обязательства, скрытой суммы и необязательного тега представления
    <sarang> увеличение диапазона с 2 -> {3 или 4} составляет еще 64 байта
    <ArticMine> значит, что для 3 он будет равен 137 байта
    <sarang> это уже более правдоподобно
    <sarang> Это также подразумевает увеличение времени сканирования (но оно сокращается за счет предпросмотра тегов)
    <ArticMine> и для 4 210 байт
    <sarang> и дополнительное время сканирования
    <ArticMine> Да
    <sarang> В любом случае, в интересах экономии времени, есть ли другие темы, которые нужно затронуть?
    <sarang> (мы всегда можем продолжить обсуждение после окончания основной встречи)
    <knaccc> Кстати, мне было бы интересно увидеть примеры использования 3-out транзакций
    <knaccc> да, конечно, как вариант, после встречи
    <sarang> пучаются очень большие комиссии
    <sarang> Один выход отправляется получателю, один для изменения, другой поставщику услуг
    <ArticMine> НДС / СБОРЫ?
    <knaccc> sarang, что вы подразумеваете под поставщиком услуг? Это какой-то слишком общий пример
    <knaccc> ArticMine, вы предлагаете платить НДС напрямую правительству как часть транзакции?
    <sarang> knaccc: может быть, вы используете какой-то сервис стороннего кошелька
    <sarang> или у вашего кошелька есть возможность пожертвовать небольшую сумму на благотворительность с каждой транзакции
    <knaccc> всё, теперь понял, спасибо
    <sarang> Хорошо, давайте быстро пройдемся по КЛЮЧЕВЫМ МОМЕНТАМ, если у вас нет других тем для обсуждения
    <sarang> когда я исправлю ошибку с Windows CI, я подготовлю новый PR
    <sarang> и еще закончу подготовку документов Triptych и Arcturus для отправки на PoPETs
    <sarang> надеюсь, что успею закончить дополнительные тесты и трассировку
    <moneromooo> Микроплатежи в каждой транзакции - отличный способ задушить Monero. Мы ведь не хотим иметь огромное количество выбросов пыли, ведь она тоже потребляет ресурсы, как и «нормальные» выходы
    <sarang> moneromooo: это то, что я имел в виду
    <knaccc> сборы имеют важное значение для multisig
    <ArticMine> довольно скользкий путь...
    <knaccc> я думаю, что все типы оплаты по умолчанию должны поддерживать multisig
    <knaccc> и multisig не будет никогда поддерживаться другим типом кошелька
    <sarang> Хорошо, я полагаю, мы можем закрыть нашу сегодняшнюю встречу (и я смогу публиковать журнал), но обсуждение, конечно, может продолжаться дальше
    <sarang> Спасибо всем за участие!
    <knaccc> ^^

    Источник: Research meeting: 27 May 2020 @ 17:00 UTC #468

    Перевод:
    Unholy (@Unholy)
    Редактирование:
    Mr. Pickles (@v1docq47)
    Коррекция:
    Kukima (@Kukima)
     
    #1 Unholy, 4 июн 2020
    Последнее редактирование модератором: 9 июн 2020
  • О нас

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