Перевод Обновление от Шурэ, конец ноября (2017)!

Тема в разделе "Статьи", создана пользователем Mr. Pickles, 8 дек 2017.

  1. Mr. Pickles

    Команда форума Модератор Редактор

    Регистрация:
    11 сен 2017
    Сообщения:
    251
    Симпатии:
    71
    Привет всем! Несколько дней назад Саранг разместил свое обновление, тем самым дав сообществу возможность изучить его работу. Я надеялся закончить Multisig до конца месяца… так что к тому моменту я уже задержался с написанием этого обновления… но, кажется, я уже где-то в двух днях и неделе от этого.

    Объявления MRL


    • Встречи.
    Мы проводим еженедельные встречи по понедельникам в 17:00 UTC. Записи скоро появятся на моей странице GitHub. Обычно мы чередуем «приемные часы» с «исследовательскими встречами». Нам бы хотелось, чтобы в приемные часы члены сообщества заходили и могли задавать свои вопросы. Поэтому, если ничего не выйдет из-под контроля, мы рассматриваем возможность выделения freenode-канала в такие часы.

    • Конкурс на замену POW (POW-Difficulty Replacement Contest).
    В декабре я планирую формализовать «идею» FFS и объявить многоэтапный конкурс на поиск возможной замены нашему доказательству работы (proof of work, POW). Крайний срок для представления результатов на первом этапе составит 3 или 6 месяцев. Лично мне бы хотелось, чтобы премия за FFS имела неограниченный размер. Если сообщество окажется предельно щедрым, мы легко сможем собрать достаточно большую сумму, чтобы привлечь серьезный интерес представителей сообщества во всем мире.

    Доказательство работы Bitcoin использует безопасный алгоритм хеширования SHA256, позволяющий найти случайные коды (nonces), обеспечивающие хеши с достаточно малыми дайджестами (по меркам сложности Bitcoin). Наше доказательство работы использует алгоритм CryptoNight, позволяющий найти случайные коды, генерирующие хеши с достаточно малыми дайджестами, но уже по меркам сложности CryptoNote. Победителем совершенно не обязательно станет доказательство работы. На данный момент у меня примерно следующие мысли.

    Все представленные на рассмотрение варианты должны быть публичными. Предпочтение будет отдаваться тем вариантам, которые будут минимизировать стимул к централизованному майнингу (или будут максимально отталкивающими с этой точки зрения). Также предпочтение будет отдаваться элегантным решениям. Преимущество будут иметь варианты с доказуемым соответствием, желаемым свойствам (например, как в случае POW для Bitcoin, так и в случае с POW для Monero, необходимое и достаточное сетевое условие для этих алгоритмов, связанное с возможностью создания блоков в процессе Poisson). Предпочтение будет отдаваться решениям, которые оказывают наименьшее влияние на среду. Мне бы хотелось иметь как можно больше идей относительно системы оценки вариантов на первом этапе. Особенно в том случае, если премия будет предполагать выплату значительной суммы.

    Подробности второго этапа будут объявлены вместе с победителями первого. Премиальный фонд будет разблокирован после того, как совет жюри определит победителя. MRL и Monero Core должны быть представлены в совете жюри, а также в него должен входить, по крайней мере, один независимый судья, не связанный напрямую с Monero Project, как Питер Тодд (Peter Todd) или Тим Руффинг (Tim Ruffing), или кто-то другой в этом роде. Но пока это просто идея. Если она не понравится сообществу, то мы можем ничего и не делать.

    Вот краткое изложение сделанного за ноябрь.


    • Технология Multisig.
    Работа практически завершена. Знаю, знаю — это ее постоянное состояние. Мы недавно пришли к пониманию важности тщательной и формальной проверки правильности наших схем перед их окончательной реализацией. Multisig является особым случаем, поскольку при его простой и бесхитростной реализации, может случиться так, что появится возможность раскрытия информации об участниках транзакций.

    Сегодня я заканчиваю работу над проверочным ключом, а работу над сигнатурами планирую завершить завтра-послезавтра. Затем я передам результаты moneromooo и luigi, чтобы убедиться в том, что мое описание их кода является достаточно точным. После этого работа будет передана Сарангу, который произведет окончательную проверку перед публикацией. Надеюсь, что мы все успеем до конца месяца. Вплоть до воскресного вечера я буду работать над завершением проекта. Копия документа будет представлена сообществу настолько скоро, насколько это будет возможно (старая версия выложена на моей странице на Github), сразу после того, как будут проведены некоторые проверки и будут внесены соответствующие изменения.

    Официальный документ по Multisig будет разбит на две части: одна будет посвящена независимой технической экспертизе кольцевых мультиподписей, а другая станет Стандартом Monero. Об этом позже…

    • Связность графов и амортизация RTRS RingCT.
    Вы можете спросить: «Что? Я думал, мы же отложили вопрос RTRS RingCT». Ну, я по-прежнему размышляю над амортизацией сигнатур. Я думаю, что вполне возможно (хотя и не обосновано), чтобы пользователи включали амортизированные подписи после нахождения новых блоков. Это бы позволило им ссылаться на амортизированную подпись для облегчения процесса верификации, но и здесь могут возникнуть определенные недостатки. Но что более примечательно, я беседовал с Тимом Руффингом, одним из авторов документов по RTRS RingCT, он считает, что ему известно решение нашей проблемы «связности графов» MLSAG и RingCT. В настоящее время мы пытаемся сделать так, чтобы один получатель не использовал более одной кольцевой подписи. Это позволит избежать связывания отдельных выходов на основе построения этих кольцевых подписей. Руффинг уверен в том, что RTRS RingCT можно подправить таким образом, чтобы в векторе обязательств доказывалось несколько обязательств. Это бы позволило вычислять и проверять одну RTRS RingCT для каждого использованного выхода.

    Как только все подробности будут проверены, мною будет написан документ, копия которого будет представлена сообществу. Если все сработает, конечно.

    • Последствия использования доказательств Bulletproofs.
    В своем последнем обновлении, вышедшим в конце месяца, я намекал на экспоненциально растущие временные и трудовые затраты на RTRS RingCT. За счет сэкономленных, благодаря доказательствам Bulletproofs, скорости и месту, стала осуществимой реализация RTRS RingCT. Благодаря экономии времени на верификацию при использовании доказательств Bulletproofs, мы можем ослабить требования к времени верификации сигнатур. Это уравновешивает немного большее время, которое затрачивается на верификацию RTRS RingCT. Решение проблемы, которая сводится к вопросу о том, какой размер колец мы получим в итоге, включает в себя некоторое моделирование и решение некоторых проблем, связанных с линейным программированием (линейным программированием или линейной оптимизацией, областью прикладной математики с анахроничным названием, связанной с оптимизацией логарифмических проблем… дополнительную информацию можно найти здесь).

    Таким образом, мы вставим доказательства Bulletproofs в Monero без особых усилий и потерь, а затем рассмотрим пути перехода на RTRS RingCT.

    • Стандарты Monero.
    На данный момент у нас нет понятно и упорядоченно изложенных принципов работы Monero, полного описания различных примитивов и того, как они взаимодействуют. Саранг и я начали работу над некоторыми стандартами Monero, которые похожи на оригинальные Стандарты Cryptonote (более полная информация находится здесь). Для каждого стандарта, начиная с нашей хеш-функции и выше, нами будет описано обоснование выбора Monero (полное со ссылками), а также будет составлен список возможных аналогов. Например, в нашем стандарте RingCT для Monero (Monero RingCT Standard) должна быть приведена схема RingCT, описанная shen, которая, по существу, является кольцевой подписью с линейными комбинациями ключей с обязательствами суммы. В разделе «возможных аналогов» в качестве опций нами были бы описаны как схема RTRS RingCT, так и вдвойне эффективная технология zk-snark.

    Написание этих стандартов может потребовать не так уж и много времени. Но это будут уже рабочие, «живые» документы, которые будут меняться по мере того, как мы будем изменять сами протоколы. А пока будущим исследователям значительно проще вступить в MRL и начать с того места, на котором остановились их предшественники.

    • Иерархические ключи просмотра.
    Благодаря алгебре, мы можем использовать вычислительные одноразовые ключи (схема подадресов некоторым образом работает неадекватно с ключами просмотра), что позволяет пользователю иметь один ключ просмотра для множества кошельков. Подобным образом, мы можем разбить ключ просмотра на несколько составляющих, где каждый поднабор таких частей можно будет использовать для выдачи ограниченного доступа к просмотру кошелька. Получатель сможет сделать запрос, чтобы отправитель использовал определенную базовую точку своего ключа транзакции, от которой различные поднаборы частей ключа просмотра будут давать доступ к транзакциям с различными базовыми точками в их ключах транзакций. Это исследование не уровня протокола, а уровня кошелька. Необходимо только то, что пользователь опционально указал базовую точку.

    Другими словами, иерархические ключи просмотра являются скрытой характеристикой нашей схемы одноразовых адресов, которая до этого никак не развивалась. Эта работа имеет довольно низкий приоритет относительно других разрабатываемых проектов. Пользователям дается многоуровневое средство контроля законности их действий, но Стандарты Monero еще окажут долгосрочное влияние на разработку и исследования, проводимые с Monero.

    • Критика.
    Недавно Monero подверглась некоторой критике за нашу хеш-функцию. Хотелось бы кратко ответить на эту критику.

    Во-первых, я уверен в том, что определенная часть критики связана с путаницей между Keccak3, SHA-3 и Keccak. Мы никогда не заявляли о том, что используем SHA-3 в качестве нашей хеш-функции. Мы использовали только хеш-функцию Keccak3, которая является унаследованным выбором из исходно кода CryptoNote. Многие разработчики путают эти две функции, но именно на хеш-функции Keccak3 основана функция SHA-3. В частности, sponge-конструкция Keccak может использоваться для адаптации невероятного количества примитивов, каждый из которых может быть справедливо назван «Keccak». Как Keccak3, так и SHA-3 имеют конструкцию Keccak. Это можно рассматривать как вопрос тонкостей терминологии, но это важно, поскольку значительная часть наших критиков утверждает: «Смотрите, они не используют SHA-3!»

    Во-вторых, я так же уверен в том, что часть критики основана на нашем выборе библиотеки, что, на мой взгляд, важно, так как библиотека работает, как заявлено. В данном случае, в соответствии с документацией Keccak3, наша хеш-функция является действительной реализацией Keccak3. Наиболее важным объектом, который подвергается критике, по-моему, является наш выбор в качестве хеш-функции, предшествующей SHA-3, функции Keccak3. В ходе соперничества с SHA, функция Keccak3 была подвергнута очень тщательному анализу. Таким образом, Keccak3 является хорошо проверенной функцией, но, тем не менее, она не стала международным стандартом. Сообщество разработчиков криптовалют не доверяет стандартам и, вероятно, поступает здраво. Однако в данном случае это означает, что наш выбор хеш-функции едва ли найдет общую поддержку в проверенных библиотеках в будущем. Более того, так как функция SHA-3 является международным стандартом, она подвергнется серьезному тестированию в ближайшие десятилетия, то есть получит преимущество, которого Keccak3 не видать.

    В прошлом месяце, после некоторого обсуждения, мы внесли некоторые изменения в наш выбор PRNG для Monero, чтобы обеспечить соответствие PRNG для Bitcoin. После этого развернулась некоторая дискуссия, развернутая anonimal, относительно выбора PRNG. В MRL мы делаем все возможное, чтобы помочь Core Team в определении относительных затрат и преимуществ перехода на библиотеку, подобную like crypto++, а также мы уверены, что вся эта критика попадает в ту же категорию. Мы собираемся решить все эти вопросы и реализовать официальные рекомендации в составе вышеупомянутых Стандартов Monero. Прошу прощения за использование слова «вышеупомянутые».


    Дела, в которых не наблюдалось особого продвижения:

    1. Образовательная программа;
    2. SPECTRE;
    3. Дорожная карта противодействия ASIC;
    4. Отмена транзакций (refund-транзакции).
    Большая часть этих проектов была приостановлена для того, чтобы завершить работу над Multisig.

    Что касается образовательной программы, я связался с некоторыми сотрудниками кафедр математики/вычислительной техники нескольких университетов, находящихся недалеко от меня, но пока не могу сообщить ничего обнадеживающего. Я хотел организовать все локально (относительно моего местонахождения), что все бы упростило, но это кажется маловероятным. Неважно, какой уровень энтузиазма продемонстрирует найденная нами кафедра — привлечение к работе членов факультета, организация учебного процесса для студентов, решение вопросов финансирования, разработка логистики для доставки учителей/лекторов/докладчиков из пункта A в пункт B, размещение студентов и т.п. — все эти вопросы можно будет решить не раньше, скажем, июля. А в некоторых учебных заведениях первый семестр начинается уже в середине августа. Поэтому, я думаю, что лето 2019 года — разумное время для организации первой Летней школы Monero… и было бы реально здорово именно так закончить двухлетний период после защиты диссертации!


    Планы на декабрь.

    Я собираюсь закончить работу с Multisig, а затем завершить проверку zk-lit, которую мы проводим вместе с Джеффри Кеснеллем (Jeffrey Quesnelle) — отправим в корзину два мяча подряд. Остальное время в декабре я собираюсь посвятить:
    1. Поиску путей использования доказательств Bulletproofs и настройке RTRS RingCT;
    2. Чтению работы по технологии zk-stark, где описывается ее важность для Monero;
    3. Началу работы над Стандартами Monero, с учетом критики в адрес нашей хеш-функции, PRNG и т.д.
    Спасибо всем еще раз! Это невероятная возможность! В этом сообществе полно умных людей, каждый день решается какая-то задача, и на данном этапе жизни я бы не хотел еще чего-то более интересного. Я надеюсь, что в результате моей работы Monero станет лучше.

    https://en.wikipedia.org/wiki/Linear_programming
    https://cryptonote.org/cns/cns006.txt

    Источник: Surae's (me) end-of-November (2017!) update.


    Перевод:
    Mr. Pickles (@v1docq47)
    Редактирование:
    Agent LvM (@LvMi4)
    Коррекция:
    Kukima (@Kukima)
     
    #1 Mr. Pickles, 8 дек 2017
    Последнее редактирование: 8 дек 2017
  • О нас

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