2015-12-31 01:39:56 -05:00
|
|
|
// Copyright (c) 2014-2016, The Monero Project
|
2015-12-13 23:54:39 -05:00
|
|
|
//
|
2014-07-23 09:03:52 -04:00
|
|
|
// All rights reserved.
|
2015-12-13 23:54:39 -05:00
|
|
|
//
|
2014-07-23 09:03:52 -04:00
|
|
|
// Redistribution and use in source and binary forms, with or without modification, are
|
|
|
|
// permitted provided that the following conditions are met:
|
2015-12-13 23:54:39 -05:00
|
|
|
//
|
2014-07-23 09:03:52 -04:00
|
|
|
// 1. Redistributions of source code must retain the above copyright notice, this list of
|
|
|
|
// conditions and the following disclaimer.
|
2015-12-13 23:54:39 -05:00
|
|
|
//
|
2014-07-23 09:03:52 -04: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-13 23:54:39 -05:00
|
|
|
//
|
2014-07-23 09:03:52 -04: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-13 23:54:39 -05:00
|
|
|
//
|
2014-07-23 09:03:52 -04: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.
|
2015-12-13 23:54:39 -05:00
|
|
|
//
|
2014-07-23 09:03:52 -04:00
|
|
|
// Parts of this file are originally copyright (c) 2012-2013 The Cryptonote developers
|
2014-03-03 17:07:58 -05:00
|
|
|
|
|
|
|
#include <algorithm>
|
|
|
|
#include <cassert>
|
|
|
|
#include <cstddef>
|
|
|
|
#include <cstdint>
|
|
|
|
#include <vector>
|
|
|
|
|
|
|
|
#include "common/int-util.h"
|
|
|
|
#include "crypto/hash.h"
|
|
|
|
#include "cryptonote_config.h"
|
|
|
|
#include "difficulty.h"
|
|
|
|
|
|
|
|
namespace cryptonote {
|
|
|
|
|
|
|
|
using std::size_t;
|
|
|
|
using std::uint64_t;
|
|
|
|
using std::vector;
|
|
|
|
|
** 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 16:09:32 -04:00
|
|
|
#if defined(__x86_64__)
|
2014-03-03 17:07:58 -05:00
|
|
|
static inline void mul(uint64_t a, uint64_t b, uint64_t &low, uint64_t &high) {
|
2014-05-03 12:19:43 -04:00
|
|
|
low = mul128(a, b, &high);
|
2014-03-03 17:07:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
#else
|
|
|
|
|
|
|
|
static inline void mul(uint64_t a, uint64_t b, uint64_t &low, uint64_t &high) {
|
2015-12-13 23:54:39 -05:00
|
|
|
// __int128 isn't part of the standard, so the previous function wasn't portable. mul128() in Windows is fine,
|
|
|
|
// but this portable function should be used elsewhere. Credit for this function goes to latexi95.
|
|
|
|
|
|
|
|
uint64_t aLow = a & 0xFFFFFFFF;
|
|
|
|
uint64_t aHigh = a >> 32;
|
|
|
|
uint64_t bLow = b & 0xFFFFFFFF;
|
|
|
|
uint64_t bHigh = b >> 32;
|
|
|
|
|
|
|
|
uint64_t res = aLow * bLow;
|
|
|
|
uint64_t lowRes1 = res & 0xFFFFFFFF;
|
|
|
|
uint64_t carry = res >> 32;
|
|
|
|
|
|
|
|
res = aHigh * bLow + carry;
|
|
|
|
uint64_t highResHigh1 = res >> 32;
|
|
|
|
uint64_t highResLow1 = res & 0xFFFFFFFF;
|
|
|
|
|
|
|
|
res = aLow * bHigh;
|
|
|
|
uint64_t lowRes2 = res & 0xFFFFFFFF;
|
|
|
|
carry = res >> 32;
|
|
|
|
|
|
|
|
res = aHigh * bHigh + carry;
|
|
|
|
uint64_t highResHigh2 = res >> 32;
|
|
|
|
uint64_t highResLow2 = res & 0xFFFFFFFF;
|
|
|
|
|
|
|
|
//Addition
|
|
|
|
|
|
|
|
uint64_t r = highResLow1 + lowRes2;
|
|
|
|
carry = r >> 32;
|
|
|
|
low = (r << 32) | lowRes1;
|
|
|
|
r = highResHigh1 + highResLow2 + carry;
|
|
|
|
uint64_t d3 = r & 0xFFFFFFFF;
|
|
|
|
carry = r >> 32;
|
|
|
|
r = highResHigh2 + carry;
|
|
|
|
high = d3 | (r << 32);
|
2014-03-03 17:07:58 -05:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
static inline bool cadd(uint64_t a, uint64_t b) {
|
|
|
|
return a + b < a;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool cadc(uint64_t a, uint64_t b, bool c) {
|
|
|
|
return a + b < a || (c && a + b == (uint64_t) -1);
|
|
|
|
}
|
|
|
|
|
|
|
|
bool check_hash(const crypto::hash &hash, difficulty_type difficulty) {
|
|
|
|
uint64_t low, high, top, cur;
|
|
|
|
// First check the highest word, this will most likely fail for a random hash.
|
|
|
|
mul(swap64le(((const uint64_t *) &hash)[3]), difficulty, top, high);
|
|
|
|
if (high != 0) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
mul(swap64le(((const uint64_t *) &hash)[0]), difficulty, low, cur);
|
|
|
|
mul(swap64le(((const uint64_t *) &hash)[1]), difficulty, low, high);
|
|
|
|
bool carry = cadd(cur, low);
|
|
|
|
cur = high;
|
|
|
|
mul(swap64le(((const uint64_t *) &hash)[2]), difficulty, low, high);
|
|
|
|
carry = cadc(cur, low, carry);
|
|
|
|
carry = cadc(high, top, carry);
|
|
|
|
return !carry;
|
|
|
|
}
|
|
|
|
|
2016-03-25 02:42:42 -04:00
|
|
|
difficulty_type next_difficulty(vector<uint64_t> timestamps, vector<difficulty_type> cumulative_difficulties, size_t target_seconds) {
|
|
|
|
//cutoff DIFFICULTY_LAG
|
2014-03-03 17:07:58 -05:00
|
|
|
if(timestamps.size() > DIFFICULTY_WINDOW)
|
|
|
|
{
|
|
|
|
timestamps.resize(DIFFICULTY_WINDOW);
|
|
|
|
cumulative_difficulties.resize(DIFFICULTY_WINDOW);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
size_t length = timestamps.size();
|
|
|
|
assert(length == cumulative_difficulties.size());
|
|
|
|
if (length <= 1) {
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
static_assert(DIFFICULTY_WINDOW >= 2, "Window is too small");
|
|
|
|
assert(length <= DIFFICULTY_WINDOW);
|
|
|
|
sort(timestamps.begin(), timestamps.end());
|
|
|
|
size_t cut_begin, cut_end;
|
|
|
|
static_assert(2 * DIFFICULTY_CUT <= DIFFICULTY_WINDOW - 2, "Cut length is too large");
|
|
|
|
if (length <= DIFFICULTY_WINDOW - 2 * DIFFICULTY_CUT) {
|
|
|
|
cut_begin = 0;
|
|
|
|
cut_end = length;
|
|
|
|
} else {
|
|
|
|
cut_begin = (length - (DIFFICULTY_WINDOW - 2 * DIFFICULTY_CUT) + 1) / 2;
|
|
|
|
cut_end = cut_begin + (DIFFICULTY_WINDOW - 2 * DIFFICULTY_CUT);
|
|
|
|
}
|
|
|
|
assert(/*cut_begin >= 0 &&*/ cut_begin + 2 <= cut_end && cut_end <= length);
|
|
|
|
uint64_t time_span = timestamps[cut_end - 1] - timestamps[cut_begin];
|
|
|
|
if (time_span == 0) {
|
|
|
|
time_span = 1;
|
|
|
|
}
|
|
|
|
difficulty_type total_work = cumulative_difficulties[cut_end - 1] - cumulative_difficulties[cut_begin];
|
|
|
|
assert(total_work > 0);
|
|
|
|
uint64_t low, high;
|
|
|
|
mul(total_work, target_seconds, low, high);
|
|
|
|
if (high != 0 || low + time_span - 1 < low) {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
return (low + time_span - 1) / time_span;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|