為什麼 CLN（Core Lightning）從 Genesis 同步，而 LND 只從錢包的生日同步？

我已經安裝了兩個主要的閃電網路實現，CLN（以前稱為 c-lightning）和LND，在同一台伺服器上使用 bitcoind 測試網作為後鏈。在第一次啟動時，我注意到 CLN 從區塊鏈的開頭同步所有塊：

2022-07-05T23:31:29.487Z DEBUG   lightningd: Still waiting for initial block download
2022-07-05T23:31:29.593Z DEBUG   lightningd: Adding block 1: 00000000b873e79784647a6c82962c70d228557d24a747ea4d1b8bbe878e1206
2022-07-05T23:31:29.647Z DEBUG   lightningd: Adding block 2: 000000006c02c8ea6e4ff69651f7fcde348fb9d557a06e6957b65552002a7820
2022-07-05T23:31:29.685Z DEBUG   lightningd: Adding block 3: 000000008b896e272758da5297bcd98fdc6d97c9b765ecec401e286dc1fdbe10
2022-07-05T23:31:29.732Z DEBUG   lightningd: Adding block 4: 000000008b5d0af9ffb1741e38b17b193bd12d7683401cecd2fd94f548b6e5dd
2022-07-05T23:31:29.752Z DEBUG   lightningd: Adding block 5: 00000000bc45ac875fbd34f43f7732789b6ec4e8b5974b4406664a75d43b21a1
2022-07-05T23:31:29.774Z DEBUG   lightningd: Adding block 6: 000000006633685edce4fa4d8f12d001781c6849837d1632c4e2dd6ff2090a7b
2022-07-05T23:31:29.792Z DEBUG   lightningd: Adding block 7: 00000000e29e3aa65f3d12440eac9081844c464aeba7c6e6121dfc8ac0c02ba6

而 LND 只掃描錢包生日之後的區塊：

2022-07-05 23:21:55.757 [INF] LTND: Waiting for chain backend to finish sync, start_height=2284292
2022-07-05 23:21:56.613 [DBG] LNWL: Chain backend synced to tip!
2022-07-05 23:21:56.614 [DBG] LNWL: Locating suitable block for birthday 2022-07-03 15:15:05 -0300 -03 between blocks 0-2284292
2022-07-05 23:21:56.617 [DBG] LNWL: Checking candidate block: height=1142146, hash=00000000000bee59e6acdb88deee299fcce4c8603a04a60b022d70f256b4d880, timestamp=2017-06-18 16:00:52 -0300 -03
2022-07-05 23:21:56.619 [DBG] LNWL: Checking candidate block: height=1713219, hash=000000000000905bf5e522da9cc5d30a93728feb51f3409396193f120505e2ca, timestamp=2020-04-14 06:51:58 -0300 -03
2022-07-05 23:21:56.621 [DBG] LNWL: Checking candidate block: height=1998755, hash=00000000000009aa098093884b3f352bfc1efa24ec2af3d541e2fa2ba7e54d6b, timestamp=2021-06-02 19:57:47 -0300 -03
2022-07-05 23:21:56.623 [DBG] LNWL: Checking candidate block: height=2141523, hash=00000000849bdb7b93b3deb7182cb1ec3dc2e470d4359ac6fe67d19e5bd5f84e, timestamp=2022-02-14 17:16:49 -0300 -03
2022-07-05 23:21:56.625 [DBG] LNWL: Checking candidate block: height=2212907, hash=00000000000004e43dbee8c2f5ae622bb6a984183ef07a8341b1eec6ce331ce5, timestamp=2022-04-28 00:06:02 -0300 -03
2022-07-05 23:21:56.627 [DBG] LNWL: Checking candidate block: height=2248599, hash=00000000000009c8763aaa3757774b8c8611495dd2f190672d1c4084d40368d6, timestamp=2022-05-26 08:36:29 -0300 -03
2022-07-05 23:21:56.629 [DBG] LNWL: Checking candidate block: height=2266445, hash=00000000000022f256ef974c1467221afc19f6c087ffb147554191d128099438, timestamp=2022-06-16 10:46:47 -0300 -03
2022-07-05 23:21:56.631 [DBG] LNWL: Checking candidate block: height=2275368, hash=0000000000000069a27c710313fc5a764e8bab5fed550af837d0c8b1d6fdd558, timestamp=2022-06-16 14:23:46 -0300 -03
2022-07-05 23:21:56.633 [DBG] LNWL: Checking candidate block: height=2279830, hash=00000000000001d54cbb97ed368723e4ae7681f6c3d625d517b9dbe3a7d0678a, timestamp=2022-06-18 00:41:09 -0300 -03
2022-07-05 23:21:56.635 [DBG] LNWL: Checking candidate block: height=2282061, hash=00000000000000b1517a474a0c8e32a9bd452bd1117cc2a799195991d10c3306, timestamp=2022-06-23 13:04:59 -0300 -03
2022-07-05 23:21:56.637 [DBG] LNWL: Checking candidate block: height=2283176, hash=00000000000000498bf2dbab757cba69b77a8d31ea437b2a377aabdb08c0d3cc, timestamp=2022-06-28 19:37:39 -0300 -03
2022-07-05 23:21:56.639 [DBG] LNWL: Checking candidate block: height=2283734, hash=000000000000003a55f287f3243841f215572c092995ccf286d9d92398d21785, timestamp=2022-07-02 14:50:17 -0300 -03
2022-07-05 23:21:56.641 [DBG] LNWL: Checking candidate block: height=2284013, hash=000000000000004f39aada91825e5d6121e6d7bcda6be504a6f2c13dac133df9, timestamp=2022-07-04 05:13:13 -0300 -03
2022-07-05 23:21:56.643 [DBG] LNWL: Checking candidate block: height=2283873, hash=000000003c07419de729aa383f639e506e24dc5f7e947f80cfaf5d2e67837c43, timestamp=2022-07-03 08:31:57 -0300 -03
2022-07-05 23:21:56.645 [DBG] LNWL: Checking candidate block: height=2283943, hash=0000000000000017b3b716a4e380900fbf2e114d2536a6f5e71427e5b10a34f8, timestamp=2022-07-03 17:57:30 -0300 -03
2022-07-05 23:21:56.647 [DBG] LNWL: Checking candidate block: height=2283908, hash=000000000000004aef1f2fc4dc6973f7c9ac67e5f6c69e1df089f92c83e91324, timestamp=2022-07-03 13:34:25 -0300 -03
2022-07-05 23:21:56.647 [DBG] LNWL: Found birthday block: height=2283908, hash=000000000000004aef1f2fc4dc6973f7c9ac67e5f6c69e1df089f92c83e91324, timestamp=2022-07-03 13:34:25 -0300 -03
2022-07-05 23:21:56.656 [INF] LNWL: Started rescan from block 000000000000004aef1f2fc4dc6973f7c9ac67e5f6c69e1df089f92c83e91324 (height 2283908) for 0 addresses
2022-07-05 23:21:56.687 [INF] LNWL: Catching up block hashes to height 2283919, this might take a while
2022-07-05 23:21:56.693 [INF] LNWL: Done catching up block hashes
2022-07-05 23:21:56.693 [INF] LNWL: Rescanned through block 0000000000000005cdcf62d03147fc812f5b01b21a919bdbe38a3588cafdd5f8 (height 2283919)
2022-07-05 23:21:59.062 [INF] LNWL: Catching up block hashes to height 2284292, this might take a while
2022-07-05 23:21:59.063 [INF] LNWL: Done catching up block hashes
2022-07-05 23:21:59.063 [INF] LNWL: Finished rescan for 0 addresses (synced to block 00000000eb61cbd41eaaa4c3646418dd1acf75d30b04239385b19c51fef43cec, height 2284292)
2022-07-05 23:21:59.785 [INF] LTND: Chain backend is fully synced (end_height=2284292)!

與 CLN 相比，這似乎在首次啟動時具有巨大優勢。截至目前，我的 CLN 節點已經花費了超過 14 個小時進行同步，而 LND 只需幾秒鐘即可工作。此外，據我了解，閃電節點應同步完整的 UTXO 集以驗證開放通道。但這應該由後鏈提供。

CLN 是否有充分的理由重新處理所有內容？另外，如果 LND 只從錢包的生日同步，它如何驗證渠道的資金交易？

提前致謝。

CLN 應該從接近目前區塊鏈高度開始，但是目前區塊鏈高度是從中學習的bitcoind，在您的情況下仍在同步。

通過大致同時開始，我們得到一個bitcoind報告目前高度非常接近於高度 0 的創世塊的高度。當詢問目前區塊鏈高度時，它會返回那個低值高度並假設它應該開始同步那個高度，導致整個區塊鏈被處理。lightningd``bitcoind``lightningd``bitcoind

有幾個解決方案：

1. 等待bitcoind完全同步（或幾乎完全同步，如果您對 CLN 處理更多塊沒問題），然後才啟動 CLN
2. 如果您在bitcoind同步之前啟動 CLN，您可以通過在其前面lightningd指定要同步的絕對高度來重置同步的高度-：lightningd --rescan=-600000 [other options]將區塊鏈高度重置為 600k，並lightningd應從該高度繼續掃描.
3. 使用替代後端，例如sauron或btcli4j，它們與資源管理器而不是本地對話，bitcoind用於超輕量級（但更受信任）比特幣後端。您稍後也可以在同步後切換到本地bitcoind。

如果有關於如何使其更加使用者友好的想法，我們願意接受建議。

免責聲明：我是 CLN 維護者之一。

對於錢包來說，要評估它控制了多少比特幣，它需要掃描區塊鏈以查找由錢包控制的 UTXO。

LND 使用一種稱為aezeed的錢包種子格式，它定義了錢包的生日（比特幣誕生以來的天數）。它從這個生日開始掃描區塊鏈，而不是從 Genesis 開始掃描相關的 UTXO，並假設它不控制在這個生日之前創建的任何 UTXO。

如果我在同一台伺服器上執行比特幣全節點，我不明白為什麼我應該同步我的閃電節點（為什麼不直接告訴 CLN/LND 塊在哪裡？）。

你的比特幣全節點從創世紀驗證區塊鏈。它對所有交易和所有有效且符合共識規則的區塊感興趣，而不僅僅是與錢包相關的 UTXO。一旦您的完整節點完成此操作，您的錢包就可以假設它正在掃描有效的區塊鏈。

引用自：https://bitcoin.stackexchange.com/questions/114366