IV.ХРАНЕНИЕ

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

A. Балансировка нагрузки

Чтобы добиться равномерного распределения фрагментов по сети, мы используем технику, основанную на последовательном хешировании [19]. Напомним, что у каждого фермера есть самоназначенный идентификатор в качестве хэша их открытого ключа, который мы можем сопоставить с кольцом в домене хэш-функции. Если фермер не может сохранить полную копию на своем участке, он предпочитает части, идентификатор которых наиболее близок к его собственному идентификатору на кольце, вплоть до размера сектора, предоставляемого его хранилищем. В противном случае он просто хранит столько полных реплик и одну частичную, сколько позволяет его хранилище. Эта схема имеет преимущество рассеивания истории, так что большая часть сети должна быть отключена, чтобы стереть любой отдельный фрагмент, в то же время обеспечивая, чтобы по мере увеличения числа фермеров присоединяйтесь к сети средний коэффициент репликации для любой части будет приближаться к коэффициенту репликации главной книги. По мере роста истории фермеры сканируют новые участки, сохраняя только те, которые попадают в их (сокращающийся) самостоятельный сектор, в то же время выселяя тех, кто находится на границах.Это означает, что каждый фермер будет пересчитывать половину своего участка каждый раз, когда история удваивается в размерах. Однако, в отличие от первоначального построения графика, это вычисление амортизируется в течение гораздо более длительного периода времени, так что оно налагает незначительные дополнительные накладные расходы. Чтобы свести к минимуму повторное построение графиков для ранних фермеров, сеть будет заполнена несколькими терабайтами данных в genesis, включающими историю нескольких ведущих блокчейнов. В то время как пассивный фермер мог бы отклониться от вышеуказанной стратегии, мы отмечаем, что для этого мало стимулов, поскольку это никак не повлияет на их функцию вознаграждения. В лучшем случае это сэкономит им незначительное количество вычислительных затрат. Лучшей стратегией было бы вместо этого увеличить их емкость хранилища в соответствии с ростом истории, чтобы размер их сектора оставался постоянным, позволяя им сохранять свои в противном случае допустимые кодировки вдоль ограничений. Фермер также может использовать стратегию sybil, в которой они генерируют множество идентификаторов, позволяя им создавать множество небольших частичных копий из одного и того же небольшого фрагмента истории. Хотя это все еще не влияет на их функцию вознаграждения, это может значительно сократите затраты на пропускную способность на начальном этапе построения графика. Чтобы предотвратить такое поведение и вместо этого поощрять фермеров хранить как можно больше полных копий, мы требуем, чтобы каждый фермер отвечал на вызов своим идентификатором.

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

B. Надежность

Чтобы получить уровень надежности, на много порядков превышающий простую репликацию, мы применяем хорошо известную технику кодирования стирания [20]. Конкретно, в начале каждой новой эпохи история какой-либо прошлой эпохи теперь может быть использована в качестве основы для обоснованного решения. Мы начинаем с разбиения каждого блока из недавно подтвержденной эпохи на блоки постоянного размера из k исходных фрагментов. Затем мы применяем код стирания с половинной скоростью, чтобы получить дополнительные k единицы четности. Обратите внимание, что фермеры сохраняют и кодируют только исходный код или четные фигуры, которые попадают в их сектор кольца. Наконец, мы строим древо Меркле по всем n частям в партии. Поскольку партии редко аккуратно совпадают с отдельными блоками, мы объединяем части по многим блокам до тех пор, пока не будет получен желаемый размер партии. Затем мы создаем гораздо меньшую цепочку заголовков состояний, которая просто привязывается к корню Меркле каждой партии. Это позволяет фермеру-победителю доказать, что некоторая кодировка, удовлетворяющая аудиту, фактически получена из подтвержденной истории, не требуя от фермеров или проверяющих ведите историю сами. Вместо этого они требуются только для поддержания гораздо меньшей цепочки заголовков состояния, которая может быть дополнительно сжата только до корней Меркле после начальной синхронизации.

C. Возможность извлечения

Чтобы гарантировать, что история остается полностью доступной для извлечения и, следовательно , доступной, мы используем упрощенную версию распределенного Хэш-таблица (DHT). Обратите внимание, что понятие расстояния между идентификаторами фигуры и фермера на кольце эквивалентно метрике XOR, ключевому компоненту Kademlia DHT [21]. Если мы упростим K-DHT таким образом, чтобы каждый фермер объявлял только свой идентификатор и контактную информацию, любой узел может затем получить фрагмент, просто найдя фермера, чей идентификатор достаточно близок к фрагменту на расстоянии XOR, прежде чем запрашивать фрагмент у этот фермер. Это превращает K-DHT из универсального хранилища значений ключей в своего рода децентрализованную службу доменных имен. Накладные расходы на хранение DHT на каждом узле невелики даже для большого числа фермеров, и для поиска какой-либо конкретной детали потребуется не более нескольких переходов. Чтобы обеспечить эффективную пропускную способность и сбалансированную загрузку фермерского сектора на начальном этапе построения графика, мы можем адаптировать продуманный подход, впервые предложенный сетью BitTorrent, путем разделения, мультиплексирования и потоковой передачи запросов между многими близлежащими одноранговыми узлами. Основанный на успехе BitTorrent, мы ожидаем, что оптимистичная политика обмена частями " tit-for-tat " в сочетании со значительно сниженными наложенными расходами, необходимыми для работы узла DHT, и ожидаемой балансировкой нагрузки запросов на всех узлах приведет к тому, что достаточно большая часть фермеров будет делиться своими частями без каких-либо прямых финансовых стимулов [22]. Аналогичный подход, используемый Arweave, сетью постоянного хранения данных на основе блокчейна, работает на практике в течение нескольких лет [23]. Обратите внимание, что эта схема позволяет извлекать только отдельные фрагменты, если их идентификатор известен ранее, так как они адресованы содержимому. Мы можем обойти эту проблему, если вместо этого будем обращаться к фрагментам по хэшу их индекса по мере их создания, позволяя узлам легче извлекать определенные периоды истории. Мы также можем расширить эту схему дополнительным уровнем распознавателей, чтобы обеспечить эффективное извлечение определенных блоков, транзакций или любого произвольного объекта по идентификатору, как это часто требуется клиентам light. Для достижения этой цели каждый фермер выделяет небольшой настраиваемый объем памяти, в которые они сохраняют сопоставление между теми распознавателями, которые ближе всего к их идентификатору, и индексом фрагмента, в котором хранятся базовые данные. Затем легкий клиент может запросить какой-либо объект с помощью Идентификатор, получение его индекса хранения, прежде чем извлекать полную часть и извлекать необходимые данные. Фермеры могут по желанию поддерживать кэш тех товаров, которые наиболее популярны в самом DHT.

D. Стоимость хранения

Чтобы гарантировать, что объем истории не превысит общую емкость сетевого хранилища, мы модифицируем механизм платы за транзакции таким образом, чтобы он динамически корректировался в зависимости от коэффициента репликации . Напомним, что в BTC базовая ставка комиссии зависит от размера транзакции в байтах, а не от суммы переводимого BTC. Мы расширяем это уравнение, включая множитель, полученный из коэффициента репликации. Это устанавливает обязательную минимальную комиссию за каждую транзакцию, которая отражает стоимость ее постоянного хранения. Множитель пересчитывается каждую эпоху, исходя из предполагаемого сетевого хранилища и текущего размера истории. Чем выше коэффициент репликации, тем дешевле стоимость хранения на байт. По мере приближения коэффициента репликации к единице стоимость хранения асимптотически приближается к бесконечности. По мере уменьшения коэффициента репликации плата за транзакции будет расти, что сделает фермерство более прибыльным и, в свою очередь, привлечет больше мощностей в сеть. Это позволяет стоимости хранения достичь равновесной цены в зависимости от предложения и спроса на пространство.