rt-1/781 原生账户抽象为账户可编程打开大门，StarkNet 的开发倡导者@barretodavid 提到 StarkNet 上实现手机硬钱包的思路。 以太坊上的 EOA 仅支持 Secp256k1 椭圆曲线上的签名方案 ECDSA 大部分的智能手机都不支持以太坊的椭圆曲线。 所以移动钱包需要依靠软件签署交易，移动钱包因此是热钱包。 StarkNet 原生账户抽象，支持多种椭圆曲线，签名验证高度可编程，因此基于 StarkNet/Cairo 的手机钱包完全可以变成硬钱包。 Cairo 已经有一个nistp256（用于智能手机Secure Enlave）的实现 https://github.com/spartucus/nistp256-cairo 简单来讲就是直接调用手机的加密模块来对交易进行“硬签名”。 STARK 目前有许多不同的证明系统（生成和验证证明） ，如 Halo、PLONK、Groth16、Groth09 、Marlin、Plonky2 等，它们都属于 SNARK 证明系统。证明系统存在一个证明者生成证明，一个验证者验证证明。而不同的 ZK 项目几乎都会使用不同的证明系统，StarkNet 使用的 STARK 某种意义上属于一种特别的 SNARK 。 STARK 相比 SNARK 有更多创新。它不需要和 SNARK 一样依赖“可信设置”。它还带有更简单的密码学假设，避免了对椭圆曲线、配对和指数知识假设的需要，纯粹依赖哈希和信息论，因此抗量子攻击。总体来讲 STARK 比 SNARK 更安全。 在扩展性方面，STARK 的扩展性更强。证明生成速度具备线性扩展性，验证时间和证明大小具备对数扩展性。但缺点在于生成的证明尺寸更大。但随着证明规模增加，验证成本将会边际递减——这意味证明越大，总成本越低。 https://consensys.net/blog/blockchain-explained/zero-knowledge-proofs-starks-vs-snarks/ 总结一下，相比 SNARK，STARK 更安全，平均验证时间和证明大小将随着验证规模扩大而降低，缺点在于初始证明尺寸更大，因此更适合大规模应用。 扩展性详解 证明时间线性扩展：证明人花费的时间与哈希调用的数量呈近似线性关系。 在 80 比特的安全级，STARK 每 12288 次哈希调用的证明者执行时间为 1 秒，得 12288次/S；而每 98304 次哈希调用需要 10 秒，得 9830次/S，因此，我们可以知道 STARK 的证明时间和哈希调用基本呈近似线性关系。如下图所示 https://eprint.iacr.org/2021/582.pdf **验证和证明大小对数扩展：验证时间（与证明大小）与哈希调用呈现对数关系。**如下图所示： 左图可以看出，当哈希调用从 3072 增加到 49152，验证时间从 40 毫秒增加到 60 毫秒。而当哈希调用从 49152 增加到 786432，验证时间仅从 60 毫秒增加到 80 毫秒。证明大小同理。因此，我们可得知，哈希调用次数越多，平均验证时间越短，平均证明大小也会更小（调用哈希生成哈希值/证明）。 递归证明 任何通用的、简洁的知识系统的证明/论证（特别是STARKs） 都可以用来递增地验证计算。这意味着一个计算可以产生一个证明，以证明该计算的前一个实例的正确性，这个概念被非正式地称为 “递归证明组合"或者"递归STARKs”。 换句话说，一个递归 STARK 证明者可为一个陈述生成一个证明，即系统的状态可以从 a 移到 a+1。因为证明者已经验证了一个证实 a 的计算完整性的(递归)证明，并且忠实地执行了状态 a 的计算，达到了新的状态 a+1。简而言之，你可以理解该过程将 a 和 a+1 两个证明合并为了一个证明**。如下图所示：** https://medium.com/starkware/recursive-starks-78f8dd401025 Cairo VM：验证计算正确性 Cairo VM 概述 有时候也通过 StarkNet OS/Cairo OS 的方式出现，是一个东西，不同于 EVM 执行计算，Cairo VM 本身仅为计算生成证明并验证正确性。 Cairo VM 是一个是一个采用冯诺依曼架构的 CPU VM，其编程语言也叫 Cairo，Cairo 语言基于 Cairo 汇编，因此编译效率非常高。Cairo 是 CPU Algebraic Intermediate Representation （代数中间表达）的首字母缩写。Cairo VM 包含单个 AIR 来验证这个 「CPU」 的指令集。 关于工作方式，它根据收到的输入的交易来更新系统的 L2 状态。促进（基于Cairo的）StarkNet 合约的执行。操作系统是基于Cairo的，本质上是使用 STARK 证明系统对其输出进行证明和验证的程序。StarkNet 合约可用的具体系统操作和功能可作为对操作系统的调用。 Cairo 语言概述 Cairo 是 StarkNet 的智能合约语言，基于 STARK 设计，Cairo 程序可生成 STARK 证明。 Cairo 程序是汇编代码的集合，Cairo 开发人员将以高级语言 Cairo 来编写智能合约而非 Cairo 汇编。当我们写了一个 Cairo 程序，Cairo 编译器会将 Cairo 代码编译成 Cairo 汇编，Cairo 汇编器将采用汇编代码生成 Cairo 字节码（它运行在 Cairo CPU）以在 Cairo VM 执行，当他最终运行到真实机器上还需要编译为操作码和机器代码（还有指令）。 非确定性计算 Cairo 程序的目标是验证某些计算是正确的，因此可以相比那些确定性计算走捷径。它意味着为了证明一个计算，验证者可以做一些不属于计算的额外工作。 例如，证明x=961的平方根y是在0,1,…,100的范围内。直接的方法是写一个复杂的代码，从 961 开始，计算它的根，并验证这个根是否在所要求的范围内。 伪代码如下：猜测y的值（这是不确定的部分）。计算y2并确保其结果等于x。验证y是否在范围内。并且，如果我们采取以下的计算方式。Y = SQRT(X)我们可以改为计算如下（非确定性计算）。Y*Y=X 我们可以看到，有两种可能的解决方案。+Y和-Y，而且有可能只有其中一个能满足其余的指令。 这意味着，如果没有一些额外的信息，一些开罗程序（如上述）是无法有效执行的。这种信息由我们称之为提示的东西提供。提示是 Cairo Runner 的特殊指令；用于解决不能轻易推导出数值的非确定性问题。理论上，提示可以用任何编程语言编写。在当前的Cairo实现中，提示是用 Python 写的。 关于确定性和非确定虚拟机，witness Cairo 在这里其实也会涉及到有确定性的 Cairo VM 和非确定性的 Cairo VM。前者就是正经的 zkVM，证明和验证；后者用于非确定性计算。 an accepting input to the Cairo deterministic machine, that constitutes the witness to the nondeterministic machine. Cairo 确定性 VM 的一个可接受的输入构成了非确定性 VM 的 witness，ZKP 需要将 witness 作为输入输出 proof。（NP 语句的 witness 见证是一条信息，可让您有效地验证该语句是否真实。例如，如果声明某个图中存在哈密顿环，则见证就是这样的环。给定一个环，可以有效地检查它是否是一个有效的哈密顿环，但是找到这样的环很困难） 是一个并行状态机。 内存模型：只读非确定性 只读的非确定性内存，这意味着每个内存单元的值由证明者选择，它不能随时间改变（在 Cairo 程序执行期间），是不可变的。该指令只能从中读取。我们可以将之视为一次写入的存储器：可以向一个单元写一次值，但事后不能改变它。 而且它是连续的，如果有空会被任意值填充。 ROM 优点包括 低成本，电路比 RAM 更简单 永存储， 不可篡改，数据不能修改和删除 内置函数：减少代码编译 开发者直接调用内置函数可以减少计算开销，优化开发体验，而不需要代码转换。添加内置函数不会影响 CPU 约束。这只是意味着相同的内存在 CPU 和内置函数之间共享，如图所示。 https://medium.com/@pban/demystifying-cairo-white-paper-part-i-b71976ad0108 Cairo 体系结构没有指定一组特定的内置函数。可以根据需要在 AIR （代数中间表示）中添加或删除内置函数。 CPU 架构：灵活 更加灵活，可以通过软件编程的方式无限接近 AISC 的性能（所以Cairo会做CPU？）。以 Cairo 复刻其他虚拟机。 启动加载：从哈希加载程序 程序可以将另一个程序字节码写入内存，并让 Program Counter 指向该内存段，然后运行该程序。一个从哈希启动加载的用例是，一个被称为启动加载器的程序计算并输出另一个程序的字节码，然后像之前一样开始执行它。这样验证者只需要知道程序的哈希而非完整字节码。这有两个好处： 可扩展性，验证时间和程序大小呈现对数关系，正如 STARK 部分提到的。 隐私性，验证者可以验证程序是否正确执行而无需知道计算。 连续记忆：连续访问内存地址 Cairo 有一个技术要求，程序访问的内存地址必须是连续的。例如，如果访问地址 7 和 9，那么在程序结束之前也必须访问 8（访问顺序无关紧要）。如果地址范围中存在小间隙，证明者将自动用任意值填充这些地址。通常，存在这样的间隙是低效的，因为这意味着内存在未被使用的情况下被消耗。引入太多的漏洞可能会使证明的生成对于诚实的证明者来说过于昂贵而无法执行。然而，这仍然没有违反可靠性保证——无论如何都不会产生错误的证明。 StarkNet 生态 盘点 StarkNet 生态： https://h0m83hhc6r.feishu.cn/docx/doxcnS3GGdXXc1PzKh9uTgTR73c 全链游戏 全链游戏——生产效率+消费体验的变革，基本上，有思考（各个机构和团队的文章），有实践（链上游戏项目和黑客松），有资金（融资和grant），最重要的是有一个富有活力的开发者社区。 Matchbox DAO：https://mirror.xyz/matchboxdao.eth The Future of On-Chain Gaming： https://volt.capital/blog/the-future-of-on-chain-gaming Game 2.0： https://www.guiltygyoza.xyz/2022/07/game2 重点推荐 Topology 团队，Lootreamls 。 合约钱包 合约钱包变成硬钱包的实现方法有两种。 共识层支持手机硬件。在 StarkNet（编程语言Cairo）这样原生账户抽象的 L2 上，支持多种椭圆曲线，而不是和以太坊一样只支持 ECDSA（Secp256k1），因此可以让手机的加密芯片/模块直接对交易签名（大部分手机不支持ECDSA）。因此，在原生账户抽象的 L2 上，合约钱包可以和硬钱包一样直接通过硬件签署交易。 钱包层进行签名转录。在以太坊这样非原生账户抽象的网络上，合约钱包可以签名转录。像 EIP-4337 可以自定义验证逻辑，用户用手机硬件支持的算法签名后再转换为以太坊支持的 ECDSA。 StarkNet 的开发倡导者@barretodavid，提到的在 StarkNet 上实现手机硬钱包的思路。 以太坊上的 EOA 仅支持 Secp256k1 椭圆曲线上的签名方案 ECDSA 大部分的智能手机都不支持以太坊的椭圆曲线。 所以移动钱包需要依靠软件签署交易，移动钱包因此是热钱包。 StarkNet 原生账户抽象，支持多种椭圆曲线，签名验证高度可编程，因此基于 StarkNet/Cairo 的手机钱包完全可以变成硬钱包。 https://twitter.com/barretodavid/status/1563584823884935168 Cairo 已经有一个[nistp256]( )（用于智能手机Secure Enlave）的实现。 合约钱包+全链游戏的耦合，开辟了钱包+DeFi 之外的新场景。Argent、Cartridge.gg 正在做。 链上AI 目前有 2 个机器学习项目，ML 平台 Giza 和 链上交易机器人（Rockybot by ModulusLabs）StarkNet 中文群还有另外一个。 Modulus Labs：https://www.moduluslabs.xyz/ Giza - Machine Learning in the Blockchain： https://gizatech.xyz/ StarkNet decentralization : Kicking off the discussion mirror.xyz：https://community.starknet.io/t/starknet-decentralization-kicking-off-the-discussion/711 总结下 StarkNet 与 AI+ML 为何如此登对？ZKP 允许 AI ML 链下计算，将生成证明交由他人验证。 应用范围包括：游戏、预言机、交易（自动收益）、反女巫、KYC、数据隐私；AI 模型算力挖矿。 致谢 本文由HackerDojo资助和创作。Hacker Dōjo是由Hacker共建的加密、Web3前沿技术开源知识社区。 感谢创作者Maxlion及HackerDojo。 原文链接：https://community.dorahacks.io/t/starkware/272 来源：金色财经lg...
北美站
