Topic: Автооптимизация блокчейна - урезанием (Read 248 times)

Ок.

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

Можно. Есть лёгкие кошельки, тот же Electrum, или веб-кошельки.
Например https://www.blockchain.com/ru/wallet#/login
Там уже есть блок-эксплорер, с полностью синхронизированным блокчейном: https://www.blockchain.com/ru/explorer
Так вот, в том веб-кошельке, после захода в акк, можно импортировать privkey в аккаунт и платить с адреса,
которому соответствует этот privkey, и на котором лежат монеты биткоина.
И никакой синхронизации не нужно.

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

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

Какой такой рандомайзер? Как он по-твоему, должен бы ускорить проверку?
В рандомном порядке что-ли блоки проверять?
Так они же сцеплены друг с другом через сами хэши этих заголовков блоков:
https://hsto.org/webt/sy/0t/r5/sy0tr5wr3a814bs81gp0xte4tmw.png
Видишь?
Ты можешь выкачать отдельно из сети, блок номер 2,
например в JSON, вот здесь
И даже, можешь проверить хэш заголовка.
То же самое, ты можешь сделать для блока 3.
Более того, ты можешь сравнить хэш заголовка блока номер 2, с хэшем внутри заголовка блока 3.
Если они совпадают, то блоки 2 и 3 - последовательны в блокчейне. Иначе - блок 3 некорректен.
Но тот факт, что блоки 2 и 3 они идут друг за другом, и проверены, вовсе не означает, что они вообще принадлежат блокчейну,
пока ты не проверишь в блоке 2 хэш блока 1.
Таким образом, исходя из вышеописанноно,
самым оптимальным вариантом проверки - является именно последовательная проверка всех блоков,
а не какая-то фрагментарная и/или - рандомизированная.
Хотя, конечно же, можно было бы и заранее прохэшировать длиннющие блоки,
и чтобы их не перепроверять - забить их хэши внутрь софтины.
Так оно и делается. Называется это, походу, checkpoints, если мне память не изменяет.

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

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

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


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

Я слабо разбираюсь в технической стороне вопроса. Поэтому попрошу сильно строго не судить и тапками не бросаться)

Если упростить все до уровня на котором понятно станет и обычным людям, то говоря о блокчейне мы имеем две основных проблемы:
1. Большой, постоянно увеличивающийся вес из-за которого хранить блокчейн довольно проблематично.
2. Если я стану новой нодой, то мне предстоит долгое и томительное ожидание, покуда моя версия блокчейна не окажется сверена с остальными нодами сети и подтверждена? А это означает полную проверку каждого блока начиная с первого и до актуального.

Почему в первом случае нельзя просто хранить весь блокчейн в облаке, позволяя нодам обрабатывать определенное кол-во новых блоков, а после отбрасывать их в это облако? Замутить синхронизацию с этим облаком для того чтобы можно было время от времени сверять версии блокчейнов на разных нодах? Но проверять при этом не каждый блок. Почему вместо того чтобы проверять каждый блок, нельзя использовать в системе рандомайзер? Допустим блокчейн сам генерирует номера блоков и выбирает порядок их проверки. Разве это не существенно снизит длительность проверки и не будет быстрее даже чем проверять просто заголовки каждого блока?

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

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

У меня тоже были идеи, как можно сократить постоянно увеличивающийся размер блокчейна на примере Bitcoin. Правда, кода пока нет, но алгоритм был описан в моей теме в разделе "Кодеры":
Способы отсечения старых блоков в блокчейне

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

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

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

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

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

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

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

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

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

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

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


Чтобы нода могла проверить хеш блокчейна ей нужно скачать весь этот блокчейн. Тогда в чём смысл? Блокчейн и сейчас "расшарен в сети". Какая разница как раздавать блокчейн: через торрент или через ноду? 

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

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

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

Дак опять возвращаешься либо к _собственноручной_ проверке _всей_ цепи, либо выкачивания готового - но тогда доверия не избежать...

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

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

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


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

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

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

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

короче идея счетов вместо блоков реализована в риппле, но там пришлось фактически делать счета платными - как думаешь почему?..

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


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-ному блоку,
то есть, продолжая основной, старый блокчейн,
который при установке ноды, всё-равно придётся выкачивать полностью,
и парсить тоже полностью, и валидировать там чё-то, пробегаясь по нему полностью,
и раздавать его - тоже полностью, что в течении тысячи лет - сожрёт весьма дофига трафика, если нода будет онлайн.

Уже есть такой тут https://bitcointalksearch.org/topic/ttc-tdc-2254304   https://neiros.github.io/

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

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

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


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

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

Для чего это надо?
1. А чтобы у старых монет не было длинных блокчейнов, с кучей неактуальных транз сдохших токенов, как у эфира, например.
2. Чтобы синхронизация быстрее шла на нодах и кошельках.
3. Чтобы без проблем можно было поставить ноду, и быстро синхронизировать её, не выделяя под блокчейн - терабайты.

Как я это вижу?
1. С определённого блока, скажем, с 1000000-го весь блокчейн парсится на наличие монет на неизрасходованных выходах у различных адресов.
Генерируется rich-list https://bitinfocharts.com/ru/top-100-richest-bitcoin-addresses.html для всех адресов.
2. Извлекаются адреса и количества монет на неизрасходованных выходах.
3. Этот блокчейн архивируется, заливается куда-нибудь в torrent. Формируется magnet-ссылка на архив в сети torrent.
4. magnet-ссылка на архив со старым блокчейном - суётся в первый блок нового блокчейна.
5. Затем, в этот блок включаются транзакции зачисления монет всем юзерам, причём только монет на неизрасходованных выходах.
В результате, получаем новый блокчейн. В нём всего пару блоков с транзакциями зачисления монет предыдущим пользователям.
Новый блокчейн продолжает майнится, как ни в чём ни бывало. Синхронизация проходит быстро.
И главное - никто из предыдущих владельцев не теряет монеты и доступ к ним.

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

Но старых транзакций из предыдущего блокчейна, в новом блокчейне уже не будет.
Они просто выкидываются, чтобы не жрать трафик при синхронизации.
Однако, так как старый блокчейн может быть доступен по magnet-ссылке,
то его можно было бы выкачать из torrent'a, пропарсить, и восстановить список старых транзакций.

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

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