Когда: Среда, 30 сентября 2020 года @ 17:00 UTC Где: #monero-research-lab (freenode/matrix) Повестка дня: Приветствия Круглый стол Вопросы Ключевые моменты Журнал встречи: <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)
