Дайте мне знать, что вы думаете.

---Bitcoin ШКАЛИРОВАНИЕ ---
-- 1 О ME--
Мартин Клеменс Блох. Генеральный директор BlochsTech и создатель простой в использовании Bitcoin смарт-карт оборудования бумажнике.
(WWW. BlochsTech.com)

-- 2 GOAL--
Мы хотим создать частичный узел, который вместе с другими узлами может сделать полную проверку цепи.
Имея многие из такой «рои» узлы цепь будет оставаться безопасной и дублируется много раз.

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

Если есть много полных узлов, но все они являются крупными компаниями, становится легко для правительств нацелить их.

Если очень мало полных узлов сети может легко потерпеть неудачу.

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

Каждый раз, когда количество пользователей увеличилось сеть будет также получить больше ресурсов.

-- 3 WHY--
Потому что, если стоимость запуска проверяющего узла тривиальна много много людей будут делать это.

Это не постулирование; все торрент-файлы распределяются бесплатно люди, которые сделали его загрузку
и есть все стимулы, чтобы остановить обмен.

Однако, поскольку стоимость отправляет файл несколько раз тривиальна они - или достаточно пользователей в любом случае - сохранить
обмен.

Это единственное верное решение. Дебаты 1mb против 8MB против XT вводит в заблуждение и не могут удовлетворить требования к цене и децентрализации в то же время.
Раздельное свидетель абсолютно ничего не делает, чтобы решить эту проблему.

Сеть молнии красивая идея, и в то время как она имеет большие заслуги он дает слишком много власти операторам оплаты канала. Крупные операторы оплаты канала может
платить больше сборов, чем мелкие, которые вместе с пределом 1mb означает полную централизацию.

Bitcoin имеет только 3 реальный выбор:
1. Ничего не делать и умереть / заменить.
2. Увеличение лимита и принять централизацией в сторону больших шахтеров и крупных узлов хостинга компании.
Это все равно будет гораздо более децентрализована, чем наши центральные банки, так что я бы не видеть, что, как полный провал.
3. Разделить работу проверки между несколькими узлами - роя узлов.

В этом примере проходит, как сделать 3 вариант предполагая стандартный ПК с менее 1 Мб / с доступны и 1 млн транзакций в блок - 1600 TX в секунду.

-- 4 БЫТЬ VALIDATED--
1. Ничто не может быть удержан из проверенного блока.
2. Допустимые сценарии и подписей.
3. Правильная общая плата за сделку (coinbase).
4. Ни один двойной не тратит.
5. Правильная добыча вознаграждения / добыча трудность (тривиальная не будет обсуждать).
6. Размер блока.

-- 5 SOLUTION--
- 5,1 НЕОБХОДИМЫЕ Изменения-
Txs в блоках должны быть отсортированы по их хэш TX. Сегодня порядок является случайным и без какого-либо эффекта.

После сортировки хэш-TX, начиная с 000, может быть первым в индексе листа Merkle дерева и хэш
начиная с FFF последнего.

Это будет необходимо для того, чтобы легко запрашивать данные из других узлов роя. (Смотрите раздел 5.7)

Swarm узлы могут быть сделаны без этого изменения, но это делает обработку данных проще.

- 5.2 SWARM УЗЕЛ CHUNKS-
Swarm узлы будут нарушать операции Bitcoin на куски, основанные на их индекс в блоке.
Для этого примера мы просто скажем, 512. (ограничение тока блока соответствует приблизительно 3000 передатчикам)

Блок таким образом, будет разбит на некоторое количество кусков ровно 512 передатчиках каждый и один последний кусок
из 1-512 сделок.

Мы пройдем через этот пример предполагая наш роя узел проверяет только один кусок.

Кусок размеров, как это будет означать, что мы бы 1954 Кусок диапазоны 1 млн TX на блок - VISA
уровни или 1600 TX / с.

Узел роя потребуется только 15,6 ГБ в год, чтобы не отставать на этих уровнях (см раздел 6.1).

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

- 5,3 SWARM УЗЕЛ SCRIPT RANGES-
В дополнении к кускам мы также разделить данные длинные претензии скрипта хэш.
Все выходы Bitcoin в виде сценария, хэш всех этих сценариев являются уникальными для каждого сценария.

Swarm узлы будут подписаться на определенные диапазоны. Так что, если хэш может быть только 1 или 0 узел А может подписаться
к 0 хешам и узел B подписаться на 1 хеши.

Если узел А видит 1 хэш в диапазоне 0-512 куска он будет посылать его в B. Если B видит хэш 0 в диапазоне порций
513 до 1024 он пошлет его к А.
B даст свою подпись А что он послал все 0 хэш - например, с помощью просьбы B "Есть ли Tx534 и Tx567
содержат все 0 хешей выходов в диапазоне 513-1024 порций для блока хуга?" и B подписание, что + "да",

Таким образом, может быть легко доказано позже, если B удержан данные.
Как это помогает нам станет ясно позже.

- 5.4 НЕТ WITHHOLDING-
Наш узел роя получает свой кусок от сети, а также список других кусков Merkle хэш.

Используя эту информацию, можно определить:
1. Сделка, это полученная в блоке, и что из этого куска ничего не хватает.
В противном случае Merkle корень не будет соответствовать.

2. Опять же, если весь кусок удерживается Merkle корень не будет соответствовать.

Таким образом, если бы мы имели 1 миллион транзакций в блоке это будет означать лишь 62,5 килобайт Merkle хэшей
для проверки.

- не 5,5 NO Witholding - Нечестные NODES-
Теперь в то время как это заботится о собственном куске, другие узлы мы подключаем к могли обмануть.
Другие узлы роя может сделать две вещи:
1. Просто подписать недопустимый кусок.
2. Отказать TX данные, которые мы присоединяемся к от их куска.

Для того, чтобы ограничить этот риск мы ранжировать все узлы, мы можем найти для каждого диапазона куска. Каждый узел будет иметь такую ​​идентичность
как открытый ключ ECDSA-AES, над которой происходит все коммуникации и кусок подпись.

Мы ранжировать свои открытые ключи на следующий и в следующем порядке:
1. Мы постоянно черный список * узлы, которые подписали диапазоны сценариев, которые оказываются недействительными.
или что скрыли ** Txs от нас. Ранжирование узлов, которые рекомендовали в черный список узел
последние 2 года снижается на 95%.
2. Доказательство работы жечь сделано для этого конкретного ключа. (Топ 10 мы можем подключиться)
3. Задержка. (Топ-5)
4. Как долго мы знаем, что узел и получили сообщения от него. (Топ-5)
5. ли другие узлы, которым мы доверяем "рекомендовать" этот узел. (Топ-5)
(То есть., Если кто-то побежал узел на два отдельных устройства, они, конечно, рекомендовать их собственные узлы)

25 коллег для 10 ^ 6/512 = 1953 куска диапазонов с 2000 байтами данных ID каждый из них будет иметь фиксированную 100 Мб стоимости.

Перед тем, как блок будет считаться действительным узлом потребует 15 из 25 своих коллег в кусок, чтобы подписать на их
Кусок * и по меньшей мере один равный по типу группы сверстников (например. Верхняя история, верхний ожог, верхний пинг и сверху рекомендует).

* Блокирующий из-за недопустимый диапазон сценариев будет основываться на Merkle ветвь доказательства, показывающий, что ТЙ будучи
двойной израсходованы и что узел подписал свой выбор сценария действительным.

** Blacklisting в связи с удержанием будет основываться на подписи от нечестного узла, вся информация
разделял, хотя это не было. (Диапазон Кусок включает в себя соответствующие TXS 1, 2 и 3 в то время как нечестный узел подписан
что 1 и 3 были единственным значимым)

- 5,6 BLACKLIST REPORTS-
Чтобы подтвердить сообщение об ошибке вы бы только получить обижая кусок, эфир, чтобы проверить Merkle хэшей,
для проверки отсутствия данных или для проверки недействительных сценариев.

Для проверки двойного израсходуют лишь требует Merkle ветви ранее сделок расходов.

Если сообщение об ошибке оказывается ложной ложной репортер занесен в черный список.

Отчеты об ошибках принимаются топ 95% узлы с помощью хэш-ожога / доказательства работы.

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

- 5.7 ПРОВЕРКА SCRIPTS-
Для проверки скриптов нам нужны выходные сценарии, что содержащие ссылки TX в разделе входов.

Когда упомянутые выходы не известны к узлу он будет запрашивать этот TXS от узла, известного процесс,
Диапазон ломоть.

Поскольку Txs сортируются по их хэшей в блоке и так, следовательно, каждый фрагмент будет иметь самый высокий хэш что мы можем
несколько легко отслеживать, какой кусок хэш находится.
Мы делаем это, поддерживая таблицу высочайших кусков на номер блока (3,3 Гб / год).

Используя таблицу, а другой узел, мы просим и получаем искомую TX.

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

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

- 5.8 ОБОСНОВАНИЕ BLOCK SIZE -
Для проверки блока размеров узлов проверить размер их чушки операций и подписывает на ней то есть. "Кусок 45 1,7 кб подписан",
Все узлы могут затем быстро отсчитывать 1954 размеров добавить их и посмотреть, если он находится ниже предела.

Если узел видит разные размеры для того же куска узел нарушитель может быть занесен в черный список после получения ломоть и проверки его
размер.

- 5.9 ОБОСНОВАНИЕ Общая сумма вознаграждения -
Тот же механизм используется как для размера в разделе 5.8.

Общая сумма вознаграждения, затем также по сравнению с coinbase сделки.

- 5.10 ПРОВЕРКА ДЛЯ DOUBLE ПРОВОДИТ -
Каждый узел хранит таблицу, индексированную скрипт хэш, содержащего список неизрасходованных хэш транзакций и расходы TX хэш на индекс.
То есть. список кортежей упорядоченных по индексу сценария хэш.

Для экономии дискового пространства узлов жестких не будет хранить полную информацию о сделках в их диапазоне сценариев. Вместо этого они хранят то, что
в их пределах куска и попросить любую другую информацию, TX от других узлов.

Поскольку каждый узел обрабатывает роя небольшое подмножество полосы пропускания blockchain является более дешевым ресурсом, чем дисковое пространство, а не большое беспокойство.
(Соединение A 1 Мб / с можно заполнить 31 Тб диск в течение одного года - наши роя узлы используют только 15.6GB)

-- 6 НОМЕР CRUNCHING--
- 6.1 Хранение Требования в год -
Эти цифры 1000000 транзакций в блоке, и с каждым узлом обработки транзакций 512 рой
каждый.
Каждый узел будет хранить ровно 512 транзакций из своего диапазона порции и около 512 транзакций
от его диапазона сценариев для каждого блока.

Мы не храним диапазон сценария Txs, только диапазон ломоть. Сохранение данных диапазона сценариев будет стоить почти 30 ГБ / год. Вместо этого мы храним только таблица TX хэшей в нашем ассортименте сценария
и TX хеши их расходов операций.
При необходимости мы забираем диапазон сценариев из наших коллег, что означает дополнительное использование полосы пропускания. Это, однако, не является проблема, так как нашего годового использование полосы пропускания слежения небольшого подмножества
из blockchain является довольно низким.

8.9 ГБ для порций транзакций (ср. 330 байт / TX * 512 * 6 * 24 * 365).
3.4 ГБ для расходов TX Хэши ((32 TX хэш + 32 * 3 ср. Выводит расходы TX хэширует) * Диапазон расходов 512 * 52560 блоков / год сценария TX хешей.)
(Log2 (10 ^ 6 Txs) * 32 = 640 байт дополнительных на TX в информации Merkle филиала)
3.2 гб для TX хэша, чтобы блокировать и чанку индексации. (1954 высокий кусок хэшей в отсортированном порядке * 32 байт в хэш * 52560 блоков / год)
~ 0,1 ГБ для черных списков и репутации узла информации (+ ~ 1gb фиксированной один раз стоимость).

Использование соединения, вероятно, будет до 10 раз эта сумма (в основном опрос неизвестных выходов), так что 156 ГБ в год
или 0,005 Мб / с - много, чтобы сэкономить там.

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

Другими словами, обычный ПК с 100 $ 1TB HD с использованием ничтожное широкополосного может запустить узел роя и помочь бежать
сеть Bitcoin на 1600 TPS 32 (!) лет и использовать только половину диска.

Понадобится лишь 1954 таких компьютеров приравнять один полный узел - так небольшая группа энтузиастов может запустить
Вся Bitcoin сети на уровне VISA, даже если все остальное не удалось.

- 6.1 ОЦЕНОЧНЫХ полные копии AT 1600 TPS -
При такой рыночной капитализации, было бы справедливо предположить, что лишь немногие крупные компании и шахтеров работать нормально полные
узлы в то время как намного больше ассортимент небольших компаний и частных лиц, будет работать под управлением роя узлов.

Если есть 2 миллиона bitcoiners сегодня и в результате 6000 полных узлов - что сегодня требуется примерно такой же, как
рой узел будет в 1600 TPS - мы можем попытаться экстраполировать.
На уровне VISA можно было бы ожидать, что-то вроде 0,7 миллиарда пользователей, и если отношение имеет 0,5-2 млн роя узлов.

В 1600 TPS это будет приравнивать 255-1023 полные копии blockchain размещенного в очень разнообразные, надежном и децентрализованном
путь.

-- 7 КРАТКОЕ SUMMARY--
- 7.1 ЧТО SWARM NODES SIGN / VALIDATE -
1. Срок действия сценария диапазона сценариев и диапазон порций.
2. Ни один удерживаемый не претендует на куски.
3. Ни один двойной тратит в пределах сценария (на основании каких-либо подписей удержанных другими узлами).
4. размер Chunk и общие сборы.

- 7.2 SWARM узлы ДЕЛИТЕЛЬ -
1. Кусок диапазоны.
2. Сценарий диапазонов.

- 7.3 КАК СДЕЛАТЬ ЭТО -
Первый вариант может быть сделано, когда все узлы доверяют друг другу. Это позволит исключить необходимость черных списков и другого кодекс, касающийся
доверие коллег.

Это может затем быть добавлены позже на досуге.