Bitcoin full node and query server

March 2023

Archive of the libbitcoin Slack #general channel.

Wednesday, March 8, 2023

evoskuil05:27

Back from a few days at a small conf in Jackson Hole. I completed the message broadcaster, which allows protocols to subscribe to messages by type, broadcast internally from other channels. This is an analog to the message distributor, which allows protocols to subscribe to messages by type, sent from the peer of the protocol's channel. This was some backlog I wanted to work off in order to normalize the processing of both types of messages. Both distributor and broadcaster incorporate some optimizations for hashing messages.

👍 1

Thursday, March 9, 2023

evoskuil06:32

Today I added [network].bind = 0.0.0.0:8333 type configuration settings to replace the simple port-only config for inbound connections. The above will bind to all NICs on IPv4, and [network].bind = [::]:8333 will bind all on ipv6. Otherwise individual NICs (including local host) can be explicitly bound. This provides a huge increase in flexibility and was pretty simple - one day implementation and test. This also included a change to the [network].self = 42.42.42.42:8333 setting, which is used to advertised one's own address. This is no a multivalued setting, so that multiple public addresses can be advertised to peers. Note that bound endpoints and public addresses are independent for both security and flexibility purposes.

06:33

This should be merged in a few minutes, feel free to try it out. Note that config settings can always be discovered using bn -s.

evoskuil06:48

merged.

pmienk17:00

Topic: Dev Weekly Status Time: March 9, 2023 01:00pm Pacific Time (US and Canada) Join Zoom Meeting https://us05web.zoom.us/j/87666370902?pwd=bEZDUlJ0MGJ5V3dVMUhVdHl5QzdFdz09 Meeting ID: 876 6637 0902 Passcode: 85U0bF

evoskuil20:59

On my way

pmienk21:01

Cool, might be a little rocky. Internet is out here, using my phone. Fingers crossed

Sunday, March 12, 2023

evoskuil10:52

Today I applied the new broadcaster to address message relay between channels. After a few tweaks it's working smoothly. This is a secondary source of incoming messages to a protocol, for which a protocol can register. The other is of course peer traffic. In this case a trickle of message traffic is broadcast to other channels and then sent to peers. The includes the first address message which is unsolicited and sent upon connection as a matter of convention, as a way to advertise one's own address(es). Later the broadcaster will be used for such things as tx forwarding.

(edited)

Wednesday, March 15, 2023

evoskuil07:09

Today I moved fully to node blockchain processing. 🕺🏻

evoskuil07:17

I created the header_in protocol and added it to node sessions using protocol attachment overloading. The store query engine is exposed by protocol base. Used network::message locator heights generation, passed to database::get hashes(heights) and was quickly generating a proper locator sequence (although with no candidate/confirmed blocks these always start at genesis). Set up a SEND(get_headers) and a SUBSCRIBE(headers) and was immediately iterating over the full chain, storing each header. The store is fully concurrent, so need to worry about bouncing store calls to a common strand. Set up a few log messages and watched it run.

07:18

No problems, except it was much slower than I expected, regardless of peer.

07:22

So I dropped out the database storage, which solved that problem. This led me to realize that I had not bucketized the store - all hashmaps are 100 buckets. Not so great when storing 781,000 blocks, basically linear. :<

07:23

So after some quick computations and adding two settings to the config file, I restored the database archival and completed a full header sync against one random peer in 76 seconds, which is well within expectations.

(edited)

evoskuil07:52

The full headers_in protocol, less comments, log messages, and assertions:

void protocol_header_in::start() NOEXCEPT
{
    if (started())
        return;

    SUBSCRIBE_CHANNEL2(headers, handle_receive_headers, _1, _2);
    SEND1(create_get_headers(), handle_send, _1);
    protocol::start();
}

bool protocol_header_in::handle_receive_headers(const code& ec, const headers::cptr& message) NOEXCEPT
{
    if (stopped(ec))
        return false;

    for (const auto& header: message->header_ptrs)
    {
        if (!query().set(*header, database::context{}))
        {
            stop(network::error::protocol_violation);
            return false;
        }
    };

    if (message->header_ptrs.size() == max_get_headers)
    {
        SEND1(create_get_headers({ message->header_ptrs.back()->hash() }), handle_send, _1);
    }

    return true;
}

get_headers protocol_header_in::create_get_headers() NOEXCEPT
{
    return create_get_headers(query().get_hashes(get_blocks::heights(query().get_top_candidate())));
}

get_headers protocol_header_in::create_get_headers(hashes&& hashes) NOEXCEPT
{
    return { std::move(hashes), null_hash };
}

07:52

handle_send is a base protocol nop handler.

07:57

This simplicity and isolation of protocol implementation is a major design goal of the network stack. Each channel instance operates on its own strand, and all protocol handlers (and protocol::start()) are guaranteed stranded invocation, so they can be coded as if on a single thread. Above is still early, as the headers need to populate an in-memory graph and reorg into the candidate chain based on strength. But the protocol won't be any more complicated.

(edited)

08:01

The fact that all queries are now thread safe, and incorporate transactional commit, is also significantly simplifying. There is no need for query completion handing, queries ideally run sequentially. Each channel conversation is ordered on its own strand and can execute concurrently across channels.

(edited)

08:06

Header sync performance across peers is presently anecdotal, but I just had a peer show up inbound and complete a full header sync (inbound to the node) in 20 secs, so clearly peer speed is the most limiting factor.

Thursday, March 16, 2023

evoskuil08:33

Did some more work on the headers protocol today. One of the things I wanted to look at was the benefit of obtaining identity hashes from the wire serialization (vs. the header.hash() method, which reserializes the header into the hash accumulator). The tradeoff is memory (caching the hashes) for speed (no need to reserialize to obtain the hash). With headers the expected gain is minimal, since the reserialization is trivial. However, the net difference when applied to the headers message is about 35% reduction in header sync time. I found two very reliable peers, which have fast and reliable times for header sync. They average 14.5 seconds without the caching and 9.5 seconds with it. This implies that the advantage to for applying this to tx hashing should be significant. Even 35% would be huge, but I'd guess we'd be closer to 50% improvement.

(edited)

08:35

The implementation was trivial, based on work in system and network previously done in anticipation.

evoskuil08:40

The best I've seen so far, for 781,000 headers, iterating 2,000 at a time from a peer, each validated, looked-up, and stored, is 8 seconds. In years past, on the same computer, with closer to 500,000 blocks, the best we saw was 30-45 secs.

🎉 1

pmienk16:00

Topic: Dev Weekly Status Time: March 16, 2023 01:00pm Pacific Time (US and Canada) Join Zoom Meeting https://us05web.zoom.us/j/87666370902?pwd=bEZDUlJ0MGJ5V3dVMUhVdHl5QzdFdz09 Meeting ID: 876 6637 0902 Passcode: 85U0bF

Saturday, March 18, 2023

evoskuil02:42

Got a few smaller things down yesterday after the meeting. I stubbed in the block and transaction protocols, inbound and outbound. Also resolved a small issue whereby the version protocols need access to the store top, though they are in network not node. Then I installed my new 2TB dedicated blockchain SSD and ran a bunch of tests. Startup and shutdown are clearly much faster than on my HDD, especially with a large address pool. Today I worked on making the logging and console systems simpler and more robust. That's all complete now. The console input can now enable/disable any log level dynamically. Default log levels are initialized with consideration of what log levels may have been compiled out entirely. Events, which use the log system but include no textual messaging, now include a span event, which accepts a starting time_point and diffs that with current time at invocation so that duration of asynchronous operations can be easily logged as events.

👍 1

Monday, March 20, 2023

evoskuil08:47

Implemented basic blocks first sync yesterday. Spent today analyzing it. Overall everything is looking great. From a single peer I downloaded 480,555 blocks, parsed, hashed and stored all headers and txs. I stopped the run today to look at the flush behavior. It took about 15 minutes to flush that full run to my HDD (146.5GB). The network stop is always almost instant, only flushing the logging buffer will slow it down. The store stop is now isolated from that, so we get a clear measure and indication of store flush progress. I'm probably going to add events so that we can reflect progress. There are a lot of tables, and we can get feedback from the msync and fsync completion of each one. That's as good as it will get for the memory maps, but that's enough to know that it isn't dead. The event logging system can be used by a UI to provide progress/feedback for these types of things.

🎉 1