2015-12-31 06:37:27 +00:00
|
|
|
// Copyright (c) 2014-2016, The Monero Project
|
2015-12-14 04:54:39 +00:00
|
|
|
//
|
2014-10-06 23:46:25 +00:00
|
|
|
// All rights reserved.
|
2015-12-14 04:54:39 +00:00
|
|
|
//
|
2014-10-06 23:46:25 +00:00
|
|
|
// Redistribution and use in source and binary forms, with or without modification, are
|
|
|
|
// permitted provided that the following conditions are met:
|
2015-12-14 04:54:39 +00:00
|
|
|
//
|
2014-10-06 23:46:25 +00:00
|
|
|
// 1. Redistributions of source code must retain the above copyright notice, this list of
|
|
|
|
// conditions and the following disclaimer.
|
2015-12-14 04:54:39 +00:00
|
|
|
//
|
2014-10-06 23:46:25 +00:00
|
|
|
// 2. Redistributions in binary form must reproduce the above copyright notice, this list
|
|
|
|
// of conditions and the following disclaimer in the documentation and/or other
|
|
|
|
// materials provided with the distribution.
|
2015-12-14 04:54:39 +00:00
|
|
|
//
|
2014-10-06 23:46:25 +00:00
|
|
|
// 3. Neither the name of the copyright holder nor the names of its contributors may be
|
|
|
|
// used to endorse or promote products derived from this software without specific
|
|
|
|
// prior written permission.
|
2015-12-14 04:54:39 +00:00
|
|
|
//
|
2014-10-06 23:46:25 +00:00
|
|
|
// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY
|
|
|
|
// EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
|
|
|
|
// MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL
|
|
|
|
// THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
|
|
|
|
// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
|
|
|
|
// PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
|
|
|
|
// INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
|
|
|
|
// STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
|
|
|
|
// THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
|
2014-10-15 22:33:53 +00:00
|
|
|
#ifndef BLOCKCHAIN_DB_H
|
|
|
|
#define BLOCKCHAIN_DB_H
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
#include <list>
|
|
|
|
#include <string>
|
|
|
|
#include <exception>
|
|
|
|
#include "crypto/hash.h"
|
|
|
|
#include "cryptonote_core/cryptonote_basic.h"
|
|
|
|
#include "cryptonote_core/difficulty.h"
|
|
|
|
|
|
|
|
/* DB Driver Interface
|
|
|
|
*
|
|
|
|
* The DB interface is a store for the canonical block chain.
|
|
|
|
* It serves as a persistent storage for the blockchain.
|
|
|
|
*
|
|
|
|
* For the sake of efficiency, the reference implementation will also
|
|
|
|
* store some blockchain data outside of the blocks, such as spent
|
|
|
|
* transfer key images, unspent transaction outputs, etc.
|
|
|
|
*
|
|
|
|
* Transactions are duplicated so that we don't have to fetch a whole block
|
|
|
|
* in order to fetch a transaction from that block. If this is deemed
|
|
|
|
* unnecessary later, this can change.
|
|
|
|
*
|
|
|
|
* Spent key images are duplicated outside of the blocks so it is quick
|
|
|
|
* to verify an output hasn't already been spent
|
|
|
|
*
|
|
|
|
* Unspent transaction outputs are duplicated to quickly gather random
|
|
|
|
* outputs to use for mixins
|
|
|
|
*
|
|
|
|
* IMPORTANT:
|
|
|
|
* A concrete implementation of this interface should populate these
|
|
|
|
* duplicated members! It is possible to have a partial implementation
|
|
|
|
* of this interface call to private members of the interface to be added
|
|
|
|
* later that will then populate as needed.
|
|
|
|
*
|
|
|
|
* General:
|
|
|
|
* open()
|
2015-03-25 15:41:30 +00:00
|
|
|
* is_open()
|
2014-10-06 23:46:25 +00:00
|
|
|
* close()
|
|
|
|
* sync()
|
|
|
|
* reset()
|
|
|
|
*
|
|
|
|
* Lock and unlock provided for reorg externally, and for block
|
|
|
|
* additions internally, this way threaded reads are completely fine
|
|
|
|
* unless the blockchain is changing.
|
|
|
|
* bool lock()
|
|
|
|
* unlock()
|
|
|
|
*
|
2014-10-15 22:33:53 +00:00
|
|
|
* vector<str> get_filenames()
|
|
|
|
*
|
2014-10-06 23:46:25 +00:00
|
|
|
* Blocks:
|
|
|
|
* bool block_exists(hash)
|
|
|
|
* height add_block(block, block_size, cumulative_difficulty, coins_generated, transactions)
|
|
|
|
* block get_block(hash)
|
|
|
|
* height get_block_height(hash)
|
|
|
|
* header get_block_header(hash)
|
|
|
|
* block get_block_from_height(height)
|
|
|
|
* size_t get_block_size(height)
|
|
|
|
* difficulty get_block_cumulative_difficulty(height)
|
|
|
|
* uint64_t get_block_already_generated_coins(height)
|
2015-12-14 04:54:39 +00:00
|
|
|
* uint64_t get_block_timestamp(height)
|
2014-10-06 23:46:25 +00:00
|
|
|
* uint64_t get_top_block_timestamp()
|
|
|
|
* hash get_block_hash_from_height(height)
|
|
|
|
* blocks get_blocks_range(height1, height2)
|
|
|
|
* hashes get_hashes_range(height1, height2)
|
|
|
|
* hash top_block_hash()
|
|
|
|
* block get_top_block()
|
|
|
|
* height height()
|
|
|
|
* void pop_block(block&, tx_list&)
|
|
|
|
*
|
|
|
|
* Transactions:
|
|
|
|
* bool tx_exists(hash)
|
|
|
|
* uint64_t get_tx_unlock_time(hash)
|
|
|
|
* tx get_tx(hash)
|
|
|
|
* uint64_t get_tx_count()
|
|
|
|
* tx_list get_tx_list(hash_list)
|
|
|
|
* height get_tx_block_height(hash)
|
|
|
|
*
|
|
|
|
* Outputs:
|
|
|
|
* uint64_t get_num_outputs(amount)
|
|
|
|
* pub_key get_output_key(amount, index)
|
2014-12-14 20:20:41 +00:00
|
|
|
* hash,index get_output_tx_and_index_from_global(index)
|
2014-10-06 23:46:25 +00:00
|
|
|
* hash,index get_output_tx_and_index(amount, index)
|
|
|
|
* vec<uint64> get_tx_output_indices(tx_hash)
|
|
|
|
*
|
|
|
|
*
|
|
|
|
* Spent Output Key Images:
|
|
|
|
* bool has_key_image(key_image)
|
|
|
|
*
|
|
|
|
* Exceptions:
|
|
|
|
* DB_ERROR -- generic
|
|
|
|
* DB_OPEN_FAILURE
|
|
|
|
* DB_CREATE_FAILURE
|
|
|
|
* DB_SYNC_FAILURE
|
|
|
|
* BLOCK_DNE
|
|
|
|
* BLOCK_PARENT_DNE
|
|
|
|
* BLOCK_EXISTS
|
|
|
|
* BLOCK_INVALID -- considering making this multiple errors
|
|
|
|
* TX_DNE
|
|
|
|
* TX_EXISTS
|
|
|
|
* OUTPUT_DNE
|
2014-10-23 23:47:36 +00:00
|
|
|
* OUTPUT_EXISTS
|
|
|
|
* KEY_IMAGE_EXISTS
|
2014-10-06 23:46:25 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
namespace cryptonote
|
|
|
|
{
|
|
|
|
|
2014-10-06 23:54:46 +00:00
|
|
|
// typedef for convenience
|
|
|
|
typedef std::pair<crypto::hash, uint64_t> tx_out_index;
|
|
|
|
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
#pragma pack(push, 1)
|
|
|
|
struct output_data_t
|
|
|
|
{
|
2015-12-14 04:54:39 +00:00
|
|
|
crypto::public_key pubkey;
|
|
|
|
uint64_t unlock_time;
|
|
|
|
uint64_t height;
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
};
|
|
|
|
#pragma pack(pop)
|
2015-12-14 04:54:39 +00:00
|
|
|
|
2014-10-06 23:46:25 +00:00
|
|
|
/***********************************
|
|
|
|
* Exception Definitions
|
|
|
|
***********************************/
|
2014-12-06 21:21:17 +00:00
|
|
|
class DB_EXCEPTION : public std::exception
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
private:
|
|
|
|
std::string m;
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
protected:
|
|
|
|
DB_EXCEPTION(const char *s) : m(s) { }
|
|
|
|
|
|
|
|
public:
|
|
|
|
virtual ~DB_EXCEPTION() { }
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
const char* what() const throw()
|
|
|
|
{
|
|
|
|
return m.c_str();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class DB_ERROR : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
DB_ERROR() : DB_EXCEPTION("Generic DB Error") { }
|
|
|
|
DB_ERROR(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class DB_OPEN_FAILURE : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
DB_OPEN_FAILURE() : DB_EXCEPTION("Failed to open the db") { }
|
|
|
|
DB_OPEN_FAILURE(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class DB_CREATE_FAILURE : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
DB_CREATE_FAILURE() : DB_EXCEPTION("Failed to create the db") { }
|
|
|
|
DB_CREATE_FAILURE(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class DB_SYNC_FAILURE : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
DB_SYNC_FAILURE() : DB_EXCEPTION("Failed to sync the db") { }
|
|
|
|
DB_SYNC_FAILURE(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class BLOCK_DNE : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
BLOCK_DNE() : DB_EXCEPTION("The block requested does not exist") { }
|
|
|
|
BLOCK_DNE(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class BLOCK_PARENT_DNE : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
BLOCK_PARENT_DNE() : DB_EXCEPTION("The parent of the block does not exist") { }
|
|
|
|
BLOCK_PARENT_DNE(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class BLOCK_EXISTS : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
BLOCK_EXISTS() : DB_EXCEPTION("The block to be added already exists!") { }
|
|
|
|
BLOCK_EXISTS(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class BLOCK_INVALID : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
BLOCK_INVALID() : DB_EXCEPTION("The block to be added did not pass validation!") { }
|
|
|
|
BLOCK_INVALID(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class TX_DNE : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
TX_DNE() : DB_EXCEPTION("The transaction requested does not exist") { }
|
|
|
|
TX_DNE(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class TX_EXISTS : public DB_EXCEPTION
|
2014-10-06 23:46:25 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
TX_EXISTS() : DB_EXCEPTION("The transaction to be added already exists!") { }
|
|
|
|
TX_EXISTS(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-06 23:46:25 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class OUTPUT_DNE : public DB_EXCEPTION
|
2014-10-23 23:47:36 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
OUTPUT_DNE() : DB_EXCEPTION("The output requested does not exist!") { }
|
|
|
|
OUTPUT_DNE(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-23 23:47:36 +00:00
|
|
|
};
|
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class OUTPUT_EXISTS : public DB_EXCEPTION
|
2014-10-23 23:47:36 +00:00
|
|
|
{
|
|
|
|
public:
|
2014-12-06 21:21:17 +00:00
|
|
|
OUTPUT_EXISTS() : DB_EXCEPTION("The output to be added already exists!") { }
|
|
|
|
OUTPUT_EXISTS(const char* s) : DB_EXCEPTION(s) { }
|
|
|
|
};
|
2014-10-23 23:47:36 +00:00
|
|
|
|
2014-12-06 21:21:17 +00:00
|
|
|
class KEY_IMAGE_EXISTS : public DB_EXCEPTION
|
|
|
|
{
|
|
|
|
public:
|
|
|
|
KEY_IMAGE_EXISTS() : DB_EXCEPTION("The spent key image to be added already exists!") { }
|
|
|
|
KEY_IMAGE_EXISTS(const char* s) : DB_EXCEPTION(s) { }
|
2014-10-23 23:47:36 +00:00
|
|
|
};
|
|
|
|
|
2014-10-06 23:46:25 +00:00
|
|
|
/***********************************
|
|
|
|
* End of Exception Definitions
|
|
|
|
***********************************/
|
|
|
|
|
|
|
|
|
|
|
|
class BlockchainDB
|
|
|
|
{
|
|
|
|
private:
|
|
|
|
/*********************************************************************
|
|
|
|
* private virtual members
|
|
|
|
*********************************************************************/
|
|
|
|
|
|
|
|
// tells the subclass to add the block and metadata to storage
|
|
|
|
virtual void add_block( const block& blk
|
|
|
|
, const size_t& block_size
|
|
|
|
, const difficulty_type& cumulative_difficulty
|
|
|
|
, const uint64_t& coins_generated
|
2015-02-11 23:55:53 +00:00
|
|
|
, const crypto::hash& blk_hash
|
2014-10-06 23:46:25 +00:00
|
|
|
) = 0;
|
|
|
|
|
2014-10-23 19:37:10 +00:00
|
|
|
// tells the subclass to remove data about the top block
|
|
|
|
virtual void remove_block() = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// tells the subclass to store the transaction and its metadata
|
2015-02-11 23:55:53 +00:00
|
|
|
virtual void add_transaction_data(const crypto::hash& blk_hash, const transaction& tx, const crypto::hash& tx_hash) = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// tells the subclass to remove data about a transaction
|
2015-01-12 02:04:04 +00:00
|
|
|
virtual void remove_transaction_data(const crypto::hash& tx_hash, const transaction& tx) = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// tells the subclass to store an output
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
virtual void add_output(const crypto::hash& tx_hash, const tx_out& tx_output, const uint64_t& local_index, const uint64_t unlock_time) = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// tells the subclass to remove an output
|
|
|
|
virtual void remove_output(const tx_out& tx_output) = 0;
|
|
|
|
|
|
|
|
// tells the subclass to store a spent key
|
|
|
|
virtual void add_spent_key(const crypto::key_image& k_image) = 0;
|
|
|
|
|
|
|
|
// tells the subclass to remove a spent key
|
|
|
|
virtual void remove_spent_key(const crypto::key_image& k_image) = 0;
|
|
|
|
|
|
|
|
|
|
|
|
/*********************************************************************
|
|
|
|
* private concrete members
|
2015-12-14 04:54:39 +00:00
|
|
|
*********************************************************************/
|
2014-10-06 23:46:25 +00:00
|
|
|
// private version of pop_block, for undoing if an add_block goes tits up
|
|
|
|
void pop_block();
|
|
|
|
|
|
|
|
// helper function for add_transactions, to add each individual tx
|
2015-02-11 23:55:53 +00:00
|
|
|
void add_transaction(const crypto::hash& blk_hash, const transaction& tx, const crypto::hash* tx_hash_ptr = NULL);
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// helper function to remove transaction from blockchain
|
|
|
|
void remove_transaction(const crypto::hash& tx_hash);
|
|
|
|
|
2015-02-11 23:55:53 +00:00
|
|
|
uint64_t num_calls = 0;
|
|
|
|
uint64_t time_blk_hash = 0;
|
|
|
|
uint64_t time_add_block1 = 0;
|
|
|
|
uint64_t time_add_transaction = 0;
|
|
|
|
|
2014-10-06 23:46:25 +00:00
|
|
|
|
2015-02-11 23:55:53 +00:00
|
|
|
protected:
|
|
|
|
|
2015-02-11 04:01:02 +00:00
|
|
|
mutable uint64_t time_tx_exists = 0;
|
2015-02-11 23:55:53 +00:00
|
|
|
uint64_t time_commit1 = 0;
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
bool m_auto_remove_logs = true;
|
2015-02-11 23:55:53 +00:00
|
|
|
|
2014-10-06 23:46:25 +00:00
|
|
|
public:
|
2014-10-15 22:33:53 +00:00
|
|
|
|
|
|
|
// virtual dtor
|
|
|
|
virtual ~BlockchainDB() { };
|
|
|
|
|
2015-02-11 23:55:53 +00:00
|
|
|
// reset profiling stats
|
|
|
|
void reset_stats();
|
|
|
|
|
|
|
|
// show profiling stats
|
|
|
|
void show_stats();
|
2014-10-15 22:33:53 +00:00
|
|
|
|
2014-10-06 23:46:25 +00:00
|
|
|
// open the db at location <filename>, or create it if there isn't one.
|
2015-02-12 00:02:20 +00:00
|
|
|
virtual void open(const std::string& filename, const int db_flags = 0) = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
2015-03-25 15:41:30 +00:00
|
|
|
// returns true of the db is open/ready, else false
|
2015-05-27 18:03:46 +00:00
|
|
|
bool is_open() const;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// close and sync the db
|
|
|
|
virtual void close() = 0;
|
|
|
|
|
|
|
|
// sync the db
|
|
|
|
virtual void sync() = 0;
|
|
|
|
|
|
|
|
// reset the db -- USE WITH CARE
|
|
|
|
virtual void reset() = 0;
|
|
|
|
|
2014-10-15 22:33:53 +00:00
|
|
|
// get all files used by this db (if any)
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual std::vector<std::string> get_filenames() const = 0;
|
2014-10-15 22:33:53 +00:00
|
|
|
|
2015-03-14 01:39:27 +00:00
|
|
|
// return the name of the folder the db's file(s) should reside in
|
|
|
|
virtual std::string get_db_name() const = 0;
|
|
|
|
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// FIXME: these are just for functionality mocking, need to implement
|
|
|
|
// RAII-friendly and multi-read one-write friendly locking mechanism
|
|
|
|
//
|
|
|
|
// acquire db lock
|
|
|
|
virtual bool lock() = 0;
|
|
|
|
|
|
|
|
// release db lock
|
|
|
|
virtual void unlock() = 0;
|
|
|
|
|
2015-07-11 19:28:20 +00:00
|
|
|
virtual void batch_start(uint64_t batch_num_blocks=0) = 0;
|
2015-02-11 23:55:53 +00:00
|
|
|
virtual void batch_stop() = 0;
|
|
|
|
virtual void set_batch_transactions(bool) = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// adds a block with the given metadata to the top of the blockchain, returns the new height
|
2014-10-23 19:37:10 +00:00
|
|
|
// NOTE: subclass implementations of this (or the functions it calls) need
|
|
|
|
// to handle undoing any partially-added blocks in the event of a failure.
|
|
|
|
virtual uint64_t add_block( const block& blk
|
|
|
|
, const size_t& block_size
|
|
|
|
, const difficulty_type& cumulative_difficulty
|
|
|
|
, const uint64_t& coins_generated
|
|
|
|
, const std::vector<transaction>& txs
|
|
|
|
);
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return true if a block with hash <h> exists in the blockchain
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual bool block_exists(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return block with hash <h>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual block get_block(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return the height of the block with hash <h> on the blockchain,
|
|
|
|
// throw if it doesn't exist
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t get_block_height(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return header for block with hash <h>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual block_header get_block_header(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return block at height <height>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual block get_block_from_height(const uint64_t& height) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return timestamp of block at height <height>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t get_block_timestamp(const uint64_t& height) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return timestamp of most recent block
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t get_top_block_timestamp() const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return block size of block at height <height>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual size_t get_block_size(const uint64_t& height) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return cumulative difficulty up to and including block at height <height>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual difficulty_type get_block_cumulative_difficulty(const uint64_t& height) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return difficulty of block at height <height>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual difficulty_type get_block_difficulty(const uint64_t& height) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return number of coins generated up to and including block at height <height>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t get_block_already_generated_coins(const uint64_t& height) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return hash of block at height <height>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual crypto::hash get_block_hash_from_height(const uint64_t& height) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
2014-10-15 22:33:53 +00:00
|
|
|
// return vector of blocks in range <h1,h2> of height (inclusively)
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual std::vector<block> get_blocks_range(const uint64_t& h1, const uint64_t& h2) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
2014-10-15 22:33:53 +00:00
|
|
|
// return vector of block hashes in range <h1, h2> of height (inclusively)
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual std::vector<crypto::hash> get_hashes_range(const uint64_t& h1, const uint64_t& h2) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return the hash of the top block on the chain
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual crypto::hash top_block_hash() const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return the block at the top of the blockchain
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual block get_top_block() const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
2014-12-14 19:30:38 +00:00
|
|
|
// return the height of the chain
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t height() const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// pops the top block off the blockchain.
|
|
|
|
// Returns by reference the popped block and its associated transactions
|
|
|
|
//
|
|
|
|
// IMPORTANT:
|
|
|
|
// When a block is popped, the transactions associated with it need to be
|
|
|
|
// removed, as well as outputs and spent key images associated with
|
|
|
|
// those transactions.
|
2014-10-30 22:33:35 +00:00
|
|
|
virtual void pop_block(block& blk, std::vector<transaction>& txs);
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
|
|
|
|
// return true if a transaction with hash <h> exists
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual bool tx_exists(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return unlock time of tx with hash <h>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t get_tx_unlock_time(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return tx with hash <h>
|
|
|
|
// throw if no such tx exists
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual transaction get_tx(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// returns the total number of transactions in all blocks
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t get_tx_count() const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return list of tx with hashes <hlist>.
|
|
|
|
// TODO: decide if a missing hash means return empty list
|
|
|
|
// or just skip that hash
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual std::vector<transaction> get_tx_list(const std::vector<crypto::hash>& hlist) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// returns height of block that contains transaction with hash <h>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t get_tx_block_height(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// returns the total number of outputs of amount <amount>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual uint64_t get_num_outputs(const uint64_t& amount) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
2015-12-05 18:41:29 +00:00
|
|
|
// return index of the first element (should be hidden, but isn't)
|
|
|
|
virtual uint64_t get_indexing_base() const { return 0; }
|
|
|
|
|
2014-10-06 23:46:25 +00:00
|
|
|
// return public key for output with global output amount <amount> and index <index>
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
virtual output_data_t get_output_key(const uint64_t& amount, const uint64_t& index) = 0;
|
|
|
|
virtual output_data_t get_output_key(const uint64_t& global_index) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
2014-12-14 20:20:41 +00:00
|
|
|
// returns the tx hash associated with an output, referenced by global output index
|
|
|
|
virtual tx_out_index get_output_tx_and_index_from_global(const uint64_t& index) const = 0;
|
|
|
|
|
2014-10-06 23:46:25 +00:00
|
|
|
// returns the transaction-local reference for the output with <amount> at <index>
|
|
|
|
// return type is pair of tx hash and index
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
virtual tx_out_index get_output_tx_and_index(const uint64_t& amount, const uint64_t& index) = 0;
|
|
|
|
virtual void get_output_tx_and_index(const uint64_t& amount, const std::vector<uint64_t> &offsets, std::vector<tx_out_index> &indices) = 0;
|
|
|
|
virtual void get_output_key(const uint64_t &amount, const std::vector<uint64_t> &offsets, std::vector<output_data_t> &outputs) = 0;
|
2015-12-14 04:54:39 +00:00
|
|
|
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
virtual bool can_thread_bulk_indices() const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// return a vector of indices corresponding to the global output index for
|
|
|
|
// each output in the transaction with hash <h>
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual std::vector<uint64_t> get_tx_output_indices(const crypto::hash& h) const = 0;
|
2015-01-09 20:57:33 +00:00
|
|
|
// return a vector of indices corresponding to the amount output index for
|
|
|
|
// each output in the transaction with hash <h>
|
|
|
|
virtual std::vector<uint64_t> get_tx_amount_output_indices(const crypto::hash& h) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
|
|
|
// returns true if key image <img> is present in spent key images storage
|
2014-12-06 21:37:22 +00:00
|
|
|
virtual bool has_key_image(const crypto::key_image& img) const = 0;
|
2014-10-06 23:46:25 +00:00
|
|
|
|
2015-10-25 10:45:25 +00:00
|
|
|
virtual bool for_all_key_images(std::function<bool(const crypto::key_image&)>) const = 0;
|
|
|
|
virtual bool for_all_blocks(std::function<bool(uint64_t, const crypto::hash&, const cryptonote::block&)>) const = 0;
|
|
|
|
virtual bool for_all_transactions(std::function<bool(const crypto::hash&, const cryptonote::transaction&)>) const = 0;
|
|
|
|
virtual bool for_all_outputs(std::function<bool(uint64_t amount, const crypto::hash &tx_hash, size_t tx_idx)> f) const = 0;
|
|
|
|
|
2015-09-20 17:41:38 +00:00
|
|
|
// Hard fork related storage
|
|
|
|
virtual void set_hard_fork_starting_height(uint8_t version, uint64_t height) = 0;
|
|
|
|
virtual uint64_t get_hard_fork_starting_height(uint8_t version) const = 0;
|
|
|
|
virtual void set_hard_fork_version(uint64_t height, uint8_t version) = 0;
|
|
|
|
virtual uint8_t get_hard_fork_version(uint64_t height) const = 0;
|
2016-01-15 14:00:58 +00:00
|
|
|
virtual void check_hard_fork_info() = 0;
|
2016-02-05 01:15:37 +00:00
|
|
|
virtual void drop_hard_fork_info() = 0;
|
2015-09-20 17:41:38 +00:00
|
|
|
|
2015-12-26 22:27:35 +00:00
|
|
|
virtual bool is_read_only() const = 0;
|
|
|
|
|
2015-12-06 20:48:17 +00:00
|
|
|
// fix up anything that may be wrong due to past bugs
|
|
|
|
virtual void fixup();
|
|
|
|
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
void set_auto_remove_logs(bool auto_remove) { m_auto_remove_logs = auto_remove; }
|
|
|
|
|
2015-03-25 15:41:30 +00:00
|
|
|
bool m_open;
|
** CHANGES ARE EXPERIMENTAL (FOR TESTING ONLY)
Bockchain:
1. Optim: Multi-thread long-hash computation when encountering groups of blocks.
2. Optim: Cache verified txs and return result from cache instead of re-checking whenever possible.
3. Optim: Preload output-keys when encoutering groups of blocks. Sort by amount and global-index before bulk querying database and multi-thread when possible.
4. Optim: Disable double spend check on block verification, double spend is already detected when trying to add blocks.
5. Optim: Multi-thread signature computation whenever possible.
6. Patch: Disable locking (recursive mutex) on called functions from check_tx_inputs which causes slowdowns (only seems to happen on ubuntu/VMs??? Reason: TBD)
7. Optim: Removed looped full-tx hash computation when retrieving transactions from pool (???).
8. Optim: Cache difficulty/timestamps (735 blocks) for next-difficulty calculations so that only 2 db reads per new block is needed when a new block arrives (instead of 1470 reads).
Berkeley-DB:
1. Fix: 32-bit data errors causing wrong output global indices and failure to send blocks to peers (etc).
2. Fix: Unable to pop blocks on reorganize due to transaction errors.
3. Patch: Large number of transaction aborts when running multi-threaded bulk queries.
4. Patch: Insufficient locks error when running full sync.
5. Patch: Incorrect db stats when returning from an immediate exit from "pop block" operation.
6. Optim: Add bulk queries to get output global indices.
7. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
8. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
9. Optim: Added thread-safe buffers used when multi-threading bulk queries.
10. Optim: Added support for nosync/write_nosync options for improved performance (*see --db-sync-mode option for details)
11. Mod: Added checkpoint thread and auto-remove-logs option.
12. *Now usable on 32-bit systems like RPI2.
LMDB:
1. Optim: Added custom comparison for 256-bit key tables (minor speed-up, TBD: get actual effect)
2. Optim: Modified output_keys table to store public_key+unlock_time+height for single transaction lookup (vs 3)
3. Optim: Used output_keys table retrieve public_keys instead of going through output_amounts->output_txs+output_indices->txs->output:public_key
4. Optim: Added support for sync/writemap options for improved performance (*see --db-sync-mode option for details)
5. Mod: Auto resize to +1GB instead of multiplier x1.5
ETC:
1. Minor optimizations for slow-hash for ARM (RPI2). Incomplete.
2. Fix: 32-bit saturation bug when computing next difficulty on large blocks.
[PENDING ISSUES]
1. Berkely db has a very slow "pop-block" operation. This is very noticeable on the RPI2 as it sometimes takes > 10 MINUTES to pop a block during reorganization.
This does not happen very often however, most reorgs seem to take a few seconds but it possibly depends on the number of outputs present. TBD.
2. Berkeley db, possible bug "unable to allocate memory". TBD.
[NEW OPTIONS] (*Currently all enabled for testing purposes)
1. --fast-block-sync arg=[0:1] (default: 1)
a. 0 = Compute long hash per block (may take a while depending on CPU)
b. 1 = Skip long-hash and verify blocks based on embedded known good block hashes (faster, minimal CPU dependence)
2. --db-sync-mode arg=[[safe|fast|fastest]:[sync|async]:[nblocks_per_sync]] (default: fastest:async:1000)
a. safe = fdatasync/fsync (or equivalent) per stored block. Very slow, but safest option to protect against power-out/crash conditions.
b. fast/fastest = Enables asynchronous fdatasync/fsync (or equivalent). Useful for battery operated devices or STABLE systems with UPS and/or systems with battery backed write cache/solid state cache.
Fast - Write meta-data but defer data flush.
Fastest - Defer meta-data and data flush.
Sync - Flush data after nblocks_per_sync and wait.
Async - Flush data after nblocks_per_sync but do not wait for the operation to finish.
3. --prep-blocks-threads arg=[n] (default: 4 or system max threads, whichever is lower)
Max number of threads to use when computing long-hash in groups.
4. --show-time-stats arg=[0:1] (default: 1)
Show benchmark related time stats.
5. --db-auto-remove-logs arg=[0:1] (default: 1)
For berkeley-db only. Auto remove logs if enabled.
**Note: lmdb and berkeley-db have changes to the tables and are not compatible with official git head version.
At the moment, you need a full resync to use this optimized version.
[PERFORMANCE COMPARISON]
**Some figures are approximations only.
Using a baseline machine of an i7-2600K+SSD+(with full pow computation):
1. The optimized lmdb/blockhain core can process blocks up to 585K for ~1.25 hours + download time, so it usually takes 2.5 hours to sync the full chain.
2. The current head with memory can process blocks up to 585K for ~4.2 hours + download time, so it usually takes 5.5 hours to sync the full chain.
3. The current head with lmdb can process blocks up to 585K for ~32 hours + download time and usually takes 36 hours to sync the full chain.
Averate procesing times (with full pow computation):
lmdb-optimized:
1. tx_ave = 2.5 ms / tx
2. block_ave = 5.87 ms / block
memory-official-repo:
1. tx_ave = 8.85 ms / tx
2. block_ave = 19.68 ms / block
lmdb-official-repo (0f4a036437fd41a5498ee5e74e2422ea6177aa3e)
1. tx_ave = 47.8 ms / tx
2. block_ave = 64.2 ms / block
**Note: The following data denotes processing times only (does not include p2p download time)
lmdb-optimized processing times (with full pow computation):
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.25 hours processing time (--db-sync-mode=fastest:async:1000).
2. Laptop, Dual-core / 4-threads U4200 (3Mb) - 4.90 hours processing time (--db-sync-mode=fastest:async:1000).
3. Embedded, Quad-core / 4-threads Z3735F (2x1Mb) - 12.0 hours processing time (--db-sync-mode=fastest:async:1000).
lmdb-optimized processing times (with per-block-checkpoint)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 10 minutes processing time (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with full pow computation)
1. Desktop, Quad-core / 8-threads 2600k (8Mb) - 1.8 hours processing time (--db-sync-mode=fastest:async:1000).
2. RPI2. Improved from estimated 3 months(???) into 2.5 days (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
berkeley-db optimized processing times (with per-block-checkpoint)
1. RPI2. 12-15 hours (*Need 2AMP supply + Clock:1Ghz + [usb+ssd] to achieve this speed) (--db-sync-mode=fastest:async:1000).
2015-07-10 20:09:32 +00:00
|
|
|
mutable epee::critical_section m_synchronization_lock;
|
2014-10-06 23:46:25 +00:00
|
|
|
}; // class BlockchainDB
|
|
|
|
|
|
|
|
|
|
|
|
} // namespace cryptonote
|
2014-10-15 22:33:53 +00:00
|
|
|
|
|
|
|
#endif // BLOCKCHAIN_DB_H
|