{ "base_url": "https://talk.nervos.org", "generated_at": "2026-05-02T17:42:11.444835+00:00", "since": "2026-05-01T17:42:03.155930+00:00", "until": "2026-05-02T17:42:03.155930+00:00", "window_hours": 24, "topics": [ { "topic_id": 10224, "title": "CellScript 0.13 Preview: The Action Model and Syntax", "slug": "cellscript-0-13-preview-the-action-model-and-syntax", "url": "https://talk.nervos.org/t/cellscript-0-13-preview-the-action-model-and-syntax/10224", "created_at": "2026-05-01T15:34:27.229000+00:00", "last_posted_at": "2026-05-02T15:44:55.946000+00:00", "category_id": 49, "tags": [ "CKB-VM", "CellScript" ], "posters": [ "Original Poster, Most Recent Poster" ], "recent_posts": [ { "post_id": 24116, "post_number": 2, "topic_id": 10224, "topic_title": "CellScript 0.13 Preview: The Action Model and Syntax", "topic_slug": "cellscript-0-13-preview-the-action-model-and-syntax", "author": "ArthurZhang", "created_at": "2026-05-02T15:44:55.946000+00:00", "updated_at": "2026-05-02T15:46:52.903000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/cellscript-0-13-preview-the-action-model-and-syntax/10224/2", "content_text": "0.13.1 Patch Plan Preview\nLocal Ergonomics and Syntax Governance\n1. Background\nCellScript 0.13.0 set to be released next week will establish the new action model:\nA transaction proposes a Cell transformation.\nAn action verifies whether that transformation is allowed.\nIn this model, an action is not a method call, not an account-storage mutation, and not a runtime constructor. It is a typed verifier case: it names the input evidence, names the proposed output evidence, and proves the relationship between them. The 0.13 tutorial already frames this explicitly: signature direction describes transaction topology, where scopes proof obligations, move declares a state edge, require states verifier constraints, and create constrains proposed outputs.\n0.13.1 does not change this model.\nInstead, 0.13.1 introduces two local syntax improvements:\npreserve sugar\naggregated require block\nBoth are intentionally small, local, and mechanically expandable into existing 0.13 core syntax.\nThe goal is to reduce repetitive notation without hiding verifier obligations.\n2. Design Principle\n0.13.1 follows one rule:\nReduce ceremony, not safety visibility.\nA syntax addition is acceptable only if:\nits desugared form is obvious;\nall security-relevant fields or expressions remain visible at the action site;\nit does not introduce remote policy lookup;\nit does not behave like replace;\naudit tooling can expand it back into canonical 0.13 require statements.\nThis keeps 0.13.1 aligned with the 0.13 philosophy:\nThe action header says what changes.\nThe where block proves why it is allowed.\n3. Feature 1: preserve Sugar\n3.1 Motivation\nA common 0.13 pattern is explicit field preservation:\nrequire output.seller == input.seller\nrequire output.price == input.price\nrequire output.payment_symbol == input.payment_symbol\nThis is clear, but repetitive.\n0.13.1 introduces local field-preservation sugar:\npreserve output from input {\nseller\nprice\npayment_symbol\n}\nThis desugars exactly to:\nrequire output.seller == input.seller\nrequire output.price == input.price\nrequire output.payment_symbol == input.payment_symbol\n3.2 Canonical Example\n0.13.0:\naction fill(input: Offer, payment: Token, buyer: Address)\n-> (output: Offer, seller_payment: Token)\nmove input.state: Live -> output.state: Filled\nwhere\nrequire output.seller == input.seller\nrequire output.price == input.price\nrequire output.payment_symbol == input.payment_symbol\nrequire payment.amount == input.price\nrequire payment.symbol == input.payment_symbol\nrequire output.buyer == buyer\nconsume payment\ncreate seller_payment = Token {\namount: payment.amount,\nsymbol: payment.symbol\n} with_lock(input.seller)\n0.13.1:\naction fill(input: Offer, payment: Token, buyer: Address)\n-> (output: Offer, seller_payment: Token)\nmove input.state: Live -> output.state: Filled\nwhere\npreserve output from input {\nseller\nprice\npayment_symbol\n}\nrequire {\npayment.amount == input.price\npayment.symbol == input.payment_symbol\noutput.buyer == buyer\n}\nconsume payment\ncreate seller_payment = Token {\namount: payment.amount,\nsymbol: payment.symbol\n} with_lock(input.seller)\nThe second version is shorter, but still audit-visible.\nThe auditor still sees exactly which fields are preserved:\nseller\nprice\npayment_symbol\nNothing is hidden behind a reusable policy or opaque replacement primitive.\n3.3 Rules\npreserve is a local field-preservation shorthand.\nAllowed:\npreserve output from input {\nseller\nprice\npayment_symbol\n}\nNot allowed:\npreserve output from input\nNot allowed:\npreserve output from input {\n*\n}\nNot allowed:\npreserve output from input except {\nstate\n}\nReason\nCellScript should use whitelist preservation, not blacklist preservation.\nWhitelist preservation is safe because every preserved field is visible at the action site.\nBlacklist preservation is dangerous because newly added fields may be accidentally preserved or accidentally left unaudited.\n3.4 Scope\nIn 0.13.1, preserve applies only to resource data fields.\nIt does not preserve Cell metadata such as:\nlock\ntype\ncapacity\nThose remain explicit for now:\nrequire output.lock_hash == input.lock_hash\nrequire output.type_hash == input.type_hash\nrequire output.capacity == input.capacity\nFuture versions may consider standard-library helpers such as:\nstd::cell::same_lock(output, input)\nstd::cell::same_type(output, input)\nor later namespaced sugar, but these should not be part of 0.13.1 core.\n4. Feature 2: Anonymous require Block\n4.1 Motivation\nLong runs of require statements are common:\nrequire payment.amount == input.price\nrequire payment.symbol == input.payment_symbol\nrequire output.buyer == buyer\n0.13.1 allows grouping them:\nrequire {\npayment.amount == input.price\npayment.symbol == input.payment_symbol\noutput.buyer == buyer\n}\nThis desugars into independent atomic require statements:\nrequire payment.amount == input.price\nrequire payment.symbol == input.payment_symbol\nrequire output.buyer == buyer\n4.2 Rules\nA require block may contain only pure boolean expressions.\nAllowed:\nrequire {\npayment.amount == input.price\npayment.symbol == input.payment_symbol\n}\nNot allowed:\nrequire {\nlet x = payment.amount\nx == input.price\n}\nNot allowed:\nrequire {\nconsume payment\n}\nNot allowed:\nrequire {\nif payment.amount == input.price {\noutput.buyer == buyer\n}\n}\nReason\nA require block is not a nested proof language.\nIt is only grouping sugar.\n4.3 No Named Blocks in 0.13.1\n0.13.1 should not introduce named require blocks.\nDo not add:\nrequire payment_valid {\npayment.amount == input.price\npayment.symbol == input.payment_symbol\n}\nReason:\nnames can mislead;\nnames may imply semantic status;\nnames invite future reusable policy calls;\nreusable proof labels risk becoming user-defined replace.\nFor 0.13.1, keep it anonymous:\nrequire {\npayment.amount == input.price\npayment.symbol == input.payment_symbol\n}\nIf future tooling needs diagnostics labels, consider an annotation form later:\nrequire @payment_valid {\npayment.amount == input.price\npayment.symbol == input.payment_symbol\n}\nBut that should remain metadata, not semantics.\n5. Syntax Governance\n0.13.1 should also introduce a formal syntax-governance note.\nThe goal is to define which features belong in core syntax, which belong in local sugar, which belong in standard library, and which should be avoided.\n5.1 Layer 1: Core Verifier Syntax\nCore syntax is small, stable, and directly tied to the Cell verifier model.\nExamples:\naction input -> output\nwhere\nmove input.state: A -> output.state: B\nflow\nrequire expr\ncreate output = T { ... }\nconsume\ndestroy\nread / protected / witness / lock_args\nThese are the verifier calculus.\nThey should remain minimal and explicit.\n5.2 Layer 2: Local Explicit Sugar\nLocal sugar may enter the language if it keeps all safety facts visible.\n0.13.1 local sugar:\npreserve output from input {\nfield\nfield\n}\nand:\nrequire {\nexpr\nexpr\n}\nThese are acceptable because they remain local and expandable.\n5.3 Layer 3: Standard-Library Advanced Patterns\nMore advanced protocol concepts should not enter core syntax immediately.\nExamples:\nconserve\npreserve_lock\npreserve_type\npreserve_capacity\nclaim helpers\nsettle helpers\ntransfer helpers\ncapacity accounting helpers\nreceipt redemption helpers\nThese should first live in standard-library categories such as:\nstd::cell\nstd::accounting\nstd::receipt\nstd::lifecycle\nstd::ckb\nThis makes the user mental model clear:\ncore syntax = verifier calculus\nstdlib helper = typed sugar / audit pattern\nFor example:\nrequire std::cell::same_lock(output, input)\nrequire std::cell::same_type(output, input)\nrequire std::accounting::conserved(input.amount, [left.amount, right.amount])\nEvery advanced standard-library primitive should have a canonical expansion into core CellScript.\n5.4 Layer 4: Non-Core / Avoided Features\nThe following should remain outside 0.13.1:\ngeneral policy primitive\nnamed reusable require blocks\nreplace / replaces\npreserve all\npreserve except\nimplicit transfer magic\ngeneral settle magic\ncapacity conservation sugar\ncross-module proof policy imports\nReason:\nThese features can hide proof obligations, lengthen audit paths, or recreate the ambiguity that replace was removed to avoid.\n6. Desugaring Requirements\n0.13.1 should define canonical expansion rules.\n6.1 preserve\nSource:\npreserve output from input {\nseller\nprice\npayment_symbol\n}\nCanonical expansion:\nrequire output.seller == input.seller\nrequire output.price == input.price\nrequire output.payment_symbol == input.payment_symbol\n6.2 require Block\nSource:\nrequire {\npayment.amount == input.price\npayment.symbol == input.payment_symbol\n}\nCanonical expansion:\nrequire payment.amount == input.price\nrequire payment.symbol == input.payment_symbol\n7. Example: Updated 0.13.1 Style\nenum OfferState {\nCreated,\nLive,\nFilled,\nCancelled,\n}\nresource Offer has store {\nstate: OfferState\nseller: Address\nbuyer: Address\nprice: u64\npayment_symbol: [u8; 8]\n}\nresource Token has store, destroy {\namount: u64\nsymbol: [u8; 8]\n}\nflow Offer.state {\nCreated -> Live;\nLive -> Filled;\nLive -> Cancelled;\n}\naction fill(input: Offer, payment: Token, buyer: Address)\n-> (output: Offer, seller_payment: Token)\nmove input.state: Live -> output.state: Filled\nwhere\npreserve output from input {\nseller\nprice\npayment_symbol\n}\nrequire {\npayment.amount == input.price\npayment.symbol == input.payment_symbol\noutput.buyer == buyer\n}\nconsume payment\ncreate seller_payment = Token {\namount: payment.amount,\nsymbol: payment.symbol\n} with_lock(input.seller)\nThis keeps the 0.13 action model intact while improving readability.\nThe action still clearly shows:\ninput evidence\noutput proposal\nstate edge\nfield continuity\npayment validation\ninput fate\noutput construction\n9. Final Summary\nThat is the current plan for the 0.13.1 patch.\nThe intention is deliberately modest: keep the 0.13 action model explicit, add only local ergonomics where the desugared form is obvious, and keep higher-level protocol patterns out of core syntax until they have proved themselves in real examples.\nAs always, comments are very welcome, especially on the boundary between useful local sugar and abstractions that might make audits harder.\nI would be particularly interested in feedback on:\nwhether preserve output from input { ... } feels clear enough as field-preservation sugar;\nwhether anonymous require { ... } blocks improve readability without implying a new proof abstraction;\nwhether advanced primitives such as conserve, preserve_lock, claim, settle, or transfer are better kept in standard-library categories rather than core syntax.", "content_html": "

0.13.1 Patch Plan Preview

\n

Local Ergonomics and Syntax Governance

\n

1. Background

\n

CellScript 0.13.0 set to be released next week will establish the new action model:

\n
A transaction proposes a Cell transformation.\nAn action verifies whether that transformation is allowed.\n
\n

In this model, an action is not a method call, not an account-storage mutation, and not a runtime constructor. It is a typed verifier case: it names the input evidence, names the proposed output evidence, and proves the relationship between them. The 0.13 tutorial already frames this explicitly: signature direction describes transaction topology, where scopes proof obligations, move declares a state edge, require states verifier constraints, and create constrains proposed outputs.

\n

0.13.1 does not change this model.

\n

Instead, 0.13.1 introduces two local syntax improvements:

\n
    \n
  1. preserve sugar
    2. \n
  2. aggregated require block
    3. \n
\n

Both are intentionally small, local, and mechanically expandable into existing 0.13 core syntax.

\n

The goal is to reduce repetitive notation without hiding verifier obligations.

\n
\n

2. Design Principle

\n

0.13.1 follows one rule:

\n
\n

Reduce ceremony, not safety visibility.

\n
\n

A syntax addition is acceptable only if:

\n
    \n
  1. its desugared form is obvious;
    2. \n
  2. all security-relevant fields or expressions remain visible at the action site;
    3. \n
  3. it does not introduce remote policy lookup;
    4. \n
  4. it does not behave like replace;
    5. \n
  5. audit tooling can expand it back into canonical 0.13 require statements.
    6. \n
\n

This keeps 0.13.1 aligned with the 0.13 philosophy:

\n
The action header says what changes.\nThe where block proves why it is allowed.\n
\n
\n

3. Feature 1: preserve Sugar

\n

3.1 Motivation

\n

A common 0.13 pattern is explicit field preservation:

\n
require output.seller == input.seller\nrequire output.price == input.price\nrequire output.payment_symbol == input.payment_symbol\n
\n

This is clear, but repetitive.

\n

0.13.1 introduces local field-preservation sugar:

\n
preserve output from input {\n    seller\n    price\n    payment_symbol\n}\n
\n

This desugars exactly to:

\n
require output.seller == input.seller\nrequire output.price == input.price\nrequire output.payment_symbol == input.payment_symbol\n
\n
\n

3.2 Canonical Example

\n

0.13.0:

\n
action fill(input: Offer, payment: Token, buyer: Address)\n    -> (output: Offer, seller_payment: Token)\n    move input.state: Live -> output.state: Filled\nwhere\n    require output.seller == input.seller\n    require output.price == input.price\n    require output.payment_symbol == input.payment_symbol\n\n    require payment.amount == input.price\n    require payment.symbol == input.payment_symbol\n    require output.buyer == buyer\n\n    consume payment\n\n    create seller_payment = Token {\n        amount: payment.amount,\n        symbol: payment.symbol\n    } with_lock(input.seller)\n
\n

0.13.1:

\n
action fill(input: Offer, payment: Token, buyer: Address)\n    -> (output: Offer, seller_payment: Token)\n    move input.state: Live -> output.state: Filled\nwhere\n    preserve output from input {\n        seller\n        price\n        payment_symbol\n    }\n\n    require {\n        payment.amount == input.price\n        payment.symbol == input.payment_symbol\n        output.buyer == buyer\n    }\n\n    consume payment\n\n    create seller_payment = Token {\n        amount: payment.amount,\n        symbol: payment.symbol\n    } with_lock(input.seller)\n
\n

The second version is shorter, but still audit-visible.

\n

The auditor still sees exactly which fields are preserved:

\n
seller\nprice\npayment_symbol\n
\n

Nothing is hidden behind a reusable policy or opaque replacement primitive.

\n
\n

3.3 Rules

\n

preserve is a local field-preservation shorthand.

\n

Allowed:

\n
preserve output from input {\n    seller\n    price\n    payment_symbol\n}\n
\n

Not allowed:

\n
preserve output from input\n
\n

Not allowed:

\n
preserve output from input {\n    *\n}\n
\n

Not allowed:

\n
preserve output from input except {\n    state\n}\n
\n

Reason

\n

CellScript should use whitelist preservation, not blacklist preservation.

\n

Whitelist preservation is safe because every preserved field is visible at the action site.

\n

Blacklist preservation is dangerous because newly added fields may be accidentally preserved or accidentally left unaudited.

\n
\n

3.4 Scope

\n

In 0.13.1, preserve applies only to resource data fields.

\n

It does not preserve Cell metadata such as:

\n
lock\ntype\ncapacity\n
\n

Those remain explicit for now:

\n
require output.lock_hash == input.lock_hash\nrequire output.type_hash == input.type_hash\nrequire output.capacity == input.capacity\n
\n

Future versions may consider standard-library helpers such as:

\n
std::cell::same_lock(output, input)\nstd::cell::same_type(output, input)\n
\n

or later namespaced sugar, but these should not be part of 0.13.1 core.

\n
\n

4. Feature 2: Anonymous require Block

\n

4.1 Motivation

\n

Long runs of require statements are common:

\n
require payment.amount == input.price\nrequire payment.symbol == input.payment_symbol\nrequire output.buyer == buyer\n
\n

0.13.1 allows grouping them:

\n
require {\n    payment.amount == input.price\n    payment.symbol == input.payment_symbol\n    output.buyer == buyer\n}\n
\n

This desugars into independent atomic require statements:

\n
require payment.amount == input.price\nrequire payment.symbol == input.payment_symbol\nrequire output.buyer == buyer\n
\n
\n

4.2 Rules

\n

A require block may contain only pure boolean expressions.

\n

Allowed:

\n
require {\n    payment.amount == input.price\n    payment.symbol == input.payment_symbol\n}\n
\n

Not allowed:

\n
require {\n    let x = payment.amount\n    x == input.price\n}\n
\n

Not allowed:

\n
require {\n    consume payment\n}\n
\n

Not allowed:

\n
require {\n    if payment.amount == input.price {\n        output.buyer == buyer\n    }\n}\n
\n

Reason

\n

A require block is not a nested proof language.

\n

It is only grouping sugar.

\n
\n

4.3 No Named Blocks in 0.13.1

\n

0.13.1 should not introduce named require blocks.

\n

Do not add:

\n
require payment_valid {\n    payment.amount == input.price\n    payment.symbol == input.payment_symbol\n}\n
\n

Reason:

\n
    \n
  1. names can mislead;
    2. \n
  2. names may imply semantic status;
    3. \n
  3. names invite future reusable policy calls;
    4. \n
  4. reusable proof labels risk becoming user-defined replace.
    5. \n
\n

For 0.13.1, keep it anonymous:

\n
require {\n    payment.amount == input.price\n    payment.symbol == input.payment_symbol\n}\n
\n

If future tooling needs diagnostics labels, consider an annotation form later:

\n
require @payment_valid {\n    payment.amount == input.price\n    payment.symbol == input.payment_symbol\n}\n
\n

But that should remain metadata, not semantics.

\n
\n

5. Syntax Governance

\n

0.13.1 should also introduce a formal syntax-governance note.

\n

The goal is to define which features belong in core syntax, which belong in local sugar, which belong in standard library, and which should be avoided.

\n
\n

5.1 Layer 1: Core Verifier Syntax

\n

Core syntax is small, stable, and directly tied to the Cell verifier model.

\n

Examples:

\n
action input -> output\nwhere\nmove input.state: A -> output.state: B\nflow\nrequire expr\ncreate output = T { ... }\nconsume\ndestroy\nread / protected / witness / lock_args\n
\n

These are the verifier calculus.

\n

They should remain minimal and explicit.

\n
\n

5.2 Layer 2: Local Explicit Sugar

\n

Local sugar may enter the language if it keeps all safety facts visible.

\n

0.13.1 local sugar:

\n
preserve output from input {\n    field\n    field\n}\n
\n

and:

\n
require {\n    expr\n    expr\n}\n
\n

These are acceptable because they remain local and expandable.

\n
\n

5.3 Layer 3: Standard-Library Advanced Patterns

\n

More advanced protocol concepts should not enter core syntax immediately.

\n

Examples:

\n
conserve\npreserve_lock\npreserve_type\npreserve_capacity\nclaim helpers\nsettle helpers\ntransfer helpers\ncapacity accounting helpers\nreceipt redemption helpers\n
\n

These should first live in standard-library categories such as:

\n
std::cell\nstd::accounting\nstd::receipt\nstd::lifecycle\nstd::ckb\n
\n

This makes the user mental model clear:

\n
core syntax = verifier calculus\nstdlib helper = typed sugar / audit pattern\n
\n

For example:

\n
require std::cell::same_lock(output, input)\nrequire std::cell::same_type(output, input)\nrequire std::accounting::conserved(input.amount, [left.amount, right.amount])\n
\n

Every advanced standard-library primitive should have a canonical expansion into core CellScript.

\n
\n

5.4 Layer 4: Non-Core / Avoided Features

\n

The following should remain outside 0.13.1:

\n
general policy primitive\nnamed reusable require blocks\nreplace / replaces\npreserve all\npreserve except\nimplicit transfer magic\ngeneral settle magic\ncapacity conservation sugar\ncross-module proof policy imports\n
\n

Reason:

\n

These features can hide proof obligations, lengthen audit paths, or recreate the ambiguity that replace was removed to avoid.

\n
\n

6. Desugaring Requirements

\n

0.13.1 should define canonical expansion rules.

\n
\n

6.1 preserve

\n

Source:

\n
preserve output from input {\n    seller\n    price\n    payment_symbol\n}\n
\n

Canonical expansion:

\n
require output.seller == input.seller\nrequire output.price == input.price\nrequire output.payment_symbol == input.payment_symbol\n
\n
\n

6.2 require Block

\n

Source:

\n
require {\n    payment.amount == input.price\n    payment.symbol == input.payment_symbol\n}\n
\n

Canonical expansion:

\n
require payment.amount == input.price\nrequire payment.symbol == input.payment_symbol\n
\n
\n

7. Example: Updated 0.13.1 Style

\n
enum OfferState {\n    Created,\n    Live,\n    Filled,\n    Cancelled,\n}\n\nresource Offer has store {\n    state: OfferState\n    seller: Address\n    buyer: Address\n    price: u64\n    payment_symbol: [u8; 8]\n}\n\nresource Token has store, destroy {\n    amount: u64\n    symbol: [u8; 8]\n}\n\nflow Offer.state {\n    Created -> Live;\n    Live -> Filled;\n    Live -> Cancelled;\n}\n\naction fill(input: Offer, payment: Token, buyer: Address)\n    -> (output: Offer, seller_payment: Token)\n    move input.state: Live -> output.state: Filled\nwhere\n    preserve output from input {\n        seller\n        price\n        payment_symbol\n    }\n\n    require {\n        payment.amount == input.price\n        payment.symbol == input.payment_symbol\n        output.buyer == buyer\n    }\n\n    consume payment\n\n    create seller_payment = Token {\n        amount: payment.amount,\n        symbol: payment.symbol\n    } with_lock(input.seller)\n
\n

This keeps the 0.13 action model intact while improving readability.

\n

The action still clearly shows:

\n
input evidence\noutput proposal\nstate edge\nfield continuity\npayment validation\ninput fate\noutput construction\n
\n

9. Final Summary

\n

That is the current plan for the 0.13.1 patch.

\n

The intention is deliberately modest: keep the 0.13 action model explicit, add only local ergonomics where the desugared form is obvious, and keep higher-level protocol patterns out of core syntax until they have proved themselves in real examples.

\n

As always, comments are very welcome, especially on the boundary between useful local sugar and abstractions that might make audits harder.

\n

I would be particularly interested in feedback on:

\n", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10136, "title": "Building CKB PoP: a reusable participation primitive on CKB", "slug": "building-ckb-pop-a-reusable-participation-primitive-on-ckb", "url": "https://talk.nervos.org/t/building-ckb-pop-a-reusable-participation-primitive-on-ckb/10136", "created_at": "2026-03-29T14:53:12.991000+00:00", "last_posted_at": "2026-05-02T12:43:18.761000+00:00", "category_id": 32, "tags": [ "CKB", "NFT", "dapp" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24115, "post_number": 6, "topic_id": 10136, "topic_title": "Building CKB PoP: a reusable participation primitive on CKB", "topic_slug": "building-ckb-pop-a-reusable-participation-primitive-on-ckb", "author": "RobaireTH", "created_at": "2026-05-02T12:43:18.761000+00:00", "updated_at": "2026-05-02T12:43:18.761000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/building-ckb-pop-a-reusable-participation-primitive-on-ckb/10136/6", "content_text": "Over the last few days, I have completed a thorough investigation and fix for several critical bugs across the ckb-pop and ckb-pop-cli repositories. I tried to ensure protocol consistency and restore core functionality that was previously broken.\nKey Bug Fixes & Improvements\nConfirmed Bugs\nThe dob-badge on-chain contract expects 60-byte script args (including a unique 20-byte Type ID), but the CLI was only providing 40 bytes. This caused all CLI-initiated mints to fail.\nThe open-window command signed a window proof but never registered it with the backend. This meant HMACs generated by the CLI could never be verified by the backend when an attendee tried to claim a badge.\nThe frontend “Live QR” kiosk was using a naive CKB-PoP-QR message format that wasn’t supported by the backend, and it was displaying QR codes containing raw signatures instead of time-rotating HMACs.\nFixes\nUpdated badge args to 60 bytes to match the on-chain dob-badge contract requirements.\nUpdated the Browser Signer to automatically compute the truncated Type ID (blake2b hash of the first input) and inject it into the transaction before signing, ensuring the on-chain uniqueness constraint is met.\nAdded backend window registration to the open-window command.\nAligned the ckb-presence library with the backend’s CKB-PoP-Window message format\nRefactored LiveQrComponent to register the attendance window and poll the backend for standard rotating QR codes, ensuring web-hosted kiosks are fully compatible with the backend and attendee apps.\nUpdated the badgeExistsHint in the frontend to query the backend’s badge-holders endpoint. This provides a reliable check for existing badges, which is otherwise difficult via indexers due to the unique Type ID prefix in the script args.\nDiff: CKB PoP | CKB PoP CLI", "content_html": "

Over the last few days, I have completed a thorough investigation and fix for several critical bugs across the ckb-pop and ckb-pop-cli repositories. I tried to ensure protocol consistency and restore core functionality that was previously broken.

\n

Key Bug Fixes & Improvements

\n

Confirmed Bugs

\n
    \n
  1. \n

    The dob-badge on-chain contract expects 60-byte script args (including a unique 20-byte Type ID), but the CLI was only providing 40 bytes. This caused all CLI-initiated mints to fail.

    \n
    2. \n
  2. \n

    The open-window command signed a window proof but never registered it with the backend. This meant HMACs generated by the CLI could never be verified by the backend when an attendee tried to claim a badge.

    \n
    3. \n
  3. \n

    The frontend “Live QR” kiosk was using a naive CKB-PoP-QR message format that wasn’t supported by the backend, and it was displaying QR codes containing raw signatures instead of time-rotating HMACs.

    \n
    4. \n
\n

Fixes

\n
    \n
  1. Updated badge args to 60 bytes to match the on-chain dob-badge contract requirements.
    2. \n
  2. Updated the Browser Signer to automatically compute the truncated Type ID (blake2b hash of the first input) and inject it into the transaction before signing, ensuring the on-chain uniqueness constraint is met.
    3. \n
  3. Added backend window registration to the open-window command.
    4. \n
  4. Aligned the ckb-presence library with the backend’s CKB-PoP-Window message format
    5. \n
  5. Refactored LiveQrComponent to register the attendance window and poll the backend for standard rotating QR codes, ensuring web-hosted kiosks are fully compatible with the backend and attendee apps.
    6. \n
  6. Updated the badgeExistsHint in the frontend to query the backend’s badge-holders endpoint. This provides a reliable check for existing badges, which is otherwise difficult via indexers due to the unique Type ID prefix in the script args.
    7. \n
\n

Diff: CKB PoP | CKB PoP CLI

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10226, "title": "Multi-Model Allocation Guide for Complex Tasks", "slug": "multi-model-allocation-guide-for-complex-tasks", "url": "https://talk.nervos.org/t/multi-model-allocation-guide-for-complex-tasks/10226", "created_at": "2026-05-02T05:44:50.813000+00:00", "last_posted_at": "2026-05-02T12:34:46.323000+00:00", "category_id": 31, "tags": [ "AI" ], "posters": [ "Original Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24111, "post_number": 1, "topic_id": 10226, "topic_title": "Multi-Model Allocation Guide for Complex Tasks", "topic_slug": "multi-model-allocation-guide-for-complex-tasks", "author": "zz_tovarishch", "created_at": "2026-05-02T05:44:50.862000+00:00", "updated_at": "2026-05-02T05:44:50.862000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/multi-model-allocation-guide-for-complex-tasks/10226/1", "content_text": "For routing complex tasks across multiple AI models, I noticed that benchmark-based allocation (HLE, GPQA, IFBench, etc.) only explains part of the story. Each model defaults to a distinct cognitive register when handed the same task. Therefore, have this guide.\nClaude Opus 4.7 is the lead and coordinator. Highest non-hallucination rate and 1M context. Methodology judgment, long-document reading, integration, final draft.\nCodex (GPT-5.5) is the hard-reasoning specialist. Highest raw reasoning scores, most surgical precision in rewrites and cross-section consistency. Never let it independently produce factual claims.\nGemini 3.1 Pro is the knowledge anchor. Highest Omniscience and IFBench. Default first-stop for knowledge queries, figure extraction, plus reviewer-mind sniff tests.\nKimi K2.6 is the interactive ping-pong specialist with Sinophone audit. About 1 second first-chunk latency. Principle-and-category thinking, non-Western prior-work coverage.\nSent the guide to your main AI, then it dispatches all three external models in parallel, then has the lead integrate by using Kimi’s principle to structure the rewrite, Codex’s phrasing for the actual text, and Gemini’s heuristic for the final sniff test. Hard stop-doing rules cover the failure modes (Codex hallucinations, Gemini style-drift, Kimi context truncation, Claude format-drift).", "content_html": "

For routing complex tasks across multiple AI models, I noticed that benchmark-based allocation (HLE, GPQA, IFBench, etc.) only explains part of the story. Each model defaults to a distinct cognitive register when handed the same task. Therefore, have this guide.

\n

Claude Opus 4.7 is the lead and coordinator. Highest non-hallucination rate and 1M context. Methodology judgment, long-document reading, integration, final draft.

\n

Codex (GPT-5.5) is the hard-reasoning specialist. Highest raw reasoning scores, most surgical precision in rewrites and cross-section consistency. Never let it independently produce factual claims.

\n

Gemini 3.1 Pro is the knowledge anchor. Highest Omniscience and IFBench. Default first-stop for knowledge queries, figure extraction, plus reviewer-mind sniff tests.

\n

Kimi K2.6 is the interactive ping-pong specialist with Sinophone audit. About 1 second first-chunk latency. Principle-and-category thinking, non-Western prior-work coverage.

\n

Sent the guide to your main AI, then it dispatches all three external models in parallel, then has the lead integrate by using Kimi’s principle to structure the rewrite, Codex’s phrasing for the actual text, and Gemini’s heuristic for the final sniff test. Hard stop-doing rules cover the failure modes (Codex hallucinations, Gemini style-drift, Kimi context truncation, Claude format-drift).

", "like_count": 0, "quote_count": 0 }, { "post_id": 24114, "post_number": 2, "topic_id": 10226, "topic_title": "Multi-Model Allocation Guide for Complex Tasks", "topic_slug": "multi-model-allocation-guide-for-complex-tasks", "author": "ArthurZhang", "created_at": "2026-05-02T12:34:46.323000+00:00", "updated_at": "2026-05-02T12:35:14.666000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/multi-model-allocation-guide-for-complex-tasks/10226/2", "content_text": "Nice sum-up.\nOne model I would also add to this routing map is GLM 5.1, especially for code review and engineering-risk audit.", "content_html": "

Nice sum-up.
\nOne model I would also add to this routing map is GLM 5.1, especially for code review and engineering-risk audit.

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10008, "title": "Spark Program | Ckb-probe: Deep Observability Tool for CKB Nodes Based on Aya Kernel eBPF/ckb-probe：基于 Aya 内核 eBPF 的 CKB 节点深度可观测性工具", "slug": "spark-program-ckb-probe-deep-observability-tool-for-ckb-nodes-based-on-aya-kernel-ebpf-ckb-probe-aya-ebpf-ckb", "url": "https://talk.nervos.org/t/spark-program-ckb-probe-deep-observability-tool-for-ckb-nodes-based-on-aya-kernel-ebpf-ckb-probe-aya-ebpf-ckb/10008", "created_at": "2026-02-26T07:25:51.446000+00:00", "last_posted_at": "2026-05-02T08:19:48.293000+00:00", "category_id": 49, "tags": [ "In-Progress", "Spark-Program" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24112, "post_number": 51, "topic_id": 10008, "topic_title": "Spark Program | Ckb-probe: Deep Observability Tool for CKB Nodes Based on Aya Kernel eBPF/ckb-probe：基于 Aya 内核 eBPF 的 CKB 节点深度可观测性工具", "topic_slug": "spark-program-ckb-probe-deep-observability-tool-for-ckb-nodes-based-on-aya-kernel-ebpf-ckb-probe-aya-ebpf-ckb", "author": "clair", "created_at": "2026-05-02T08:17:46.141000+00:00", "updated_at": "2026-05-02T08:17:46.141000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-ckb-probe-deep-observability-tool-for-ckb-nodes-based-on-aya-kernel-ebpf-ckb-probe-aya-ebpf-ckb/10008/51", "content_text": "CKB-Probe 演示流程说明\n范围：仅限 CKB 测试网\n本文档覆盖 ckb-probe 的五个核心演示步骤，每步附完整终端输出、关键命令说明和输出解读。\n所有输出均为真实运行数据（2026-05-02，CKB v0.204.0 测试网节点）。\n调整说明\n本文档替代原计划的演示视频。文字报告在以下方面对评审者更为友好：\n评审者可以直接复制报告中的命令进行复现，不需要反复拖动视频进度条\n终端输出配合文字解读比视频旁白更容易精确定位到具体的输出字段和数值\n报告本身可以作为项目文档的一部分长期保留，便于后续版本更新时同步修改\n视频一旦录制后修改成本较高，而文档可以随项目迭代\n前置条件\n# 系统要求\n# - Linux 内核 >= 5.8 (BTF 支持)\n# - root 权限 (eBPF 需要 CAP_BPF + CAP_SYS_ADMIN)\n# - CKB 测试网节点运行中\n# Docker 方式运行 (推荐)\ndocker run --rm --privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /path/to/ckb-testnet:/data \\\n-v /path/to/ckb:/usr/local/bin/ckb:ro \\\nckb-probe:latest \n# 或者直接在宿主机运行 (需要 root)\nsudo ckb-probe \n步骤 1: 环境检查与 eBPF 验证\n目的： 验证 eBPF 环境就绪、CKB 二进制可探测、所有 uprobe/kprobe/tracepoint 可挂载。\n命令：\nsudo ckb-probe check --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb)\n完整终端输出：\n╔══════════════════════════════════════════════════════════════╗\n║ ckb-probe environment check ║\n╠══════════════════════════════════════════════════════════════╣\n✅ Kernel version 6.8.0-106-generic (need >= 5.8)\n✅ BPF config BPF=y SYSCALL=y JIT=y\n✅ BTF support /sys/kernel/btf/vmlinux exists\n✅ Permissions running as root\n✅ bpf() syscall available\n✅ uprobe support /sys/kernel/debug/tracing/uprobe_events exists\n✅ CKB process 1 instance(s), pid=2349824\n✅ CKB symbols 2/3 key symbols found (symtab)\n╚══════════════════════════════════════════════════════════════╝\nResult: 8/8 checks passed\n🎉 All checks passed!\n╔═════���════════════════════════════════════════════════════════╗\n║ ckb-probe eBPF validation ║\n╠══════════════════════════════════════════════════════════════╣\n✅ ── uprobe latency ── entry/return pair attach test\n✅ rocksdb_get_pinned_cf entry + return attached\n✅ rocksdb_put entry + return attached\n✅ rocksdb_write entry + return attached\n❌ rocksdb_delete symbol not in binary (expected)\n✅ rocksdb_create_iterator_cf entry + return attached\n❌ rocksdb_multi_get_cf symbol not in binary (expected)\n✅ ── uprobe Tier 1 ── all 19 Tier 1 symbol attach test\n✅ rocksdb_get symbol found, uprobe-attachable\n✅ rocksdb_get_pinned symbol found, uprobe-attachable\n✅ rocksdb_get_pinned_cf symbol found, uprobe-attachable\n✅ rocksdb_put symbol found, uprobe-attachable\n✅ rocksdb_put_cf symbol found, uprobe-attachable\n✅ rocksdb_write symbol found, uprobe-attachable\n❌ rocksdb_delete not found in binary\n❌ rocksdb_delete_cf not found in binary\n❌ rocksdb_multi_get_cf not found in binary\n✅ rocksdb_transaction_put_cf symbol found, uprobe-attachable\n✅ rocksdb_transaction_delete_cf symbol found, uprobe-attachable\n❌ rocksdb_transaction_get_cf not found in binary\n✅ rocksdb_transaction_commit symbol found, uprobe-attachable\n✅ rocksdb_optimistictransaction_begin symbol found, uprobe-attachable\n✅ rocksdb_create_iterator_cf symbol found, uprobe-attachable\n✅ rocksdb_iter_seek symbol found, uprobe-attachable\n✅ rocksdb_iter_seek_to_first symbol found, uprobe-attachable\n✅ rocksdb_iter_next symbol found, uprobe-attachable\n✅ rocksdb_iter_destroy symbol found, uprobe-attachable\n✅ uprobe summary latency pairs: 4/6, Tier 1 symbols: 15/19\n✅ kprobe tcp_sendmsg_entry attached to tcp_sendmsg\n✅ kprobe tcp_sendmsg_return attached to tcp_sendmsg\n✅ kprobe tcp_recvmsg_entry attached to tcp_recvmsg\n✅ kprobe tcp_recvmsg_return attached to tcp_recvmsg\n✅ tracepoint sys_enter attached to raw_syscalls/sys_enter\n╚══════════════════════════════════════════════════════════════╝\nResult: 27/33 checks passed\n⏳ Collecting live events for 3 seconds...\n[syscall] pid=2349824 tid=808096 nr=232 (epoll_wait)\n[uprobe] pid=2349824 tid=2351140 func=get_pinned_cf latency=45.2μs\n[uprobe] pid=2349824 tid=2351140 func=get_pinned_cf latency=14.5μs\n[uprobe] pid=2349824 tid=2351140 func=get_pinned_cf latency=5.3μs\n[uprobe] pid=2349824 tid=2351140 func=get_pinned_cf latency=6.0μs\n[uprobe] pid=2349824 tid=2351140 func=get_pinned_cf latency=4.5μs\n[tcp] pid=2349824 tid=740351 dir=RX bytes=705\n[tcp] pid=2349824 tid=808096 dir=TX bytes=705\n📊 Captured 264 uprobe, 40 tcp, 438 syscall events in 3s\n解读：\n环境检查 8/8 全部通过：内核 6.8.0 满足 >= 5.8 要求，BTF 可用，root 权限，bpf() 系统调用可用\neBPF 验证 27/33 通过：4 个 uprobe 延迟对（GET/PUT/WRITE/ITER）成功挂载，15/19 个 Tier 1 符号可用，4 个未找到的符号（delete/multi_get/transaction_get_cf）是 CKB 未使用的 RocksDB API，属于预期缺失\nkprobe/tracepoint 全部成功：tcp_sendmsg/tcp_recvmsg 网络探针 + raw_syscalls 系统调用追踪\n实时事件采集验证：3 秒内捕获 264 个 uprobe 事件 + 40 个 TCP 事件 + 438 个 syscall 事件，证明数据通道正常\n步骤 2: 符号分析\n目的： 全面分析 CKB 二进制中的 RocksDB 符号，评估 uprobe 覆盖率。\n命令：\nckb-probe symbols /root/ckb-testnet/ckb\n完整终端输出：\n════════════════════════════════════════════════════════════════════\nCKB Binary Symbol Analysis Report\nBinary: /root/ckb-testnet/ckb (65.0 MB)\nFormat: ELF 64-bit x86_64\n════════════════════════════════════════════════════════════════════\n── ELF Overview ────────────────────────────────────────\n.symtab: ✅ Present (153057 symbols)\n.dynsym: ✅ Present (511 symbols)\nDWARF: ❌ Not found\nStrip status: debuginfo-stripped (.symtab retained)\n── RocksDB Linkage ─────────────────────────────────────\nMethod: Static (bundled into CKB binary)\nEvidence: No librocksdb.so in dynamic deps; 155 rocksdb_* in .symtab\nAssessment: ✅ Ideal — C API symbols embedded in binary\n── Dynamic Dependencies ────────────────────────────────\nlibstdc++.so.6 libgcc_s.so.1 libm.so.6\nlibc.so.6 ld-linux-x86-64.so.2\n── [Tier 1] Directly uprobe-attachable (extern \"C\", stable) ──\n✅ rocksdb_get 0x021e3330 (318 B)\n✅ rocksdb_get_cf 0x021e34a0 (215 B)\n✅ rocksdb_get_pinned 0x021e4b20 (427 B)\n✅ rocksdb_get_pinned_cf 0x021e4d00 (379 B)\n✅ rocksdb_put 0x021e30a0 (105 B)\n✅ rocksdb_put_cf 0x021e3120 (240 B)\n✅ rocksdb_write 0x021e3230 (208 B)\n✅ rocksdb_transaction_put_cf 0x021e4770 (113 B)\n✅ rocksdb_transaction_delete_cf 0x021e4800 (101 B)\n✅ rocksdb_transaction_commit 0x021e42f0 (71 B)\n✅ rocksdb_optimistictransaction_begin 0x021e4a50 (99 B)\n✅ rocksdb_create_iterator_cf 0x021e3670 (167 B)\n✅ rocksdb_iter_seek 0x021e3b30 (30 B)\n✅ rocksdb_iter_seek_to_first 0x021e3b10 (9 B)\n✅ rocksdb_iter_next 0x021e3b70 (9 B)\n✅ rocksdb_iter_destroy 0x021e3ae0 (32 B)\n→ 16 / 20 tracked targets found\n── [Tier 2] Possibly available (Rust mangled, version-bound) ──\n⚠️ ckb_network::network::NetworkService::start\n⚠️ ckb_sync::synchronizer::block_process::BlockProcess::execute\n⚠️ ckb_sync::synchronizer::headers_process::HeadersProcess::execute\n⚠️ ckb_chain::chain_controller::ChainController::asynchronous_process_remote_block\n⚠️ ckb_store::transaction::StoreTransaction::attach_block\n⚠️ ckb_store::transaction::StoreTransaction::insert_block\n⚠️ ckb_store::transaction::StoreTransaction::commit\n⚠️ ckb_db::db::RocksDB::get_pinned\n⚠️ ckb_db::db::RocksDB::get_pinned_default\n... (11 / 21 tracked targets found)\n── [Tier 3] Unavailable (inlined / stripped / crate-internal) ──\n❌ ckb_network::protocols::CKBHandler::received — not found (likely inlined)\n❌ ckb_chain::chain_service::ChainService::process_block — not found (likely inlined)\n❌ ckb_store::db::ChainDB::get_block — not found (likely inlined)\n... (19 tracked functions not found)\n── Summary ─────────────────────────────────────────────\nTier 1: 16 / 20 ( 80%) partial coverage ⚠️\nTier 2: 11 / 21 ( 52%) available in this binary\nTier 3: 19 tracked functions not found\nTotal function symbols: 86852\nTotal RocksDB C API symbols: 155\n════════════════════════════════════════════════════════════════════\n解读：\nTier 1 (C API) — 16/20 找到（80%），这些是 extern \"C\" 符号，跨 CKB 版本稳定，是 ckb-probe 的核心探测点\nRocksDB 静态链接 — 155 个 rocksdb_* 符号直接嵌入 CKB 二进制，无需额外的 .so 文件\nTier 2 (Rust mangled) — 11/21 找到，这些 Rust 函数名含编译哈希，不同版本可能变化\nTier 3 (inlined) — 19 个预期缺失，因为编译器内联优化消除了这些函数入口\n步骤 3: 正常同步期间的实时 RocksDB 监控\n目的： 在 CKB 测试网节点正常运行期间，实时展示五类 RocksDB 操作的延迟、吞吐和延迟分布。\n3a. 统计表格模式\n命令：\nsudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) --interval 5\n终端输出：\n╭───────────────── CKB RocksDB Monitor (PID: 2349824) ─────────────────╮\n│ Uptime: 00:00:05 Sampling: 5s Node: CKB v0.204.0 │\n├────────────┬───────┬──────────┬──────────┬──────────┬────────────────┤\n│ Operation │ QPS │ Avg(μs) │ P50(μs) │ P99(μs) │ Bytes/s │\n├────────────┼───────┼──────────┼──────────┼──────────┼────────────────┤\n│ GET │ 93 │ 23.8 │ 6.1 │ 196.6 │ 5.5 KB/s │\n│ PUT │ 8 │ 6.7 │ 6.1 │ 24.6 │ 624 B/s │\n│ WRITE │ 0 │ 43.1 │ 49.2 │ 49.2 │ — │\n│ ITER_NEW │ 1 │ 38.6 │ 49.2 │ 98.3 │ — │\n│ TXN_COMMIT │ 1 │ 326.7 │ 393.2 │ 393.2 │ 624 B/s │\n╰────────────┴───────┴──────────┴──────────┴──────────┴────────────────╯\nStatus: ⏳ Warming up — Collecting baseline (295s remaining).\n╭───────────────── CKB RocksDB Monitor (PID: 2349824) ─────────────────╮\n│ Uptime: 00:00:10 Sampling: 5s Node: CKB v0.204.0 │\n├────────────┬───────┬──────────┬──────────┬──────────┬────────────────┤\n│ Operation │ QPS │ Avg(μs) │ P50(μs) │ P99(μs) │ Bytes/s │\n├────────────┼───────┼──────────┼──────────┼──────────┼────────────────┤\n│ GET │ 177 │ 411.6 │ 12.3 │ 12582.9 │ 21.5 KB/s │\n│ PUT │ 0 │ 0.0 │ 0.0 │ 0.0 │ 0 B/s │\n│ WRITE │ 0 │ 0.0 │ 0.0 │ 0.0 │ — │\n│ ITER_NEW │ 0 │ 0.0 │ 0.0 │ 0.0 │ — │\n│ TXN_COMMIT │ 0 │ 0.0 │ 0.0 │ 0.0 │ 0 B/s │\n╰────────────┴───────┴──────────┴──────────┴──────────┴────────────────╯\nStatus: ⏳ Warming up — Collecting baseline (290s remaining).\n3b. 延迟分布直方图模式\n命令：\nsudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) --histogram --interval 5\n终端输出（表格下方附加直方图）：\nGET latency distribution:\n2μs │████ 22\n4μs │████████████████████████████████████████ 369\n8μs │███████████████████ 182\n16μs │██████████████████ 213\n32μs │██████████ 46\n65μs │██ 6\nPUT latency distribution:\n2μs │██████ 3\n4μs │████████████████████████████████████████ 10\n8μs │████ 2\n16μs │██████ 3\n32μs │██ 1\nWRITE latency distribution:\n32μs │████████████████████████████████████████ 1\nITER_NEW latency distribution:\n16μs │████████████████████████████████████████ 2\n32μs │████████████████████████████████████████ 2\nTXN_COMMIT latency distribution:\n65μs │████████████████████ 1\n262μs │████████████████████████████████████████ 2\n解读：\nGET 呈长尾分布：主体在 2~32us（缓存命中），少量尾部延迟由磁盘 I/O 引起\nPUT 集中在 4~16us，单次写入非常轻量\nTXN_COMMIT 在 65~262us 区间，反映 WAL 写入开销\n直方图数据来自 eBPF 内核态 per-CPU 计数器，零采样开销\n步骤 4: 慢操作捕获\n目的： 实时捕获超过阈值的 RocksDB 操作，展示每个慢操作的精确延迟、数据大小和 BPF 事件丢失率。\n命令：\nsudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) \\\n--slow --threshold 1000 --interval 5\n终端输出：\n╭───────────────── Slow Operations (threshold: 1000μs) ──────────────────╮\n│ Timestamp │ Op │ Latency │ Size │ Note │\n├───────────────┼────────────┼───────────┼──────────┼────────────────────┤\n│ 57:21.976 │ GET │ 8,162μs │ 125 B │ │\n│ 57:21.986 │ GET │ 9,389μs │ 240 B │ │\n│ 57:21.992 │ GET │ 5,346μs │ 125 B │ │\n│ 57:21.998 │ GET │ 6,167μs │ 8 B │ │\n│ 57:22.004 │ GET │ 5,484μs │ 173 B │ │\n│ 57:22.007 │ GET │ 3,084μs │ 8 B │ │\n╰───────────────┴────────────┴───────────┴──────────┴────────────────────╯\nShowing 8 of 13 slow operations in last 5s.\nBPF event loss: 0 / 13 attempted (0.0000%)\n╭───────────────── Slow Operations (threshold: 1000μs) ──────────────────╮\n│ Timestamp │ Op │ Latency │ Size │ Note │\n├───────────────┼────────────┼───────────┼──────────┼────────────────────┤\n│ 57:29.099 │ GET │ 7,207μs │ 8 B │ │\n│ 57:29.104 │ GET │ 5,223μs │ 32 B │ │\n│ 57:29.107 │ GET │ 2,432μs │ 240 B │ │\n│ 57:29.115 │ GET │ 8,238μs │ 101 B │ │\n│ 57:29.127 │ GET │ 11,631μs │ 32 B │ │\n│ 57:29.130 │ GET │ 3,230μs │ 240 B │ │\n│ 57:29.134 │ GET │ 4,002μs │ 101 B │ │\n│ 57:29.137 │ GET │ 2,946μs │ 8 B │ │\n╰───────────────┴────────────┴───────────┴──────────┴────────────────────╯\nShowing 8 of 32 slow operations in last 10s.\nBPF event loss: 0 / 32 attempted (0.0000%)\n解读：\n仅超过 1000us (1ms) 的操作被捕获，常态下对系统零开销\n慢操作全部为 GET，延迟在 2~11ms，由 RocksDB block cache miss 触发磁盘读取导致\nBPF event loss: 0 / 32 (0.0000%) — RingBuf 数据通道零丢失\nSize 列显示该操作读写的数据大小（8B = key, 32~240B = value）\n步骤 5: JSON 导出\n目的： 展示机器可读的 JSON 输出格式，适合下游监控管线和数据分析。\n5a. 标准 JSON 输出\n命令：\nsudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) \\\n--json --interval 5\n终端输出（单个采样周期）：\n{\n\"anomalies\": [],\n\"operations\": {\n\"GET\": {\n\"avg_us\": 19.71,\n\"bytes_per_sec\": 1673,\n\"p50_us\": 12.29,\n\"p99_us\": 98.3,\n\"qps\": 22\n},\n\"ITER_NEW\": {\n\"avg_us\": 0.0,\n\"bytes_per_sec\": null,\n\"p50_us\": 0.0,\n\"p99_us\": 0.0,\n\"qps\": 0\n},\n\"PUT\": {\n\"avg_us\": 0.0,\n\"bytes_per_sec\": 0,\n\"p50_us\": 0.0,\n\"p99_us\": 0.0,\n\"qps\": 0\n},\n\"TXN_COMMIT\": {\n\"avg_us\": 0.0,\n\"bytes_per_sec\": 0,\n\"p50_us\": 0.0,\n\"p99_us\": 0.0,\n\"qps\": 0\n},\n\"WRITE\": {\n\"avg_us\": 0.0,\n\"bytes_per_sec\": null,\n\"p50_us\": 0.0,\n\"p99_us\": 0.0,\n\"qps\": 0\n}\n},\n\"pid\": 2349824,\n\"timestamp\": \"2026-05-02T07:31:41Z\",\n\"uptime_secs\": 0\n}\n5b. JSON + 直方图融合输出\n命令：\nsudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) \\\n--json --histogram --interval 5\n终端输出（单个采样周期，含 histogram 字段）：\n{\n\"anomalies\": [],\n\"operations\": {\n\"GET\": {\n\"avg_us\": 244.69,\n\"bytes_per_sec\": 11803,\n\"histogram\": [\n{ \"count\": 25, \"ge_us\": 4.1 },\n{ \"count\": 5, \"ge_us\": 8.19 },\n{ \"count\": 6, \"ge_us\": 16.38 }\n],\n\"p50_us\": 12.29,\n\"p99_us\": 12582.91,\n\"qps\": 116\n},\n\"PUT\": {\n\"avg_us\": 6.26,\n\"bytes_per_sec\": 1439,\n\"histogram\": [\n{ \"count\": 10, \"ge_us\": 4.1 },\n{ \"count\": 2, \"ge_us\": 8.19 },\n{ \"count\": 3, \"ge_us\": 16.38 }\n],\n\"p50_us\": 6.14,\n\"p99_us\": 49.15,\n\"qps\": 10\n}\n},\n\"pid\": 2349824,\n\"timestamp\": \"2026-05-02T07:32:11Z\",\n\"uptime_secs\": 5\n}\n5c. JSON 字段说明\n字段\n类型\n说明\ntimestamp\nstring\nISO 8601 UTC 时间戳\npid\nnumber\n目标 CKB 进程 PID\nuptime_secs\nnumber\nckb-probe 运行时长（秒）\noperations\nobject\n五个 RocksDB 操作的实时指标\noperations.*.qps\nnumber\n每秒操作数\noperations.*.avg_us\nnumber\n平均延迟（微秒）\noperations.*.p50_us\nnumber\nP50 延迟（微秒，log2 直方图插值）\noperations.*.p99_us\nnumber\nP99 延迟（微秒，log2 直方图插值）\noperations.*.bytes_per_sec\nnumber / null\n吞吐量（B/s），WRITE/ITER_NEW 为 null\noperations.*.histogram\narray\nlog2 延迟分布（仅 --histogram 时出现）\noperations.*.histogram[].ge_us\nnumber\n桶下界（微秒）\noperations.*.histogram[].count\nnumber\n该桶内的操作数\nanomalies\narray\nEWMA 异常事件（5 分钟 warmup 后启用）\nanomalies.*.trigger\nstring\n触发条件组合：AVG / P99 / CAP\nanomalies.*.multiplier\nnumber\n当前均值 / 基线均值\n附录 A: 48h 稳定性测试结果摘要\n完整报告见 docs/STABILITY-REPORT_zh.md\n#\n指标\n结果\n关键数据\nS-1\n无崩溃\nPASS\n48h 全程无 panic/SIGSEGV\nS-2\n内存稳定\nPASS\nRSS 增长 0.00 MB（预算 5 MB）\nS-3\n无 BPF 错误\nPASS*\n误报（systemd 版本字符串匹配）\nS-4\n重启恢复\nPASS\nCKB 重启后 1 秒重连\n资源使用：Probe CPU P99=0.29%，RSS 稳定 21.4 MB，BPF 事件丢失 0/126,934 (0.0000%)\n附录 B: Case Study 结果摘要\n完整报告见 docs/CASE-STUDY-REPORT_zh.md\nCase 1 (IBD 写入模式): 22 分钟完整 IBD 追赶，GET 主导 (109.7 QPS)，6 个 ITER_NEW 异常事件\nCase 2 (压缩风暴): aggressive 调优下 GET 延迟从 ~200us 飙升至 6,988us (35x)，30 分钟捕获 6,112 个慢操作，零事件丢失\n附录 C: P-1~P-4 性能测试结果摘要\n完整报告见 Week 5 周报\n指标\n结果\n预算\nP-1 CPU 开销\n+2.11% (2h 综合)\n<= 3%\nP-2 RSS\n21.97 MB (稳定)\n<= 50 MB\nP-3 事件丢失\n0/78,353 (0.0000%)\n< 0.1%\nP-4 同步退化\n+0.37% (2h 综合)\n< 1%\n四项全部 PASS。\n运行模式总结\n模式\n命令\n输出格式\n用途\n环境检查\ncheck\n文本\n验证 eBPF 环境和符号可用性\n符号分析\nsymbols\n文本 / JSON\n分析 CKB 二进制符号覆盖率\n实时表格\nrocksdb\nTUI 表格\n实时监控 QPS/延迟/吞吐\n延迟直方图\nrocksdb --histogram\nTUI 直方图\n分析延迟分布特征\n慢操作捕获\nrocksdb --slow\nTUI 列表\n捕获超阈值操作\nJSON 输出\nrocksdb --json\nJSONL\n机器可读，供下游管线消费\nJSON + 直方图\nrocksdb --json --histogram\nJSONL\n含 log2 延迟分布的完整导出\n附录 D: Docker 构建与运行指南\nD.1 构建 Docker 镜像\ncd /root/ckb-probe\ndocker build -f docker/Dockerfile -t ckb-probe:latest .\n构建过程：\nStage 1 (probe-builder)：安装 Rust nightly + clang/llvm + bpf-linker，编译 eBPF 内核程序 + 用户态 CLI + db_bench\nStage 2 (runtime)：Ubuntu 24.04 + 运行时工具，复制编译产物和脚本\n产物镜像约 123 MB\nD.2 通用 Docker 运行模板\n# 基础命令模板（所有 demo / case / perf / stability 通用）\ndocker run --rm \\\n--privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /path/to/ckb-testnet:/data \\\n-v /path/to/ckb:/usr/local/bin/ckb:ro \\\n-v /tmp/output:/tmp/perf-run \\\nckb-probe:latest [args...]\n必需卷挂载说明：\n挂载\n用途\n/sys/kernel/debug\neBPF uprobe/kprobe 需要 debugfs\n/sys/kernel/btf\nBTF 类型信息（内核 >= 5.8）\n/path/to/ckb-testnet:/data\nCKB 链数据目录\n/path/to/ckb:/usr/local/bin/ckb:ro\nCKB 二进制（路径需与宿主机进程 exe 匹配）\n/tmp/output:/tmp/perf-run\n输出目录（报告、日志）\n必需权限：\n--privileged：eBPF 需要 CAP_BPF + CAP_SYS_ADMIN\n--pid host：访问宿主机进程的 PID namespace\nD.3 Docker 内六个 Demo 执行方法与结果\n以下所有命令均在 Docker 容器中执行，CKB 测试网节点运行在宿主机上。\nDemo 1: demo-check（环境检查 + 符号验证）\n命令：\ndocker run --rm --privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\nckb-probe:latest demo-check\n实际输出：\n════════════════════════════════════════════════════════════════\ndemo-check — environment + symbol report\n════════════════════════════════════════════════════════════════\n[1/3] running: ckb-probe check\n╔══════════════════════════════════════════════════════════════╗\n║ ckb-probe environment check ║\n╠══════════════════════════════════════════════════════════════╣\n✅ Kernel version 6.8.0-106-generic (need >= 5.8)\n❌ BPF config config not found\n✅ BTF support /sys/kernel/btf/vmlinux exists\n✅ Permissions running as root\n✅ bpf() syscall available\n✅ uprobe support /sys/kernel/debug/tracing/uprobe_events exists\n✅ CKB process 1 instance(s), pid=2349824\n❌ CKB symbols no key rocksdb symbols found\n╚══════════════════════════════════════════════════════════════╝\nResult: 6/8 checks passed\n╔══════════════════════════════════════════════════════════════╗\n║ ckb-probe eBPF validation ║\n╠══════════════════════════════════════════════════════════════╣\n✅ ── uprobe latency ── entry/return pair attach test\n✅ rocksdb_get_pinned_cf entry + return attached\n✅ rocksdb_put entry + return attached\n✅ rocksdb_write entry + return attached\n✅ rocksdb_create_iterator_cf entry + return attached\n✅ uprobe summary latency pairs: 4/6, Tier 1 symbols: 15/19\n✅ kprobe tcp_sendmsg/tcp_recvmsg attached\n✅ tracepoint sys_enter attached to raw_syscalls/sys_enter\n╚══════════════════════════════════════════════════════════════╝\n📊 Captured 264 uprobe, 40 tcp, 438 syscall events in 3s\n注：Docker 容器内 /proc/config.gz 不可用，导致 BPF config 检查失败（），但不影响实际 eBPF 功能。CKB symbols 检查在容器内因路径差异报 ，但 eBPF validation 部分确认了 15/19 个 Tier 1 符号实际可挂载。\nDemo 2: demo-table（实时统计表格）\n命令：\ndocker run --rm --privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\nckb-probe:latest demo-table 60\n实际输出：\n╭───────────────── CKB RocksDB Monitor (PID: 2349824) ─────────────────╮\n│ Uptime: 00:00:15 Sampling: 5s Node: CKB v0.204.0 │\n├────────────┬───────┬──────────┬──────────┬──────────┬────────────────┤\n│ Operation │ QPS │ Avg(μs) │ P50(μs) │ P99(μs) │ Bytes/s │\n├────────────┼───────┼──────────┼──────────┼──────────┼────────────────┤\n│ GET │ 112 │ 1671.8 │ 12.3 │ 25165.8 │ 12.0 KB/s │\n│ PUT │ 11 │ 6.3 │ 6.1 │ 24.6 │ 1.5 KB/s │\n│ WRITE │ 0 │ 58.7 │ 49.2 │ 49.2 │ — │\n│ ITER_NEW │ 0 │ 21.5 │ 24.6 │ 24.6 │ — │\n│ TXN_COMMIT │ 0 │ 177592.5 │ 50331.6 │402653.2 │ 1.5 KB/s │\n╰────────────┴───────┴──────────┴──────────┴──────────┴────────────────╯\nStatus: ⏳ Warming up — Collecting baseline (285s remaining).\nDemo 3: demo-histogram（延迟分布直方图）\n命令：\ndocker run --rm --privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\nckb-probe:latest demo-histogram 60\n实际输出：\nGET latency distribution:\n2μs │████ 6\n4μs │████████████████████████████████████████ 404\n8μs │███████████████ 150\n16μs │██████████████████████ 212\n32μs │████████████ 60\n65μs │█ 2\n131μs │█ 3\nGET latency distribution (next cycle):\n2μs │█ 5\n4μs │████████████████████████████████████████ 215\n8μs │█████████████ 72\n16μs │████████████ 68\n32μs │████████ 42\n65μs │█ 3\n131μs │ 2\nDemo 4: demo-slow（慢操作捕获）\n命令：\ndocker run --rm --privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\nckb-probe:latest demo-slow 60 1000\n参数说明：60 = 运行 60 秒，1000 = 阈值 1000us\n实际输出：\n╭───────────────── Slow Operations (threshold: 1000μs) ──────────────────╮\n│ Timestamp │ Op │ Latency │ Size │ Note │\n├───────────────┼────────────┼───────────┼──────────┼────────────────────┤\n│ 18:25.870 │ GET │ 3,060μs │ 32 B │ │\n│ 18:25.892 │ GET │ 22,348μs │ 240 B │ │\n│ 18:25.928 │ GET │ 36,416μs │ 125 B │ │\n│ 18:25.953 │ GET │ 24,177μs │ 8 B │ │\n│ 18:25.956 │ GET │ 3,211μs │ 32 B │ │\n│ 18:26.006 │ GET │ 50,378μs │ 240 B │ │\n│ 18:26.042 │ GET │ 36,064μs │ 101 B │ │\n│ 18:26.068 │ GET │ 25,758μs │ 8 B │ │\n╰───────────────┴────────────┴───────────┴──────────┴────────────────────╯\nShowing 8 of 157 slow operations in last 15s.\nBPF event loss: 0 / 157 attempted (0.0000%)\nDemo 5: demo-normal（JSON 监控输出）\n命令：\ndocker run --rm --privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n-v /tmp/output:/tmp/perf-run \\\nckb-probe:latest demo-normal 60\n实际输出（最后一个采样周期）：\n{\n\"anomalies\": [],\n\"operations\": {\n\"GET\": {\n\"avg_us\": 421.02,\n\"bytes_per_sec\": 5629,\n\"p50_us\": 12.29,\n\"p99_us\": 12582.91,\n\"qps\": 50\n},\n\"ITER_NEW\": {\n\"avg_us\": 33.57,\n\"bytes_per_sec\": null,\n\"p50_us\": 24.58,\n\"p99_us\": 49.15,\n\"qps\": 3\n},\n\"PUT\": {\n\"avg_us\": 5.82,\n\"bytes_per_sec\": 1676,\n\"p50_us\": 6.14,\n\"p99_us\": 24.58,\n\"qps\": 13\n},\n\"TXN_COMMIT\": {\n\"avg_us\": 54568.75,\n\"bytes_per_sec\": 1676,\n\"p50_us\": 786.43,\n\"p99_us\": 201326.59,\n\"qps\": 0\n},\n\"WRITE\": {\n\"avg_us\": 51.8,\n\"bytes_per_sec\": null,\n\"p50_us\": 49.15,\n\"p99_us\": 49.15,\n\"qps\": 0\n}\n},\n\"pid\": 2349824,\n\"timestamp\": \"2026-05-02T07:52:39Z\",\n\"uptime_secs\": 15\n}\n输出保存到 /tmp/perf-run/demo/demo-normal-snapshot.json。\nDemo 6: demo-stress（压力注入 + 异常检测）\n命令：\ndocker run --rm --privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n-v /tmp/output:/tmp/perf-run \\\nckb-probe:latest demo-stress 50000\n参数说明：50000 = db_bench 写入 50,000 条记录（每条 4KB，共 ~195MB）\n实际输出：\n════════════════════════════════════════════════════════════════\ndemo-stress — synthetic RocksDB load injection (db_bench)\n════════════════════════════════════════════════════════════════\nckb pid : 2349824\ndb_bench size : 50000 entries × 4KB = ~195 MB\noutput : /tmp/perf-run/demo/demo-stress.txt\n[demo-stress] starting ckb-probe rocksdb --slow --threshold 500\n[demo-stress] ckb-probe pid=3548386\n[demo-stress] capturing 15s baseline...\n[demo-stress] launching db_bench fillrandom --num=50000 --threads=4\n[demo-stress] waiting for db_bench to complete...\n[demo-stress] db_bench done\n[demo-stress] 30s cool-down...\n════════════════════════════════════════════════════════════════\ndemo-stress result\n2026-05-02 07:54:08\n════════════════════════════════════════════════════════════════\nckb-probe captured during stress:\nANOMALY DETECTED count : 0\nslow op log lines : 128\nBPF event loss: 0 / 215 attempted (0.0000%)\nNote: no ANOMALY DETECTED triggered. This can happen if the disk had\nenough headroom to absorb db_bench without contending with CKB.\nTry with a larger --num or apply db-options.aggressive via case-2.\n注：本次测试磁盘有足够的 I/O headroom 吸收了 db_bench 负载，未触发 ANOMALY DETECTED。在磁盘 I/O 更紧张的环境下（或使用 aggressive RocksDB 调优），异常检测会被触发。Case 2 的压缩风暴测试已验证此能力（GET 延迟 35x 飙升，6,112 个慢操作）。\nD.4 三项长时间测试的 Docker 命令\n48h 稳定性测试 (S-1 ~ S-4)\ndocker run -d --name stability-test \\\n--privileged --pid host --network host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/root/ckb-testnet/ckb:ro \\\n-v /tmp/perf-run:/tmp/perf-run \\\n-e CKB_BIN=/root/ckb-testnet/ckb \\\n-e CKB_RPC=http://127.0.0.1:8124 \\\nckb-probe:latest stability\n# 查看进度\ndocker logs -f stability-test\n# 测试完成后生成报告\ndocker exec stability-test bash -c \\\n'/opt/scripts/stability/generate-report.sh /path/to/stability-/'\n测试内容：48 小时持续运行，3 个 ckb-probe 实例并行采集，含 T+24h 的 CKB 进程重启恢复测试。\nCase 1: IBD 写入模式 (最长 2 小时)\ndocker run --rm \\\n--privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n-v /tmp/case-output:/tmp/perf-run \\\n--entrypoint bash \\\nckb-probe:latest -c '\n/opt/scripts/case/start-ckb.sh\n/opt/scripts/case/case-1-ibd-write-pattern.sh 7200\n'\n脚本会自动在 tip 追上网络最新高度时提前退出。\nCase 2: 压缩风暴捕获 (最长 30 分钟)\ndocker run --rm \\\n--privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n-v /tmp/case-output:/tmp/perf-run \\\n--entrypoint bash \\\nckb-probe:latest -c '\n/opt/scripts/case/start-ckb.sh\n/opt/scripts/case/case-2-compaction-storm.sh 1800\n'\n脚本会自动应用 aggressive RocksDB 调优、重启 CKB、挂载探针、等待慢操作数据，结束后自动恢复原始配置。\nP-1 ~ P-4 性能测试 (约 4 小时)\ndocker run --rm \\\n--privileged --pid host \\\n-v /sys/kernel/debug:/sys/kernel/debug:ro \\\n-v /sys/kernel/btf:/sys/kernel/btf:ro \\\n-v /root/ckb-testnet:/data \\\n-v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n-v /tmp/perf-output:/tmp/perf-run \\\nckb-probe:latest perf\nPhase A (2h with-probe) + Phase B (2h baseline)，均从相同 tip 启动，自动对比 CPU / RSS / 事件丢失 / 同步速度。", "content_html": "

CKB-Probe 演示流程说明

\n
\n

范围：仅限 CKB 测试网

\n

本文档覆盖 ckb-probe 的五个核心演示步骤，每步附完整终端输出、关键命令说明和输出解读。
\n所有输出均为真实运行数据（2026-05-02，CKB v0.204.0 测试网节点）。

\n
\n
\n

调整说明

\n

本文档替代原计划的演示视频。文字报告在以下方面对评审者更为友好：

\n
    \n
  • 评审者可以直接复制报告中的命令进行复现，不需要反复拖动视频进度条
    • \n
  • 终端输出配合文字解读比视频旁白更容易精确定位到具体的输出字段和数值
    • \n
  • 报告本身可以作为项目文档的一部分长期保留，便于后续版本更新时同步修改
    • \n
  • 视频一旦录制后修改成本较高，而文档可以随项目迭代
    • \n
\n
\n

前置条件

\n
# 系统要求\n# - Linux 内核 >= 5.8 (BTF 支持)\n# - root 权限 (eBPF 需要 CAP_BPF + CAP_SYS_ADMIN)\n# - CKB 测试网节点运行中\n\n# Docker 方式运行 (推荐)\ndocker run --rm --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /path/to/ckb-testnet:/data \\\n  -v /path/to/ckb:/usr/local/bin/ckb:ro \\\n  ckb-probe:latest <command>\n\n# 或者直接在宿主机运行 (需要 root)\nsudo ckb-probe <command>\n
\n
\n

步骤 1: 环境检查与 eBPF 验证

\n

目的： 验证 eBPF 环境就绪、CKB 二进制可探测、所有 uprobe/kprobe/tracepoint 可挂载。

\n

命令：

\n
sudo ckb-probe check --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb)\n
\n

完整终端输出：

\n
╔══════════════════════════════════════════════════════════════╗\n║  ckb-probe environment check                               ║\n╠══════════════════════════════════════════════════════════════╣\n  ✅ Kernel version            6.8.0-106-generic (need >= 5.8)\n  ✅ BPF config                BPF=y SYSCALL=y JIT=y\n  ✅ BTF support               /sys/kernel/btf/vmlinux exists\n  ✅ Permissions               running as root\n  ✅ bpf() syscall             available\n  ✅ uprobe support            /sys/kernel/debug/tracing/uprobe_events exists\n  ✅ CKB process               1 instance(s), pid=2349824\n  ✅ CKB symbols               2/3 key symbols found (symtab)\n╚══════════════════════════════════════════════════════════════╝\n\n  Result: 8/8 checks passed\n  🎉 All checks passed!\n\n\n╔═════���════════════════════════════════════════════════════════╗\n║  ckb-probe eBPF validation                                 ║\n╠══════════════════════════════════════════════════════════════╣\n  ✅ ── uprobe latency ──      entry/return pair attach test\n  ✅   rocksdb_get_pinned_cf   entry + return attached\n  ✅   rocksdb_put             entry + return attached\n  ✅   rocksdb_write           entry + return attached\n  ❌   rocksdb_delete          symbol not in binary (expected)\n  ✅   rocksdb_create_iterator_cf  entry + return attached\n  ❌   rocksdb_multi_get_cf    symbol not in binary (expected)\n  ✅ ── uprobe Tier 1 ──       all 19 Tier 1 symbol attach test\n  ✅   rocksdb_get             symbol found, uprobe-attachable\n  ✅   rocksdb_get_pinned      symbol found, uprobe-attachable\n  ✅   rocksdb_get_pinned_cf   symbol found, uprobe-attachable\n  ✅   rocksdb_put             symbol found, uprobe-attachable\n  ✅   rocksdb_put_cf          symbol found, uprobe-attachable\n  ✅   rocksdb_write           symbol found, uprobe-attachable\n  ❌   rocksdb_delete          not found in binary\n  ❌   rocksdb_delete_cf       not found in binary\n  ❌   rocksdb_multi_get_cf    not found in binary\n  ✅   rocksdb_transaction_put_cf  symbol found, uprobe-attachable\n  ✅   rocksdb_transaction_delete_cf  symbol found, uprobe-attachable\n  ❌   rocksdb_transaction_get_cf  not found in binary\n  ✅   rocksdb_transaction_commit  symbol found, uprobe-attachable\n  ✅   rocksdb_optimistictransaction_begin  symbol found, uprobe-attachable\n  ✅   rocksdb_create_iterator_cf  symbol found, uprobe-attachable\n  ✅   rocksdb_iter_seek       symbol found, uprobe-attachable\n  ✅   rocksdb_iter_seek_to_first  symbol found, uprobe-attachable\n  ✅   rocksdb_iter_next       symbol found, uprobe-attachable\n  ✅   rocksdb_iter_destroy    symbol found, uprobe-attachable\n  ✅ uprobe summary            latency pairs: 4/6, Tier 1 symbols: 15/19\n  ✅ kprobe tcp_sendmsg_entry  attached to tcp_sendmsg\n  ✅ kprobe tcp_sendmsg_return attached to tcp_sendmsg\n  ✅ kprobe tcp_recvmsg_entry  attached to tcp_recvmsg\n  ✅ kprobe tcp_recvmsg_return attached to tcp_recvmsg\n  ✅ tracepoint sys_enter      attached to raw_syscalls/sys_enter\n╚══════════════════════════════════════════════════════════════╝\n\n  Result: 27/33 checks passed\n\n  ⏳ Collecting live events for 3 seconds...\n\n  [syscall] pid=2349824 tid=808096 nr=232 (epoll_wait)\n  [uprobe] pid=2349824 tid=2351140 func=get_pinned_cf            latency=45.2μs\n  [uprobe] pid=2349824 tid=2351140 func=get_pinned_cf            latency=14.5μs\n  [uprobe] pid=2349824 tid=2351140 func=get_pinned_cf            latency=5.3μs\n  [uprobe] pid=2349824 tid=2351140 func=get_pinned_cf            latency=6.0μs\n  [uprobe] pid=2349824 tid=2351140 func=get_pinned_cf            latency=4.5μs\n  [tcp] pid=2349824 tid=740351 dir=RX bytes=705\n  [tcp] pid=2349824 tid=808096 dir=TX bytes=705\n\n  📊 Captured 264 uprobe, 40 tcp, 438 syscall events in 3s\n
\n

解读：

\n
    \n
  • 环境检查 8/8 全部通过：内核 6.8.0 满足 >= 5.8 要求，BTF 可用，root 权限，bpf() 系统调用可用
    • \n
  • eBPF 验证 27/33 通过：4 个 uprobe 延迟对（GET/PUT/WRITE/ITER）成功挂载，15/19 个 Tier 1 符号可用，4 个未找到的符号（delete/multi_get/transaction_get_cf）是 CKB 未使用的 RocksDB API，属于预期缺失
    • \n
  • kprobe/tracepoint 全部成功：tcp_sendmsg/tcp_recvmsg 网络探针 + raw_syscalls 系统调用追踪
    • \n
  • 实时事件采集验证：3 秒内捕获 264 个 uprobe 事件 + 40 个 TCP 事件 + 438 个 syscall 事件，证明数据通道正常
    • \n
\n
\n

步骤 2: 符号分析

\n

目的： 全面分析 CKB 二进制中的 RocksDB 符号，评估 uprobe 覆盖率。

\n

命令：

\n
ckb-probe symbols /root/ckb-testnet/ckb\n
\n

完整终端输出：

\n
════════════════════════════════════════════════════════════════════\n   CKB Binary Symbol Analysis Report\n   Binary: /root/ckb-testnet/ckb (65.0 MB)\n   Format: ELF 64-bit x86_64\n════════════════════════════════════════════════════════════════════\n\n── ELF Overview ────────────────────────────────────────\n  .symtab:        ✅ Present (153057 symbols)\n  .dynsym:        ✅ Present (511 symbols)\n  DWARF:          ❌ Not found\n  Strip status:   debuginfo-stripped (.symtab retained)\n\n── RocksDB Linkage ─────────────────────────────────────\n  Method:         Static (bundled into CKB binary)\n  Evidence:       No librocksdb.so in dynamic deps; 155 rocksdb_* in .symtab\n  Assessment:     ✅ Ideal — C API symbols embedded in binary\n\n── Dynamic Dependencies ────────────────────────────────\n  libstdc++.so.6            libgcc_s.so.1             libm.so.6\n  libc.so.6                 ld-linux-x86-64.so.2\n\n── [Tier 1] Directly uprobe-attachable (extern \"C\", stable) ──\n  ✅ rocksdb_get                                    0x021e3330  (318 B)\n  ✅ rocksdb_get_cf                                 0x021e34a0  (215 B)\n  ✅ rocksdb_get_pinned                             0x021e4b20  (427 B)\n  ✅ rocksdb_get_pinned_cf                          0x021e4d00  (379 B)\n  ✅ rocksdb_put                                    0x021e30a0  (105 B)\n  ✅ rocksdb_put_cf                                 0x021e3120  (240 B)\n  ✅ rocksdb_write                                  0x021e3230  (208 B)\n  ✅ rocksdb_transaction_put_cf                     0x021e4770  (113 B)\n  ✅ rocksdb_transaction_delete_cf                  0x021e4800  (101 B)\n  ✅ rocksdb_transaction_commit                     0x021e42f0  (71 B)\n  ✅ rocksdb_optimistictransaction_begin            0x021e4a50  (99 B)\n  ✅ rocksdb_create_iterator_cf                     0x021e3670  (167 B)\n  ✅ rocksdb_iter_seek                              0x021e3b30  (30 B)\n  ✅ rocksdb_iter_seek_to_first                     0x021e3b10  (9 B)\n  ✅ rocksdb_iter_next                              0x021e3b70  (9 B)\n  ✅ rocksdb_iter_destroy                           0x021e3ae0  (32 B)\n  → 16 / 20 tracked targets found\n\n── [Tier 2] Possibly available (Rust mangled, version-bound) ──\n  ⚠️  ckb_network::network::NetworkService::start\n  ⚠️  ckb_sync::synchronizer::block_process::BlockProcess::execute\n  ⚠️  ckb_sync::synchronizer::headers_process::HeadersProcess::execute\n  ⚠️  ckb_chain::chain_controller::ChainController::asynchronous_process_remote_block\n  ⚠️  ckb_store::transaction::StoreTransaction::attach_block\n  ⚠️  ckb_store::transaction::StoreTransaction::insert_block\n  ⚠️  ckb_store::transaction::StoreTransaction::commit\n  ⚠️  ckb_db::db::RocksDB::get_pinned\n  ⚠️  ckb_db::db::RocksDB::get_pinned_default\n  ... (11 / 21 tracked targets found)\n\n── [Tier 3] Unavailable (inlined / stripped / crate-internal) ──\n  ❌ ckb_network::protocols::CKBHandler::received — not found (likely inlined)\n  ❌ ckb_chain::chain_service::ChainService::process_block — not found (likely inlined)\n  ❌ ckb_store::db::ChainDB::get_block — not found (likely inlined)\n  ... (19 tracked functions not found)\n\n── Summary ─────────────────────────────────────────────\n  Tier 1:  16 / 20  ( 80%)  partial coverage ⚠️\n  Tier 2:  11 / 21  ( 52%)  available in this binary\n  Tier 3:  19 tracked functions not found\n  Total function symbols:      86852\n  Total RocksDB C API symbols: 155\n════════════════════════════════════════════════════════════════════\n
\n

解读：

\n
    \n
  • Tier 1 (C API) — 16/20 找到（80%），这些是 extern \"C\" 符号，跨 CKB 版本稳定，是 ckb-probe 的核心探测点
    • \n
  • RocksDB 静态链接 — 155 个 rocksdb_* 符号直接嵌入 CKB 二进制，无需额外的 .so 文件
    • \n
  • Tier 2 (Rust mangled) — 11/21 找到，这些 Rust 函数名含编译哈希，不同版本可能变化
    • \n
  • Tier 3 (inlined) — 19 个预期缺失，因为编译器内联优化消除了这些函数入口
    • \n
\n
\n

步骤 3: 正常同步期间的实时 RocksDB 监控

\n

目的： 在 CKB 测试网节点正常运行期间，实时展示五类 RocksDB 操作的延迟、吞吐和延迟分布。

\n

3a. 统计表格模式

\n

命令：

\n
sudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) --interval 5\n
\n

终端输出：

\n
╭───────────────── CKB RocksDB Monitor (PID: 2349824) ─────────────────╮\n│ Uptime: 00:00:05   Sampling: 5s   Node: CKB v0.204.0               │\n├────────────┬───────┬──────────┬──────────┬──────────┬────────────────┤\n│ Operation  │  QPS  │ Avg(μs)  │ P50(μs)  │ P99(μs)  │    Bytes/s    │\n├────────────┼───────┼──────────┼──────────┼──────────┼────────────────┤\n│ GET        │    93 │    23.8  │     6.1  │   196.6  │   5.5 KB/s    │\n│ PUT        │     8 │     6.7  │     6.1  │    24.6  │    624 B/s    │\n│ WRITE      │     0 │    43.1  │    49.2  │    49.2  │       —       │\n│ ITER_NEW   │     1 │    38.6  │    49.2  │    98.3  │       —       │\n│ TXN_COMMIT │     1 │   326.7  │   393.2  │   393.2  │    624 B/s    │\n╰────────────┴───────┴──────────┴──────────┴──────────┴────────────────╯\n  Status: ⏳ Warming up — Collecting baseline (295s remaining).\n
\n
╭───────────────── CKB RocksDB Monitor (PID: 2349824) ─────────────────╮\n│ Uptime: 00:00:10   Sampling: 5s   Node: CKB v0.204.0               │\n├────────────┬───────┬──────────┬──────────┬──────────┬────────────────┤\n│ Operation  │  QPS  │ Avg(μs)  │ P50(μs)  │ P99(μs)  │    Bytes/s    │\n├────────────┼───────┼──────────┼──────────┼──────────┼────────────────┤\n│ GET        │   177 │   411.6  │    12.3  │ 12582.9  │  21.5 KB/s    │\n│ PUT        │     0 │     0.0  │     0.0  │     0.0  │     0 B/s     │\n│ WRITE      │     0 │     0.0  │     0.0  │     0.0  │       —       │\n│ ITER_NEW   │     0 │     0.0  │     0.0  │     0.0  │       —       │\n│ TXN_COMMIT │     0 │     0.0  │     0.0  │     0.0  │     0 B/s     │\n╰────────────┴───────┴──────────┴──────────┴──────────┴────────────────╯\n  Status: ⏳ Warming up — Collecting baseline (290s remaining).\n
\n

3b. 延迟分布直方图模式

\n

命令：

\n
sudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) --histogram --interval 5\n
\n

终端输出（表格下方附加直方图）：

\n
  GET latency distribution:\n         2μs │████                                        22\n         4μs │████████████████████████████████████████   369\n         8μs │███████████████████                        182\n        16μs │██████████████████                         213\n        32μs │██████████                                  46\n        65μs │██                                           6\n\n  PUT latency distribution:\n         2μs │██████                                       3\n         4μs │████████████████████████████████████████    10\n         8μs │████                                         2\n        16μs │██████                                       3\n        32μs │██                                           1\n\n  WRITE latency distribution:\n        32μs │████████████████████████████████████████     1\n\n  ITER_NEW latency distribution:\n        16μs │████████████████████████████████████████     2\n        32μs │████████████████████████████████████████     2\n\n  TXN_COMMIT latency distribution:\n        65μs │████████████████████                         1\n       262μs │████████████████████████████████████████     2\n
\n

解读：

\n
    \n
  • GET 呈长尾分布：主体在 2~32us（缓存命中），少量尾部延迟由磁盘 I/O 引起
    • \n
  • PUT 集中在 4~16us，单次写入非常轻量
    • \n
  • TXN_COMMIT 在 65~262us 区间，反映 WAL 写入开销
    • \n
  • 直方图数据来自 eBPF 内核态 per-CPU 计数器，零采样开销
    • \n
\n
\n

步骤 4: 慢操作捕获

\n

目的： 实时捕获超过阈值的 RocksDB 操作，展示每个慢操作的精确延迟、数据大小和 BPF 事件丢失率。

\n

命令：

\n
sudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) \\\n  --slow --threshold 1000 --interval 5\n
\n

终端输出：

\n
╭───────────────── Slow Operations (threshold: 1000μs) ──────────────────╮\n│ Timestamp     │ Op         │   Latency │     Size │ Note               │\n├───────────────┼────────────┼───────────┼──────────┼────────────────────┤\n│ 57:21.976     │ GET        │   8,162μs │    125 B │                    │\n│ 57:21.986     │ GET        │   9,389μs │    240 B │                    │\n│ 57:21.992     │ GET        │   5,346μs │    125 B │                    │\n│ 57:21.998     │ GET        │   6,167μs │      8 B │                    │\n│ 57:22.004     │ GET        │   5,484μs │    173 B │                    │\n│ 57:22.007     │ GET        │   3,084μs │      8 B │                    │\n╰───────────────┴────────────┴───────────┴──────────┴────────────────────╯\n  Showing 8 of 13 slow operations in last 5s.\n  BPF event loss: 0 / 13 attempted  (0.0000%)\n
\n
╭───────────────── Slow Operations (threshold: 1000μs) ──────────────────╮\n│ Timestamp     │ Op         │   Latency │     Size │ Note               │\n├───────────────┼────────────┼───────────┼──────────┼────────────────────┤\n│ 57:29.099     │ GET        │   7,207μs │      8 B │                    │\n│ 57:29.104     │ GET        │   5,223μs │     32 B │                    │\n│ 57:29.107     │ GET        │   2,432μs │    240 B │                    │\n│ 57:29.115     │ GET        │   8,238μs │    101 B │                    │\n│ 57:29.127     │ GET        │  11,631μs │     32 B │                    │\n│ 57:29.130     │ GET        │   3,230μs │    240 B │                    │\n│ 57:29.134     │ GET        │   4,002μs │    101 B │                    │\n│ 57:29.137     │ GET        │   2,946μs │      8 B │                    │\n╰───────────────┴────────────┴───────────┴──────────┴────────────────────╯\n  Showing 8 of 32 slow operations in last 10s.\n  BPF event loss: 0 / 32 attempted  (0.0000%)\n
\n

解读：

\n
    \n
  • 仅超过 1000us (1ms) 的操作被捕获，常态下对系统零开销
    • \n
  • 慢操作全部为 GET，延迟在 2~11ms，由 RocksDB block cache miss 触发磁盘读取导致
    • \n
  • BPF event loss: 0 / 32 (0.0000%) — RingBuf 数据通道零丢失
    • \n
  • Size 列显示该操作读写的数据大小（8B = key, 32~240B = value）
    • \n
\n
\n

步骤 5: JSON 导出

\n

目的： 展示机器可读的 JSON 输出格式，适合下游监控管线和数据分析。

\n

5a. 标准 JSON 输出

\n

命令：

\n
sudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) \\\n  --json --interval 5\n
\n

终端输出（单个采样周期）：

\n
{\n  \"anomalies\": [],\n  \"operations\": {\n    \"GET\": {\n      \"avg_us\": 19.71,\n      \"bytes_per_sec\": 1673,\n      \"p50_us\": 12.29,\n      \"p99_us\": 98.3,\n      \"qps\": 22\n    },\n    \"ITER_NEW\": {\n      \"avg_us\": 0.0,\n      \"bytes_per_sec\": null,\n      \"p50_us\": 0.0,\n      \"p99_us\": 0.0,\n      \"qps\": 0\n    },\n    \"PUT\": {\n      \"avg_us\": 0.0,\n      \"bytes_per_sec\": 0,\n      \"p50_us\": 0.0,\n      \"p99_us\": 0.0,\n      \"qps\": 0\n    },\n    \"TXN_COMMIT\": {\n      \"avg_us\": 0.0,\n      \"bytes_per_sec\": 0,\n      \"p50_us\": 0.0,\n      \"p99_us\": 0.0,\n      \"qps\": 0\n    },\n    \"WRITE\": {\n      \"avg_us\": 0.0,\n      \"bytes_per_sec\": null,\n      \"p50_us\": 0.0,\n      \"p99_us\": 0.0,\n      \"qps\": 0\n    }\n  },\n  \"pid\": 2349824,\n  \"timestamp\": \"2026-05-02T07:31:41Z\",\n  \"uptime_secs\": 0\n}\n
\n

5b. JSON + 直方图融合输出

\n

命令：

\n
sudo ckb-probe rocksdb --binary /root/ckb-testnet/ckb --pid $(pgrep -x ckb) \\\n  --json --histogram --interval 5\n
\n

终端输出（单个采样周期，含 histogram 字段）：

\n
{\n  \"anomalies\": [],\n  \"operations\": {\n    \"GET\": {\n      \"avg_us\": 244.69,\n      \"bytes_per_sec\": 11803,\n      \"histogram\": [\n        { \"count\": 25, \"ge_us\": 4.1 },\n        { \"count\": 5, \"ge_us\": 8.19 },\n        { \"count\": 6, \"ge_us\": 16.38 }\n      ],\n      \"p50_us\": 12.29,\n      \"p99_us\": 12582.91,\n      \"qps\": 116\n    },\n    \"PUT\": {\n      \"avg_us\": 6.26,\n      \"bytes_per_sec\": 1439,\n      \"histogram\": [\n        { \"count\": 10, \"ge_us\": 4.1 },\n        { \"count\": 2, \"ge_us\": 8.19 },\n        { \"count\": 3, \"ge_us\": 16.38 }\n      ],\n      \"p50_us\": 6.14,\n      \"p99_us\": 49.15,\n      \"qps\": 10\n    }\n  },\n  \"pid\": 2349824,\n  \"timestamp\": \"2026-05-02T07:32:11Z\",\n  \"uptime_secs\": 5\n}\n
\n

5c. JSON 字段说明

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
字段类型说明
timestampstringISO 8601 UTC 时间戳
pidnumber目标 CKB 进程 PID
uptime_secsnumberckb-probe 运行时长（秒）
operationsobject五个 RocksDB 操作的实时指标
operations.*.qpsnumber每秒操作数
operations.*.avg_usnumber平均延迟（微秒）
operations.*.p50_usnumberP50 延迟（微秒，log2 直方图插值）
operations.*.p99_usnumberP99 延迟（微秒，log2 直方图插值）
operations.*.bytes_per_secnumber / null吞吐量（B/s），WRITE/ITER_NEW 为 null
operations.*.histogramarraylog2 延迟分布（仅 --histogram 时出现）
operations.*.histogram[].ge_usnumber桶下界（微秒）
operations.*.histogram[].countnumber该桶内的操作数
anomaliesarrayEWMA 异常事件（5 分钟 warmup 后启用）
anomalies.*.triggerstring触发条件组合：AVG / P99 / CAP
anomalies.*.multipliernumber当前均值 / 基线均值
\n
\n

附录 A: 48h 稳定性测试结果摘要

\n
\n

完整报告见 docs/STABILITY-REPORT_zh.md

\n
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
#指标结果关键数据
S-1无崩溃PASS48h 全程无 panic/SIGSEGV
S-2内存稳定PASSRSS 增长 0.00 MB（预算 5 MB）
S-3无 BPF 错误PASS*误报（systemd 版本字符串匹配）
S-4重启恢复PASSCKB 重启后 1 秒重连
\n

资源使用：Probe CPU P99=0.29%，RSS 稳定 21.4 MB，BPF 事件丢失 0/126,934 (0.0000%)

\n

附录 B: Case Study 结果摘要

\n
\n

完整报告见 docs/CASE-STUDY-REPORT_zh.md

\n
\n

Case 1 (IBD 写入模式): 22 分钟完整 IBD 追赶，GET 主导 (109.7 QPS)，6 个 ITER_NEW 异常事件

\n

Case 2 (压缩风暴): aggressive 调优下 GET 延迟从 ~200us 飙升至 6,988us (35x)，30 分钟捕获 6,112 个慢操作，零事件丢失

\n

附录 C: P-1~P-4 性能测试结果摘要

\n
\n

完整报告见 Week 5 周报

\n
\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
指标结果预算
P-1 CPU 开销+2.11% (2h 综合)<= 3%
P-2 RSS21.97 MB (稳定)<= 50 MB
P-3 事件丢失0/78,353 (0.0000%)< 0.1%
P-4 同步退化+0.37% (2h 综合)< 1%
\n

四项全部 PASS。

\n
\n

运行模式总结

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
模式命令输出格式用途
环境检查check文本验证 eBPF 环境和符号可用性
符号分析symbols文本 / JSON分析 CKB 二进制符号覆盖率
实时表格rocksdbTUI 表格实时监控 QPS/延迟/吞吐
延迟直方图rocksdb --histogramTUI 直方图分析延迟分布特征
慢操作捕获rocksdb --slowTUI 列表捕获超阈值操作
JSON 输出rocksdb --jsonJSONL机器可读，供下游管线消费
JSON + 直方图rocksdb --json --histogramJSONL含 log2 延迟分布的完整导出
\n
\n

附录 D: Docker 构建与运行指南

\n

D.1 构建 Docker 镜像

\n
cd /root/ckb-probe\ndocker build -f docker/Dockerfile -t ckb-probe:latest .\n
\n

构建过程：

\n
    \n
  • Stage 1 (probe-builder)：安装 Rust nightly + clang/llvm + bpf-linker，编译 eBPF 内核程序 + 用户态 CLI + db_bench
    • \n
  • Stage 2 (runtime)：Ubuntu 24.04 + 运行时工具，复制编译产物和脚本
    • \n
  • 产物镜像约 123 MB
    • \n
\n

D.2 通用 Docker 运行模板

\n
# 基础命令模板（所有 demo / case / perf / stability 通用）\ndocker run --rm \\\n  --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /path/to/ckb-testnet:/data \\\n  -v /path/to/ckb:/usr/local/bin/ckb:ro \\\n  -v /tmp/output:/tmp/perf-run \\\n  ckb-probe:latest <command> [args...]\n
\n

必需卷挂载说明：

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
挂载用途
/sys/kernel/debugeBPF uprobe/kprobe 需要 debugfs
/sys/kernel/btfBTF 类型信息（内核 >= 5.8）
/path/to/ckb-testnet:/dataCKB 链数据目录
/path/to/ckb:/usr/local/bin/ckb:roCKB 二进制（路径需与宿主机进程 exe 匹配）
/tmp/output:/tmp/perf-run输出目录（报告、日志）
\n

必需权限：

\n
    \n
  • --privileged：eBPF 需要 CAP_BPF + CAP_SYS_ADMIN
    • \n
  • --pid host：访问宿主机进程的 PID namespace
    • \n
\n
\n

D.3 Docker 内六个 Demo 执行方法与结果

\n

以下所有命令均在 Docker 容器中执行，CKB 测试网节点运行在宿主机上。

\n

Demo 1: demo-check（环境检查 + 符号验证）

\n

命令：

\n
docker run --rm --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  ckb-probe:latest demo-check\n
\n

实际输出：

\n
════════════════════════════════════════════════════════════════\n  demo-check — environment + symbol report\n════════════════════════════════════════════════════════════════\n\n[1/3] running: ckb-probe check\n\n╔══════════════════════════════════════════════════════════════╗\n║  ckb-probe environment check                               ║\n╠══════════════════════════════════════════════════════════════╣\n  ✅ Kernel version            6.8.0-106-generic (need >= 5.8)\n  ❌ BPF config                config not found\n  ✅ BTF support               /sys/kernel/btf/vmlinux exists\n  ✅ Permissions               running as root\n  ✅ bpf() syscall             available\n  ✅ uprobe support            /sys/kernel/debug/tracing/uprobe_events exists\n  ✅ CKB process               1 instance(s), pid=2349824\n  ❌ CKB symbols               no key rocksdb symbols found\n╚══════════════════════════════════════════════════════════════╝\n\n  Result: 6/8 checks passed\n\n╔══════════════════════════════════════════════════════════════╗\n║  ckb-probe eBPF validation                                 ║\n╠══════════════════════════════════════════════════════════════╣\n  ✅ ── uprobe latency ──      entry/return pair attach test\n  ✅   rocksdb_get_pinned_cf   entry + return attached\n  ✅   rocksdb_put             entry + return attached\n  ✅   rocksdb_write           entry + return attached\n  ✅   rocksdb_create_iterator_cf  entry + return attached\n  ✅ uprobe summary            latency pairs: 4/6, Tier 1 symbols: 15/19\n  ✅ kprobe tcp_sendmsg/tcp_recvmsg  attached\n  ✅ tracepoint sys_enter      attached to raw_syscalls/sys_enter\n╚══════════════════════════════════════════════════════════════╝\n\n  📊 Captured 264 uprobe, 40 tcp, 438 syscall events in 3s\n
\n
\n

注：Docker 容器内 /proc/config.gz 不可用，导致 BPF config 检查失败（\":cross_mark:\"），但不影响实际 eBPF 功能。CKB symbols 检查在容器内因路径差异报 \":cross_mark:\"，但 eBPF validation 部分确认了 15/19 个 Tier 1 符号实际可挂载。

\n
\n
\n

Demo 2: demo-table（实时统计表格）

\n

命令：

\n
docker run --rm --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  ckb-probe:latest demo-table 60\n
\n

实际输出：

\n
╭───────────────── CKB RocksDB Monitor (PID: 2349824) ─────────────────╮\n│ Uptime: 00:00:15   Sampling: 5s   Node: CKB v0.204.0               │\n├────────────┬───────┬──────────┬──────────┬──────────┬────────────────┤\n│ Operation  │  QPS  │ Avg(μs)  │ P50(μs)  │ P99(μs)  │    Bytes/s    │\n├────────────┼───────┼──────────┼──────────┼──────────┼────────────────┤\n│ GET        │   112 │  1671.8  │    12.3  │ 25165.8  │  12.0 KB/s    │\n│ PUT        │    11 │     6.3  │     6.1  │    24.6  │   1.5 KB/s    │\n│ WRITE      │     0 │    58.7  │    49.2  │    49.2  │       —       │\n│ ITER_NEW   │     0 │    21.5  │    24.6  │    24.6  │       —       │\n│ TXN_COMMIT │     0 │ 177592.5 │ 50331.6  │402653.2  │   1.5 KB/s    │\n╰────────────┴───────┴──────────┴──────────┴──────────┴────────────────╯\n  Status: ⏳ Warming up — Collecting baseline (285s remaining).\n
\n
\n

Demo 3: demo-histogram（延迟分布直方图）

\n

命令：

\n
docker run --rm --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  ckb-probe:latest demo-histogram 60\n
\n

实际输出：

\n
  GET latency distribution:\n         2μs │████                                         6\n         4μs │████████████████████████████████████████   404\n         8μs │███████████████                            150\n        16μs │██████████████████████                     212\n        32μs │████████████                                60\n        65μs │█                                            2\n       131μs │█                                            3\n\n  GET latency distribution (next cycle):\n         2μs │█                                            5\n         4μs │████████████████████████████████████████   215\n         8μs │█████████████                               72\n        16μs │████████████                                68\n        32μs │████████                                    42\n        65μs │█                                            3\n       131μs │                                             2\n
\n
\n

Demo 4: demo-slow（慢操作捕获）

\n

命令：

\n
docker run --rm --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  ckb-probe:latest demo-slow 60 1000\n
\n

参数说明：60 = 运行 60 秒，1000 = 阈值 1000us

\n

实际输出：

\n
╭───────────────── Slow Operations (threshold: 1000μs) ──────────────────╮\n│ Timestamp     │ Op         │   Latency │     Size │ Note               │\n├───────────────┼────────────┼───────────┼──────────┼────────────────────┤\n│ 18:25.870     │ GET        │   3,060μs │     32 B │                    │\n│ 18:25.892     │ GET        │  22,348μs │    240 B │                    │\n│ 18:25.928     │ GET        │  36,416μs │    125 B │                    │\n│ 18:25.953     │ GET        │  24,177μs │      8 B │                    │\n│ 18:25.956     │ GET        │   3,211μs │     32 B │                    │\n│ 18:26.006     │ GET        │  50,378μs │    240 B │                    │\n│ 18:26.042     │ GET        │  36,064μs │    101 B │                    │\n│ 18:26.068     │ GET        │  25,758μs │      8 B │                    │\n╰───────────────┴────────────┴───────────┴──────────┴────────────────────╯\n  Showing 8 of 157 slow operations in last 15s.\n  BPF event loss: 0 / 157 attempted  (0.0000%)\n
\n
\n

Demo 5: demo-normal（JSON 监控输出）

\n

命令：

\n
docker run --rm --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  -v /tmp/output:/tmp/perf-run \\\n  ckb-probe:latest demo-normal 60\n
\n

实际输出（最后一个采样周期）：

\n
{\n  \"anomalies\": [],\n  \"operations\": {\n    \"GET\": {\n      \"avg_us\": 421.02,\n      \"bytes_per_sec\": 5629,\n      \"p50_us\": 12.29,\n      \"p99_us\": 12582.91,\n      \"qps\": 50\n    },\n    \"ITER_NEW\": {\n      \"avg_us\": 33.57,\n      \"bytes_per_sec\": null,\n      \"p50_us\": 24.58,\n      \"p99_us\": 49.15,\n      \"qps\": 3\n    },\n    \"PUT\": {\n      \"avg_us\": 5.82,\n      \"bytes_per_sec\": 1676,\n      \"p50_us\": 6.14,\n      \"p99_us\": 24.58,\n      \"qps\": 13\n    },\n    \"TXN_COMMIT\": {\n      \"avg_us\": 54568.75,\n      \"bytes_per_sec\": 1676,\n      \"p50_us\": 786.43,\n      \"p99_us\": 201326.59,\n      \"qps\": 0\n    },\n    \"WRITE\": {\n      \"avg_us\": 51.8,\n      \"bytes_per_sec\": null,\n      \"p50_us\": 49.15,\n      \"p99_us\": 49.15,\n      \"qps\": 0\n    }\n  },\n  \"pid\": 2349824,\n  \"timestamp\": \"2026-05-02T07:52:39Z\",\n  \"uptime_secs\": 15\n}\n
\n

输出保存到 /tmp/perf-run/demo/demo-normal-snapshot.json。

\n
\n

Demo 6: demo-stress（压力注入 + 异常检测）

\n

命令：

\n
docker run --rm --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  -v /tmp/output:/tmp/perf-run \\\n  ckb-probe:latest demo-stress 50000\n
\n

参数说明：50000 = db_bench 写入 50,000 条记录（每条 4KB，共 ~195MB）

\n

实际输出：

\n
════════════════════════════════════════════════════════════════\n  demo-stress — synthetic RocksDB load injection (db_bench)\n════════════════════════════════════════════════════════════════\n  ckb pid       : 2349824\n  db_bench size : 50000 entries × 4KB = ~195 MB\n  output        : /tmp/perf-run/demo/demo-stress.txt\n\n[demo-stress] starting ckb-probe rocksdb --slow --threshold 500\n[demo-stress] ckb-probe pid=3548386\n[demo-stress] capturing 15s baseline...\n[demo-stress] launching db_bench fillrandom --num=50000 --threads=4\n[demo-stress] waiting for db_bench to complete...\n[demo-stress] db_bench done\n[demo-stress] 30s cool-down...\n\n════════════════════════════════════════════════════════════════\n  demo-stress result\n  2026-05-02 07:54:08\n════════════════════════════════════════════════════════════════\n\nckb-probe captured during stress:\n  ANOMALY DETECTED count : 0\n  slow op log lines      : 128\n  BPF event loss: 0 / 215 attempted  (0.0000%)\n\nNote: no ANOMALY DETECTED triggered. This can happen if the disk had\n      enough headroom to absorb db_bench without contending with CKB.\n      Try with a larger --num or apply db-options.aggressive via case-2.\n
\n
\n

注：本次测试磁盘有足够的 I/O headroom 吸收了 db_bench 负载，未触发 ANOMALY DETECTED。在磁盘 I/O 更紧张的环境下（或使用 aggressive RocksDB 调优），异常检测会被触发。Case 2 的压缩风暴测试已验证此能力（GET 延迟 35x 飙升，6,112 个慢操作）。

\n
\n
\n

D.4 三项长时间测试的 Docker 命令

\n

48h 稳定性测试 (S-1 ~ S-4)

\n
docker run -d --name stability-test \\\n  --privileged --pid host --network host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/root/ckb-testnet/ckb:ro \\\n  -v /tmp/perf-run:/tmp/perf-run \\\n  -e CKB_BIN=/root/ckb-testnet/ckb \\\n  -e CKB_RPC=http://127.0.0.1:8124 \\\n  ckb-probe:latest stability\n\n# 查看进度\ndocker logs -f stability-test\n\n# 测试完成后生成报告\ndocker exec stability-test bash -c \\\n  '/opt/scripts/stability/generate-report.sh /path/to/stability-<timestamp>/'\n
\n

测试内容：48 小时持续运行，3 个 ckb-probe 实例并行采集，含 T+24h 的 CKB 进程重启恢复测试。

\n

Case 1: IBD 写入模式 (最长 2 小时)

\n
docker run --rm \\\n  --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  -v /tmp/case-output:/tmp/perf-run \\\n  --entrypoint bash \\\n  ckb-probe:latest -c '\n    /opt/scripts/case/start-ckb.sh\n    /opt/scripts/case/case-1-ibd-write-pattern.sh 7200\n  '\n
\n

脚本会自动在 tip 追上网络最新高度时提前退出。

\n

Case 2: 压缩风暴捕获 (最长 30 分钟)

\n
docker run --rm \\\n  --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  -v /tmp/case-output:/tmp/perf-run \\\n  --entrypoint bash \\\n  ckb-probe:latest -c '\n    /opt/scripts/case/start-ckb.sh\n    /opt/scripts/case/case-2-compaction-storm.sh 1800\n  '\n
\n

脚本会自动应用 aggressive RocksDB 调优、重启 CKB、挂载探针、等待慢操作数据，结束后自动恢复原始配置。

\n

P-1 ~ P-4 性能测试 (约 4 小时)

\n
docker run --rm \\\n  --privileged --pid host \\\n  -v /sys/kernel/debug:/sys/kernel/debug:ro \\\n  -v /sys/kernel/btf:/sys/kernel/btf:ro \\\n  -v /root/ckb-testnet:/data \\\n  -v /root/ckb-testnet/ckb:/usr/local/bin/ckb:ro \\\n  -v /tmp/perf-output:/tmp/perf-run \\\n  ckb-probe:latest perf\n
\n

Phase A (2h with-probe) + Phase B (2h baseline)，均从相同 tip 启动，自动对比 CPU / RSS / 事件丢失 / 同步速度。

", "like_count": 0, "quote_count": 0 }, { "post_id": 24113, "post_number": 52, "topic_id": 10008, "topic_title": "Spark Program | Ckb-probe: Deep Observability Tool for CKB Nodes Based on Aya Kernel eBPF/ckb-probe：基于 Aya 内核 eBPF 的 CKB 节点深度可观测性工具", "topic_slug": "spark-program-ckb-probe-deep-observability-tool-for-ckb-nodes-based-on-aya-kernel-ebpf-ckb-probe-aya-ebpf-ckb", "author": "clair", "created_at": "2026-05-02T08:19:48.293000+00:00", "updated_at": "2026-05-02T08:19:48.293000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/spark-program-ckb-probe-deep-observability-tool-for-ckb-nodes-based-on-aya-kernel-ebpf-ckb-probe-aya-ebpf-ckb/10008/52", "content_text": "Week 7 周报：JSON 全局输出优化 + 演示说明文档\n周期：2026-04-27 ~ 2026-05-03\n作者：Clair\n项目：ckb-probe — 基于 eBPF 的 CKB 全节点深度可观测性工具\n一、本周目标\nJSON 全局输出 — 确保所有模式的 JSON 输出格式统一、字段完整\n制作完整演示说明文档 — 结构化的文字演示报告（Markdown），覆盖五个演示流程步骤，附完整终端输出和说明\n二、完成情况\n交付项\n状态\n说明\nJSON --histogram 融合输出\n--json --histogram 联用时 JSON 包含 log2 延迟分布\nJSON 输出字段文档化\n全部字段含义、类型、取值范围写入演示文档\n演示说明文档（中文）\n五步流程 + 真实终端输出 + 解读 + Docker 构建与运行指南\nDocker 构建指南\n镜像构建、通用模板、卷挂载/权限说明\nDocker 六个 Demo 实际运行\n全部在 Docker 容器内执行并记录真实输出\nDocker 长时间测试命令\n48h 稳定性 / Case 1 / Case 2 / P-1~P-4 的完整 Docker 命令\nClippy 修复\nmanual_checked_ops 警告，改用 checked_div()\n三、JSON 全局输出优化\n3.1 现有 JSON 输出模式\nckb-probe 提供两种 JSON 输出：\n模式\n命令\n内容\nRocksDB 监控\nrocksdb --json\n每周期输出操作统计 + 异常事件\n符号分析\nsymbols --json\n完整的 ELF 符号分析报告\n3.2 本周改进：--json --histogram 融合\n改进前： --json 和 --histogram 为独立分支，--json 模式下直方图数据被忽略。\n改进后： --json --histogram 联用时，每个操作的 JSON 对象中增加 histogram 字段，包含非零 log2 桶的延迟分布：\n{\n\"operations\": {\n\"GET\": {\n\"qps\": 845,\n\"avg_us\": 24.97,\n\"p50_us\": 24.58,\n\"p99_us\": 98.30,\n\"bytes_per_sec\": 101976,\n\"histogram\": [\n{ \"ge_us\": 1.02, \"count\": 40 },\n{ \"ge_us\": 4.1, \"count\": 1528 },\n{ \"ge_us\": 8.19, \"count\": 421 },\n{ \"ge_us\": 16.38, \"count\": 727 },\n{ \"ge_us\": 32.77, \"count\": 125 },\n{ \"ge_us\": 65.54, \"count\": 22 }\n]\n}\n}\n}\n设计决策：\n仅在 --histogram 显式启用时输出 histogram 字段，避免默认 JSON 体积膨胀\n仅输出非零桶（count > 0），稀疏表示，典型场景下每操作 5~15 个桶\nge_us 表示该桶的下界（微秒），对应 2^i 纳秒转换\n不影响已有 JSON 消费者（新增字段，向后兼容）\n3.3 JSON 字段完整性审计\n字段\n类型\n说明\n模式\ntimestamp\nstring\nISO 8601 UTC\nrocksdb --json\npid\nnumber\n目标进程 PID\nrocksdb --json\nuptime_secs\nnumber\n运行时长（秒）\nrocksdb --json\noperations\nobject\n五个操作的指标\nrocksdb --json\noperations.*.qps\nnumber\n每秒操作数\nrocksdb --json\noperations.*.avg_us\nnumber\n平均延迟（微秒）\nrocksdb --json\noperations.*.p50_us\nnumber\nP50 延迟（微秒）\nrocksdb --json\noperations.*.p99_us\nnumber\nP99 延迟（微秒）\nrocksdb --json\noperations.*.bytes_per_sec\nnumber|null\n吞吐量（B/s）\nrocksdb --json\noperations.*.histogram\narray\nlog2 延迟分布\nrocksdb --json --histogram\nanomalies\narray\nEWMA 异常事件\nrocksdb --json\nanomalies.*.time\nstring\n相对时间\nrocksdb --json\nanomalies.*.type\nstring\n固定 “latency_spike”\nrocksdb --json\nanomalies.*.operation\nstring\n操作名\nrocksdb --json\nanomalies.*.trigger\nstring\n触发条件组合\nrocksdb --json\nanomalies.*.current_avg_us\nnumber\n当前均值\nrocksdb --json\nanomalies.*.baseline_avg_us\nnumber\n基线均值\nrocksdb --json\nanomalies.*.multiplier\nnumber\n偏离倍数\nrocksdb --json\nanomalies.*.current_p99_us\nnumber\n当前 P99\nrocksdb --json\nanomalies.*.baseline_p99_us\nnumber\n基线 P99\nrocksdb --json\n所有数值保留 2 位小数（round2()），bytes_per_sec 对 WRITE/ITER_NEW 为 null。\n四、演示说明文档\n已创建 docs/demo-walkthrough_zh.md，覆盖五个完整演示步骤：\n步骤\n演示\n对应命令\n内容\n1\n环境检查\ncheck / demo-check\neBPF 环境验证 + 符号分析\n2\n符号分析\nsymbols\nTier 1/2/3 符号分类 + 覆盖率\n3\n实时监控\ndemo-table / demo-histogram\n表格 + 延迟直方图\n4\n慢操作捕获\ndemo-slow\n超阈值操作实时列表 + BPF 丢失率\n5\nJSON 导出\n--json / --json --histogram\n标准 JSON + 直方图融合输出\n每个步骤包含：\n宿主机直接运行命令 + Docker 运行命令\n真实终端输出（2026-05-02 CKB v0.204.0 测试网节点）\n输出解读说明\n附录包含：\n附录 A/B/C：48h 稳定性 / Case Study / P-1~P-4 结果摘要\n附录 D：Docker 构建指南 + 通用运行模板 + 六个 Demo 的 Docker 命令与实际输出 + 三项长时间测试的 Docker 命令\n4.2 Docker 内六个 Demo 执行结果\n所有 Demo 均在 Docker 容器中实际执行并记录了真实输出：\nDemo\n命令\n关键结果\ndemo-check\nckb-probe:latest demo-check\n6/8 环境检查通过，15/19 Tier 1 符号可挂载，264 uprobe + 40 tcp + 438 syscall 事件\ndemo-table\nckb-probe:latest demo-table 60\nGET 93~177 QPS，PUT 8 QPS，TXN_COMMIT 326us\ndemo-histogram\nckb-probe:latest demo-histogram 60\nGET 双峰分布：主峰 4~32us，尾部 4~33ms\ndemo-slow\nckb-probe:latest demo-slow 60 1000\n157 个慢操作，最大 50,378us，BPF 丢失 0/157\ndemo-normal\nckb-probe:latest demo-normal 60\nJSON 快照输出，保存到 demo-normal-snapshot.json\ndemo-stress\nckb-probe:latest demo-stress 50000\n128 个慢操作，BPF 丢失 0/215，磁盘 headroom 充裕未触发 ANOMALY\n五、Clippy 修复\nCI 中 cargo clippy -- -D warnings 报出 manual_checked_ops 警告（Rust 1.95.0 新增 lint）：\nerror: manual checked division\n--> ckb-probe/src/commands/rocksdb.rs:814\n--> ckb-probe/src/commands/symbols.rs:572\n修复：将手动 if d == 0 { 0 } else { n / d } 模式改为 n.checked_div(d).unwrap_or(0)。\n六、交付物清单\n文件\n说明\ndocs/demo-walkthrough_zh.md\n五步演示 + Docker 指南 + 六个 Demo 实际输出\nckb-probe/src/commands/rocksdb.rs\nJSON --histogram 融合输出 + clippy 修复\nckb-probe/src/commands/symbols.rs\nclippy 修复\n六、后续计划\nWeek 8：发布与结项\n中英双语文档定稿 — 各类文档最终审校\nGitHub v0.1.0 Release — 打 tag、写 release notes、附带预编译 binary\n结项报告 — 按 main_proj.md 规范整理全部交付物、验收清单、已知限制\n社区分享 — 最终月度报告提交", "content_html": "

Week 7 周报：JSON 全局输出优化 + 演示说明文档

\n
\n

周期：2026-04-27 ~ 2026-05-03
\n作者：Clair
\n项目：ckb-probe — 基于 eBPF 的 CKB 全节点深度可观测性工具

\n
\n
\n

一、本周目标

\n
    \n
  1. JSON 全局输出 — 确保所有模式的 JSON 输出格式统一、字段完整
    2. \n
  2. 制作完整演示说明文档 — 结构化的文字演示报告（Markdown），覆盖五个演示流程步骤，附完整终端输出和说明
    3. \n
\n
\n

二、完成情况

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
交付项状态说明
JSON --histogram 融合输出\":white_check_mark:\"--json --histogram 联用时 JSON 包含 log2 延迟分布
JSON 输出字段文档化\":white_check_mark:\"全部字段含义、类型、取值范围写入演示文档
演示说明文档（中文）\":white_check_mark:\"五步流程 + 真实终端输出 + 解读 + Docker 构建与运行指南
Docker 构建指南\":white_check_mark:\"镜像构建、通用模板、卷挂载/权限说明
Docker 六个 Demo 实际运行\":white_check_mark:\"全部在 Docker 容器内执行并记录真实输出
Docker 长时间测试命令\":white_check_mark:\"48h 稳定性 / Case 1 / Case 2 / P-1~P-4 的完整 Docker 命令
Clippy 修复\":white_check_mark:\"manual_checked_ops 警告，改用 checked_div()
\n
\n

三、JSON 全局输出优化

\n

3.1 现有 JSON 输出模式

\n

ckb-probe 提供两种 JSON 输出：

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
模式命令内容
RocksDB 监控rocksdb --json每周期输出操作统计 + 异常事件
符号分析symbols --json完整的 ELF 符号分析报告
\n

3.2 本周改进：--json --histogram 融合

\n

改进前： --json 和 --histogram 为独立分支，--json 模式下直方图数据被忽略。

\n

改进后： --json --histogram 联用时，每个操作的 JSON 对象中增加 histogram 字段，包含非零 log2 桶的延迟分布：

\n
{\n  \"operations\": {\n    \"GET\": {\n      \"qps\": 845,\n      \"avg_us\": 24.97,\n      \"p50_us\": 24.58,\n      \"p99_us\": 98.30,\n      \"bytes_per_sec\": 101976,\n      \"histogram\": [\n        { \"ge_us\": 1.02, \"count\": 40 },\n        { \"ge_us\": 4.1, \"count\": 1528 },\n        { \"ge_us\": 8.19, \"count\": 421 },\n        { \"ge_us\": 16.38, \"count\": 727 },\n        { \"ge_us\": 32.77, \"count\": 125 },\n        { \"ge_us\": 65.54, \"count\": 22 }\n      ]\n    }\n  }\n}\n
\n

设计决策：

\n
    \n
  • 仅在 --histogram 显式启用时输出 histogram 字段，避免默认 JSON 体积膨胀
    • \n
  • 仅输出非零桶（count > 0），稀疏表示，典型场景下每操作 5~15 个桶
    • \n
  • ge_us 表示该桶的下界（微秒），对应 2^i 纳秒转换
    • \n
  • 不影响已有 JSON 消费者（新增字段，向后兼容）
    • \n
\n

3.3 JSON 字段完整性审计

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
字段类型说明模式
timestampstringISO 8601 UTCrocksdb --json
pidnumber目标进程 PIDrocksdb --json
uptime_secsnumber运行时长（秒）rocksdb --json
operationsobject五个操作的指标rocksdb --json
operations.*.qpsnumber每秒操作数rocksdb --json
operations.*.avg_usnumber平均延迟（微秒）rocksdb --json
operations.*.p50_usnumberP50 延迟（微秒）rocksdb --json
operations.*.p99_usnumberP99 延迟（微秒）rocksdb --json
operations.*.bytes_per_secnumber|null吞吐量（B/s）rocksdb --json
operations.*.histogramarraylog2 延迟分布rocksdb --json --histogram
anomaliesarrayEWMA 异常事件rocksdb --json
anomalies.*.timestring相对时间rocksdb --json
anomalies.*.typestring固定 “latency_spike”rocksdb --json
anomalies.*.operationstring操作名rocksdb --json
anomalies.*.triggerstring触发条件组合rocksdb --json
anomalies.*.current_avg_usnumber当前均值rocksdb --json
anomalies.*.baseline_avg_usnumber基线均值rocksdb --json
anomalies.*.multipliernumber偏离倍数rocksdb --json
anomalies.*.current_p99_usnumber当前 P99rocksdb --json
anomalies.*.baseline_p99_usnumber基线 P99rocksdb --json
\n

所有数值保留 2 位小数（round2()），bytes_per_sec 对 WRITE/ITER_NEW 为 null。

\n
\n

四、演示说明文档

\n

已创建 docs/demo-walkthrough_zh.md，覆盖五个完整演示步骤：

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
步骤演示对应命令内容
1环境检查check / demo-checkeBPF 环境验证 + 符号分析
2符号分析symbolsTier 1/2/3 符号分类 + 覆盖率
3实时监控demo-table / demo-histogram表格 + 延迟直方图
4慢操作捕获demo-slow超阈值操作实时列表 + BPF 丢失率
5JSON 导出--json / --json --histogram标准 JSON + 直方图融合输出
\n

每个步骤包含：

\n
    \n
  • 宿主机直接运行命令 + Docker 运行命令
    • \n
  • 真实终端输出（2026-05-02 CKB v0.204.0 测试网节点）
    • \n
  • 输出解读说明
    • \n
\n

附录包含：

\n
    \n
  • 附录 A/B/C：48h 稳定性 / Case Study / P-1~P-4 结果摘要
    • \n
  • 附录 D：Docker 构建指南 + 通用运行模板 + 六个 Demo 的 Docker 命令与实际输出 + 三项长时间测试的 Docker 命令
    • \n
\n

4.2 Docker 内六个 Demo 执行结果

\n

所有 Demo 均在 Docker 容器中实际执行并记录了真实输出：

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
Demo命令关键结果
demo-checkckb-probe:latest demo-check6/8 环境检查通过，15/19 Tier 1 符号可挂载，264 uprobe + 40 tcp + 438 syscall 事件
demo-tableckb-probe:latest demo-table 60GET 93~177 QPS，PUT 8 QPS，TXN_COMMIT 326us
demo-histogramckb-probe:latest demo-histogram 60GET 双峰分布：主峰 4~32us，尾部 4~33ms
demo-slowckb-probe:latest demo-slow 60 1000157 个慢操作，最大 50,378us，BPF 丢失 0/157
demo-normalckb-probe:latest demo-normal 60JSON 快照输出，保存到 demo-normal-snapshot.json
demo-stressckb-probe:latest demo-stress 50000128 个慢操作，BPF 丢失 0/215，磁盘 headroom 充裕未触发 ANOMALY
\n
\n

五、Clippy 修复

\n

CI 中 cargo clippy -- -D warnings 报出 manual_checked_ops 警告（Rust 1.95.0 新增 lint）：

\n
error: manual checked division\n  --> ckb-probe/src/commands/rocksdb.rs:814\n  --> ckb-probe/src/commands/symbols.rs:572\n
\n

修复：将手动 if d == 0 { 0 } else { n / d } 模式改为 n.checked_div(d).unwrap_or(0)。

\n
\n

六、交付物清单

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
文件说明
docs/demo-walkthrough_zh.md五步演示 + Docker 指南 + 六个 Demo 实际输出
ckb-probe/src/commands/rocksdb.rsJSON --histogram 融合输出 + clippy 修复
ckb-probe/src/commands/symbols.rsclippy 修复
\n
\n

六、后续计划

\n

Week 8：发布与结项

\n
    \n
  1. 中英双语文档定稿 — 各类文档最终审校
    2. \n
  2. GitHub v0.1.0 Release — 打 tag、写 release notes、附带预编译 binary
    3. \n
  3. 结项报告 — 按 main_proj.md 规范整理全部交付物、验收清单、已知限制
    4. \n
  4. 社区分享 — 最终月度报告提交
    5. \n
", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10225, "title": "iCKB Contracts Revisited: Old Code, New Audit", "slug": "ickb-contracts-revisited-old-code-new-audit", "url": "https://talk.nervos.org/t/ickb-contracts-revisited-old-code-new-audit/10225", "created_at": "2026-05-02T00:36:46.351000+00:00", "last_posted_at": "2026-05-02T01:33:02.680000+00:00", "category_id": 32, "tags": [], "posters": [ "Original Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24104, "post_number": 1, "topic_id": 10225, "topic_title": "iCKB Contracts Revisited: Old Code, New Audit", "topic_slug": "ickb-contracts-revisited-old-code-new-audit", "author": "phroi", "created_at": "2026-05-02T00:36:46.460000+00:00", "updated_at": "2026-05-02T00:36:46.460000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/ickb-contracts-revisited-old-code-new-audit/10225/1", "content_text": "This post mirrors the original security review report published in ickb/contracts: any question or feedback is more than welcomed\nReview completion date: 2026-05-01.\nReviewed contracts commit: 454cfa9. This is the last commit that changed scripts/contracts/** or scripts/Cargo.toml.\nExecutable test evidence: current scripts/tests/** suite in this repository state.\nScope: iCKB Logic, Owned Owner, Limit Order, and the shared utils crate.\nCross-references: the iCKB whitepaper and Nervos L1 reference implementations.\nPrior external audit: Scalebit (2024-09-10). That audit reported three issues: two informational and one minor.\nExecutive Summary\nUnder the current deployment assumptions, the review confirmed one live issue: the known Limit Order confusion attack.\niCKB Logic has a provenance-blind path: receiptless DAO-shaped outputs can later be treated as deposits, and a separately funded aggregate-deposit path can realize the split-vs-aggregate soft-cap spread.\nEven so, the current iCKB Logic tests do not show theft, duplicated principal, or a standalone profit path beyond assets the caller already controls.\nLimit Order remains vulnerable to phantom-order continuation, real-order stranding through fake match-state cells, and master rebinding when cloned or otherwise indistinguishable orders are cross-wired at mint or during match.\nOwned Owner preserves its pairing rules under the current whole-transaction-binding lock model; the remaining weak-lock claim-reassignment cases stay at the integration boundary.\nAll other candidate issues are blocked paths, generic CKB model constraints, or boundary cases relevant only to future integrations.\nFindings Summary\nOne known live issue remains in scope.\nID\nStatus\nComponent\nFinding\nLO-01\nKnown\nLimit Order\nCKB does not execute output locks at creation time, and limit_order accepts swapped mint pairings, so phantom and cross-wired order/master lineages can survive into later match or melt flows.\nProtocol Model and Assumptions\nThe component analyses below rely on the following protocol model and deployment assumptions.\niCKB is an inflation-protected CKB token (xUDT) that tokenizes NervosDAO deposits into a liquid, fungible asset. The protocol owns all CKB deposits in a shared pool. Users deposit CKB and receive iCKB; later, they can burn iCKB to withdraw from any mature deposit in that pool.\nThree on-chain scripts govern that flow:\niCKB Logic (dual-role): lock script on deposit cells, type script on receipt cells. Enforces the core balance equation and deposit-receipt accounting.\nOwned Owner: pairs withdrawal request cells with owner cells so users can claim NervosDAO phase 2 withdrawals.\nLimit Order: enables order-book-style exchange between CKB and UDTs, abstracting over NervosDAO and iCKB protocol constraints.\nKey Flows\nDeposit (two phases):\nPhase 1: CKB locked into NervosDAO deposit cells (lock = iCKB Logic, type = DAO). Receipts (type = iCKB Logic) track the deposits.\nPhase 2: Receipts converted to iCKB xUDT tokens using the deposit block’s accumulated rate (AR).\nWithdrawal:\nPhase 1: iCKB burned to release deposits from the pool into NervosDAO withdrawal requests.\nPhase 2: Standard NervosDAO withdrawal (outside iCKB scope).\nMixed transactions: A single transaction can combine deposit phase 1, phase 2, and withdrawal operations.\nThe next four execution rules explain why later findings hold or fail.\nScript Grouping\nMixed transactions execute iCKB Logic twice, but both runs see the same global cells and apply the same checks, so the dual execution does not create a desync path. CKB groups scripts by both hash and role. From script/src/types.rs:179-180:\nA cell can have a lock script and an optional type script. Even they reference the same script, lock script and type script will not be grouped together.\nLock groups and type groups are stored in separate BTreeMaps (types.rs:657-659). iCKB Logic uses the same {code_hash, Data1, empty_args} for both roles, so a mixed transaction produces one lock group for deposit cells and one type group for receipt cells.\nBoth groups still see the same global cell set (Source::Input and Source::Output, not group-local sources) and apply the same balance checks, so duplicate execution does not create a path where one run succeeds and the other fails.\nScript group construction at types.rs:716-740: lock groups are built from input locks only; type groups are built from both input and output types.\nxUDT Owner Mode\nxUDT owner mode stays within iCKB accounting because, in the deployed configuration, only two owner-mode routes are live and both co-execute iCKB Logic.\niCKB xUDT args are built as [ickb_logic_hash, XUDT_ARGS_FLAGS] with XUDT_ARGS_FLAGS = 0x80000000.\nRFC 0052’s owner-mode update has four triggers: matching input lock, matching input type, matching output type, and a witness owner_script whose hash matches the owner hash in args.\nIn the deployed configuration, the upstream xudt_rce.c flag parsing enables input lock by default, enables input type when flags & 0x80000000 is non-zero, and enables output type only when flags & 0x40000000 is non-zero. It also falls back to the witness owner_script path.\nThe witness owner_script path requires an exported validate symbol loaded via ckb_dlsym, while iCKB Logic is built as a CKB entrypoint (program_entry via ckb_std::entry!), not an xUDT validate extension. Under iCKB’s deployed args [ickb_logic_hash, 0x80000000], the live owner-mode paths are:\nA receipt (input type = iCKB Logic): needed for phase 2 minting\nA deposit (input lock = iCKB Logic): fires during withdrawal\nIn both cases iCKB Logic co-executes, as a type script for receipts or a lock script for deposits. Under this design, xUDT cannot enter owner mode without iCKB Logic also running.\nNervosDAO Interaction\nThe deposit phase 1 section of the iCKB whitepaper pins NervosDAO to the historical 814eb82 dao.c. That version enforces the known 64-output-cell limit with an output_withdrawing_mask bitset. iCKB inherits that as a platform constraint, but its own correctness does not depend on the limit.\nKey NervosDAO constraints confirmed against the whitepaper-pinned dao.c:\nWithdrawal request must be at the same output index as the consumed deposit.\nWithdrawal request capacity must equal the deposit capacity.\nWithdrawal request lock is not checked by validate_withdrawing_cell, but current CKB nodes still apply the DaoScriptSizeVerifier, so the withdrawing lock must at least match the consumed deposit lock’s serialized size.\nAR is read from deposit_data.dao[8], matching iCKB’s AR_OFFSET = 160 + 8.\nHeader Access\nHeader access explains why iCKB uses a two-phase deposit flow. From script/src/syscalls/load_header.rs:\nFor Source::Input: returns the header of the block containing the cell’s creation transaction. The block hash must appear in header_deps.\nFor Source::Output: always returns INDEX_OUT_OF_BOUND (load_header.rs:80). Deposits require two phases.\nTwo shared boundaries matter in the later sections: authorization and accounting.\nAuthorization Boundary\nSeveral candidate issues turn on the boundary between lock-script authorization and type-script accounting. The lock script / type script split means ownership is enforced by the user lock, while ickb_logic enforces value conservation. Its balance equation and cell classification never inspect who receives the output iCKB or the phase-1 DAO claim.\nUnder the current whole-transaction-binding user-lock assumption, that division is acceptable because the user’s signature commits to the full transaction. The deployment model used for this review assumes current user-facing iCKB flows use strong transaction-binding locks and does not treat delegated or adopted OTX flows as in-scope present-day integrations.\nThe weak-lock tests in this report do not replay a current wallet path. They model future or custom delegated, OTX, or other non-output-binding integrations, where recipient binding is an integration invariant rather than a guarantee provided by the iCKB contracts.\nExecuted regressions show why that stays a boundary case rather than a current finding:\nWeak-lock behavior: Recipient reassignment is possible in both iCKB Logic and Owned Owner. The phase-2 weak-lock redirect test and the withdrawal weak-lock redirect test demonstrate that weak-lock path.\nSigned phase-2 minting: Once sighash binds the full transaction, phase-2 redirects stop working. The phase-2 sighash binding test and the mixed phase-2 sighash binding test show that binding.\nSigned withdrawals: The same redirect pattern fails for withdrawal outputs once sighash binds the transaction. The withdrawal sighash binding test and the mixed withdrawal sighash binding test show the same result.\nWitness binding: The input-group signing test and the full-witness signing test confirm the witness-binding model used by the signed path.\nThe same ancillary scripts section already warns that delegated and OTX ownership patterns have their own pitfalls.\nAccounting Basis and Build Setting\nThe main accounting claims in this report rest on three properties:\nBalance equation: entry.rs:32 enforces in_udt + in_receipts == out_udt + in_deposits.\nDeposit-receipt accounting: entry.rs:132-137 requires deposited == receipted per amount bucket.\nOverflow checks: overflow-checks = true keeps the release-build accumulators from silently wrapping.\nTogether, these preserve protocol accounting across deposit, conversion, withdrawal, and mixed transactions.\nScope and Methodology\nThis section pins the reviewed sources and the checks behind the conclusions.\nReference Repositories\nRepository\nCommit\nickb/contracts\n454cfa9\nickb/whitepaper\ncdbabf6\nnervosnetwork/ckb\n6730f80\nnervosnetwork/ckb-system-scripts\n814eb82\nnervosnetwork/ckb-production-scripts\n26b0b4f\nnervosnetwork/rfcs\n4b502ff\nMethodology\nThe review prioritized executable behavior over static plausibility and classified issues by their concrete impact.\nReviewed the deployed release binaries and the transaction semantics they actually enforce, not just the latest source-level intent.\nReproduced script behavior locally with ckb-testtool, using executable transaction tests rather than relying on inspection alone.\nReused and extended the existing test suite, including replayed transaction shapes from observed protocol flows.\nComputed NervosDAO accounting with the exact DAO withdrawal math before classifying any claim-path discrepancy as a finding.\nSeparated findings that affect the current deployment from weak-lock assumptions, operator mistakes, or broader integration-only scenarios.\nRemoved or downgraded candidate issues that did not yield a harmful state transition, exploitable profit path, or realistic user loss.\nExplicitly tested mixed transactions and script-group interactions because iCKB safety depends on whole-transaction execution rather than isolated cell intent.\nTest Coverage\nA module wiring overview plus the test layout note show three layers:\nTest harness and utilities: root harness, fixtures, encoders, signing, and replay_helpers.\nScenario suite roots: ickb_logic, owned_owner, limit_order, and replay, each wiring topic-focused files under the matching subdirectory.\nHelper-focused unit coverage: helpers, which checks the shared encoders and witness/data builders used by the larger suites.\nA fresh cargo test -p tests run passed 214 tests with no failures. Those tests cover deployment-hash sanity checks, helper encodings, core flows, blocked-path regressions, and replayed transaction shapes across iCKB Logic, Owned Owner, and Limit Order.\nThe strong-lock regressions in ickb_logic, owned_owner, and signing replay secp256k1_blake160_sighash_all as the representative whole-transaction-binding lock. This repo does not include a QRL fixture or harness, so conclusions for other strong-lock deployments rely on the same binding property and the stated deployment assumptions rather than a separate in-repo replay.\nLimit Order\nThe deployed Limit Order binary still carries one live issue: the known confusion attack. No other candidate path in this component validates as a live issue.\nDesign\nLimit Order supports three operations: Mint (create order plus master), Match (partial or full fill), and Melt (destroy order plus master). Orders store exchange ratios (ckb_to_udt, udt_to_ckb) and a minimum match size.\nKey Validations\nValue conservation (entry.rs:103-105): uses C256 (checked U256) to prevent overflow.\nif i.ckb * ckb_mul + i.udt * udt_mul > o.ckb * ckb_mul + o.udt * udt_mul\nConcave ratio check (entry.rs:233-235): ensures round-trip conversion doesn’t lose value for the maker:\nif c2u.ckb_mul * u2c.udt_mul < c2u.udt_mul * u2c.ckb_mul\nMinimum match enforcement (entry.rs:108-129): prevents dust-level partial matches.\nStrict data length on execution (entry.rs:166): when limit_order executes, order data must be exactly UDT_SIZE + ORDER_SIZE bytes, so trailing data fails validation.\nAssessment\nExecuted tests confirm several live confusion manifestations under the current deployment assumptions, and separate tests bound the rebinding path.\nID\nStatus\nFinding\nLO-01\nKnown\nCKB does not execute output locks at creation time, and limit_order’s mint branch accepts swapped mint pairings, so mint-time output creation can seed phantom or cross-wired order/master lineages that later pass match or melt validation.\nConfirmed live manifestations:\nPhantom orders can be created without master validation: the phantom mint creation test.\nThat phantom lineage can then enter and keep advancing through fake match state without a real master: the phantom mint continuation test and the fake match lineage continuation test.\nA fake match-shaped order can melt against a real master and strand the real order: the real-order stranding test.\nCross-wired or cloned orders can rebind masters at mint or during match: the mint crosswire test and the cloned-order master-swap test.\nThe cloned-order continuation is reproduced with secp256k1_blake160_sighash_all-protected masters, so the live path is not a weak-lock-only artifact: the cloned-order master-swap test.\nBounding evidence: separate tests show that the rebinding path is narrower than arbitrary master rewriting:\nDiffering mint capacities and differing match progress both block cross-wiring: the distinct mint-capacity crosswire block test and the distinct match-progress crosswire block test.\nEven real orders fail to cross-wire arbitrarily, whether the checked info matches or differs: the same-info real-order crosswire block test and the different-info mainnet crosswire block test.\nThe UDT → CKB zero-UDT fulfilled-order shape still fails at the outer InvalidMatch check rather than surfacing a dedicated fulfilled-order guard.\niCKB Logic\nThe deployed iCKB Logic binary is provenance-blind at cell classification, but once a cell is inside the scripted flow it still preserves receipt and xUDT accounting. The subsections below explain both properties and why the currently executed provenance-blind paths still stop short of a confirmed theft or profit finding.\nCore Invariant\nentry.rs:32:\nif in_udt_ickb + in_receipts_ickb != out_udt_ickb + in_deposits_ickb {\nreturn Err(Error::AmountMismatch);\n}\nThis equation is the core accounting invariant across all flows:\nDeposit phase 1: 0 + 0 == 0 + 0 (deposits and receipts handled by accounting check only)\nDeposit phase 2: 0 + receipt_value == out_udt + 0\nWithdrawal: in_udt + 0 == out_udt + deposit_value\nMixed: any combination\nCell Classification\ncelltype.rs:60-82 classifies every cell in the transaction by examining lock and type script hashes, plus the DAO data shape when the DAO hash is present:\nLock\nType\nClassification\nLine\niCKB Logic\nDAO deposit (8 zero bytes)\nDeposit\nL69\niCKB Logic\nanything else\nScriptMisuse (error)\nL72\nother\niCKB Logic\nReceipt\nL75\nother\niCKB xUDT\nUdt\nL78\nDAO deposit (8 zero bytes) as lock\nany\nScriptMisuse (error)\nL62\niCKB xUDT as lock\nany\nScriptMisuse (error)\nL63\nother\nother\nUnknown (ignored)\nL81\nScriptType::None is only synthesized for missing type scripts; script_type() never returns None for locks, so the (ScriptType::None, _) arm is unreachable. NervosDAO withdrawal requests, which have non-zero data, correctly classify as Unknown via is_deposit_data.\nDeposit-Receipt Accounting (check_output)\nentry.rs:86-140 uses a BTreeMap to ensure every group of same-sized output deposits is matched by equal receipt counts.\nOutput deposit: extract_unused_capacity → keyed by amount, deposited += 1\nOutput receipt: extract_receipt_data → keyed by deposit_amount, receipted += quantity\nFinal check at entry.rs:132-137: all entries must have deposited == receipted\nIt also validates:\nDeposits: 1000 CKB <= unoccupied_capacity <= 1M CKB (entry.rs:101-106, bounds at constants.rs:5-6)\nReceipts: deposit_quantity > 0 (entry.rs:114-116)\nUDT: amount <= u64::MAX (entry.rs:123-125)\niCKB Conversion (deposit_to_ickb)\nentry.rs:71-84 uses the same conversion for minting and withdrawal:\nlet ickb_amount = amount * ar_0 / ar_m;\nif ickb_amount > ICKB_SOFT_CAP_PER_DEPOSIT {\nreturn Ok(ickb_amount - (ickb_amount - ICKB_SOFT_CAP_PER_DEPOSIT) / 10);\n}\nDivision by zero: impossible (the RFC 0023 accumulated-rate rule sets AR_0 = 10 ^ 16 and AR_i = AR_{i-1} + floor(AR_{i-1} * s_i / C_{i-1}), so AR_m is non-zero).\nOverflow: u64 * u128 fits in u128 (~1.8e19 * 1e16 = ~1.8e35 < 3.4e38).\nPrecision: integer division loses at most 1 shannon per operation.\nFee/discount symmetry: the same function is used for both input receipts (fee, entry.rs:58-59) and input deposits (discount, entry.rs:52). The protocol breaks even: minted amount = burned amount.\nhas_empty_args Validation\nCell identification relies on the exact deployed script hash. utils/utils.rs:14-36 enforces empty args on:\nThe current script instance (covers input lock, input type, output type via CKB’s execution model)\nAll output locks matching the same code_hash + hash_type (utils.rs:29-31)\nOutput types don’t need explicit checking because they trigger execution and self-validate.\nAssessment\niCKB Logic has one state-admission blind spot plus several boundary points:\nProvenance blind spot: Receiptless DAO-shaped outputs can be admitted at output-lock creation time because CKB does not execute output locks, and later treated as pool deposits because cell_type_iter classifies any ickb_logic-locked, DAO-typed, deposit-data input as Deposit with no receipt-provenance check. The receiptless deposit-admission test confirms that admission-plus-later-classification path.\nAccepted spread path is still self-funded: When a separately provided split receipt is paired against a self-funded receiptless aggregate deposit, the contract accepts minting only the soft-cap valuation delta rather than the aggregate principal. The delta-only spread test and the oversized spread test show the accepted spread, while the deposit-alone spread block test blocks the deposit-alone variant.\nOrdinary mixed flows still apply the soft cap per receipt: The mixed phase1-phase2 soft-cap test shows that adding fresh phase-1 deposits in the same transaction does not turn this into a general aggregate soft-cap bypass.\nExecuted path limit: The narrowing comment in the phase-2 claim test and the self-funded principal claim test make the current limit explicit: the self-funded aggregate principal remains claimable in DAO phase 2, so the executed path does not show third-party principal theft or duplicated recovery.\nPrefix behavior: Trailing bytes in receipt and xUDT data reflect prefix-based parsing, while truncated encodings are still rejected. The receipt trailing-bytes tests, truncated receipt tests, and trailing/short xUDT output-data tests cover that behavior.\nWeak-lock boundary: Recipient-redirection scenarios remain boundary cases and do not apply under the current whole-transaction-binding user-lock assumption.\nRounding: Whole-CKB rounding claims remain false leads. The rounding mint test and the rounding withdrawal test fail unless exact shannon precision is used.\nOn current executable evidence, that provenance-blind path is real, but it still falls short of a confirmed theft or standalone profit finding.\nOwned Owner\nThe deployed Owned Owner binary preserves its pairing invariant under the current assumptions. The remaining questions concern which cells can be paired and who controls the pair at creation time.\nDesign\nOwned Owner pairs owned cells, namely NervosDAO withdrawal requests, with owner cells through a MetaPoint derived from the owner cell’s owned_distance field:\nMint: the owner cell stores a signed distance to the owned cell, so owned_index == owner_index + owned_distance.\nMelt: both cells must be consumed together.\nValidation\nFor inputs and outputs separately, the script enforces the same pairing rules:\nEach metapoint must have exactly owned == 1 and owner == 1 (entry.rs:57-60).\nOwned cells must be NervosDAO withdrawal requests: DAO type + non-zero data (entry.rs:45-47).\nA cell using the script as both lock and type is rejected (entry.rs:53).\nAssessment\nOwned Owner leaves four boundary points. The live claim-rotation path stays blocked in the currently modeled flows:\nLive claim rotation remains blocked: Attempts to roll a live claim into fresh Owned Owner pairs or to crosswire a fully DAO-constrained batch are rejected before a new live pairing survives. The fresh-pair rotation block test, new-pair rotation block test, and the DAO index-rule crosswire block test show that block.\nCrosswired later-claim ownership still depends on weak phase-1 authorization: When phase-1 owner outputs use weak or otherwise non-output-binding locks, later DAO claims can be reassigned across mixed foreign-plus-iCKB batches or fully iCKB batches. The mixed foreign-plus-iCKB weak-lock crosswire test, two-way weak-lock crosswire claim test, and three-way weak-lock crosswire claim test show that boundary case. Under the current strong-lock deployment assumption, this is not a present finding.\nForeign DAO withdrawal wrapping is allowed: The foreign DAO wrapping test shows that any DAO withdrawal request can be wrapped and later claimed, because the script checks only DAO type plus withdrawal-shaped data on the owned cell.\nCreator-side dead states are narrower than arbitrary malformed pairs: When Owned Owner actually executes as a type script, it rejects orphan and count-mismatch shapes, as shown by the orphan-owner rejection test and the two-owner mismatch test. But creation still accepts pairs whose owner lock never validated, as shown by the unspendable foreign-owner-lock test and the limit-order owner-lock stranding test. It also allows lock-only Owned Owner look-alikes that later fail on spend, as shown by the lock-only non-DAO look-alike test and the lock-only DAO-deposit look-alike test.\nDeployment Context and Documented Risks\nWitness Malleability (Documented)\nWitness malleability is a documented property, not a new finding. All three scripts use the script-as-lock (unsigned) plus script-as-type (controller) pattern, and none of them reads witnesses.\nThe whitepaper states the consequence directly: “if a script in a transaction needs to store data in the witness and this data can be tampered without the transaction becoming invalid, then this transaction must not employ the scripts presented in the current whitepaper.”\nNon-Upgradable Deployment\nDeployment is intentionally non-upgradable. The whitepaper’s non-upgradable deployment section says the scripts are deployed by data1, not by type, so they are non upgradable. Additionally, secp256k1_blake160 zero lock controls the binary.\nAny post-deployment bug requires migration to entirely new script deployments and a new dep group.\nConclusion\nUnder the current deployment assumptions, only the known Limit Order confusion attack remains live.\nThe iCKB Logic provenance-blind path exists, but the executed tests still stop at a self-funded edge case.\nThe remaining Owned Owner and cross-script cases are blocked or confined to integration/deployment boundaries.", "content_html": "

This post mirrors the original security review report published in ickb/contracts: any question or feedback is more than welcomed \":hugs:\"

\n
    \n
  • Review completion date: 2026-05-01.
    • \n
  • Reviewed contracts commit: 454cfa9. This is the last commit that changed scripts/contracts/** or scripts/Cargo.toml.
    • \n
  • Executable test evidence: current scripts/tests/** suite in this repository state.
    • \n
  • Scope: iCKB Logic, Owned Owner, Limit Order, and the shared utils crate.
    • \n
  • Cross-references: the iCKB whitepaper and Nervos L1 reference implementations.
    • \n
  • Prior external audit: Scalebit (2024-09-10). That audit reported three issues: two informational and one minor.
    • \n
\n

Executive Summary

\n

Under the current deployment assumptions, the review confirmed one live issue: the known Limit Order confusion attack.

\n
    \n
  • iCKB Logic has a provenance-blind path: receiptless DAO-shaped outputs can later be treated as deposits, and a separately funded aggregate-deposit path can realize the split-vs-aggregate soft-cap spread.
    • \n
  • Even so, the current iCKB Logic tests do not show theft, duplicated principal, or a standalone profit path beyond assets the caller already controls.
    • \n
  • Limit Order remains vulnerable to phantom-order continuation, real-order stranding through fake match-state cells, and master rebinding when cloned or otherwise indistinguishable orders are cross-wired at mint or during match.
    • \n
  • Owned Owner preserves its pairing rules under the current whole-transaction-binding lock model; the remaining weak-lock claim-reassignment cases stay at the integration boundary.
    • \n
  • All other candidate issues are blocked paths, generic CKB model constraints, or boundary cases relevant only to future integrations.
    • \n
\n

Findings Summary

\n

One known live issue remains in scope.

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
IDStatusComponentFinding
LO-01KnownLimit OrderCKB does not execute output locks at creation time, and limit_order accepts swapped mint pairings, so phantom and cross-wired order/master lineages can survive into later match or melt flows.
\n

Protocol Model and Assumptions

\n

The component analyses below rely on the following protocol model and deployment assumptions.

\n

iCKB is an inflation-protected CKB token (xUDT) that tokenizes NervosDAO deposits into a liquid, fungible asset. The protocol owns all CKB deposits in a shared pool. Users deposit CKB and receive iCKB; later, they can burn iCKB to withdraw from any mature deposit in that pool.

\n

Three on-chain scripts govern that flow:

\n
    \n
  1. iCKB Logic (dual-role): lock script on deposit cells, type script on receipt cells. Enforces the core balance equation and deposit-receipt accounting.
    2. \n
  2. Owned Owner: pairs withdrawal request cells with owner cells so users can claim NervosDAO phase 2 withdrawals.
    3. \n
  3. Limit Order: enables order-book-style exchange between CKB and UDTs, abstracting over NervosDAO and iCKB protocol constraints.
    4. \n
\n

Key Flows

\n

Deposit (two phases):

\n
    \n
  • Phase 1: CKB locked into NervosDAO deposit cells (lock = iCKB Logic, type = DAO). Receipts (type = iCKB Logic) track the deposits.
    • \n
  • Phase 2: Receipts converted to iCKB xUDT tokens using the deposit block’s accumulated rate (AR).
    • \n
\n

Withdrawal:

\n
    \n
  • Phase 1: iCKB burned to release deposits from the pool into NervosDAO withdrawal requests.
    • \n
  • Phase 2: Standard NervosDAO withdrawal (outside iCKB scope).
    • \n
\n

Mixed transactions: A single transaction can combine deposit phase 1, phase 2, and withdrawal operations.

\n

The next four execution rules explain why later findings hold or fail.

\n

Script Grouping

\n

Mixed transactions execute iCKB Logic twice, but both runs see the same global cells and apply the same checks, so the dual execution does not create a desync path. CKB groups scripts by both hash and role. From script/src/types.rs:179-180:

\n
\n

A cell can have a lock script and an optional type script. Even they reference the same script, lock script and type script will not be grouped together.

\n
\n

Lock groups and type groups are stored in separate BTreeMaps (types.rs:657-659). iCKB Logic uses the same {code_hash, Data1, empty_args} for both roles, so a mixed transaction produces one lock group for deposit cells and one type group for receipt cells.

\n

Both groups still see the same global cell set (Source::Input and Source::Output, not group-local sources) and apply the same balance checks, so duplicate execution does not create a path where one run succeeds and the other fails.

\n

Script group construction at types.rs:716-740: lock groups are built from input locks only; type groups are built from both input and output types.

\n

xUDT Owner Mode

\n

xUDT owner mode stays within iCKB accounting because, in the deployed configuration, only two owner-mode routes are live and both co-execute iCKB Logic.

\n

iCKB xUDT args are built as [ickb_logic_hash, XUDT_ARGS_FLAGS] with XUDT_ARGS_FLAGS = 0x80000000.

\n

RFC 0052’s owner-mode update has four triggers: matching input lock, matching input type, matching output type, and a witness owner_script whose hash matches the owner hash in args.

\n

In the deployed configuration, the upstream xudt_rce.c flag parsing enables input lock by default, enables input type when flags & 0x80000000 is non-zero, and enables output type only when flags & 0x40000000 is non-zero. It also falls back to the witness owner_script path.

\n

The witness owner_script path requires an exported validate symbol loaded via ckb_dlsym, while iCKB Logic is built as a CKB entrypoint (program_entry via ckb_std::entry!), not an xUDT validate extension. Under iCKB’s deployed args [ickb_logic_hash, 0x80000000], the live owner-mode paths are:

\n
    \n
  • A receipt (input type = iCKB Logic): needed for phase 2 minting
    • \n
  • A deposit (input lock = iCKB Logic): fires during withdrawal
    • \n
\n

In both cases iCKB Logic co-executes, as a type script for receipts or a lock script for deposits. Under this design, xUDT cannot enter owner mode without iCKB Logic also running.

\n

NervosDAO Interaction

\n

The deposit phase 1 section of the iCKB whitepaper pins NervosDAO to the historical 814eb82 dao.c. That version enforces the known 64-output-cell limit with an output_withdrawing_mask bitset. iCKB inherits that as a platform constraint, but its own correctness does not depend on the limit.

\n

Key NervosDAO constraints confirmed against the whitepaper-pinned dao.c:

\n\n

Header Access

\n

Header access explains why iCKB uses a two-phase deposit flow. From script/src/syscalls/load_header.rs:

\n
    \n
  • For Source::Input: returns the header of the block containing the cell’s creation transaction. The block hash must appear in header_deps.
    • \n
  • For Source::Output: always returns INDEX_OUT_OF_BOUND (load_header.rs:80). Deposits require two phases.
    • \n
\n

Two shared boundaries matter in the later sections: authorization and accounting.

\n

Authorization Boundary

\n

Several candidate issues turn on the boundary between lock-script authorization and type-script accounting. The lock script / type script split means ownership is enforced by the user lock, while ickb_logic enforces value conservation. Its balance equation and cell classification never inspect who receives the output iCKB or the phase-1 DAO claim.

\n

Under the current whole-transaction-binding user-lock assumption, that division is acceptable because the user’s signature commits to the full transaction. The deployment model used for this review assumes current user-facing iCKB flows use strong transaction-binding locks and does not treat delegated or adopted OTX flows as in-scope present-day integrations.

\n

The weak-lock tests in this report do not replay a current wallet path. They model future or custom delegated, OTX, or other non-output-binding integrations, where recipient binding is an integration invariant rather than a guarantee provided by the iCKB contracts.

\n

Executed regressions show why that stays a boundary case rather than a current finding:

\n\n

The same ancillary scripts section already warns that delegated and OTX ownership patterns have their own pitfalls.

\n

Accounting Basis and Build Setting

\n

The main accounting claims in this report rest on three properties:

\n
    \n
  1. Balance equation: entry.rs:32 enforces in_udt + in_receipts == out_udt + in_deposits.
    2. \n
  2. Deposit-receipt accounting: entry.rs:132-137 requires deposited == receipted per amount bucket.
    3. \n
  3. Overflow checks: overflow-checks = true keeps the release-build accumulators from silently wrapping.
    4. \n
\n

Together, these preserve protocol accounting across deposit, conversion, withdrawal, and mixed transactions.

\n

Scope and Methodology

\n

This section pins the reviewed sources and the checks behind the conclusions.

\n

Reference Repositories

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
RepositoryCommit
ickb/contracts454cfa9
ickb/whitepapercdbabf6
nervosnetwork/ckb6730f80
nervosnetwork/ckb-system-scripts814eb82
nervosnetwork/ckb-production-scripts26b0b4f
nervosnetwork/rfcs4b502ff
\n

Methodology

\n

The review prioritized executable behavior over static plausibility and classified issues by their concrete impact.

\n
    \n
  • Reviewed the deployed release binaries and the transaction semantics they actually enforce, not just the latest source-level intent.
    • \n
  • Reproduced script behavior locally with ckb-testtool, using executable transaction tests rather than relying on inspection alone.
    • \n
  • Reused and extended the existing test suite, including replayed transaction shapes from observed protocol flows.
    • \n
  • Computed NervosDAO accounting with the exact DAO withdrawal math before classifying any claim-path discrepancy as a finding.
    • \n
  • Separated findings that affect the current deployment from weak-lock assumptions, operator mistakes, or broader integration-only scenarios.
    • \n
  • Removed or downgraded candidate issues that did not yield a harmful state transition, exploitable profit path, or realistic user loss.
    • \n
  • Explicitly tested mixed transactions and script-group interactions because iCKB safety depends on whole-transaction execution rather than isolated cell intent.
    • \n
\n

Test Coverage

\n

A module wiring overview plus the test layout note show three layers:

\n\n

A fresh cargo test -p tests run passed 214 tests with no failures. Those tests cover deployment-hash sanity checks, helper encodings, core flows, blocked-path regressions, and replayed transaction shapes across iCKB Logic, Owned Owner, and Limit Order.

\n

The strong-lock regressions in ickb_logic, owned_owner, and signing replay secp256k1_blake160_sighash_all as the representative whole-transaction-binding lock. This repo does not include a QRL fixture or harness, so conclusions for other strong-lock deployments rely on the same binding property and the stated deployment assumptions rather than a separate in-repo replay.

\n
\n

Limit Order

\n

The deployed Limit Order binary still carries one live issue: the known confusion attack. No other candidate path in this component validates as a live issue.

\n

Design

\n

Limit Order supports three operations: Mint (create order plus master), Match (partial or full fill), and Melt (destroy order plus master). Orders store exchange ratios (ckb_to_udt, udt_to_ckb) and a minimum match size.

\n

Key Validations

\n

Value conservation (entry.rs:103-105): uses C256 (checked U256) to prevent overflow.

\n
if i.ckb * ckb_mul + i.udt * udt_mul > o.ckb * ckb_mul + o.udt * udt_mul\n
\n

Concave ratio check (entry.rs:233-235): ensures round-trip conversion doesn’t lose value for the maker:

\n
if c2u.ckb_mul * u2c.udt_mul < c2u.udt_mul * u2c.ckb_mul\n
\n

Minimum match enforcement (entry.rs:108-129): prevents dust-level partial matches.

\n

Strict data length on execution (entry.rs:166): when limit_order executes, order data must be exactly UDT_SIZE + ORDER_SIZE bytes, so trailing data fails validation.

\n

Assessment

\n

Executed tests confirm several live confusion manifestations under the current deployment assumptions, and separate tests bound the rebinding path.

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
IDStatusFinding
LO-01KnownCKB does not execute output locks at creation time, and limit_order’s mint branch accepts swapped mint pairings, so mint-time output creation can seed phantom or cross-wired order/master lineages that later pass match or melt validation.
\n

Confirmed live manifestations:

\n\n

Bounding evidence: separate tests show that the rebinding path is narrower than arbitrary master rewriting:

\n\n

The UDT → CKB zero-UDT fulfilled-order shape still fails at the outer InvalidMatch check rather than surfacing a dedicated fulfilled-order guard.

\n
\n

iCKB Logic

\n

The deployed iCKB Logic binary is provenance-blind at cell classification, but once a cell is inside the scripted flow it still preserves receipt and xUDT accounting. The subsections below explain both properties and why the currently executed provenance-blind paths still stop short of a confirmed theft or profit finding.

\n

Core Invariant

\n

entry.rs:32:

\n
if in_udt_ickb + in_receipts_ickb != out_udt_ickb + in_deposits_ickb {\n    return Err(Error::AmountMismatch);\n}\n
\n

This equation is the core accounting invariant across all flows:

\n
    \n
  • Deposit phase 1: 0 + 0 == 0 + 0 (deposits and receipts handled by accounting check only)
    • \n
  • Deposit phase 2: 0 + receipt_value == out_udt + 0
    • \n
  • Withdrawal: in_udt + 0 == out_udt + deposit_value
    • \n
  • Mixed: any combination
    • \n
\n

Cell Classification

\n

celltype.rs:60-82 classifies every cell in the transaction by examining lock and type script hashes, plus the DAO data shape when the DAO hash is present:

\n
\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
LockTypeClassificationLine
iCKB LogicDAO deposit (8 zero bytes)DepositL69
iCKB Logicanything elseScriptMisuse (error)L72
otheriCKB LogicReceiptL75
otheriCKB xUDTUdtL78
DAO deposit (8 zero bytes) as lockanyScriptMisuse (error)L62
iCKB xUDT as lockanyScriptMisuse (error)L63
otherotherUnknown (ignored)L81
\n

ScriptType::None is only synthesized for missing type scripts; script_type() never returns None for locks, so the (ScriptType::None, _) arm is unreachable. NervosDAO withdrawal requests, which have non-zero data, correctly classify as Unknown via is_deposit_data.

\n

Deposit-Receipt Accounting (check_output)

\n

entry.rs:86-140 uses a BTreeMap<u64, Accounting> to ensure every group of same-sized output deposits is matched by equal receipt counts.

\n\n

It also validates:

\n\n

iCKB Conversion (deposit_to_ickb)

\n

entry.rs:71-84 uses the same conversion for minting and withdrawal:

\n
let ickb_amount = amount * ar_0 / ar_m;\nif ickb_amount > ICKB_SOFT_CAP_PER_DEPOSIT {\n    return Ok(ickb_amount - (ickb_amount - ICKB_SOFT_CAP_PER_DEPOSIT) / 10);\n}\n
\n
    \n
  • Division by zero: impossible (the RFC 0023 accumulated-rate rule sets AR_0 = 10 ^ 16 and AR_i = AR_{i-1} + floor(AR_{i-1} * s_i / C_{i-1}), so AR_m is non-zero).
    • \n
  • Overflow: u64 * u128 fits in u128 (~1.8e19 * 1e16 = ~1.8e35 < 3.4e38).
    • \n
  • Precision: integer division loses at most 1 shannon per operation.
    • \n
  • Fee/discount symmetry: the same function is used for both input receipts (fee, entry.rs:58-59) and input deposits (discount, entry.rs:52). The protocol breaks even: minted amount = burned amount.
    • \n
\n

has_empty_args Validation

\n

Cell identification relies on the exact deployed script hash. utils/utils.rs:14-36 enforces empty args on:

\n
    \n
  • The current script instance (covers input lock, input type, output type via CKB’s execution model)
    • \n
  • All output locks matching the same code_hash + hash_type (utils.rs:29-31)
    • \n
\n

Output types don’t need explicit checking because they trigger execution and self-validate.

\n

Assessment

\n

iCKB Logic has one state-admission blind spot plus several boundary points:

\n\n

On current executable evidence, that provenance-blind path is real, but it still falls short of a confirmed theft or standalone profit finding.

\n
\n

Owned Owner

\n

The deployed Owned Owner binary preserves its pairing invariant under the current assumptions. The remaining questions concern which cells can be paired and who controls the pair at creation time.

\n

Design

\n

Owned Owner pairs owned cells, namely NervosDAO withdrawal requests, with owner cells through a MetaPoint derived from the owner cell’s owned_distance field:

\n
    \n
  • Mint: the owner cell stores a signed distance to the owned cell, so owned_index == owner_index + owned_distance.
    • \n
  • Melt: both cells must be consumed together.
    • \n
\n

Validation

\n

For inputs and outputs separately, the script enforces the same pairing rules:

\n
    \n
  • Each metapoint must have exactly owned == 1 and owner == 1 (entry.rs:57-60).
    • \n
  • Owned cells must be NervosDAO withdrawal requests: DAO type + non-zero data (entry.rs:45-47).
    • \n
  • A cell using the script as both lock and type is rejected (entry.rs:53).
    • \n
\n

Assessment

\n

Owned Owner leaves four boundary points. The live claim-rotation path stays blocked in the currently modeled flows:

\n\n
\n

Deployment Context and Documented Risks

\n

Witness Malleability (Documented)

\n

Witness malleability is a documented property, not a new finding. All three scripts use the script-as-lock (unsigned) plus script-as-type (controller) pattern, and none of them reads witnesses.

\n

The whitepaper states the consequence directly: “if a script in a transaction needs to store data in the witness and this data can be tampered without the transaction becoming invalid, then this transaction must not employ the scripts presented in the current whitepaper.”

\n

Non-Upgradable Deployment

\n

Deployment is intentionally non-upgradable. The whitepaper’s non-upgradable deployment section says the scripts are deployed by data1, not by type, so they are non upgradable. Additionally, secp256k1_blake160 zero lock controls the binary.

\n

Any post-deployment bug requires migration to entirely new script deployments and a new dep group.

\n
\n

Conclusion

\n

Under the current deployment assumptions, only the known Limit Order confusion attack remains live.

\n

The iCKB Logic provenance-blind path exists, but the executed tests still stop at a self-funded edge case.

\n

The remaining Owned Owner and cross-script cases are blocked or confined to integration/deployment boundaries.

", "like_count": 0, "quote_count": 0 }, { "post_id": 24105, "post_number": 2, "topic_id": 10225, "topic_title": "iCKB Contracts Revisited: Old Code, New Audit", "topic_slug": "ickb-contracts-revisited-old-code-new-audit", "author": "phroi", "created_at": "2026-05-02T00:37:05.260000+00:00", "updated_at": "2026-05-02T00:37:05.260000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/ickb-contracts-revisited-old-code-new-audit/10225/2", "content_text": "Appendix: Scenario Analysis\nThe appendix records the case-by-case traces that support the component assessments and the findings summary.\nClass 1: Token Inflation (minting iCKB without backing)\nThese scenarios test whether iCKB can be created without the corresponding deposit-side accounting.\n1A. Direct xUDT minting bypass\nAttack: trigger xUDT owner mode without iCKB Logic validation.\nTrace: under iCKB’s deployed [ickb_logic_hash, XUDT_ARGS_FLAGS] with XUDT_ARGS_FLAGS = 0x80000000, xUDT owner mode has two live iCKB routes: a matching input type for receipts and a matching input lock for deposits (RFC 0052, xudt_rce.c).\nThe only other upstream owner-mode route is the witness owner_script fallback, but that path looks up the exported validate symbol via ckb_dlsym. iCKB Logic is built as a CKB entrypoint instead of an xUDT extension. In the two live cases, iCKB Logic co-executes, so the balance equation still applies. The output-witness owner-script fallback test and the input-witness owner-script fallback test reproduce that attempted route and still fail under xUDT amount checks.\nResult: Blocked.\n1B. Forge a high-value receipt\nAttack: create a receipt claiming more deposits than actually exist.\nTrace: check_output accounting requires deposited == receipted per amount in a BTreeMap. The over-counted receipt test shows that a receipt cannot claim more same-sized deposits than the transaction actually creates.\nResult: Blocked.\n1C. Inflate receipt value via AR manipulation\nAttack: make a receipt appear to be from an older block (lower AR = higher iCKB value).\nTrace: extract_accumulated_rate calls load_header, which reads the block hash from CellMeta.transaction_info.block_hash and only succeeds when that block is also present in header_deps. The transaction creator cannot override that linkage.\nResult: Blocked.\n1D. Create receipt without prior deposits\nAttack: consume a “receipt” that was never backed by actual deposits.\nTrace: the receipt uses iCKB Logic as its type script. Creating it as an output triggers iCKB Logic, which validates deposit-receipt accounting. CKB’s UTXO model then makes the created cell immutable. No valid receipt can exist without corresponding deposits.\nResult: Blocked.\nClass 2: Token Theft (unauthorized withdrawal)\nThese scenarios test whether pool deposits can be released without paying the corresponding iCKB cost.\n2A. Withdraw deposits without burning iCKB\nAttack: consume a deposit cell without providing sufficient iCKB.\nTrace: the balance equation (entry.rs:32) requires in_udt + in_receipts == out_udt + in_deposits. With no UDT or receipts on input: 0 + 0 != 0 + deposit_value → AmountMismatch.\nResult: Blocked.\n2B. Bypass iCKB Logic during deposit consumption\nAttack: consume a deposit cell through NervosDAO directly, without iCKB Logic running.\nTrace: deposits use iCKB Logic as their lock. CKB always executes input lock scripts (the lock-script rule), so there is no way to consume the input without triggering that lock.\nResult: Blocked.\n2C. Exploit cell_dep for value extraction\nAttack: reference a deposit as a cell_dep to extract data without consuming it.\nTrace: cells used in cell_deps remain live and are not considered dead like inputs. CKB executes lock scripts for inputs and type scripts for inputs and outputs, so referencing a deposit as a cell dep neither consumes it nor triggers its scripts.\nResult: No attack vector.\nClass 3: Economic Exploitation\nThese paths matter only if they create a repeatable profit or a material pool imbalance.\n3A. Oversized deposit fee/discount arbitrage\nAttack: deposit oversized, get iCKB with a 10% fee, then immediately withdraw the same deposit with a 10% discount.\nTrace: both fee and discount use the same deposit_to_ickb function with the same parameters. For a deposit at block M:\nPhase 2 mints: deposit_to_ickb(amount, AR_m) = X iCKB\nWithdrawal costs: deposit_to_ickb(amount, AR_m) = X iCKB\nNet profit = 0.\nResult: No arbitrage. Fee and discount are symmetric by construction.\n3B. Cherry-pick cheapest deposits\nAttack: scan the pool for deposits that require the least nominal iCKB to withdraw and then withdraw those deposits first.\nTrace: deposit_to_ickb computes amount * AR_0 / AR_m. RFC 0023’s maximum-withdrawable-capacity formula scales the later DAO claim by AR_n / AR_m, and the whitepaper’s exchange-rate calculation values the same deposit from block m at 100000 CKB * 10 ^ 16 / AR_m iCKB, excluding occupied capacity.\nDeposits with higher AR_m require less nominal iCKB because the formula values them lower in iCKB, not because the pool applies a discount.\nResult: No mispricing. Each deposit is priced by the same formula, up to integer-division rounding.\n3C. Integer rounding exploitation\nAttack: create many small deposits to accumulate rounding errors.\nTrace: the rounding mint test and the rounding withdrawal test show that the reported whole-CKB or rounded claims fail with AmountMismatch unless the exact shannon-precision value is used. The supposed extraction path does not validate on chain.\nResult: Blocked by exact shannon-precision accounting.\nClass 4: Data Manipulation\nThese cases test whether malformed cells can enter the accounting flow with misleading metadata.\n4A. Receipt with zero deposit_quantity\nTrace: entry.rs:114-116 rejects zero-quantity receipts. The zero-quantity receipt test shows the output creation failure directly, so input receipts with zero quantity cannot exist as live cells.\nResult: Blocked.\n4B. Receipt amount without matching deposit\nTrace: check_output uses a BTreeMap keyed by deposit_amount. The over-counted receipt test shows that a receipt cannot claim more same-sized deposits than the transaction actually creates, and the unmatched receipt-amount test shows that a receipt amount with no matching deposit bucket yields ReceiptMismatch.\nResult: Blocked.\n4C. Cell with iCKB Logic lock + non-DAO type\nTrace: once iCKB Logic executes, celltype.rs:72 rejects (ScriptType::IckbLogic, _) with ScriptMisuse. The lock-only non-DAO output test shows that such an output can still be created because output locks do not execute at creation time, but spending it later fails with ScriptMisuse.\nResult: Cannot be spent successfully.\n4D. NervosDAO withdrawal request classified as deposit\nTrace: is_deposit_data checks for exactly 8 zero bytes. Withdrawal requests have non-zero data that stores the block number, so they fall through to ScriptType::Unknown and then CellType::Unknown.\nResult: Blocked.\n4E. Deposit capacity manipulation\nAttack: inflate extract_unused_capacity by manipulating cell fields.\nTrace: CKB requires occupied capacity to fit within cell capacity, and extract_unused_capacity subtracts that VM-computed occupied capacity from the actual cell capacity. For the standard iCKB deposit shape, the whitepaper’s exchange-rate calculation uses c_o = 82 CKB. That occupied capacity is fixed by the deposit structure, not chosen independently by the attacker.\nResult: Blocked.\n4F. Deposit interest/maturity reset (whitepaper#18)\nAttack: consume an iCKB deposit and create a new deposit at the same output index, effectively resetting the deposit’s age and accrued interest in the pool. This would lower pool-wide returns at minimal cost.\nTrace: the specific same-index reset described here is blocked by NervosDAO phase 1. The receiptless aggregate-deposit variant is a different claim.\nNervosDAO blocks it: when a DAO deposit is consumed, validate_withdrawing_cell requires the output at the same index to be a withdrawal request with non-zero data containing the deposit block number. A new deposit with 8 zero bytes fails the stored_block_number != deposit_header.block_number check because genesis block number 0 does not match the real deposit block. The transaction is rejected.\nBy contrast, the broader provenance-blind path is a different claim. The receiptless deposit-admission test shows that ickb_logic later accepts a receiptless DAO-shaped output as a structurally valid deposit input once it exists.\nThe delta-only spread test and the oversized spread test show that the contract accepts a self-funded soft-cap spread, while the deposit-alone spread block test blocks the deposit-only variant.\nThe narrowing comment in the phase-2 claim test and the self-funded principal claim test make the limit explicit: the executed path still does not prove receipt-backed-principal theft or duplicated recovery.\nSo the specific “same output index” reset is blocked by NervosDAO. The receiptless aggregate-deposit variant stays a self-funded provenance-blind edge case rather than a confirmed double-claim exploit.\nResult: Blocked for the same-index reset described here. The receiptless aggregate-deposit path exists, but the current tests still stop short of proving receipt-backed-principal theft or duplicated recovery.\nClass 5: Cross-Script Interactions\nThese scenarios check whether behavior that is safe in isolation breaks once multiple scripts share a transaction.\n5A. Witness malleability during withdrawal (whitepaper#22, credit: @XuJiandong)\nAttack: tamper with witness data for the iCKB Logic lock group (unsigned lock). All three witness fields in the group (lock, input_type, output_type) are malleable because iCKB Logic does not use signature-based verification.\nTrace: iCKB Logic does not read witnesses. NervosDAO does read input_type from the witness to locate the deposit header (dao.c:63-98). If an attacker tampers with that header index, NervosDAO later compares the claimed deposit block number with the actual deposit header and fails at deposited_block_number != deposit_data.block_number.\nThe iCKB malformed witness test and the Owned Owner malformed witness test reproduce that malformed header-index witness failure path in iCKB Logic and Owned Owner withdrawal flows.\nThe whitepaper’s unsigned-lock-witnesses section already documents that general malleability risk and warns against combining these scripts with witness-dependent logic.\nResult: Can cause transaction failure (griefing), cannot cause fund loss. This is a liveness issue, not a safety issue. Documented in the whitepaper.\n5B. Separate lock/type group execution desync\nAttack: exploit dual execution in the hope that one run passes while the other fails.\nTrace: CKB requires ALL script groups to pass (the verifier loop returns an error if any verify_script_group(...) call fails). Both lock and type executions see identical cells at absolute indices and perform the same balance checks. If either fails, the transaction is rejected.\nResult: Blocked.\n5C. Non-empty-args iCKB Logic variant\nAttack: create a cell with {iCKB Logic code_hash, Data1, [0x01]} as type, hoping to bypass validation.\nTrace: different args produce a different script hash, so the cell is not recognized by script_type(). Even if it executes as its own type group, it still fails has_empty_args(). The non-empty-args poisoning regressions in phase2_sibling_classification.rs cover both output-sibling and input-sibling variants.\nResult: Blocked.\n5D. Orphaned Owned Owner cell\nTrace: owned_owner/entry.rs:57-60 requires every metapoint to have exactly owned==1, owner==1. The orphan-owner rejection test shows that an orphan type-script owner cell is rejected immediately. A separate lock-only orphan case can still be created at output-lock creation time and later strand, as shown by the orphan withdrawal-request dead-state test.\nResult: Blocked when Owned Owner executes. Lock-only look-alikes can still be created and later fail.\n5E. Limit Order value decrease\nTrace: limit_order/entry.rs:103-105 enforces value conservation with C256 (checked U256). Any decrease is rejected.\nResult: Blocked.\n5F. Limit Order confusion attack\nTrace: CKB builds lock groups only from input locks, while type groups come from both input and output types (types.rs:716-739). A limit-order cell is the lock-only (true, false) case in limit_order/entry.rs:48-56, so an attacker can create phantom order outputs with arbitrary master outpoints without running limit_order at creation time. One manifestation is a fake order that shares a real master outpoint; if a user later melts the wrong order, the real order becomes permanently stranded.\nResult: Known vulnerability. Documented in whitepaper. The real-order stranding test confirms the later real-order stranding path on the deployed binary.\nThe whitepaper’s mitigation is front-end lineage checking from the original mint transaction. Under the deployed lock-only design, the chain does not validate phantom orders at creation time because the order cell is created as an output lock-only cell.\nClass 6: Edge Cases\nThe remaining scenarios are boundary checks, platform constraints, or known economic limitations.\n6A. Boundary values\nTrace: the minimum deposit check uses < (entry.rs:101), so exactly 1000 CKB is allowed. The maximum uses > (entry.rs:104), so exactly 1M CKB is also allowed. The boundary-value regressions in deposit_bounds.rs cover both edges.\nResult: Correct.\n6B. u128 overflow in balance equation\nTrace: overflow-checks = true is enabled in scripts/Cargo.toml. Overflow panics and rejects the transaction.\nResult: Blocked (by the compiler setting and practical bounds).\n6C. Division by zero in deposit_to_ickb\nTrace: the RFC 0023 accumulated-rate rule sets AR_0 = 10 ^ 16 and AR_i = AR_{i-1} + floor(AR_{i-1} * s_i / C_{i-1}), so every deposit header has non-zero AR_m. deposit_to_ickb cannot divide by zero.\nResult: Impossible.\n6D. extract_unused_capacity underflow\nTrace: CKB VM enforces capacity >= occupied_capacity for all cells. The subtraction at utils.rs:48 is safe.\nResult: Impossible.\n6E. Chain reorganization between deposit phases (whitepaper#15)\nAttack: deposit phase 1 is included in block B. Before phase 2, a chain reorg removes B. The phase 2 transaction still references B’s header in header_deps, but B no longer exists in the canonical chain.\nTrace: CKB consensus requires all blocks listed in header_deps to exist in the canonical chain (RFC 0022: “the transaction can only be added to the chain if all the block listed in header_deps are already in the chain (uncles excluded)”). If B is reorged out, then (a) the phase 1 deposit cell no longer exists as a live cell, so it cannot be referenced, and (b) the header_dep pointing to B is invalid. The phase 2 transaction is rejected.\nResult: Blocked by CKB consensus rules. Reorgs cannot create phantom deposits.\n6F. Busywork / pool dilution attack (whitepaper#8)\nAttack: an attacker with large capital repeatedly deposits CKB in standard deposits and then withdraws, cycling through the pool. This shifts the maturity distribution: the remaining deposits are younger, so users must wait longer for a mature deposit.\nTrace: the attack requires sustained capital commitment. Per the whitepaper analysis, controlling the first available epoch requires about 0.6% of pool capital, while controlling the first 3 days requires about 10%. With a 0.3% APR per 180 epochs, a user blocked for 1 epoch loses about 0.0017% interest.\nThe attacker earns nothing because the cycled CKB returns to them, still pays transaction fees, and must lock capital for 180 epochs per cycle. As the pool grows, the capital requirement rises proportionally while the impact per unit of capital falls.\nResult: Requires sustained capital and yields less impact as the pool grows. This is a known limitation, not a vulnerability.\n6G. Same-block receipt and deposit consumption\nAttack: create a deposit plus receipt in TX1, then consume both in TX2 (receipt for phase 2 plus deposit for withdrawal) in the hope that the AR difference yields free iCKB.\nTrace: both were created in the same block (TX1). extract_accumulated_rate returns the same AR for both. Since receipt_value == deposit_value, the balance equation yields 0 + receipt_value == out_udt + deposit_value → out_udt = 0. No net iCKB is minted.\nResult: No profit.\n6H. Race between receipt creation and deposit withdrawal\nScenario: a user creates deposit D plus receipt R in phase 1. Before the user performs phase 2, someone else withdraws D.\nTrace: R still exists and is valid, and its iCKB value is fixed by the creation-block AR. D being consumed by someone else is expected pool behavior, so the user still converts R to iCKB normally in phase 2.\nThe protocol remains balanced because the withdrawer paid deposit_to_ickb(D) iCKB, and the receipt holder receives the equivalent receipt_iCKB_value(R).\nResult: Pool accounting stays balanced.", "content_html": "

Appendix: Scenario Analysis

\n

The appendix records the case-by-case traces that support the component assessments and the findings summary.

\n

Class 1: Token Inflation (minting iCKB without backing)

\n

These scenarios test whether iCKB can be created without the corresponding deposit-side accounting.

\n

1A. Direct xUDT minting bypass

\n

Attack: trigger xUDT owner mode without iCKB Logic validation.

\n

Trace: under iCKB’s deployed [ickb_logic_hash, XUDT_ARGS_FLAGS] with XUDT_ARGS_FLAGS = 0x80000000, xUDT owner mode has two live iCKB routes: a matching input type for receipts and a matching input lock for deposits (RFC 0052, xudt_rce.c).

\n

The only other upstream owner-mode route is the witness owner_script fallback, but that path looks up the exported validate symbol via ckb_dlsym. iCKB Logic is built as a CKB entrypoint instead of an xUDT extension. In the two live cases, iCKB Logic co-executes, so the balance equation still applies. The output-witness owner-script fallback test and the input-witness owner-script fallback test reproduce that attempted route and still fail under xUDT amount checks.

\n

Result: Blocked.

\n

1B. Forge a high-value receipt

\n

Attack: create a receipt claiming more deposits than actually exist.

\n

Trace: check_output accounting requires deposited == receipted per amount in a BTreeMap. The over-counted receipt test shows that a receipt cannot claim more same-sized deposits than the transaction actually creates.

\n

Result: Blocked.

\n

1C. Inflate receipt value via AR manipulation

\n

Attack: make a receipt appear to be from an older block (lower AR = higher iCKB value).

\n

Trace: extract_accumulated_rate calls load_header, which reads the block hash from CellMeta.transaction_info.block_hash and only succeeds when that block is also present in header_deps. The transaction creator cannot override that linkage.

\n

Result: Blocked.

\n

1D. Create receipt without prior deposits

\n

Attack: consume a “receipt” that was never backed by actual deposits.

\n

Trace: the receipt uses iCKB Logic as its type script. Creating it as an output triggers iCKB Logic, which validates deposit-receipt accounting. CKB’s UTXO model then makes the created cell immutable. No valid receipt can exist without corresponding deposits.

\n

Result: Blocked.

\n

Class 2: Token Theft (unauthorized withdrawal)

\n

These scenarios test whether pool deposits can be released without paying the corresponding iCKB cost.

\n

2A. Withdraw deposits without burning iCKB

\n

Attack: consume a deposit cell without providing sufficient iCKB.

\n

Trace: the balance equation (entry.rs:32) requires in_udt + in_receipts == out_udt + in_deposits. With no UDT or receipts on input: 0 + 0 != 0 + deposit_value → AmountMismatch.

\n

Result: Blocked.

\n

2B. Bypass iCKB Logic during deposit consumption

\n

Attack: consume a deposit cell through NervosDAO directly, without iCKB Logic running.

\n

Trace: deposits use iCKB Logic as their lock. CKB always executes input lock scripts (the lock-script rule), so there is no way to consume the input without triggering that lock.

\n

Result: Blocked.

\n

2C. Exploit cell_dep for value extraction

\n

Attack: reference a deposit as a cell_dep to extract data without consuming it.

\n

Trace: cells used in cell_deps remain live and are not considered dead like inputs. CKB executes lock scripts for inputs and type scripts for inputs and outputs, so referencing a deposit as a cell dep neither consumes it nor triggers its scripts.

\n

Result: No attack vector.

\n

Class 3: Economic Exploitation

\n

These paths matter only if they create a repeatable profit or a material pool imbalance.

\n

3A. Oversized deposit fee/discount arbitrage

\n

Attack: deposit oversized, get iCKB with a 10% fee, then immediately withdraw the same deposit with a 10% discount.

\n

Trace: both fee and discount use the same deposit_to_ickb function with the same parameters. For a deposit at block M:

\n
    \n
  • Phase 2 mints: deposit_to_ickb(amount, AR_m) = X iCKB
    • \n
  • Withdrawal costs: deposit_to_ickb(amount, AR_m) = X iCKB
    • \n
\n

Net profit = 0.

\n

Result: No arbitrage. Fee and discount are symmetric by construction.

\n

3B. Cherry-pick cheapest deposits

\n

Attack: scan the pool for deposits that require the least nominal iCKB to withdraw and then withdraw those deposits first.

\n

Trace: deposit_to_ickb computes amount * AR_0 / AR_m. RFC 0023’s maximum-withdrawable-capacity formula scales the later DAO claim by AR_n / AR_m, and the whitepaper’s exchange-rate calculation values the same deposit from block m at 100000 CKB * 10 ^ 16 / AR_m iCKB, excluding occupied capacity.

\n

Deposits with higher AR_m require less nominal iCKB because the formula values them lower in iCKB, not because the pool applies a discount.

\n

Result: No mispricing. Each deposit is priced by the same formula, up to integer-division rounding.

\n

3C. Integer rounding exploitation

\n

Attack: create many small deposits to accumulate rounding errors.

\n

Trace: the rounding mint test and the rounding withdrawal test show that the reported whole-CKB or rounded claims fail with AmountMismatch unless the exact shannon-precision value is used. The supposed extraction path does not validate on chain.

\n

Result: Blocked by exact shannon-precision accounting.

\n

Class 4: Data Manipulation

\n

These cases test whether malformed cells can enter the accounting flow with misleading metadata.

\n

4A. Receipt with zero deposit_quantity

\n

Trace: entry.rs:114-116 rejects zero-quantity receipts. The zero-quantity receipt test shows the output creation failure directly, so input receipts with zero quantity cannot exist as live cells.

\n

Result: Blocked.

\n

4B. Receipt amount without matching deposit

\n

Trace: check_output uses a BTreeMap keyed by deposit_amount. The over-counted receipt test shows that a receipt cannot claim more same-sized deposits than the transaction actually creates, and the unmatched receipt-amount test shows that a receipt amount with no matching deposit bucket yields ReceiptMismatch.

\n

Result: Blocked.

\n

4C. Cell with iCKB Logic lock + non-DAO type

\n

Trace: once iCKB Logic executes, celltype.rs:72 rejects (ScriptType::IckbLogic, _) with ScriptMisuse. The lock-only non-DAO output test shows that such an output can still be created because output locks do not execute at creation time, but spending it later fails with ScriptMisuse.

\n

Result: Cannot be spent successfully.

\n

4D. NervosDAO withdrawal request classified as deposit

\n

Trace: is_deposit_data checks for exactly 8 zero bytes. Withdrawal requests have non-zero data that stores the block number, so they fall through to ScriptType::Unknown and then CellType::Unknown.

\n

Result: Blocked.

\n

4E. Deposit capacity manipulation

\n

Attack: inflate extract_unused_capacity by manipulating cell fields.

\n

Trace: CKB requires occupied capacity to fit within cell capacity, and extract_unused_capacity subtracts that VM-computed occupied capacity from the actual cell capacity. For the standard iCKB deposit shape, the whitepaper’s exchange-rate calculation uses c_o = 82 CKB. That occupied capacity is fixed by the deposit structure, not chosen independently by the attacker.

\n

Result: Blocked.

\n

4F. Deposit interest/maturity reset (whitepaper#18)

\n

Attack: consume an iCKB deposit and create a new deposit at the same output index, effectively resetting the deposit’s age and accrued interest in the pool. This would lower pool-wide returns at minimal cost.

\n

Trace: the specific same-index reset described here is blocked by NervosDAO phase 1. The receiptless aggregate-deposit variant is a different claim.

\n
    \n
  1. \n

    NervosDAO blocks it: when a DAO deposit is consumed, validate_withdrawing_cell requires the output at the same index to be a withdrawal request with non-zero data containing the deposit block number. A new deposit with 8 zero bytes fails the stored_block_number != deposit_header.block_number check because genesis block number 0 does not match the real deposit block. The transaction is rejected.

    \n
    2. \n
  2. \n

    By contrast, the broader provenance-blind path is a different claim. The receiptless deposit-admission test shows that ickb_logic later accepts a receiptless DAO-shaped output as a structurally valid deposit input once it exists.

    \n
    3. \n
\n

The delta-only spread test and the oversized spread test show that the contract accepts a self-funded soft-cap spread, while the deposit-alone spread block test blocks the deposit-only variant.

\n

The narrowing comment in the phase-2 claim test and the self-funded principal claim test make the limit explicit: the executed path still does not prove receipt-backed-principal theft or duplicated recovery.

\n

So the specific “same output index” reset is blocked by NervosDAO. The receiptless aggregate-deposit variant stays a self-funded provenance-blind edge case rather than a confirmed double-claim exploit.

\n

Result: Blocked for the same-index reset described here. The receiptless aggregate-deposit path exists, but the current tests still stop short of proving receipt-backed-principal theft or duplicated recovery.

\n

Class 5: Cross-Script Interactions

\n

These scenarios check whether behavior that is safe in isolation breaks once multiple scripts share a transaction.

\n

5A. Witness malleability during withdrawal (whitepaper#22, credit: @XuJiandong)

\n

Attack: tamper with witness data for the iCKB Logic lock group (unsigned lock). All three witness fields in the group (lock, input_type, output_type) are malleable because iCKB Logic does not use signature-based verification.

\n

Trace: iCKB Logic does not read witnesses. NervosDAO does read input_type from the witness to locate the deposit header (dao.c:63-98). If an attacker tampers with that header index, NervosDAO later compares the claimed deposit block number with the actual deposit header and fails at deposited_block_number != deposit_data.block_number.

\n

The iCKB malformed witness test and the Owned Owner malformed witness test reproduce that malformed header-index witness failure path in iCKB Logic and Owned Owner withdrawal flows.

\n

The whitepaper’s unsigned-lock-witnesses section already documents that general malleability risk and warns against combining these scripts with witness-dependent logic.

\n

Result: Can cause transaction failure (griefing), cannot cause fund loss. This is a liveness issue, not a safety issue. Documented in the whitepaper.

\n

5B. Separate lock/type group execution desync

\n

Attack: exploit dual execution in the hope that one run passes while the other fails.

\n

Trace: CKB requires ALL script groups to pass (the verifier loop returns an error if any verify_script_group(...) call fails). Both lock and type executions see identical cells at absolute indices and perform the same balance checks. If either fails, the transaction is rejected.

\n

Result: Blocked.

\n

5C. Non-empty-args iCKB Logic variant

\n

Attack: create a cell with {iCKB Logic code_hash, Data1, [0x01]} as type, hoping to bypass validation.

\n

Trace: different args produce a different script hash, so the cell is not recognized by script_type(). Even if it executes as its own type group, it still fails has_empty_args(). The non-empty-args poisoning regressions in phase2_sibling_classification.rs cover both output-sibling and input-sibling variants.

\n

Result: Blocked.

\n

5D. Orphaned Owned Owner cell

\n

Trace: owned_owner/entry.rs:57-60 requires every metapoint to have exactly owned==1, owner==1. The orphan-owner rejection test shows that an orphan type-script owner cell is rejected immediately. A separate lock-only orphan case can still be created at output-lock creation time and later strand, as shown by the orphan withdrawal-request dead-state test.

\n

Result: Blocked when Owned Owner executes. Lock-only look-alikes can still be created and later fail.

\n

5E. Limit Order value decrease

\n

Trace: limit_order/entry.rs:103-105 enforces value conservation with C256 (checked U256). Any decrease is rejected.

\n

Result: Blocked.

\n

5F. Limit Order confusion attack

\n

Trace: CKB builds lock groups only from input locks, while type groups come from both input and output types (types.rs:716-739). A limit-order cell is the lock-only (true, false) case in limit_order/entry.rs:48-56, so an attacker can create phantom order outputs with arbitrary master outpoints without running limit_order at creation time. One manifestation is a fake order that shares a real master outpoint; if a user later melts the wrong order, the real order becomes permanently stranded.

\n

Result: Known vulnerability. Documented in whitepaper. The real-order stranding test confirms the later real-order stranding path on the deployed binary.

\n

The whitepaper’s mitigation is front-end lineage checking from the original mint transaction. Under the deployed lock-only design, the chain does not validate phantom orders at creation time because the order cell is created as an output lock-only cell.

\n

Class 6: Edge Cases

\n

The remaining scenarios are boundary checks, platform constraints, or known economic limitations.

\n

6A. Boundary values

\n

Trace: the minimum deposit check uses < (entry.rs:101), so exactly 1000 CKB is allowed. The maximum uses > (entry.rs:104), so exactly 1M CKB is also allowed. The boundary-value regressions in deposit_bounds.rs cover both edges.

\n

Result: Correct.

\n

6B. u128 overflow in balance equation

\n

Trace: overflow-checks = true is enabled in scripts/Cargo.toml. Overflow panics and rejects the transaction.

\n

Result: Blocked (by the compiler setting and practical bounds).

\n

6C. Division by zero in deposit_to_ickb

\n

Trace: the RFC 0023 accumulated-rate rule sets AR_0 = 10 ^ 16 and AR_i = AR_{i-1} + floor(AR_{i-1} * s_i / C_{i-1}), so every deposit header has non-zero AR_m. deposit_to_ickb cannot divide by zero.

\n

Result: Impossible.

\n

6D. extract_unused_capacity underflow

\n

Trace: CKB VM enforces capacity >= occupied_capacity for all cells. The subtraction at utils.rs:48 is safe.

\n

Result: Impossible.

\n

6E. Chain reorganization between deposit phases (whitepaper#15)

\n

Attack: deposit phase 1 is included in block B. Before phase 2, a chain reorg removes B. The phase 2 transaction still references B’s header in header_deps, but B no longer exists in the canonical chain.

\n

Trace: CKB consensus requires all blocks listed in header_deps to exist in the canonical chain (RFC 0022: “the transaction can only be added to the chain if all the block listed in header_deps are already in the chain (uncles excluded)”). If B is reorged out, then (a) the phase 1 deposit cell no longer exists as a live cell, so it cannot be referenced, and (b) the header_dep pointing to B is invalid. The phase 2 transaction is rejected.

\n

Result: Blocked by CKB consensus rules. Reorgs cannot create phantom deposits.

\n

6F. Busywork / pool dilution attack (whitepaper#8)

\n

Attack: an attacker with large capital repeatedly deposits CKB in standard deposits and then withdraws, cycling through the pool. This shifts the maturity distribution: the remaining deposits are younger, so users must wait longer for a mature deposit.

\n

Trace: the attack requires sustained capital commitment. Per the whitepaper analysis, controlling the first available epoch requires about 0.6% of pool capital, while controlling the first 3 days requires about 10%. With a 0.3% APR per 180 epochs, a user blocked for 1 epoch loses about 0.0017% interest.

\n

The attacker earns nothing because the cycled CKB returns to them, still pays transaction fees, and must lock capital for 180 epochs per cycle. As the pool grows, the capital requirement rises proportionally while the impact per unit of capital falls.

\n

Result: Requires sustained capital and yields less impact as the pool grows. This is a known limitation, not a vulnerability.

\n

6G. Same-block receipt and deposit consumption

\n

Attack: create a deposit plus receipt in TX1, then consume both in TX2 (receipt for phase 2 plus deposit for withdrawal) in the hope that the AR difference yields free iCKB.

\n

Trace: both were created in the same block (TX1). extract_accumulated_rate returns the same AR for both. Since receipt_value == deposit_value, the balance equation yields 0 + receipt_value == out_udt + deposit_value → out_udt = 0. No net iCKB is minted.

\n

Result: No profit.

\n

6H. Race between receipt creation and deposit withdrawal

\n

Scenario: a user creates deposit D plus receipt R in phase 1. Before the user performs phase 2, someone else withdraws D.

\n

Trace: R still exists and is valid, and its iCKB value is fixed by the creation-block AR. D being consumed by someone else is expected pool behavior, so the user still converts R to iCKB normally in phase 2.

\n

The protocol remains balanced because the withdrawer paid deposit_to_ickb(D) iCKB, and the receipt holder receives the equivalent receipt_iCKB_value(R).

\n

Result: Pool accounting stays balanced.

", "like_count": 0, "quote_count": 0 }, { "post_id": 24110, "post_number": 3, "topic_id": 10225, "topic_title": "iCKB Contracts Revisited: Old Code, New Audit", "topic_slug": "ickb-contracts-revisited-old-code-new-audit", "author": "ArthurZhang", "created_at": "2026-05-02T01:33:02.680000+00:00", "updated_at": "2026-05-02T01:33:02.680000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/ickb-contracts-revisited-old-code-new-audit/10225/3", "content_text": "Great update.\nThis appendix is almost exactly the kind of scenario map I would need before turning iCKB into a CellScript maturity benchmark. The attack-class structure, traces, expected results, and links to concrete tests make it much easier.", "content_html": "

Great update.
\nThis appendix is almost exactly the kind of scenario map I would need before turning iCKB into a CellScript maturity benchmark. The attack-class structure, traces, expected results, and links to concrete tests make it much easier.

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10199, "title": "Cellora — designing a production indexing and query service for CKB (feedback welcome)", "slug": "cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome", "url": "https://talk.nervos.org/t/cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome/10199", "created_at": "2026-04-22T15:33:26.290000+00:00", "last_posted_at": "2026-05-02T01:21:16.135000+00:00", "category_id": 32, "tags": [ "CKB", "Nervos-项目动态", "dapp", "testnet" ], "posters": [ "Original Poster", "Frequent Poster", "Frequent Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24109, "post_number": 8, "topic_id": 10199, "topic_title": "Cellora — designing a production indexing and query service for CKB (feedback welcome)", "topic_slug": "cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome", "author": "phroi", "created_at": "2026-05-02T01:21:16.135000+00:00", "updated_at": "2026-05-02T01:21:16.135000+00:00", "reply_to_post_number": 6, "url": "https://talk.nervos.org/t/cellora-designing-a-production-indexing-and-query-service-for-ckb-feedback-welcome/10199/8", "content_text": "matt_ckb:\nWithout the Flyclient proof, I have trouble seeing how the client can verify that the block header returned from Cellora has been included in the chain. Am I missing something?\nEven if the returned header is anchored to consensus, there is still the harder question: how does the client prove that no matching cells or txs were omitted from the answer?\nIf the client wants both consensus anchoring and query completeness for itself, it still needs its own light client or full node.\nThe more interesting design space is not “one provider proves everything”, but “independent parties reproducing the same canonical view at the same tip”.\nBeen chiseling away at a design in that direction: not fully trustless, but potentially a useful middle ground for users willing to trade a bit of trust for much less sync time.\nPhroi", "content_html": "\n

Even if the returned header is anchored to consensus, there is still the harder question: how does the client prove that no matching cells or txs were omitted from the answer?

\n

If the client wants both consensus anchoring and query completeness for itself, it still needs its own light client or full node.

\n

The more interesting design space is not “one provider proves everything”, but “independent parties reproducing the same canonical view at the same tip”.

\n

Been chiseling away at a design in that direction: not fully trustless, but potentially a useful middle ground for users willing to trade a bit of trust for much less sync time.

\n

Phroi

", "like_count": 0, "quote_count": 1 } ] }, { "topic_id": 10193, "title": "CellScript - A DSL for Cell-Based Contracts", "slug": "cellscript-a-dsl-for-cell-based-contracts", "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193", "created_at": "2026-04-21T04:43:38.654000+00:00", "last_posted_at": "2026-05-02T01:12:37.583000+00:00", "category_id": 49, "tags": [ "CKB-VM", "CellScript", "DSL" ], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24106, "post_number": 18, "topic_id": 10193, "topic_title": "CellScript - A DSL for Cell-Based Contracts", "topic_slug": "cellscript-a-dsl-for-cell-based-contracts", "author": "phroi", "created_at": "2026-05-02T00:41:47.201000+00:00", "updated_at": "2026-05-02T00:41:47.201000+00:00", "reply_to_post_number": 17, "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193/18", "content_text": "Hey Arthur, you are very welcome to try iCKB in CellScript\nTo make that easier, I tightened the iCKB artifacts around the relevant DAO, header, witness, and deployment details:\nickb/contracts PR #19: merged. Adds the local executable review plus the expanded scripts/tests suites and replay-heavy cases. See also iCKB Contracts Revisited: Old Code, New Audit\nickb/whitepaper PR #24: merged. Consolidates the protocol and deployment notes.\nnervosnetwork/rfcs PR #453: open. Notes the current DAO same-serialized-lock-size rule that nodes enforce for phase-1 withdrawals.\nSo if you still want to use iCKB as a maturity benchmark, the code and docs should be a much cleaner starting point now.\nHappy to help once you get to concrete fixtures,\nPhroi", "content_html": "

Hey Arthur, you are very welcome to try iCKB in CellScript \":hugs:\"

\n

To make that easier, I tightened the iCKB artifacts around the relevant DAO, header, witness, and deployment details:

\n\n

So if you still want to use iCKB as a maturity benchmark, the code and docs should be a much cleaner starting point now.

\n

Happy to help once you get to concrete fixtures,
\nPhroi

", "like_count": 0, "quote_count": 0 }, { "post_id": 24108, "post_number": 19, "topic_id": 10193, "topic_title": "CellScript - A DSL for Cell-Based Contracts", "topic_slug": "cellscript-a-dsl-for-cell-based-contracts", "author": "ArthurZhang", "created_at": "2026-05-02T01:12:37.583000+00:00", "updated_at": "2026-05-02T01:12:37.583000+00:00", "reply_to_post_number": 18, "url": "https://talk.nervos.org/t/cellscript-a-dsl-for-cell-based-contracts/10193/19", "content_text": "Hi Phroi,\nThat is very helpful.\nI will read through these updates before turning this into concrete fixtures.\nOnce I have the first small fixture set ready, I will tag you again for feedback.\nReally appreciate the help.", "content_html": "

Hi Phroi,

\n

That is very helpful. \":100:\"
\nI will read through these updates before turning this into concrete fixtures.
\nOnce I have the first small fixture set ready, I will tag you again for feedback.
\nReally appreciate the help.

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 8369, "title": "[DIS] iCKB & dCKB Rescuer Funding Proposal (Non-Coding Expenses)", "slug": "dis-ickb-dckb-rescuer-funding-proposal-non-coding-expenses", "url": "https://talk.nervos.org/t/dis-ickb-dckb-rescuer-funding-proposal-non-coding-expenses/8369", "created_at": "2024-10-18T14:39:31.343000+00:00", "last_posted_at": "2026-05-02T00:45:39.136000+00:00", "category_id": 65, "tags": [], "posters": [ "Original Poster, Most Recent Poster", "Frequent Poster", "Frequent Poster", "Frequent Poster" ], "recent_posts": [ { "post_id": 24107, "post_number": 28, "topic_id": 8369, "topic_title": "[DIS] iCKB & dCKB Rescuer Funding Proposal (Non-Coding Expenses)", "topic_slug": "dis-ickb-dckb-rescuer-funding-proposal-non-coding-expenses", "author": "phroi", "created_at": "2026-05-02T00:45:39.136000+00:00", "updated_at": "2026-05-02T00:45:39.136000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/dis-ickb-dckb-rescuer-funding-proposal-non-coding-expenses/8369/28", "content_text": "Hey all, small update on the iCKB side\nI cleaned up a few iCKB artifacts around the DAO, headers, witnesses, and deployment notes:\nickb/contracts PR #19: merged. Adds the local executable review plus the expanded scripts/tests suites and replay-heavy cases. See also iCKB Contracts Revisited: Old Code, New Audit\nickb/whitepaper PR #24: merged. Consolidates the protocol and deployment notes.\nnervosnetwork/rfcs PR #453: open. Notes the current DAO same-serialized-lock-size rule that nodes enforce for phase-1 withdrawals.\nThat last point is the same current node rule I mentioned earlier here for dCKB Rescuer, so at least that constraint is now written down more clearly.\nLove & Peace, Phroi", "content_html": "

Hey all, small update on the iCKB side \":hugs:\"

\n

I cleaned up a few iCKB artifacts around the DAO, headers, witnesses, and deployment notes:

\n\n

That last point is the same current node rule I mentioned earlier here for dCKB Rescuer, so at least that constraint is now written down more clearly.

\n

Love & Peace, Phroi

", "like_count": 0, "quote_count": 0 } ] }, { "topic_id": 10221, "title": "Revamping and Refactoring the CKB Wallet Connection Experience: A Modular Compound Component for React Developers", "slug": "revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers", "url": "https://talk.nervos.org/t/revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers/10221", "created_at": "2026-04-30T19:28:31.062000+00:00", "last_posted_at": "2026-05-01T19:35:13.576000+00:00", "category_id": 49, "tags": [ "CKB", "wallet" ], "posters": [ "Original Poster", "Most Recent Poster" ], "recent_posts": [ { "post_id": 24103, "post_number": 2, "topic_id": 10221, "topic_title": "Revamping and Refactoring the CKB Wallet Connection Experience: A Modular Compound Component for React Developers", "topic_slug": "revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers", "author": "Ajay", "created_at": "2026-05-01T19:35:13.576000+00:00", "updated_at": "2026-05-01T19:35:13.576000+00:00", "reply_to_post_number": null, "url": "https://talk.nervos.org/t/revamping-and-refactoring-the-ckb-wallet-connection-experience-a-modular-compound-component-for-react-developers/10221/2", "content_text": "This is awesome", "content_html": "

This is awesome

", "like_count": 0, "quote_count": 0 } ] } ] }