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

Цель: Моя главная задача в том, что с по-цепи масштабирования, наша blockchain может расти в размерах в несколько петабайт, в течение нескольких десятилетий, и как емкость сети и жесткие требования к дисковому пространству будут вне развивать нашу способность поддерживать тех.

Концепция:
2016 [блок 0] ... [блок п] --- баланс последнего блока мог бы перенести в новый блок генеза 2017 года.
2017 [блок 0]

Баланс (все utxo) каждый адрес копируется в новый Masterblock в качестве одной транзакции. Masterblocks создаются детерминированным образом, так что каждый узел может видеть и воспроизводить правильность Masterblock.

Затем Mining должны начать строить на новой цепи. Просто история сделок будет потеряна.

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

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

Эта идея, если она работает, будет означать, что Bitcoin будет бить Visa х 10 сделок, с целью разорвать 1 миллиард операций в день, в децентрализованном порядке.

NOTE1: Blockchain обрезки, как это делается в Bitcoin имеет очень плохие побочные эффекты, а именно: невозможность запуск новых узлов из них и делают полное пересканирование. Мой подход не имеет таких недостатков. https://news.bitcoin.com/pros-and-cons-on-bitcoin-block-pruning/

Разъяснение 01: новый термин: Давайте переименовать наш так называемый новый Genesis блок в Masterblock. (для ясности)

Разъяснение 02: New Masterblock должен быть сгенерирован детерминированным образом, чтобы быть воспроизводимым всеми шахтерами и Full Узлов.

Разъяснение 03: крошечные количества пыли могут быть распространены последние 1000 шахтеров.
Давайте определим «пыль» в качестве выходов сделки ниже медианной платы за последние 100 блоков.
(Это снимает кучу наворотов от blockchain)

Разъяснение 04: Старая цепь не получает немедленно удалена, но только после того, как Y блоков (скажем, через 1 месяц).
Это означает, что новые узлы, подключенные к сети в течение этого периода можно загрузить как новую цепь и старую цепь, может проверить новый Masterblock путем перерасчета ее от цепи в прошлом году.

Разъяснение 05: Q: Что делать новые узлы, когда они приходят в Интернете после того, как этот один месяц прошел? Как они проверяют правильную цепочку с нуля?
A: консенсус должен работать следующим образом:

1. То же, что в настоящее время (длинная цепь) и
2. текущая метка времени (2017 год) - доказательство работы должны включать в себя временную метку.
(Если он находит очень длинную цепочку, но со старой временной меткой, как 2015 или 2016, он отвергается, будущие временные метки также отклонены)


TODO: Исследовать новый вектор атаки: NTP протокола / неправильное время. (На данный момент моя идея требует, чтобы администратор вручную настроить часы на критических производственных систем, таких как платежные системы Может быть, мы можем решить эту проблему позже.). - Может быть, мы можем решить с помощью идеи криптографической времени - отдельный блок- цепь для хронометража, с тем же SHA256-корректуры из-работы и той же сложности, как основной цепи, которая не сбрасывается на каждом Masterblock - это непрерывно. Следует объединить-добыты вместе с первичной цепи блока. В основном Раздельное Time - 'SegTime.

Примечание: Новая проблема: Моя идея, как написано сейчас, аннулирует специальные TX-выходы, такие как замок время и multisig. Но, возможно, есть элегантное решение этой проблемы тоже ... -. Что-то вроде расширенного блока, который будет записан в Masterblock, и перечислить все предыдущие специальные операции в неизрасходованных ТХ выходах, как действует)

================
Хорошо, Давайте делать некоторую математику:
4 ГБ каждый блок 10 мин =. Это позволит нам на 1 млрд ТХ / сут. В Bitcoin она будет равна 144 блоков / день х 4 Гб / блок = 576 Гб / день.

Это 576 Гб / день х 365 (год) = 210 ТБ-в-год.

Без моей идеи мы будем расти на территорию с несколькими петабайт в течение 5 лет. Будет трудно, даже с хорошим аппаратным сервером класса.
С моей идеей было бы принять только 18 жестких дисков (в порядке 20 жестких дисков, с RAID6), чтобы держать весь блок цепи (это предполагает большие жесткие диски 12 ТБ, что и Seagate и Western Digital начала производить в этом году).

Распространение блока? Он занимает всего 8 секунд на Google Fiber (1 Гбит / с Интернет) - поэтому я считаю, что это очень возможно и целесообразно выращивать с по-цепочке транзакций масштабируемости.
================

Что ты думаешь об этом?

-Technologov
05.Mar.2017
ОБНОВЛЕНИЕ на 02.04.2017

Ссылка:
https://github.com/BitcoinUnlimited/BitcoinUnlimited/issues/340