Всем привет,

Я научный сотрудник Еврейского университета в Израиле, и я работал с учеником (Йонатан Sompolinsky) на бумаге, связанной Bitcoin. У нас есть очень интересные результаты, которые мы готовы поделиться с сообществом Bitcoin. Мы действительно хотели бы получить конструктивную обратную связь о нашей работе от многих умных людей в обществе, поэтому я вывешиваю здесь.

Вот ссылка на полные бумаги: http://www.cs.huji.ac.il/~avivz/pubs/13/btc_scalability_full.pdf
Название: Ускорение обработки транзакций Bitcoin в (Быстрые деньги растут на деревьях, а не на цепях)

Edit: Спасибо за хорошую обратную связь! Резюме основных проблем и вопросов, добавили ниже.

Поскольку документ является довольно длительным, и написана для академической аудитории (которая, к сожалению, не является, как правило, знакомы с протоколом), мы решили, что лучше также обеспечить быстрое объяснение наших результатов, направленных на Bitcoiners:

TL; др: Мы предлагаем модификацию протокола к блоку цепи, которая надежно позволяет блоки, которые будут созданы вокруг один раз в секунду, может обрабатывать более 200 транзакций в секунду на этих частотах, и потребляет менее 0,5 Мбайт с точки зрения пропускной способности (меньше при более низких скоростях чем 200 TPS). Все это, без повышенной susceptability до 50% атак. Это по существу решает проблему, которая вызвала Сатоси, чтобы установить 10-минутную мишень для скорости создания блока. Мы также анализируем количество транзакций в секунду Bitcoin может работать и без нашей модификации. Замечу, что время распространения блока являются основным препятствием для масштабируемости.


Более подробное объяснение следует ниже. Основная цель нашего исследования заключается в рассмотрении способности Bitcoin к быстро обрабатывать транзакции, и в больших объемах. Вот наши основные выводы:

Scalibility, Задержки & Безопасность:


Мы начинаем нашу статью, рассматривая точные эффекты высоких ставок по сделкам по безопасности Bitcoin (в Следуя по стопам предыдущих работ по Decker и Wattenhofer). Количество транзакций в секунду (TPS), что Bitcoin может обрабатывать ограничивается двумя основными вещами: 1) Скорость создания блока (1 блок каждые 10 минут) и 2) предельный размер блока (в настоящее время в 1 Мбайт по умолчанию). Эти два параметра объединяются, чтобы ограничить количество операций в секунду, что Биткойн может обрабатывать. Простой способ увеличить TPS является либо увеличить размер блока, или увеличить скорость создания блока. Оба эти изменения носят противоречивый характер, и по уважительной причине: как может повлиять на гарантии безопасности протокола. Во-первых, рассмотрим увеличение числа блоков в секунду (например, блоки Litecoin, что создаются каждые 2,5 минуты или даже Fastcoin с его крайних 12 вторых блоков). Поскольку блоки создаются быстро, много противоречащих друг другу блоков создаются. Большинство будет в конечном итоге от blockchain. Тот же симптом возникает, когда размер блока увеличивается: большие блоки занять больше время для распространения через сеть (из-за ограничения пропускной способности) и блоки, которые создаются в то же время, вероятно, построены на вершине старых блоков, то есть, они будут потрачены впустую.

Тот факт, что многие блоки впустую снижает безопасность сети и делает его более восприимчивым к 50% атакам. Например, если половина блоки впустую таким образом, сеть по существу тратит половину своей хеш мощности на блоки, которые не способствуют подтверждений сделок. Злоумышленник, который является централизованным и не имеет никаких задержек, может выполнять так называемые 50% атаки лишь немногим более 33% от мощности хэша. Это потому, что он может легко создавать более длинные цепи, чем остальная часть сети (ботнеты, которые все еще страдают от влияния внутренних задержек являются менее эффективными, чем централизованные нападающие).
Используя различные методы, мы анализируем, сколько блоков в конечном итоге в цепи, и сколько отбрасываются, и использовать для оценки изменений в области безопасности для различных параметров. Среди других результатов, мы покажем, что при передаче блоков, которые содержат только хэш транзакций (вместо полных записей транзакций) будет в значительной степени способствовать масштабируемости (т.е. это не просто 2 раза экономии полосы пропускания, а скорее 16-кратное увеличение числа транзакций в секунду!).

Наша модификация предложенного протокола (который появляется в разделе 8 нашей статьи):

Поскольку высокие ставки сделки подразумевают созданы много противоречащих друг другу блоков, было бы весьма полезно, если эти блоки не были действительно потеряны. На самом деле, каждый блок можно рассматривать как поддержку не только транзакции внутри нее, но и встроенные в предыдущих блоках. Даже если блок не в основной цепи, мы можем рассчитывать на подтверждение дает предыдущие блоки действительными. Это основа нашей предлагаемой модификации, которую мы называем "Жадный Тяжеленный-Наблюдаемая Sub-Tree" правила отбора цепи.

Грубо говоря, поскольку каждый блок содержит хэш его предшественник, все блоки образуют структуру дерева, с корнем в Genesis Block. Биткойн в данный момент выбирает принятую историю как самый длинный (или, скорее тяжелой цепи) в дереве. Мы предлагаем другой подход: На каждой развилке, выберите суб-дерево, содержащее наибольшее количество блоков (или, скорее, блоки с величайшим трудом в сочетании). Сделайте это несколько раз, пока не достигнут лист. Путь, пройденный является цепью, что узлы должны принять. Но как это поможет? Обратите внимание, в настоящее время, что злоумышленник, который хочет изменить основную цепь, выбранную с помощью алгоритма необходимо, чтобы заставить нас изменить наше решение в одном из вилок. Для этого ему нужно строить больше блоков, чем содержится во всем поддереве (а не только больше блоков, чем содержится в самой длинной цепи!).

Вот псевдо-код правила отбора цепь ПРИЗРАК:

1. В КОМПЛЕКТ <- Бытие Блок.
2. ЕСЛИ Б не имеет наследников: RETURN (B).
   Else: SET B <- Дитя B с тяжелым поддереве.
3. GOTO 2

Стоимость такой модификации: При скорости создания низких блоков, а небольшой блок размера нет почти никакой разницы между правилом длинной цепи и призраком-правилами. Там ничего не стоит. Оба практически идентичны, так как длинная цепь в этих случаях является также самым тяжелым поддерево. В высоких скоростях транзакций, ПРИВИДЕНИЕ создает несколько меньше блоков в своей основной цепи (потому что это не всегда проходит самую длинную цепочку), таким образом, немного уменьшив количество операций, принятых в секунду, но делает это более надежно! Задержки и многие блоки от цепи больше не делают его более восприимчивым к 50% атакам. Это означает, что мы можем увеличить темпы создания блоков и размер блока до уровней, которые ранее были слишком рискованными и легко компенсировать потери в объемах сделок. В самом деле, по нашим оценкам, 1 второй блоки могут быть легко объединены с частотой более 200 TPS. Это предполагает довольно быстрое время авторизации, но гораздо более важно то, что более высокий уровень детализации в подтверждениях. Даже 1 подтверждение дает некоторый уровень уверенности относительно необратимо, и он приходит почти мгновенно, когда блоки генерируются каждый второй.

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

Резюме основных вопросов, поднятых:
Я хотел бы уточнить одну вещь: Мы не утверждаем, чтобы быть в состоянии решить все проблемы можно было бы подумать о отношении к различным аспектам Bitcoin в (стимулы, добыча централизацией и т.д.), так что я думаю, что мы критиковали за проблемы, которые уже там в протоколе. Наша главная претензия в том, что безопасность становится очень плохо, если возникают высокие скорости транзакций, а модификация GHOST фиксирует, что (и только). Если вам неудобно с 1 вторыми блоками, модификация одинаково ценна при более низких скоростях блока. Необходимость решения высоких темпов транзакций по-прежнему существует.

Некоторые конкретные замечания:

1) Преимущество узлов с низкой задержкой. Узлы могут получить доступ к остальной части сети быстро больше блоков на главной цепи и меньше сирот.

Ответ: Это является серьезной проблемой, что текущий протокол Биткойн столкнется, если высокие скорости транзакций (то есть, большие размеры блоков) посылаются через систему. Сильные шахтеры будут иметь возможность получить больше, чем их пропорциональной доли блоков. Мы не улучшить положение вещей, но модификация GHOST не помешает. Единственное улучшение, которое мы предлагаем, является то, что 50% атака не становится хуже, в этих сценариях.

2) DDOS атака: Вредоносные узлы могут добывать блоки выше блока генеза на трудности 1 и спама сети

Ответ: Это тоже, как проблема, что текущий протокол Bitcoin сталкивается. Именно поэтому контрольно-пропускные пункты постоянно ставить на место. (Любой человек может в настоящее время утверждает, что цепь с более твердыми доказательствами работы, и просто начать отправку Трудности 1 блоки в длинной цепи, которая никогда не заканчивается Смотрите здесь для объяснения gmaxwell в.:
.
Контрольно-пропускные пункты могут быть также применены к нашему решению.

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

3) SPV клиенты нуждаются в большей пропускной способности + хранения, если есть блоки каждый второй (при условии, что там будет 600 раз больше заголовков блоков для загрузки).

Ответ: Это верно. Но исправление, вероятно, следует найти более эффективные механизмы для SPV узлов. Например, должно быть возможным вероятностно проверить длинную цепочку заголовков блоков фактически не загружая их все. Вот основная идея: Были ли полный узел построить Merkle дерева всех блоков + трудности, и отправить его клиенту SPV. Клиент выбирает SPV блоков случайным образом из цепочки (взвешивается труд должны иметь) и просит Merkle ветвь к ним (от корня он послал) + проверяет их трудность. всего несколько проверок будет достаточно, чтобы убедиться в том, что есть на самом деле достаточно работы хранятся в цепи (с очень высокой вероятностью).

4) реализация внешний: Как бы узлам знать о осиротевших блоках, если они находились в автономном режиме на некоторое время?

Ответ: Мы считаем, что каждый блок будет содержать хеши офф-цепи (сиротой) блоки в заголовке (только те, которые не написаны в блоках он построен на). Таким образом, основная цепь также содержит запись всех внедорожных цепи блоков, так что он знает, о чем просить. Еще одна причина, мы думаем, что это хорошая идея: (. Включая детей-сирот) Мы считаем, что трудности должны быть перенацеливаться в зависимости от общего числа блоков, построенных в секунду, а не на основе длины самой длинной цепи (retargetting для этого труднее при высоких скоростях ).

5) проблема хранения: много места потребуется

Ответ: Такие решения, как мини-blockchain по-прежнему применимы, и позволяют сохранить только запись последних событий. Еще нет обойти тот факт, что высокие ставки сделки потребуется много памяти (Это не просто масштабирование до размера Paypal / VISA). Опять же, это не вызвано нашей модификации. Вам не нужно, чтобы сохранить содержимое осиротевших блоков - только их заголовки, чтобы проверить трудности. Наличие большего количества блоков в цепи в секунду просто означает каждый из них будет иметь меньше транзакций внутри него. Только добавленная стоимость держит больше заголовков.