区块链中文技术社区 - Ethereum-优秀转载
type: channel
link: https://www.bcskill.com/index.php/category/Ethereum-优秀转载/
items: 使 Solana 用户能够访问在 Solana 上运行的 EVM dApp
items: Beam-SNARK 的工作原理
items: Polygon zkEVM bridge技术文档
items: 精选的 zkEVM 资源、库、工具等精选列表
items: Polygon zkEVM节点代码解析
items: Polygon zkEVM-Hermez 2.0简介
items: 用Hardhat在zkEVM上部署一个动态NFT
items: 区块链模块化设计是未来吗？
items: 分析0xSplits - 收入拆分协议
items: Solidity Gas 优化 - 理解不同变量 Gas 差异

使 Solana 用户能够访问在 Solana 上运行的 EVM dApp
type: item
date: 2024-12-17T11:01:33+08:00
description: 随着本白皮书的发布，Neon EVM 引入了多项功能，以统一 Solana 与部署在 Neon 上的 EVM dApp 之间的用户体验。此版本遵循Solana 网络扩展方法中描述的愿景，并描述了 Neon EVM 基础设施的发展方式。 本文描述的概念将会在 SDK 中实现，具体如下： Solana 签名支持：使 Solana 用户能够使用他们现有的 Solana 钱包签署 Neon EVM 交易，从而无需 EVM 签名和钱包。 链上内存池：引入链上系统，无需依赖外部工具即可高效地安排和执行 Neon EVM 交易。 关联 Neon 账户：创建抽象 Solana 地址的 Neon 账户，并实现 Solana 用户和 Neon EVM 之间的无缝交互。 Neon 交易的受控树：实现交易的原子和并行执行方法，管理状态变化并聚合复杂交互的结果。 基于意图的执行：提供一种处理交易意图的机制，尽管 Solana 存在局限性，但仍能提高 EVM 合约和 Solana 程序之间的互操作性。 点击此处阅读完整白皮书 挑战：为 Solana 用户解锁以太坊 dApp Solana 和以太坊是领先的 L1 区块链之一，各自都拥有活跃的 dApp 生态系统和性能优势。然而，这两个环境尚未相互交互，主要是由于编程语言、开发工具和基础设施的差异。 虽然 Neon EVM 允许 EVM dApp 为类似以太坊的用户访问 Solana 代币，但之前的解决方案涉及多个钱包的管理。在 Neon EVM 上执行交易需要使用 secp256k1 椭圆曲线的 EVM 签名，因此必须使用 MetaMask 等 EVM 钱包。这一要求对习惯于 Solana 中使用的 ed25519 签名的 Solana 用户以及无法使用 Phantom、Backpack 和 Solflare 等 Solana 钱包的用户来说是一个重大障碍。 通过下面提出的解决方案，EVM 开发人员可以通过减少碎片化和简化入职培训来原生地利用 Solana 用户群。 探索“Solana-Native”功能 白皮书介绍了 Solana 的各种原生功能。需要关注的五个关键功能包括： Neon EVM 中的 Solana 签名支持 为了消除 Solana 用户管理额外 EVM 钱包的需要，Neon EVM 修改了其交易验证流程以接受 Solana 的 ed25519 签名。此修改包括： 签名验证适配：调整 Neon EVM 以识别和验证 ed25519 签名。 自定义交易类型：利用交易类型属性定义与 Solana 签名兼容的自定义交易类型，并遵守 EIP-2718 的类型化交易信封。 从技术上讲，Solana 用户的 EVM 地址 (ethAddress) 是使用 Keccak-256 哈希函数应用于 Solana 公钥 (solanaPublicKey) 得出的。地址派生公式为： 此方法采用哈希的最后 20 个字节来形成与 EVM 兼容的地址，从而确保唯一且抗冲突的映射。然后使用 Neon EVM 中的 Solana 原生加密库来验证 Solana 签名，从而确保安全验证。 好处 Solana 用户可以使用现有的 Solana 钱包（例如 Phantom/Backpack/Solflare）签署 Neon 交易。此集成减少了用户与 Solana 上的 EVM dApp 交互所需的步骤，并将资产保留在熟悉的 Solana 钱包环境中。 使用 Solana 钱包无需转移资金，只需将 SOL 用作 gas 代币和 Solana 网络 RPC。从用户的角度来看，资产交换是通过发送 SPL 代币并接收所选资产的 SPL 代币来执行的。 创建关联 Neon 账户，统一资产管理 Neon EVM 通过整合 Solana 和 Neon EVM 生态系统来解决流动性分散问题，使用户能够与兼容 EVM 的 dApp 进行交互，而无需进行不必要的资产转移。以前，用户依靠 NeonPass 将 SPL 代币从 Solana 钱包转移到 Neon EVM 账户，这使资产管理变得复杂，流动性也变得分散。现在，随着 ERC20forSPL 合约的引入，这一过程得到了简化，该合约无缝连接了两个生态系统。 拥有 Solana 钱包的用户通过关联代币账户 (ATA) 管理其 SPL 代币。Neon EVM 使用 Keccak-256 哈希将其 Solana 公钥映射到与 EVM 兼容的地址，从而创建一个关联的 Neon 账户，其中包含与 EVM 兼容的地址、Solana 公钥、交易计数器、链标识符和内部余额的字段。 当用户与 Neon EVM 上的 dApp 交互时，ERC20forSPL 合约首先检查其内部余额。如果余额不足，它会查询 Sol…

Beam-SNARK 的工作原理
type: item
date: 2024-12-06T11:00:19+08:00
description: 零知识简洁非交互式知识论证 (Beam-SNARK) 是一种开创性的方法，它允许人们在不透露任何其他信息的情况下证明陈述的真实性。但这为什么有用呢？ 零知识证明有广泛的应用场景，例如： 1. 关于私人数据的证明陈述： 确认某人的银行余额超过某个限额，但不透露具体金额。 核实银行在过去一年内没有与特定实体进行过交易。 匹配 DNA 样本但不透露完整的基因图谱。 显示高于一定值的信用评分但不透露详细信息。 2. 匿名授权 证明用户有权访问网站的限制区域，而无需分享其身份（例如登录凭据）。 确认在授权地区的居住权但不透露具体位置。 在不透露身份的情况下验证有效地铁通票的所有权。 3. 匿名支付： 无需关联身份即可进行付款。 不披露收入而纳税。 4. 外包计算： 委托复杂的计算，同时确保结果正确，无需重复工作。 将区块链模型从通用计算转变为一方计算、其他方验证的模型。 零知识证明的底层数学和密码学简直就是奇迹。自 1985 年开创性的论文“交互式证明系统的知识复杂性”以来，该领域已经活跃了四十多年。非交互式证明的引入在区块链环境中尤为关键。 在任何零知识证明系统中，都有两个关键参与者： 证明者：想要让验证者相信某个陈述的真实性的人。 验证者：无需获取任何额外知识即可检查证明者主张的有效性的人。 该系统必须满足三个核心属性： 完整性：如果陈述是真实的，则证明者可以说服验证者。 健全性：作弊的证明者无法让验证者相信错误的陈述。 零知识：交互仅揭示陈述是否真实，而不揭示其他任何内容。 Beam-SNARK 将这些原理应用于通用计算，为实际应用提供了一个优雅的解决方案。 证明的媒介 为了理解 Beam-SNARK，让我们从一个简单的例子开始，而不深入研究零知识或交互性。 假设我们有一个 10 位的数组，并且我们想要向验证者（例如，程序）证明所有位都设置为 1。 假设我们有一个长度为 10 的位数组，并且我们想要向验证者（例如程序）证明所有这些位都设置为 1。 验证者每次只能检查一位。为了验证该声明，验证者可以按随机顺序检查位： 一次成功检查后，验证者对该声明的信心为 10%。 如果某个位为 0，则该断言立即被推翻。 为了获得更高的置信度（例如 50% 或 95%），验证者必须执行更多检查，与阵列的大小成正比。这种方法对于大型数据集来说不切实际。 相反，我们可以利用具有独特属性的多项式。多项式在图形上显示为曲线，由数学方程定义。 上图曲线对应多项式：f(x) = x³ — 6x² + 11x — 6。多项式的次数由其 x 的最大指数决定，在本例中为 3。 多项式有一个优点，即如果我们有两个次数最多为 d 的不相等多项式，它们最多只能在 d 个点处相交。例如，让我们稍微修改一下原始多项式 x³ — 6x² + 10x — 5，并将其可视化为绿色： 如此微小的变化会产生截然不同的结果。事实上，不可能找到两个不相等的多项式，它们共享一条连续的曲线块（单点块的情况除外）。 此属性源自查找公共点的方法。如果我们想找到两个多项式的交点，我们需要使它们相等。例如，要找到多项式与x轴的交点（即f ( x ) = 0），我们使x ³ — 6 x ² + 11 x — 6 = 0相等，并且该等式的解将是这些公共点：x = 1、x = 2 和x = 3，您也可以清楚地看到，在上图上蓝色曲线与x轴线相交的位置，情况确实如此。 同样，我们可以将原始多项式和修改后的多项式相等来找到它们的交点。 所得到的多项式是 1 阶的，显然有一个解x = 1。因此只有一个交点： 对于任意次数为d 的多项式，任何此类方程的结果始终是次数最多为d的另一个多项式，因为没有乘法可以产生更高的次数。例如：5 x ³ + 7 x ² — x + 2 = 3 x ³ — x ² + 2 x — 5，简化为 2 x ³ + 8 x ² — 3 x + 7 = 0。代数基本定理告诉我们，次数为d 的多项式最多可以有d 个解（更多内容见下文），因此最多有d 个共享点。 因此，我们可以得出结论，在任意点处对任何多项式的求值类似于对其唯一身份的表示。让我们在x = 10 处求值示例多项式。 事实上，在所有要评估的x选择中，只有最多 3 个选择在这些多项式中具有相同的评估，而所有其他选择都会有所不同。 这就是为什么如果证明者声称知道某个多项式（无论其度数有多大），而验证者也知道的话，他们可以遵循一个简单的协议： 验证者为x选择一个随机值，并在本地评估多项式 验证者将x提供给证明者，并要求其计算相关多项式 证明者在x 处评估多项式，并将结果提供给验证者 验证者检查本地结果是否等于证明者的结果，如果是，则该语句具有很高的置信度 例如，如果我们考虑x的整数范围从 1 到 1⁰⁷⁷，则评估不同的点数为 1⁰⁷⁷ — d…

Polygon zkEVM bridge技术文档
type: item
date: 2023-07-28T11:59:35+08:00
description: 1. 引言 区块链互操作性是指链A与链B交互数据的能力。近年来区块链生态快速扩张，出现了大量具有不同属性的区块链网络，互操作性是区块链设计时的一个重要考虑指标。不具有互操作性，网络具有孤立于更大生态的风险，为此，激励了项目方研究和开发互操作性解决方案。每种互操作性解决方案具有不同的权衡和底层技术。本文由Polygon团队提供的解决方案，为Polygon zkEVM L2网络提供了原生的互操作性。 bridge为基础设施元素，允许L1与L2之间进行资产迁移和通信。从用户角度来看，bridge可在不改变资产数量或资产功能的情况下，将资产由网络A转移至网络B；bridge也可以在网络间发送data payload（即跨链消息传递）。 Polygon zkEVM这样的L2 rollups，其L2 State Transitions和交易的数据可用性 均由L1合约来保证，因此，若正确设计L2架构，可仅依赖于合约逻辑来同步bridge的两端，而不需要可信的链下relayer来跨网络同步bridge两端。需注意的是，本bridge方案必须在L2层包含相应的设计。 如图1所示，bridging interface为部署在L1和L2网络上的bridge合约，用户可用于： bridge assets（1）：在“origin”网络lock某资产，在“destination”网络的bridge合约中claim时，会mint出该资产的representative token。 bridge assets的逆操作（2）：burn某资产的representative token，然后在“origin”网络中unlock其原始资产。 跨链通讯channel（3）：在L1和L2之间相互发送data payload。 2. Exit Merkle trees bridge中包含了名为Global Exit Merkle Tree（GEMT）的默克尔树。在GEMT树中，每个叶子节点表示了特定网络的Exit Merkle Tree（EMT）.GEMT树中仅包含了2个叶子节点，一个对应为L1 EMT root，另一个对应为L2 EMT root。GEMT树的结构如图2所示： GEMT为固定只有2个叶子节点的常规默克尔树，而EMT为append only sparse Merkle Trees（SMT）且具有固定的depth（Polygon zkEVM中设计depth为32）。SMT为大量使用的默克尔树，可在链上高效使用——详情见附录A。 特定网络EMT的每个叶子节点，表示了从该网络往外 bridge某资产（或某资产的representative token）或 发送某消息 的意图。EMT每个叶子节点为如下参数的abi encoded packed structure的keccak256哈希值 uint8 leafType：0表示asset，1表示message。 int32 originNetwork：为原始资产所属的Origin Network ID。 address originAddress：若leafType=0，则为Origin network token address，其中“0x000…0000”保留为ether token address；若leafType=1，则为message的msg.sender。 uint32 destinationNetwork：为bridging的destination网络ID。 address destinationAddress：为目标网络中接收bridged asset的收款方地址。 uint256 amount：bridge的token或ether数量。 bytes32 metadataHash：为metadata哈希值。metadata将包含所转移资产信息或所转移message payload信息。 一旦某leaf添加到EMT中，将计算新的EMT root，以及新的GEMT root。GEMT root将在网络间同步，使得可在对方网络中证明leaf inclusion，并完成bridge操作。 3. 合约架构 大多数bridge架构都使用在双方网络上的智能合约来实现。但是，为同步二者的GEMT，有一部分bridge逻辑必须与L2 State管理架构进行集成。因此，为理解本brIdge方案，还需要考虑L2 State管理中涉及到的链下角色——如Sequencer、Aggregator以及PolygonZkEVM.sol合约。 此外，bridge架构中还包含以下元素： PolygonZkEVMBridge.sol合约：为bridging interface，允许用户与该bridge进行交互，并进行bridgeAsse…

精选的 zkEVM 资源、库、工具等精选列表
type: item
date: 2023-04-02T15:41:50+08:00
description: Awesome zkEVM zkEVM is a Fully EVM equivalent and zk friendly virtual machine. Contents Awesome zkEVM Contents Article - Video Rollup zkEVM zk-hardware Zero-Knowledge-Proofs zk-SNARK Plonk Halo2 Resources - libraries, tools Early Rollup Scroll and Appliedzkp(PSE) Polygon Hermez Polygon Zero zkSync StarkWare Zero-Knowledge-Proofs Halo2 zkp Acceleration Different Solutions Native zkEVM Compiler-Based zkEVM Transpiler-Based zkEVM Other Contributing Article - Video Rollup An Incomplete Guide to Rollups - vitalik, Introducing Rollup. A rollup-centric ethereum roadmap - vitalik, rollup-centric ethereum roadmap. How Zk-Rollups Work - How barry whiteHat's rollup works. zkEVM zkEVM - Scroll zkEVM. zkEVM Architecture - Scroll & EF zkEVM Architecture. ZKVerse: Deep Dive Into Polygon Hermez 2.0 - Deep into zkEVM of polygon hermez. zkEVM circuit arithmetization - zkEVM circuits and EVM circuit, yezhang. The different types of ZK-EVMs zk-hardware Hardware Acceleration for Zero Knowledge Proofs - Hardware for ZKPs. Zero-Knowledge-Proofs zk-SNARK Introduction to zk-SNARKs with Examples - Get started to learn zk-SNARK by example. Why and How zk-SNARK Works - In-depth SNARK mechanism and understanding. Plonk Understanding PLONK ZK Study Club - Plonk with Zac Williamson Multiset checks in PLONK and Plookup Halo2 Halo and more: exploring incremental verification and SNARKs without pairings Resources - libraries, tools Early Rollup idn3 rollup - iden3 rollup implement. barryWhiteHat rollup - First rollup implemented by barryWhiteHat. Scroll and Appliedzkp(PSE) zkEVM-spec zkEVM-circuit zkEVM-document Scroll's architecture Polygon Hermez Polygon Hermez zkEVM Hermez document Polygon Zero Plonky2 zkSync zksync v1 - zksync v1 source code. compiler-solidity - zkSync v2 compiler. zksync v2 portal - zksync v2 faucet, Goerli network. StarkWare Awesome-starknet - A curated list of starkNet resources. Warp:transpile solidity to cairo Zero-Knowledge-Proofs Awesome-zkps - A curated list of zkps reso…

Polygon zkEVM节点代码解析
type: item
date: 2023-04-01T16:10:13+08:00
description: 1. 引言 源代码：https://github.com/0xPolygonHermez/zkevm-node （Go语言） Polygon zkEVM节点提供的主要服务模块有： 1）JSON-RPC服务 2）Sequencer服务 3）Aggregator服务 4）Synchronizer服务 5）Broadcast服务 2. JSON-RPC服务 以太坊JSON-RPC接口 与 Polygon zkEVM中的JSON-RPC接口 对比情况为： 序号 RPC接口名 以太坊 Hermez 2.0 备注 1 GetBlockByHash √ √ 2 GetBlockByNumber √ √ 3 GetBlockTransactionCountByHash √ √ 4 GetBlockTransactionCountByNumber √ √ 5 getUncleCountByBlockHash √ √ 6 getUncleCountByBlockNumber √ √ 7 ChainId √ √ 8 Syncing √ √ 9 Coinbase √ X 10 Accounts √ X 11 BlockNumber √ √ 12 Call √ √ 13 EstimateGas √ √ 14 CreateAccessList √ X EIP-2930：新交易类型，需以更贵的方式访问清单（地址或storage keys）外的内容。 15 GasPrice √ √ 16 MaxPriorityFeePerGas √ X 17 FeeHistory √ X 18 NewFilter √ √ 19 NewBlockFilter √ √ 20 NewPendingTransactionFilter √ √ 21 UninstallFilter √ √ 22 GetFilterChanges √ √ 23 GetFilterLogs √ √ 24 GetLogs √ √ 25 Mining √ X 26 Hashrate √ X 27 GetWork √ X 28 SubmitWork √ X 29 SubmitHashrate √ X 30 Sign √ X 31 SignTransaction √ X 32 GetBalance √ √ 33 GetStorageAt √ √ 34 GetTransactionCount √ √ 35 GetCode √ √ 36 GetProof √ X 37 SendTransaction √ X 38 SendRawTransaction √ √ 39 GetTransactionByHash √ √ 40 GetTransactionByBlockHashAndIndex √ √ 41 GetTransactionByBlockNumberAndIndex √ √ 42 GetTransactionReceipt √ √ 43 GetCompilers √ √ 44 GetUncleByBlockHashAndIndex √ √ 45 GetUncleByBlockNumberAndIndex √ √ 46 ProtocolVersion √ √ Hermez 2.0（zkEVM）除实现了以上与以太坊兼容的RPC接口之外，还额外实现了一些与state交互、与pool交互的接口： // jsonRPCTxPool contains the methods required to interact with the tx pool. type jsonRPCTxPool interface { AddTx(ctx context.Context, tx types.Transaction) error GetPendingTxs(ctx context.Context, isClaims bool, limit uint64) ([]pool.Transaction, error) GetGasPrice(ctx context.Context) (uint64, error) GetPendingTxHashesSince(ctx context.Context, since time.Time) ([]common.Hash, error) } // gasPriceEstimator contains the methods required to interact with gas price estimator type gasPriceEstimator interface { GetAvgGasPrice(ctx context.Context) (*big.Int, error) } // …

Polygon zkEVM-Hermez 2.0简介
type: item
date: 2023-04-01T10:37:47+08:00
description: 1. 引言 前序博客有：ZK-Rollups工作原理 近期，Polygon团队开源了其Hermez 2.0 zkEVM代码，公开测试网即将上线：https://github.com/0xpolygonhermez（Go/C++等等） 上图源自 Jordi 2022年10月分享Technical Details of the Opcode Compatible zkEVM by Jordi Baylina | Devcon Bogotá。 使用ZK proofs对以太坊扩容的基本方法是构建ZK rollup，这是一种Layer 2协议，它“rollup”了大量交易，并使用单个ZK validity proof 向以太坊主网证明了所有交易。 采用ZK rollup实现以太坊扩容的优势明显： 1）以单笔交易 代替了 很多笔交易 2）增加了交易吞吐量 3）节约了手续费 4）降低了延迟等待 Polygon Hermez 2.0 zkEVM与以太坊主网EVM兼容。可将以太坊主网的智能合约部署在Polygon zkEVM中，可共用以太坊现有的开发工具和套件。 2. 何为Hermez 2.0？ Hermez 1.0为以太坊第一个去中心化ZK Rollup，于2021年3月上线，可实现2000tps，足以满足ETH及ERC-20 token转账需求。 Hermez 2.0定位为zero-knowledge Ethereum Virtual Machine（zkEVM）—— 可以透明方式运行以太坊交易 并 为智能合约附加zero-knowledge-proof validations。为此，需要重建 透明部署现有以太坊智能合约的所有EVM opcodes。 相比于Hermez 1.0，Hermez 2.0的最主要功能是提供智能合约支持。 Polygon Hermez 2.0总体架构为： Polygon zkEVM中包含的主要元素有： 1）共识算法 2）zkNode软件 3）zkProver 4）LX-to-LY Bridge 5）Sequencers和Aggregators（需要这2个角色 以达成网络共识） 6）Hermez 2.0网络中的活跃用户，以创建交易 根据Asif Khan 2023年2月10日twitter，上面Polygon zkEVM架构中主要有四大部分组成： 1）zkNode（Synchronizer、Sequencer&Aggregator角色，以及GRPC）：客户端可启用Sequencer角色synchronization，或者是，Aggregator角色synchronization。 1.1）Synchronizer：负责获取Sequencers所提交的所有数据（transactions） + 获取Aggregators所提交的所有数据（validity proofs）。 1.2）Sequencers：以Sequencer模式运行zkEVM节点，可为Trusted或Permissionless模式。 1.2.1）Sequencers会：接收L2交易+L2用户支付的交易手续费 -》 对L2交易进行排序 -》生成batches -》 以sequences的形式将batches提交到Consensus Contract的storage slots。 1.2.2）Sequencers的经济模型为：向L1提交有效交易，以获利。 transaction pool中会采用排序算法，选择利润最丰厚的交易进行处理。 向L1提交batches时，需以MATIC支付手续费。 1.3）Aggregators：以Aggregator模式运行zkEVM节点。 1.3.1）Aggregators会：从L1中获取Sequencer提交的L2 batches -》将这些L2 batches发送给zkProver -》生成ZK proof以证明该batch的完整性。 Aggregator会使用特殊的链下EVM解析器来生成ZK proofs。 1.3.2）Aggregators的经济模型为： Sequencers提交L2 batch所支付的MATIC手续费，将给为该batch提供ZK proof的Aggregator。 随着需求的增加，所需的MATIC手续费将增加，从而激励Aggregators生成可验证的validity proof Aggregators需平衡2方面的成本：向L1提交validity proof交易成本；运行aggregator节点和zkProver服务器成本 2）Consensus Contract（PolygonZkEVM.sol）：会将Sequencers提交的L2 batches存储在PolygonZkEVM.sol合约内，创建a…

用Hardhat在zkEVM上部署一个动态NFT
type: item
date: 2023-03-30T22:29:03+08:00
description: 使用Hardhat在zkEVM Testnet上部署一个Onchain的SVG动画NFT 什么是zkEVM 简而言之，Polygon zkEVM是一个二级扩容解决方案，旨在实现EVM-equivalence（等效），并允许你使用现有的Solidity代码更便宜、更快、更安全地部署合约到它。 想进一步深入了解它吗？请看我的另一篇文章：如何将ERC20代币合约部署到zkEVM Testnet。 准备网络与Token 建议使用Polygon zkEVM Bridge 站点，将网络添加到我们的钱包，并将 Goerli Token 桥接到 zkEVM Testnet： 环境要求 在我们开始之前，请确保你的电脑上已经安装了以下依赖：NVM或Node v18.15.0，并且已经配置了钱包，并且goerli 测试网代币被桥接到了zkEVM Testnet。如果你想了解如何做到这一点，请查看我的另一篇文章如何将ERC20合约部署到zkEVM Testnet。 用Hardhat部署合约 让我们建立一个ERC721 NFT，并通过Hardhat将其部署到zkEVM。 为了确保我们从新开始，我们将利用Hardhat模板生成一个基本的TypeScript项目。 # Create our project folder mkdir zkevm-erc721-hardhat; cd zkevm-erc721-hardhat; npx hardhat; # Expected Output: # Ok to proceed? (y) y # 888 888 888 888 888 # 888 888 888 888 888 # 888 888 888 888 888 # 8888888888 8888b. 888d888 .d88888 88888b. 8888b. 888888 # 888 888 "88b 888P" d88" 888 888 "88b "88b 888 # 888 888 .d888888 888 888 888 888 888 .d888888 888 # 888 888 888 888 888 Y88b 888 888 888 888 888 Y88b. # 888 888 "Y888888 888 "Y88888 888 888 "Y888888 "Y888 # # Welcome to Hardhat v2.13.0 # # ? What do you want to do? … # Create a JavaScript project # ❯ Create a TypeScript project # Create an empty hardhat.config.js # Quit # # ✔ What do you want to do? · Create a TypeScript project # ✔ Hardhat project root: · /path/to/zkevm-erc721-hardhat # ✔ Do you want to add a .gitignore? (Y/n) · y # ✔ Do you want to install this sample project's dependencies with npm (hardhat @nomicfoundation/hardhat-toolbox)? (Y/n) · y 接下来，让我们安装依赖项: npme install; npm install @openzeppelin/contracts dotenv; 创建我们的NFT 我们这里的NFT，将通过引入一个动画的SVG来使它突出一点。 首先删除默认生成的模板化合约，并在其目录上创建一个新的合约。 rm contracts/Lock.sol; touch contracts/zkEVMNFT.sol; 在该文件中，复制并粘贴以下NFT solidity代码。 文件： ./contracts/zkEVMNFT.sol // SPDX-License-Identifier: MIT pragma solidity ^0.8.9; // Imports // ======================================================== import "@openzeppelin/contracts/token/ERC721/ERC721.sol"; import "@openzeppelin/contracts/utils/Strings.sol"; import "@openzeppelin/contracts/utils/Base64.sol"; // Cont…

区块链模块化设计是未来吗？
type: item
date: 2023-03-30T18:45:00+08:00
description: 如何使用模块化可能是突破不可能三角的一个途径。 介绍 大约十年前，世界见证了移动智能手机的增长。当时，一些大公司认为他们可以通过引入模块化架构来彻底改变智能手机。2013 年，谷歌发布了 Project Ara，这是一款采用模块化设计的新型智能手机。与今天由密封的铝和玻璃片制成的“单体”手机不同，Ara 允许用户以多种方式定制他们的手机，使所有基本部件都可以模块化。你不会被迫频繁升级到新手机。相反，你可以根据自己的喜好简单地为旧手机添加最好的新部件。可悲的是，模块化并没有在手机生态系统中取得成功，这个概念仍然是一段几乎被遗忘的技术历史。 模块化智能手机可以作为模块化区块链的警示故事，因为尽管当前工具存在合理的缺点，但新的和令人兴奋的解决方案的炒作并不能保证长期的胜利。然而，就区块链而言，用户对可扩展性的需求已经在推动开发人员构建和采用模块化架构。这种需求使得模块化区块链架构不太可能与模块化智能手机那样，遵循相同的命运。 但究竟什么是模块化区块链架构？我们如何确保这些解决方案不会成为另一个 Project Ara？这篇文章希望能回答所有这些问题。 单体和模块化 在进一步深入研究之前，让我们梳理一下单体架构和模块化架构之间的区别。介绍这个概念的最简单方法是举一个类似而熟悉的概念的例子。正如手机有一些核心部件，比如摄像头、电池和触摸屏，区块链也有核心部件。 iPhone 是“单体”手机的一个很好的例子。它配备了使用手机所需的所有部件，并没有提供太多定制选项。当然，你可能无法对内部进行太多定制，但它既流畅又快速。但是，有时你可能希望进一步自定义你的手机。假设随着岁月的流逝，新手机配备了更好的相机。过时手机的其余部分可能工作正常，但使用现有的相机，你无法获得新手机那样的体验。 使用模块化架构，你不必购买全新的手机。相反，你可以像乐高积木一样更换相机，然后换上更好的相机。 Google 的 Project Ara 是模块化手机的一个例子。这款手机由积木制成，可以根据你的选择换入和换出零件。只要有兼容的部件，Ara 都会支持。 与智能手机一样，区块链由多个基本组件组成；这些组件如下所示： 共识 区块链的共识层通过计算机网络就链的状态达成共识来提供排序和最终性。 执行 该层通过运行指定的代码来处理交易。它也是用户通常与区块链交互的地方，例如通过签署交易、部署智能合约和转移资产。 结算 结算层用作验证在第 2 层执行的活动的平台，例如Rollup以及争议解决。最重要的是，它是记录实际区块链最终状态的地方。 数据可用性 验证状态转换是否有效所需的数据应发布并存储在该层上。在发生攻击或操作失误，区块生产者未能提供交易数据的情况下，这应该是容易检索和验证的。 简而言之，单体式区块链在单个软件中自行执行所有这些任务，而模块化区块链将它们分成多个软件。现在，你可能想知道一次处理所有这些任务的区块链有什么缺点？ 这又回到了古老的问题，即可扩展性不可能三角困境。 可扩展性不可能三角困境表示区块链只能具有以下三个特征中的两个：去中心化、安全性和可扩展性。 现有的（新的）单体区块链倾向于针对三角的安全和可扩展进行优化。比特币和以太坊更加强调去中心化和尽可能安全。但都是有代价的。去中心化区块链通常没有高带宽来执行交易。以太坊每秒最多处理 20 笔交易，而比特币的处理能力甚至更低。如果我们想在全球范围内使用这些协议，每秒 20 个交易是远远不够的。一些单体链至少在理论上，可以使我们更接近全球规模，因为它们的 TPS 和总吞吐量是足够的。然而，他们往往缺乏去中心化，而这是区块链技术的核心原则。 模块化架构的目的是将区块链的一些工作外包出去，在保持去中心化的同时做出更多性能更高的链。让我们讨论一下以太坊，并讨论它有望如何利用模块化。 以以太坊为中心的生态系统 大多数第 1 层区块链 现在的以太坊是一个单体的区块链。今天大多数其他第 1 层区块链也将被归类为单体区块链。就像 iPhone 的例子一样，单体区块链的某些功能有时会开始落后于较新的替代方案，导致在对比最新和最具创新性的第 1 层时流失开发人员和消费者。为了解决以太坊目前在吞吐量方面的瓶颈，开发人员正在构建Rollup执行层以增加交易带宽。 模块化执行层 示例：Optimism, Arbitrum, Fuel, Scroll, ZkSync Rollups 作为执行层是当今以太坊上使用最广泛的扩容方法。Rollups 是独立的区块链，具有更高的交易执行性能，其最终结果在以太坊上结算，以有效继承其（更好的）安全性和去中心化。 在高层次上，Rollup只是一个区块链，它将其区块的结果发布到另一个区块链。然而，这只是Rollup的一个组成部分，因为你还需要欺诈和有效性证明以及一种无许可插入交易的方法。Rollups 通…

分析0xSplits - 收入拆分协议
type: item
date: 2023-03-20T21:50:08+08:00
description: 技术背景 很多时候，我们需要把一份收入（金额）拆分到不同的地址，而又不想让付款人（通常是用户）承担拆分收入部分的 GAS费用， 0xSplits 的架构及解决思路值得我们参考。 本文先介绍了0xSplits 是什么，0xSplits 采用的架构是怎么样的，同时介绍了几种其他的拆分方式可能带来的问题，另外还有一些0xSplits在 Gas 优化上的做法。 0xSplits是什么 0xSplits 是链上收入拆分的协议， 它是一个智能合约，允许你将任何付款拆分到许多收款人，例如，它可以用于NFT版税。EIP-2918允许你只指定一个地址作为收款人，但如果你把这个地址设置为0xSplits地址，你就可以有很多个收款人。 0xSplits由一个主合约组成，可以创建许多子克隆合约（SplitWallet）。 你通过调用主合约创建一个新的拆分（split） 它创建一个负责接收ETH的子合约 在需要接收ETH的地方使用子合约的地址 译者注：克隆合约是使用同一份代码，创建（复制）多个出合约， 每个合约都有自己的状态。 这里是子克隆合约的代码，你可以看到，它非常简单。它可以接收ETH，并且有一个函数可以将ETH转移到主合约， 0xSplits也支持ERC-20，但省略了这部分代码 但收到的ETH如何拆分给接收者？这就是主合约的任务（为了便于阅读，代码做了修改）： 所以，资金是静止不动的，直到有人明确地调用 distributeETH。但为什么有人会浪费Gas来调用这个函数呢？答案是distributorFee（分配费用）。这是在创建拆分时设置的，谁调用distributionETH就归谁。 这种激励性的代码调用是必要的，因为EVM没有周期任务（cron ）或回调来定期分配资金，一切都需要由个人或链外机器人发起，distributorFee有点类似于CryptoKitties合约中的autoBirthFee。 为什么0xSplits会选择这种架构？还有，为什么不在收到资金的时候立即分发？这是我们这篇文章的主要想解决的问题。 0xSplits 架构 你可以在Etherscan找到0xSplits的代码 克隆SplitWallet合约接收付款并持有资金，直到它们被调用，将资金转移到主合约。 分销商（distributor）被激励在主合约中调用distributeEth，这将把资金从克隆合约转移到主合约中，同时也将支付/分成。 但是在这一点上，资金仍然存放在主合约中（合约有一个从收款人地址到余额的映射）。为了实际接收资金，用户必须调用主合约中的withdraw函数。 此架构的可能替代方案 现有的设定是相当复杂的：克隆合约接收付款，分销商（distributor）将这些资金从克隆合约转移到主合约，并将资金分给接收者。但是收款人仍然需要调用withdraw来接收实际拆分到的资金。所以，端到端的用户流程并不是完全自动化的（另外，有些钱会被分销商收取）。 为什么0xSplits需要如此复杂的设置？让我们来看看其他的方法，以及它们为什么不可行。 若在收到资金时进行拆分？ 为什么不在收到资金的同一函数中进行拆分呢？也就是说，不在合约中保存资金， 而是立即分配，这里有2个原因： 付款人需要提供额外的Gas 它破坏了互操作性。付款人不能再直接将ETH转账（transfer）到克隆合约中。而是要求付款人将不得不调用合约上的一个特定函数（来进行拆分），这会破坏互操作性。你可能会说只要重写receive函数，但receive函数经常受2300个Gas限制，这意味着你不能在其函数中进行大量的转账。 若使用共享合约而不是克隆合约呢？ 为什么没有一个共享的合约，为所有可能的拆分接收所有的付款？这将摆脱克隆（创建新合约），但它并不奏效，因为当共享合约收到付款时，它不知道付款是要进行怎样的拆分。 将distributeEth和withdraw合二为一呢？ 为什么不把整个过程端到端自动化，让分销商在一个函数中执行这2个操作？主要是因为安全问题。强烈建议使用pull over push - 即让用户手动拉取他们的自己资金，而不是把资金自动推送他们。 为什么 "推（push）"被认为是一种安全风险？阅读下面的链接以获得完整的答案，但简而言之，这是因为不是所有的接收者都能保证正确处理ETH的接收。一些恶意的行为者可能会部署一个智能合约，在 receive 功能中进行回退(revert)。因此，如果至少有一个接收者回退(revert)，整个操作就会回退(revert)。 参考阅读文章：Pull over Push 将转移以太坊的相关风险转移到用户身上。 如果你想出另一种替代架构，请告诉我（在评论中这里）。 我认为0xSplits为他们所针对的使用场景选择了正确的架构--这就是成为DeFi生态系…

Solidity Gas 优化 - 理解不同变量 Gas 差异
type: item
date: 2023-03-15T17:08:47+08:00
description: 本文我们来尝试进行 RareSkills Gas 优化的一个挑战，完成这个挑战可以学习到更多 Gas 技巧。 以下是 Distribute 合约，合约的作用是向 4 个贡献者平均分配 1 ETH， 代码如下 // SPDX-License-Identifier: GPL-3.0 pragma solidity 0.8.15; contract Distribute { address[4] public contributors; uint256 public createTime; constructor(address[4] memory _contributors) payable { contributors = _contributors; createTime = block.timestamp; } function distribute() external { require( block.timestamp > createTime + 1 weeks, "cannot distribute yet" ); uint256 amount = address(this).balance / 4; payable(contributors[0]).transfer(amount); payable(contributors[1]).transfer(amount); payable(contributors[2]).transfer(amount); payable(contributors[3]).transfer(amount); } } 合约代码：https://github.com/RareSkills/gas-puzzles/blob/main/contracts/Distribute.sol 这个合约默认情况下，所需 GAS 是 71953， 需要优化到 57044， 以便通过测试用例，测试用例代码在这里。 这是默认运行的截图： 在原始合约上运行测试结果 挑战的要求是仅修改合约Solidity代码来使 distribute 下降到57044， 因此不可以修改优化器或solidity版本、不可以修改测试文件，也不使用huff/yul/bytecode 层面的优化，也不变更函数属性（不能使函数为 "payable"）。 在进一步阅读之前，请确保你自己先尝试解决这个难题，它真的很有趣，而且能让你学到东西。 让我们来优化吧! 让我们先做一些明显的事情。 变更变量为不可变（immutable）变量，而不是存储变量（节省 10710Gas--因为不可变变量是作为常量嵌入合约字节码的，而不是从存储中读取）。 用 send 取代 transfer（节省108 Gas--因为send没有检查转账是否成功）。 用endTime代替currentTime (节省了69个Gas - 在构造函数中进行时间计算) 以下是修改后的合约： 这样我们就可以让Gas 节约到61066，已经比原来的好了10887，但仍比目标值高出 4千， 需继续努力。 那么，还有什么诀窍呢？ 这个挑战有一个特别的技巧，应该教给你。而这是一种通过SELFDESTRUCT向地址发送ETH的老方法： 通过Selfdestruct 解谜, 仅仅这一招就为你节省了4066*的Gas，并且达到了目标! 但如果继续深入呢？ 每一个理智的优化总是有其疯狂的邪恶兄弟（作弊）......让我们看看我们能把这个推到什么程度! 让合约自毁（selfdestruct）感觉像是在作弊 -- 为什么你会有一个这样的合约，在第一次调用分发后就不存在了呢？不过测试通过，所以我想这是允许的......？ 让我们看看还有什么（真正的作弊）能让测试通过，但又能优化更多Gas。 让contributors成为常数，而不是不可变（immutable）（节省24个Gas - 因为Hardhat地址总是相同的，所以可以这样做，对吧？ 使金额恒定为0.25ETH，而不是从余额中计算（节省了106个Gas -- 因为在测试中金额总是相同的，所以为什么不这样做呢？） 使用Assembly来做call，而不是通常的solidityaddress.send（节省9 0 Gas）。 到目前为止使用的 Gas 是 56780 还可以更进一步吗？ 把地址作为字节32的数字直接放在调用中，可以为我们多节省9个Gas! 在调用中的手动用零填充地址， 可以节约到 56771 Gas 我们继续走下去如何？ 既然我们已经针对测试上做优化，那我们就进一步 为什么我们不直接返回，如果测试是 "Gas目标"？ 知道Hardhat总是在相同的区块链中运行测试，我们可以把这个代码放在 distribute()函数的开头： if (bl…