CIPs icon indicating copy to clipboard operation
CIPs copied to clipboard

Discussion: CIP-34

Open Thegaram opened this issue 4 years ago • 1 comments

Previous discussion: #34.

Thegaram avatar Nov 05 '20 09:11 Thegaram

The concern is that the uncommitted receipts are continuously updating since that header, whereas the receipts Merkle root up to that latest valid timer block (since the second last valid timer block) is already fixed. Hence by moving the receipts Merkle root one step later we can save the cost of updating the receipts Merkle tree.

Just to clarify, given a pivot chain like this:

 ---       ---       ---       ---       ---       ---
| A | <-- | B | <-- | C | <-- | D | <-- | E | <-- | F | <-- ...
 ---       ---       ---       ---       ---       ---
  ^                             ^
timer                         timer

... block headers would include a new reference to the latest known timer block:

+   .----------------------------
+   .-------------------         | .------------------
+   .---------          |        | .--------          |
+   v         |         |        | v        |         |
   ---       ---       ---       ---       ---       ---
  | A | <-- | B | <-- | C | <-- | D | <-- | E | <-- | F | <-- ...
   ---       ---       ---       ---       ---       ---
    ^                             ^
  timer                         timer

... and each header would also include the Merkle root of all receipts since the second latest timer block, up to (and including) the latest timer block.

-                       v-----------------------------
-                       *<------------------          |
-                      /|\                  |         |
-                 ----  |  ----             |         |
-               /       |       \           |         |
   ---       ---       ---       ---       ---       ---
  | A | <-- | B | <-- | C | <-- | D | <-- | E | <-- | F | <-- ...
   ---       ---       ---       ---       ---       ---
    ^                             ^
  timer                         timer

Moreover, these two new fields are only verified for pivot blocks and they are subject to blaming.

The size of Merkle proof mainly depends on the depth of receipt Merkle tree. Currently Conflux timer block has quality 180x of usual, i.e. the expected number of transactions (when fully used) during two timer blocks is 1.5k180=270k, and w.h.p. bounded by 1.5k(180±14) ≤ 291k. In comparison, every Bitcoin block contains up to ~4k transactions. Therefore, the depth of receipt Merkle tree is ~18.15 vs. ~12, only increased by 51.25%.

Yeah, that makes sense. So assuming we build an in-memory Merkle tree of receipt hashes, that would mean computing the root on about 9 MB of data once for every timer block, seems feasible, though the DB load seems to be significant.

Thegaram avatar Nov 05 '20 09:11 Thegaram

Closing due to inactivity. Feel free to comment if you'd like to continue the discussion. Thank you!

ChenxingLi avatar Oct 17 '23 10:10 ChenxingLi