Audit report corrections

[phroi]

A PR for minor corrections to the audit report

[gemini-code-assist]

Code Review

This pull request updates the ICKB Audit Report to clarify the non-upgradable deployment process, specifying that scripts are deployed using data1 and controlled by a secp256k1_blake160 zero lock. Feedback was provided to improve technical precision, fix formatting issues like double spaces and inconsistent hyphenation, and update the whitepaper link to an authoritative URL.

[phroi]

/gemini review

[gemini-code-assist]

Code Review

This pull request updates the ICKB Audit Report to provide a more detailed technical explanation of the non-upgradable deployment, specifically detailing the use of RFC 0022, RFC 0032, and the hash_type = data1 mechanism. The review feedback suggests refining the terminology from "later scripts" to "referencing scripts" for clarity and standardizing the capitalization of "Data1" to maintain consistency throughout the document.

I am having trouble creating individual review comments. Click here to see my feedback.

20260501-ICKB-Audit-Report.md (356)

The term "later scripts" is somewhat ambiguous in this technical context, as it could be interpreted as referring to temporal sequence or transaction order. Using "referencing scripts" or "consuming scripts" is more precise. Additionally, the capitalization of data1 is inconsistent with the Data1 used elsewhere in the report (e.g., lines 62 and 557). Standardizing on Data1 improves professional consistency.

The reviewed deployment is non-upgradable under the observed script references. Under RFC 0022 and RFC 0032, the deployed script references use hash_type = Data1: referencing scripts locate code from cell_deps by cell data hash and run it on CKB VM v1. This is not a property stored in the binary cell itself, but a property of how the live lock/type scripts refer to that cell. That reference mode pins validation to the exact deployed binary bytes. By contrast, hash_type = type would locate code by type-script hash, allowing a replacement code cell with the same type script and different contents, with upgrade policy then governed by that code cell's lock script. Separately, the published binary cells themselves are locked with a secp256k1_blake160 zero lock, an unspendable lock, so no trusted operator key remains as an owner of the binaries.

[phroi]

Updated in 0b7989a7390c14bae686271314fcbc675698bf09.

The current text now:

• removes the original spacing and hyphenation issues
• states the mechanism explicitly as hash_type = data1
• avoids the earlier "controls the binary" shortcut and instead ties the conclusion to the observed script-reference mode
• leads with audit observation (The reviewed deployment is non-upgradable under the observed script references) rather than project intent
• keeps the consequence scoped as an audit observation

I did not take the Data1 capitalization suggestion, because the deployment paragraph is describing the concrete hash_type value, and elsewhere in the report Data1 appears when referring to the script-hash-type label in script tuples. Keeping hash_type = data1 in lowercase matches the actual field value being described here.