• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Могут ли SegWit, Lighting и RBF появиться в Dash?

alex-ru

Well-known member
Все криптовалютные сообщества постоянно обсуждают новые технологии и решения в сфере электронных платежей. И всегда, когда в сообществе Dash о них заходит речь, опытные пользователи и новички постоянно задают вопросы о перспективах Dash. Эти вопросы постоянно рассматриваются на наших форумах, на Reddit, в чате Discord, а также на реальных встречах поклонников криптовалюты и Dash.

Данный пост отражает только моё личное мнение и мои же личные соображения по некоторым вопросам. Но всё же, хочу сказать, что после немалого количества наших дискуссий, я уверен, что большинство разработчиков Dash согласятся со мной, и можно смело говорить об определённом консенсусе в затронутых вопросах.

Естественно, что эти темы интересуют не только поклонников Dash. Многие из упомянутых технологий уже “проданы” в качестве спасательного круга, который мог бы решить много проблем и избавиться от недостатков, коими грешат криптовалюты, особенно Биткойн. Но, напомню, мы – это не Биткойн, и наши приоритеты, как и наша стратегия, отличаются некоторыми важными аспектами, а именно – мы в Dash стремимся устранить сами причины основных проблем, а не лечить, или же пытаться обойти их симптомы.

Основные проблемы Биткойна часто связаны с предельным размером блока в 1 Мб, что ограничивает максимальную пропускную способность транзакций в сети. Пользователи и торговцы сталкиваются со следующими симптомами: высокая комиссия, долгое ожидание подтверждения и транзакции, надолго застрявшие в сети Биткойн. Если бы размер блока не был ограничен, все указанные симптомы не проявлялись бы.

Наши планы on-chain масштабирования означают, что по мере необходимости мы будем увеличивать максимальный размер блока и, таким образом, сумеем полностью избежать упомянутых симптомов. Это и есть наш приоритет, и мы уверены в успехе его реализации. А уверены мы в этом потому, что у нас есть большая сеть Мастернод, экономически заинтересованных в масштабировании. Вознаграждения, получаемые при запуске Мастерноды, достаточно высоки, чтобы обеспечить необходимые средства и при этом иметь возможность получать приличную прибыль. У Биткойна, напротив, ноды работают исключительно благодаря добровольцам и, таким образом, масштабирование сети происходит гораздо медленнее. Обычные пользователи Dash совершенно не обязаны работать как ноды сети, поскольку они могут задействовать SPV или приложение “Лёгкий клиент”. Evolution станет следующим шагом в этом направлении (с точки зрения пользователей, “Dash Эволюция” - это будет “SPV на стероидах”.)

Некоторые криптовалюты продемонстрировали значительный рост курса, последовавший за их заявлениями о намерении внедрить эти технологии. Подчеркну, что повышение курса не является нашим в команде Dash приоритетом, и наши технические решения не направлены на сиюминутное увеличение капитализации. Однако, это будет происходить естественным образом в долгосрочной перспективе, так как мы поставляем необходимый и качественный программный продукт для сети, для пользователей и для торговцев.


SegWit

SegWit, вероятно, является самым обсуждаемым изменением в Биткойне. Оно оказалось настолько спорным, что привело к полному расколу Bitcoin сообщества. Закончилось всё тем, что Биткойн разделился на две цепи, одна с SegWit (BTC) и одна без SegWit (BCH). Состояние, в котором сейчас находятся эти два лагеря, иначе как войной не назовёшь.

Можно назвать несколько качеств у SegWit, которые и привели к этому расколу. Многие из них являются техническими, но многие, кажется, можно назвать политическими. Однако, детали аргументации обоих лагерей не являются задачей моей публикации.

Я хотел бы поделиться с сообществом Dash одним собственным выводом по этому вопросу: Мы не должны безоговорочно заимствовать SegWit в его нынешнем виде, так как полезность этой технологии не вполне очевидна. Полемика вокруг SegWit возникла не на пустом месте, и у обоих лагерей были очень веские причины для борьбы за одно из двух направлений. Следует тщательно оценить, насколько нам нужен SegWit, и существуют ли альтернативные решения имеющихся проблем.


Сеть Lightning / Сети Off-chain


Есть много вопросов по Dash и Lightning. Они часто идут в комплекте с SegWit, поскольку они, по-видимому, рассматриваются как единое целое или, по крайней мере, как сильно зависящие друг от друга. Однако на деле это две разные независимые технологии. Благодаря SegWit проще реализовать Lightning (и другие off-chain сети), поскольку SegWit устраняет многие недостатки, вызванные текущей “неповоротливостью” транзакций, но это касается также и решений других проблем, являющихся следствием этой “неповоротливости”.

Lightning обещает снизить комиссии до минимума, сделать транзакции мгновенными и в то же время снять нагрузку на блокчейн и сеть P2P.

Однако, высокие комиссии и медленные транзакции являются прямым следствием слишком малого размера блоков. Поэтому, добывая новые блоки, майнеры стремятся получить максимум прибыли, а это означает, что они предпочитают транзакции только с самыми высокими комиссиями, и не включают все транзакции с низкой комиссией. Поэтому, если нам удастся сделать on-chain масштабирование (увеличить максимальный размер блока), эти два качества Lightning станут просто ненужными. Как я уже написал во введении, такой подход и является нашим главным приоритетом.

В то же время у Dash уже есть InstantSend, а эта функция уже сегодня может легко конкурировать с обещанной скоростью от Lightning. У InstantSend есть некоторые ограничения, мы все их знаем. Их устранение мы считаем более существенным приоритетом, чем пытаться использовать технологию off-chain. У нас в запасе уже есть некоторые идеи насчёт исправления этих проблем и улучшения работы пользователей с InstantSend.

Снижение нагрузки на блокчейн и P2P-сеть не являются для нас достаточным аргументами, чтобы утверждать, что Dash тоже должен задействовать технологию Lightning. Масштабирование on-chain всегда будет иметь для нас более высокий приоритет, причём это будет достигаться не только увеличением размера блока, но также и другими решениями для уменьшения размеров транзакций.

Lighting уж точно не может претендовать на звание “неуязвимого решения”. Там остаётся ещё много нерешённых проблем, которые могут затруднить жизнь пользователям. Например, чтобы убедиться в получении платежа, вам необходимо блокировать средства в каналах и оставаться в сети 24/7. Это неприемлемо в существующих условиях, когда большинству пользователей криптовалюты нужен функциональный мобильный или веб-кошелёк. Такой подход абсолютно несовместим с теми задачами, которые стоят перед нашей Dash Evolution.


RBF (Replace by fee)

Функция RBF у Bitcoin пыталась решить проблему “транзакция-навсегда-зависла- в-мeмпуле (пуле памяти)”, с которой Биткойн сталкивается каждый раз при переполнении блоков. Проблема проявляется, когда вы отправляете транзакцию в сеть, в каждый пул памяти узла/майнера, но в то же время комиссия за транзакцию такова, что майнеру невыгодно включать её в блокчейн.

В результате транзакция очень долго остаётся неподтвержденной, что делает невозможным использование тех же самых входов/средств в любой другой транзакции. Прохождение ваших средств, как правило, блокируется. RBF решает эту проблему таким образом: вы можете полностью заменить эту транзакцию, т.е. к тем же самым средствам добавить дополнительные средства, но при этом комиссия, естественно, повышается.

Мы считаем, что такой подход борется не с самой проблемой, а с её симптомами. Симптомом здесь является заблокированная транзакция, а проблема, на самом деле - это переполнение блока. У майнеров нет стимула обрабатывать транзакции с низкими комиссиями, когда можно работать с более высокими. Мы же предпочитаем действовать другим образом и идти по пути on-chain масштабирования, как я уже отмечал во введении.

В продолжении разговора о проблеме, давайте вспомним, что в версии Bitcoin 0.14 представлена функция под названием “пакеты транзакций”, которая также будет включена в следующий релиз Dash 12.3. Эта функция меняет способ расчётов прибыли майнеров от транзакций. Вместо расчёта комиссии за одну транзакцию, майнеры создают “пакеты” серии связанных транзакций и вычисляют комиссию за весь пакет. Это означает, что если у майнера есть 2 транзакции, в которых вторая тратит выход первой (связанные транзакции), их размер и комиссии суммируются, и на основе этих вычислений рассчитывается итоговая общая комиссия за байт.

Если же какая-нибудь непредвиденная транзакционная нагрузка приводит к полной блокировке и перегрузке сети, вы всё же можете спасти свою застрявшую транзакцию, отправив еще одну, которая тратит изменённый выход зависшей транзакции. Эта вторая транзакция будет включать более высокую, чем обычно, комиссию, которая также покроет комиссию за первую транзакцию. И такой путь сделает первую транзакцию прибыльной, несмотря на то, что она сама по себе изначально имела достаточно низкую комиссию.

В качестве альтернативы, получатели платежей могли бы сами доплатить вашу комиссию, применив эти связанные транзакции. Торговец может просто создать ещё одну транзакцию, которая потратит выход вашей транзакции. Это возможно, так как этот выход был предназначен ему. И таким образом, торговцы могли бы сами увеличивать комиссию за каждый байт в этом пакете транзакций, как мы видели в приведённом выше примере. Торговцы даже могут быть заинтересованы в этом, ведь они хотят, чтобы оплата им прошла.

Эта схема называется CPFP (Child Pays For Parent) и представляет собой отличную альтернативу RBF. Оба решения требуют увеличения комиссии, поскольку они добавляют новые входы и выходы, за которые нужно платить. RBF делает это с самой изначальной транзакцией, а CPFP - путём создания новой доволнительной транзакции. Таким образом, для применения CPFP требуется ещё несколько байтов для заголовка дополнительной транзакции, но увеличение комиссии на это достаточно незначительное.

(Продолжение - в следующем посте)
 
Last edited:
Подписи Schnorr

Мы потратили некоторое время на исследования технологии подписей Schnorr и на самом деле нашли хорошие варианты по их использованию, особенно для некоторых функций, связанных с Evolution.

Однако вскоре выяснилось, что существует более надёжная альтернатива: подписи BLS (Boneh-Lynn-Shacham). Сейчас это выглядит так, что с BLS-подписями мы сможем реализовать те же самые функции, но более простым и гибким образом. Некоторые свойства подписей BLS позволяют применять их и для многих других целей. Например, так как подписи BLS являются детерминированными и уникальными, для каждого подписанного сообщения (например, транзакции) существует только одна действительная подпись. Данное свойство работает и для совместных, и для изначальных подписей, а это открывает много новых возможностей. Следите за грядущими новостями DIP, и вы услышите о некоторых интересных идеях.


Свойство гибкости транзакций

Гибкость транзакций - это возможность изменить транзакцию таким образом, что в результате меняется хеш транзакции, а сама транзакция остается действительной. В основном эта проблема существует по двум причинам. Первая заключается в том, что торговцы, биржи и другие стороны процесса полагаются на хеш транзакции, чтобы убедиться в подтверждении on-chain-транзакции. Если транзакция будет подтверждена другим хэшем, чем в изначальной транзакцией, это может говорить о её неправомерности. Наиболее показательный случай в этой сфере произошёл с биржей MtGox, которая не могла определить корректность произведенных исходящих транзакций, и в результате затем повторно отправляла средства этих транзакции, чтобы “исправить” якобы “проблему”.

Вторая проблема возникает, когда предварительно подготавливаются (pre-built) связанные транзакции, которые зависят от второй транзакции, а та, в свою очередь, тратит выходы предыдущей. Некоторые схемы, например те, которые используются в “atomic”-свопах, требуют транслирования второй транзакции перед первой. В результате если первая транзакция подтверждается как уязвимая, вторая транзакция становится недействительной.

Существует ряд уже известных способов использования этой транзакционной уязвимости.


Неправильные подписи

В более ранних версиях Bitcoin и Dash закодированная подпись могла модифицироваться таким образом, что сама подпись оставалась действительной, но кодировка была изменена. Биткойн и Dash игнорировали изменённую кодировку, а при подтверждении учитывали правильную подпись. Такой подход позволял кому угодно изменить транзакцию и транслировать изменённую версию подписи в сеть.

Dash решил эту проблему начиная с блока 245817 (2 апреля 2015 г.). Такое же решение осуществил и Bitcoin (BIP66).


Гибкость scriptSig

Ошибка в дизайне объектов OP_CHECKMULTISIG и OP_CHECKMULTISIGVERIFY привела к восприятию неиспользуемого остатка значения из стека. Поскольку эта величина не была вообще проверена/использована, изменить её мог кто угодно, причём, сама транзакция не аннулировалась. В течение некоторого времени у Биткойна и Dash существовало необязательное правило не передавать транзакции с ненулевым значением в стеке. Таким образом, только не подчиняющиеся правилам майнеры могли столкнуться с этой уязвимостью.

Следующая версия Dash (12.3) введёт новое правило для контроля величины nulldummy on-chain, а это означает, что не только правильные майнеры будут защищены. Это то же самое решение проблемы, которое Bitcoin задействовал на базе протокола SegWit с внедрением BIP147. Мы же выпускаем новую независимую версию (ведь мы не запускаем SegWit).


Гибкость повторного подписания

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

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

Схемы с подписями не на основе ECDSA могут оказаться более лёгким решением. Например, BLS обеспечивает детерминизм и уникальность без каких-либо дополнительных усилий. BLS имеет и другие преимущества, включая решение проблем, имеющих даже более высокий приоритет, чем устранение этой уязвимости. Но мы с удовольствием примем и эти положительные побочные эффекты. ;)

В принципе, этот тип уязвимости мы можем рассматривать, с некоторым упрощением, как проблему двойной траты. Разница только в том, что этот тип «двойной траты» производит её на те же самые выходы. Таким образом, к этому типу применимы такие же правила и ограничения, например, применение правила “first-seen-relayed-and-mined” снижает риски уязвимости этого типа в той же степени, что и при классической “двойной трате”.


Выводы

Наиболее серьезными являются первые два типа уязвимостей, поскольку они позволяют кому угодно извне изменить видимую всем транзакцию и отправлять её повторно после изменения. После выхода релиза Dash 12.3, оба эти типа транзакций будут запрещены в сети Dash.

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

Часто упоминаемый пример проблемы с биржей MtGox невозможно реализовать с помощью третьего типа уязвимости. Его может применить только отправитель, но не получатель транзакции. В случае с MtGox отправителем была сама MtGox, а использована была уязвимость из первых 2-х типов.


Поддержка IPv6 в Dash

Похоже, в сообществе Dash не до конца понимают суть этого вопроса, поскольку некоторые считают, что Dash сознательно отключил/удалил /прекратил поддержку IPv6 в Dash.

IPv6 никогда не ограничивали, когда речь шла об обычных P2P-взаимодействиях и операциях обычных нод сети. Каждый может подключиться к сети Dash с помощью IPv6, при этом все стандартные функции P2P (например, формирование транзакции и её трансляция по сети) работают нормально. С помощью IPv6 можно даже запустить полную ноду.

Однако существует требование, которое применяется только к Мастернодам: для каждой Мастерноды должен быть обязательно указан IPv4 адрес и они должны обеспечивать соединение между собой по IPv4 адресам. Если бы этого требования не существовало, клиенты/ноды IPv4 не смогли бы подключиться к таким Мастернодам на IPv6. Обратите внимание, что узлы сети IPv6 с двойным стеком IPv4/IPv6 всегда могут подключаться к узлам IPv4, но наоборот это сделать невозможно.

Мастерноды предназначены для обслуживания всей сети и всех типов пользователей. Именно за это они получают своё вознаграждение, и мы считаем, что такое требование для Мастернод просто необходимо к исполнению, поскольку иначе они не будут полностью выполнять свои обязанности.

Если внедрение IPv6 когда-нибудь станет настолько повсеместным, что можно будет пренебречь незначительно малым числом IPv4-клиентов, тогда можно было бы пересмотреть это требование к Мастернодам.


Синхронизироваться с актуальной версией кода Биткойна

Если говорить о кодовой базе, то у Dash тут получается интересная история. Первоначально Dash был основан на кодовой базы Litecoin (который сам является форком Bitcoin). Развитие Litecoin вскоре сошло на нет, и после этого Dash перешёл на оригинальный исходный код Биткойна. Вследствие нехватки времени и ресурсов дальнейшие обновления кодовой базы происходили в Dash нерегулярно, в результате чего Dash оставался на довольно старой версии кода Биткойна.

А вот и наша свежая история обновлений и бэкпортов:

1. До Dash 12.1, основой нашей кодовой базы был исключительно Bitcoin 0.12​
2. Релиз Dash 12.2 включал бэкпорты значительной реорганизации исходного кода Биткойна 0.13–0.14, что способствовало повышению стабильности и улучшению качества работы Dash.​
3. Dash 12.2.3 применил патч “per-utxo”, который справился с угрожающим и публично известным вектором DDoS атак “Corebleed”. Это сыграло важную роль в обновлении кода у Bitcoin 0.15​
4. Dash 12.3 будет включать уже все улучшения, присущие версиям Bitcoin 0.13 и 0.14, за исключением SegWit и обновлений, связанных с RBF. Всё уже закончено, и вы можете найти информацию об этом в соответствующей ветке разработок на Github. Скоро наша новая версия получит публичный релиз.​

Как вы можете видеть, в последнее время мы приложили много усилий для обновления нашей кодовой базы - мы обработали более 800 Пул-реквестов и тысячи коммитов изменений. Мы планируем и дальше делать постоянные обновления и бэкпорты, пока не придём к такому высокому уровню развития, где исчезнет необходимость продолжать это делать. Тогда уже цели и приоритеты у Bitcoin и Dash совершенно разойдутся, а пока это происходит довольно постепенно. Например, Биткойн сосредоточил много усилий на внедрение SegWit в версии 0,15 и 0,16, ну а мы все больше и больше концентрируемся на внедрении кода, связанного с функционалом Evolution.


ПЕРЕВОД
Оригинал:
SegWit, Lightning, RBF…in Dash?

Этот перевод оказался непростой задачей для наших редакторов...
Пресылайте свои замечания и предложения по корректировке перевода.
Кроме того, если кто-то способен нам помогать - выступать "техническим редактором" в последующих схожих переводах - прошу написать мне об этом в личку. Спасибо.
 
Last edited:
Back
Top