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

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

  1. Unholy

    Unholy Well-Known Monerano

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

    Журнал встречи:

    <sgp_> Время встречи
    <sgp_> 1. Приветствия
    <hyc> hola
    <zkao> hoi
    <sethsimmons> всем привет
    <sethsimmons> правда, я только частично тут или, скорее, в режиме чтения
    <rottenwheel> Привет
    <sgp_> пропингую: sarang, moneromooo, ArticMine, knaccc, vtnerd
    <rbrunner> Привет (я так, поглядеть, что у вас тут твориться)
    <h4sh3d[m]> hi
    <zkao> jwinterm, midipoet
    <endogenic> endogenic
    <sgp_> всем привет
    <lederstrumpf> привет
    <sgp_> sarang и moneromooo сегодня с нами?
    <ArticMine> Hi
    <sgp_> хм, видимо, нет
    <sgp_> начнем с первой темы сегодняшней повестки
    <sgp_> https://github.com/monero-project/meta/issues/547#issuecomment-772600779
    <sgp_> нам нужно подумать о том, какой план действий мы выбираем
    <sgp_> это уже обсуждалось на предыдущей встрече, но для удобства я всё переписал в отдельную тему
    <sgp_> Саранг упомянул, что исследовательская работа в ключе triptych займет порядка 2 месяцев
    <sgp_> 3 месяца, если добавить этап работы от moneromooo
    <sethsimmons> Я просто не вижу необходимости откладывать обновление сети из-за мультиподписей, которые и так редко используются
    <sethsimmons> Так что вариант 2 мне кажется лучше
    <sgp_> для ясности:
    <sethsimmons> Если мы сможем работать над мультиподписью параллельно или сможем профинансировать эту часть отдельно, это будет самый лучший вариант
    <sgp_> вариант 1 и вариант 2 включают поддержку кошелька с мультиподписью
    <sgp_> вариант 1 — это 2 хардфорка (1 для BP +, другой для triptych)
    <sgp_> вариант 2 состоит из 1 хардфорка с объединёнными вариантами выше
    <sethsimmons> Оу
    <hyc> мне кажется, что лучше всего менять по одной вещи за раз
    <ArticMine> Я предпочитаю вариант 1
    <rottenwheel> Я хотел бы сначала услышать позицию Саранга или Moo
    <h4sh3d[m]> согласен с hyc, хардфорк с двумя большими изменениями более рискован
    <zkao> я полностью согласен с hyc
    <sgp_> однако два хардфорка создают больше головной боли для экосистемы, чем 1
    <ArticMine> Тем не менее я хочу услышать о сроках от Саранга
    <sgp_> обратите внимание, что я могу говорить от имени Санага о не менее двух месяцах исследований. Это его точный прогноз
    <sgp_> но я не могу говорить от имени moo
    <hyc> второй хардфорк через 10 месяцев после первого не кажется такой уж большой проблемой
    <hyc> учитывая, что мы делали их каждые 6 месяцев, почему 10 месяцев - проблема?
    <rbrunner> Я пока не понимаю, что будет происходить в эти 5 месяцев работы в варианте 1, где заявлена одна только цель - «Поддержка ...». Что там будет происходить?
    <sgp_> к тому же у Cake есть проблемы с реализацией triptich в их кошельке
    <sethsimmons> Как по мне, 1 вариант самый лучший. Меньше возможностей для потенциальных ошибок
    * needmoney90 только что проснулся и пытается понять, что тут вообще происходит
    <sethsimmons>
    <rbrunner "Что там будет происходить?"> Предполагаю, что это время с учётом паузы между хардфорками
    * needmoney90 занимает одно из свободных мест
    <endogenic>
    вот и пополнение в лице needmoney90
    <rbrunner> окей
    <hyc> по-видимому, будет и другая работа
    <sgp_> неужели август — это самый ближайший вариант, когда у нас будет v15? На самом деле я бы предпочел двигаться вперед и как можно дальше, если мы хотим обойтись одним хардфорком
    <needmoney90> debruyne или selsta сегодня с нами?
    <sgp_> а так я бы, конечно, предпочел провести хардфорк в июне
    <needmoney90> они оба являются первой линией поддержи на передовой, и я думаю, что их мнение будет ценным
    <ArticMine> это вы про вопрос #70?
    <needmoney90> именно они занимаются решением всех проблем после очередного хардфорка
    * zkao голосует за август
    <sgp_>
    dEBRUYNE сегодня нет, однако в комментариях он высказался за второй вариант
    <sgp_> лично я предпочитаю вариант 2, но я также понимаю аргументы в пользу варианта 1
    <rbrunner> одна большая проблема вместо двух поменьше?
    <ArticMine> Преимущество варианта 2 состоит в том, что он упрощает масштабирование, поскольку будет только один размер транзакций, с которым нам нужно будет работать
    <moneromooo> думаю, время будет зависеть от того, когда код пройдет аудит, разве нет?
    <moneromooo> BP+ уже готов к интеграции
    <moneromooo> интеграция Triptych потребует дополнительного времени, плюс нам может потребоваться новый способ представления колец, в зависимости от того, насколько мы решим увеличить текущий размер кольца
    <sarang> Hi
    <moneromooo> к тому же просто взять и забить на пользователей, использующих мультиподпись, нельзя. И вероятно, нам придётся оставить сборы в старой схеме CLSAG в дополнении к новой схеме, чтобы они все еще смогли потратить свои монеты, пока мы разбираемся с новой схемой мультиподписи
    <gingeropolous> ^
    <sgp_> moneromooo: насколько я понимаю, во 2 варианте мы не пускаем этот момент с мультиподписью на самотёк
    <sgp_> похоже, что большинство голосует за 1 вариант
    <needmoney90> если Deb склоняется ко 2 варианту, я поддержу его выбор
    <sethsimmons> оба варианта имеют место быть, но лично я склоняюсь к варианту с быстрым переходом к новому размеру колец
    <hyc> не понимаю, что будет таким переломным изменением для реализации мультиподписи?
    <hyc> и да, давайте не будем торопиться
    <moneromooo> Когда я сказал "аудит", я имел в виду аудит третьей стороной
    <sethsimmons> Оба варианта усложняют реализацию мультиподписи
    <rbrunner> Потенциальная проблема мультиподписи заключается в том, что у пользователей не будет возможности тратить монеты из кошелька с мультиподписью в течение определенного периода?
    <sarang> Области исследований по-прежнему включают в себя: пакетирование кросс-транзакций, многозначные алгоритмы, их анализ и, конечно, пакетирование наборов анонимности
    <needmoney90> Мы должны склоняться к большей последовательности в наших релизах, если это вообще возможно. Я думаю, что два хардфорка (когда мы знаем, что будет включено в оба заранее) менее жизнеспособный вариант
    <sgp_> rbrunner: Не думаю, что это так работает
    <sethsimmons> sgp_: есть ли у вас краткое изложение потенциальных последствий каждого из вариантов?
    <rbrunner> Просто интересно, что это за "херня"...
    <sgp_> Пользователи кошелька clsag с мультиподписью должны «конвертировать» свой кошелек в кошелек без мультиподписи, прежде чем они смогут потратить средства в triptych
    <sethsimmons> <needmoney90 "Мы должны склоняться к большей последовательности в наших релизах"> Если мы пойдем по этому пути и объединим BP + и Triptych, я бы проголосовал за более долгое время для тестирования в тестовой / отладочной сети
    <sethsimmons> как вариант, заставить людей запускать узлы с использованием простых скриптов для сценариев стресс-тестирования.
    <sgp_> возможно, мне нужно все это четко задокументировать, так как мне кажется, что есть масса путаницы
    <needmoney90> Это вызовет меньшую нагрузку на все наши ресурсы и экосистему в целом
    <rbrunner> это не может причинить вреда :)
    <sgp_> хорошо, а как насчет этого
    <sethsimmons> Обычно мы не проводим какие-то публичные тесты / тесты в отладочной сети перед форками, и в тестировании участвуют лишь некоторые из нас. И я был бы рад, если бы мы активно пытались привлечь новых пользователей для проведения дополнительной нагрузки и тестов в общем
    <sgp_> Я открою проблему на github для этих двух вариантов
    <sethsimmons> <sgp_ "возможно, мне нужно все это четко задокументировать"> Это будет только сбивать с толку
    <sgp_> будет где-то неделя для возможности прокомментировать или высказать своё мнение
    <sgp_> хотя, можно и продлить
    <needmoney90> Более длинная временная шкала будет для нас отличным шансом к более интенсивному тестированию
    <sgp_> прежде чем я создам тему на github, почему дата проведения хардфорка в 1 варианте август?
    <moneromooo> BP+ не является таким уж большим достижением по сравнению с оригинальной работой, так что я бы вообще отложил его на потом
    <sethsimmons> Я бы рекомендовал выбрать дату в 1-2 месяца после завершения аудита
    <moneromooo> в первом варианте мы получили весомое уменьшение размера, с12 kB до 2.5 kB.
    <sgp_> ArticMine: с другой стороны, уменьшение от BP+ тоже нужное улучшение
    <sgp_> мы можем завершить аудит bp+ за 2 месяца, это вполне выполнимая задача
    <sethsimmons> конечно
    <sgp_> поэтому я настроен на дату раньше, чем август
    <sethsimmons> Я бы рекомендовал провести данный хардфорк вместе с другими улучшениями, такими как MRL70 или увеличение размера кольца
    <sethsimmons> <sgp_ "мы можем завершить аудит bp+ за 2 месяца"> Тогда июль?
    <sgp_> кто-нибудь против конца июня?
    <sgp_> потому что, если никто не будет против конца июня, я могу скорректировать первый вариант
    <needmoney90> Я бы предпочел получить какую-то информацию от нашей службы поддержки, прежде чем звонить в сервисный центр :D
    <ArticMine> Итак, получается, дата окончания аудита ВР+ в апреле, а сам хардфорк в июне. В этом есть смысл...
    <moneromooo> В любом случае это обсуждение для канала dev. Мы не должны здесь обсуждать время проведения хардфорка
    <sgp_> ладно, похоже, мне нужно поработать над концепцией подачи
    <sgp_> Я составлю текст для темы на github не позднее завтрашнего утра и постараюсь сделать краткое изложение текущих вариантов и дальнейших планов
    <sgp_> ArticMine: может тогда поговорим о комиссиях?
    <sgp_> https://github.com/monero-project/research-lab/issues/70#issuecomment-768036260
    <sgp_> меня немного беспокоит увеличение лимита масштабирования с 1.4 до 2
    <sgp_> мне это кажется весьма агрессивным
    <sgp_> если внедрение Monero будет увеличиваться быстрее, чем установленный нами лимит, конечно, сеть не даст трещину, просто транзакции станут дороже
    <sgp_> у кого-нибудь есть мысли?
    <ArticMine> я согласен, что во многих случаях может быть достаточно значения в рамках 1,6 или 1,8
    <UkoeHB> Ох, что-то новое и то, о чём я еще не в курсе… Совсем нет времени…
    <sgp_> коэффициент 2 позволит увеличить размер блока аж на x32 в год
    <ArticMine> В 2016 году мы увидели, что показатель за несколько месяцев превысил отметку в 2, а в период медвежьего рынка 2014–2015 годов и роста внедрения как такового изменения не наблюдалось
    <sgp_> коэффициент 1.4 будет составлять порядка ~ 5.4x
    <ArticMine> и уже только в 2019-2020 годах мы наблюдали рост внедрения во время очередного медвежьего рынка
    <sgp_> Что ж, может быть, нам следует установить верхний предел роста в год, но, опять же, это приближает нас к текущей пропускной способности транзакций в Bitcoin
    <sgp_> поскольку сегодня сеть BTC действительно работает с ограниченным размером
    <sgp_> или это неразумно?
    <ArticMine> Добавьте к этому недавние нормативные изменения и повторение того, что произошло в 2016 году, и нас уже будет коэффициент более 2
    <ArticMine> В Bitcoin это не работает из-за ограничений роста
    <ArticMine> Так что следовать примеру Bitcoin неразумно
    <sgp_> Однако у нас еще есть резерв для потенциального роста
    <sgp_> это ограниченная скорость роста, а не ограниченный статический размер
    <ArticMine> То, что у нас есть коэффициент 2, не означает, что он будет исчерпан
    <sgp_> мы должны подготовиться к тому, что спамеры попытаются воспользоваться им в своих злых умыслах
    <ArticMine> Вот почему мы вводим долгосрочную медиану
    <ArticMine> А недавняя атака имела обратный результат
    <ArticMine> Я имею в виду атаку, которая случилась месяц назад
    <sgp_> да, я понимаю вводимые ограничение
    <jwinterm> коэффициент может быть максимален в двух случаях: 1) когда размер блокчейна вырастет в два раза за один год и 2) когда комиссионные сборы преодолеют среднегодовой показатель
    <jwinterm> как-то так
    <sgp_> jwinterm: это суждение позволит блокам вырасти в 32 раза больше, чем они были в начале предыдущего года
    <ArticMine> Если мы позволим краткосрочной медиане находиться выше долгосрочной медианы в течение длительного периода времени, то подобные атаки имели бы более серьёзный характер
    <needmoney90> Я считаю, что ~32x в год — это слишком много, и у нас мало времени, чтобы среагировать на атаку. И да, на данном этапе нам следует учитывать время в годах, а не в месяцах.
    <ArticMine> У нас достаточно времени
    <ArticMine> для реагирования на подобные атаки
    <needmoney90> не стоит забывать, что существует множество других проблем с поддержкой / экосистемой
    <ArticMine> в то время как у злоумышленников порядка 2 часов, чтобы пересмотреть вектор атаки
    <needmoney90> и все они должны присутствовать в этом уравнении
    <ArticMine> Это я о том, как долго может падать краткосрочная медиана
    <sgp_> В Bitcoin сейчас чуть более x10 транзакций в день, чем в Monero
    <selsta> Как по мне, июнь - не самое лучшее время
    <needmoney90> о, а вот и selsta
    * selsta пытается наверстать упущенное
    <needmoney90>
    продолжайте, нам очень важно ваше мнение в ключе данного вопроса
    <needmoney90> ведь именно вы имеете дело с последствиями хардфорков
    <ArticMine> Таким образом, мы говорим о том, что время реагирования на атаку составляет менее 2 часов против 2 месяцев
    <sgp_> ArticMine: давайте разделим эти две вещи
    <sgp_> 1) максимальная скорость падения (мы, кажется, согласны с этой частью уравнения)
    <ArticMine> не совсем вас понимаю
    <sgp_> 2) максимальная скорость увеличения
    <sgp_> всё правильно?
    <ArticMine> Да, но вы игнорируете тот факт, что краткосрочная медиана все еще может быть выше долгосрочной медианы в течение длительного периода времени
    <ArticMine> а это уже какая-то подготовка почвы для атаки
    <ArticMine> именно той, что случилась ранее
    <ArticMine> весь смысл долгосрочной медианы - дать сообществу более двух месяцев на то, чтобы среагировать на готовящееся событие атаки
    <ArticMine> и будет весьма глупо, если мы что-то поменяем
    <sgp_> потому что рост ограничен ~2-кратным увеличением?
    <ArticMine> Краткосрочная медиана ограничена в 50 раз в отличие от долгосрочной медианы
    <ArticMine> Чтобы обеспечить сохранение долгосрочной медианы при всплеске в течение 1-2 месяцев
    <ArticMine> Вот почему максимальная емкость медианы в VISA в 20 раз превышает их средней месячный показатель
    <ArticMine> Все это было сделано, когда в 2019 году была введена долгосрочная медиана
    <sgp_> Я все еще считаю данный рост слишком амбициозным
    <sgp_> извините, мы приближаемся к окончанию нашего эфирного времени
    <sgp_> selsta: значит вы считаете август слишком пессимистичным настроем
    <sgp_> или как?
    <ArticMine> На самом деле это очень разумно
    <ArticMine> особенно если учитывать текущие транзакции
    <sgp_> Я думаю, что нам нужно будет запланировать еще одно отдельное обсуждение ограничений блокировки
    <ArticMine> Я предлагаю сделать отдельную выжимку из текущих аргументов на GitHub
    <needmoney90> Пусть selsta наверстает упущенное и ответит в соответствующей теме на github
    <ArticMine> Сделайте сравнение для 1.6 и 1.8
    <ArticMine> против 2
    <selsta> needmoney90: я перечитаю запись журнала немного позже
    <sgp_> да, я могу задокументировать это сравнение
    <selsta> мы можем двигаться дальше
    <sgp_> но я не хочу, чтобы по умолчанию предполагалось увеличение до 2
    <sgp_> изменение на 2 — это весьма ожидаемое изменение
    <selsta> да, на последней встрече я сказал, что хардфорк случится не раньше июля / августа
    <sgp_> окей, спасибо, selsta
    <sgp_> какие-нибудь заключительные мысли?
    <sgp_> если кто-то хочет присоединиться ко мне и помочь в работе над составлением второго запроса на аудит BP+, пожалуйста, сообщите мне об этом
    <sgp_> выводы:
    <needmoney90> Аудиты будут опубликованы общедоступно?
    <needmoney90> может, стоит провести отдельную встречу по результатам аудита
    <sgp_> needmoney90: не думаю, что стоит проводить отдельную встречу
    <sgp_> аудит от SoW будет опубликован в их репозитории
    <needmoney90> Окей, понял.
    <sgp_> ориентировочно через неделю после окончания аудита
    <sgp_> правда если график их работ не изменится
    <needmoney90> ясно
    <needmoney90> вопросов не имею
    <sgp_> и я был бы рад, если бы Саранг подготовил свои комментарии и мысли по результату аудита
    <sgp_> так как я понятия не имею, что это за код и как именно он работает :D
    <sgp_> в любом случае
    <sgp_> спасибо за встречу

    ---

    Источник: IRC #monero-research-lab

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

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