「Bitcoin Core 0.11 (ch 3): Initialization and Startup」の版間の差分

提供: tezos-wiki
移動先: 案内検索
(1版 をインポートしました)
 
(同じ利用者による、間の1版が非表示)
1行目: 1行目:
  
This page describes the Bitcoin Core code that manages startup and initialization.
+
このページでは、起動と初期化を管理するBitcoin Coreコードについて説明します。
  
==Program entry point==  
+
==プログラムエントリポイント==
  
The program's entry point can be found in <u>bitcoind.cpp</u>.
+
プログラムのエントリポイントは<u> bitcoind.cpp </u>にあります。
  
main() is three lines of code:
+
main()はコードの3行です:
* SetupEnvironment() (all this does is set the program's locale)
+
* SetupEnvironment()(これはプログラムのロケールを設定します)
* Connect signal handlers
+
*信号ハンドラを接続する
* AppInit() (this function loops for the life of the program)
+
* AppInit()(この関数はプログラムの寿命を延ばす)
  
  
AppInit:  this is located nearby in <u>bitcoind.cpp</u>:
+
AppInit:これは<u> bitcoind.cpp </u>の近くにあります。
* Parses the command line
+
*コマンドラインを解析する
* Opens the data directory
+
*データディレクトリを開きます。
* Reads the config file
+
*設定ファイルを読み込みます
* Forks a process (if running as a daemon)
+
*プロセスをフォークします(デーモンとして実行している場合)
* Passes control to AppInit2(), found in <u>init.cpp</u>.
+
*コントロールを<u> init.cpp </u>にあるAppInit2()に渡します。
  
  
==Initialization steps (<u>init.cpp</u>)==
+
==初期化ステップ(<u> init.cpp </u>==
  
AppInit2() initializes the bitcoin system. 
+
AppInit2()はビットコインシステムを初期化します。
  
It contains about 800 lines of code, which are broken into 12 steps. 
+
これには約800行のコードが含まれており、12段階に分かれています。
  
Where each step begins is documented in the code. <u>Init.cpp</u> has a few functions at the top of the file, but for the most part it consists of AppInit2().
+
各ステップが始まる場所は、コードに文書化されています。 <u> Init.cpp </u>にはファイルの先頭にいくつかの関数がありますが、大部分はAppInit2()で構成されています。
 
 
The following table summarizes the steps:
 
  
 +
次の表は、手順をまとめたものです。
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Initialization<br>Step !! Short Description !! Longer Description
+
! 初期化<br>ステップ !! 簡単な説明 !! 詳細
 
|-
 
|-
| 1 || OS-specific setup tasks || These tasks are not particularly interesting.<br>For more info, see the code.  
+
| 1 || OS固有のセットアップタスク || これらの作業は特に興味深いものではありません。<br>詳細は、コードを参照してください。  
 
|-
 
|-
| 2 || Parameter Interactions || Certain command-line options require other options to be set in a certain way.<br>For example, -zapwallettxes implies a -rescan, thus the code will set the -rescan flag=true if it isn't already.  
+
| 2 || パラメータの相互作用 || 特定のコマンドラインオプションでは、特定の方法で他のオプションを設定する必要があります。<br>たとえば、-zapwallettxesは-rescanを意味します。したがって、コードは-rescanフラグ= trueを設定します(まだ存在していない場合)。  
 
|-
 
|-
| 3 || Internal flags / <br>Parameter sanity-check || Sets global variables for certain parameters.<br>For the wallet, it sanity-checks transaction fee levels (makes sure your fee is high enough to qualify for relay [error]; but not absurdly high [warning]).  
+
| 3 || 内部フラグ / <br>パラメータ健全性チェック || 特定のパラメータのグローバル変数を設定します。<br>財布については、取引料金レベルを正当性をチェックします(あなたの手数料がリレー[エラー]の資格を得るのに十分高いが、不当に高い[警告]ではないことを確認します)。  
 
|-
 
|-
| 4 || Application init. / RPC Server ||  
+
| 4 || アプリケーション初期化。 / RPCサーバー ||  
Locks the data directory.  (If unable, print error and quit.)<br>
+
データディレクトリをロックします。 (できない場合は、エラーを出力して終了してください。)<br>
Spawn X threads for the Script-checking engine. (Default=0, meaning use all available processors; boost::thread::hardware_concurrency).<br>
+
スクリプトチェックエンジン用のXスレッドを生成する。 (デフォルト= 0、使用可能なすべてのプロセッサを使用することを意味し、boost :: thread :: hardware_concurrency)。<br>
Start RPC server in "warmup" mode.
+
"ウォームアップ"モードでRPCサーバーを起動します。
 
|-
 
|-
| 5 || Verify wallet database integrity || If wallet is enabled, try to open it.<br>
+
| 5 || ウォレット・データベースの整合性の確認 || ウォレットが有効になっている場合は、開こうとします。<br>
If the user knows that the wallet has been corrupted (-salvagewallet), try to recover the private keys.  
+
ウォレットが破損していることがわかっている場合(-salvagewallet)、パスワードの回復を試みます。  
 
|-
 
|-
| 6 || Network Initialization ||  
+
| 6 || ネットワーク初期化 ||  
The node registers for certain signals.<br>
+
ノードは特定の信号を登録する。<br>
Checks whether the user wants to interact only with peers on a certain network (ip4, ip6, tor).<br>
+
ユーザーが特定のネットワーク(ip4、ip6、tor)のピアとのみ対話したいかどうかを確認します。<br>
Checks whether to use onion routing (tor).<br>
+
オニオンルーティング(tor)を使用するかどうかをチェックします。<br>
Checks whether the user wants to whitelist any specific peers.<br>
+
ユーザーが特定のピアをホワイトリストに登録するかどうかを確認します。<br>
Attempts to listen on the bitcoin port (exits on failure).<br>
+
ビットコインポートでリスンしようとします(失敗時に終了します)。<br>
If user specified a certain peer to seed connections, attempt to connect.  
+
ユーザーが接続をシードする特定のピアを指定した場合は、接続を試みます。  
 
|-
 
|-
| 7 || Load the block chain. ||  
+
| 7 || ブロックチェーンをロードします。 ||  
Load the blockchain into memory and initialize the UTXO caches.<br>
+
ブロックチェーンをメモリにロードし、UTXOキャッシュを初期化します。<br>
 
<br>
 
<br>
<u>Calculate cache sizes.</u><br>
+
<u>キャッシュサイズを計算します。</u><br>
There is a total cache size, which is divided amongst three specific caches.<br>  
+
3つの特定のキャッシュに分割された合計キャッシュサイズがあります。<br>  
Default total cache size = 100MB (Max: 4 GB, min: 4 MB).<br>   
+
デフォルトの合計キャッシュサイズ= 100MB(最大:4GB、最小:4MB)。<br>   
1) Blockchain cache:  1/8 of the total cache, but shouldn't be larger than 2MB.<br>
+
1)ブロックチェーンキャッシュ:合計キャッシュの1/8ですが、2MBを超えてはいけません。<br>
2) UTXO database cache : 25-50% of the remaining cache space.  This is the LevelDB cache.<br>
+
2)UTXOデータベース・キャッシュ:残りのキャッシュ・スペースの25〜50%。 これはLevelDBキャッシュです。<br>
This stores uncompressed blocks of LevelDB data and is managed by LevelDB, as described in [http://leveldb.googlecode.com/git-history/1.17/doc/index.html the LevelDB documentation.]<br>
+
これは、LevelDBデータの圧縮されていないブロックを格納し、LevelDBによって管理されます。[http://leveldb.googlecode.com/git-history/1.17/doc/index.html the LevelDB documentation.]<br>
3) UTXO in-memory cache: Half of the remaining cache space.<br>
+
3)UTXOインメモリキャッシュ:残りのキャッシュスペースの半分。<br>
This cache size defines the size of the cacheCoins object (a protected member of CoinsViewCache).<br>
+
このキャッシュサイズは、cacheCoinsオブジェクト(CoinsViewCacheの保護されたメンバー)のサイズを定義します。<br>
TODO: verify that this statement is correct... <br>
+
TODO:このステートメントが正しいことを確認してください... <br>
 
<br>
 
<br>
<u>Load the blockchain into mapBlockIndex.</u><br>
+
<u>ブロックチェーンをmapBlockIndexにロードします。</u><br>
By "blockchain" this means the entire block tree (all known blocks, not just those in the active chain.)<br>
+
「ブロックチェイン」とは、ブロックツリー全体(アクティブチェーン内のブロックだけでなく、すべての既知のブロック)を意味します。<br>
What is loaded into memory are the CBlockIndex objects, which contain metadata about the block. <br>
+
メモリにロードされるのはブロックに関するメタデータを含むCBlockIndexオブジェクトです。<br>
Verifies the last 288 blocks (VerifyDB).<br>
+
最後の288ブロック(VerifyDB)を検証します。<br>
Note: The program takes less than 1 second from startup until this point;  this step takes about 10-20 seconds.<br>
+
注意:プログラムはこの時点までに起動から1秒未満を要します。 このステップには約10〜20秒かかります。<br>
 
<br>
 
<br>
<u>The UTXO set.</u><br>
+
<u>UTXOセット。</u><br>
The UTXO set is not loaded into memory; instead, the cache will be filled as coins are accessed from the database.<br>
+
UTXOセットはメモリにロードされません。 代わりに、コインがデータベースからアクセスされるときにキャッシュがいっぱいになります。<br>
Note that as of May 2015, storing the entire UTXO set in memory would require about 3.6 GB.<br>
+
2015年5月現在、UTXOセット全体をメモリに格納するには約3.6 GBが必要です。<br>
As of Jan. 2016, the compressed data on disk is about 1.2 GB.
+
2016年1月現在、ディスク上の圧縮データは約1.2 GBです。
 
|-
 
|-
| 8 || Load the wallet. || If this is the first time the program has been run, it creates a wallet and gives you an initial key (address).
+
| 8 || ウォレットをロードします。 || プログラムが初めて実行された場合は、ウォレットが作成され、最初のキー(アドレス)が与えられます。
 
|-
 
|-
| 9 || Datadir maintenance || If the user is block-pruning, unset NODE_NETWORK and call the pruning function.
+
| 9 || Datadirのメンテナンス || ユーザーがブロックプルーニングを行っている場合は、NODE_NETWORKの設定を解除し、プルーニング機能を呼び出します。
 
|-
 
|-
| 10 || Import blocks || Scan for better chains in the block chain database, that are not yet connected as the active best chain.
+
| 10 || インポートブロック || 現在有効なチェーンとして接続されていないブロックチェーンデータベースのチェーンをスキャンします。
 
|-
 
|-
| 11 || Start node /<br>RPC server ||  
+
| 11 || 開始ノード /<br>RPCサーバー ||  
Calls StartNode in net.cpp.<br>
+
net.cppでStartNodeを呼び出します。<br>
This starts up the networking thread group, including ThreadProcessMessage, which is the program's main thread (see below). <br>
+
これは、プログラムのメインスレッドであるThreadProcessMessageを含むネットワーキングスレッドグループを起動します(下記参照)。 <br>
Transition RPC server from "warmup" mode to normal mode.
+
RPCサーバーを "ウォームアップ"モードから通常モードに移行します。
 
|-
 
|-
| 12 || Finished
+
| 12 || 終了
 
|}
 
|}
  
  
When AppInit2 finishes, control returns to AppInit() in <u>bitcoind.cpp</u>.
+
AppInit2が終了すると、<u> bitcoind.cpp </u>のAppInit()に戻ります。
 
 
There, the code's top-level thread loops indefinitely in a function called WaitForShutdown().  It sleeps for 2 seconds and checks to see if the user pressed ctrl-C.  If so, it calls Shutdown() back in <u>init.cpp</u>.
 
  
Shutdown() shuts down the RPC server, stops the node, unregisters the signal handlers, etc., and then the program completes.
+
そこで、コードのトップレベルスレッドは、WaitForShutdown()という関数で無期限にループします。 2秒間スリープ状態になり、ユーザーがctrl-Cを押したかどうかを確認します。 その場合は、<u> init.cpp </u>でShutdown()を呼び出します。
  
==Cache Sizes==
+
シャットダウン()は、RPCサーバーをシャットダウンし、ノードを停止し、シグナルハンドラの登録を解除し、プログラムが完了します。
  
Step 7 initialized the cache sizes.  There are 3 caches contemplated in step 7.  Two are LevelDB database caches and the other is the coins cache, whose size is managed by the flushing code in <u>main.cpp</u>.
+
==キャッシュサイズ==
  
The user can allocate a total cache size with -dbcache. The user cannot pick and choose how much space to allocate to each specific cache. The default total cache size = 100MB (Max: 4 GB, min: 4 MB). 
+
ステップ7は、キャッシュサイズを初期化した。手順7で考えられる3つのキャッシュがあります.2つはLevelDBデータベースキャッシュであり、もう1つはコインキャッシュであり、そのサイズは<u> main.cpp </u>のフラッシュコードによって管理されます。
  
'''1) Block index cache'''
+
ユーザーは、-dbcacheを使用して合計キャッシュ・サイズを割り当てることができます。ユーザーは、特定の各キャッシュに割り当てるスペースを選択して選択することはできません。デフォルトの合計キャッシュサイズ= 100MB(最大:4GB、最小:4MB)。
  
This cache stores uncompressed chunks of the /blocks/index LevelDB data and is managed by LevelDB, as described in [http://leveldb.googlecode.com/git-history/1.17/doc/index.html the LevelDB documentation.]<br>
+
'' '1)ブロックインデックスキャッシュ' ''
  
If the user enables a full transaction index (-txindex=1) it can be up to 1/8 of the total cache size.  If -txindex is not enabled then only 2 MiB is needed.  
+
このキャッシュには、/ block / index LevelDBデータの圧縮されていないチャンクが保存され、[http://leveldb.googlecode.com/git-history/1.17/doc/index.html LevelDBのドキュメント]に記載されているように、LevelDBによって管理されます。 br>
  
 +
ユーザーが完全なトランザクションインデックス(-txindex = 1)を有効にした場合、合計キャッシュサイズの1/8までになります。 -txindexが有効でない場合は、2 MiBだけが必要です。
  
'''2) UTXO database cache'''
 
  
This is the LevelDB cache for the /chainstate database.
+
'' '2)UTXOデータベースキャッシュ' ''
  
This cache is allocated 25-50% of the remaining cache space, depending on the total cache size.
+
これは、/ chainstateデータベースのLevelDBキャッシュです。
  
 +
このキャッシュは、合計キャッシュ・サイズに応じて、残りのキャッシュ・スペースの25〜50%に割り振られます。
  
'''3)  UTXO in-memory cache'''
 
  
This is the coins cache that is managed by the <u>main.cpp</u> code. (see FlushStateToDisk and related functions)
+
'' '3)UTXOインメモリキャッシュ' ''
  
The variable (nCoinsCache) is declared as extern in <u>main.h</u>.  In <u>main.cpp</u>, it is hard-coded to 5000 * 300 (in-memory coins are about 300 bytes, so this means 5000 coins), however it should be re-initialized in Step 7.
+
これは<u> main.cpp </u>コードで管理されるコインキャッシュです。 (FlushStateToDiskおよび関連する関数を参照)
  
This cache is given all of the remaining cache space.  
+
変数(nCoinsCache)は、<u> main.h </u>のexternとして宣言されています。 <u> main.cpp </u>には、5000 * 300にハードコードされています(メモリ内コインは約300バイトなので5000コインを意味します)。しかし、ステップ7で再初期​​化する必要があります。
  
This cache is not loaded during initialization, rather it is filled as coins are accessed.  (This can be verified by the CCoinsViewCache constructor, which sets cachedCoinsUsage=0.)
+
このキャッシュには残りのキャッシュ領域がすべて与えられます。
  
==Thread Startup==
+
このキャッシュは、初期化中にロードされるのではなく、コインがアクセスされるときに満たされます。 (これは、cachedCoinsUsage = 0を設定するCCoinsViewCacheコンストラクタによって検証できます)。
  
The code uses boost::thread_groups to manage the various threads.
+
==スレッド起動==
  
It should be noted that although Bitcoin Core is a multi-threaded program, "the reference Satoshi client is largely single-threaded." [https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki Comment by Mike Hearn in BIP 31 (2012)]
+
このコードでは、boost :: thread_groupsを使用してさまざまなスレッドを管理しています。
  
What is meant is that the vast majority of the program's activity takes place in the messaging thread (ThreadMessageHandler - see below.
+
Bitcoin Coreはマルチスレッドプログラムですが、 "参照Satoshiクライアントは主にシングルスレッドです"ということに注意してください。 [https://github.com/bitcoin/bips/blob/master/bip-0031.mediawiki BIP 31(2012)のMike Hearnによるコメント]
  
Almost all of the threads are part of a single, master thread group that is created on the stack at program startup (see <u>bitcoind.cpp</u>). This thread group is passed to <u>init.cpp</u> which creates a few child threads (including a number of script-checking threads, but these are all part of the master thread group, not a separate group.)
+
つまり、プログラムの活動の大部分がメッセージングスレッド(ThreadMessageHandler - 以下を参照)で行われるということです。  
  
The thread group is passed to <u>net.cpp</u>, which creates the networking threads, including the message-processing thread.  
+
ほとんどすべてのスレッドは、プログラムの起動時にスタック上に作成される単一のマスタースレッドグループの一部です(<u> bitcoind.cpp </u>を参照)。このスレッドグループはいくつかの子スレッドを生成する<u> init.cpp </u>に渡されます(いくつかのスクリプト検査スレッドを含みますが、これらはすべて別個のグループではなくマスタースレッドグループの一部です)。
  
The two other thread groups are task-specific:
+
スレッドグループは<u> net.cpp </u>に渡され、メッセージ処理スレッドを含むネットワーキングスレッドが作成されます。
* rpc server thread group (see <u>rpcserver.h/cpp</u>)
 
* miner thread group
 
  
Naturally, the node will only create the RPC server thread group if the RPC server is activated, and will only create the miner thread group if it is mining.  If both are disabled, then Bitcoin Core only has a single thread group.  
+
2つの他のスレッドグループはタスク固有です。
 +
* rpcサーバースレッドグループ(<r> rpcserver.h / cpp </u>を参照)
 +
* minerスレッドグループ
  
'''Child Threads'''
+
当然のことながら、ノードはRPCサーバーがアクティブになっている場合にのみRPCサーバースレッドグループを作成し、マイナースレッドグループがマイニングの場合にのみ作成します。両方が無効の場合、Bitcoin Coreは単一のスレッドグループしか持たない。
  
The parent thread (meaning the thread in which the program begins operating) delegates almost all of the program's work to child threads.  After spawning threads in <u>init.cpp</u> and <u>net.cpp</u>, the parent thread simply listens for a shutdown command, at which time the parent thread needs only to interrupt the threads in its thread group and proceed with shutdown.
+
'' '子スレッド' ''
  
The child threads are summarized in this table, listed in the order in which they are created:
+
親スレッド(プログラムが動作を開始するスレッドを意味する)は、ほとんどすべてのプログラムの作業を子スレッドに委譲します。 <u> init.cpp </u>と<u> net.cpp </u>でスレッドを生成した後、親スレッドは単にシャットダウンコマンドを待ちます。スレッドグループを開き、シャットダウンを続行します。
  
 +
子スレッドは、作成された順にリストされています。
  
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Thread !! When / Where Created !! Description
+
! スレッド !! いつ / どこで作成されました !! 説明
 
|-
 
|-
| Script-checking || Step 4<br>init.cpp || This is a set of threads - 4 by default.<br>Script-checking (including signature checking) is expensive so is handled in separate threads.
+
| スクリプトチェック || ステップ4<br>init.cpp || これはスレッドのセットで、デフォルトでは4です。<br>スクリプトチェック(署名チェックを含む)は高価なので、別のスレッドで処理されます。
 
|-
 
|-
| Scheduler || Step 4<br>init.cpp ||  Scheduler thread.<br> (TODO: describe)
+
| スケジューラ || ステップ4<br>init.cpp ||  スケジューラスレッド。<br> (TODO: describe)
 
|-
 
|-
| RPC Threads || Step 4<br>rpcserver.cpp ||  If RPC server enabled, start a group of threads to handle RPC calls.
+
| RPCスレッド || ステップ4<br>rpcserver.cpp ||  RPCサーバーが有効な場合は、RPC呼び出しを処理するスレッドのグループを開始します。
 
|-
 
|-
| Import || Step 10<br>init.cpp ||  Imports blocks. Three scenarios:<br>1) Reindex (rescan all known blocks from blk???.dat files).<br>2) Bootstrap (use bootstrap.dat as an alternative to full IBD from the network.)<br>3) -loadblock (scan a specific blk???.dat file)<br>If none of those apply, this thread does nothing.
+
| インポート || ステップ10<br>init.cpp ||  ブロックをインポートします。 3つのシナリオ:<br>1)再インデックス(blk ??? datファイルからすべての既知のブロックを再スキャンする)。<br>2)ブートストラップ(bootstrap.datをネットワークからの完全なIBDの代わりに使用します)。<br>3)-loadblock(特定のblk ???。datファイルをスキャンする) - これらのどれも適用されない場合、このスレッドは何もしません。
 
|-
 
|-
| DNSAddressSeed || Step 11<br>net.cpp || Attempts to build a vector of IP addresses based on the dns seeds, stores the vector and the thread exits.<br>In a test in June 2014, this took about 4 seconds and found 158 addresses.
+
| DNSアドレスシード || ステップ11<br>net.cpp || dnsシードに基づいてIPアドレスのベクトルを構築しようとし、ベクトルとスレッドを終了します。<br>2014年6月のテストでは、これには約4秒かかり、158のアドレスが見つかりました。
 
|-
 
|-
| Plug & Play || Step 11<br>net.cpp ||  UPNP (Universal Plug & Play) <br>Deals with port mapping for UPNP.
+
| プラグ&プレイ || ステップ11<br>net.cpp ||  UPNP(ユニバーサルプラグ&プレイ) <br>UPNPのポートマッピングを扱う。
 
|-
 
|-
| SocketHandler || Step 11<br>net.cpp || <u>This thread services the sockets:</u><br>Waits for I/O on all the relevant sockets with a 50ms timeout.<br>Processes new incoming connections on listening socket and creates a CNode for the new peer.<br>Receives and sends data streams.<br>Sets sockets that have not done anything to a disconnected state.
+
| SocketHandler || ステップ11<br>net.cpp || <u>このスレッドはソケットをサービスします:</u><br>関連するすべてのソケットのI / Oを50msのタイムアウトで待機します。<br>リスニングソケットで新しい着信接続を処理し、新しいピアのCNodeを作成します。<br>データストリームを受信して送信します。<br>何もしなかったソケットを切断状態に設定します。
 
|-
 
|-
| OpenAddedConnections || Step 11<br>net.cpp || Initiates outbound connections specified by the user with the –addnode parameter.<br>If can't connect, sleeps for 2 minutes each cycle.
+
| OpenAddedConnections || ステップ11<br>net.cpp || -addnodeパラメーターを使用して、ユーザーが指定したアウトバウンド接続を開始します。<br>接続できない場合、各サイクルで2分間スリープします。
 
|-
 
|-
| OpenConnections || Step 11<br>net.cpp || Initiates other outbound connections from DNS seeds (if that fails, find nodes based on fixed seeds)<br>If can't connect, sleeps for 500 milliseconds each cycle.
+
| OpenConnections || ステップ11<br>net.cpp || DNSシードから他のアウトバウンド接続を開始する(失敗した場合、固定シードに基づいてノードを見つける)<br>接続できない場合、各サイクルで500ミリ秒間スリープします。
 
|-
 
|-
| MessageHandler || Step 11<br>net.cpp || <u>This is the program's main thread.</u> <br> This thread runs a while(true) loop, receiving and sending messages. (See <u>net.cpp</u>:1049) <br>The code uses boost::signals2 to call the ProcessMessages and SendMessages functions in main.cpp.<br>(The code introducing signals is in PR 2154 - see the next-to-last commit in that pull.)<br>ProcessMessage and SendMessage run in this thread.<br>So, most of the code in <u>main.cpp</u> runs in this thread.
+
| MessageHandler || ステップ11<br>net.cpp || <u>これがプログラムの主なスレッドです。</u> <br> このスレッドはwhile(true)ループを実行し、メッセージの送受信を行います。 (参照 <u>net.cpp</u>:1049) <br>このコードでは、boost :: signals2を使用してmain.cppのProcessMessages関数とSendMessages関数を呼び出します。<br>(シグナルを導入するコードはPR 2154にあります - そのプルで最後から2番目のコミットを参照してください)。<br>ProcessMessageとSendMessageはこのスレッドで実行されます。<br>したがって、<u> main.cpp </u>のコードのほとんどはこのスレッドで実行されます。
 
|-
 
|-
| Wallet Flusher || Step 12<br>init.cpp || If wallet is enabled, this thread flushes the wallet periodically.
+
| ウォレットフリュッシャー || ステップ12<br>init.cpp || ウォレットが有効な場合、このスレッドは定期的にウォレットをフラッシュします。
 
|}
 
|}
  
  
  
==See also==
+
==関連項目==
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1):_Overview Bitcoin Core 0.11 (Ch 1): Overview]
+
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_1):_オーバービューBitcoin Core 0.11(Ch 1):概要]
 
<br>
 
<br>
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage Bitcoin Core 0.11 (Ch 2): Data Storage]
+
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_2):_Data_Storage Bitcoin Core 0.11(Ch 2):データストレージ]
 
<br>
 
<br>
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_4):_P2P_Network Bitcoin Core 0.11 (Ch 4): P2P Network]
+
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_4):P2P_Network Bitcoin Core 0.11(Ch 4):P2Pネットワーク]
 
<br>
 
<br>
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Download Bitcoin Core 0.11 (Ch 5): Initial Block Download]
+
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_5):_Initial_Block_Down Bitcoin Core 0.11(Ch 5):初期ブロックダウンロード]
 
<br>
 
<br>
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_6):_The_Blockchain Bitcoin Core 0.11 (Ch 6): The Blockchain]
+
[https://en.bitcoin.it/wiki/Bitcoin_Core_0.11_(ch_6):_The_Blockchain Bitcoin Core 0.11(Ch 6):ブロックチェーン]
  
  
[[Category:Technical]]
+
[[Category:技術]]
[[Category:Developer]]
+
[[Category:開発者]]

2018年4月14日 (土) 16:44時点における最新版

このページでは、起動と初期化を管理するBitcoin Coreコードについて説明します。

プログラムエントリポイント[編集]

プログラムのエントリポイントは bitcoind.cpp にあります。

main()はコードの3行です:

  • SetupEnvironment()(これはプログラムのロケールを設定します)
  • 信号ハンドラを接続する
  • AppInit()(この関数はプログラムの寿命を延ばす)


AppInit:これは bitcoind.cpp の近くにあります。

  • コマンドラインを解析する
  • データディレクトリを開きます。
  • 設定ファイルを読み込みます
  • プロセスをフォークします(デーモンとして実行している場合)
  • コントロールを init.cpp にあるAppInit2()に渡します。


初期化ステップ( init.cpp [編集]

AppInit2()はビットコインシステムを初期化します。

これには約800行のコードが含まれており、12段階に分かれています。

各ステップが始まる場所は、コードに文書化されています。 Init.cpp にはファイルの先頭にいくつかの関数がありますが、大部分はAppInit2()で構成されています。

次の表は、手順をまとめたものです。

初期化
ステップ
簡単な説明 詳細
1 OS固有のセットアップタスク これらの作業は特に興味深いものではありません。
詳細は、コードを参照してください。
2 パラメータの相互作用 特定のコマンドラインオプションでは、特定の方法で他のオプションを設定する必要があります。
たとえば、-zapwallettxesは-rescanを意味します。したがって、コードは-rescanフラグ= trueを設定します(まだ存在していない場合)。
3 内部フラグ /
パラメータ健全性チェック
特定のパラメータのグローバル変数を設定します。
財布については、取引料金レベルを正当性をチェックします(あなたの手数料がリレー[エラー]の資格を得るのに十分高いが、不当に高い[警告]ではないことを確認します)。
4 アプリケーション初期化。 / RPCサーバー

データディレクトリをロックします。 (できない場合は、エラーを出力して終了してください。)
スクリプトチェックエンジン用のXスレッドを生成する。 (デフォルト= 0、使用可能なすべてのプロセッサを使用することを意味し、boost :: thread :: hardware_concurrency)。
"ウォームアップ"モードでRPCサーバーを起動します。

5 ウォレット・データベースの整合性の確認 ウォレットが有効になっている場合は、開こうとします。

ウォレットが破損していることがわかっている場合(-salvagewallet)、パスワードの回復を試みます。

6 ネットワーク初期化

ノードは特定の信号を登録する。
ユーザーが特定のネットワーク(ip4、ip6、tor)のピアとのみ対話したいかどうかを確認します。
オニオンルーティング(tor)を使用するかどうかをチェックします。
ユーザーが特定のピアをホワイトリストに登録するかどうかを確認します。
ビットコインポートでリスンしようとします(失敗時に終了します)。
ユーザーが接続をシードする特定のピアを指定した場合は、接続を試みます。

7 ブロックチェーンをロードします。

ブロックチェーンをメモリにロードし、UTXOキャッシュを初期化します。

キャッシュサイズを計算します。
3つの特定のキャッシュに分割された合計キャッシュサイズがあります。
デフォルトの合計キャッシュサイズ= 100MB(最大:4GB、最小:4MB)。
1)ブロックチェーンキャッシュ:合計キャッシュの1/8ですが、2MBを超えてはいけません。
2)UTXOデータベース・キャッシュ:残りのキャッシュ・スペースの25〜50%。 これはLevelDBキャッシュです。
これは、LevelDBデータの圧縮されていないブロックを格納し、LevelDBによって管理されます。the LevelDB documentation.
3)UTXOインメモリキャッシュ:残りのキャッシュスペースの半分。
このキャッシュサイズは、cacheCoinsオブジェクト(CoinsViewCacheの保護されたメンバー)のサイズを定義します。
TODO:このステートメントが正しいことを確認してください...

ブロックチェーンをmapBlockIndexにロードします。
「ブロックチェイン」とは、ブロックツリー全体(アクティブチェーン内のブロックだけでなく、すべての既知のブロック)を意味します。
メモリにロードされるのはブロックに関するメタデータを含むCBlockIndexオブジェクトです。
最後の288ブロック(VerifyDB)を検証します。
注意:プログラムはこの時点までに起動から1秒未満を要します。 このステップには約10〜20秒かかります。

UTXOセット。
UTXOセットはメモリにロードされません。 代わりに、コインがデータベースからアクセスされるときにキャッシュがいっぱいになります。
2015年5月現在、UTXOセット全体をメモリに格納するには約3.6 GBが必要です。
2016年1月現在、ディスク上の圧縮データは約1.2 GBです。

8 ウォレットをロードします。 プログラムが初めて実行された場合は、ウォレットが作成され、最初のキー(アドレス)が与えられます。
9 Datadirのメンテナンス ユーザーがブロックプルーニングを行っている場合は、NODE_NETWORKの設定を解除し、プルーニング機能を呼び出します。
10 インポートブロック 現在有効なチェーンとして接続されていないブロックチェーンデータベースのチェーンをスキャンします。
11 開始ノード /
RPCサーバー

net.cppでStartNodeを呼び出します。
これは、プログラムのメインスレッドであるThreadProcessMessageを含むネットワーキングスレッドグループを起動します(下記参照)。
RPCサーバーを "ウォームアップ"モードから通常モードに移行します。

12 終了


AppInit2が終了すると、 bitcoind.cpp のAppInit()に戻ります。

そこで、コードのトップレベルスレッドは、WaitForShutdown()という関数で無期限にループします。 2秒間スリープ状態になり、ユーザーがctrl-Cを押したかどうかを確認します。 その場合は、 init.cpp でShutdown()を呼び出します。

シャットダウン()は、RPCサーバーをシャットダウンし、ノードを停止し、シグナルハンドラの登録を解除し、プログラムが完了します。

キャッシュサイズ[編集]

ステップ7は、キャッシュサイズを初期化した。手順7で考えられる3つのキャッシュがあります.2つはLevelDBデータベースキャッシュであり、もう1つはコインキャッシュであり、そのサイズは main.cpp のフラッシュコードによって管理されます。

ユーザーは、-dbcacheを使用して合計キャッシュ・サイズを割り当てることができます。ユーザーは、特定の各キャッシュに割り当てるスペースを選択して選択することはできません。デフォルトの合計キャッシュサイズ= 100MB(最大:4GB、最小:4MB)。

'1)ブロックインデックスキャッシュ'

このキャッシュには、/ block / index LevelDBデータの圧縮されていないチャンクが保存され、LevelDBのドキュメントに記載されているように、LevelDBによって管理されます。 br>

ユーザーが完全なトランザクションインデックス(-txindex = 1)を有効にした場合、合計キャッシュサイズの1/8までになります。 -txindexが有効でない場合は、2 MiBだけが必要です。


'2)UTXOデータベースキャッシュ'

これは、/ chainstateデータベースのLevelDBキャッシュです。

このキャッシュは、合計キャッシュ・サイズに応じて、残りのキャッシュ・スペースの25〜50%に割り振られます。


'3)UTXOインメモリキャッシュ'

これは main.cpp コードで管理されるコインキャッシュです。 (FlushStateToDiskおよび関連する関数を参照)

変数(nCoinsCache)は、 main.h のexternとして宣言されています。 main.cpp には、5000 * 300にハードコードされています(メモリ内コインは約300バイトなので5000コインを意味します)。しかし、ステップ7で再初期​​化する必要があります。

このキャッシュには残りのキャッシュ領域がすべて与えられます。

このキャッシュは、初期化中にロードされるのではなく、コインがアクセスされるときに満たされます。 (これは、cachedCoinsUsage = 0を設定するCCoinsViewCacheコンストラクタによって検証できます)。

スレッド起動[編集]

このコードでは、boost :: thread_groupsを使用してさまざまなスレッドを管理しています。

Bitcoin Coreはマルチスレッドプログラムですが、 "参照Satoshiクライアントは主にシングルスレッドです"ということに注意してください。 BIP 31(2012)のMike Hearnによるコメント

つまり、プログラムの活動の大部分がメッセージングスレッド(ThreadMessageHandler - 以下を参照)で行われるということです。

ほとんどすべてのスレッドは、プログラムの起動時にスタック上に作成される単一のマスタースレッドグループの一部です( bitcoind.cpp を参照)。このスレッドグループはいくつかの子スレッドを生成する init.cpp に渡されます(いくつかのスクリプト検査スレッドを含みますが、これらはすべて別個のグループではなくマスタースレッドグループの一部です)。

スレッドグループは net.cpp に渡され、メッセージ処理スレッドを含むネットワーキングスレッドが作成されます。

2つの他のスレッドグループはタスク固有です。

  • rpcサーバースレッドグループ(<r> rpcserver.h / cpp </u>を参照)
  • minerスレッドグループ

当然のことながら、ノードはRPCサーバーがアクティブになっている場合にのみRPCサーバースレッドグループを作成し、マイナースレッドグループがマイニングの場合にのみ作成します。両方が無効の場合、Bitcoin Coreは単一のスレッドグループしか持たない。

'子スレッド'

親スレッド(プログラムが動作を開始するスレッドを意味する)は、ほとんどすべてのプログラムの作業を子スレッドに委譲します。 init.cpp net.cpp でスレッドを生成した後、親スレッドは単にシャットダウンコマンドを待ちます。スレッドグループを開き、シャットダウンを続行します。

子スレッドは、作成された順にリストされています。

スレッド いつ / どこで作成されました 説明
スクリプトチェック ステップ4
init.cpp
これはスレッドのセットで、デフォルトでは4です。
スクリプトチェック(署名チェックを含む)は高価なので、別のスレッドで処理されます。
スケジューラ ステップ4
init.cpp
スケジューラスレッド。
(TODO: describe)
RPCスレッド ステップ4
rpcserver.cpp
RPCサーバーが有効な場合は、RPC呼び出しを処理するスレッドのグループを開始します。
インポート ステップ10
init.cpp
ブロックをインポートします。 3つのシナリオ:
1)再インデックス(blk ??? datファイルからすべての既知のブロックを再スキャンする)。
2)ブートストラップ(bootstrap.datをネットワークからの完全なIBDの代わりに使用します)。
3)-loadblock(特定のblk ???。datファイルをスキャンする) - これらのどれも適用されない場合、このスレッドは何もしません。
DNSアドレスシード ステップ11
net.cpp
dnsシードに基づいてIPアドレスのベクトルを構築しようとし、ベクトルとスレッドを終了します。
2014年6月のテストでは、これには約4秒かかり、158のアドレスが見つかりました。
プラグ&プレイ ステップ11
net.cpp
UPNP(ユニバーサルプラグ&プレイ)
UPNPのポートマッピングを扱う。
SocketHandler ステップ11
net.cpp
このスレッドはソケットをサービスします:
関連するすべてのソケットのI / Oを50msのタイムアウトで待機します。
リスニングソケットで新しい着信接続を処理し、新しいピアのCNodeを作成します。
データストリームを受信して送信します。
何もしなかったソケットを切断状態に設定します。
OpenAddedConnections ステップ11
net.cpp
-addnodeパラメーターを使用して、ユーザーが指定したアウトバウンド接続を開始します。
接続できない場合、各サイクルで2分間スリープします。
OpenConnections ステップ11
net.cpp
DNSシードから他のアウトバウンド接続を開始する(失敗した場合、固定シードに基づいてノードを見つける)
接続できない場合、各サイクルで500ミリ秒間スリープします。
MessageHandler ステップ11
net.cpp
これがプログラムの主なスレッドです。
このスレッドはwhile(true)ループを実行し、メッセージの送受信を行います。 (参照 net.cpp:1049)
このコードでは、boost :: signals2を使用してmain.cppのProcessMessages関数とSendMessages関数を呼び出します。
(シグナルを導入するコードはPR 2154にあります - そのプルで最後から2番目のコミットを参照してください)。
ProcessMessageとSendMessageはこのスレッドで実行されます。
したがって、 main.cpp のコードのほとんどはこのスレッドで実行されます。
ウォレットフリュッシャー ステップ12
init.cpp
ウォレットが有効な場合、このスレッドは定期的にウォレットをフラッシュします。


関連項目[編集]

Core 0.11(Ch 1):概要
Bitcoin Core 0.11(Ch 2):データストレージ
Bitcoin Core 0.11(Ch 4):P2Pネットワーク
Bitcoin Core 0.11(Ch 5):初期ブロックダウンロード
Bitcoin Core 0.11(Ch 6):ブロックチェーン


Category:技術 Category:開発者