Hey all~ @ArthurZhang, glad the scenario map helped!
iCKB safety has always been my priority. With all the recent LLM incidents, I went back to the contracts. I was already pretty sure there was no issue (but you never know), so I threw at them every technique I could think of, fuzzing first and foremost!!
Right now, the greater concern I have is over the continuous reporting of vulnerabilities and breaches: PHP, Node.js, Binance, even the Linux kernel itself, all in ten days of October.
The time correlation is pretty telling: AI is what enables the speed of these developments, on both sides.
So once again I put that same speed on our side: I just want to be sure we’re doing our best to keep the contracts as safe as possible. They can’t be changed on chain, so I tried hard to make them accept something they shouldn’t. They held every single time!!
- Same bytes: anyone can rebuild the contracts from source and get exactly the bytes running on chain.
- Millions of attempts: 12 million random transactions plus every small combination of tricky cells (37.8 million more), each checked against the four protocol rules: over 50 hours of computing. Not a single break.
- Real network rules: the tests now apply the same checks a CKB node runs. Every real iCKB transaction so far passes them.
- Testing the tests: of the 231 planted bugs that still compiled, the tests catch 229. The other two change nothing.
- A lying node can’t steal: since stack#66, the iCKB SDK checks what a node says before signing. A lying node can only make a transaction fail.
Bottom line: the iCKB contracts hold up, with nothing new found!! The one known limitation is still the fake limit order trick, which the iCKB Stack guards against. The report has the details and how to repeat every check. The appendix still maps every scenario to the section that traces it.
Love & Peace,
Phroi