CIP-34: Contract-friendly simple verification rules #34
Conversation
Update from Conflux-Chain
|
|
||
| The blocks with significant quality constitute a "slow chain" embedded in the tree-graph structure. More specifically, the timer chain blocks have quality 180 times of target quality, and hence the timer chain has expected block generation time ~90 seconds, which can be safely confirmed with Nakamoto consensus. Thus a Conflux SPV proof consisting of sufficiently many (say, seven or eight) chained timer blocks would be sufficient to provide confidence comparable to six-block confirmation in Bitcoin. | ||
|
|
||
| To implement efficient SPV proof with timer blocks, Conflux protocol should change in following two points: |
There was a problem hiding this comment.
So the change is basically adding two new fields in each header: the hash of the latest valid timer block, and a Merkle root of all receipts since that header, right?
One concern I have is the size of the receipts Merkle tree. While it can be optimized, the proof size still seems significantly larger than with BTC's SPV proofs.
There was a problem hiding this comment.
Two new fields: yes.
- hash reference of the latest valid timer block;
- a Merkle root of all receipts during two valid timer blocks, but not necessarily since that latest valid timer block.
- 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.
Regarding size of the SPV proof, it consists of block headers and a Merkle proof. The number of block headers would be comparable to BTC's SPV proof, i.e. 7~8 vs. 6, since the generation time of timer blocks is less than Bitcoin blocks (~90s vs. ~600s).
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%.
There was a problem hiding this comment.
Thanks for the explanation. I suggest we move the discussion to #36, feel free to merge this draft.
Abstract:
Enable verification of Conflux status with simple rules inside a smart contract (e.g. an Ethereum contract).
This change is