Вернуться   Биткоин Форум > Разработка и Техническое Обсуждение
4 марта 2016, 8:17:49 PM   # 1
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

Взлом Биткоин адресов.
500 Биткоинов взломаны в "мозговом кошельке" с паролем "bitcoin is awesome"
Адрес кошелька: 14NWDXkQwcGN1Pd9fboL8npVynD5SfyJAE
Приватный ключ: 5J64pq77XjeacCezwmAr2V1s7snvvJkuAz8sENxw7xCkikceV6e
подробнее...


Всем кто хочет заработать Биткоины без вложений - рекомендую сайт http://bitcoin-zarabotat.ru
Нет, я не один

Мне было просто интересно, потому что я знаю, что UTXO дБ является очень важным компонентом системы Bitcoin и она, очевидно, будет как-то выгодно в будущем, чтобы он хорошо выполняет.

Как бы вы представить себе ядро ​​базы данных, разработанное специально для Bitcoins UTXO дб?

Я думаю, что это очень важно, чтобы иметь возможность просматривать все записи в кратчайшие сроки.
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n


Как заработать Биткоины?
Без вложений. Не майнинг.


5 марта 2016, 4:45:33 AM   # 2
 
 
Сообщения: 1988
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

Получил 1806 Биткоинов
Реальная история.





Это действительно бессмысленно вопрос.

Я думаю, что это очень важно, чтобы иметь возможность просматривать все записи в кратчайшие сроки.

Для кого скорость так важно?

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

2112 сейчас офлайн Пожаловаться на 2112   Ответить с цитированием Мультицитирование Сообщения от 2112 Быстрый ответ на сообщение 2112

5 марта 2016, 8:35:27 AM   # 3
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

Это действительно бессмысленно вопрос.

Я думаю, что это очень важно, чтобы иметь возможность просматривать все записи в кратчайшие сроки.

Для кого скорость так важно?

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



Вы путаете вещи. Вероятно потому, что вы на самом деле не понимают, что база данных UTXO фактически делает внутри программного обеспечения Bitcoin.

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

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

Эффективная база данных UTXO, которые могут быстро просматривать все записи, безусловно, необходимо для следующего поколения программного обеспечения Bitcoin узла.
Я просто не в курсе каких-либо существующих двигателей, которые были бы готовы заменить используемую в данный момент LevelDB.
Я думаю, в конце концов, один должен быть (и будут) созданы специально для Bitcoin. Так же, как secp256k1 Lib SIPA был создан специально для Bitcoin, поскольку реализация этого первоначально использовался OpenSSL не был достаточно хорош, чтобы справиться с важной частью программного обеспечения.
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

5 марта 2016, 3:56:58 PM   # 4
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

для utxo, мой подход с игуана создает параллельный набор наборов данных в считанных только файлы, отображенные на память. Можно утверждать, что это в конечном итоге DB, как это просто не могу получить быстрее, чем это.

Все вещи, необходимые для запросов на уровне блоков проводниковых являются предварительно вычислены и введены в считанных только файлы.

Имея каждый сверток 2000 блоков, в основном, зависят от всех других блоков, это позволяет не только для параллельной синхронизации в blockchain, но и с использованием нескольких ядер для всех запросов regarading истории ОЙ.

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

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

Формат вектора utxo бы только расположение неизрасходованного, что тратятся и расположение расходов подразумеваются в порядке Vins.

[U0, u1, u2, u3, ...] представляет собой список из 6 байт локаторов для неизрасходованного, что соответствующая Vin в пучке тратит, где каждый пользовательский интерфейс содержит расслоение идентификатор и unspentind. Каждый unspentind просто порядок оказывается в пучке (начиная с 1).

выше, не может непосредственно использоваться, но оно инвариантно и может быть создано один раз и положить в только для чтения файла (системы). используя mksquashfs уменьшает размер таблиц индексов почти на 50%.

Учитывая такой список для всех пучков, а затем с помощью параллельного процесса многожильного, все они могут быть пройдены и обновлять битовую карту, чтобы указать, какие выходы расходуются. Таким образом, 0 бит это означает, что неизрасходованные. Может быть, 1 бит пространства на utxo достаточно хорошо, так как это, казалось бы, так хорошо, как он получает, но это 1 бит на Vout, так больше похоже на размер 30МБ. Тем не менее, я думаю, что это может быть сжат очень хорошо с большинством ранних vouts уже затраченных (игнорируя Satoshi них). Я гавань была возможность получить до даты utxo битовой карты, но я надеюсь, чтобы получить один на следующей неделе.

При размере 30MB или меньше, весь utxo растровый будет вписываться в L кэш процессора и обеспечивают в 10 раз быстрее, чем производительность ОЗУ. RAM на самом деле довольно медленно по сравнению с вещами, которые могут быть выполнены полностью внутри процессора.

Джеймс

jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

5 марта 2016, 4:12:57 PM   # 5
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

Это действительно бессмысленно вопрос.

Я думаю, что это очень важно, чтобы иметь возможность просматривать все записи в кратчайшие сроки.

Для кого скорость так важно?

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


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

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

Конечно, это наиболее вероятно, что любая такая быстрая и надежная система является более сложной, писать, но когда-то написал, что может быть подтверждено

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

5 марта 2016, 7:47:23 PM   # 6
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

для utxo, мой подход с игуана создает параллельный набор наборов данных в считанных только файлы, отображенные на память. Можно утверждать, что это в конечном итоге DB, как это просто не могу получить быстрее, чем это.

Все вещи, необходимые для запросов на уровне блоков проводниковых являются предварительно вычислены и введены в считанных только файлы.

Имея каждый сверток 2000 блоков, в основном, зависят от всех других блоков, это позволяет не только для параллельной синхронизации в blockchain, но и с использованием нескольких ядер для всех запросов regarading истории ОЙ.

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

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

Формат вектора utxo бы только расположение неизрасходованного, что тратятся и расположение расходов подразумеваются в порядке Vins.

[U0, u1, u2, u3, ...] представляет собой список из 6 байт локаторов для неизрасходованного, что соответствующая Vin в пучке тратит, где каждый пользовательский интерфейс содержит расслоение идентификатор и unspentind. Каждый unspentind просто порядок оказывается в пучке (начиная с 1).

выше, не может непосредственно использоваться, но оно инвариантно и может быть создано один раз и положить в только для чтения файла (системы). используя mksquashfs уменьшает размер таблиц индексов почти на 50%.

Учитывая такой список для всех пучков, а затем с помощью параллельного процесса многожильного, все они могут быть пройдены и обновлять битовую карту, чтобы указать, какие выходы расходуются. Таким образом, 0 бит это означает, что неизрасходованные. Может быть, 1 бит пространства на utxo достаточно хорошо, так как это, казалось бы, так хорошо, как он получает, но это 1 бит на Vout, так больше похоже на размер 30МБ. Тем не менее, я думаю, что это может быть сжат очень хорошо с большинством ранних vouts уже затраченных (игнорируя Satoshi них). Я гавань была возможность получить до даты utxo битовой карты, но я надеюсь, чтобы получить один на следующей неделе.

При размере 30MB или меньше, весь utxo растровый будет вписываться в L кэш процессора и обеспечивают в 10 раз быстрее, чем производительность ОЗУ. RAM на самом деле довольно медленно по сравнению с вещами, которые могут быть выполнены полностью внутри процессора.

Джеймс
Я сожалею, что не хватает времени, чтобы копаться в коде, хотя я уверен, что его хороший материал.
Так как же вы на самом деле хранить БД в памяти, в некоторых простых словах?

Я использую HashMaps и его довольно быстро, но и очень примитивно.
Кроме того, он принимает нагрузку памяти и возрастов, чтобы загрузить с диска.
И писать его на диск - отдельная проблема.

Я уверен, что должно быть так много места, чтобы улучшить его.

Можете ли вы сказать, сколько секунд вам нужно просмотреть все текущие записи utxo и известково, позволяет сказать, сумму всех значений.
С моим двигателем я не могу получить ниже 4 секунды больше.

UTXO дБ составляет более 35 миллионов записей теперь.
Это действительно нуждается в лучшем дерьмо, чем LevelDB
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

5 марта 2016, 8:23:20 PM   # 7
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

для utxo, мой подход с игуана создает параллельный набор наборов данных в считанных только файлы, отображенные на память. Можно утверждать, что это в конечном итоге DB, как это просто не могу получить быстрее, чем это.

Все вещи, необходимые для запросов на уровне блоков проводниковых являются предварительно вычислены и введены в считанных только файлы.

Имея каждый сверток 2000 блоков, в основном, зависят от всех других блоков, это позволяет не только для параллельной синхронизации в blockchain, но и с использованием нескольких ядер для всех запросов regarading истории ОЙ.

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

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

Формат вектора utxo бы только расположение неизрасходованного, что тратятся и расположение расходов подразумеваются в порядке Vins.

[U0, u1, u2, u3, ...] представляет собой список из 6 байт локаторов для неизрасходованного, что соответствующая Vin в пучке тратит, где каждый пользовательский интерфейс содержит расслоение идентификатор и unspentind. Каждый unspentind просто порядок оказывается в пучке (начиная с 1).

выше, не может непосредственно использоваться, но оно инвариантно и может быть создано один раз и положить в только для чтения файла (системы). используя mksquashfs уменьшает размер таблиц индексов почти на 50%.

Учитывая такой список для всех пучков, а затем с помощью параллельного процесса многожильного, все они могут быть пройдены и обновлять битовую карту, чтобы указать, какие выходы расходуются. Таким образом, 0 бит это означает, что неизрасходованные. Может быть, 1 бит пространства на utxo достаточно хорошо, так как это, казалось бы, так хорошо, как он получает, но это 1 бит на Vout, так больше похоже на размер 30МБ. Тем не менее, я думаю, что это может быть сжат очень хорошо с большинством ранних vouts уже затраченных (игнорируя Satoshi них). Я гавань была возможность получить до даты utxo битовой карты, но я надеюсь, чтобы получить один на следующей неделе.

При размере 30MB или меньше, весь utxo растровый будет вписываться в L кэш процессора и обеспечивают в 10 раз быстрее, чем производительность ОЗУ. RAM на самом деле довольно медленно по сравнению с вещами, которые могут быть выполнены полностью внутри процессора.

Джеймс
Я сожалею, что не хватает времени, чтобы копаться в коде, хотя я уверен, что его хороший материал.
Так как же вы на самом деле хранить БД в памяти, в некоторых простых словах?

Я использую HashMaps и его довольно быстро, но и очень примитивно.
Кроме того, он принимает нагрузку памяти и возрастов, чтобы загрузить с диска.
И писать его на диск - отдельная проблема.

Я уверен, что должно быть так много места, чтобы улучшить его.

Можете ли вы сказать, сколько секунд вам нужно просмотреть все текущие записи utxo и известково, позволяет сказать, сумму всех значений.
С моим двигателем я не могу получить ниже 4 секунды больше.

UTXO дБ составляет более 35 миллионов записей теперь.
Это действительно нуждается в лучшем дерьмо, чем LevelDB
В сыром виде, со всеми данными, разбросанных по 200 пучков, упрощенный поиск конкретного адреса занял 2,5 миллисекунды на 1.4GHz i5. Не параллельный процесс, но серийный. Используя быстрый процессор и 8 ядер, я думаю, что раз в 100 наносекунд могли сделать полный поиск и сумму по конкретному адресу.

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

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

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

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

Было бы Vin количество дополнений, которые происходят в каждом пучке, чтобы получить общее затрачивает для адресов в этом пакете, а затем один дополнение для каждого адреса к глобальным противовесов. Делая это таким образом, чтобы получить до даты баланса будет вопрос индексации в глобальном списке баланса, а затем регулировать его Vins и vouts расслоение в реальном масштабе времени в.

В одном из вариантов осуществления я обновил все остатки, как новый ТХ пришел, так что не приняло никакого времени, чтобы получить общее резюме. Проверка, что всего путем суммирования всех счетов Потребовалось несколько миллисекунд, но его сортировка в список богачей были в конечном итоге принимает несколько секунд. Он израсходовал HDD пространство для хранения всех остатков, 16 байт на адрес, поэтому он добавляет место, необходимое, если все адреса нуждающихся в обновлении. но процессор может сделать десятки миллионов добавляет довольно быстро через RAM

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

5 марта 2016, 8:29:17 PM   # 8
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

В сыром виде, со всеми данными, разбросанных по 200 пучков, упрощенный поиск конкретного адреса занял 2,5 миллисекунды на 1.4GHz i5. Не параллельный процесс, но серийный. Используя быстрый процессор и 8 ядер, я думаю, что раз в 100 наносекунд могли сделать полный поиск и сумму по конкретному адресу.
Да, но я не заинтересован в проверке баланса на адреса. Я просто хочу знать, как быстро это идти корыто каждая из UTXO БД записей - хотите сделать что-либо на каждом отдельном одном из них.

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

5 марта 2016, 8:43:29 PM   # 9
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

В сыром виде, со всеми данными, разбросанных по 200 пучков, упрощенный поиск конкретного адреса занял 2,5 миллисекунды на 1.4GHz i5. Не параллельный процесс, но серийный. Используя быстрый процессор и 8 ядер, я думаю, что раз в 100 наносекунд могли сделать полный поиск и сумму по конкретному адресу.
Да, но я не заинтересован в проверке баланса на адреса. Я просто хочу знать, как быстро это идти корыто каждая из UTXO БД записей - хотите сделать что-либо на каждом отдельном одном из них.

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

потребовалось 2,5 миллисекунды, чтобы сделать listunspents для адреса с тысячами ТХ на моем ноутбуке. Это может быть любой адрес (как только я получаю все ошибки исправлены)

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

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

Может быть, я что-то пропустил, что нужно, чтобы отсканировать все utxo? С моей установкой importprivkey не нужна, поскольку все адреса в основном уже есть. Если время миллисекунды слишком медленно, то это, конечно, может быть разыменовываются в 6 байт в utxo.

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

Если вы просто хотите, чтобы все utxo просканировать, просто перебирать utxo растровый извлечь данные utxo и поместить все это в единую память отображенного файла. Но не уверен, что стоит тратить ГБ, чтобы сделать это, поскольку все неизрасходованные данные уже в памяти отображаются файлы, так что 6 байт на неизрасходованных достаточно, чтобы сделать список для utxo каждого адреса в. Затем с помощью прямого поиска этого адреса вы найдете все utxo

структура iguana_unspent // 28 байт
 {
    uint64_t значение;
    uint32_t txidind, pkind, prevunspentind, scriptoffset;
    uint16_t hdrsi: 14, тип: 4, Vout: 14;
 } __attribute __ ((упакованы));

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

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

5 марта 2016, 8:59:40 PM   # 10
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

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

у вас есть база данных utxo, или так вы это называете.
Вы получаете новую транзакцию, и вы должны проверить его.
сколько это займет?

я надеюсь, вы знаете, что вам нужно получить вклад каждого ТХ от БД, проверить ее консистенцию, а затем положить измененные записи обратно в БД.
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

5 марта 2016, 9:25:01 PM   # 11
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

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

у вас есть база данных utxo, или так вы это называете.
Вы получаете новую транзакцию, и вы должны проверить его.
сколько это займет?

я надеюсь, вы знаете, что вам нужно получить вклад каждого ТХ от БД, проверить ее консистенцию, а затем положить измененные записи обратно в БД.

FETCH:
Для каждых вин, то TXID / Vout отображается соответствующим unspentind
У меня есть побитовое Hashtable, который не более 50% от полной, так что таблица openhash работает довольно хорошо. Я думаю, что в худшем случае составляет около 20 столкновений, но каждый из них является лишь вопросом, чтобы увеличить к следующему пункту.

когда TXID найден, Vout говорит нам, где неизрасходованный есть, поскольку каждый TXID имеет firstvout как часть своих данных. не более 200, но в среднем сканирования в обратном направлении находит TXID быстрее, чем N / 2 пучков по очевидным причинам.

Использование listunspent в качестве сравнения, который должен также пройти связанный список и должен был бы сделать это для каждого пучка, поэтому обновление utxo бы величину порядка меньше работы. Dont есть тесты еще, но, вероятно, в диапазоне от 100 микросекунд

ПРОВЕРКИ:
После того, как unspentind извлекается, то utxo растровый проверяется (мгновенная)

ПОЛОЖИЛ:
Если все хорошо, то бит utxo растровый установлен в отработавший (момент)

На запуске системы utxo растровые действительно необходимо регенерировать и обновляются с последней границы расслоения. Я планирую сделать utxo набор данных сохраняет более часто, чем 2000 границ блока, может быть, каждые 10, так что только 10 блоков стоимостью должен быть переигран, чтобы добраться до текущего набора utxo

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

5 марта 2016, 9:28:08 PM   # 12
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

звучит как хороший материал.
Я дам ему лучше выглядеть, как только я трезвый

так что вы можете обратиться к какому-то конкретному коду, который реализует это?
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

5 марта 2016, 9:40:16 PM   # 13
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

звучит как хороший материал.
Я дам ему лучше выглядеть, как только я трезвый

так что вы можете обратиться к какому-то конкретному коду, который реализует это?
github.com/jl777/SuperNET

в Надсети / игуанах Dir игуаны _ *. C-файлы имеют это, в основном, в iguana_ramchain.c. Нет комментарии говорить, и я хотел бы упаковать как много в каждую строку, как это возможно, так что 3x до 5x более плотным, чем большинство коды C там.

Я правильно документировать все, как только все это окончательно.

Как вы можете себе представить, что это довольно сложно, чтобы получить все биты в нужном месте, поэтому проверка набора данных мой текущий приоритет. Я добавил возможность для того, чтобы выступать в качестве кодека без потерь для rawtransactions, который позволил бы грубой силы сравнения с эталонным bitcoind.

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

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

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

5 марта 2016, 9:46:40 PM   # 14
 
 
Сообщения: 1778
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

После того, как все остатки по всем адресам, проверяется на все границах расслоения, то "все" что осталось, это расслоение в реальном времени проверяемого. Перебором путь будет просто генерировать пучок без всех блоков, так как каждый новый блок придет. Я предполагаю, что оно не будет так плохо, как и цветение фильтр и открытый Хеш был разработан, чтобы быть в состоянии быть постепенно добавлены в.
Хотя я не совсем уверен, что вы имеете в виду "грубая сила" среди прочего, на самом деле путь, чтобы сохранить только blockchain обеспеченного снимка utxo дб на определенном этапе.
Его единственный путь.
Всем известно, что, но никто ничего не делает об этом
piotr_n сейчас офлайн Пожаловаться на piotr_n   Ответить с цитированием Мультицитирование сообщения от piotr_n Быстрый ответ на сообщение piotr_n

5 марта 2016, 9:56:02 PM   # 15
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

После того, как все остатки по всем адресам, проверяется на все границах расслоения, то "все" что осталось, это расслоение в реальном времени проверяемого. Перебором путь будет просто генерировать пучок без всех блоков, так как каждый новый блок придет. Я предполагаю, что оно не будет так плохо, как и цветение фильтр и открытый Хеш был разработан, чтобы быть в состоянии быть постепенно добавлены в.
Хотя я не совсем уверен, что вы имеете в виду "грубая сила", На самом деле путь, чтобы сохранить только blockchain обеспеченного снимка объекта на utxo дб.
Его единственный путь.
Всем известно, что, но никто ничего не делает об этом
Я SHA256 хэш всех внутренних наборов данных, так что можно быстро узнать, где какое-то несоответствие между двумя наборами данных (хотя он загрязнен Endian зависимости в это время). Как узнать, кто поставил utxo хэш в blockchain? Если есть способ сделать это без его уязвимым для атакующего размещения его версии, то было бы здорово иметь

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

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

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

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

5 марта 2016, 10:38:09 PM   # 16
 
 
Сообщения: 266
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

Я думаю, что это очень важно, чтобы иметь возможность просматривать все записи в кратчайшие сроки.

Я не согласен, основные требования

проверить utxo тратить
проверить utxo количество
удалить используемый Тх
добавлять новые utxos из блока
реорганизовать REVERT utxo
Watashi-kokoto сейчас офлайн Пожаловаться на Watashi-kokoto   Ответить с цитированием Мультицитирование сообщения от Watashi-kokoto Быстрый ответ на сообщение Watashi-kokoto

5 марта 2016, 10:51:52 PM   # 17
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

Я думаю, что это очень важно, чтобы иметь возможность просматривать все записи в кратчайшие сроки.

Я не согласен, основные требования

проверить utxo тратить
проверить utxo количество
удалить используемый Тх
добавлять новые utxos из блока
реорганизовать REVERT utxo
да, это было мое мышление с моим дизайном. большинство операций над очень быстро.
добавление utxo из нового блока требует обновлений всех различных наборов данных, но в целом не так много времени

REORG Revert utxo является только медленной, но я отложить завершение узелка до 10 блоков в прошлом, так что шансы на REORG к аннулированию сверток довольно малы. Если это произойдет, через несколько минут, чтобы восстановить файл пучок.

расслоение в реальном времени должен быть достаточно мал, так что любой REORG можно просто пересчитать с глубины не более Reorg
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

6 марта 2016, 1:35:51 AM   # 18
 
 
Сообщения: 1988
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

Вы путаете вещи. Вероятно потому, что вы на самом деле не понимают, что база данных UTXO фактически делает внутри программного обеспечения Bitcoin.

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

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

Эффективная база данных UTXO, которые могут быстро просматривать все записи, безусловно, необходимо для следующего поколения программного обеспечения Bitcoin узла.
Я просто не в курсе каких-либо существующих двигателей, которые были бы готовы заменить используемую в данный момент LevelDB.
Я думаю, в конце концов, один должен быть (и будут) созданы специально для Bitcoin. Так же, как secp256k1 Lib SIPA был создан специально для Bitcoin, поскольку реализация этого первоначально использовался OpenSSL не был достаточно хорош, чтобы справиться с важной частью программного обеспечения.
Я имел эту дискуссию около 3 лет назад с etotheipi, экс-генеральный директор экс-Оружейной:

Новое управление blockchain в Оружейной



Теперь мы уверены, что Оружейная была полная потеря как бизнес: они поставляли обещал программное обеспечение, но достигли ровно ноль продаж, даже не консалтинговый контракт на бывших сотрудников.

Я не буду повторять аргументы от 3-х лет назад, заинтересованные читатели могли изучить Оружейной Trainwreck.

AFAIK Оружейная где-то в 2015 г. Также понятно, что LevelDB не очень подходит и попытку изменить базовый двигатель LightningDB:

https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database

Несмотря на вышесказанное, я согласен с Вами, что распределенные cyptocurrencies оба создают уникальные требования и обеспечивают уникальные возможности для оптимизации. В частности, традиционная ACID базы данных является излишеством для UTxO, то гораздо проще будет работать из-за чрезвычайную репликацию, которая является основой для концепции распределенных cryptocurrencies.

Я всегда хотел, чтобы собрать проигравшие, которые отрицают необходимость согласованности транзакций имеют решающее значение. GLBSE и ASICMINER было два наиболее известными случаями двойной оплаты. Пару дней назад BitBet вступил в клуб, на этот раз обвинив его шахтеров. Я буду цитировать всю статью Qntra для моей будущей ссылки здесь:
Шахтер проблемы

Добавлено 2 марта 2016 года Мирча Попеску   
  
Как было объявлено в # Bitcoin-активов, BitBet был атакован ранее сегодня через механизм транзакций удержания. Наступление развивалось следующим образом:

1. BitBet ставка (Джеб Буш будет Республиканцы 2016 кандидат на пост президента) был закрыт и решен 21 февраля. Это создало список победителей с разумно ожидать, чтобы быть выплачены выигрыши.

2. Первая сделка была передана, чтобы удовлетворить требования победителей, затрачивая несколько входов, и предлагая вознаграждение в размере 0. Эта сделка была, как и следовало ожидать, ни добывали, ни включенных в mempools большинства узлов Bitcoin.

3. вторая транзакция была передана, проводя те же входы, как A1, в том числе платы 0,0001, назовет его А2. Для 1.5kb сделки ~, эта плата находится на низкой стороне, так что, возможно, можно было бы утверждать, что это не добываются можно было бы ожидать. Тем не менее, сделка A2 также не включены в mempools большинства узлов Bitcoin.

4. Так как ни сделки А1 или А2 были добыты после 54 (48) часов, дальнейшая сделка была передана, проводя те же входы, как A1 и A2, и в том числе вознаграждения в размере 0.000175, назовет его А3. По какому-то мере, плата превышает 10 Satoshi на байты должна быть достаточной, чтобы иметь операции минные. Тем не менее, вопреки ожиданиям, сделка A3 не была включена в любой блок или mempools большинства узлов Bitcoin.

5. После того, как еще 48 часов, четвертая сделка была передана, проводя те же входы, как A1, A2 и A3, в том числе и вознаграждение в размере 0,00022, назовем его формата А4. Так же, как и предыдущие три, сделка A4 не была включена либо в блоке или рекламируются большинство узлов Bitcoin.

6. По истечении еще 16 часов, транзакция B транслировалась, который включал те же выходные сигналы как операции А1-А4, но разные входы. Транзакция B, как сделки A4, включал сбор в 0,00022. Транзакция B была объявлена ​​большинство Биткойна узлов сразу же после этого, и была включена в блоке в течение получаса передается.

7. Два часа после того, как В, был включен в блоке, транзакция А1 была повторно транслироваться по неизвестной третьей стороной. Двадцать минут спустя, 0 плата, недельных, не раскрученный-на-никому-либо сделки, был включен в блок.

На основе этих событий, следующие утверждения легко могут быть поддержаны:

• Это понятие "большинство узлов Bitcoin" лишена содержания, большая часть ретрансляционной сети находится под контролем того же объекта и поддерживая функциональные возможности, не предусмотренное протоколом Bitcoin (например, селективной консервацию отдельных операций). (1) В частности, это означает, что "кто то"(2) имеет возможность Nuke операции из сети, независимо от того, являются ли они надлежащим образом подписаны или нет, напрямую тиражирования функциональности уже доступна для правительств декретных в декретных платежных системах, такие как Visa или Paypal.

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

• Что ни выше пункт имеет смысл или может долго существовать без другого, а это означает, что обязательно виновником является один и тот же. Обратите внимание, для записи, что юридическое лицо контролирующей 51% сетей (как с большим отрывом случая с картелем Antpool / F2pool) можно смело отказать в блоки на неопределенный срок - если конкурент выпускает более длинную цепь, все картель должен сделать, это сохранить добычу на своих собственных, в конечном счете, они будут иметь преимущественную силу. (4)

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

Обновление 2 марта 2016 18:49 UTC: В дальнейшем развитии на этой истории, Bitbet теперь объявила мораторий на платежи до тех пор, пока проблема не будет решена. (Н. ред.)

1. Вы должны помнить, что реле сети Bitcoin уже в течение многих лет были в очень плохом состоянии - были всего лишь как 60 узлов активны в прошлом году примерно в это время. С тех пор ситуация только ухудшилась - жюри все еще относительно того, действительно ли помогает или мешает в то время как он был функционален doohicky BlueMatt, но нет никаких аргументов, что сеть деградирует сравнению с предыдущим годом.

2. Кто, по вашему собственному выбору, может быть АНБ или картель Antpool / F2pool.

3. Сделка A1 не была передана, а затем включены в блок - в то время он был показан блок, содержащий его уже добыты - это просто еще не поделился с остальными плебса все.

4. 51% означает, что из 144 блоков в один день, один имеет 74, и, следовательно, получает 3 блок преимущество в более конкурирующей цепи каждый day..It правда, что картель обычно не желают афишировать свое присутствие (пока) , и поэтому на сегодняшний день они избегали крупной реорганизации;. Имейте в виду, однако, что это также случай, когда остальная часть меньшинства не объединено, но фрагментированным - так они на самом деле не нужно прибегать к основным реорганизацию;.
Edit: форматирование исправлений
2112 сейчас офлайн Пожаловаться на 2112   Ответить с цитированием Мультицитирование Сообщения от 2112 Быстрый ответ на сообщение 2112

6 марта 2016, 4:53:28 AM   # 19
 
 
Сообщения: 1162
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

Вы путаете вещи. Вероятно потому, что вы на самом деле не понимают, что база данных UTXO фактически делает внутри программного обеспечения Bitcoin.

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

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

Эффективная база данных UTXO, которые могут быстро просматривать все записи, безусловно, необходимо для следующего поколения программного обеспечения Bitcoin узла.
Я просто не в курсе каких-либо существующих двигателей, которые были бы готовы заменить используемую в данный момент LevelDB.
Я думаю, в конце концов, один должен быть (и будут) созданы специально для Bitcoin. Так же, как secp256k1 Lib SIPA был создан специально для Bitcoin, поскольку реализация этого первоначально использовался OpenSSL не был достаточно хорош, чтобы справиться с важной частью программного обеспечения.
Я имел эту дискуссию около 3 лет назад с etotheipi, экс-генеральный директор экс-Оружейной:

Новое управление blockchain в Оружейной



Теперь мы уверены, что Оружейная была полная потеря как бизнес: они поставляли обещал программное обеспечение, но достигли ровно ноль продаж, даже не консалтинговый контракт на бывших сотрудников.

Я не буду повторять аргументы от 3-х лет назад, заинтересованные читатели могли изучить Оружейной Trainwreck.

AFAIK Оружейная где-то в 2015 г. Также понятно, что LevelDB не очень подходит и попытку изменить базовый двигатель LightningDB:

https://en.wikipedia.org/wiki/Lightning_Memory-Mapped_Database

Несмотря на вышесказанное, я согласен с Вами, что распределенные cyptocurrencies оба создают уникальные требования и обеспечивают уникальные возможности для оптимизации. В частности, традиционная ACID базы данных является излишеством для UTxO, то гораздо проще будет работать из-за чрезвычайную репликацию, которая является основой для концепции распределенных cryptocurrencies.

Я всегда хотел, чтобы собрать проигравшие, которые отрицают необходимость согласованности транзакций имеют решающее значение. GLBSE и ASICMINER было два наиболее известными случаями двойной оплаты. Пару дней назад BitBet вступил в клуб, на этот раз обвинив его шахтеров. Я буду цитировать всю статью Qntra для моей будущей ссылки здесь:
Шахтер проблемы

Добавлено 2 марта 2016 года Мирча Попеску   
  
Как было объявлено в # Bitcoin-активов, BitBet был атакован ранее сегодня через механизм транзакций удержания. Наступление развивалось следующим образом:

1. BitBet ставка (Джеб Буш будет Республиканцы 2016 кандидат на пост президента) был закрыт и решен 21 февраля. Это создало список победителей с разумно ожидать, чтобы быть выплачены выигрыши.

2. Первая сделка была передана, чтобы удовлетворить требования победителей, затрачивая несколько входов, и предлагая вознаграждение в размере 0. Эта сделка была, как и следовало ожидать, ни добывали, ни включенных в mempools большинства узлов Bitcoin.

3. вторая транзакция была передана, проводя те же входы, как A1, в том числе платы 0,0001, назовет его А2. Для 1.5kb сделки ~, эта плата находится на низкой стороне, так что, возможно, можно было бы утверждать, что это не добываются можно было бы ожидать. Тем не менее, сделка A2 также не включены в mempools большинства узлов Bitcoin.

4. Так как ни сделки А1 или А2 были добыты после 54 (48) часов, дальнейшая сделка была передана, проводя те же входы, как A1 и A2, и в том числе вознаграждения в размере 0.000175, назовет его А3. По какому-то мере, плата превышает 10 Satoshi на байты должна быть достаточной, чтобы иметь операции минные. Тем не менее, вопреки ожиданиям, сделка A3 не была включена в любой блок или mempools большинства узлов Bitcoin.

5. После того, как еще 48 часов, четвертая сделка была передана, проводя те же входы, как A1, A2 и A3, в том числе и вознаграждение в размере 0,00022, назовем его формата А4. Так же, как и предыдущие три, сделка A4 не была включена либо в блоке или рекламируются большинство узлов Bitcoin.

6. По истечении еще 16 часов, транзакция B транслировалась, который включал те же выходные сигналы как операции А1-А4, но разные входы. Транзакция B, как сделки A4, включал сбор в 0,00022. Транзакция B была объявлена ​​большинство Биткойна узлов сразу же после этого, и была включена в блоке в течение получаса передается.

7. Два часа после того, как В, был включен в блоке, транзакция А1 была повторно транслироваться по неизвестной третьей стороной. Двадцать минут спустя, 0 плата, недельных, не раскрученный-на-никому-либо сделки, был включен в блок.

На основе этих событий, следующие утверждения легко могут быть поддержаны:

• Это понятие "большинство узлов Bitcoin" лишена содержания, большая часть ретрансляционной сети находится под контролем того же объекта и поддерживая функциональные возможности, не предусмотренное протоколом Bitcoin (например, селективной консервацию отдельных операций). (1) В частности, это означает, что "кто то"(2) имеет возможность Nuke операции из сети, независимо от того, являются ли они надлежащим образом подписаны или нет, напрямую тиражирования функциональности уже доступна для правительств декретных в декретных платежных системах, такие как Visa или Paypal.

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

• Что ни выше пункт имеет смысл или может долго существовать без другого, а это означает, что обязательно виновником является один и тот же. Обратите внимание, для записи, что юридическое лицо контролирующей 51% сетей (как с большим отрывом случая с картелем Antpool / F2pool) можно смело отказать в блоки на неопределенный срок - если конкурент выпускает более длинную цепь, все картель должен сделать, это сохранить добычу на своих собственных, в конечном счете, они будут иметь преимущественную силу. (4)

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

Обновление 2 марта 2016 18:49 UTC: В дальнейшем развитии на этой истории, Bitbet теперь объявила мораторий на платежи до тех пор, пока проблема не будет решена. (Н. ред.)

1. Вы должны помнить, что реле сети Bitcoin уже в течение многих лет были в очень плохом состоянии - были всего лишь как 60 узлов активны в прошлом году примерно в это время. С тех пор ситуация только ухудшилась - жюри все еще относительно того, действительно ли помогает или мешает в то время как он был функционален doohicky BlueMatt, но нет никаких аргументов, что сеть деградирует сравнению с предыдущим годом.

2. Кто, по вашему собственному выбору, может быть АНБ или картель Antpool / F2pool.

3. Сделка A1 не была передана, а затем включены в блок - в то время он был показан блок, содержащий его уже добыты - это просто еще не поделился с остальными плебса все.

4. 51% означает, что из 144 блоков в один день, один имеет 74, и, следовательно, получает 3 блок преимущество в более конкурирующей цепи каждый day..It правда, что картель обычно не желают афишировать свое присутствие (пока) , и поэтому на сегодняшний день они избегали крупной реорганизации;. Имейте в виду, однако, что это также случай, когда остальная часть меньшинства не объединено, но фрагментированным - так они на самом деле не нужно прибегать к основным реорганизацию;.
Edit: форматирование исправлений
независимо от того, "база данных" используются, конечно согласованность транзакций имеет решающее значение. Не знаю, как вы создалось впечатление, что это было не так.

Теперь в случае сеть делает глубокий REORG, то независимо от того, что используется БД или не-DB, все будет синхронизирован, пока глубоко REORG не распространяется. До тех пор пока раствор не-БД генерирует одни и те же результаты, что и в растворе дБ, то все внешние проблемы, которые являются внешними по отношению к местным методам хранения

Джеймс
jl777 сейчас офлайн Пожаловаться на jl777   Ответить с цитированием Мультицитирование сообщения от jl777 Быстрый ответ на сообщение jl777

6 марта 2016, 6:27:11 PM   # 20
 
 
Сообщения: 1260
Цитировать по имени
цитировать ответ
по умолчанию Re: оптимальный двигатель для UTXO дБ

http://tarantool.org/
amaclin сейчас офлайн Пожаловаться на amaclin   Ответить с цитированием Мультицитирование сообщения от amaclin Быстрый ответ на сообщение amaclin



Как заработать Биткоины?

Bitcoin Wallet * Portefeuille Bitcoin * Monedero Bitcoin * Carteira Bitcoin * Portafoglio Bitcoin * Bitcoin Cüzdan * 比特币钱包

bitcoin-zarabotat.ru
Почта для связи: bitcoin-zarabotat.ru@yandex.ru

3HmAQ9FkRFk6HZGuwExYxL62y7C1B9MwPW