Почему бы не просто хранить блоки через равные промежутки времени? Что такое преимущество, что делает его (псевдо) случайных?
У меня есть X гигабайты сегодня, что я хочу внести свой вклад в сети Bitcoin. Я хотел бы, чтобы использовать все, что X как можно скорее.
Но я не хочу быть в ситуации, когда в сети растет распределение блоков хранятся становится неоднородным. Например. потому что я использовал мое пространство, а затем несколько блоков появились я слишком тяжелым в старых блоках ... или где моя местность становится плохой (создание соединения накладных расходов для коллег, имеющих принести лишь несколько блоков в связь).
Я не хочу, чтобы полагаться на попытки измерить мои сверстники, чтобы выяснить, какие разделы отсутствуют и нуждаются в хранении, так как злоумышленник может ложно сделать некоторые участки цепи кажется более представлены для того, чтобы сделать их непредставленными.
В конце концов, если разреженные узлы должны быть полезны для узлов в их IBD вы хотите узнать о том, что находится в пределах поддержки узлов, прежде чем пытаться соединиться с ними, так что я не хочу, чтобы сигнал больше, чем несколько байт данных указывают на то, что диапазоны я хранения, или должны постоянно поддерживать обновляемые коллег о том, что я храню, как время идет ..., как это потребовало бы много трафика.
Я хочу, чтобы иметь возможность увеличивать или уменьшать свою память, не полностью изменяя блоки я храню или смещают выбор. (Хотя, очевидно, что потребуется некоторое сообщение для указания изменения).
Так что те, по крайней мере, мотивации я в основном думали о там.
Вы знаете, является ли кто-то и намерение работать на более поздние идеях, которые вы упоминаете ниже? Я не хочу, чтобы дублировать любую работу, но я заинтересован в работе над этим набором функций, так как я считаю, что это и очень полезно, а также интересно.
Я не думаю, что кто-то кодирование на нем. Там была куча дискуссий в прошлом, так что по крайней мере с моей стороны у меня есть идея о том, что я хочу видеть в конце концов сделал (материал я изложил).
Pieter размещены на Bitcoin-разработки о служебных битов для этого ... не хотя это говорит о редкой поддержки блоков, но только бит, указывающий, что вы можете некоторое количество самых последних блоков. (Он также сделал некоторые измерения, которые показали, что вероятность запроса стала довольно однородной после того, как около 2000 блоков глубоких, очевидно, последние блоки были гораздо более часто запрашиваемым из-за узлы, находящихся на форуме в течение всего нескольких дней / недель).
Да, я знаю, что идея кэширования имеет много проблем. Я также думал о случайном удалении блоков таким образом, чтобы все узлы вместе будут иметь полную историю доступной даже если каждый узел имеет только часть - но я не пошел так далеко, как вы делали с "predicatable" блок диапазонов. Мне нравится эта идея очень много! Если вы пытаетесь самонастройки и в настоящее время не имеете подсоединенные сверстников, которые имеют отдельный блок, вы бы случайно подключиться к новым аналогам, пока вы не получите один? Или реализовать метод явным образом задать сеть "который имеет этот диапазон блоков"?
Мое мышление является то, что изначально вы должны подключиться к узлу, чтобы выяснить, какие диапазоны у него есть (например, мы просто добавить рукопожатия для этого к протоколу p2p), и вы бы просто отключить сверстник, которые не были полезны для вы, а также узнать, кто имеет то, что (например, если вам нужны блоки 1000-2000, но найти 100000-110000 вы будете знать, куда идти позже), но последнее сообщение адреса должно быть пересмотрены таким образом, чтобы он мог нести данные с ним. Так что ваши коллеги расскажут вам о том, какие узлы могут иметь блоки вам нужно.
Мое мнение таково, что отмененных файлы являются хорошей отправной точкой - они используются только для цепной реорганизации;, поэтому вопросы сетей нет с ними. Если вы держите только за последнюю пару блоков в них (или к последней контрольной точке), вы должны иметь точно такую же функциональность, как в настоящее время, не так ли? Так почему бы не удалить их до последней контрольной точки, не отключив "сеть" флаг службы, или даже делать это всегда (не только тогда, когда включен в явном виде)? Это похоже на первый логический шаг ко мне (если нет проблем я пропавший без вести с таким подходом).
Мы (по крайней мере, Sipa и I) планирование на удаление контрольно-пропускных пунктов почти полностью после заголовков первого слито. Они действительно разрушительные для рассуждения людей о модели безопасности, а также заголовки первыми удаляют практически фактические их использование. (Вместо этого они будут преобразованы в "chainwork достаточность" число, например, сколько работы лучшая цепь должна иметь, и что-то, чтобы положить бумажник в безопасный режим и выдает ошибку, если большая REORG бывает).
Отменить файлы занимают сравнительно мало места, все они сейчас составляют лишь около двух с половиной гигов ... и в отличие от блоков, если вы хотите их снова, вы не можете просто идти за ними.
В целом я обеспокоен запрещая какую-либо конкретную глубину, за которой узел должен отказаться от reorg- любого вообще или, по крайней мере, не каким-либо, что отдаленно коротко. Риск заключается в том, что если кто-то создает REORG в этом пределе они могут полностью разделить консенсус. (Например, пусть половина узлы получают один блок, который пересекает порог затем объявить REORG). Вдвойне так, если учесть, угловые случаи начального блока загрузки, например, как где вы получите узел застрял на фиктивные цепях (хотя бы часть идеи позади теста достаточности).
Является ли это O (п) подход, который вы отметили? Я не думаю, что О (п) с п быть высота блока слишком плохо.
Да, вот в принципе. Единственная причина, я не очень нравится, O (N), возможно, ваша база данных адра имеет 100000 entries- 3/4 из которых являются фиктивным мусор потушить сломанные или вредоносные узлами. Теперь вам нужно сделать изрядное количество работы, чтобы выяснить, какие всматривается вы должны попробовать.
Тем не менее, я считаю, что это теоретически возможно выбрать диапазоны для Ni, а также значения для Si таким образом, что вы получите O (журнал N):
Ni в случайном порядке [2 ^ I, 2 ^ (г + 1)),
Si = 2 ^ I
Перестройка базы экспоненциального или введения некоторых факторов, это должно быть возможно настроить сохраненную часть блоков (я не сделал математику, это просто грубая идея). Я не знаю, есть ли у какого-либо отрицательное влияние на статистических свойствах которых блоки хранятся как часто в сети экспоненциально растущих размерах диапазонов. Может быть что-то более умный также возможно.
О интересно. Я застрял, пытаясь придумать O (1), что я не думаю о форме журнала решений. Я дам, что какой-то мысли ...
Я думаю, что в целом мы хотим, чтобы иметь возможность утверждать, что если семена узла равномерно распределены, что мы ожидаем, что распределительный блок, чтобы приблизиться к однородным во все времена, как счетчик узлов приближается к бесконечности, независимо от того, как устанавливается размер. На практике я ожидаю (и надеюсь), что будет значительное количество узлов с очень большими настройками размера (например, все блоки), которые помогут даже из любой не uniformity- действительно, на мой взгляд, большая часть причины для поддержки разреженных узлы, чтобы убедиться, что каждый может внести свой вклад на любой уровень они хотят, и чтобы убедиться, что те, кто выбирают внести много хранения не полностью насыщены запросами.
Re: Обрезка старых блоков с диска
