Журнал встречи исследовательской лаборатории 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 <-- 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, так и для случая с защитой паролем (хоть и совсем по разным причинам).
<gmaxwell> По сути, при предельной стоимости вы платите много, чтобы купить атаку, но амортизированная стоимость после этого низкая. Так что это только благоприятствует первопроходцам <gmaxwell> Доказательство покупки, а не доказательство работы <-- 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)
