白开水宣布NPM新星计划- Neptune Mutual
为什么你需要参加NPM新星竞赛因为它能让你在我们的社区建设工作中发挥积极作用。 Neptune Mutual项目保障了以太坊社区免受当代金融产品的网络威胁。我们的投资者网络、合作伙伴和社区都是在捍卫以太坊和其他区块链生态系统免受网络威胁的原则下形成的。 像往常一样，我们很高兴根据社区的意见和反馈，推出NPM新星大赛。此外，请密切关注即将推出的大使计划。谁是NPM新星NPM新星是像你一样的社区成员，他们为我们的社区讨论渠道做出贡献，并帮助塑造海王星互助协议的未来。作为新星，你有能力通过我们的社区平台，特别是Discord和Twitter，提高人们的认识并鼓励积极合作。获奖者如何被选中首先，你必须使用Gleam注册参加本次比赛，并完成所有要求的任务。你在Gleam上完成的可选任务将被大奖得主的评选过程纳入。 https://gleam.io/D2oed/npm-rising-stars-first-batch 在Gleam上注册完成任务之后，加入我们的Discord服务器并开始参与我们的社区对话。带来你对我们协议的想法，提出问题，提供反馈，并在其他社区成员有问题时回答他们。成为我们社...
白开水什么是永续合约？
欢迎来到我们回归基础系列的第 2 部分，我们将在其中讨论什么是永续合约？并深入了解衍生品世界。在我们进入永续合约以及它们如何主导加密市场之前，让我们绕道而行，先了解衍生品的历史、衍生品是什么以及它们的类型。 沃伦·巴菲特 (Warren Buffet *) 曾将衍生品称为“大规模杀伤性金融武器”。*虽然巴菲特似乎对衍生品没有多大信心，但没有它们，全球金融体系就无法像今天这样运作。 衍生品的历史早在货币发明之前，人们一直在进行商品和服务的交易。如果我们追溯衍生品的起源，它起源于使用粘土代币的塞缪尔人，之后欧洲人使用公平信来买卖农业。如果我们快进到18世纪的日本，他们使用大米券，可以换取现金。这种新的交易方式从太平洋地区传到了北美，1848年，芝加哥期货交易所成立。今天，利率互换、货币衍生品和结构性产品都是源于这些古老商业方法的现代交易实践。 现在，让我们深入了解什么是现代衍生品？ 衍生品是两方或多方之间签订的金融合同，其价值来自另一相关金融资产的价格。它们的基础资产决定了其定价、风险和基本期限结构。 衍生价值的资产类型衍生品类型你也可以观看 "什么是衍生品 "的数学视频，以获得直观...
白开水Neptune Mutual Incentive Testnet Interaction Guide
Neptune Mutual is an open crypto asset insurance yield protocol that enables users to purchase insurance policies to protect their digital assets from hacking and exploitation. The protocol uses parametric insurance rather than discretionary insurance. It has a simple and reliable on-chain claims process.Neptune Mutual Got You Covered Get guaranteed payouts from our parametric cover model. Resolve incidents faster without the need for claims assessment. Receive Rewards Invest stablecoin liqui...
If i had to leave my life without you near me.
白开水宣布NPM新星计划- Neptune Mutual
为什么你需要参加NPM新星竞赛因为它能让你在我们的社区建设工作中发挥积极作用。 Neptune Mutual项目保障了以太坊社区免受当代金融产品的网络威胁。我们的投资者网络、合作伙伴和社区都是在捍卫以太坊和其他区块链生态系统免受网络威胁的原则下形成的。 像往常一样，我们很高兴根据社区的意见和反馈，推出NPM新星大赛。此外，请密切关注即将推出的大使计划。谁是NPM新星NPM新星是像你一样的社区成员，他们为我们的社区讨论渠道做出贡献，并帮助塑造海王星互助协议的未来。作为新星，你有能力通过我们的社区平台，特别是Discord和Twitter，提高人们的认识并鼓励积极合作。获奖者如何被选中首先，你必须使用Gleam注册参加本次比赛，并完成所有要求的任务。你在Gleam上完成的可选任务将被大奖得主的评选过程纳入。 https://gleam.io/D2oed/npm-rising-stars-first-batch 在Gleam上注册完成任务之后，加入我们的Discord服务器并开始参与我们的社区对话。带来你对我们协议的想法，提出问题，提供反馈，并在其他社区成员有问题时回答他们。成为我们社...
白开水什么是永续合约？
欢迎来到我们回归基础系列的第 2 部分，我们将在其中讨论什么是永续合约？并深入了解衍生品世界。在我们进入永续合约以及它们如何主导加密市场之前，让我们绕道而行，先了解衍生品的历史、衍生品是什么以及它们的类型。 沃伦·巴菲特 (Warren Buffet *) 曾将衍生品称为“大规模杀伤性金融武器”。*虽然巴菲特似乎对衍生品没有多大信心，但没有它们，全球金融体系就无法像今天这样运作。 衍生品的历史早在货币发明之前，人们一直在进行商品和服务的交易。如果我们追溯衍生品的起源，它起源于使用粘土代币的塞缪尔人，之后欧洲人使用公平信来买卖农业。如果我们快进到18世纪的日本，他们使用大米券，可以换取现金。这种新的交易方式从太平洋地区传到了北美，1848年，芝加哥期货交易所成立。今天，利率互换、货币衍生品和结构性产品都是源于这些古老商业方法的现代交易实践。 现在，让我们深入了解什么是现代衍生品？ 衍生品是两方或多方之间签订的金融合同，其价值来自另一相关金融资产的价格。它们的基础资产决定了其定价、风险和基本期限结构。 衍生价值的资产类型衍生品类型你也可以观看 "什么是衍生品 "的数学视频，以获得直观...
白开水Neptune Mutual Incentive Testnet Interaction Guide
Neptune Mutual is an open crypto asset insurance yield protocol that enables users to purchase insurance policies to protect their digital assets from hacking and exploitation. The protocol uses parametric insurance rather than discretionary insurance. It has a simple and reliable on-chain claims process.Neptune Mutual Got You Covered Get guaranteed payouts from our parametric cover model. Resolve incidents faster without the need for claims assessment. Receive Rewards Invest stablecoin liqui...
If i had to leave my life without you near me.
Subscribe to 白开水
Subscribe to 白开水
Share Dialog
Share Dialog
<100 subscribers
<100 subscribers
在这篇文章中，我们将分享尝试的不是一个，而是两个以前从未做过的事情的研发过程，zkSync 2.0 的重新设计如何更高效和兼容，以及使用具有独特架构的 LLVM 的挑战作为 zk EVM。
zkSync 2.0的设计涉及到两件以前从未做过的事情：
zk EVM：对 SNARK 友好的 EVM 堆栈操作操作码（例如 popN、dup）准备数据并且不执行有意义的计算，但它们通常构成交易的相当大的成本。这种语义对于 zkSNARKs 来说是低效的，所以我们的 zkEVM 使用了不同的操作数寻址方法，但是从一个到另一个的转换需要在编译器端进行额外的工作。
通过编译成对 SNARK 友好的 zkEVM，我们可以为操作码提供更通用的操作数寻址，降低交易成本，减少证明的延迟，并提供额外的好处，例如一个块中许多交易的摊销公共数据使用。
不同的每账户数据可用性政策 在同一个地址空间中为 zkRollup 和 zkPorter 账户进行交互设计可以比作 ETH 2.0 分片但具有同步执行。此外，如果其中一个“碎片”不可用，则两者之间的交互必须可证明无法交互。
除了高效执行 Solidity 智能合约之外，让协议看起来像以太坊也是一项非常复杂的任务。
重新设计以提高效率和兼容性 我们之前讨论过我们的新设计更高效并且与以太坊兼容。以下是我们所做的一些更改：
现在可以仅使用我们的 Web3+ API 和 Ethers+ SDK 与我们的网络进行交互： 对于读取请求：
任何语言的任何兼容 web3 的框架都可以开箱即用，我们还将提供额外的 zkSync L2 特定功能 对于写请求：由于 L1 和 L2 之间的根本区别，您将不得不编写一些额外的代码（例如，zkSync 支持以任何代币支付费用，因此发送交易将涉及选择代币支付费用）
更新了内存实现，允许我们在 zkEVM 的每个周期访问更多内存。此外，每个区块对同一合约代码的所有访问现在都被“摊销”了。
增加动态定价模型：zkSync 中的 gas 很大程度上是由价格固定来证明的（例如 1 个周期 = 1 个单位），但如果用户使用公共数据，则它以单位为单位动态定价，以反映以太坊 gas 价格和以太币价格。
为了支持 Solidity 智能合约，我们将 Yul IR 转换为 LLVM IR。我们通过使所有 Yul 指令与 LLVM 框架和目标虚拟机兼容来构建 Yul 前端：zk EVM。主要挑战是我们必须按原样翻译 Yul（并在以后优化结果！）；我们不能以任何方式改变它。
虽然 Yul 语法最小且易于解析，但一些指令和模式需要变通方法才能与我们的 zkEVM 兼容。让我们深入研究几个有趣的例子：
未对齐的内存访问
特例 A：处理呼叫数据
特例 B：适配构造函数
2. 保留执行流程
未对齐的内存访问
在 EVM 中，内存使用字节偏移量进行寻址：
mload(12)：从区域 12..44 加载 32 个字节
mstore(16, X)：将 X 存储在区域 16..48
calldataload(4)：加载第一个 calldata 参数
另一方面，在 zkEVM 中，内存是通过单元偏移来寻址的，其中每个单元仍然由 32 个字节组成，但每个单元是原子的，只能作为一个整体进行读取或写入：
mov r1, 4：将寄存器r1的值存储到单元格4，即字节128..160
mov 4, r1：将单元格 4 中的值加载到寄存器 r1
为了翻译像 mload(4) 这样的指令，我们必须从单元 1 加载 28 个字节，然后从单元 2 加载 4 个字节，并使用按位运算将它们合并成一个 32 字节的值。
幸运的是，Yul 很少使用不是 32 倍数的偏移量。通常情况如下：
calldata 布局：每个参数使用签名哈希移动 4 个字节
错误消息编码：代码和描述以小于 32 字节的块形式出现
作为映射键的字符串文字通常不会占用整个 32 字节块
上述所有情况都需要单元拆分和合并，对于非常量地址，每条内存访问指令的复杂度都会增加数倍。有一些建议可以针对我们的 zk EVM 需求优化 Yul 生成器的行为，例如，将外部合约条目签名哈希存储在其自己的 32 字节块中，以及在将错误消息块写入内存之前在 Yul 中合并它们。
特例 A：处理呼叫数据
在 Solidity 合约 ABI 中，calldata 的前 4 个字节是入口签名哈希。然后，每个参数存储在偏移量 4+32n 处。
在 zkEVM 合约 ABI 中，我们向 calldata 添加了一个 252 字节的标头以及一些附加信息：
单元格中的调用数据大小
返回单元格中的数据大小
然后，我们将条目签名哈希和参数从区域 252.. 开始，并在偏移量 256、288、320 等处使用对齐的内存访问加载每个参数。
这是通过检查 calldataload(A) 指令中的地址来实现的。如果地址为零，我们从区域 224..256 加载条目签名哈希，否则，我们从区域 A+252..A+252+32 加载参数。
特例 B：适配构造函数
在 Solidity 中，构造函数参数与最后的合约字节码一起部署。在 zk EVM 中，构造函数是一个普通的合约入口，只能调用一次；在第一次执行结束时会在存储中设置一个保护标志。
保留执行流程
许多 Yul 指令已被存根以保留预期的执行流程。例如，Yul 在进行外部调用之前使用 `extcodesize` 指令检查外部合约大小。我们在调用之前不做这样的检查，所以我们总是返回 MAX_VALUE 来通过代码大小检查。其他存根指令包括 pc、callvalue、msize、balance 等。
我们的架构有一些特性，我们不得不花一些时间将其集成到 LLVM 框架中：
zkEVM 使用 256 位宽的寄存器，但 LLVM 在许多情况下本身并不支持 256 位整数
256 位是内存中的最小寻址区域，但 LLVM 硬编码假设内存寻址为 8 位字节
我们在堆栈中缺少绝对地址：所有地址都必须与堆栈指针相关，并且 LLVM 中没有这样的架构，因此我们不得不引入自定义通道来处理它（但是，我们计划在初始版本之后引入绝对地址)
VM 不提供显式读取或写入堆栈指针的能力，只能通过 push 和 pop 指令
出于安全原因，zkEVM 不支持跳转到任意目的地，仅支持代码中的静态已知地址
zkEVM 不支持有符号算术，我们为它实现了自定义降低
使用 LLVM 的主要优势之一是我们受益于他们庞大的测试套件存储库：
回归测试检查编译器生成合理的输出和优化是否按预期工作。核心 LLVM 存储库中有 36,000 个公共测试可用，我们从其中的 20,000 个中受益。（其他 16,000 个检查不同的 LLVM 后端）
可执行测试或集成测试运行编译器，但也运行编译器生成的二进制文件。在我们使用的 LLVM 测试套件存储库中，至少有 3,000 个这样的测试是公开可用的。
为了检查我们的整个编译器工作流程，我们实现了自己的可执行测试套件，目前有 1,000 个测试，使用所有支持的语言编写，包括 IR：Solidity、Zinc、Yul、LLVM IR 和 zkEVM 程序集。
我们希望您喜欢这个窗口，了解我们在编译器和 zkSync 2.0 的研发过程中所面临的挑战！
在这篇文章中，我们将分享尝试的不是一个，而是两个以前从未做过的事情的研发过程，zkSync 2.0 的重新设计如何更高效和兼容，以及使用具有独特架构的 LLVM 的挑战作为 zk EVM。
zkSync 2.0的设计涉及到两件以前从未做过的事情：
zk EVM：对 SNARK 友好的 EVM 堆栈操作操作码（例如 popN、dup）准备数据并且不执行有意义的计算，但它们通常构成交易的相当大的成本。这种语义对于 zkSNARKs 来说是低效的，所以我们的 zkEVM 使用了不同的操作数寻址方法，但是从一个到另一个的转换需要在编译器端进行额外的工作。
通过编译成对 SNARK 友好的 zkEVM，我们可以为操作码提供更通用的操作数寻址，降低交易成本，减少证明的延迟，并提供额外的好处，例如一个块中许多交易的摊销公共数据使用。
不同的每账户数据可用性政策 在同一个地址空间中为 zkRollup 和 zkPorter 账户进行交互设计可以比作 ETH 2.0 分片但具有同步执行。此外，如果其中一个“碎片”不可用，则两者之间的交互必须可证明无法交互。
除了高效执行 Solidity 智能合约之外，让协议看起来像以太坊也是一项非常复杂的任务。
重新设计以提高效率和兼容性 我们之前讨论过我们的新设计更高效并且与以太坊兼容。以下是我们所做的一些更改：
现在可以仅使用我们的 Web3+ API 和 Ethers+ SDK 与我们的网络进行交互： 对于读取请求：
任何语言的任何兼容 web3 的框架都可以开箱即用，我们还将提供额外的 zkSync L2 特定功能 对于写请求：由于 L1 和 L2 之间的根本区别，您将不得不编写一些额外的代码（例如，zkSync 支持以任何代币支付费用，因此发送交易将涉及选择代币支付费用）
更新了内存实现，允许我们在 zkEVM 的每个周期访问更多内存。此外，每个区块对同一合约代码的所有访问现在都被“摊销”了。
增加动态定价模型：zkSync 中的 gas 很大程度上是由价格固定来证明的（例如 1 个周期 = 1 个单位），但如果用户使用公共数据，则它以单位为单位动态定价，以反映以太坊 gas 价格和以太币价格。
为了支持 Solidity 智能合约，我们将 Yul IR 转换为 LLVM IR。我们通过使所有 Yul 指令与 LLVM 框架和目标虚拟机兼容来构建 Yul 前端：zk EVM。主要挑战是我们必须按原样翻译 Yul（并在以后优化结果！）；我们不能以任何方式改变它。
虽然 Yul 语法最小且易于解析，但一些指令和模式需要变通方法才能与我们的 zkEVM 兼容。让我们深入研究几个有趣的例子：
未对齐的内存访问
特例 A：处理呼叫数据
特例 B：适配构造函数
2. 保留执行流程
未对齐的内存访问
在 EVM 中，内存使用字节偏移量进行寻址：
mload(12)：从区域 12..44 加载 32 个字节
mstore(16, X)：将 X 存储在区域 16..48
calldataload(4)：加载第一个 calldata 参数
另一方面，在 zkEVM 中，内存是通过单元偏移来寻址的，其中每个单元仍然由 32 个字节组成，但每个单元是原子的，只能作为一个整体进行读取或写入：
mov r1, 4：将寄存器r1的值存储到单元格4，即字节128..160
mov 4, r1：将单元格 4 中的值加载到寄存器 r1
为了翻译像 mload(4) 这样的指令，我们必须从单元 1 加载 28 个字节，然后从单元 2 加载 4 个字节，并使用按位运算将它们合并成一个 32 字节的值。
幸运的是，Yul 很少使用不是 32 倍数的偏移量。通常情况如下：
calldata 布局：每个参数使用签名哈希移动 4 个字节
错误消息编码：代码和描述以小于 32 字节的块形式出现
作为映射键的字符串文字通常不会占用整个 32 字节块
上述所有情况都需要单元拆分和合并，对于非常量地址，每条内存访问指令的复杂度都会增加数倍。有一些建议可以针对我们的 zk EVM 需求优化 Yul 生成器的行为，例如，将外部合约条目签名哈希存储在其自己的 32 字节块中，以及在将错误消息块写入内存之前在 Yul 中合并它们。
特例 A：处理呼叫数据
在 Solidity 合约 ABI 中，calldata 的前 4 个字节是入口签名哈希。然后，每个参数存储在偏移量 4+32n 处。
在 zkEVM 合约 ABI 中，我们向 calldata 添加了一个 252 字节的标头以及一些附加信息：
单元格中的调用数据大小
返回单元格中的数据大小
然后，我们将条目签名哈希和参数从区域 252.. 开始，并在偏移量 256、288、320 等处使用对齐的内存访问加载每个参数。
这是通过检查 calldataload(A) 指令中的地址来实现的。如果地址为零，我们从区域 224..256 加载条目签名哈希，否则，我们从区域 A+252..A+252+32 加载参数。
特例 B：适配构造函数
在 Solidity 中，构造函数参数与最后的合约字节码一起部署。在 zk EVM 中，构造函数是一个普通的合约入口，只能调用一次；在第一次执行结束时会在存储中设置一个保护标志。
保留执行流程
许多 Yul 指令已被存根以保留预期的执行流程。例如，Yul 在进行外部调用之前使用 `extcodesize` 指令检查外部合约大小。我们在调用之前不做这样的检查，所以我们总是返回 MAX_VALUE 来通过代码大小检查。其他存根指令包括 pc、callvalue、msize、balance 等。
我们的架构有一些特性，我们不得不花一些时间将其集成到 LLVM 框架中：
zkEVM 使用 256 位宽的寄存器，但 LLVM 在许多情况下本身并不支持 256 位整数
256 位是内存中的最小寻址区域，但 LLVM 硬编码假设内存寻址为 8 位字节
我们在堆栈中缺少绝对地址：所有地址都必须与堆栈指针相关，并且 LLVM 中没有这样的架构，因此我们不得不引入自定义通道来处理它（但是，我们计划在初始版本之后引入绝对地址)
VM 不提供显式读取或写入堆栈指针的能力，只能通过 push 和 pop 指令
出于安全原因，zkEVM 不支持跳转到任意目的地，仅支持代码中的静态已知地址
zkEVM 不支持有符号算术，我们为它实现了自定义降低
使用 LLVM 的主要优势之一是我们受益于他们庞大的测试套件存储库：
回归测试检查编译器生成合理的输出和优化是否按预期工作。核心 LLVM 存储库中有 36,000 个公共测试可用，我们从其中的 20,000 个中受益。（其他 16,000 个检查不同的 LLVM 后端）
可执行测试或集成测试运行编译器，但也运行编译器生成的二进制文件。在我们使用的 LLVM 测试套件存储库中，至少有 3,000 个这样的测试是公开可用的。
为了检查我们的整个编译器工作流程，我们实现了自己的可执行测试套件，目前有 1,000 个测试，使用所有支持的语言编写，包括 IR：Solidity、Zinc、Yul、LLVM IR 和 zkEVM 程序集。
我们希望您喜欢这个窗口，了解我们在编译器和 zkSync 2.0 的研发过程中所面临的挑战！
No activity yet