Skip to content

Commit 7424540

Browse files
authored
Merge pull request #18 from chenyukang/add-doc
Add documentation for the three implementations
2 parents da0a761 + 1150b85 commit 7424540

File tree

3 files changed

+61
-5
lines changed

3 files changed

+61
-5
lines changed

Makefile

Lines changed: 3 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -50,7 +50,9 @@ build:
5050
cargo build -p $$(basename $$crate) $(MODE_ARGS) $(CARGO_ARGS); \
5151
done; \
5252
for contract in $(sort $(wildcard contracts/*)); do \
53-
$(MAKE) -e -C $$contract build; \
53+
if [ -d "$$contract" ]; then \
54+
$(MAKE) -e -C $$contract build; \
55+
fi; \
5456
done; \
5557
for crate in $(wildcard tools/*); do \
5658
cargo build -p $$(basename $$crate | tr '-' '_') $(MODE_ARGS) $(CARGO_ARGS); \

README.md

Lines changed: 9 additions & 4 deletions
Original file line numberDiff line numberDiff line change
@@ -1,8 +1,13 @@
11
# quantum-resistant-lock-script
2-
Quantum resistant lock script on CKB, based on [NIST FIPS 205](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf) standard. 2 implementations exist:
2+
Quantum resistant lock script on CKB, based on [NIST FIPS 205](https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.205.pdf) standard.
33

4-
* A C lock script using [SPHINCS+](https://github.com/sphincs/sphincsplus)
5-
* A Rust lock script using [fips205](https://github.com/integritychain/fips205)
4+
5+
There are 3 implementations:
6+
* [A C lock script](./contracts/c-sphincs-all-in-one-lock/) using [SPHINCS+](https://github.com/sphincs/sphincsplus)
7+
* [A Rust lock script](./contracts/sphincs-all-in-one-lock/) using [fips205](https://github.com/integritychain/fips205)
8+
* [A hybrid lock script](./contracts/hybrid-sphincs-all-in-one-lock/) with the implementation of SPHINCS+ utilizing the sphincsplus C library and Rust glue code.
9+
10+
You can find more details about the implementation strategy in [contracts/README.md](./contracts/README.md).
611

712
## Build
813

@@ -43,7 +48,7 @@ In general, the `s` variants take longer to generate a signature, but takes less
4348

4449
**NOTE**: the following tool shall be considered deprecated, and only kept here for historic reasons.
4550

46-
This tool is to **convert a default Lock(SECP256K1/blake160) to quantum resistant lock script.**.
51+
This tool is to **convert a default Lock(SECP256K1/blake160) to quantum resistant lock script.**.
4752

4853
Follow steps below:
4954

contracts/README.md

Lines changed: 49 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,49 @@
1+
2+
## SPHINCS+ Lock Implementation Strategy
3+
4+
We have evaluated three different technical approaches for implementing the SPHINCS+ lock with the goal of selecting the most secure and stable version for long-term deployment.
5+
6+
### The Three Implementation Versions
7+
8+
The following three versions were created to compare trade-offs in cryptographic assurance, performance, and long-term maintenance:
9+
10+
| Version | Core SPHINCS+ Logic | CKB Glue Code | Key Technology |
11+
| :--- | :--- | :--- | :--- |
12+
| **1. Pure C** | `sphincsplus` C library (NIST reference) | C99 Standard | High cryptographic assurance and stability. |
13+
| **2. Pure Rust** | `fips205` Rust crate | Rust | Fully Rust-native implementation. |
14+
| **3. Hybrid** | `sphincsplus` C library (NIST reference) | Rust | Combines the proven C core with a Rust wrapper. |
15+
16+
### Compare Metrics
17+
18+
While performance was not the primary deciding factor, the contracts showed differences in size and computational cost:
19+
20+
| Metric | Pure C | Pure Rust | Hybrid |
21+
| :--- | :--- | :--- | :--- |
22+
| **Minimised Contract Size** | $\text{206K}$ | $\text{224K}$ | $\text{277K}$ |
23+
| **Cycle Consumption** | Fastest ($\approx 60\%$ of Rust cycles) | Slowest | Similar to Pure C |
24+
25+
More details on performance can be found in [Performance Doc](../docs/performance.md).
26+
27+
### Rationale for Version Selection
28+
29+
The decision to choose a specific version is driven by two critical factors: **Cryptographic Assurance** and **Long-Term Stability**.
30+
31+
#### 1. Maximum Cryptographic Assurance
32+
33+
For a quantum-resistant solution like SPHINCS+, the security of the underlying cryptographic primitive is paramount.
34+
35+
* The **`sphincsplus` C library** used in the Pure C and Hybrid versions is the **reference implementation** submitted to the NIST Post-Quantum Cryptography Standardization process. It is authored and maintained by the original creators of the SPHINCS+ algorithm.
36+
* This high level of scrutiny and maintenance by leading cryptographers provides the greatest assurance that the implementation is robust and free from subtle cryptographic errors.
37+
38+
#### 2. Long-Term Stability for HODL Use Case
39+
40+
SPHINCS+ is intended primarily as a **long-term security solution** for users who wish to secure their assets against potential future quantum attacks (e.g., over a $\text{10-20}$ year period). This use case demands a contract that is maximally stable and immutable.
41+
42+
* We prioritize **foundational stability** over added features or a rapidly changing ecosystem.
43+
* The **Pure C** implementation, leveraging mature, stable toolchains and the proven `sphincsplus` C library, offers the most reliable foundation for a contract intended to remain unchanged for decades.
44+
45+
### Usage Guidance
46+
47+
We will deploy the **Pure C Implementation Contract** due to its combination of superior cryptographic assurance (NIST reference implementation) and its stability for long-term, quantum-resistant asset protection. This approach ensures the most trustworthy and enduring lock on the CKB chain.
48+
49+
While the Pure Rust and Hybrid versions offer interesting trade-offs, you should generally consider them for experimental, short-term scenarios or situations where the benefits of native Rust tooling outweigh the need for maximum guarantees and long-term stability.

0 commit comments

Comments
 (0)