1  Работать(теоретически) такое может, но вот только это уже нифига не блокчейн - а просто срез всех счетов на какой-то момент времени.

2  Не факт что не израсходованных адресов будет меньше, а не больше - скорее всего больше тк каждая транза обычно имеет 1 вход(как бы - сумму) и много выходов...

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


PS  оптимизация с цепочкой доверия получается?..
(например дома на большом сервере храните весь блокчейн и считаете сами такой срез, а на мобильном устройстве проверяете только последнии блоки от среза, установив доверие своему домашнему серверу, или кому-то еще...)

Хм... Почему это "цепочка доверия"? Хочешь сказать, что данные при автооптимизации блокчейна - можно подделать?
Так как блокчейн до N-ного блока (в вышеизложенном примере - это 1000000-й блок) - во всей децентрализованной сети,
он один единственный, то и хэш у него - один единственный.
Его может пересчитать любая нода, перед отбрасыванием старого блокчейна и перед переходом на новый.
А все остальные форки блокчейна должны быть просто подвержены оверрайду, при попытке соединения с основной сетью,
ведь эти форки могут существовать только в подсетях децентрализованной сети, несвязанных с основной сетью.
Но... Возможно ты и прав, в той части, что если существует много обособленных подсетей, несвязанных с сетью,
то может быть и множество форков блокчейнов, в последствии подвеграющихся автооптимизации, и ещё раз и ещё раз...
И так, пока подсеть не связана с основной сетью.
И после установления связи подсети с основной сетью, не совсем будет понятно какой же из оптимизированных блокчейнов - валидный.
Но в любом случае, первый блок, GENESIS-block, он как правило общий для любой подсети, и обычно вшивается даже - в открытый и диверсифицирующийся исходник, вместе с checkpoints.
Поэтому, начиная с первого блока можно запустить проверку ВСЕГО БЛОКЧЕЙНА,
для обнаружения разветвления основного блокчейна.
Для этого, нужно ЕГО наличие ПОЛНОСТЬЮ и доступность его - в сети (по тем же magnet-ссылкам из первого поста).

При наличии определённых параметров сети, вшитых в первый блок нового блокчейна,
таких как, например:

• суммарный хэшрейт сети,
• сложность Proof-Of-Work майнинга одного блока в сети,
• вес всех монет которыми осуществляется Proof-Of-Stake во всей сети,
• или сложность Proof-Of-Stake майнинга
• или что-то ещё...

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

Всё-равно старые транзакции просто выкидывались бы из блокчейна, в результате его автооптимизации.
Он весил бы намного меньше, синхронизировался бы - намного быстрее, и конечно же количество блоков в нём было бы меньше.
А так, имеем что имеем... Если пройти на https://etherscan.io/ видно, что там уже 8421470 блоков.
Занимает, вроде, всё это дело - уже больше терабайта.
Основная инфа что содержится там, внутри, так - это транзакции старые, в том числе и транзакции эфиротокенов,
возможно уже давно неактуальных токенов, и транзакций - на адреса, приватные ключи от которых уже давно утеряны.
То есть тупо шлак.
А теперь, представь следующее...
Человек хочет поставить себе ноду.
Купил себе ОТДЕЛЬНЫЙ ТЕРАБАЙТНЫЙ ДИСК, купил его давно, а там - НЕ ХВАТАЕТ МЕСТА УЖЕ.
Купил четырёх-терабайтный... И...
Сколько же ВРЕМЕНИ он будет ждать синхронизации ВСЕГО этого блокчейна??
А валидации блоков его, в результате поблочного парсинга, а??
Я вон, WAVES-блокчейн с его >1600000 блоками - пятые сутки уже валидирую.
Хочется взять и удалить нафиг всё.

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

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

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

То, что ты описал выше, не есть вышеописанная мною "автооптимизация".
Это, скорее - просто ричлист на N-ном блоке, возможно даже с неизрасходованными выходами.
Да, такая фича юзабельна, ведь не надо парсить весь блокчейн до N-ного блока,
чтобы узнать лежат ли монеты на конкретном адресе (и возможно конкретном неизрасходованном выходе) или не лежат.
Но да, такой ричлист требует доверия его генератору, ведь туда, при его формировании - может быть вшиты какие угодно данные.
Да, если он корректен, то можно продолжать парсить основной блокчейн,
начиная лишь с N-ного блока, а до него - опираться на этот вот самый - rich-list.

Однако, как я уже написал выше - это не есть та самая моя "автооптимизация",
ведь ричлист этот, по сути, не является "автооптимизированным блокчейном"
- и с него не продолжается майнинг в основной сети,
и новые блоки в этой сети, выходят, цепляясь именно - к N-ному блоку,
то есть, продолжая основной, старый блокчейн,
который при установке ноды, всё-равно придётся выкачивать полностью,
и парсить тоже полностью, и валидировать там чё-то, пробегаясь по нему полностью,
и раздавать его - тоже полностью, что в течении тысячи лет - сожрёт весьма дофига трафика, если нода будет онлайн.

Я риплом не пользовался.
Мне достаточно взглянуть здесь на Total Supply 99 991 371 628 XRP,
чтобы отбросить его как обычный премайнутый альткоин, причём с премайном - вкрай извращённым.

Поэтому, понятия не имею что там за счета, и почему они платные.
Наверное из-за нагрузки на ноды при достижении консенсуса?

Блокчейн должен быть, в децентрализованной сети, ведь именно блокчейн,
согласно самой идее Сатоши Накамото - исключает возможность двойных трат в децентрализованной сети.
А на счетах во всяких "сетях доверия" - могут что угодно нарисовать кому угодно, и в каком угодно количестве,
я уж молчу о том, что в разных подсетях, могут быть копии, дающие возможность осуществлять двойные траты.
С блокчейном же, такое не прокатит, особенно если система работает по принципу неизрасходованных выходов - UTXO.
И знаешь почему? Да потому во всей сети - только один блокчейн работает, и принят всеми.
Все другие блокчейны - просто оверрайдятся, по какому-либо критерию: меньшая длина блокчейна, например.


Таким образом, в основном блокчейне, трата либо есть, либо её нет. Две траты - быть не может в нём.
А все остальные блокчейны, которые покороче - они просто будут заоверрайжены им, этим основным блокчейном.

Двойные траты исключаются блокчейном, ещё сильнее - тогда,
когда для транзакций в системе - используется принцип неизрасходованных выходов (UTXO).
В противном случае, транзакцию с адреса можно подписать и отправить в сеть - повторно, чуть позже,
и если timestamp она не содержит, также как RAW-транзакции биткоина,
то такая транзакция может быть повторно включена в блок блокчейна, что привело бы - к двойной трате.
А у биткоина - нет, ведь там используются неизрасходованные выходы,
и если монет на конкретном выходе нет и они уже растрачены, такая транзакция просто будет отклонена.
И без UTXO возможны попытки отправки одной и той же транзакции, и возможно даже - принятие нодами/майнерами их,
и повторное включение их в блоки...
Ведь для проверки того, что средства уже потрачены - надо будет парсить весь блокчейн...
Или опять же - использовать динамически формируемые - ричлисты, просто чтобы сверять баланс,
а эти данные, в какой-то момент - могут быть просто сфальсифицированы...

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

Ты не совсем так меня понял.
В изначальном, первом посте, я писал не о загрузке из torrent "среза блокчейна" (автооптимизированного блокчейна),
а возможности загрузке - самого блокчейна, содержащего [0 - 1000000] блоков, который был до оптимизации.
При этом, поскольку блокчейн этот может быть загружен из torrent'a, то его архив, как файл - он имеет хэш,
а хэш этот может быть включён в magnet-ссылку,
коротенькую ссылку, которая позволяет выкачать весь блокчейн в виде архива - из децентрализованной сети, из torrent'a.
Сама же magnet-ссылка эта, она может быть включена в первый блок автооптимизированного блокчейна (среза),
и перед принятием этого блока - весь блокчейн может быть верифицирован.
Может быть просчитан его хэш, содержащийся в той же magnet-ссылке, например.

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

Что касается "_собственноручной_ проверке _всей_ цепи",
я не думаю, есть какой-то смысл в том, чтобы парсить блоки старого блокчейна,
для проверки корректности - первого блока нового,
достаточно хэш всех данных посчитать и сверить, ведь хэш - считается гораздо быстрее,
тогда и в блоки можно не смотреть, и даже можно не распаковывать из архива - выкачанный старый блокчейн.
Но да, для проверки со стороны, старый блокчейн надо будет всё-же выкачать целиком, или частями (если торрент),
можно одним файлом, в архиве, а можно части в архивы запихнуть.
Но не в этом дело. Дело в том, что кому это надо?
Просто вот взять и проверить первый блок нового блокчейна?
По причине недоверия узлу его запушившиму?
Ну вот алгоритм, выкачивай себе, проверяй, и т. д.
А так-то при замене старого блокчейна на новый,
ноде его и выкачивать же не надо, ведь он уже есть на ноде.
Она может без выкачки просчитать хэш старого блокчейна,
и если он совпадает с хэшем, указанным в первом блоке нового,
то весь старый блокчейн - заменяется на новый, и удаляется нафиг.
При этом команда замены и удаления, могла бы быть закриптована
и подписана цифровой подписью ноды,
а исполнена - после проверки её цифровой подписи - сетью.
Таким образом, нода, валидировавшая новый блокчейн,
после проверки старого, и заменившая старый блокчейн на новый,
является подписантом результата валидации,
а он, этот результат - может быть уже расшарен в сети и перепроверен другими нодами,
как и цифровая подпись ноды - тоже может быть проверена.
Тогда вопрос доверия, я думаю, сам собой отпадает.

А что касается удаления старого блокчейна после замены его на новый...
Можно его и не удалять, а продолжать раздавать - сидировать, так сказать, для тех, кому надо его выкачать.
Но не синхронизировать. Синхронизировать - только новый блокчейн, начиная с первого его блока.
Так и быстрее намного, и с нуля начать проще - кто ноды в первый раз ставит на 5-ти миллионном блокке,
ему не надо будет ВСЁ ТО ЕЩЁ выкачивать и чё-то там валидировать.
Ну а чтобы не хранить по копии старого блокчейна на каждой ноде,
с учётом того, что новые ноды не синхронизируют его,
а синхронизируют только новый блокчейн с первого его блока,
то можно было бы разбить старый блокчейн на части, а их уже - диверсифицировать между нодами.
Например, на одной ноде части [1-5000], на второй [5001-1000], [...-...], на последней [995000-1000000] -
получается, что по 5к блоков всего старого блокчейна на каждой ноде может храниться.
Таким образом, достаточно лишь 200 нод в сети, чтобы выкачать весь блокчейн от 0-го до 1000000-го блока,
и место экономится, и старый блокчейн - всегда в сети, он доступен к выкачке с децентрализированной сети, по частям.
К тому же, его можно было бы и выкачать полностью, с любого места, и как-бы "захостить" его, целиком, у себя,
так сказать - засидировать, встать на раздачу его.
А так-то, для каждой новоявленной ноды, может вгружаться лишь 5к блоков старого блокчейна,
из какого-либо диапазона (с наименьшим аптаймом, например) + первый блок нового,
с которого начинается более быстрая синхронизация нового, автооптимизированного, более короткого блокчейна.

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

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

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

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

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

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

И, в случае выгрузки старого блокчейна с конца,
закачка его, могла бы происходить - уже при рабочей сети,
синхронизированном новом блокчейне, и намного позже.
Ведь, в случае невалидации первого блока нового блокчейна,
синхронизация всё-равно могла бы происходить с него,
и вне зависимости от текущей длины ВСЕГО БЛОКЧЕЙНА - происходить быстро,
позволяя основной сети работать на новом блокчейне,
а вот валидация его, и возможно, оверрайд - могли бы происходить намного позже,
после загрузки блокчейна, на уже работающей ноде...

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

И если что пойдёт не так, например свет мигнул из-за перепада напряжения, то...
ПЕРЕСИНХРОНИЗАЦИЯ И ПЕРЕВАЛИДАЦИЯ, ЕЩЁ НЕСКОЛЬКО НЕДЕЛЬ, ААААААА!!!!!!

Осталось теперь это стандартизировать, унифицировать, запрограммировать, а исполнение запрограммированного - автоматизировать. 

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

2  Биткойнеры попутали децентрализацию и распределение - то что они слепили это не distributed, а просто тупо миллионы копий всего центра!   Отсюда - и проблемы с масштабированием...
(про качество всего остального кода тихо помолчу - но многие сделали новые проекты с нуля, это оказалось легче чем разбираться в готовом коде биткойна!
Тот-же Виталик например сразу работал над цветными монетами для биткойна...)


PS  разделить приходные и расходные операции интересно еще никто не догадался?..