Что такое режим обрезки света четности?

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

  --pruning METHOD         Configure pruning of the state/storage trie. METHOD
                           may be one of auto, archive, basic, fast, light:
                           archive - keep all state trie data. No pruning.
                           basic - reference count in disk DB. Slow but light.
                           fast - maintain journal overlay. Fast but 50MB used.
                           light - early merges with partial tracking. Fast
                           and light. Experimental!
                           auto - use the method most recently synced or
                           default to archive if none synced [default: auto].

Я только что попробовал, archiveпотому что у меня достаточно места и времени для полной синхронизации. Это сравнивается с размером цепочки гетов следующим образом:

 ~ $ du -hs .parity/
17G .parity/
 ~ $ du -hs .ethereum/
15G .ethereum/

Теперь я вижу, archiveчто это будет очень похоже на синхронизацию по умолчанию в eth или eth. Но что есть basic, что есть light? И это fastтот же уровень, что и geth --fast?

Что такое режим обрезки света четности? Это уже можно рассматривать как легкий клиент?

Ответы (2)

geth и parity имеют разные методы сохранения блокчейна ethereum во внутреннем формате. Я сделал много скамеек, потому что мне так долго просто пользоваться кошельком.

Режим обрезки — это способ сохранения данных блока. В режиме архива сохраняются все состояния. Итак, вы знаете состояние в каждый момент без перезагрузки всего блокчейна. С быстрым и легким мы предполагаем, что нам не нужна вся эта информация, а только текущее состояние и несколько предыдущих, поэтому мы удаляем много промежуточных состояний.

В geth метод --fast сохраняет состояние блокчейна в блоке B[-1500] и все состояния после этого блока (B[-1] — последний блок, B[-2] — перед последним блоком. ..). Так что можно перемотать на состояние 1500 последних блоков. С полным блокчейном вы можете сделать это для всех блоков.

По четности есть 4 режима обрезки или алгоритмов journalDB :

  • Архив (Архив): в качестве архива geth мы храним все состояния
  • Fast (OverlayRecent): как geth Fast мы сохраняем все полные состояния блоков B[-i]
  • Легкий (EarlyMerge): мы сохраняем все состояния блоков B[-i] , но в дифференциальном (поэтому он меньше, чем быстрый, но более медленный доступ)
  • Базовый (RefCounted): мы сохраняем все состояния блоков B[-i] , как и в случае с OverlayRecent, но мы удаляем состояния после x изменений... поэтому у нас есть только x-е последнее изменение

Тесты проводились на i7 3720QM 16GB ram с Geth 1.4.4 (Homestead с блоками 1.6Mi)

_____________________________________________
| Option | Disk Used | Time | Disk Written  |
|--------|-----------|------|---------------|
| none   | 19.GB     | 5h00 | 1TB           |
| fast   | 3.7GB     | 1h00 | 100GB         |
---------------------------------------------

Тесты, выполненные на i7 3720QM 16GB ram с нестабильной версией Geth 1.5.0 (Homestead с блоками 1.6Mi, найденными на https://gitter.im/ethereum/go-ethereum?at=574d26c010f0fed86f49b32f )

__________________________________________________
| command     | Disk Used | Time | Disk Written  |
|-------------|-----------|------|---------------|
| geth        | 21GB      | 5h00 | 150GB         |
| geth --fast | 4.2GB     | 21m  | 35GB          |
| geth export | 1.5GB     | 10m  |               |
| geth import | 21GB      | 3h30 |               |
--------------------------------------------------

Тесты проводились на i7 3720QM 16GB ram с Parity 1.2 (Homestead с блоками 1.6Mi)

_____________________________________________
| Option | Disk Used | Time | Disk Written  |
|--------|-----------|------|---------------|
| archive| 19.GB     | 2h00 | 300GB         |
| fast   | 3.7GB     | 1h30 | 20GB          |
| light  | 2.5GB     | 2h00 | 130GB         |
---------------------------------------------

Примечание. Если у вас есть узел с цепочкой блоков, вы можете сбросить данные цепочки из каталога geth, чтобы использовать его на других ваших компьютерах. Я проверяю это с Linux, Windows и OS X.

Примечание: если вы используете --cache с 1024, это может быть быстрее. Но в моей системе это не существенно. То же самое касается --jitvm

Примечание: блокчейн Эфириума сохранил конечное состояние после транзакций, но безопаснее воспроизвести транзакции, чтобы проверить их.

Что это за аббревиатура "Go"? Я предполагаю, что это "Гб"?
Извините, французский штрих. Go это ГБ
Мне интересно, а как вы измеряли "Disk Written"?
Пожалуйста, обновите ссылку на github.com/paritytech/parity/blob/…
обновление сделано. спасибо

С каждым блоком состояние (хранение контрактов и остатки) меняется. По умолчанию ( archive) мы храним в базе данных полное состояние каждого блока.

С помощью различных алгоритмов обрезки мы удаляем данные о состоянии для старых блоков, сохраняя только те части, которые необходимы. basic/fast/lightпросто различные подходы к этой проблеме с различными компромиссами.

geth --fastявляется реализацией PV63 ( https://github.com/ethereum/wiki/wiki/Ethereum-Wire-Protocol ) — вместо обработки каждого прошедшего блока мы просто загружаем его с других узлов, что приводит к гораздо более быстрому времени начальной синхронизации. Это не связано с обрезкой.

Легкий клиент ( https://github.com/ethereum/wiki/wiki/Light-client-protocol ) — это тоже другое дело. Вместо обработки (и хранения) данных обо всей цепочке блоков легкие клиенты будут обрабатывать только те части состояния, которые их интересуют.

Что такое режим обрезки света четности?
СпросиСетьПолитика конфиденциальности1y, 0v