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

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

  1. Unholy

    Unholy Active Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    61
    Симпатии:
    6
    Журнал встречи исследовательской лаборатории Monero
    2019-02-09

    <hyc>
    Я думал, что эта идея randomJS PoW была довольно крутой, когда я придумывал ее
    <-- sgp_1 (~justi@50-202-180-242-static.hfc.comcastbusiness.net) покинул #monero-research-lab
    --> sgp_ (~justi@50-202-180-242-static.hfc.comcastbusiness.net) подключился
    к #monero-research-lab
    <gmaxwell>
    hyc: такой подход полностью разрушался всякий раз, когда я видел его предложенным ранее (по крайней мере, в 2012 году)
    <gmaxwell> как правило, одним из необходимых свойств для хорошего POW является то, что каждый экземпляр одинаково трудно выполнить в наиболее оптимизированной среде
    <-- muff1nman (~irccc@75-166-29-132.hlrn.qwest.net) вышел (Причина: нет ответа в течение 180 секунд)
    <hyc>
    да, только насколько сложен этот код, определяющий "супер-тривиальность"
    <hyc> генератор кода настроен так, чтобы сохранить весь сгенерированный код в течение времени выполнения (x +/- 10 миллисекунд)
    <endogenic> hyc: какие изменения могут быть внесены в randomjs, если выяснится, что некоторые его аспекты были реализованы аппаратно?
    <andytoshi> я ожидал бы, что это сделает сопоставление с шаблоном и возьмет однозначные числа наносекунд
    --> muff1nman (~irccc@75-166-29-132.hlrn.qwest.net) подключился к #monero-research-lab
    <hyc>
    andytoshi: Я очень сильно сомневаюсь в этом, поскольку сгенерированный код включает в себя вызовы exec ("") со случайно сгенерированным кодом
    <hyc> на самом деле это потребует выполнения JS, обойти это невозможно
    <gmaxwell> знаменитые последние слова
    <hyc> количество перестановок просто астрономическое, есть шаблон для всего этого?
    <hyc> независимо от того, какую именно оптимизацию мы получим, требуемая схема будет намного тяжелее, чем ASIC Cryptonight
    <hyc> большая площадь микросхемы, более высокая мощность, более низкий коэффициент полезного действия
    <hyc> как вы собираетесь оптимизировать инструкции? вам понадобится CPU предсказатель ответвлений
    <endogenic> не уверен, что ваши рассуждения верны, когда у нас есть крупные игроки со стимулом и возможностями для производства JS чипа
    <hyc> endogenic: это все равно победа
    <endogenic> я не эксперт в этом ..
    <andytoshi> hyc: это действительно звучит так, что люди нашли легкие пути
    <endogenic> это еще не победа, если у нас нет быстрого способа изменить это, когда появится следующая угроза
    <hyc> если JS чип становится коммодитизированным, выигрывают все
    <andytoshi> и дешево идентифицируемые слабые подмножества
    <hyc> andytoshi: Я не понимаю, как анализ кода может быть значительно дешевле
    <hyc> посмотрите на современное состояние инструментов анализа кода, таких как Coverity или Veracode. Они изобилуют ложными срабатываниями и поддельными результатами.
    <hyc> и это всё только для языка, как C, с небольшим набором ключевых слов и семантики
    --> doubletwist25 (~doubletwi@41.218.203.121) подключился к#monero-research-lab
    <andytoshi>
    верно, вы не заботитесь о ложных негативах (в пределах разумного), и при всём этом вы не заботитесь о глубине анализа, который вам понадобится для проведения полезного статического анализа для логических ошибок
    <andytoshi> также C в основном UB
    <andytoshi> так что для меня не сразу понятно, что это будет легче, чем JS
    <hyc> по сути, вы говорите о написании декомпилятора для преобразования сгенерированного синтаксического дерева в макрооперации
    <hyc> и каким-то образом настройка таблицы поиска, которая может направлять поток к различным обработчикам шаблонов
    <-- valentinbuza_ (~valentinb@unaffiliated/valentinbuza) вышел (Время бездействия 252 секунды)
    <hyc>
    это все равно будет интерпретатором для токенизированного языка, вы просто говорите, что некоторые из токенов могут быть макромасштабными
    <andytoshi> да, и если вы можете сделать это за 0,1% времени, необходимого для фактического выполнения кода, но это работает только в 0,1% времени, тогда всё настроено
    <andytoshi> а остальные 99,9% времени вы просто отвергаете однократно используемое число
    <hyc> это самоубийство, так как выигрышное однократно используемое число с большей вероятностью будет на 99,9% в последовательности кода, которую вы отклонили
    <gmaxwell> andytoshi: именно так я и сломал свой POW
    <andytoshi> hyc: нет «победившего однократного используемого числа», только некоторая доля одноразовых номеров, которые приводят к действительному
    <gmaxwell> hyc: «победившее однократно используемое число» звучит как общее фундаментальное недоразумение в POW.
    <-- doubletwist25 (~doubletwi@41.218.203.121) вышел (Время бездействия 272 секунды)
    <hyc>
    конечный результат должен иметь XXXX байтов ниже, чем сложность
    <gmaxwell> Майнинг - это «найти иголку в стоге сена», а это решение «найти самую короткую соломинку в куче соломы»
    <gmaxwell> hyc: таких решений бесконечное множество
    <andytoshi> количество пропущенных однократно используемых чисел будет в 999 раз больше, чем число одноразовых номеров, которые я не пропущу
    <andytoshi> но это нормально, потому что я трачу намного меньше времени на пропущенные
    <gmaxwell> Я бы посоветовал прочитать статью по equihash’у с описанием того, что нужно, чтобы сделать хороший POW (не то чтобы equihash’у это удалось реализовать, авторы просто хорошо понимали, что требуется, но у них были неверные представления о том, как работает конечное оборудование)
    <hyc> для хэша блока есть только небольшое количество допустимых одноразовых номеров
    <hyc> хм, я читал про equihash, да.
    <gmaxwell> hyc: процесс майнинга не просто меняет диапозон однократно используемого числа, в противном случае он будет зависать и никогда не будет решен
    <gmaxwell> Если вы не нашли решения при поиске в одноразовых номерах, вы просто переходите к более большому диапозону
    <hyc> это верно, что для данного хэша блока, не может быть решения
    <andytoshi> вы имеете в виду "для данного заголовка блока без одноразового номера"
    <hyc> да
    <andytoshi> но вы можете изменить другие части заголовка блока
    <gmaxwell> поэтому кардинально неправильно думать в разрезе термина "только небольшого числа действительных одноразовых номеров"
    <andytoshi> например, bitcoin, где фактическое поле "действительных одноразовых номеров" составляет всего 32 бита
    <hyc> вы можете изменить временную метку и изменить сочетание txns, используемые для генерации заголовка
    <moneromooo> Я думаю, что вы можете просто помахать руками и не особо заморачиваться о том, что что-нибудь изменится, и потом назвать это "однократно используемым числом". Достаточно близко по смыслу и не коверкает суть теории
    <gmaxwell> moneromooo: в точности!
    <hyc> вы не знаете, что вам нужно что-то изменить, если вы уже не исчерпали одноразовое пространство
    <gmaxwell> hyc: конечно, и что?
    <gmaxwell> hyc: moneromooo, дело в том, что поскольку вы можете изменить другие параметры, одноразовое пространство фактически не ограничено. Да, вы разделяете его на две части, но с точки зрения анализа это не имеет большого значения.
    <moneromooo> О, сгенерированная программа зависит от фактического одноразового числа, верно? Таким образом, вы можете сохранить то же самое одноразовое число, а затем перебирать другие вещи (например, non-nonce tx_extra garbage).
    <gmaxwell> кроме того, обновление одной части несколько дороже, но поскольку вы будете выполнять огромное количество проверок для быстро обновляемой части, амортизируется, как правило, более дорогая часть.
    <moneromooo> Таким образом, вы можете выполнить анализ программы один раз
    <hyc> moneromooo: сгенерированная программа зависит от всего заголовка, включая одноразовое число
    <hyc> вы не можете повторно использовать любой похожий анализ
    <moneromooo> OK, просто игнорируйте меня ^_^
    <hyc> заголовок с одноразовым номером хэшируется, результат хеширования передается PRNG
    <hyc> Equihash также требует памяти, которая является быстро развивающимся решением. Технологии памяти продвигается гораздо быстрее, чем скорости процессора
    <hyc> Это обреченный подход с самого начала
    <gmaxwell> Я согласен, что это плохая идея, но причина, по которой вы даете это суждение, своего рода помешательство: "технологии памяти продвигается гораздо быстрее, чем скорости процессора", просто исторически сложилось все совсем наоборот... память развивалась намного-намного медленнее, чем скорости процессора.
    <hyc> емкость удваивается быстрее, чем скорость процессора
    <gmaxwell> Эти функции не являются «ресурсоемкими по емкости», а скорее, ресурсоемкими по пропускной способности
    <hyc> на самом деле скорость процессора в течение последних нескольких лет оставалась неизменной, и сейчас она снижается из-за уязвимостей
    <hyc> если вы уменьшите используемое пространство памяти, работа ускорится более чем в 2 раза
    <hyc> если вы уменьшаете требуемое пространство...
    <gmaxwell> Кроме того, (xkcd386) самая дешевая память тоже прогрессирует очень медленно...
    <gmaxwell> (по крайней мере, в последние годы)
    <gmaxwell> https://people.xiph.org/~greg/temp/memoryprices.png < Я сделал тебе график.
    <gmaxwell> это последнее десятилетие
    --> valentinbuza_ (~valentinb@unaffiliated/valentinbuza) подключился к #monero-research-lab
    --> sfhi (~sfhi@1e.94.7a9f.ip4.static.sl-reverse.com) подключился
    к #monero-research-lab
    <hyc>
    хммм. Я думаю, что это результат физически уничтоженных заводов, а не технологических тенденций.
    <gmaxwell> прогресс на вычисление/$ был НАМНОГО лучше. ... это выглядит примерно так, как если вы зададите для вычисления/$ логарифмический масштаб вместо линейного, как на этом графике
    <andytoshi> memory_speed_ прогрессировала за период времени, когда $/мегабайт оставался неизменным
    <gmaxwell> andytoshi: да, но улучшение пропускной способности все еще шутка по сравнению с компьютерными улучшениями.
    <hyc> вычислительная стоимость: http://image.slidesharecdn.com/jsu-...unch-of-other-things-18-638.jpg?cb=1454723352
    <hyc> стоимость хранения: http://image.slidesharecdn.com/jsu-...unch-of-other-things-19-638.jpg?cb=1454723352
    <andytoshi> я больше пытаюсь оправдать все деньги, которые я потратил на оперативную память, чем пытаюсь внести свой вклад в разговор ;)
    <hyc> LOL
    <gmaxwell> главное заключается в том, что ограничения пропускной способности памяти - это не столько фундаментальное свойство памяти, сколько свойство фундаментальных характеристик источника ввода-вывода для чипа. Поместите память в чип, и пропускная способность возрастет в 100 раз без каких-либо других технических улучшений
    <hyc> стоимость хранения снижается на 38% в год по сравнению с вычислительной мощностью 33% в год
    <hyc> Я думаю, что никто не сказал этим парням о HBM
    <gmaxwell> Хранение= RAM, хотя, да, сверхурочные затраты на хранение исторически улучшились намного лучше, чем вычислительная мощность
    <-- muff1nman (~irccc@75-166-29-132.hlrn.qwest.net) вышел (Время бездействия 180 секунд)
    --> el00ruobuob_[m] (~el00ruobu@blabour.fr) подключился
    к #monero-research-lab
    --> thelinuxguy7 (~thelinuxg@174-17-128-182.phnx.qwest.net) подключился
    к #monero-research-lab
    <gmaxwell>
    hyc: eldyentyrell, размещенный на github zcash, в основном указывает на пакет, прикрепленный к ram, tsvs и т.д… но они проигнорировали его
    <hyc> удивительный ответ...
    <gmaxwell> это то, что вы получаете, когда сами назначаете экспертов по узким областям разработки чего-то подобного, без участия тех людей, которые были бы ответственны за его оптимизацию (инженеров)
    <gmaxwell> с тех пор комментарий был удален, в противном случае я бы дал ссылку на него.
    --> muff1nman (~irccc@75-166-29-132.hlrn.qwest.net) подключился к #monero-research-lab
    <hyc>
    кстати, Andytoshi, может быть, пришло время снова разориться на еще один DRAM https://press.trendforce.com/press/20180926-3163.html
    --> midipoet (uid316937@gateway/web/irccloud.com/x-phbbtmjglhzxrinb) подключился к #monero-research-lab
    <gmaxwell>
    В любом случае ребята из equihash понимали, что нужно, но не понимали, с каким оборудованием им предстоит работать... это лучше, чем большинство других проектов, которые потерпели неудачу в обеих областях
    --> jwheare10 (~jwheare@85.97.10.51) подключился к #monero-research-lab
    <andytoshi>
    hyc: моя дилемма заключается в том, что 14-дюймовые ThinkPad-ы имеют материнские платы, которые ограничены 32Gb уже в течение примерно 6 лет
    <hyc> Да, я это подметил. Я сам приглядывался к a485
    <gmaxwell> andytoshi: для компьютеров на базе xeon потребуется все 64 :p
    <-- thelinuxguy7 (~thelinuxg@174-17-128-182.phnx.qwest.net) вышел (Удаленный хост прервал соединение)
    <knaccc>
    Lenovo’s ThinkPad X1 Extreme: шесть ядер, GTX 1050 Ti, 64GB RAM и весит почти 2 килограмма
    <hyc> gmaxwell: так вы верите, что память - все еще жизнеспособный подход к проблеме? принимая во внимание встроенную память?
    <gmaxwell> hyc: Я думаю, что этого никто не знает. В общем, память можно рассматривать как конкретный случай «предоплаты по стоимости», и я думаю, что есть хорошие аргументы в пользу того, почему «предоплата по стоимости» является плохим решением как для POW, так и для случая с защитой паролем (хоть и совсем по разным причинам).
     
  2. АВТОР
    АТ
    Unholy

    Unholy Active Monerano

    Регистрация:
    6 мар 2018
    Сообщения:
    61
    Симпатии:
    6
    <gmaxwell> По сути, при предельной стоимости вы платите много, чтобы купить атаку, но амортизированная стоимость после этого низкая. Так что это только благоприятствует первопроходцам
    <gmaxwell> Доказательство покупки, а не доказательство работы :p
    <-- jwheare10 (~jwheare@85.97.10.51) вышел (Удаленный хост прервал соединение)
    <hyc>
    казалось бы, но это правда, даже если бы мы были в мире, где всем управляет только процессор
    <hyc> первопроходцы просто скупают большинство мощностей процессоров
    <gmaxwell> Я думаю, что попытка прировнять все только cpu в основном является проигранной... с одной стороны, это огромная субсидия на патентные права на работу процессора, а не на материальные затраты, а это означает, что какой-нибудь хакер, будет иметь преимущество. Кроме того, независимо от того, какова функция «только для процессора», кто-то может создать специальный процессор для майнинга, который удаляет ненужные части (например, шины pcie) и использует изрядно меньше энергии
    <gmaxwell> например, в Силиконовой долине. В лучшем случае вы могли бы сделать оптимизированное оборудование только в 2 раза энергоэффективнее и в 10 раз эффективнее по производительности, но в разрезе майнинга (по крайней мере) такое оборудование в конечном итоге будет вытеснено из бизнеса.
    <gmaxwell> (Пираты или сами компании, конечно)
    <knaccc> разве экономия масштаба не влияет на такие вещи?
    <hyc> Я думаю, это слишком пессимистично. На автономном сервере, предназначенном для майнинга, ALU будут заняты 100% времени, а внешние шины будут простаивать
    <gmaxwell> Я гораздо больше надеюсь на полезность причудливых функций именно для защиты паролей, чем для майнинга. Я полагаю, что для майнинга делать специализированные вещи довольно "просто", 2x/10x будут более эффективными на коротком промежутке, чем в долгосрочной перспективе, но для безопасности паролей это отличное решение
    <hyc> специальному майнинговому чипу по-прежнему нужен канал связи для ввода и вывода данных.
    <gmaxwell> hyc: Я не знаю о других примеров, но бездействующие контроллеры pci-e в epyc потребляют около 4 Вт. (в качестве примера)
    <hyc> этот канал связи будет иметь примерно такое же использование, как и шины на сервере.
    <gmaxwell> майнинговый чип нуждается в консервной банке и веревке с мылом для ввода и вывода данных. Это несравнимо с гигабайтной шиной :)
    <hyc> конечно, но эта гигабайтная шина включается только на микросекунду
    <knaccc> что может пойти не так, если мы попробуем идею hyc для нескольких циклов обновления Monero? кажется, что у этой идеи большой потенциал
    <hyc> самое худшее, что может случиться через несколько месяцев – это новый ASIC
    <knaccc> да, и поэтому мы возвращаемся к чему-то другому, никакого реального ущерба
    <knaccc> или сделать его гибридным, так что каждый четвертый блок требует идеи hyc, а затем увеличивается в зависимости от реакции
    <hyc> ущерб заключается в том, что у нас не будет запасного алгоритма для следующего обновления после этого
    <moneromooo> Хуже всего то, что кто-то найдет скрытый или потайной подход к этому и поработит 99% сети
    <hyc> невозможно заполучить 99% и не наследить...
    <gmaxwell> knaccc: необоснованный аргумент
    <gmaxwell> один из недостатков в том, что такие люди, как я, начинают думать, что monero больше похож на ethereum с точки зрения архитектуры (пилим сук, на котором сидим)
    <moneromooo> Да, мы обязательно заметим. И моя точка зрения заключается в том, что у производителя ASIC устройств будет стимул сохранить сеть "без видимых изменений"
    <knaccc> ахахаха, пилить сук, отличная формулировка
    <gmaxwell> (FWIW и ethereum предложил аналогичный POW, когда RNG выбрал случайную цепь, и они отказались от нее после того, как было показано, что она будет сломана из-за тех же планируемых оптимизаций)
    <hyc> Вы говорите о чем-то до ProgPoW?
    <gmaxwell> да, задолго до их запуска
    <hyc> можете ли вы мне дать ссылку на это обсуждение?
    <gmaxwell> оригинальный хеш построил случайную арифметическую схему над 256-битными целыми числами
    --> Trieste24 (~Trieste@mx-ll-180.183.136-35.dynamic.3bb.co.th) подключился к #monero-research-lab
    <-- Trieste24 (~Trieste@mx-ll-180.183.136-35.dynamic.3bb.co.th) вышел (Удаленный хост прервал соединение)
    <gmaxwell>
    кажется, они исчезли из многих публичных документов, вы можете увидеть это на данной странице : http://nbviewer.jupyter.org/gist/anonymous/cb53d06b837be97ebe32
    <hyc> спасибо
    <gmaxwell> (который показывал изначально 64 бит, но я уверен, что это было 256 бит, и в какой-то момент они просто изменили его)
    <gmaxwell> да, это должно быть более поздняя версия, в первой версии были инструкции, такие как div и mod.
    <endogenic> "самое худшее, что может случиться через несколько месяцев – это новый ASIC" < вы также потеряете много месяцев на развитие ASIC сопротивления, в то время как простые майнеры будут умолять вас о переключении назад
    <hyc> текущий алгоритм вообще не является устойчивым к ASIC, это просто изменения, чтобы вывести из строя существующие ASIC
    <hyc> эта «случайная схема» довольно тривиальна
    <gmaxwell> Он является общим для всех вычислений, поэтому я не думаю, что вы можете сказать, что это менее "тривиально", чем что-либо еще. Дополнительные сложности могут возникнуть, только если мы сами запутаемся.
    <knaccc> В конце концов, я предсказываю, что все правительства мира выдадут каждому гражданину уникальную асимметричную пару ключей, опубликуют список всех выпущенных ключей, чтобы их количество было известно, и тогда нам больше не будет нужен сам принцип доказательства работы
    <hyc> Разница между теорией и практикой - в теории алгоритмы X и Y могут быть сопоставимы, в то время как на практике одно гораздо легче реализовать, чем другое
    <gmaxwell> knaccc: привет, Майк Херн
    <knaccc> хаха, о, это то, на что он тоже надеется
    <gmaxwell> knaccc: «доказательство паспорта» было то, что он хотел реализовать
    <hyc> он библейский толкователь из книги откровений?
    <knaccc> интересно, спасибо, я буду гуглить
    <hyc> что бы победить все анонимные криптовалюты
    <gmaxwell> hyc: Если вы посмотрите на X и скажете, что это тривиально, но затем мы смотрим на Y и понимаем, что Y доказуемо идентичен к X, не должно ли вас беспокоить, что Y получается также аналогично тривиален?
    <knaccc> hyc: пара ключей будет использоваться только для "майнинга", а не в качестве ключей кошелька
    <hyc> да, это верный момент
    <hyc> Я бы сказал, что поскольку входные данные в конечном итоге одинаковы, диапазон перестановок также может быть одинаковым
    <endogenic> у monero была бы возможность узнать что-то о приближающейся опасности ASIC на том моменте, когда мы столкнулись с проблемой ручной настройки алгоритма
    <hyc> Я имею в виду, мы знаем, что PRNG не могут создавать энтропию, так что все может оказаться просто бессмысленным оформлением пустых витрин
    <hyc> оборотная сторона аргумента в том, что существующие алгоритмы не смогли выдавить столько перестановок, сколько могли бы
    <hyc> если мы можем сказать, что эти 2^256 могут быть уменьшены до 2^32 уникальных шаблонов, мы все равно создадим проблему, которая будет намного сложнее для разработчика ASIC
    <endogenic> насколько это будет сложнее для нас?
    <hyc> с процессором? это не будет большим недостатком
    <endogenic> но какие изменения в него можно внести?
    <gmaxwell> hyc: Я совершенно с этим не согласен
    <gmaxwell> Разработчик ASIC будет смотреть на 2^32 уникальных шаблона и находить большой подкласс, который довольно дешево будет реализовать, а затем просто заставлять свой чип преобразовывать работу
    <hyc> мы могли бы смоделировать это прямо сейчас, изменить случайный JS Impl и прервать его на 90%
    <gmaxwell> hyc: и будет в 1000 раз быстрее на оставшихся 10% ...
    <endogenic> ^
    <hyc> конечно, мы можем заменить его с 10 наносекунд сна
    <hyc> хм, нет, нам все еще нужно, чтобы он выдал действительный вывод для случаев, которые он фактически выполняет
    <hyc> вместо этого нам пришлось бы замедлить обычную реализацию
    <hyc> но это бы хорошо работало, мы также можем изменить коэффициент задержки и посмотреть, где находится точка безубыточности

    Источник: Logs for the Research Lab Meeting Held on 2019.02.09

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

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