23/06/2019
Пол Шапиро — ветеран в области разработки программных приложений и пользовательских интерфейсов (UI). Его основная работа касается взаимодействия, проектирования продукции и качества кода. Он является генеральным директором и ведущим разработчиком MyMonero, контрибьютором кодовой базы Monero, проживает в Нешвилле, штат Теннесси, где занимается скалолазанием и своим садом.
Аннотация
В рамках этого выступления будут рассмотрены подходы, используемые различными основными и сторонними интеграторами базового кода Monero, такими как MyMonero, Cake Wallet, Monerujo, официальный GUI Monero, Monero Simplewallet и новый сервер Monero Lightwallet. Также будет говориться о компромиссах, связанных с различными подходами, и будут предложены направления дальнейшей работы. Все вышеуказанные интеграторы совместно работают с одним кодом и должны делать это более активно. Monero как бесплатный и открытый (FOSS) проект является относительно уникальным с точки зрения своего развития и разработки, поэтому для него характерны уникальные проблемы, которые также будут рассмотрены, равно как и соответствующие альтернативы.
Стенограмма:
Меня зовут Пол Шапиро. Я являюсь генеральным директором MyMonero, компании-разработчика программного кошелька. Кроме того, мы также делаем свой вклад в сам проект Monero, в первую очередь, в форме начальной факторизации качественных улучшений кода. Мы также принимали участие в работе над сервером лёгкого кошелька для кодовой базы Monero. И я расскажу ещё немного об этом. По-моему, это кликер. У всех бывают проблемы с кликером, продолжим. Начнём с таблицы? Мне кажется, это таблица Фарадея. Немного подробнее расскажу о Monero. Monero является свободным и открытым проектом. За ним не стоит какая-либо корпорация или один ведущий архитектор. Кодовая база Monero, которую упоминали несколько других выступавших, создана неизвестными авторами, а комментарии были намеренно удалены, или с ними произошло нечто в этом роде. Многие компоненты также были позаимствованы из неизвестных источников. Одним из таких компонентов является библиотека, известная как epee и принадлежащая к классу утилит. В ней также используются эти странные специализированные форматы wire. Процесс разработки децентрализован, и в нём принимают участие сотни контрибьюторов со всего света, так что это довольно внушительный открытый проект. Как результат, довольно сложно поставить проект на паузу, просто сказав: «О’Кей, ребята. Прекращаем писать код. Давайте всё упростим, пересмотрим общую архитектуру и решим, какой она должна быть или какими должны быть общие требования к проекту», поскольку это естественная часть процесса написания программного обеспечения. Приходится периодически пересматривать всё и говорить: «О’Кей, давайте займёмся переработкой, опираясь на описание известной проблемы, а не на аморфное, постоянно меняющееся со временем описание».
Сложность существующего кода сильно затрудняет его расширение и интеграцию. Лично я вижу тысячи оснований, которые мне нужно охватить за короткий отрезок времени. 15 минут, по-моему. Оказывается, немного больше. Как бы то ни было, я постараюсь успеть пройтись по всем вопросам. В своём выступлении я буду использовать эмодзи. У нас есть унаследованный код. В основном это epee, это утилитная библиотека, включающая в себя тысячи и тысячи вещей, как кухонная раковина, и это печально известный факт, связанный с вашей кодовой базой. Почему, я объясню позже. Само ядро криптовалюты факторизовано относительно хорошо. Не всё названо безупречно, и это приводит к некоторой неэффективности при внесении улучшений или при оптимизации кодовой базы, так как это вопрос читаемости фактических результатов различных вычислений по мере развития. Есть ещё одна вещь под названием Simplewallet. Все знают это CLI приложение. Simplewallet включён в код. Они называют его Simplewallet. И его логической бизнес основой является wallet2. Так что Simplewallet просто великолепен. wallet2 — очень сложная вещь. Начнём с того, что код, изначально унаследованный проектом Monero, был написан самыми различными контрибьюторами. То есть у него было множество авторов.
Это выступление будет касаться того, как MyMonero.com, компания, на которую я работаю (это сетевой кошелёк), взяла базовую архитектуру, которая изначально служила криптографической основой Monero, перепаковала её в подмножество ASMJS, которое похоже на ASM и может работать в браузере, как родное JS. А затем поверх этого был реализован большой объём вендорского JavaScript. И мы сделали это, поскольку, в случае с лёгким кошельком, ключ траты никогда не отправляется серверу, он всегда хранится в браузере.
Таким образом, транзакции создаются в браузере, образы ключей вычисляются в браузере с целью определения той части баланса, которая уже была потрачена, и Monero периодически и в обязательном порядке обновляется раз в шесть месяцев, эти обновления известны как хардфорки, таким образом, повторная реализация всех этих конструкций транзакций и создания образов ключей, а также создания ключей, деривации ключей была необоснованной. Она стала необоснованной со временем, по крайней мере, когда в работе принимают участие один или два человека. Таким образом, нам понадобилось новое решение, и идею можно было сформулировать так: «О’Кей, попытаемся перепаковать всё, используя код C++ при реализации всей конструкции транзакций, как-то так». Но мы наткнулись на стену. Дело в том, что код Monero довольно запутан и сложен, в нём слишком много зависимостей. Итак, в этом выступлении Endogenic, это моё имя онлайн, и оно, очевидно, уже прилипло ко мне, будет жаловаться на качество кода Monero, но не поймите меня неправильно, я безмерно уважаю основных контрибьюторов кода, таких как Moneromooo и ему подобные. И мне бы хотелось выразить им огромную признательность, поскольку они просто коллективная бомба.
Итак, epee. contrib/epee является унаследованной библиотекой. В ней содержится код, я рад, что подготовил заметки по этому вопросу, в ней содержится код для стираемой памяти, регулярные выражения, запись данных, предупреждения компилятора, алгоритмы хеширования, код аутентификации, утилиты на языке «misc», что бы это ни означало, большой объём кода для TCP и HTTP серверов, нам даже не пришлось писать его. Это, вообще говоря, это должно быть то, что мы уже используем — уже существующая, хорошо поддерживаемая библиотека, пригодная к реализации, код Math Helper, профили, такие как профиль времени выполнения операций, шестнадцатеричный код, всё, что касается командной строки, парсинг JSON. Какова точно область применения epee? Если мы посмотрим на набор функций, описанный модулями, какова фактическая область применения epee? Почему всё это реализуется где-то ещё, но не дополняет epee?
Неоднозначность применения приводит к дублированию кода, как в случае с epee и этой другой директорией источника/сериализации. В обоих случаях содержится отдельный код парсинга, каждый был написан для незнакомых нам форматов, и они также отличаются; один предназначен для однорангового протокола, а другие для транзакций и блоков. Я правильно понял? Таким образом, существует другая директория, которая называется src/common. В ней содержится код для DNS, обновления программного обеспечения, файловая система, время выполнения операций, дополнительное время выполнения операций, файл в тысячу строк под названием util, который, как мне кажется, был назван так ради шутки, а почему бы и нет, пул потоков, JSON, ещё JSON, управление паролями, код HTTP соединения, который, между прочим, зависит от вышеуказанного HTTP кода epee, так или иначе, это интернационализация. Итак, что создаёт «общий» код, опять же, когда, например, базовый крипто код Monero можно будет считать универсальным с точки зрения использования другими модулями, как и всё, что можно назвать универсальным? И это большой вопрос — всякий, желающий использовать запутанный код как универсальный, должен импортировать, например, код разрешения DNS, такой как libunbound, который представляет собой зависимость, которую вам совсем не обязательно хотелось бы импортировать, если вы просто пытаетесь применить какую-то криптографию.
Будущее epee и common. epee и common, выражаясь современным языком, «слишком велико, чтобы упасть». Скорее, мы увидим попытку обновить их или сохранить, или что-то ещё, или же их придётся просто разделить. И в данном случае правильно было бы создать код, подобный этому, построить модули верхнего уровня, корневого уровня, которые будут использоваться, или же должна быть выделена определённая проблемная область, вполне конкретный ряд проблем, она должна быть чётко очерчена и использована для определения названия для этого программного модуля, и название должно быть достаточно продумано и описывать всё, что фактически присутствует в модуле. Относительно хорошим примером самодостаточных модулей высокого или корневого уровня могут служить модули исходного кода/RingCT и simplewallet. Безусловно, и у RingCT есть некоторые проблемы с разнообразием названий, но, как бы то ни было, если мы не сделаем этого, код будет дополнять эти двусмысленно названные доменные области или эти пространства имён. И проблема будет только разрастаться. Фактические границы этой области определены недостаточно хорошо, и поэтому всё продолжает невидимо или скрыто разрастаться, учитывая наличие тысяч контрибьюторов, деятельность которых, определённо, не координируется каким бы то ни было образом.
А сейчас я перехожу к действительно забавной части. Итак, wallet2 является тем классом реализации кошелька Monero, который, в сущности, используется каждым существующим кошельком Monero, кроме MyMonero. Он содержит буквально всё, даже то, что мог бы и не содержать, или же то, что могло бы, по крайней мере, стать отдельным вариантом реализации, не содержащим, например, адресной книги и персистентности, а также очень специфических структур выполнения программы. Это полный кошелёк, но он также содержит логические ветви, связывающие его с кодом лёгкого кошелька, написанного другим контрибьютором, выдающимся контрибьютором, совсем недавно. Но мне уже известно, что этот код не используется никем, поскольку в нём имеется утверждение, являющееся обратным условием, логическим условием, каким и должно являться. Если бы кто-нибудь стал использовать этот код, то его бы код рухнул. Поэтому, по сути, его никто даже не поддерживает, и вся эта мёртвая часть кода включена в wallet2. Кроме того, есть и некоторые другие большие вопросы, касающиеся его, такие как ряд структур данных, определённых в wallet2, которые необходимо генерализировать в большей степени в самом коде Monero.
Помимо этого, и это действительно большой вопрос, большинство людей не понимает этого, но фактический формат буквальной сериализации передаваемых транзакций представляется довольно специфическим для структур C++. когда-то в MyMonero, ране, не так давно, но всё же, когда всё это было необходимо реализовать в JavaScript, нам приходилось воспроизводить формат буквально байт за байтом. Нам пришлось делать это вручную, и это не имеет никакого смысла в случае с глобальным протоколом. Таким образом, необходимо произвести эту сериализацию, которая позволит вычислить хеши для подписания транзакций, передаваемых в сеть. Но в Wallet2 есть весь этот многократно используемый код, который просто завязан внутри, то есть, по сути, он специфичен для Monero, но не специфичен для Wallet2, но чтобы использовать его, придётся взять все эти зависимости и весь этот сложный код. Таким образом, имеется код, который все хотят использовать, но который нельзя использовать прямо сейчас без реализации всего Wallet2, вычисления транзакций и периодов ожидания. Если этого не сделать, если все будут использовать разные комиссии, то злоумышленники или те, кто проводит криминалистический анализ, смогут заглянуть в блокчейн и сказать: «Хей! Исходя из того, как вычисляются комиссии, вполне ясно, что все, кто проводит эти транзакции, используют этот клиент». Поэтому все эти вещи должны быть одинаковыми. По той же самой причине: выбор ложных выходов, как и выбор фактических входов при создании колец; сканирование выходов, сканирование блокчейна при помощи ключа просмотра; расширение подадресов (я действительно собираюсь пробежаться по этому, так как тут мы имеем множество факторов, у меня целых три страницы); интеграция демон-программы и сервера, организация сети и парсинг; реализация обмена multisig ключами; интеграция классов счетов для генерирования и управления ключами; парсинг ID платежей; построение ID платежей, несмотря на то, что для этого можно пройтись по криптографии, лежащей в основе; подадрес кошелька; вычисление баланса; статус транзакций; парсинг упорядоченных строк транзакций; подписание транзакций; построение транзакций. И если вы когда-нибудь решите сойти с ума, загляните в createtransactions2 в wallet2. Это самая длинная функция из всех мною когда-либо виденных. Она невероятная. Таким образом, если люди будут строить транзакции различными способами, то тем самым они будут оставлять свой след, а это представляется угрозой для взаимозаменяемости самой Monero. Ещё примеры: производные трат и доказательства резервов; построение URI и парсинг; специфическая информация форка и маркеры поведения, которыми, очевидно, любой захочет воспользоваться; подписание данных и многие другие крутые вещи. Существует ещё одна странная вещь под названием… ну, пожалуй, мне не стоило говорить, что она странная, но кто-то взял и создал эту штуку под названием src/wallet/api для GUI, которая, по сути, привязывается к wallet2 и затем обеспечивает ещё один API, который, как предполагается, будет стабильным или что-то в этом роде. Но она находится в том же репозитории, так почему же для нее нет интерфейса в самом wallet2? Это проблема классов интерфейсов. А wallet/api содержит целый ряд других функций, таких как менеджер кошелька и фактический интерфейс для кошелька. И все эти вещи, очевидно, должны быть в wallet2, иначе wallet2 должен находиться на более низком уровне. Таким образом, группа интеграторов взаимодействует с API этого кошелька, но они должны бы закодированы в wallet2, а новым интеграторам неизвестно, что, возможно, им и не нужно использовать wallet/api.
Одним из примеров интеграции, который, я думаю, оправдывает отсутствие необходимости в дальнейшем использовании всего из этой связанной реализации wallet2, является сервер лёгкого кошелька, который как бы сидит напротив узла и сканирует его для вас, и вам не приходится постоянно сканировать его посредством вашего устройства. Сервер, который будет это делать для вас, может быть расположен у вас дома. Поэтому мы построили и выпустили опенсорс версию сервера. В настоящее время мы ожидаем окончательного рассмотрения нашего пул-реквеста. Но wallet2 содержит вариант реализации, в соответствии с которым серверу лёгкого кошелька необходимо получить ложные выходы и распределение выбора для того, чтобы создать кольцевые подписи, просканировать выходы, а затем расшифровать ID платежей, которые содержатся в транзакциях. Поэтому нам также хотелось использовать часть кода wallet2, чтобы реализовать наш кошелёк, перепаковать всё это в ASMJS или WebAssembly. А wallet2 уже содержит многое из того, что уже реализовано в лёгком кошельке, что я тоже упоминал, но мы не могли воспользоваться этим из-за сложности. Поэтому я задумался: «А не могли бы мы в коечном счёте свести код MyMonero и код Monero?», - поэтому я потратил какое-то время на факторизацию wallet2, всего, что было связано с построением транзакций, и наткнулся на эту проблему, в конце концов, я успешно справлялся с этим множество раз, по-моему, три раза, проблема заключалась в том, что скорость разработки самой Monero означала, что работу, которой был занят я, связанную с факторизацией или реорганизацией, приходилось в некоторых случаях переделывать дважды. Закончилось всё тем, что я сделал пул-реквест. Это стало занимать всё моё время, и скорость разработки Monero означала, что я никогда не смогу одновременно заниматься своей основной работой и кодом Monero. И я заметил, что это характерно для всех тех, кто занимается кодом Monero. Поэтому моим промежуточным креативным решением буквально стала ручная перепись кода JavaScript, который был нами реализован поверх основной криптографии. Я написал всё на C++ и перепаковал в JavaScript. И теперь, чтобы наш сетевой кошелёк работал, нам необходимо использовать C++ на каждой платформе, которая может работать с ним, такая как iOS, например, мы можем использовать один и тот же перепакованный код.
Итак, я на самом деле рассматриваю ту же самую лежащую в основе конструкцию транзакций crypto-note utils, точку ввода кода транзакций, которую wallet2… создаёт транзакции, к которым привязывается. Но требуется охватить ещё большой объём кода. Я закончил на том, что создал нечто под названием базовые CPP, который гораздо лучше поддерживается, чем написанный вручную JavaScript, поскольку он имеет много общего с базовым кодом Monero, написанном на C++. но это не идеальное решение. В коде по-прежнему присутствуют расхождения. И в него необходимо включить «раздетую» версию базового кода Monero, так как, очевидно, вы не сможете сохранить все эти зависимости и все остальные вещи, которые… понадобится такой объём дополнительного кода, который большинство интеграторов просто не станет использовать. В настоящее время core_cpp обеспечивает работу ряда приложений лёгкого кошелька и даже некоторых приложений полного кошелька, подключающихся к узлам. Но тут необходим утилитарный код Monero, даже в случае с полными кошельками. Этим я хочу показать, что wallet2 не совсем применим или же является наименее жизнеспособным вариантом для тех кто занимается разработкой полных кошельков. Уже был ряд сообщений, согласно которым люди отказывались от интеграции Monero в свою продукцию или свои службы. Но сегодня такие сообщения нам уже не поступают. И мне кажется, частично причина кроется в этом. Если хотите проверить, core_cpp был перепакован в JavaScript. И теперь у нас есть новый Core JS.
Итак, мне бы хотелось предложить некоторые решения для ситуации, в которой мы оказались. Я предлагаю произвести простую алгебраическую факторизацию wallet2. Иногда, когда люди говорят о рефакторизации, на самом деле они говорят о том, что всё необходимо переписать. Нам не следует делать этого. Это плохая идея, если только не найдётся герой, который действительно сможет сделать это. Но простая алгебраическая факторизация, простое разделение вещей, позволяет получить чистые функции, которые не изменят состояния объекта, но которые возьмут этот состояние и вернут результат. И этим способом на данный момент может воспользоваться каждый. А затем предлагаю произвести факторизацию wallet_base в wallet2, а затем ввести зависимости или привязки к персистентности. Нам также нужно извлечь адресную книгу и структуры данных, и все подобные вещи. Мы можем перенести Wallet API в репозиторий GUI. Или даже лучше — выделить из него полезный код, добавить его в wallet2 или wallet_base, а затем в коде GUI, и у всех других приложений появится некое руководство по прямому использованию объекта wallet2, если возникнет такое желание. Или же можно будет использовать wallet_base, или просто унаследовать необходимое из wallet_base. Я вижу, вы программист, вы киваете. Вы точно понимаете, о чём я говорю. Возьмём, к примеру, wallet_manager, который не принадлежит к основному коду Monero. Simplewallet использует wallet2 напрямую. Это свидетельство того, что у нас нет никакой необходимости в реализации этого дополнительного API поверх всего. И если зайти дальше, мы могли бы выделить simplewallet и другой общий код, не принадлежащий Monero, из существующего единичного репозитория, который у нас имеется на GitHub, а затем разместить его в отдельных репозиториях и создать довольно «раздетую» базовую библиотеку Monero. Я думаю, в будущем, как сказал Риккардо, народ перейдёт на Rust. Мы могли бы использовать эту базовую библиотеку Monero, возможно, привязать к ней FFI или сделать что-то в этом роде. Я думаю, нам необходимо создать libwallet, который, вероятно, будет включать эту libmonerocore. Кроме того, туда также должна входить wallet_base и всё то, что могут захотеть использовать другие люди, ряд этих факторизованных чистых функций и подобные вещи. И, вероятно, нам следует разбить демон-программу между сервером lightwallet и сервером RPC из libmonerocore, разместив в их собственных репозиториях, что было бы идеально. Вот, чем я займусь. Или же они могли бы существовать в одном репозитории, таком как репозиторий command_line. Вот вам пища для размышлений.
Что там у меня со временем? Пять минут.
Итак, улучшения кода Monero имеют огромное значение для экосистемы, не только с точки зрения роста, но и с точки зрения продвижения и эффективности фактического развития наших приложений, фактического функционала и фактической реализации, которая была сделана нами к этому моменту. Тут приводится цитата из книги «Хакеры и художники» Пола Грэма. Пол Грэм является Lisp-хакером и основателем Y Combinator. Цитата следующая: «мусор порождает мусор». Идея состоит в том, что энтропия, когда энтропия выше, она будет усиливаться в силу уже существующей энтропии. Труднее изменить код с высоким уровнем энтропии. Когда вы пытаетесь изменить его, вы, как правило, усиливаете энтропию, если не произвести факторизацию, снизив её. Так что я думаю, пусть это прозвучит несколько притянуто, но лично я думаю, что повышение энтропии кода, хоть это и выглядит невинно и существует правдоподобное отрицание, связанное с этим, но я думаю, что это может затормозить развитие Monero. Я думаю, что это можно рассматривать как вектор атаки на Monero. По мере того как развитие будет тормозиться, мы остановимся в какой-то точке, и нам придётся всё переписать, а это, по сути, убивает проекты. Это убило ранние проекты разработки браузеров. Есть множество проектов, которые умерли, когда в определённый момент их команда сказала: «Послушайте, мы больше не можем этим заниматься. Всё надо переписать». После они пытались сделать это, но то ли они не всё приняли во внимание, либо не дошли до финишной линии, но они просто сдавались. Вот, что может произойти. И это реальная угроза для Monero.
Большим фактором вклада в сложную архитектуру является то, что разработчики часто подолгу не признают решаемой ими проблемы, когда они занимаются написанием кода. Это как в случае, когда мы добавляем код в определённое место — мы делаем это, потому что мы ленивы и не хотим открыть другой файл и посмотреть, как это лучше сделать, или же мы добавляем его в нужное место? Лёгкий — это не то же самое, что и простой. Есть ещё один выдающийся архитектор программного обеспечения, Рич Хикки, который говорит: «Выбирайте лёгкий способ по простому пути». Таким образом, всегда отдавайте приоритет простоте, но выбирайте то, что можно сделать на этом пути с лёгкостью. И vtnerd упомянул, что в центре многих этих проблем находятся зависимости. Таким образом, значительная часть этого кода была написана вовсе не для ограничения использования зависимостей и не из соображений, связанных с тем, что какое-то минимальное изменение в спецификации потребует значительных изменений фактической реализации или интеграции кода. А в идеале код должен писаться единожды и существовать вечно. Вот, какая идея стоит за этим. И поэтому названия значат очень много.
В будущем будет Переход к факторизации, который сделаю я, vtnerd и ещё один человек, ndorf, который также присутствует в аудитории. Я упомянул о некоторых своих предыдущих попытках, таких как создание wallet3, некоторых чистых функций и минимального ядра Monero. Будут ещё попытки повысить качество кода, которые предпримут woodser, который сидит тут же, и vtnerd. Кроме того, нас довольно сильно поддерживает сообщество, moneromooo, hyc и Fluffy Pony. Задействованы все. Остаётся один вопрос: кто действительно займётся этим? И я не думаю, что это достаточно хорошо. Я вижу причину в том факте, что это критически важно для нашего будущего, и в том, что это даст нам множество преимуществ, и мне кажется, что нам в Monero необходимо завести традицию и праздновать завершение работы по упрощению и повышению качества нашего кода. Поэтому я обращаюсь ко всем, присоединяйтесь к обсуждению вопроса факторизации на канале IRC #monero-dev. Всё больше и больше людей понимает, насколько важна эта работа. И если кратко, факторизация нашего кода означает многое, сохранение низкого уровня энтропии, сохранение простоты и доступности. Но также существуют и довольно специфические, уникальные проблемы, связанные с реализацией в рамках проекта, который также быстро развивается, является децентрализованным, а также свободным и открытым, как Monero. Я думаю, что мы достигнем точки, в которой нам придётся переписать многое, и может всё закончиться тем, что мы сразу же перейдём к Rust. Это может стать реальной проблемой. Есть действительно простые способы её решения, и нам необходимо интегрировать эти решения или методы решения в нашу повседневную практику разработки, а не откладывать их на будущее. И мы должны уничтожить epee и src/common, но с любовью, разлив за них по бокалам Barolo, небольшая шутка. Спасибо для своих.
[аплодисменты]
Вопросы? Думаю, смогу уделить по минуте на каждый вопрос.
Шурэ: В самом деле у нас осталось немного времени, кто-нибудь хочет задать короткие вопросы Полу, перед тем как мы продолжим? По крайней мере у нас уже есть один, замечательно.
Вопрос из зала: Вы упомянули IRC и #monero-dev, конечно. Есть ли, то есть, учитывая область самого проекта IRC, из-за его временного характера, может, это не лучший способ для планирования и отслеживания в перспективе? Возникал ли такой вопрос, или, не знаю, может, это EPIC или что-то подобное, что потенциально можно было бы использовать, и куда мы могли бы влиться?
Часть проблемы состоит в том, что мы могли бы определить те области кода, которые требуют нашего внимания. Но они могут очень быстро измениться. Так что я думаю, это должна быть живая попытка, и нам необходим более гибкий подход. Я уверен, что отслеживание вопросов здесь вполне применимо. Я нахожу это хорошей идеей, это будет полезно. Но людям, которые пользуются этим, придётся произвести обновление. И в некоторых случаях бывает так, что эффективнее, кто бы не заметил проблемы, исправить её прямо там, поскольку, если честно, обычно так и происходит. И обычно люди говорят: «Нет, я не собираюсь заниматься этим, у меня есть более важные дела». На самом деле у них может их и не быть. Я думаю, нам необходимо немного изменить наши приоритеты с точки зрения того, как мы пишем код. Нам всегда приходится что-то реорганизовывать. ABF — always be factoring — всегда занимайся реорганизацией.
Шурэ: У нас есть ещё время для вопросов, если кто-то хочет спросить о чём-то ещё. О’Кей, уже вижу, что есть пара.
Вопрос из зала: Хорошо, ты знаешь, как много эта тема значит и для меня. Поэтому я хочу спросить, это будет как бы продолжение прошлого вопроса, может, на самом деле было бы хорошо иметь выделенный канал IRC, поскольку, на мой взгляд, одна из проблем заключается в новых изменениях, которые выносятся на обсуждение, то есть они перемешиваются в ходе обсуждения. В настоящее время одной из вещей, над которыми я работаю, стало решение проблемы таких отступлений. И, безусловно, многие всё так же делают свой вклад через этот канал. Но это как бы уже другое видение, поскольку то, о чём ты говоришь, касается именно изменения в видении, как мне кажется, насколько это возможно, так что: «Да, давайте создадим новый канал IRC» и будем работать на нём.
Да, я, по сути, и создал такой, #monero-newlibs, но дело в том, что это необходимо как-то интегрировать в нашу культуру. Я иногда думаю, что, может, и не стоит делать его отдельным, по крайней мере, прямо сейчас. На данный момент сообщество ещё не достигло необходимого уровня понимания проблемы, как мне кажется, чтобы реально выработать эффективную стратегию. Но я думаю, что в этом случае… То есть я хочу сказать, что в этом участвует всё больше и больше людей. Так что я думаю, это действительно имеет смысл. Мне кажется, это хорошая идея. Для этого и создан #monero-newlibs,
Шурэ: Я вижу ещё один вопрос.
Вопрос из зала: Вы закончили на минорной ноте. Проблема только усугубляется. И мне хотелось бы отметить, что это ограниченный, очень ограниченный круг людей. Существует множество контрибьюторов, но я не думаю, что многие способны провести хорошую факторизацию или хорошо проработать функции всей кодовой базы, так что совсем не обязательно они имеют представление о том, что и где должно находиться. То есть вы упомянули несколько человек, и мне интересно, думали ли вы, и в своём ответе на вопрос вы обозначили, что это должна быть групповая попытка и изменение видения, но я подумал, мне сало интересно, а может, лучше было бы попробовать одного отдельно взятого человека…
Я уже пытался. Я работаю над этим уже два года.
…так не думаете ли вы, что следовало бы пойти этим путём?
Нет, нет. Я не думаю, что это так, и я не думаю, что в этом решение, потому что это не только вопрос ответственности за факторизацию всей кодовой базы Monero, которая должна свалиться на плечи одного отдельно взятого человека. Это также и случай, в котором отсутствует возможность поддержки. Это не реальное решение, так как появятся многие, кто возьмёт и добавит свой код поверх вашей прекрасной работы. Так что я думаю, это будет нечто, создаваемое с нуля. Это надо взрастить. Но также я думаю, что кодовая база Monero не так безумна с точки зрения функционала и организации. Я думаю, что если бы вы, с качестве незаинтересованного разработчика, заглянули бы в Wallet2, вы сразу отметили ряд функций, которые можно извлечь в качестве чистых функций вообще без каких-либо затруднений. И если вы хоть немного разбираетесь в Monero, вы увидите, как и разработчик, который изучает Wallet2, что и там есть вещи, которые люди не станут использовать. Так что имеет ли это смысл? Определённо.
Шурэ: У нас есть время на один последний вопрос. Пожалуйста.
Вопрос из зала: Вы очень хорошо описали функции, которые сейчас имеются в epee и common. Существует ли документ, в котором всё это будет описано, или же вы записали это только для себя?
Да, это мой собственный анализ, моё собственное наблюдение. Но, если честно, я мог бы составить для вас список всех файлов, я могу составить список всех функций и всех интеграторов, но, опять же, Monero — это постоянно меняющаяся среда. Она меняется просто непрерывно. И в этом состоит сложность, когда речь заходит о написании документов, и происходит это так: «Смотрите, это…» Она должна быть гибкой, и должна быть группа людей, которые будут заниматься этим.
Проблема, с которой я столкнулся при работе с деревом, как в случае с функциями epee, так и функциями common, я просто не знаю, куда ещё их деть.
Так. Я могу вернуться к некоторым примерам, но если говорить в целом, идея состоит в том, чтобы определить проблемную область, к разрешению которой относится код. А после этого вы поймёте, как это описать конкретным, строгим образом. А затем вы просто сделаете, не бойтесь создавать модуль верхнего корневого уровня с таким названием и просто включите его. Wallets, например, довольно хорошее название для модуля, но программист отвечает за то, чтобы добавляемые модули соответствовали. Тут нужна практика. У меня ушли годы на то, чтобы довести до совершенства, ну, не совершенства, я не стремился достичь его, но по крайней мере я знаю, что делаю.
Шурэ: Отлично. Давайте все вместе ещё раз поблагодарим Пола. Спасибо.
Перевод: Mr. Pickles
Редактирование: Agent LvM
Коррекция: Kukima