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

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

  1. Unholy

    Unholy Well-Known Monerano

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

    Повестка дня:

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

    <sarang>
    Хорошо, время для нашей встречи!
    <sarang> Во-первых, приветствия!
    <sarang> Hi
    <ArticMine> Hi
    sarang ждет несколько минут, возможно, что придут другие участники
    <sgp_>
    привет
    <dEBRUYNE> Hi
    <binaryFate> Здравствуйте
    <Isthmus> Приветствия
    <sarang> Хорошо, перейдем к нашему круглому столу, где каждый желающий может поделиться своими темами исследований
    <sarang> Кто-нибудь хочет начать?
    <sarang> Если нет, я пойду первым
    <sarang> Вы можете прочитать мой ежемесячный исследовательский отчет здесь: https://www.reddit.com/r/Monero/comments/j2oncd/september_monthly_report_from_sarang_noether/
    <monerobux> [REDDIT] September monthly report from Sarang Noether (self.Monero) | 26 points (97.0%) | 5 comments | Posted by SarangNoether | Created at 2020-09-30 - 15:48:27
    <sarang> Это мой последний отчет за текущий период финансирования
    <sarang> На прошлой неделе я выступал на виртуальной конференции MCC с докладом на тему конфиденциальности
    <sarang> и участвовал в другой, параллельной панели
    <sarang> Я взял идею cargodog[m] для `n`-ных кодов Gray и создал рабочие прототипы для Triptych и Arcturus на Python и C++.
    v1docq47[m] подключился
    <sarang>
    и уже успел представить часть новых результатов
    <sarang> Я также обновил код Triptych для более эффективной группировки доказательств в рамках одной транзакции
    <sarang> Вот и все в ключе моего обновления
    <h4sh3d[m]> Привет (извините, сегодня я не могу присутствовать, удачной встречи)
    <sgp_> Я предполагаю, что у вас нет ETA на видео с MCC?
    <sarang> h4sh3d[m], нет проблем
    <sarang> Я не знаю, какие у них планы на видео с данного мероприятия, извините
    <sarang> Я только знаю, что они были записаны
    <sgp_> вы где-нибудь публиковали слайды?
    <sarang> Нет, но я могу опубликовать их сегодня, если это нужно
    <sarang> Им нужны были Google Slides, поэтому я могу опубликовать PDF-файл, а не исходный код
    <sarang> еще вопросы по темам моих исследований?
    <sarang> Вот слайды MCC: https://github.com/SarangNoether/talks/tree/mccvr-2020
    <sarang> Хорошо, кто-нибудь еще желает поделиться интересными темами исследований?
    <sarang> Сегодня довольно тихо!
    <sarang> Если нет, я могу обсудить код Gray немного детальней
    <sarang> Вот временной график: https://docs.google.com/spreadsheet...q5Wt9MaUi7/pubhtml?gid=1695886143&single=true
    <sarang> Я еще не успел переместить его в `gnuplot`
    <sarang> Для набора данных `Triptych Gray 2-2` есть точка выброса, которая является всего лишь временной случайностью, и ее можно спокойно игнорировать.
    <sarang> (пунктирная синяя линия)
    <dEBRUYNE> sarang: ссылка на видео с MCC -> https://www.reddit.com/r/Monero/com...onero_research_lab_will_be/g6t0egm/?context=3
    <monerobux> [REDDIT] Sarang Noether of the Monero Research Lab will be speaking at the Magical Crypto Conference today at 1:15 PM EDT (Privacy: The Collision of Theory and Practice) and 1:55 PM EDT (Is Bitcoin Falling Behind on Privacy - Panel) (https://www.magicalcryptoconference.com/2020-vr#agenda) to r/Monero | 73 points (97.0%) | 13 comments | Posted by dEBRUYNE_1 | Created at 2020-09-26 - 14:37:48
    <sarang> Если у кого-то возникнут проблемы с цветом, напишите мне сообщение, и я дам ссылку на другую версию
    <sarang> dEBRUYNE, спасибо!
    <dEBRUYNE> пожалуйста
    <sarang> Наш вариант использования Gray в Triptych/Arcturus сводится к идее использовать общие входные наборы внутри транзакций, а не между самими доказательствами
    <sarang> В Lelantus они повторно используют большие общие входные наборы для большинства имеющихся доказательств
    <sarang> В нашем случае использования Gray показывает заметную разницу только при использовании размера в диапазоне между 64–128 и при увеличении количества входов
    <sarang> Это преимущество, основанное на входных данных, можно было бы упразднить, если бы мы пересмотрели способ выполнения инверсий
    Myrtle63Kuhlman подключился
    <sarang>
    И, как вы можете заметить, для больших размеров входных наборов результаты достаточно маргинальны (процент уменьшается со временем)
    <sarang> Также я поделился своим вариантом кода с командой Lelantus; и они могут захотеть провести свои собственные временные эксперименты на основе их конкретного варианта использования
    <sarang> и похоже, что cargodog[m] намеревается добавить это в свою собственную реализацию Arcturus на Rust
    <sgp_> весьма неплохо
    <binaryFate> Где я могу найти информацию о работе кода Gray после выхода из цикла? Журналы встреч?
    <sarang> binaryFate, одну секунду, у меня где-то были ссылки
    <sarang> https://github.com/cargodog/arcturus/issues/19
    <binaryFate> спасибо!
    <sarang> cargodog[m] реализовал метод двоичного кода Gray для своей новой вариации доказательств Groth / Kohlweiss
    <sarang> и предположил, что это может быть полезно для оптимизации Bootle, используемой в Arcturus / Lelantus / Triptych
    <sarang> Я реализовал идею, используя n-ные коды Gray для Arcturus и Triptych в Python (для прототипирования) и на C ++ (для определения времени)
    <sarang> следует поблагодарить cargodog[m] за эту идею
    <sgp_> похоже на "стрижку"
    <sarang> Переходя от стандартного n разложения целых чисел к n разложению Gray, вы упрощаете умножение, используемое для вычислении определенных скаляров, и заменяете его ресурсоёмким процессом инверсии, сложность которого может быть амортизирована
    <sarang> Своеобразное отсеивание для данного типа выбора входных данных
    Myrtle63Kuhlman вышел
    <sarang>
    Для других приложений улучшения могут быть намного лучше
    <ArticMine> Есть ли различия в размере транзакции?
    <sarang> Нет
    <sarang> Размер транзакции идентичен
    <sarang> только то, как вычисляются элементы доказательств
    <ArticMine> и еще небольшое улучшение времени проверки
    <sarang> Для текущего варианта использования непересекающихся наборов входных данных между транзакциями, да
    <sarang> Однако даже при таком использовании можно было бы переделать код, чтобы объединить дорогостоящую инверсию между несвязанными доказательствами
    <sarang> Таким образом, для пакетирования потребуется только одна инверсия
    <sarang> Однако если входные наборы не пересекаются, польза от этого будет минимальной.
    <sarang> Вы действительно получите улучшение, если объедините много доказательств с одним и тем же набором входных данных, а также объедините инверсии
    <sarang> Как видите, это становится очередным узким горлышком в бутылке
    <ArticMine> пожалуй
    <sarang> В любом случае у нас получаются разумные временные данные для этой идеи
    <sarang> в общем с нетерпением жду результатов тестирования от cargodog[m] и команды Lelantus
    <sarang> стоит отметить, что cargodog [m] использует более эффективную криптографическую библиотеку, а текущий вариант использования Lelantus для пакетной обработки и наборов входных данных сильно отличается от нашего
    <sarang> во всяком случае, это очень интересная идея
    <sarang> можно сказать, что это своего рода испытание
    <UkoeHB_> классная работа
    Febo вышел
    <UkoeHB_>
    Кстати, ArticMine! У вас было какое-то предложение с пересмотром комиссий
    <UkoeHB_> Насколько помню, вы хотели пересмотреть кое-какие аспекты
    <ArticMine> Да, было дело. Основная проблема, которую я вижу, - это риск спама
    <ArticMine> однако мои переживания весьма преувеличены
    <ArticMine> ведь мы можем перейти к использованию долгосрочной медианы в качестве зоны, свободной от штрафов.
    <ArticMine> что только поспособствует эффективному обеспечению стабильных комиссий
    <ArticMine> еще одно преимущество заключается в том, что такая медиана, по сути, бесполезна в ключе атаки Большого взрыва
    <ArticMine> поскольку как только медиана сдвинется, атака Большого взрыва не прекратиться
    <UkoeHB_> Хм… мое предложение заключалось в использовании долгосрочной медианы для штрафной зоны, что позволит штрафной зоне быть более гибкой. А у вас, вообще, всё получается наоборот. Ведь если штрафная зона колеблется, то и сам размер комиссий будет больше
    <ArticMine> Это сохранение долгосрочной медианы, которая должна сдерживать атаку Большого взрыва
    <ArticMine> Да, с использованием долгосрочной медианы в качестве зоны без штрафов
    <binaryFate> Можете ли вы прояснить, как в вашем представлении выглядит "риск спама"?
    <ArticMine> есть два случая
    <ArticMine> 1) Для текущей версии атаки Большого взрыва нет никаких изменений, поскольку спамеру нет смысла поддерживать долгосрочную медиану
    <ArticMine> 2) Если краткосрочная медиана падает ниже долгосрочной, это создает ситуацию, аналогичную той, что у нас наблюдается сейчас, но с гораздо более высокими размером блока и комиссией
    <ArticMine> Таким образом, стоимость ретрансляции спама узлом составит f=минимальная плата
    <ArticMine> также стоит отметить, что в этом случае не будет штрафа за возврат к долгосрочной медиане, поскольку отсутствует штраф за возврат к стандартному размеру в 300000 байт
    <ArticMine> стоимость за ретрансляцию спама в сеть в регулярном выражении будет намного выше, чем сейчас
    <ArticMine> и это гораздо более простое решение, чем то, что есть сейчас.
    <ArticMine> да и сам код был бы чище
    <UkoeHB_> Мне придется немного подумать над всем этим
    <ArticMine> Все сводится к одному вопросу - как именно мы можем увеличить скорость транзакций в 100 раз без существенного увеличения цены на комиссии
    <ArticMine> Не думаю, что это реально
    binaryFate> согласен
    <ArticMine> Таким образом, стоимость в реальном выражении остается той же, однако стоимость спама увеличивается вместе с весом блока и его ценой
    <sarang> Хорошо, есть ли другие темы для исследования, которые нужно обсудить до окончания нашей встречи?
    <Isthmus> Есть ли смысл в определении размера блока с помощью зашифрованного голосования внутри самого майнера?
    <Isthmus> (это сводится к консенсусному предположению Накамото о том, что 51% майнеров будут действовать в интересах сети)
    <Isthmus> Один из сотрудников Insight пытается создать неинтерактивный механизм ZKP, основанный на зашифрованном голосовании Pallier.
    <sarang> О, как! Я не знал, что это вообще возможно
    <Isthmus> (каждый блок содержит один тринарный голос за {уменьшение / то же самое значение / увеличение})
    <sgp_> какую пользу это вообще может привнести?
    <ArticMine> Майнер и так может ограничить размер блока
    <binaryFate> человеческий ввод любого значения выглядит как унижение чисто алгоритмического решения, но это, безусловно, интересное исследование.
    <Isthmus> @sgp, прямо сейчас, в 2020 году, мы пытаемся улучшить алгоритм динамического размера блока, который даст желаемые результаты как минимум в 2030 году, но я не знаю, насколько крупными будут транзакции, насколько быстрым будет интернет или какой у нас вообще будет объем транзакций
    <Isthmus> Если мы пойдем по тропинке с зашифрованным голосованием майнеров, то размер блока в 2030 будет устанавливаться майнерами, а не исследователями с 2020 года.
    <Isthmus> майнеры понимают намного лучше, сколько им под силу обработать, прежде чем блоки станут слишком большими и т. д.
    <sgp_> как это отменяет существующие ограничения?
    <ArticMine> В текущей ситуации майнеры все еще могут ограничивать размер блока
    <Isthmus> Майнеры могут создавать блоки меньшего размера, чем позволяет алгоритм, но не наоборот
    <Isthmus> Так что это одностороннее решение
    <Isthmus> @sgp - никак
    <Isthmus> Может быть, стоит сделать динамический алгоритм, но с возможностью голосования со стороны майнеров
    <Isthmus> Стоит обозначить, что сейчас это просто игрушка, еще не превратившаяся в полноценный безопасный экономический инструмент
    nssy подключился
    <ArticMine>
    Голосование предлагалось только в криптовалютах с фиксированным размером блока, например Bitcoin
    <ArticMine> и Bytecoin
    <ArticMine> когда награда за блок упадет до нуля
    <Isthmus> Интересно, за что голосуют в этих системах?
    <ArticMine> за размер блока
    <ArticMine> В Ethereum за максимальное потребление газа на блок
    <Isthmus> Каждый майнер в ETH может проголосовать за +1/1024 или -1/1024, если я правильно помню
    <UkoeHB_> использование ArticMine долгосрочной медианы, свободной от штрафов, по-прежнему добавляет нам проблемы с минимальной комиссией. Связанные с тем, что если краткосрочная медиана падает, то транзакции с минимальными комиссиями будут недействительными.
    <UkoeHB_> как и в случае заполнения зоны, свободной от штрафов (при условии, что PFZ основывается на долгосрочной медиане).
    <ArticMine> комиссии устанавливается на основе долгосрочной медианы, поскольку зона, свободная от штрафов, является минимальным значением для краткосрочной медианы
    <binaryFate> Учитывая тот факт, что Monero стремится майнить на обычном оборудовании, я бы не стал предполагать, что майнеры Monero будут иметь большой долгосрочный интерес к данному голосованию
    <UkoeHB_> разве нет опасности картелизации, если размер блока основан на голосовании?
    <binaryFate> Это отличается от того, что вы ожидаете от майнеров, купивших узкоспециализированное оборудование для майнинга других монет
    <ArticMine> <UkoeHB_> разве нет опасности картелизации, если размер блока основан на голосовании? <--- Даже очень
    <Isthmus> "разве нет опасности картелизации, если размер блока основан на голосовании?" <--- а что если майнеры решат ограничить размер блока или что-то в этом роде?
    <ArticMine> это единственный вариант фиксированного размера блока для монет с падающей эмиссией
    <ArticMine> Крупные картели рано или поздно терпят поражение...
    <UkoeHB_> черт возьми, это даже хуже, чем картелизация, поскольку стимул голосовать за небольшие блоки предоставляется всем майнерам; картелизация просто вытесняет транзакции
    <UkoeHB_> картелизация в настоящее время является проигрышным предложением, так как другие майнеры просто заберут на себя оставшиеся транзакции в сети
    <UkoeHB_> поэтому картель работает в убыток, если у него нет серьезного конкурентного преимущества
    <Isthmus> 501 майнер из 1000 должен проголосовать за любое изменение размера блока, что подразумевает несоблюдение консенсусного предположения Накамото
    <Isthmus> (опять же, это не более чем наша песочница)
    <Isthmus> для уточнения - изменение размера блока не произойдет, если за него не проголосует как минимум 51% всех майнеров
    <Isthmus> Ну ладно, как только мы закончим исследование, я обязательно поделюсь ссылкой
    <Isthmus> Извините, но мне нужно уходить
    <sarang> Получилась отличная беседа!
    <sarang> ладно, предлагаю прерваться, обсуждения, конечно, могут продолжаться дальше

    ---

    Источник: Research meeting: 30 September 2020 @ 17:00 UTC #513

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

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