Proof-of-Stake

微信扫码分享
从零学大语言模型 L15:Mid/Post-Training | 斯坦福CS336  2026春季

从零学大语言模型 L15:Mid/Post-Training | 斯坦福CS336 2026春季

**视频 AI 总结**:该视频深入讲解了语言模型后训练(post-training)的核心技术,包括监督微调(SFT)和基于人类反馈的强化学习(RLHF)。视频指出,预训练模型(如GPT-3)的能力有限,需要通过后训练才能实现指令遵循、安全控制和工具使用等高级功能。SFT阶段强调高质量数据的重要性,而RLHF阶段则通过奖励模型和策略优化(如PPO、DPO)来对齐人类偏好。视频还讨论了数据收集的挑战、标注者偏差、模型过优化和模式崩溃等问题,并展望了未来推理模型的发展方向。 **主要内容**: - 后训练是将基础模型(如GPT-3)转化为可用系统(如ChatGPT)的必要步骤,分为SFT和RLHF两个阶段。 - SFT阶段依赖于高质量人工标注或模型生成的数据,数据量不宜过多,但质量至关重要,需避免引入幻觉和错误知识。 - RLHF阶段通过人类反馈训练奖励模型,再使用强化学习(如PPO或DPO)优化策略,核心是平衡奖励最大化和KL正则化。 - 数据收集挑战包括标注者质量、偏差、成本以及AI标注的普及,近年来更多采用专家标注和模型蒸馏。 - 算法方面,DPO作为PPO的简化替代方案,通过直接优化偏好对来实现对齐,效果接近PPO但更易实现。 - 后训练需注意过优化、模型熵降低和校准问题,这些问题在推理模型(如o1)的发展中尤为关键。 课件与代码:https://cs336.stanford.edu/

83 0 0 2026-06-29 23:53
VibeCoding: 利用 EIP-7702批量打包 Approve与Deposit

VibeCoding: 利用 EIP-7702批量打包 Approve与Deposit

视频 AI 总结: 视频主要讲解了如何在 Token Bank 项目中利用 EIP-7702 将 approve 和 deposit 两笔交易打包成一次批量交易,并纠正了 AI 认为“无法实现”的误导。主讲人指出 AI 对新标准(如 7702)的语料库滞后,需手动分析;通过实际代码部署和演示,说明前端与 demo 网站本质相同,均可实现。最终成功添加了 7702 批量存款功能,并介绍了 MetaMask 的 5792 标准及委托合约的执行流程。 视频中提出的关键信息: 1. AI 对较新的 EIP-7702 存在知识盲区,容易产生幻觉,不能完全依赖。 2. EIP-7702 允许将 EOA 账户临时加载合约代码,使其像合约一样执行批量交易。 3. 通过 MetaMask 的 `wallet_sendCalls`(ERC-5792)接口,可以将多个调用打包成数组一次性发送。 4. 本地测试可能因缺少 MetaMask 预设的委托合约地址而困难,建议在测试网上验证。 5. 实现时需检查钱包是否支持 batch 能力,并在前端条件渲染。

11 0 0 2026-06-03 07:11
ZKP - S3M2:与 Jim Posen 探讨 SNARK 的高性能工程

ZKP - S3M2:与 Jim Posen 探讨 SNARK 的高性能工程

视频 AI 总结: 视频探讨了SNARKs高性能工程,通过利用并行计算、优化硬件资源和定制化设计,显著提升零知识证明的生成效率。 视频中提出了哪些关键信息: 1. **SNARKs协议瓶颈:** 识别了SNARKs(以STARKs为例)证明生成中的计算和内存瓶颈,如域乘法、哈希和NTT(数论变换)。 2. **CPU优化:** * **SIMD并行:** 利用单指令多数据(SIMD)技术,在CPU层面同时处理多个数据元素,提高域乘法吞吐量,应用于约束评估、PCS开启和哈希。 * **多核并行:** 将任务分配给多个CPU核心,利用共享内存和缓存机制加速计算,但NTT中的转置操作可能导致内存瓶颈。 3. **GPU优化:** * **大规模并行:** 利用GPU海量计算核心进行并行算术运算,显著提升吞吐量。 * **“喂饱野兽”原则与流水线:** 通过操作流水线(如重叠内存传输与计算)确保GPU核心持续工作,避免空闲。 * **交互性影响:** 协议中的交互轮次(如Fiat-Shamir挑战)可能限制流水线效率。 4. **集群级并行与递归:** * **分布式证明:** 将大型计算(如数十亿RISC-V周期)分解为小段,在多台服务器上并行生成独立证明。 * **递归聚合:** 通过递归方式(如二叉树结构)将小段证明聚合成最终证明,克服网络带宽限制。 * **见证生成优化:** 采用“预执行”(preflight execution)策略,先顺序记录关键数据,再并行生成见证。 5. **定制硬件:** * **ASIC/ASIP:** 为SNARKs计算设计专用芯片(如ASIC或ASIP),进一步减少指令周期、降低成本和功耗。 * **二元域优势:** 在硬件层面,二元域乘法比素数域乘法效率高出约5倍,但通用CPU/GPU难以利用。 * **FPGA:** 可编程门阵列(FPGA)可用于原型验证和特定场景生产,其二元域乘法吞吐量可与消费级GPU的素数域乘法媲美。

255 0 0 2026-03-23 08:14
精简以太坊第二部分: PQ 签名和 Poseidon

精简以太坊第二部分: PQ 签名和 Poseidon

视频 AI 总结: 本期“零知识”播客是“精益以太坊”迷你系列节目的第二集,由以太坊基金会的密码学研究员 Benedikt Wagner 和 Dmitry Korvatovich 担任嘉宾。节目深入探讨了后量子签名技术,特别是 LeanSig。该方案是一种基于哈希的多签名机制,旨在取代以太坊共识层中易受量子攻击的 BLS 签名,以实现量子安全。讨论内容涵盖了 LeanSig 的设计原理、安全权衡、编码挑战以及对核心哈希函数 Poseidon 的持续密码分析。 **视频中提出的关键信息:** 1. **核心问题与解决方案:** 以太坊共识目前使用的 BLS 签名易受量子计算机攻击。LeanSig 被提出作为一种基于哈希的后量子多签名方案,旨在提供量子安全且可聚合的替代方案。 2. **LeanSig 的工作原理:** * 它从一次性签名(one-time signature)开始,然后通过 Merkle 树构建一个可支持多次签名(例如 2^32 次,足以支持数百年)的方案。 * 聚合功能通过使用通用 SNARK(零知识简洁非交互式论证)实现,SNARK 证明了对一系列有效签名的了解,其输出即为聚合签名。 3. **设计权衡与优化:** * LeanSig 的设计涉及签名大小与性能(哈希计算量)之间的权衡。为了优化 SNARK 验证器的电路大小,通常需要增加证明者的工作量。 * “超立方体顶部”(Top of the Hypercube)优化旨在进一步减小签名并加快验证,但其复杂的编码方式在 SNARK 环境中仍面临挑战,目前正在通过新的形式化模型进行安全分析。 4. **安全分析方法:** * 为了减小签名大小,需要使用输出较小的哈希函数,这要求对方案进行更严格(tight)的安全分析。 * 研究人员正从传统的“随机预言模型”(random oracle model)转向更保守的“标准模型”(standard model),通过定义哈希函数的具体安全属性(如目标碰撞抗性、原像抗性)来证明方案的安全性。 5. **Poseidon 哈希函数:** * Poseidon 是 LeanSig 设计的核心哈希函数,目前主要关注其针对小素数域优化的新版本。 * 通过“Poseidon 倡议”(Poseidon Initiative)等项目,社区正积极对其进行密码分析,以建立对其安全性的信心。尽管已发现一些弱点,但其安全裕度仍在可接受范围内。 * 节目录制时,尚未考虑到 Mertz 和 Garcia 对 Poseidon 的最新攻击。 6. **其他相关工作:** 视频还简要提及了 ZK Summit 会议、ZK Mesh Plus 订阅服务,以及对 Plonky3 库中 Merkle 树实现进行安全分析的“十亿美元 Merkle 树”论文。

361 0 0 2026-03-09 15:00
深入探讨 Uniswap V4  Hooks 安全性

深入探讨 Uniswap V4 Hooks 安全性

视频 AI 总结: 该视频主要介绍了 Uniswap V4 的架构、设计理念以及潜在的安全威胁。演讲者来自 Composable Security,分享了他们对 Uniswap V4 的安全研究经验,并着重讲解了 V4 引入的 Hook 机制可能带来的安全风险。核心观点是 V4 虽然提供了更高的定制化和效率,但也引入了新的安全挑战,开发者需要特别注意 Hook 合约的安全性,避免潜在的攻击。 视频中提出的关键信息: 1. Uniswap V4 的目标是迁移 V2 的流动性,并提供更优的 Gas 优化和可定制性。 2. V4 采用 Singleton 模式,所有 Pool 都在一个 Pool Manager 合约中。 3. V4 引入了 Hook 机制,允许在交易的不同阶段调用自定义合约,实现高度定制化。 4. Hook 机制可能存在多种安全威胁,包括缺乏访问控制、未经授权的调用、动态 V 手续费操纵、以及升级带来的风险。 5. 开发者需要注意 Hook 合约的访问控制,避免直接调用,并验证调用者的身份。 6. 动态 V 手续费可能被恶意利用,导致交易费用异常或合约被锁定。 7. Hook 合约的升级可能引入新的安全风险,需要谨慎对待。 8. Composable Security 提供了关于 Uniswap V4 安全性的文章和最佳实践,供开发者参考。

655 0 0 2026-01-22 21:10