Joined November 2022
252 Photos and videos
Yi 发现这个问题后和我进行了讨论,这是一个并不复杂的问题,简单来说就是 ERC4626 金库的奖励分发不应该是突变的,否则攻击者可以在奖励分配前存入资产,然后出触发奖励分配,最后撤回所有资产。我在此前甚至和 ChatGPT 讨论了这个问题。
Jun 3
If you’re wrong, own it. If you mishandle a responsible disclosure, take your lumps. @codephobic I followed USD8’s own security.md, privately submitted a Loss of Funds bug with a working PoC, then watched it get quietly patched with no credit and mocked as spam. This is exactly how you teach researchers that responsible disclosure is a sucker's game. I documented the case here: github.com/SuplabsYi/Crypto-… cc @openzeppelin @demibrener @holajotola
2
4
2,549
WongSSH retweeted
Formal Verification gets clearer when it moves from textbook examples to real bugs. Our new Dafny walkthrough starts with Bubble Sort, Quick Sort, and Merge Sort, then shows how specifications, invariants, and proof obligations uncover a stage-accounting vulnerability.
2
3
8
984
今天尝试证明了一下 uniswap v4 内的 balance delta 的正确性,核心不变量就是用户的余额变化与 balance delta 变化是一致的,然后把所有涉及到 Balance detla 的 solidity 函数丢给 codex 进行抽象,然后使用 dafny 证明。发现了一个有趣的点,即 self-call 返回 ZERO_DELTA 其实是为了资金安全
1
22
2,960
当我们尝试干掉 `caller == hook` 的 require 时,我们就可以看到 dafny 的抱怨,其实是因为假如允许 hook 进行 self-call 就会被双重记账,产生没有 balance 支持的 balance delta
1
1
966
背后的所有与 codex 的沟通流程可以在 gist 内找到,但是其实没啥用,核心就是让 codex 读 solidity 然后抽象后编写证明不变量的 dafny 代码,最好让 codex 写一份 MODEL.md 文档用于描述目前的抽象情况,方便人工判读,因为抽象不是没有代价的,可能会不小心把核心代码抽象掉 gist.github.com/wangshouh/4f…
4
825
为昨天未完成的博客补充了最后一个案例,并且大概总结了一下如何在 dafny 内证明 solidity 的正确性,这个步骤是我目前认为正确的环节。目前我还没有证明过极其复杂的 solidity 合约机制,我认为 uniswap v3 的区间流动性手续费算法可能算最复杂的合约机制之一,这也是未来我希望证明的机制
2
1
14
2,183
之前还 vibe coding 了一个小工具来辅助抓取某一个核心不变量有关的所有函数片段,过几天可能开源一下,大概只需要十几分钟就可以拿 codex 写出来,底层用的是 slither-analyzer 来解析 solidity 合约
5
755
最近手动使用 dafny 证明了几个经典的数组排序算法,从浅入深分别是冒泡排序、快速排序和归并排序,最难证明的应该是快速排序。在写代码过程中,我写了一篇博客。由于我目前实践较少,所以博客内容不太成体系。 除了算法外,博客最后附上了一个智能合约漏洞的证明,明天应该还会再补充另一个案例。
1
5
26
4,441
部分内容参考了 The Calculus of Computation 的第六章 Program Correctness: Strategies。 目前来看,使用 dafny 写形式化证明的核心就是复制已知条件进入 loop invariant,毕竟使用的 basic path 方法会丢弃大量上下文。当然,很好的是目前来看,LLM 比我这个初学者厉害,核心性质都可以写出来
3
2
630
发现我的 128GB 内存的 MacBook Pro 插电情况下也好卡,看一下活动监控器,发现 z3 内存泄漏了 128GB,太恐怖了。为了保命直接 kill 掉了,感觉应该研究一下内存泄漏的原因,也许这是一个用 Rust 重写 z3 的好理由
3
5
2,091
最近正在读 2 本与逻辑学有关的书,一本是 The Calculus of Computation,另一本是《面向计算机科学的数理逻辑》(最近出了中文版,但我还是用的影印版)。前者强调 semantics,而后者第一章全是 natural deduction。我没有搞明白两者的异同,但《数学哲学讲义》内证明的哥德尔完备性定理解决了我的疑惑
5
13
108
10,030
《面向计算机科学的数理逻辑》的影印版目前应该只能找到二手书了,2005 年出版的,最近出了中文版
1
1
3
1,499
而《数学哲学讲义》是真心推荐所有人阅读,内容丰富且有趣,这点可以从课后习题内看到,课后习题的答案其实在前面的文本内都是出现过的。假如有计算机科学背景,建议优先阅读第五章 证明和第六章 可计算性。
1
1
6
1,290
依靠 ChatGPT 证明了一个版本的快速排序,不是很理解证明思路,还是要继续研究一下证明策略,不知道能不能使用 precondition method 获得一些启发。
4
1,341
在 Licredity 内存在 stage 机制,该机制类似 balance delta,允许用户在 unlock 内多次向合约转账。我尝试对 stage 机制进行形式化证明。从 stage 开始到某一个函数结束,中间存在无数调用路径,但是教科书告诉我们不变量可以约束状态空间,所以我实际上只是证明所有中间环节不会打破如图所示的不变量
1
1
8
1,566
为什么探索该问题?实际上是因为人类审计没有发现 stage 机制内的问题,在随后一次 LLM 审计中,LLM 指出 decreaseDebtShare 存在严重漏洞,我们随后验证认为该漏洞确实存在,原因是因为 mint 函数对 balance 的影响没有处理好。简单编写几行形式化证明,其实我们都可以发现该问题。
1
861
实际上就是因为 stage 机制依赖于 balanceOf 读取数据计算用户的代币输入,但是 licredity 内的 mint / burn 机制也会影响 balanceOf 的结果,这会导致相当程度的混淆,最后导致计算出的用户代币输入错误
681