免责声明
本站为个人博客，分享记录个人学习过程和相关信息。所有内容如有外部来源，将会在分享时明确标注，如有遗漏，请通过邮件联系以便及时删除。未标注来源的部分（如代码等），读者可以自由使用，但需自行承担使用可能带来的后果。关于信息的准确性请读者自行鉴别，这不是科普，绝大多数情况下无法做到精准描述。
个人代码仓库
About languages
If you have some difficulties in reading Chinese, usually because you are not a native Chinese speaker. It is recommended to use the Chrome plugin Immersive Translate to read this blog. Welcome everyone to learn about my learning experience.
关于个人
我是 徐 ，此博客旨在分享技术学习和个人见解。欢迎查阅我的简历，部分信息在此。
希望能找到一个对于区块链行业有热忱的团队一起奋进。如果我的技术栈刚好符合你的需求，可以通过邮件与我进一步联系。部分技术栈不匹配的问题也可以后续跟进。
资源导航
遇到收费等情况自行斟酌，仅做推荐
电子书站点
全国图书馆参考咨询联盟 ->声名不显的网站，在国内流通的任何书籍无论冷门热门均有，包括冷门教材。获取书籍方法需要渠道，可淘宝问。
文献
娱乐影视
前端部分
联系方式
- Email：web3test1@outlook.com
- Github：https://github.com/codermaybe
个人信息
- 姓名：徐
- 性别：男
- 出生年份：2000
- 学历：本科 / 计算机系网络工程专业
- 区块链开发：1年+
- 期望职位：区块链开发(智能合约开发)
- 期望薪资：面议
- 期望城市：深圳/香港/上海/远程
- 个人主页：codermaybe.github.io
工作经历
A 公司 | 网络工程师
2023年6月 ~ 2025年2月
- 主导网络架构设计与实施，熟悉Panabit、爱快、高恪、ROS、OpenWrt等软路由系统，具备丰富的实操经验。
- 完成网络布线规划及设备选型，采用ikuai软路由+华为S5700-24TP-SI-AC方案，配置ACL、VLAN、IPSec VPN、行为管理及DPI检测分流，支持200个房间近300人同时在线，网络稳定运行近两年。
- 负责日常网络维护与优化，确保高并发场景下的流畅体验。
B 公司 | 网络工程师
2023年2月 ~ 2023年5月
- 日均处理20+家企业网络问题，服务规模涵盖20-500人，独立完成路由器选型、配置及VPN（IPSec/L2TP/PPTP）部署，实现跨平台、跨厂家设备互联互通。
- 熟练配置企业级交换机，支持大流量数据交互，具备华为、深信服、锐捷等主流网络设备的调试与故障排查能力。
- 解决多起防火墙配置问题，提升企业网络安全性及稳定性。
区块链相关
接触区块链开发领域
- 自2024.1月始-至今
技术栈
- 编程语言：Java / Rust / Solidity
- Web3开发框架及工具：
- 交互：Ethers.JS（主） / Web3.JS
- 前端：ReactJS / Web3uikit / Antd / Wagmi / HTML / JS / TS / CSS / AJAX
- 智能合约开发与部署：Solidity / Rust / Hardhat（含Hardhat Ignition、Hardhat Truffle等） / Ganache
- 合约检查工具：Slither
- 数据库：MySQL
- 版本管理与部署工具：Git
区块链能力
-
智能合约开发：
- 熟悉ERC-20、ERC-721、ERC-777、ERC-1155等标准，具备独立开发、部署和上线智能合约的经验。主要实践项目部署于以太坊测试链。
- 熟练使用OpenZeppelin安全合约库，阅读过Uniswap、USDT等项目的源码，有部分实例分析在博客中。
-
区块链生态理解：
- 了解DeFi、GameFi、DApp等发展方向，实现过简单的ERC-20流动池货币兑换项目。
- 熟悉Uniswap、Layer2、IPFS等技术实现，了解RWA、AMM、永续合约等概念及实现方式。
-
共识机制：
- 熟悉PoW、PoS、DPOS、PoH、PBFT等共识机制的原理及应用场景。
计算机基础
- 英语能力：英语六级，能流畅阅读并理解英文技术文档。
- 计算机组成：
- 熟悉CPU流水线、访存、译码、写回等阶段，了解进制转换、有符号数/无符号数计算、溢出等概念。
- 掌握汇编语言、机器指令实现方式及编译过程，熟悉计算机存储层次结构。
- 计算机网络：
- 熟悉OSI七层模型和TCP/IP模型，了解TCP协议、HTTP协议及Socket编程。
- 具备路由器、交换机、防火墙、AC+AP等网络设备的实操经验。
- Rust语言：
- 熟悉所有权系统、借用与生命周期、数据类型、函数与闭包、错误处理等核心特性。
开源项目(建议直接查看github仓库)
区块链交互工具
- 项目链接：https://github.com/codermaybe/BlockChain_InteractTools
- 功能：
- 以太坊余额查询、通用合约交互(目前仅view/pure方法可调用)。
- 随机钱包申请、转账、钱包恢复(助记词)、remix合约部署重定向。
- 区块链历史交易查询、区块链合约事件监听、代币归集等功能。
- 预计引入私钥管理，支持私钥导入、导出、管理。向完善的去中心化钱包发展。
Solidity智能合约开发
- 项目链接：https://sepolia.etherscan.io/address/0x48aeCf60f7D272Dc118409CE5FB589386d4267eE
- 描述：包含多个智能合约的部署与调用记录。
- 子项目1：区块链投票系统：初步仿造Aragon/MakerDao的治理模式，采用投票功能，暂未引入代币进行治理投票。
Rust子网转换工具
- 项目链接：https://github.com/codermaybe/IP_SubnetConverter_Flawed
- 功能：将Windows默认输出文本转换为路由条目。
毕业设计：P2P局域网聊天工具
- 项目链接：https://github.com/codermaybe/display
- 功能：支持大文件互传和实时信息传输，具有对去中心化模式的初步设想。
致谢
感谢您花时间阅读我的简历，期待能有机会和您共事！
Contact Information
- Email: mail to me
- GitHub: https://github.com/codermaybe
Personal Information
- Name: Xu
- Gender: Male
- Year of Birth: 2000
- Education: Bachelor's Degree / Network Engineering
- Blockchain Experience: 1+ year
- Desired Position: Blockchain Developer(smart contract development)
- Expected Salary: Negotiable
- Preferred Locations: Shenzhen(current)/Hong Kong/Shang Hai/Remote
- Personal Website: codermaybe.github.io
Work Experience
A company | Network Engineer
- June 2023 - February 2025
- Led network architecture design and implementation, familiar with soft router systems such as Panabit, iKuai, GaoKe, ROS, and OpenWrt, with extensive practical experience.
- Completed network cabling planning and equipment selection, using the iKuai soft router + Huawei S5700-24TP-SI-AC solution, configured ACL, VLAN, IPSec VPN, behavior management, and DPI detection and traffic distribution, supporting nearly 300 people online simultaneously in 200 rooms, with stable network operation for nearly two years.
- Responsible for daily network maintenance and optimization, ensuring a smooth experience in high-concurrency scenarios.
B company | Network Operation and Maintenance Engineer
- February 2023 - May 2023
- Handled 20+ enterprise network issues daily, serving organizations with 20-500 employees, independently completed router selection, configuration, and VPN (IPSec/L2TP/PPTP) deployment, achieving cross-platform and cross-vendor device interoperability.
- Proficient in configuring enterprise-grade switches, supporting high-traffic data interaction, with debugging and troubleshooting capabilities for mainstream network devices such as Huawei, Sangfor, and Ruijie.
- Resolved multiple firewall configuration issues, improving enterprise network security and stability.
Blockchain Related Experience
- Blockchain Development Exposure: January 2024 - Present
Technical Stack
- Programming Languages: Java / Rust / Solidity
- Web3 Development Frameworks and Tools:
- Interaction: Ethers.JS (Primary) / Web3.JS
- Frontend: ReactJS / Web3uikit / Antd / Wagmi / HTML / JS / TS / CSS / AJAX
- Smart Contract Development and Deployment: Solidity / Rust / Hardhat (including Hardhat Ignition, Hardhat Truffle, etc.) / Ganache
- Contract Inspection Tools: Slither
- Database: MySQL
- Version Control and Deployment Tools: Git
Blockchain Capabilities
- Smart Contract Development:
- Familiar with ERC-20, ERC-721, ERC-777, ERC-1155 standards, with independent experience in developing, deploying, and launching smart contracts. Main practical projects deployed on the Ethereum testnet.
- Proficient in using the OpenZeppelin security contract library, has read the source code of projects such as Uniswap and USDT, and has some instance analysis in the blog.
- Blockchain Ecosystem Understanding:
- Understands the development directions of DeFi, GameFi, DApp, etc., and has implemented simple ERC-20 liquidity pool currency exchange projects.
- Familiar with technical implementations such as Uniswap, Layer2, IPFS, and understands concepts and implementations such as RWA, AMM, and perpetual contracts.
- Consensus Mechanisms:
- Familiar with the principles and application scenarios of consensus mechanisms such as PoW, PoS, DPOS, PoH, and PBFT.
Computer Fundamentals
- English Proficiency: College English Test Band 6, able to fluently read and understand English technical documentation.
- Computer Organization:
- Familiar with CPU pipeline, memory access, decoding, write-back and other stages, understand concepts such as hexadecimal conversion, signed/unsigned number calculation, and overflow.
- Master assembly language, machine instruction implementation methods, and compilation process, familiar with computer storage hierarchy.
- Computer Networks:
- Familiar with the OSI seven-layer model and TCP/IP model, understand TCP protocol, HTTP protocol, and Socket programming.
- Practical experience with network devices such as routers, switches, firewalls, and AC+AP.
- Rust Language:
- Familiar with core features such as the ownership system, borrowing and lifetime, data types, functions and closures, and error handling.
Open Source Projects (Recommend checking the GitHub repository directly: github.com/codermaybe)
- Blockchain Interaction Tools
- Project Link: https://github.com/codermaybe/BlockChain_InteractTools
- Features:
- Ethereum balance query, general contract interaction (currently only view/pure methods can be called).
- Random wallet application, transfer, wallet recovery (mnemonic), remix contract deployment redirection.
- Blockchain historical transaction query, blockchain contract event monitoring.
- Supports transfer functions, and plans to integrate Wagmi Hooks in the future to transform into a wallet or Remix-like interaction tool.
- Solidity Smart Contract Development
- Project Link: https://sepolia.etherscan.io/address/0x48aeCf60f7D272Dc118409CE5FB589386d4267eE
- Description: Contains deployment and call records of multiple smart contracts.
- Sub-project 1: Blockchain Voting System: Preliminary imitation of Aragon/MakerDao's governance model, using voting functions, temporarily without introducing tokens for governance voting.
- Rust Subnet Conversion Tool
- Project Link: https://github.com/codermaybe/IP_SubnetConverter_Flawed
- Function: Convert Windows default output text into routing entries.
- Graduation Design: P2P LAN Chat Tool
- Project Link: https://github.com/codermaybe/display
- Function: Supports large file transfer and real-time information transmission, with preliminary ideas for a decentralized model.
Acknowledgement
Thank you for your time in reviewing my resume. I look forward to the opportunity to work with you!
区块链(BlockChain)
简介
！为保证内容严谨性简介摘自 百度百科，可访问链接查证来源
区块链（英文名：blockchain 或block chain ）是一种块链式存储、不可篡改、安全可信的去中心化分布式账本 ，它结合了分布式存储、点对点传输、共识机制、密码学等技术，通过不断增长的数据块链（Blocks）记录交易和信息，确保数据的安全和透明性。
区块链起源于比特币（Bitcoin），最初由中本聪（Satoshi Nakamoto）在2008年提出，作为比特币的底层技术 。从诞生初期的比特币网络开始，区块链逐渐演化为一项全球性技术，吸引了全球的关注和投资。随后，以太坊（Ethereum）等新一代区块链平台的出现进一步扩展了应用领域 。
区块链的特点包括去中心化、不可篡改、透明、安全和可编程性。每个数据块都链接到前一个块，形成连续的链，保障了交易历史的完整性。智能合约技术使区块链可编程，支持更广泛的应用 。 区块链在金融、供应链、医疗、不动产等领域得到广泛应用。尽管仍面临可扩展性和法规挑战，但它已经成为改变传统商业和社会模式的强大工具，对未来具有巨大潜力。
当前区块链部分趋势解析
1. 加密货币：数字金融的核心引擎
加密货币(常以比特币为人熟知)作为区块链技术的起点，依然是其最重要的应用之一。从比特币的价值存储功能到以太坊生态的智能合约支持，加密货币已经从单纯的投资工具扩展到支付、储值和跨境结算等实际场景。特别是稳定币（如 USDT、USDC）和央行数字货币（CBDC）正逐步成为全球金融体系的重要组成部分。
- 热点方向：
- 稳定币：提供低波动性的支付和储值工具。
- 数字资产：将现实世界资产（如房地产、股票）代币化。
- 隐私增强：如零知识证明技术（ZKP）推动隐私性支付。
- 未来展望：随着全球监管的逐步完善，加密货币将在合法合规的框架下，进一步融入主流经济。
2. 数据存储：构建去中心化存储网络
传统数据存储方式往往面临集中化风险，而区块链赋能的去中心化存储为这一问题提供了解决方案。通过分布式存储技术，数据不仅更安全，还能实现更高效的共享和访问。
- 代表技术：IPFS（星际文件系统）、Filecoin、Arweave。
- 应用场景：
- 医疗数据：安全存储患者记录并防止数据泄露。
- 科研文献：永久存储科研成果，保证数据完整性。
- 数字资产：为 NFT 等提供长期存储支持。
- 未来展望：数据存储市场将进一步与人工智能和物联网结合，构建更大规模的数据共享网络。
3. 版权保护：为创作者经济注入新活力
数字时代，创作者面临着盗版泛滥和收益分配不透明的问题，而区块链的不可篡改特性为版权保护提供了新的解决方案。通过 NFT 和智能合约，创作者可以直接确权并实现收益的自动化分配。
- 技术工具：
- NFT（非同质化代币）：用于数字艺术、音乐、视频的唯一性确权。
- 智能合约：实现收益分配的自动化和透明化。
- 代表项目：OpenSea、Async Art、Mintbase。
- 未来展望：随着区块链技术与传统版权管理体系的深度结合，更多行业将采用去中心化方式管理和保护知识产权。
4. 企业应用：赋能实体经济的数字化转型
区块链技术在企业场景中的应用正在快速增长，尤其是在供应链、物流、金融清算等领域。企业通过区块链优化流程、降低成本，并提升数据透明度。
- 当前实践：
- 防伪溯源：确保商品从生产到销售的全程可追溯性。
- 合同管理：利用智能合约实现自动化履约。
- 资产管理：数字化管理企业资产，提高运营效率。
- 未来趋势：区块链将与物联网（IoT）、人工智能（AI）结合，构建智能化、自动化的企业运营网络。
区块链技术正以多维度的方式重塑各个行业。从加密货币到数据存储、版权保护，再到企业应用，其发展方向不仅展示了技术的潜力，也为数字经济与实体经济的深度融合开辟了新路径。在未来，我们有理由期待区块链技术在更多领域的突破和落地，推动社会迈向一个更加开放、透明、高效的新时代。
未来的可能
1. 跨链互操作性
不同区块链之间的孤立性正在限制其大规模应用。未来，跨链技术将实现资产、数据和智能合约的跨链流通，为区块链生态系统的融合提供动力。
- 关键技术：Polkadot、Cosmos、桥接协议（Bridges）。
- 潜在影响：
- 实现链间的无缝交互。
- 推动更多复杂场景的落地。
2. 隐私保护与合规
随着数据隐私和合规性需求的增长，零知识证明（ZKP）、多方计算（MPC）等隐私增强技术将在金融、医疗等敏感数据场景中发挥重要作用。
- 技术前景：
- 更安全的隐私保护交易。
- 满足法规要求的合规区块链解决方案。
3. Web3 的普及
Web3 的发展将赋予用户对数据的完全掌控权，重新定义数字身份（DID）、去中心化存储和应用生态。
- 可能的变革：
- 用户数据自主权的增强。
- 去中心化社交媒体和内容平台的崛起。
4. 社会公益与可持续发展
区块链技术可以支持公益透明化、碳排放追踪和绿色金融发展，为社会带来更多正向价值。
- 应用场景：
- 环保项目：追踪碳信用交易。
- 公益捐款：确保资金流向透明。
疯狂的商机
1. 数字艺术与收藏品
随着 NFT 的兴起，数字艺术市场呈现爆炸式增长。艺术家和创作者能够通过区块链直接向全球观众出售作品，同时确保所有权和版税收益。
- 商业模式：
- 创建独特的数字艺术品。
- 提供 NFT 交易和拍卖平台。
- 潜在利润：
- 高价值艺术品销售。
- 平台交易手续费收入。
2. 游戏经济和虚拟世界
区块链赋能的游戏正重塑游戏行业，玩家可以真正拥有游戏内资产并通过交易获利。例如，"Play-to-Earn" 模式已吸引了大量玩家和投资者。
- 盈利模式：
- 虚拟道具销售。
- 游戏内资产的 NFT 化和交易。
- 成功案例：Axie Infinity、The Sandbox。
3. 去中心化金融（DeFi）
DeFi 提供了无需中介的金融服务，包括借贷、交易和收益农场。其透明性和高收益吸引了大量用户，成为区块链最具活力的领域之一。
- 商机：
- 创建创新性的 DeFi 协议。
- 提供流动性挖矿激励。
- 潜在收益：
- 协议交易费用。
- 流动性提供者的分红。
4. 元宇宙生态建设
元宇宙作为一个虚拟与现实结合的世界，区块链是其关键技术之一。开发虚拟地产、虚拟商品以及元宇宙平台将成为新的商业热点。
- 盈利方向：
- 虚拟地产销售。
- 虚拟活动门票和商品交易。
- 未来前景：元宇宙将吸引更多品牌和用户，带来持续的商业机会。
区块链技术不仅在当前热点领域中发挥着重要作用，其未来可能性更是为人类社会的方方面面带来了无限想象空间。从技术突破到实际应用，区块链正在塑造一个更加开放、透明和可持续的未来。
区块链基础
自2008年比特币诞生以来，区块链技术逐渐成为重构信任机制的核心支柱。其本质是通过分布式账本和密码学算法，实现去中心化、不可篡改的数据记录与价值传递。
一、区块链的核心原理
-
分布式账本
区块链通过将数据存储于全网多个节点，构建去中心化的数据库。每个节点持有完整账本副本，交易需经多数节点验证后写入。例如，比特币网络由约12,000个节点（截至2025年3月）共同维护，确保数据一致性。节点数的动态变化反映了网络的开放性与活力。 -
共识机制
共识算法是节点达成数据一致性的关键，常见类型包括：- 工作量证明（PoW）：比特币通过算力竞争验证交易，安全性高但能耗巨大。
- 权益证明（PoS）：以太坊2.0采用质押机制，能耗降低约99%，已成为主流趋势。
- 实用拜占庭容错（PBFT）：适用于联盟链，通过多数派投票高效达成共识。
-
不可篡改性
每个区块包含前序区块的哈希值，形成链式结构。修改任一数据需重算后续所有区块，计算难度呈指数级增长。以比特币为例，截至2025年3月，其区块链已累积约83万个区块，篡改成本近乎天文数字。
二、区块链的技术架构
区块链可分为三层结构：
-
协议层
- 存储层：采用Merkle树结构存储交易数据，支持高效验证。
- 网络层：基于P2P协议（如比特币的TCP通信）实现节点间数据同步。
- 加密层：依托非对称加密（如ECDSA）和哈希算法（如SHA-256），保障交易安全。
-
扩展层
提供开发接口以支持复杂应用。例如，以太坊通过Solidity语言实现智能合约，比特币闪电网络提升交易速度。2025年，Layer 2技术（如Rollups）进一步优化了扩展性。 -
应用层
覆盖多领域典型应用：- DeFi：去中心化交易所Uniswap和借贷平台Aave推动金融革新。
- 溯源：京东区块链防伪平台已覆盖超60万种商品（截至2024年数据，2025年预计更多）。
- 司法存证：杭州互联网法院利用区块链固化电子证据，提升司法效率。
三、区块链的分类与典型场景
-
分类
- 公有链：完全开放，如比特币和以太坊，无中心化控制。
- 联盟链：多方共管，如R3 Corda和蚂蚁链，适用于金融结算。
- 私有链：企业内部使用，如沃尔玛供应链管理，兼顾效率与隐私。
-
典型场景
- 跨境支付：传统SWIFT需3-5天，Ripple将时间缩短至2-3小时，已与Santander等银行合作。
- 供应链金融：区块链将应收账款数字化，降低中小企业融资门槛。
- 数字身份：新加坡“乌敏岛项目”通过区块链管理公民数据，提升隐私与安全性。
四、挑战与未来方向
-
现存问题
- 可扩展性：比特币每秒处理7笔交易（TPS），远低于VISA的65,000 TPS。
- 能源消耗：PoW机制年耗电量约60 TWh，相当于瑞士全年用电。
- 监管缺失：DeFi的匿名性增加了非法资金流动风险。
-
技术演进
- 分片技术：以太坊2.0通过64个分片将TPS提升至数万，2025年已初见成效。
- 零知识证明：Zcash的zk-SNARKs技术实现交易隐私保护，广泛应用于隐私链。
- 跨链互操作：Polkadot和Cosmos推动链间资产互通，加速Web3生态融合。
- Layer 2普及：Arbitrum等解决方案大幅提升吞吐量，成为2025年技术热点。
推荐链接： dappradar.com
1. 金融领域深化应用（核心方向）
- 去中心化金融（DeFi）：基于以太坊等公链构建借贷、交易、衍生品平台，2023年DeFi总锁仓量已突破千亿美元。
Uniswap
- 供应链金融：通过区块链实现多方信息透明共享，降低信任成本，解决中小企业融资难题。
- 跨境支付与结算：如瑞波币（Ripple）通过联盟链提升跨境支付效率，减少中间环节费用。
- 数字资产证券化：利用智能合约实现资产Token化，提升流动性，典型案例如房地产和艺术品投资。
2. 企业级区块链解决方案（主战场）
- 联盟链与私有链主导：企业更倾向采用强管理的联盟链（如Hyperledger Fabric）优化供应链管理、数据存证等场景，提升协作效率。
- BaaS（区块链即服务）：云服务商（如AWS、阿里云）集成区块链模块，降低企业部署成本，加速应用落地。
- 行业标准建设：金融、物流等领域制定区块链技术标准，如工信部发布的《区块链隐私保护规范》。
3. 跨行业扩展与实体经济融合
- 物联网与供应链管理：区块链+物联网实现设备数据可信上链，优化物流追踪与溯源（如IBM Food Trust）。
- 医疗健康：患者数据加密共享，提升跨机构协作效率，同时保障隐私。
- 政务与司法存证：多地政府采用区块链技术实现电子证照、司法证据存证，增强公信力。
4. 技术创新与生态扩展
- 跨链技术：解决多链互通问题，Polkadot、Cosmos等项目推动跨链协议发展，支撑价值互联网构建。
cosmos sdk
- Layer2扩容方案：如Optimism、zkSync通过Rollup技术提升以太坊交易吞吐量，降低Gas费用。
- 隐私计算结合：零知识证明（ZKP）与同态加密技术增强交易隐私性，应用于匿名币（如Zcash）和合规金融场景。
5. 监管合规与标准化
- STO（证券型代币）取代ICO：通过合规化代币发行降低风险，美国SEC已推动相关监管框架。
- 全球监管协作：如区块链协会发布《数字资产市场结构原则》，强调保护用户自托管权利与跨境协作。
- 反洗钱（AML）与KYC：各国要求交易所和钱包服务商纳入传统金融监管体系，如FATF“旅行规则”。
6. 新兴领域探索
- Web3.0与去中心化身份（DID）：构建用户自主控制的数据身份体系，如以太坊的ERC-725标准。
- 元宇宙与NFT：区块链支撑虚拟资产确权与交易，NFT应用扩展至游戏、艺术和知识产权领域。
- 碳中和与能源管理：通过区块链追踪碳足迹，激励绿色能源交易，如Power Ledger项目。
未来趋势关键点
- 技术融合：区块链与AI、物联网、边缘计算结合，形成分布式信任网络。
- 去中心化与监管平衡：在合规框架下探索DAO（去中心化自治组织）等新模式。
- 基础设施升级：高性能公链（如Solana）和模块化架构（如Celestia）推动大规模商用。
区块链共识机制
共识机制是区块链技术的核心组成部分，它解决了分布式系统中的一个基本问题：如何在没有中央权威的情况下，让网络中的所有参与者就交易的有效性和顺序达成一致。以下是主要的区块链共识机制、它们的工作原理以及各自的优缺点。
共识机制的基本概念
在分布式系统中，共识是指网络中的节点就某一状态达成一致的过程。区块链作为一种特殊的分布式账本技术，其共识机制需要解决以下问题：
- 双花问题：防止同一数字资产被花费两次
- 拜占庭将军问题：在存在恶意节点的情况下达成一致
- 系统可靠性：确保系统即使在部分节点失效的情况下仍能正常运行
- 交易顺序：确定交易的顺序并将其写入区块链
主要共识机制
1. 工作量证明 (Proof of Work, PoW)
工作原理：
- 节点（矿工）通过解决复杂的数学难题来竞争区块的生成权
- 解决难题需要大量计算资源
- 第一个找到解决方案的矿工获得将新区块添加到链上的权利并获得奖励
代表项目：
- 比特币 (Bitcoin)
- 莱特币 (Litecoin)
- 以太坊 (Ethereum) 在2022年9月之前
优点：
- 安全性高，攻击成本高（需要51%的算力）
- 已被实践证明的可靠性
- 去中心化程度高
缺点：
- 能源消耗巨大
- 交易处理速度慢
- 随着算力集中可能导致中心化趋势
2. 权益证明 (Proof of Stake, PoS)
工作原理：
- 区块生成者（验证者）基于其持有的加密货币数量（权益）被选中
- 验证者通过质押自己的代币来获得验证交易的权利
- 恶意行为将导致质押资产被罚没
代表项目：
- 以太坊2.0 (Ethereum 2.0)
- 卡尔达诺 (Cardano)
- 索拉纳 (Solana)（使用历史证明的PoS变种）
优点：
- 能源效率高
- 更高的交易吞吐量
- 持币者有动力维护网络安全
缺点：
- "富者更富"的潜在问题
- 理论上的安全性争议
- 可能导致权益集中
3. 委托权益证明 (Delegated Proof of Stake, DPoS)
工作原理：
- 持币者通过投票选出有限数量的"代表"或"见证人"
- 这些代表负责验证交易和生成区块
- 代表表现不佳可能被投票替换
代表项目：
- EOS
- TRON (波场)
- Lisk
优点：
- 极高的交易处理速度
- 能源效率高
- 治理机制更为明确
缺点：
- 中心化程度较高
- 可能形成"寡头政治"
- 参与门槛较高
4. 实用拜占庭容错 (Practical Byzantine Fault Tolerance, PBFT)
工作原理：
- 基于多轮投票达成共识
- 能在有限数量的恶意节点存在的情况下保持系统安全
- 通常需要已知且有限的验证节点集合
代表项目：
- 超级账本 (Hyperledger Fabric) --联盟链常用
- Zilliqa (结合PoW使用)
- NEO
优点：
- 交易最终性快
- 无需大量计算资源
- 高吞吐量
缺点：
- 适合许可链而非公有链
- 节点数量增加会影响性能
- 需要节点身份验证
5. 权威证明 (Proof of Authority, PoA)
工作原理：
- 区块由预先选定的权威节点（验证者）生成
- 验证者通常需要公开身份，声誉作为质押
- 适合联盟链和私有链场景
代表项目：
- VeChain
- 以太坊测试网络 (Rinkeby, Goerli)
- xDai Chain
优点：
- 高性能和可扩展性
- 能源效率高
- 交易成本低
缺点：
- 中心化程度高
- 信任依赖于验证者
- 不适合完全公开的场景
新兴共识机制
1. 可验证随机函数 (Verifiable Random Function, VRF)
Algorand等区块链使用VRF来随机选择提议者和验证委员会，结合了PoS的能效与抽签的公平性。
2. 容量证明 (Proof of Capacity/Space)
存储空间替代计算能力作为资源证明，如Chia网络使用"空间和时间证明"(Proof of Space and Time)。
3. 历史证明 (Proof of History)
Solana引入的时间戳机制，创建历史记录证明事件发生的顺序，提高交易处理速度。
共识机制的演进趋势
随着区块链技术的发展，共识机制呈现以下趋势：
- 环保趋势：从能源密集型向环保型转变
- 可扩展性提升：追求更高的TPS（每秒交易数）
- 安全与去中心化的平衡：寻找三难困境（去中心化、安全性、可扩展性）的最佳平衡点
- 混合共识：结合多种共识机制的优势
- 链下扩展：Layer 2解决方案与主链共识机制的协同
结论
共识机制是区块链技术的灵魂，不同的应用场景和需求催生了各种共识算法。随着技术的不断演进，更高效、更安全、更环保的共识机制将继续涌现，推动区块链技术走向更广泛的应用。
没有一种"完美"的共识机制适合所有场景，区块链项目需要根据自身的特点和目标用户群体选择最合适的共识算法，或者开发创新的混合解决方案。随着行业的成熟，共识机制的设计将变得更加精细和专业化，以满足特定领域的需求。
工作量证明 (Proof of Work)
深入浅出：什么是PoW共识机制？
如果你听说过比特币或区块链，可能对“挖矿”这个词不陌生。而挖矿的核心，就是 PoW（Proof of Work，工作量证明） 共识机制。本文将探讨PoW的定义、工作原理、优缺点及其历史背景。
PoW的本质
PoW是一种通过计算“工作量”实现网络共识的机制。在区块链中，参与者（称为矿工）通过解决数学难题证明其投入的计算资源。成功解题的矿工可将新区块添加到链上并获得奖励。PoW依靠“工作量”的可验证性和高计算成本，确保系统的安全性和去中心化。
以比特币为例，其难题基于 SHA-256哈希函数：矿工需找到一个随机数（Nonce），使区块数据的哈希值满足特定条件（如具有一定数量的前导零）。这一过程需要大量试错计算，体现了PoW的“工作”特性。
PoW的工作原理
- 交易收集：网络中的交易被打包进候选区块。
- 难题挑战：矿工调整Nonce，反复计算哈希值，直到结果符合难度要求。
- 验证答案：全网节点验证哈希是否有效，确保共识一致。
- 广播与确认：有效区块被添加到区块链，矿工获得代币奖励。
- 持续循环：过程重复，驱动区块链扩展。
篡改区块需重算后续所有工作量，因算力竞争的存在，这种攻击成本极高，使得PoW网络高度安全。
PoW的优点
- 安全性高：发起51%攻击需控制全网过半算力，在成熟网络（如比特币）中几乎不可行。
- 去中心化：无需许可，任何拥有计算资源的个体均可参与。
- 规则透明：奖励与算力直接相关，机制公开公平。
PoW的缺点
- 能耗巨大：高算力需求导致显著的电力消耗，引发环保争议。据估算，比特币网络年耗电量可媲美一些中小型国家。
- 效率较低：交易吞吐量受限，例如比特币每秒处理约7笔交易。
- 算力集中：专用设备（如ASIC）的普及使小型矿工难以竞争，算力逐渐向大矿池集中。
PoW的历史背景与技术意义
PoW的起源可以追溯到计算机科学和密码学的早期研究。1993年，Cynthia Dwork 和 Moni Naor 在一篇论文中提出了一种基于计算成本的方案，旨在防御垃圾邮件。他们设计了一种机制，要求发送者解决计算难题以证明诚意，这一想法成为PoW的雏形。1997年，Adam Back 推出了 Hashcash，利用SHA-1哈希函数生成特定难度的输出，用于抵御邮件轰炸和DDoS攻击。Hashcash直接启发了比特币的PoW设计。
2008年，中本聪（Satoshi Nakamoto） 在《比特币：一种点对点电子现金系统》白皮书中将PoW引入区块链，结合分布式账本和经济激励，解决了“双重支付”问题。中本聪的创新在于将Hashcash的单次证明扩展为动态调整难度的持续竞争机制，确保网络随算力增长保持约10分钟的出块时间。2009年1月3日，比特币创世区块生成，PoW成为首个成功运行的区块链共识算法。
早期，PoW被广泛采用，如Ethereum（2015-2022年）、Litecoin和Monero等。但随着技术进步，PoW的局限性显现。2022年9月15日，以太坊通过“The Merge”转向PoS，标志着对PoW的部分反思。尽管如此，PoW作为区块链技术的起点，其通过算力和数学建立信任的范式，开创了去中心化数字经济的先河。
权益证明(Proof of Stake)
- 代表链：ETH
深入浅出：什么是PoS共识机制？
如果你对比特币的PoW（工作量证明）有所了解，那么PoS（Proof of Stake，权益证明）可能是你听到的另一个热门共识机制。作为区块链技术的替代方案，PoS因其低能耗和高效率备受关注。今天，我们来聊聊PoS的原理、运作方式及其优缺点。
PoS的本质
与PoW通过计算“工作量”不同，PoS基于参与者的“权益”来决定谁有权创建新区块。在PoS系统中，“权益”通常指用户持有的加密货币数量及其持有时间。简单来说，持有越多代币并“锁定”越久的人，越有可能被选中来验证交易并添加区块。这种机制用经济投入取代了算力竞争。
在PoS区块链中，验证者（Validator）不是通过挖矿，而是通过质押（Stake）代币参与共识。被选中的验证者负责打包交易并获得奖励，而作弊（如伪造区块）会导致质押的代币被没收。
PoS的工作原理
- 质押代币：用户将一定数量的代币锁定在网络中，作为参与共识的“保证金”。
- 随机选择：系统通过算法（通常结合代币数量和质押时间）随机选择一名验证者。
- 区块创建：被选中的验证者验证交易并生成新区块。
- 全网确认：其他节点验证区块的有效性，达成共识。
- 奖励分配：验证者获得交易费或新发行的代币作为回报。
PoS的关键在于“随机性”和“经济惩罚”：选择过程看似随机，但倾向于持有更多代币的参与者；若验证者行为不当，其质押的代币将被“销毁”。
PoS的优点
- 能耗低：无需大量算力，PoS的能源消耗远低于PoW，更加环保。
- 效率高：交易确认速度快，吞吐量更高（如以太坊PoS后可达数千TPS）。
- 去中心化潜力：普通用户更容易参与，不依赖昂贵的挖矿设备。
PoS的缺点
- 富者愈富：持有更多代币的人更容易被选中，可能加剧财富集中。
- 安全性争议：相比PoW，PoS对网络攻击（如“长程攻击”）的抵御能力仍需验证。
- 初始分配问题：代币分配不均可能导致早期持有者占据主导。
PoS的历史背景与技术意义
PoS的概念最早出现在2011年，由QuantumMechanic在Bitcointalk论坛提出，旨在解决PoW的高能耗问题。2012年，Peercoin（PPC）成为首个采用PoS的加密货币项目，引入了“币龄”（Coin Age）的概念，即代币持有时间越长，获得记账权的概率越高。此后，PoS逐渐发展出多种变体，如纯PoS、DPoS（委托权益证明）和LPoS（租赁权益证明）。
以太坊的转型是PoS历史上的里程碑。2015年以太坊推出时采用PoW，但创始人Vitalik Buterin早已计划转向PoS。2022年9月15日，以太坊完成“合并”（The Merge），正式从PoW切换至PoS，成为迄今规模最大的PoS网络。这一转变不仅将能耗降低了约99.95%，还推动了PoS在主流区块链中的应用。
PoS的理论基础与博弈论和经济学密切相关。它假设参与者是理性的经济人，会因害怕失去质押资产而遵守规则。与PoW的算力竞争不同，PoS通过经济激励和惩罚构建信任，代表了区块链共识机制从“资源消耗”向“资源持有”的范式转变。
Proof of History（PoH）是什么？
Proof of History（PoH，历史证明） 是由Solana团队开发的一种时间排序机制，旨在通过加密时间戳和可验证延迟函数（VDF）记录事件顺序，提升区块链的性能和可扩展性。PoH并非独立的共识算法，而是与Proof of Stake（PoS）结合使用，专注于解决分布式系统中时间同步的效率问题，为高吞吐量区块链提供了创新基础。
使用Proof of History（PoH）的区块链项目
以下是截至2025年2月28日，已知与PoH直接关联的区块链项目及其应用情况：
1. Solana
- 概述：Solana是PoH的主要实现者，作为一个高性能Layer 1区块链，支持大规模去中心化应用（DApps）。
- PoH作用：Solana将PoH作为其架构的核心组件，与PoS结合。PoH通过生成连续的时间戳序列，标记交易和事件的顺序，减少节点间的时间同步需求，从而实现高吞吐量。
- 特点：
- 高吞吐量：理论峰值超65,000 TPS，实际表现约为2,000-3,000 TPS（视网络状况）。
- 低延迟：区块时间约400毫秒。
- 应用场景：DeFi（如Serum）、NFT（如Magic Eden）、区块链游戏等。
- 现状：截至2025年，Solana已成为领先公链之一，其生态系统持续扩展。
2. Filecoin（探索性研究）
- 概述：Filecoin是一个去中心化存储网络，基于Proof of Replication（PoRep）和Proof of Spacetime（PoSt）。
- PoH关联：Filecoin本身不使用PoH，但社区和研究者曾探讨将其集成到架构中，以优化时间戳验证或存储证明效率。
- 特点：
- PoH可能提升数据检索的排序效率。
- 目前仅为理论提案，未在主网实现。
- 现状：PoH在Filecoin中未被正式采用，仅停留于实验讨论。
3. Arweave（潜在计划）
- 概述：Arweave是一个永久存储区块链，使用Proof of Access（PoA）和“Blockweave”结构。
- PoH关联：Arweave未正式采用PoH，但其团队曾提及探索类似时间排序机制的可能性，以改进数据验证效率。
- 特点：
- PoH或可优化交易顺序记录。
- 无明确证据显示已实现整合。
- 现状：截至2025年，PoH在Arweave中仍属概念性讨论，未进入实际部署。
其他相关项目
- Hashgraph：Hedera Hashgraph是一种基于DAG的分布式账本技术，其事件排序机制与PoH有相似之处，但使用的是“Gossip about Gossip”和虚拟投票协议，非PoH。
- 小型实验链：一些未具名的区块链项目可能在研究PoH，但缺乏公开文档和影响力，无法确认。
PoH的应用前景
PoH的核心优势在于高效的时间排序，使其适用于需要高吞吐量和低延迟的场景，如金融交易和实时应用。然而，VDF的计算需求可能限制普通节点参与，引发中心化争议。Solana的成功表明PoH的潜力，未来或有更多项目借鉴其设计。
PoH的核心特点
-
时间序列生成
PoH通过连续哈希运算生成不可篡改的时间记录，证明事件发生的顺序。 -
与PoS协同
PoH不决定区块生产者，而是为PoS提供时间框架，由质押的验证者负责区块确认。 -
高效性
通过本地计算替代网络通信，PoH显著提升交易处理速度。
PoH的工作原理
PoH基于SHA-256哈希函数和可验证延迟函数（VDF），其运作流程如下：
- 一个领导节点（Leader）持续运行哈希运算，将前一输出作为下一输入，形成单向的时间序列。
- 交易和事件嵌入此序列，记录其相对时间戳。
- 其他节点验证序列的正确性，因VDF的单向性，无需重新计算即可确认。
- 在Solana中，PoS验证者轮流担任领导者，根据PoH序列打包并确认区块。
此设计将时间同步负担转移至本地计算，极大减少了网络通信开销。
PoH的优缺点
优点
- 高吞吐量：支持数千至数万TPS，适用于大规模应用。
- 低延迟：区块确认时间短，提升用户体验。
- 可扩展性：为高性能区块链提供了技术支持。
缺点
- 硬件要求：生成PoH序列需要高性能硬件，可能提高参与门槛。
- 集中化风险：领导节点的轮换若不平衡，可能削弱去中心化。
- 应用范围有限：目前主要在Solana中实现，其他项目采用较少。
PoH的历史与愿景
PoH由 Anatoly Yakovenko 于2017年首次提出，当时他试图解决分布式系统中时间协调的低效问题。传统共识如PoW依赖算力排序交易，耗能且缓慢；PoS虽降低能耗，仍需频繁通信以同步状态。Yakovenko受到密码学中VDF研究的启发，提出用加密手段生成时间序列，减少节点间依赖。
2018年2月，PoH在《Solana: A new architecture for a high performance blockchain》白皮书中正式亮相，结合PoS和VDF奠定了Solana的技术基础。2019年3月，Solana测试网上线，验证了PoH的可行性。2020年3月16日，Solana主网Beta版启动，PoH投入实际运行。此后，Solana凭借PoH实现的高性能迅速崛起，至2025年已成为公链领域的标杆。
未来，PoH可能在高吞吐量场景（如物联网、金融科技）中获得更多应用，尽管其硬件依赖性仍需优化。
PBFT共识机制
在分布式系统和区块链领域，PBFT（Practical Byzantine Fault Tolerance，实用拜占庭容错） 是一种经典共识算法，旨在应对节点故障和恶意行为。
PBFT的本质
PBFT由Miguel Castro和Barbara Liskov于1999年提出，用于解决拜占庭将军问题。它确保系统在至多1/3节点发生任意故障（包括恶意行为）时仍能达成一致，适用于节点数量有限的分布式网络。
PBFT的工作原理
PBFT通过三阶段协议实现共识，假设总节点数n，最大容错节点数f，需满足n ≥ 3f + 1：
- 预准备（Pre-prepare）：主节点接收客户端请求，分配序列号并广播提议。
- 准备（Prepare）：各节点验证提议合法性，广播准备消息，需收到
2f + 1个一致确认。 - 提交（Commit）：节点收到
2f + 1个准备确认后广播提交，达成共识并执行。
若主节点失效，视图切换（View Change）机制触发，选举新主节点。通信复杂度为O(n²)。
PBFT的优缺点
优点
- 强容错性：可容忍不超过
(n-1)/3个拜占庭节点。 - 高效性：无需算力竞争，延迟低。
- 最终性：达成共识后状态不可逆。
缺点
- 扩展性差：节点数增加时通信开销激增。
- 前提条件：需已知节点身份，不适合完全开放系统。
PBFT的应用
PBFT常见于许可链，如Hyperledger Fabric的共识模块，以及Tendermint（Cosmos SDK基础）。它适用于金融、供应链等需高效一致性的场景。
HotStuff共识机制：区块链中的高效BFT解决方案
引言
在分布式系统和区块链技术中，共识机制是确保节点间状态一致性的核心组件。传统的拜占庭容错（Byzantine Fault Tolerance, BFT）协议，如PBFT（Practical Byzantine Fault Tolerance），在安全性上表现出色，但在通信复杂度和性能扩展性上面临挑战。HotStuff作为一种新型的BFT共识协议，结合了高效性、响应性（responsiveness）和线性通信复杂度，成为近年来备受关注的解决方案。
HotStuff作为一种创新的BFT共识协议，通过三阶段投票、线性通信和管道化设计，为区块链和分布式系统提供了高效、安全的解决方案。它不仅改进了传统BFT协议的扩展性瓶颈，还为现代区块链应用奠定了技术基础。尽管存在一些局限性，但其设计理念和实践价值已得到广泛认可。随着研究的深入，HotStuff及其变种有望在更多场景中发挥作用，推动分布式共识技术的进一步发展。
HotStuff概述
HotStuff由VMware Research团队于2018年提出，并在2019年的PODC会议上正式发表。它是一种基于领导者（leader-based）的BFT共识协议，运行于部分同步（partially synchronous）网络模型中。HotStuff的目标是解决传统BFT协议（如PBFT）的痛点，同时满足区块链系统对高吞吐量、低延迟和可扩展性的需求。
HotStuff的关键特性包括：
- 响应性（Responsiveness）：在网络通信同步后，协议的推进速度取决于实际网络延迟，而非预设的最大延迟。
- 线性通信复杂度：通过优化通信模式，HotStuff将通信开销从传统BFT的平方级别（O(n²)）降低到线性级别（O(n)）。
- 三阶段提交规则：采用独特的“三链”（Three-Chain）提交规则，确保安全性和活跃性（liveness）。
- 领导者轮换：支持频繁的领导者替换，提升系统鲁棒性。
HotStuff的这些特性使其成为Facebook（现Meta）的Libra（后更名为Diem）项目中LibraBFT共识协议的基础。
HotStuff的核心设计
1. 系统模型
HotStuff假设一个由n个节点组成的系统，其中最多f个节点可能出现拜占庭故障（n ≥ 3f + 1）。网络模型为部分同步，即存在一个未知的全局稳定时间（GST），在此之前网络可能是异步的，之后变为同步。节点通过消息传递进行通信，所有消息均经过数字签名以确保不可伪造。
2. 三阶段协议
HotStuff的核心是其三阶段投票机制，与PBFT的两阶段（Pre-Prepare和Commit）不同。HotStuff的三个阶段分别为：
- Prepare：领导者提出一个新区块，收集至少2f+1个节点的投票，形成Prepare Quorum Certificate（Prepare QC）。
- Pre-Commit：领导者广播Prepare QC，节点验证后投票，领导者收集2f+1个投票形成Pre-Commit QC。
- Commit：领导者广播Pre-Commit QC，节点投票并锁定该提案，领导者收集2f+1个投票形成Commit QC，完成提交。
每个阶段的投票都被聚合为一个Quorum Certificate（QC），通过阈值签名（threshold signature）实现高效验证。相比PBFT，额外的Pre-Commit阶段解决了“隐藏锁”（hidden lock）问题，确保新领导者在视图切换（view change）时能安全接管。
3. 线性通信复杂度
传统BFT协议（如PBFT）在视图切换时需要所有节点广播其状态，导致通信复杂度为O(n²)。HotStuff通过“星型通信”（star communication）优化了这一过程：
- 节点仅与当前领导者通信，发送投票。
- 领导者聚合投票并广播QC。
这种模式将通信复杂度降至O(n)，显著提高了协议的可扩展性，尤其在节点数量较多时优势明显。
4. 领导者轮换与管道化
HotStuff支持频繁的领导者轮换，每轮共识后可更换领导者，增强了系统的公平性和抗攻击能力。此外，HotStuff引入了“链式”（Chained）设计，将多个区块的共识过程管道化：
- 一个区块的Prepare QC可作为下一个区块的依据。
- 通过连续的“三链”结构（Prepare → Pre-Commit → Commit），实现高吞吐量。
例如，当第N个区块完成Commit时，第N+1个区块可能已进入Pre-Commit，第N+2个区块进入Prepare。这种管道化设计充分利用了网络带宽，提升了整体性能。
5. 安全性和活跃性
- 安全性（Safety）：HotStuff通过三阶段投票和QC锁定机制，确保不会出现冲突提交。即使在异步网络中，只要不超过f个节点故障，协议仍是安全的。
- 活跃性（Liveness）：通过Pacemaker机制（超时触发视图切换），HotStuff保证在GST后，系统能在正确领导者的带领下达成共识。
HotStuff与PBFT的对比
| 特性 | PBFT | HotStuff |
|---|---|---|
| 通信复杂度 | O(n²) | O(n) |
| 投票阶段 | 两阶段 | 三阶段 |
| 响应性 | 无 | 有 |
| 领导者替换 | 复杂且开销大 | 简单且高效 |
| 管道化支持 | 无 | 有 |
HotStuff在通信效率和灵活性上优于PBFT，尤其适用于大规模分布式系统。
HotStuff在区块链中的应用
HotStuff因其高效性和可扩展性，被广泛应用于许可型区块链（permissioned blockchain）场景：
- LibraBFT：Libra项目的共识协议直接基于HotStuff，优化了其在金融场景下的性能。
- SafeStake：一个支持以太坊2.0 staking的中间层协议，利用HotStuff提升去中心化程度。
- Cypherium：结合HotStuff与PoW，探索混合共识的可能性。
在这些应用中，HotStuff通过线性通信和管道化设计，显著提升了交易吞吐量和确认速度，同时保持了BFT的安全性。
优势与局限性
优势
- 高性能：线性通信和管道化实现高吞吐量和低延迟。
- 可扩展性：适用于大规模节点网络。
- 鲁棒性：频繁领导者轮换减少单点故障风险。
局限性
- 延迟增加：三阶段设计在正常情况下比两阶段协议多一次通信。
- 复杂性：管道化和阈值签名的实现对开发和调试提出了更高要求。
- 性能攻击脆弱性：在某些情况下，恶意节点可能通过分叉攻击降低吞吐量。
针对这些问题，后续研究提出了改进版本，如Fast-HotStuff（两阶段优化）和HotStuff-2（简化投票流程），进一步提升效率和鲁棒性。
此小节记录部分个人学习密码学所阅读的读物
保命声明！！！
非网安、信安专业，非密码学精通人士。
个人阅读并汇总的资料,极少量的代码实现。实现算法的逻辑仅做收集，个人无法目前设计和完全实现。
附大量引导链接，尽可能不误导读者。
Ed25519：现代数字签名算法的原理与应用（附 Rust 实现）
请务必阅读此小章关于密码学
-
推荐链接 偏通识
-
不太推荐但是放上来的链接 需要丰富的密码学相关经验
1. 什么是 Ed25519？
Ed25519 是一种基于 Edwards-curve Digital Signature Algorithm (EdDSA) 的高效签名方案，使用 Curve25519 椭圆曲线。其特点包括：
- 128 位安全性（抗量子计算暴力破解）。
- 确定性签名：无需随机数生成器，避免 ECDSA 的随机数重用风险。
- 64 字节签名：紧凑且易于处理。
- 高性能：比 RSA 和传统 ECDSA 更快。
2. 核心原理
密钥生成
- 私钥：32 字节随机种子（通常来自 CSPRNG）。
- 公钥：通过私钥计算
A = d * B，其中B是曲线基点，d是私钥哈希。
签名
- 计算
r = Hash(私钥 + 消息)。 - 生成临时点
R = r * B。 - 计算
s = (r + Hash(R || A || 消息) * d) mod L。 - 输出
(R, s)（共 64 字节）。
验证
检查：
s * B == R + Hash(R || A || 消息) * A。
3. Rust 实现示例
以下代码演示如何在 Rust 中使用 Ed25519 为代币交易签名。
步骤 1：添加依赖
# Cargo.toml
[dependencies]
ed25519-dalek = { version = "2.0.0", features = ["rand_core"] }
rand_core = { version = "0.6.4", features = ["getrandom"] }
步骤 2：生成密钥对
#![allow(unused)] fn main() { use ed25519_dalek::{Keypair, Signer, Verifier, Signature}; use rand_core::OsRng; fn generate_keypair() -> Keypair { // 从安全随机源生成密钥对 let mut csprng = OsRng; Keypair::generate(&mut csprng) } }
步骤 3：签名与验证
#![allow(unused)] fn main() { fn sign_and_verify() { // 1. 生成密钥对 let keypair = generate_keypair(); let public_key = keypair.public(); // 2. 签名一条消息（例如代币交易） let message = b"Transfer 100 tokens to Alice"; let signature: Signature = keypair.sign(message); // 3. 验证签名 match public_key.verify(message, &signature) { Ok(_) => println!("Signature is valid!"), Err(_) => println!("Signature is invalid!"), } } }
步骤 4：完整代币交易示例
struct TokenTransaction { sender: String, receiver: String, amount: u64, } impl TokenTransaction { fn sign(&self, keypair: &Keypair) -> Signature { let message = serde_json::to_vec(self).unwrap(); keypair.sign(&message) } fn verify(&self, signature: &Signature, public_key: &PublicKey) -> bool { let message = serde_json::to_vec(self).unwrap(); public_key.verify(&message, signature).is_ok() } } fn main() { let keypair = generate_keypair(); let transaction = TokenTransaction { sender: "Bob".to_string(), receiver: "Alice".to_string(), amount: 100, }; // 签名交易 let signature = transaction.sign(&keypair); // 验证交易 let is_valid = transaction.verify(&signature, &keypair.public_key()); println!("Transaction valid? {}", is_valid); }
4. 为什么选择 Ed25519？
- 安全性
- 无随机数风险（对比 ECDSA）。
- 抗侧信道攻击（恒定时间操作）。
- 性能
- 签名速度比 RSA-2048 快约 10 倍。
- 签名验证速度极快。
- 标准化
- 被 IETF (RFC 8032)、OpenSSH、Solana 等广泛采用。
5. 注意事项
- 私钥管理：必须安全存储种子（32 字节）。
- 库的选择：优先使用审计过的库（如
ed25519-dalek）。 - 不要自行实现密码学：直接使用标准库。
RSA
引导
✔️❌标志文章更新时刻仍在维护
市值记录
区块链开发部署工具
✔️hardhat
- 从开发到部署全覆盖的工具，内置hardhat node等内部测试链。
- 工具全面但相对比较臃肿，类似hardhat-ethers、hardhat-viem等包均涉及，想将大部分内容包含进生态中。
- 基础的开发部署命令例如hardhat deploy等已经具备部署能力，又有hardhat ignition这类新加入的工具提供同样的效果，增加链上合约管理等功能。工具之间同质化较麻烦。
✔️Foundry-登链社区中文翻译
- 后起之秀，工具集健全，目前没有过于臃肿。
区块链交互工具
❌web3.js
- 当前使用量最高的交互工具，大量的开发项目使用此库进行开发
- doc文档丰富且全面，指引较多
- 截止2025.3.4号已经停更，详情可见ChainSafe
✔️ethers.js
- 截止2025.3.25仍在更新的交互工具
- doc内容偏应用，没有太多说明
✔️viem
- 截止2025.3.25仍在更新的交互工具
- 性能不错，相关对比测试。暂未发现第三方的实验数据，按照官方文档看来处理交互数据速度极快，似乎相当适合cex/dex高频交易？对于链上追踪聪明钱并短线跟投谋利的公司具有较强吸引力。
- ts库，在纯 JavaScript 项目中使用 Viem 时，无法利用 TypeScript 提供的类型检查功能。需要自行确保传递给 Viem 函数的参数类型正确
Ethereum
概览(官方介绍)
什么是以太坊？
以太坊是一个由世界各地的计算机组成的网络，遵循一套称为以太坊协议的规则。以太坊网络提供了一个基础，任何人都可以在上面构建和使用社区、应用程序、组织和数字资产。
谁在运行以太坊？
以太坊不受任何特定实体控制。只要计算机运行遵循以太坊协议的软件，相互连接，并为以太坊区块链添加区块，以太坊就会存在。其中每一台计算机都被称为节点。任何人都可以运行节点，但必须要质押以太币（以太坊的原生代币）才能参与保护网络安全的工作。任何人无需许可，都可以用 32 个以太币参与质押。 甚至以太坊的源代码也不是由单个实体生成的。任何人都可以建议更改协议并讨论升级。有一些以太坊协议的实现是由独立组织用多种编程语言完成的，它们通常建立在开放的基础上并鼓励来自社区的贡献。
以太坊基础
以太坊(Ethereum)是继比特币之后最具影响力的区块链平台，被誉为"区块链2.0"。不同于比特币专注于数字货币，以太坊创建了一个去中心化的全球计算机，使开发者能够构建各种应用程序。以下收集了以太坊的基础知识，包括其技术架构、核心概念、重要协议升级及其广泛的应用生态系统。
以太坊的核心概念
1. 智能合约
智能合约是以太坊最具革命性的特性，它们是部署在区块链上的自动执行程序。
- 定义：智能合约是一套以数字形式定义的承诺，包含了合约参与方可以执行的协议。
- 特点：自动执行、不可篡改、透明公开
- 语言：主要使用Solidity语言编写，也支持Vyper、Yul等
- 执行环境：以太坊虚拟机(EVM)
智能合约的代码示例(Solidity)：
// 简单的代币合约示例
pragma solidity ^0.8.0;
contract SimpleToken {
string public name;
string public symbol;
uint256 public totalSupply;
mapping(address => uint256) public balanceOf;
event Transfer(address indexed from, address indexed to, uint256 value);
constructor(string memory _name, string memory _symbol, uint256 _totalSupply) {
name = _name;
symbol = _symbol;
totalSupply = _totalSupply;
balanceOf[msg.sender] = _totalSupply;
}
function transfer(address _to, uint256 _value) public returns (bool success) {
require(balanceOf[msg.sender] >= _value, "Insufficient balance");
balanceOf[msg.sender] -= _value;
balanceOf[_to] += _value;
emit Transfer(msg.sender, _to, _value);
return true;
}
}
2. 以太坊虚拟机(EVM)
EVM是以太坊的核心组件，负责处理智能合约的执行。
- 特点：图灵完备，可以运行任何计算程序
- 操作：基于操作码(Opcodes)执行指令
- 隔离性：合约在沙箱环境中运行，确保安全性
- 状态：维护全球状态树，记录所有账户状态
3. 账户系统
以太坊有两种类型的账户：
-
外部账户(EOA)：
- 由用户控制（通过私钥）
- 可以发送交易
- 没有关联代码
-
合约账户：
- 由代码控制
- 只能响应收到的交易
- 存储合约代码和状态
4. 燃料(Gas)机制
Gas是以太坊上计算资源使用的度量单位：
- 目的：防止资源滥用和无限循环攻击
- 计算方式：每个操作都有特定的Gas成本
- Gas价格：以Gwei(10^-9 ETH)为单位，由交易发送者设定
- Gas上限：交易中指定的最大Gas使用量
- EIP-1559：2021年8月伦敦升级引入的新费用模型，引入基础费用和小费机制
5. 以太币(Ether)
以太币是以太坊网络的原生加密货币：
- 符号：ETH
- 功能：支付交易费用、智能合约操作费用、价值存储
- 单位：Wei(最小单位)、Gwei、Finney、Ether等
- 发行：初始通过ICO发行，后续通过区块奖励产生
以太坊的技术架构
1. 区块结构
以太坊区块包含以下主要组件：
- 区块头：包含前一个区块哈希、时间戳、挖矿信息等
- 交易列表：区块中包含的所有交易
- 叔块信息：包含近期的孤块信息（针对PoW时代）
- 状态树：记录所有账户的当前状态
- 收据树：记录交易执行的结果和日志
2. 共识机制演进
以太坊的共识机制经历了重大变革：
-
工作量证明(PoW)：
- 初始共识机制
- 算法：Ethash，设计为ASIC抗性
- 区块时间：约15秒
-
权益证明(PoS)：
- 通过合并(The Merge)升级实现
- 验证者需质押至少32 ETH
- 能源效率提高99.95%
- 区块时间：约12秒
3. 分片(Sharding)
分片是以太坊可扩展性路线图的关键部分：
- 目标：并行处理交易，提高网络吞吐量
- 设计：将网络分成多个分片，每个分片处理一部分交易
- 状态：目前在路线图中，计划在合并后实施
- 挑战：跨分片通信、数据可用性、安全性保证
以太坊的重要协议升级
以太坊通过硬分叉实现协议升级，主要包括：
1. 前沿(Frontier) - 2015年7月
- 以太坊主网的初始版本
- 引入基本功能：智能合约、交易处理等
2. 家园(Homestead) - 2016年3月
- 第一个稳定版本
- 改进了安全性和交易处理
3. 拜占庭(Byzantium) - 2017年10月
- 元都(Metropolis)升级的第一阶段
- 增加了零知识证明等隐私功能
- 减少了挖矿奖励
4. 君士坦丁堡(Constantinople) - 2019年2月
- 优化了Gas成本
- 延迟了难度炸弹
- 为权益证明过渡做准备
5. 伊斯坦布尔(Istanbul) - 2019年12月
- 提高了Gas使用效率
- 改进了Layer 2解决方案的兼容性
6. 信标链(Beacon Chain) - 2020年12月
- 启动了PoS链
- 为"合并"奠定基础
7. 伦敦(London) - 2021年8月
- 引入EIP-1559费用机制
- 部分ETH燃烧，引入通缩机制
8. 合并(The Merge) - 2022年9月
- 将执行层(原PoW链)与共识层(信标链)结合
- 从PoW完全过渡到PoS
- 减少了约99.95%的能源消耗
9. 上海(Shanghai)/卡佩拉(Capella) - 2023年4月
- 允许质押ETH的提取
- 提高了EVM效率
10. Cancun/Deneb - 2024年
- 引入Proto-Danksharding (EIP-4844)
- 降低了Layer 2的成本
- 改进了EVM功能
以太坊的应用生态系统
1. 代币标准
以太坊上有多种代币标准，最著名的包括：
- ERC-20：同质化代币标准，用于加密货币和实用代币
- ERC-721：非同质化代币(NFT)标准，每个代币都是独特的
- ERC-1155：多代币标准，支持同质化和非同质化代币
- ERC-4626：代币化资金库标准，用于收益聚合
2. DeFi(去中心化金融)
以太坊是DeFi的主要平台，包括：
- 去中心化交易所：Uniswap、Curve、SushiSwap
- 借贷协议：Aave、Compound、MakerDAO
- 衍生品：Synthetix、dYdX
- 保险：Nexus Mutual、InsurAce
- 收益聚合：Yearn Finance、Convex
3. NFT(非同质化代币)
NFT在以太坊上实现了突破性增长：
- 数字艺术：Art Blocks、SuperRare
- 收藏品：CryptoPunks、Bored Ape Yacht Club
- 游戏资产：Axie Infinity、Gods Unchained
- 虚拟土地：Decentraland、The Sandbox
- 社交代币：ENS域名、POAP
4. Layer 2扩展解决方案
为解决以太坊可扩展性问题，出现了多种Layer 2解决方案：
- Rollups：
- Optimistic Rollups：Optimism、Arbitrum
- ZK-Rollups：zkSync、StarkNet
- 状态通道：提供链下交易确认
- 侧链：Polygon PoS、Gnosis Chain
5. 去中心化自治组织(DAO)
以太坊上的DAO实现了去中心化治理：
- 协议治理：Uniswap、Compound
- 投资DAO：BitDAO、Flamingo
- 服务DAO：Gitcoin、RaidGuild
- 社交DAO：Friends With Benefits、PleasrDAO
以太坊开发工具与框架
1. 开发环境
- Remix：基于网页的IDE，适合入门
- Hardhat：JavaScript开发环境
- Truffle Suite：完整开发框架
- Foundry：Rust编写的快速开发工具
2. 库与API
- web3.js：JavaScript库
- ethers.js：替代web3.js的现代库
- Infura/Alchemy：节点服务提供商
- The Graph：区块链数据索引
3. 测试网络
- Sepolia：当前主要测试网
- Goerli：即将淘汰的测试网
- Holesky：新的权益证明测试网
以太坊的挑战与未来
1. 可扩展性
尽管有了Layer 2解决方案，以太坊的基础层仍面临吞吐量限制：
- 交易处理能力：主网约15-30 TPS
- 高Gas费：在网络拥堵时期可能非常昂贵
- 解决方案：分片、数据可用性采样(DAS)、Layer 2优化
2. 监管与合规
随着以太坊应用的增长，监管挑战也随之增加：
- 证券法规：某些代币可能被视为证券
- KYC/AML：DeFi协议的合规要求
- 跨境监管：不同国家的监管差异
3. 去中心化与安全性
保持去中心化同时确保安全性是持续挑战：
- 验证者集中化：大型质押池的影响
- MEV(最大可提取价值)：交易排序的公平性问题
- 智能合约漏洞：代码审计和安全实践的重要性
4. 路线图：迈向以太坊2.0
以太坊的未来发展计划包括：
- Proto-Danksharding：通过blob交易提高数据可用性
- 全分片：实现完整的数据和执行分片
- 单一时隙确定性：减少确认时间
- EVM改进：持续优化虚拟机性能
- 状态过期：解决状态膨胀问题
ERC
ERC 是 Ethereum Request for Comments（以太坊请求评论）的缩写。它是以太坊社区定义的一系列智能合约标准。这些标准为以太坊上的智能合约开发提供了规则和指南，确保不同开发者创建的合约能够相互交互和兼容。
ERC 的主要作用
互操作性
在以太坊生态系统中 ，不同的开发者可能会创建各种各样的智能合约。ERC 标准允许这些合约以一种统一的方式进行交互。例如，在去中心化金融（DeFi）领域，有许多不同的应用程序，如借贷平台、去中心化交易所等。ERC - 20 标准的存在使得各种通证能够在这些不同的平台之间方便地流通和交易。
标准化开发
为开发者提供了清晰的开发指南。以 ERC - 721 为例，这个标准专门用于非同质化通证（NFT）。它规定了 NFT 合约必须实现的一些基本方法，如balanceOf（查询某个地址拥有的 NFT 数量）、ownerOf（查询某个 NFT 的所有者）和transferFrom（转移 NFT 的所有权）等。这使得开发者在创建 NFT 项目时能够遵循一套既定的规则，减少开发过程中的混乱，并确保所开发的 NFT 能够被市场上的各种钱包和应用程序所支持。
常见的 ERC 标准
ERC - 20
这是最著名的 ERC 标准之一，主要用于创建可互换的数字资产，也就是同质化通证。在以太坊上发行的大多数加密货币（如以太坊本身之外的许多山寨币）都遵循 ERC - 20 标准。它定义了一套接口，包括totalSupply（总供应量）、balanceOf（账户余额）、transfer（转账）、transferFrom（授权转账）、approve（授权）等方法。
ERC - 721：
专为非同质化通证（NFT）设计。与 ERC - 20 不同，ERC - 721 中的每个通证都是独一无二的，不能与其他通证互换。NFT 在数字艺术、游戏道具、虚拟房地产等领域有广泛的应用。通过 ERC - 721 标准，这些独特的资产可以在以太坊区块链上安全地创建、拥有和交易。
ERC - 1155：
这是一种多令牌标准，它结合了 ERC - 20 和 ERC - 721 的特点。ERC - 1155 允许在一个智能合约中同时管理多种类型的通证，包括同质化和非同质化通证。这种标准在游戏开发等场景中特别有用，因为游戏中可能同时存在可互换的游戏货币和独一无二的游戏道具。
概念
ERC-20 标准的 ABI 是一组函数和事件定义，用于在以太坊上实现可互换的代币标准。ERC-20 代币标准由以太坊社区提出，定义了一组基础接口和功能，如余额查询、转账和授权等。
目前以太坊等支持evm的链上最活跃的合约标准，大量的加密货币依赖此合约进行交易。
ERC-20 ABI 说明
-
Functions：
totalSupply：返回代币的总供应量。balanceOf：查询指定地址的余额。transfer：从发送者地址向指定地址发送代币。approve：批准某个地址可以花费指定数量的代币。allowance：查询某个地址对另一个地址授权的代币数量。transferFrom：从指定地址向另一个地址转移代币（需要先批准）。
-
Events：
Transfer：代币转移事件，记录从一个地址向另一个地址转移的情况。Approval：授权事件，记录某个地址被授权花费代币。
-
Metadata Functions（非强制但通常包含）：
name：代币的名称。symbol：代币的符号。decimals：代币的小数位数，通常是 18。
ERC-20 标准 ABI
以下是 ERC-20 标准 ABI，用于与符合 ERC-20 标准的合约进行交互：
[
{
"constant": true,
"inputs": [{"name": "_owner", "type": "address"}],
"name": "balanceOf",
"outputs": [{"name": "balance", "type": "uint256"}],
"payable": false,
"stateMutability": "view",
"type": "function"
},
{
"constant": false,
"inputs": [
{"name": "_to", "type": "address"},
{"name": "_value", "type": "uint256"}
],
"name": "transfer",
"outputs": [{"name": "", "type": "bool"}],
"payable": false,
"stateMutability": "nonpayable",
"type": "function"
},
{
"constant": false,
"inputs": [
{"name": "_spender", "type": "address"},
{"name": "_value", "type": "uint256"}
],
"name": "approve",
"outputs": [{"name": "", "type": "bool"}],
"payable": false,
"stateMutability": "nonpayable",
"type": "function"
},
{
"constant": true,
"inputs": [
{"name": "_owner", "type": "address"},
{"name": "_spender", "type": "address"}
],
"name": "allowance",
"outputs": [{"name": "", "type": "uint256"}],
"payable": false,
"stateMutability": "view",
"type": "function"
},
{
"constant": false,
"inputs": [
{"name": "_from", "type": "address"},
{"name": "_to", "type": "address"},
{"name": "_value", "type": "uint256"}
],
"name": "transferFrom",
"outputs": [{"name": "", "type": "bool"}],
"payable": false,
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [],
"payable": false,
"stateMutability": "nonpayable",
"type": "constructor"
},
{
"anonymous": false,
"inputs": [
{"indexed": true, "name": "owner", "type": "address"},
{"indexed": true, "name": "spender", "type": "address"},
{"indexed": false, "name": "value", "type": "uint256"}
],
"name": "Approval",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{"indexed": true, "name": "from", "type": "address"},
{"indexed": true, "name": "to", "type": "address"},
{"indexed": false, "name": "value", "type": "uint256"}
],
"name": "Transfer",
"type": "event"
},
{
"constant": true,
"inputs": [],
"name": "totalSupply",
"outputs": [{"name": "", "type": "uint256"}],
"payable": false,
"stateMutability": "view",
"type": "function"
},
{
"constant": true,
"inputs": [],
"name": "name",
"outputs": [{"name": "", "type": "string"}],
"payable": false,
"stateMutability": "view",
"type": "function"
},
{
"constant": true,
"inputs": [],
"name": "symbol",
"outputs": [{"name": "", "type": "string"}],
"payable": false,
"stateMutability": "view",
"type": "function"
},
{
"constant": true,
"inputs": [],
"name": "decimals",
"outputs": [{"name": "", "type": "uint8"}],
"payable": false,
"stateMutability": "view",
"type": "function"
}
]
如何使用 ERC-20 ABI
使用上面的 ABI 和 web3.js 或 ethers.js 库，可以轻松与符合 ERC-20 标准的智能合约交互。
使用 ethers.js 示例：
使用 web3.js 示例：
const Web3 = require('web3');
const web3 = new Web3('https://mainnet.infura.io/v3/YOUR_INFURA_PROJECT_ID');
const erc20ABI = [/* 这里粘贴上面的 ERC-20 ABI */];
const contractAddress = '0xTokenContractAddress'; // 替换为 ERC-20 代币合约地址
const erc20Contract = new web3.eth.Contract(erc20ABI, contractAddress);
erc20Contract.methods.balanceOf('0xYourAddress').call()
.then(balance => console.log(`Token Balance: ${balance}`));
总结
ERC-20 标准 ABI 包含了代币的核心功能，如代币转移、余额查询和授权操作。通过使用此标准的 ABI，你可以与任何 ERC-20 兼容的合约进行交互。
如何调用任意ERC20合约
详见github项目BlockChain_InteractTools
ERC712
ERC721概念
NFT的标准实现，作为同质化代币的合约标准。具有存储元数据及拥有者，以及对应的查询、管理功能。
主要功能
-
事件 (Events)：
Transfer：当 NFT 被转移时触发。Approval：当某个地址被授权管理 NFT 时触发。ApprovalForAll：当某个地址被授权管理所有 NFT 时触发。
-
方法 (Functions)：
balanceOf(address owner)：查询某地址拥有的 NFT 数量。ownerOf(uint256 tokenId)：查询某个 NFT 的持有者。approve(address to, uint256 tokenId)：授权某个地址管理指定的 NFT。setApprovalForAll(address operator, bool approved)：批量授权某个地址管理所有 NFT。getApproved(uint256 tokenId)：查询某个 NFT 被授权的地址。isApprovedForAll(address owner, address operator)：查询某个地址是否被批量授权。safeTransferFrom(address from, address to, uint256 tokenId)：安全转移 NFT。tokenURI(uint256 tokenId)：查询 NFT 的元数据 URI。
下面是一个标准的 ERC-721 代币合约的 ABI（Application Binary Interface），基于 OpenZeppelin 的实现：
[
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "from",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "to",
"type": "address"
},
{
"indexed": true,
"internalType": "uint256",
"name": "tokenId",
"type": "uint256"
}
],
"name": "Transfer",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "owner",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "approved",
"type": "address"
},
{
"indexed": true,
"internalType": "uint256",
"name": "tokenId",
"type": "uint256"
}
],
"name": "Approval",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "owner",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "operator",
"type": "address"
},
{
"indexed": false,
"internalType": "bool",
"name": "approved",
"type": "bool"
}
],
"name": "ApprovalForAll",
"type": "event"
},
{
"inputs": [
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256",
"name": "tokenId",
"type": "uint256"
}
],
"name": "approve",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "owner",
"type": "address"
}
],
"name": "balanceOf",
"outputs": [
{
"internalType": "uint256",
"name": "",
"type": "uint256"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [
{
"internalType": "uint256",
"name": "tokenId",
"type": "uint256"
}
],
"name": "getApproved",
"outputs": [
{
"internalType": "address",
"name": "",
"type": "address"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "owner",
"type": "address"
},
{
"internalType": "address",
"name": "operator",
"type": "address"
}
],
"name": "isApprovedForAll",
"outputs": [
{
"internalType": "bool",
"name": "",
"type": "bool"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "from",
"type": "address"
},
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256",
"name": "tokenId",
"type": "uint256"
}
],
"name": "safeTransferFrom",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "from",
"type": "address"
},
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256",
"name": "tokenId",
"type": "uint256"
},
{
"internalType": "bytes",
"name": "_data",
"type": "bytes"
}
],
"name": "safeTransferFrom",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "operator",
"type": "address"
},
{
"internalType": "bool",
"name": "approved",
"type": "bool"
}
],
"name": "setApprovalForAll",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "bytes4",
"name": "interfaceId",
"type": "bytes4"
}
],
"name": "supportsInterface",
"outputs": [
{
"internalType": "bool",
"name": "",
"type": "bool"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [
{
"internalType": "uint256",
"name": "tokenId",
"type": "uint256"
}
],
"name": "ownerOf",
"outputs": [
{
"internalType": "address",
"name": "",
"type": "address"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [],
"name": "name",
"outputs": [
{
"internalType": "string",
"name": "",
"type": "string"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [],
"name": "symbol",
"outputs": [
{
"internalType": "string",
"name": "",
"type": "string"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [
{
"internalType": "uint256",
"name": "tokenId",
"type": "uint256"
}
],
"name": "tokenURI",
"outputs": [
{
"internalType": "string",
"name": "",
"type": "string"
}
],
"stateMutability": "view",
"type": "function"
}
]
EIP1155
ERC-1155 是一种以太坊代币标准，它定义了一种智能合约接口，可以管理多种代币类型。与 ERC-721（非同质化代币）和 ERC-20（同质化代币）不同，ERC-1155 允许在一个智能合约中同时处理这两种类型的代币，甚至还支持“半同质化”代币。
ERC-1155 的关键特性：
- 多重代币支持：
- ERC-1155 合约可以管理多种代币类型，包括：
- 同质化代币（如游戏中的金币或虚拟货币）
- 非同质化代币（如独特的游戏道具或数字艺术品）
- 半同质化代币（例如，一定数量的游戏门票，这些门票具有相同的属性，但是总数有限）
- ERC-1155 合约可以管理多种代币类型，包括：
- 批量转移：
- ERC-1155 允许一次交易转移多种代币，从而显著提高了效率并降低了 gas 成本。
- 高效性：
- 通过共享相同的合约逻辑，ERC-1155 减少了部署和管理多个合约的需要，从而节省了 gas 费用。
- 元数据 URI：
- ERC-1155 定义了一种标准的方法来存储代币的元数据（如名称、描述和图像），从而简化了数字资产的管理和显示。
- 安全转移：
- ERC-1155定义了安全转移代币的机制，避免了代币意外丢失或者被盗的情况。
ERC-1155 的应用场景：
- 游戏：
- 管理游戏中的各种资产，如道具、角色和货币。
- 数字艺术品：
- 表示限量版数字艺术品或收藏品。
- 供应链管理：
- 跟踪和管理供应链中的各种资产。
- 票务：
- 管理活动门票，优惠券等等。
ERC-1155 的优势：
- 提高了代币管理的灵活性和效率。
- 降低了交易成本。
- 简化了数字资产的开发和集成。
ERC-1155 方法：
balanceOf(address account, uint256 id):- 查询指定账户拥有的指定 ID 的代币数量。
balanceOfBatch(address[] accounts, uint256[] ids):- 批量查询多个账户拥有的多个 ID 的代币数量。
safeTransferFrom(address from, address to, uint256 id, uint256 amount, bytes data):- 安全地将指定数量的指定 ID 的代币从一个账户转移到另一个账户。
safeBatchTransferFrom(address from, address to, uint256[] ids, uint256[] amounts, bytes data):- 安全地批量将多个 ID 的代币从一个账户转移到另一个账户。
setApprovalForAll(address operator, bool approved):- 允许或禁止指定操作员代表调用者管理其所有代币。
isApprovedForAll(address account, address operator):- 查询指定操作员是否被授权代表指定账户管理其所有代币。
ERC-1155 事件：
TransferSingle(address operator, address from, address to, uint256 id, uint256 value):- 当单个代币被转移时发出。
TransferBatch(address operator, address from, address to, uint256[] ids, uint256[] values):- 当多个代币被批量转移时发出。
ApprovalForAll(address operator, address account, bool value):- 当操作员的授权状态发生变化时发出。
URI(string value, uint256 id):- 当代币的 URI（统一资源标识符）发生变化时发出。URI 通常指向包含代币元数据的 JSON 文件。
关键概念：
- ID：
- 用于唯一标识 ERC-1155 合约中不同代币的标识符。
- Amount：
- 表示要转移或查询的代币数量。
- Operator：
- 被授权代表账户管理代币的地址。
- URI：
- 统一资源标识符，指向代币元数据。
- 元数据：
- 对tokenId的描述，通常包括名称，描述，图片url等等信息。
[
{
"inputs": [
{
"internalType": "address",
"name": "account",
"type": "address"
},
{
"internalType": "uint256",
"name": "id",
"type": "uint256"
}
],
"name": "balanceOf",
"outputs": [
{
"internalType": "uint256",
"name": "",
"type": "uint256"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [
{
"internalType": "address[]",
"name": "accounts",
"type": "address[]"
},
{
"internalType": "uint256[]",
"name": "ids",
"type": "uint256[]"
}
],
"name": "balanceOfBatch",
"outputs": [
{
"internalType": "uint256[]",
"name": "",
"type": "uint256[]"
}
],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "from",
"type": "address"
},
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256[]",
"name": "ids",
"type": "uint256[]"
},
{
"internalType": "uint256[]",
"name": "amounts",
"type": "uint256[]"
},
{
"internalType": "bytes",
"name": "data",
"type": "bytes"
}
],
"name": "safeBatchTransferFrom",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "from",
"type": "address"
},
{
"internalType": "address",
"name": "to",
"type": "address"
},
{
"internalType": "uint256",
"name": "id",
"type": "uint256"
},
{
"internalType": "uint256",
"name": "amount",
"type": "uint256"
},
{
"internalType": "bytes",
"name": "data",
"type": "bytes"
}
],
"name": "safeTransferFrom",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "operator",
"type": "address"
},
{
"internalType": "bool",
"name": "approved",
"type": "bool"
}
],
"name": "setApprovalForAll",
"outputs": [],
"stateMutability": "nonpayable",
"type": "function"
},
{
"inputs": [
{
"internalType": "address",
"name": "account",
"type": "address"
},
{
"internalType": "address",
"name": "operator",
"type": "address"
}
],
"name": "isApprovedForAll",
"outputs": [
{
"internalType": "bool",
"name": "",
"type": "bool"
}
],
"stateMutability": "view",
"type": "function"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "operator",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "from",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "to",
"type": "address"
},
{
"indexed": false,
"internalType": "uint256[]",
"name": "ids",
"type": "uint256[]"
},
{
"indexed": false,
"internalType": "uint256[]",
"name": "values",
"type": "uint256[]"
}
],
"name": "TransferBatch",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "operator",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "from",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "to",
"type": "address"
},
{
"indexed": false,
"internalType": "uint256",
"name": "id",
"type": "uint256"
},
{
"indexed": false,
"internalType": "uint256",
"name": "value",
"type": "uint256"
}
],
"name": "TransferSingle",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{
"indexed": true,
"internalType": "address",
"name": "operator",
"type": "address"
},
{
"indexed": true,
"internalType": "address",
"name": "account",
"type": "address"
},
{
"indexed": false,
"internalType": "bool",
"name": "value",
"type": "bool"
}
],
"name": "ApprovalForAll",
"type": "event"
},
{
"anonymous": false,
"inputs": [
{
"indexed": false,
"internalType": "string",
"name": "value",
"type": "string"
},
{
"indexed": true,
"internalType": "uint256",
"name": "id",
"type": "uint256"
}
],
"name": "URI",
"type": "event"
}
]
EIP2612
EIP3009
EIP4626
授权竞争攻击（Approval Race Condition）
EIP20提案中approve函数声明提过的一种数据攻击。
缺陷代码示例
在区块链中，**授权竞争攻击（Approval Race Condition）**是一种与代币授权机制（如ERC-20标准中的approve函数）相关的攻击方式。它利用了区块链交易的异步性和用户授权行为的时间差，允许攻击者在用户不知情的情况下窃取代币。这种攻击通常发生在用户与去中心化应用（DApp）或智能合约交互时，尤其是在涉及代币转移的场景中。以下是对授权竞争攻击的详细讲解：
1. 背景：ERC-20的授权机制
在ERC-20代币标准中，approve函数允许用户授权某个地址（通常是智能合约）代表自己花费一定数量的代币。例如：
- 用户A调用
approve(合约地址, 100)，授权某个合约从A的账户中转移100个代币。 - 随后，合约可以通过
transferFrom函数执行实际的代币转移。
这种机制广泛用于DeFi协议、NFT市场等场景。然而，如果用户需要调整授权额度，就会引发潜在的竞争条件问题。
2. 授权竞争攻击的原理
授权竞争攻击的核心在于以下步骤：
- 初始授权：用户A已经授权了一个攻击者控制的合约（或恶意DApp）一定的代币额度，比如100个代币。
- 用户调整授权：用户A发现需要更改授权额度（例如从100减少到50，或增加到200），于是调用
approve函数发起新交易。 - 攻击者抢跑：攻击者监控区块链的内存池（mempool），发现用户A的新
approve交易尚未确认。攻击者在用户交易确认前，迅速提交一笔transferFrom交易，使用旧的授权额度（100个代币）提取代币。 - 结果：用户A的新授权交易最终确认，但攻击者已经利用旧授权偷走了代币。
这种攻击利用了区块链交易的非原子性（即交易不是瞬间完成，而是需要时间确认）和公开性（内存池中的交易对所有人可见）。
3. 攻击流程示例
假设用户A的代币余额为200，攻击者控制的合约为MaliciousContract：
- 用户A调用
approve(MaliciousContract, 100)，授权100个代币。 - 后来，用户A决定减少授权，调用
approve(MaliciousContract, 50)，并等待交易确认。 - 攻击者看到内存池中的
approve(MaliciousContract, 50)交易，立即调用transferFrom(A, 攻击者地址, 100)，使用旧的授权提取100个代币。 - 用户A的
approve(MaliciousContract, 50)交易确认，但此时100个代币已被转移，攻击得逞。
4. 为什么会发生？
- 授权不是原子操作：
approve函数只更新授权额度，而不撤销之前的转移能力。在新授权生效前，旧授权仍然有效。 - 内存池透明：攻击者可以实时监控未确认交易，并抢先提交自己的交易（通过提高Gas费用实现“抢跑”）。
- 用户行为：许多用户直接调整授权额度，而不是先将授权设为0再设为新值。
5. 防范措施
（1）安全的授权流程
- 用户在调整授权时，应采用“先清零，再设置新值”的两步操作：
- 调用
approve(合约地址, 0)，等待确认。 - 确认后，再调用
approve(合约地址, 新额度)。
- 调用
- 这种方法确保旧授权被撤销，消除竞争窗口。
- 注意
approve(合约地址, 0)同样无法完全避免攻击者抢跑的问题。交易未确认前，旧授权仍然有效，攻击者可以抢先调用transferFrom。 它仅能保证新授权顺利执行：一旦清零交易确认，旧授权被撤销，新授权可以在安全状态下生效。 新授权后再次被转走的风险：取决于后续操作和合约的可信度。如果用户授权给了恶意合约，新授权的代币仍可能被转走，但这属于另一类问题（非竞争攻击）。
（2）使用increaseAllowance和decreaseAllowance
- ERC-20扩展函数
increaseAllowance和decreaseAllowance允许用户增量调整授权，而无需直接覆盖旧值。 - 例如：
increaseAllowance(合约地址, 50)增加50个代币的授权，而不是直接调用approve。 - 实现示例如USDC，可以查看本博客源码解析篇FiatTokenV2_2
（3）合约端的保护
- 智能合约开发者可以在
transferFrom中添加检查，确保调用时的授权额度与预期一致，避免滥用旧授权。 - 使用一次性授权（Nonce）或时间锁，限制授权的有效期。
（4）用户教育
- 提醒用户谨慎授权，尤其是对未知合约，避免直接调整授权额度。
- 使用支持“撤销授权”的钱包（如MetaMask），定期检查并清理不必要的授权。
（5）Gas竞争应对
- 用户可以提高Gas费用，确保自己的
approve交易尽快确认，减少攻击者的抢跑机会。
6. 实际案例
- Uniswap早期问题：早期版本的Uniswap用户在调整流动性池授权时，偶尔会遇到类似问题，导致代币被恶意合约窃取。
- DeFi协议漏洞：一些小型DeFi项目因未提醒用户安全授权流程，遭受过授权竞争攻击。
7. 改进建议与新标准
为了彻底解决这个问题，一些新代币标准（如ERC-777、ERC-1155）尝试改进授权机制：
- ERC-777：引入
operator机制和回调函数，允许更灵活的授权管理。 - Permit函数（EIP-2612）：允许用户通过签名离线授权，避免直接调用
approve，从而减少链上竞争风险。
Rollup
ZK
Ethers.js 通过私钥还原公钥
一、什么是私钥和公钥？
在以太坊和其他区块链平台中，私钥是一个源信息，用于命令链上账户进行操作。公钥则是从私钥中运算出的，用于验证操作的合法性和完整性。
二、安装 ethers.js
在实现私钥还原公钥之前，需要先安装 ethers.js：
npm install ethers
三、使用 ethers.js 运算公钥
以下是通过 ethers.js 将私钥转换为公钥的完整代码：
const { Wallet } = require('ethers');
// 私钥（确保保密！）
const privateKey = "0x1e99423a701fcf82f4888e3e23b6c1840ad48d360bb8bc1239e0c7ff8ecf743d";
// 从私钥生成钥包实例
const wallet = new Wallet(privateKey);
// 获取公钥
const publicKey = wallet.publicKey;
console.log("私钥:", privateKey);
console.log("公钥:", publicKey);
输出格式
- 私钥：输入值，64 个十六进制字符，前缀为
0x。 - 公钥：未压缩格式，524-bit （含前缀
0x04），起始为一个指针。
示例输出
私钥: 0x1e99423a701fcf82f4888e3e23b6c1840ad48d360bb8bc1239e0c7ff8ecf743d
公钥: 0x04bfcab4e67d19d84cf2047269de360f3e51b50fa5c45594f5365ff3c7ec8f3f482c909de42ccadf81a913e51e535fc327fced47adf968f2bf4bfdbc5f8862bb2d
四、运算原理解析
使用的替代：secp256k1
ethers.js 使用了 secp256k1 椭圆曲线，这是比特币和以太坊等区块链系统使用的标准曲线。secp256k1 定义了一个椭圆曲线方程：y^2 = x^3 + 7，并基于此定义了一个基点 G。公钥是通过私钥对基点 G 进行椭圆曲线点乘计算得出的。这个过程确保了私钥与公钥之间的唯一性和安全性，同时公钥可以公开用于验证签名的合法性。
ERC常用实战
ERC20
ERC721
ERC1155
ERC4626
自定义ERC20代币 V1版本
- 完整实现ERC20标准
- approve函数未做安全处理（缺陷），未引用openzepplin安全库。
- 完整的项目包含测试等将后续更新在github仓库里
// SPDX-License-Identifier: MIT
/**
* @title CustomizedERC20
* @author github.com/codermaybe
* @dev CustomizedERC20 is a customized ERC20 token with a few additional features.
* @dev 本合约仅用于学习和研究。所有复现均按照eip20标准。详见：https://github.com/ethereum/ercs/blob/master/ERCS/erc-20.md
* @dev 自行复现的erc20各项功能。
* @dev V1版本特性：1.除复现各标准函数外增加 _contractOwner字段，增加erc20未定义但常用方法 mint()、burn()。暂无增加角色地址池，特殊操作均有合约拥有者控制。
*/
pragma solidity ^0.8.28;
contract CE20V1 {
address private _contractOwner; //自行设定，为合约拥有者
string private _name;
string private _symbol;
uint8 private _decimals;
uint256 private _totalSupply;
mapping(address => uint256) private _balances;
mapping(address => mapping(address => uint256)) _allowances;
event Transfer(address indexed _from, address indexed _to, uint256 _value);
event Approval(
address indexed _owner,
address indexed _spender,
uint256 _value
);
constructor(
string memory name,
string memory symbol,
uint8 decimals,
uint256 totalSupply
) {
_contractOwner = msg.sender;
_name = name;
_symbol = symbol;
_decimals = decimals;
_totalSupply = totalSupply;
_balances[msg.sender] = totalSupply;
emit Transfer(address(0), msg.sender, totalSupply);
}
/*
name
Returns the name of the token - e.g. "MyToken".
OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. */
function name() public view returns (string memory) {
return _name;
}
/*
symbol
Returns the symbol of the token. E.g. "HIX".
OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. */
function symbol() public view returns (string memory) {
return _symbol;
}
/*
decimals
Returns the number of decimals the token uses - e.g. 8, means to divide the token amount by 100000000 to get its user representation.
OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.*/
function decimals() public view returns (uint8) {
return _decimals;
}
/*
totalSupply
Returns the total token supply.*/
function totalSupply() public view returns (uint256) {
return _totalSupply;
}
/*
balanceOf
Returns the account balance of another account with address _owner. */
function balanceOf(address _owner) public view returns (uint256) {
return _balances[_owner];
}
/*
transfer
Transfers _value amount of tokens to address _to, and MUST fire the Transfer event.
The function SHOULD throw if the message caller's account balance does not have enough tokens to spend.
Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event. */
function transfer(address _to, uint256 _value) public returns (bool) {
require(_to != address(0), unicode"不可向0地址转账");
require(_balances[msg.sender] >= _value, unicode"余额不足");
require(_balances[_to] + _value > _balances[_to], unicode"数值溢出");
_balances[msg.sender] -= _value;
_balances[_to] += _value;
emit Transfer(msg.sender, _to, _value);
return true;
}
/*
transferFrom
Transfers _value amount of tokens from address _from to address _to, and MUST fire the Transfer event.
The transferFrom method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf.
This can be used for example to allow a contract to transfer tokens on your behalf and/or to charge fees in sub-currencies.
The function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism.
Note Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event. */
function transferFrom(
address _from,
address _to,
uint256 _value
) public returns (bool success) {
require(_to != address(0), unicode"不可向0地址转账");
require(
_allowances[_from][msg.sender] >= _value,
unicode"授权额度不足"
);
require(_balances[_from] >= _value, unicode"转账账户额度不足");
require(_balances[_to] + _value > _balances[_to], unicode"余额溢出");
_allowances[_from][msg.sender] -= _value;
_balances[_from] -= _value;
_balances[_to] += _value;
emit Transfer(_from, _to, _value);
return true;
}
/*
approve
Allows _spender to withdraw from your account multiple times, up to the _value amount.
If this function is called again it overwrites the current allowance with _value.
NOTE: To prevent attack vectors like the one described here and discussed here, clients SHOULD make sure to create user interfaces in such a way that they set the allowance first to 0 before setting it to another value for the same spender.
THOUGH The contract itself shouldn't enforce it, to allow backwards compatibility with contracts deployed before */
function approve(
//此版本未解决重入攻击,安全版本可检查CE20V1_openzepplin.sol
address _spender,
uint256 _value
) public returns (bool success) {
require(
_allowances[msg.sender][_spender] + _value >
_allowances[msg.sender][_spender],
unicode"授权额度溢出"
);
require(_spender != address(0), unicode"转账地址为0");
_allowances[msg.sender][_spender] = _value;
emit Approval(msg.sender, _spender, _value);
return true;
}
/*
allowance
Returns the amount which _spender is still allowed to withdraw from _owner.*/
function allowance(
address _owner,
address _spender
) public view returns (uint256 remaining) {
return _allowances[_owner][_spender];
}
/*自定义方法实现，使用mint派生代币 */
event Mint(address _to, uint256 _value);
function mint(address _to, uint256 _value) public {
require(
msg.sender == _contractOwner,
unicode"非合约拥有者无法派生代币"
);
require(_balances[_to] + _value > _balances[_to], unicode"余额溢出");
require(_totalSupply + _value > _totalSupply, unicode"总代币量将溢出");
_balances[_to] += _value;
_totalSupply += _value;
emit Transfer(address(0), _to, _value);
emit Mint(_to, _value);
}
/*自定义方法实现，使用burn燃烧代币 */
event Burn(address _from, uint256 _value);
function burn(address _from, uint256 _value) public {
require(
msg.sender == _contractOwner,
unicode"非合约拥有者无法派生代币"
);
require(
_balances[_from] >= _value,
unicode"检查燃烧的代币数量，超过用户余额"
);
_balances[_from] -= _value;
_totalSupply -= _value;
emit Burn(_from, _value);
}
}
WBNB
币安链的原生代币为BNB，与以太坊的ETH类似。 币安链和以太坊链不是完全相同。币安智能链(BSC)上的BEP标准和以太坊的EIP标准是两个不同的体系，但有意设计得相互兼容：
- EIP (Ethereum Improvement Proposals):
- 以太坊的改进提案体系
- 包括ERC (Ethereum Request for Comments)标准，如ERC-20、ERC-721等
- 为以太坊网络定义协议规范和合约标准
- BEP (Binance Evolution Proposals):
- 币安生态系统的改进提案体系
- 包括BEP-2(币安链)、BEP-20(币安智能链)等代币标准
- 为币安的区块链网络定义规范和标准
币安智能链的BEP-20标准刻意设计得与以太坊的ERC-20非常相似，以实现兼容性和便于迁移。这种设计让开发者可以相对容易地将以太坊上的智能合约部署到币安智能链上，只需要进行很小的修改。
这种兼容性是战略性的决定，让币安智能链能够吸引以太坊生态系统的开发者和用户，同时提供更低的交易费用和更高的交易速度。
此合约在币安智能链上的地址为WBNB
/**
*Submitted for verification at Bscscan.com on 2020-09-03
*/
pragma solidity ^0.4.18;
contract WBNB {
string public name = "Wrapped BNB";
string public symbol = "WBNB";
uint8 public decimals = 18;
event Approval(address indexed src, address indexed guy, uint wad);
event Transfer(address indexed src, address indexed dst, uint wad);
event Deposit(address indexed dst, uint wad);
event Withdrawal(address indexed src, uint wad);
mapping (address => uint) public balanceOf;
mapping (address => mapping (address => uint)) public allowance;
function() public payable {
deposit();
}
function deposit() public payable {
balanceOf[msg.sender] += msg.value;
Deposit(msg.sender, msg.value);
}
function withdraw(uint wad) public {
require(balanceOf[msg.sender] >= wad);
balanceOf[msg.sender] -= wad;
msg.sender.transfer(wad);
Withdrawal(msg.sender, wad);
}
function totalSupply() public view returns (uint) {
return this.balance;
}
function approve(address guy, uint wad) public returns (bool) {
allowance[msg.sender][guy] = wad;
Approval(msg.sender, guy, wad);
return true;
}
function transfer(address dst, uint wad) public returns (bool) {
return transferFrom(msg.sender, dst, wad);
}
function transferFrom(address src, address dst, uint wad)
public
returns (bool)
{
require(balanceOf[src] >= wad);
if (src != msg.sender && allowance[src][msg.sender] != uint(-1)) {
require(allowance[src][msg.sender] >= wad);
allowance[src][msg.sender] -= wad;
}
balanceOf[src] -= wad;
balanceOf[dst] += wad;
Transfer(src, dst, wad);
return true;
}
}
/*
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for
software and other kinds of works.
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too, receive
or can get the source code. And you must show them these terms so they
know their rights.
Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software. For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.
Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so. This is fundamentally incompatible with the aim of
protecting users' freedom to change the software. The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable. Therefore, we
have designed this version of the GPL to prohibit the practice for those
products. If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary. To prevent this, the GPL assures that
patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
1. Definitions.
"This License" refers to version 3 of the GNU General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that product
model, to give anyone who possesses the object code either (1) a
copy of the Corresponding Source for all the software in the
product that is covered by this License, on a durable physical
medium customarily used for software interchange, for a price no
more than your reasonable cost of physically performing this
conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to
copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party)
that supports equivalent copying facilities, provided you maintain
clear directions next to the object code saying where to find the
Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<http://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License. But first, please read
<http://www.gnu.org/philosophy/why-not-lgpl.html>.
*/
BNB
以太坊地址BNB
pragma solidity ^0.4.8;
/**
* Math operations with safety checks
*/
contract SafeMath {
function safeMul(uint256 a, uint256 b) internal returns (uint256) {
uint256 c = a * b;
assert(a == 0 || c / a == b);
return c;
}
function safeDiv(uint256 a, uint256 b) internal returns (uint256) {
assert(b > 0);
uint256 c = a / b;
assert(a == b * c + a % b);
return c;
}
function safeSub(uint256 a, uint256 b) internal returns (uint256) {
assert(b <= a);
return a - b;
}
function safeAdd(uint256 a, uint256 b) internal returns (uint256) {
uint256 c = a + b;
assert(c>=a && c>=b);
return c;
}
function assert(bool assertion) internal {
if (!assertion) {
throw;
}
}
}
contract BNB is SafeMath{
string public name;
string public symbol;
uint8 public decimals;
uint256 public totalSupply;
address public owner;
/* This creates an array with all balances */
mapping (address => uint256) public balanceOf;
mapping (address => uint256) public freezeOf;
mapping (address => mapping (address => uint256)) public allowance;
/* This generates a public event on the blockchain that will notify clients */
event Transfer(address indexed from, address indexed to, uint256 value);
/* This notifies clients about the amount burnt */
event Burn(address indexed from, uint256 value);
/* This notifies clients about the amount frozen */
event Freeze(address indexed from, uint256 value);
/* This notifies clients about the amount unfrozen */
event Unfreeze(address indexed from, uint256 value);
/* Initializes contract with initial supply tokens to the creator of the contract */
function BNB(
uint256 initialSupply,
string tokenName,
uint8 decimalUnits,
string tokenSymbol
) {
balanceOf[msg.sender] = initialSupply; // Give the creator all initial tokens
totalSupply = initialSupply; // Update total supply
name = tokenName; // Set the name for display purposes
symbol = tokenSymbol; // Set the symbol for display purposes
decimals = decimalUnits; // Amount of decimals for display purposes
owner = msg.sender;
}
/* Send coins */
function transfer(address _to, uint256 _value) {
if (_to == 0x0) throw; // Prevent transfer to 0x0 address. Use burn() instead
if (_value <= 0) throw;
if (balanceOf[msg.sender] < _value) throw; // Check if the sender has enough
if (balanceOf[_to] + _value < balanceOf[_to]) throw; // Check for overflows
balanceOf[msg.sender] = SafeMath.safeSub(balanceOf[msg.sender], _value); // Subtract from the sender
balanceOf[_to] = SafeMath.safeAdd(balanceOf[_to], _value); // Add the same to the recipient
Transfer(msg.sender, _to, _value); // Notify anyone listening that this transfer took place
}
/* Allow another contract to spend some tokens in your behalf */
function approve(address _spender, uint256 _value)
returns (bool success) {
if (_value <= 0) throw;
allowance[msg.sender][_spender] = _value;
return true;
}
/* A contract attempts to get the coins */
function transferFrom(address _from, address _to, uint256 _value) returns (bool success) {
if (_to == 0x0) throw; // Prevent transfer to 0x0 address. Use burn() instead
if (_value <= 0) throw;
if (balanceOf[_from] < _value) throw; // Check if the sender has enough
if (balanceOf[_to] + _value < balanceOf[_to]) throw; // Check for overflows
if (_value > allowance[_from][msg.sender]) throw; // Check allowance
balanceOf[_from] = SafeMath.safeSub(balanceOf[_from], _value); // Subtract from the sender
balanceOf[_to] = SafeMath.safeAdd(balanceOf[_to], _value); // Add the same to the recipient
allowance[_from][msg.sender] = SafeMath.safeSub(allowance[_from][msg.sender], _value);
Transfer(_from, _to, _value);
return true;
}
function burn(uint256 _value) returns (bool success) {
if (balanceOf[msg.sender] < _value) throw; // Check if the sender has enough
if (_value <= 0) throw;
balanceOf[msg.sender] = SafeMath.safeSub(balanceOf[msg.sender], _value); // Subtract from the sender
totalSupply = SafeMath.safeSub(totalSupply,_value); // Updates totalSupply
Burn(msg.sender, _value);
return true;
}
function freeze(uint256 _value) returns (bool success) {
if (balanceOf[msg.sender] < _value) throw; // Check if the sender has enough
if (_value <= 0) throw;
balanceOf[msg.sender] = SafeMath.safeSub(balanceOf[msg.sender], _value); // Subtract from the sender
freezeOf[msg.sender] = SafeMath.safeAdd(freezeOf[msg.sender], _value); // Updates totalSupply
Freeze(msg.sender, _value);
return true;
}
function unfreeze(uint256 _value) returns (bool success) {
if (freezeOf[msg.sender] < _value) throw; // Check if the sender has enough
if (_value <= 0) throw;
freezeOf[msg.sender] = SafeMath.safeSub(freezeOf[msg.sender], _value); // Subtract from the sender
balanceOf[msg.sender] = SafeMath.safeAdd(balanceOf[msg.sender], _value);
Unfreeze(msg.sender, _value);
return true;
}
// transfer balance to owner
function withdrawEther(uint256 amount) {
if(msg.sender != owner)throw;
owner.transfer(amount);
}
// can accept ether
function() payable {
}
}
USDC源码解析
文中代码所有来源均来自于etherscan verified contract ，代码中出现的相对路径可查阅以下链接 源代码快捷链接
USDC V1
USDC V1.1
USDC V2.0
FiatTokenProxy
pragma solidity ^0.4.24;
// File: zos-lib/contracts/upgradeability/Proxy.sol
/**
* @title Proxy
* @dev Implements delegation of calls to other contracts, with proper
* forwarding of return values and bubbling of failures.
* It defines a fallback function that delegates all calls to the address
* returned by the abstract _implementation() internal function.
*/
contract Proxy {
/**
* @dev Fallback function.
* Implemented entirely in `_fallback`.
*/
function () payable external {
_fallback();
}
/**
* @return The Address of the implementation.
*/
function _implementation() internal view returns (address);
/**
* @dev Delegates execution to an implementation contract.
* This is a low level function that doesn't return to its internal call site.
* It will return to the external caller whatever the implementation returns.
* @param implementation Address to delegate.
*/
function _delegate(address implementation) internal {
assembly {
// Copy msg.data. We take full control of memory in this inline assembly
// block because it will not return to Solidity code. We overwrite the
// Solidity scratch pad at memory position 0.
calldatacopy(0, 0, calldatasize)
// Call the implementation.
// out and outsize are 0 because we don't know the size yet.
let result := delegatecall(gas, implementation, 0, calldatasize, 0, 0)
// Copy the returned data.
returndatacopy(0, 0, returndatasize)
switch result
// delegatecall returns 0 on error.
case 0 { revert(0, returndatasize) }
default { return(0, returndatasize) }
}
}
/**
* @dev Function that is run as the first thing in the fallback function.
* Can be redefined in derived contracts to add functionality.
* Redefinitions must call super._willFallback().
*/
function _willFallback() internal {
}
/**
* @dev fallback implementation.
* Extracted to enable manual triggering.
*/
function _fallback() internal {
_willFallback();
_delegate(_implementation());
}
}
// File: openzeppelin-solidity/contracts/AddressUtils.sol
/**
* Utility library of inline functions on addresses
*/
library AddressUtils {
/**
* Returns whether the target address is a contract
* @dev This function will return false if invoked during the constructor of a contract,
* as the code is not actually created until after the constructor finishes.
* @param addr address to check
* @return whether the target address is a contract
*/
function isContract(address addr) internal view returns (bool) {
uint256 size;
// XXX Currently there is no better way to check if there is a contract in an address
// than to check the size of the code at that address.
// See https://ethereum.stackexchange.com/a/14016/36603
// for more details about how this works.
// TODO Check this again before the Serenity release, because all addresses will be
// contracts then.
// solium-disable-next-line security/no-inline-assembly
assembly { size := extcodesize(addr) }
return size > 0;
}
}
// File: zos-lib/contracts/upgradeability/UpgradeabilityProxy.sol
/**
* @title UpgradeabilityProxy
* @dev This contract implements a proxy that allows to change the
* implementation address to which it will delegate.
* Such a change is called an implementation upgrade.
*/
contract UpgradeabilityProxy is Proxy {
/**
* @dev Emitted when the implementation is upgraded.
* @param implementation Address of the new implementation.
*/
event Upgraded(address implementation);
/**
* @dev Storage slot with the address of the current implementation.
* This is the keccak-256 hash of "org.zeppelinos.proxy.implementation", and is
* validated in the constructor.
*/
bytes32 private constant IMPLEMENTATION_SLOT = 0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3;
/**
* @dev Contract constructor.
* @param _implementation Address of the initial implementation.
*/
constructor(address _implementation) public {
assert(IMPLEMENTATION_SLOT == keccak256("org.zeppelinos.proxy.implementation"));
_setImplementation(_implementation);
}
/**
* @dev Returns the current implementation.
* @return Address of the current implementation
*/
function _implementation() internal view returns (address impl) {
bytes32 slot = IMPLEMENTATION_SLOT;
assembly {
impl := sload(slot)
}
}
/**
* @dev Upgrades the proxy to a new implementation.
* @param newImplementation Address of the new implementation.
*/
function _upgradeTo(address newImplementation) internal {
_setImplementation(newImplementation);
emit Upgraded(newImplementation);
}
/**
* @dev Sets the implementation address of the proxy.
* @param newImplementation Address of the new implementation.
*/
function _setImplementation(address newImplementation) private {
require(AddressUtils.isContract(newImplementation), "Cannot set a proxy implementation to a non-contract address");
bytes32 slot = IMPLEMENTATION_SLOT;
assembly {
sstore(slot, newImplementation)
}
}
}
// File: zos-lib/contracts/upgradeability/AdminUpgradeabilityProxy.sol
/**
* @title AdminUpgradeabilityProxy
* @dev This contract combines an upgradeability proxy with an authorization
* mechanism for administrative tasks.
* All external functions in this contract must be guarded by the
* `ifAdmin` modifier. See ethereum/solidity#3864 for a Solidity
* feature proposal that would enable this to be done automatically.
*/
contract AdminUpgradeabilityProxy is UpgradeabilityProxy {
/**
* @dev Emitted when the administration has been transferred.
* @param previousAdmin Address of the previous admin.
* @param newAdmin Address of the new admin.
*/
event AdminChanged(address previousAdmin, address newAdmin);
/**
* @dev Storage slot with the admin of the contract.
* This is the keccak-256 hash of "org.zeppelinos.proxy.admin", and is
* validated in the constructor.
*/
bytes32 private constant ADMIN_SLOT = 0x10d6a54a4754c8869d6886b5f5d7fbfa5b4522237ea5c60d11bc4e7a1ff9390b;
/**
* @dev Modifier to check whether the `msg.sender` is the admin.
* If it is, it will run the function. Otherwise, it will delegate the call
* to the implementation.
*/
modifier ifAdmin() {
if (msg.sender == _admin()) {
_;
} else {
_fallback();
}
}
/**
* Contract constructor.
* It sets the `msg.sender` as the proxy administrator.
* @param _implementation address of the initial implementation.
*/
constructor(address _implementation) UpgradeabilityProxy(_implementation) public {
assert(ADMIN_SLOT == keccak256("org.zeppelinos.proxy.admin"));
_setAdmin(msg.sender);
}
/**
* @return The address of the proxy admin.
*/
function admin() external view ifAdmin returns (address) {
return _admin();
}
/**
* @return The address of the implementation.
*/
function implementation() external view ifAdmin returns (address) {
return _implementation();
}
/**
* @dev Changes the admin of the proxy.
* Only the current admin can call this function.
* @param newAdmin Address to transfer proxy administration to.
*/
function changeAdmin(address newAdmin) external ifAdmin {
require(newAdmin != address(0), "Cannot change the admin of a proxy to the zero address");
emit AdminChanged(_admin(), newAdmin);
_setAdmin(newAdmin);
}
/**
* @dev Upgrade the backing implementation of the proxy.
* Only the admin can call this function.
* @param newImplementation Address of the new implementation.
*/
function upgradeTo(address newImplementation) external ifAdmin {
_upgradeTo(newImplementation);
}
/**
* @dev Upgrade the backing implementation of the proxy and call a function
* on the new implementation.
* This is useful to initialize the proxied contract.
* @param newImplementation Address of the new implementation.
* @param data Data to send as msg.data in the low level call.
* It should include the signature and the parameters of the function to be
* called, as described in
* https://solidity.readthedocs.io/en/develop/abi-spec.html#function-selector-and-argument-encoding.
*/
function upgradeToAndCall(address newImplementation, bytes data) payable external ifAdmin {
_upgradeTo(newImplementation);
require(address(this).call.value(msg.value)(data));
}
/**
* @return The admin slot.
*/
function _admin() internal view returns (address adm) {
bytes32 slot = ADMIN_SLOT;
assembly {
adm := sload(slot)
}
}
/**
* @dev Sets the address of the proxy admin.
* @param newAdmin Address of the new proxy admin.
*/
function _setAdmin(address newAdmin) internal {
bytes32 slot = ADMIN_SLOT;
assembly {
sstore(slot, newAdmin)
}
}
/**
* @dev Only fall back when the sender is not the admin.
*/
function _willFallback() internal {
require(msg.sender != _admin(), "Cannot call fallback function from the proxy admin");
super._willFallback();
}
}
// File: contracts/FiatTokenProxy.sol
/**
* Copyright CENTRE SECZ 2018
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is furnished to
* do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in all
* copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
* WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
* CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
*/
pragma solidity ^0.4.24;
/**
* @title FiatTokenProxy
* @dev This contract proxies FiatToken calls and enables FiatToken upgrades
*/
contract FiatTokenProxy is AdminUpgradeabilityProxy {
constructor(address _implementation) public AdminUpgradeabilityProxy(_implementation) {
}
}
USDC源码解析
V1设计结构
逐模块分析
FiatTokenV1.sol (主要实现)
ownable.sol
pauseable.sol
AbstractFiatTokenV1.sol
Blacklistable.sol
/**
* SPDX-License-Identifier: MIT
*
* Copyright (c) 2018 zOS Global Limited.
* Copyright (c) 2018-2020 CENTRE SECZ
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
pragma solidity 0.6.12;
/**
* @notice The Ownable contract has an owner address, and provides basic
* authorization control functions
* @dev Forked from https://github.com/OpenZeppelin/openzeppelin-labs/blob/3887ab77b8adafba4a26ace002f3a684c1a3388b/upgradeability_ownership/contracts/ownership/Ownable.sol
* Modifications:
* 1. Consolidate OwnableStorage into this contract (7/13/18)
* 2. Reformat, conform to Solidity 0.6 syntax, and add error messages (5/13/20)
* 3. Make public functions external (5/27/20)
*/
contract Ownable {
// Owner of the contract
address private _owner;
/**
* @dev Event to show ownership has been transferred
* @param previousOwner representing the address of the previous owner
* @param newOwner representing the address of the new owner
*/
event OwnershipTransferred(address previousOwner, address newOwner);
/**
* @dev The constructor sets the original owner of the contract to the sender account.
*/
constructor() public {
setOwner(msg.sender);
}
/**
* @dev Tells the address of the owner
* @return the address of the owner
*/
function owner() external view returns (address) {
return _owner;
}
/**
* @dev Sets a new owner address
*/
function setOwner(address newOwner) internal {
_owner = newOwner;
}
/**
* @dev Throws if called by any account other than the owner.
*/
modifier onlyOwner() {
require(msg.sender == _owner, "Ownable: caller is not the owner");
_;
}
/**
* @dev Allows the current owner to transfer control of the contract to a newOwner.
* @param newOwner The address to transfer ownership to.
*/
function transferOwnership(address newOwner) external onlyOwner {
require(
newOwner != address(0),
"Ownable: new owner is the zero address"
);
emit OwnershipTransferred(_owner, newOwner);
setOwner(newOwner);
}
}
/**
* SPDX-License-Identifier: MIT
*
* Copyright (c) 2016 Smart Contract Solutions, Inc.
* Copyright (c) 2018-2020 CENTRE SECZ
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the "Software"), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* The above copyright notice and this permission notice shall be included in
* copies or substantial portions of the Software.
*
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
* SOFTWARE.
*/
pragma solidity 0.6.12;
import { Ownable } from "./Ownable.sol";
/**
* @notice Base contract which allows children to implement an emergency stop
* mechanism
* @dev Forked from https://github.com/OpenZeppelin/openzeppelin-contracts/blob/feb665136c0dae9912e08397c1a21c4af3651ef3/contracts/lifecycle/Pausable.sol
* Modifications:
* 1. Added pauser role, switched pause/unpause to be onlyPauser (6/14/2018)
* 2. Removed whenNotPause/whenPaused from pause/unpause (6/14/2018)
* 3. Removed whenPaused (6/14/2018)
* 4. Switches ownable library to use ZeppelinOS (7/12/18)
* 5. Remove constructor (7/13/18)
* 6. Reformat, conform to Solidity 0.6 syntax and add error messages (5/13/20)
* 7. Make public functions external (5/27/20)
*/
contract Pausable is Ownable {
event Pause();
event Unpause();
event PauserChanged(address indexed newAddress);
address public pauser;
bool public paused = false;
/**
* @dev Modifier to make a function callable only when the contract is not paused.
*/
modifier whenNotPaused() {
require(!paused, "Pausable: paused");
_;
}
/**
* @dev throws if called by any account other than the pauser
*/
modifier onlyPauser() {
require(msg.sender == pauser, "Pausable: caller is not the pauser");
_;
}
/**
* @dev called by the owner to pause, triggers stopped state
*/
function pause() external onlyPauser {
paused = true;
emit Pause();
}
/**
* @dev called by the owner to unpause, returns to normal state
*/
function unpause() external onlyPauser {
paused = false;
emit Unpause();
}
/**
* @notice Updates the pauser address.
* @param _newPauser The address of the new pauser.
*/
function updatePauser(address _newPauser) external onlyOwner {
require(
_newPauser != address(0),
"Pausable: new pauser is the zero address"
);
pauser = _newPauser;
emit PauserChanged(pauser);
}
}
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
abstract contract AbstractFiatTokenV1 is IERC20 {
function _approve(
address owner,
address spender,
uint256 value
) internal virtual;
function _transfer(
address from,
address to,
uint256 value
) internal virtual;
}
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { Ownable } from "./Ownable.sol";
/**
* @title Blacklistable Token
* @dev Allows accounts to be blacklisted by a "blacklister" role
*/
abstract contract Blacklistable is Ownable {
address public blacklister;
mapping(address => bool) internal _deprecatedBlacklisted;
event Blacklisted(address indexed _account);
event UnBlacklisted(address indexed _account);
event BlacklisterChanged(address indexed newBlacklister);
/**
* @dev Throws if called by any account other than the blacklister.
*/
modifier onlyBlacklister() {
require(
msg.sender == blacklister,
"Blacklistable: caller is not the blacklister"
);
_;
}
/**
* @dev Throws if argument account is blacklisted.
* @param _account The address to check.
*/
modifier notBlacklisted(address _account) {
require(
!_isBlacklisted(_account),
"Blacklistable: account is blacklisted"
);
_;
}
/**
* @notice Checks if account is blacklisted.
* @param _account The address to check.
* @return True if the account is blacklisted, false if the account is not blacklisted.
*/
function isBlacklisted(address _account) external view returns (bool) {
return _isBlacklisted(_account);
}
/**
* @notice Adds account to blacklist.
* @param _account The address to blacklist.
*/
function blacklist(address _account) external onlyBlacklister {
_blacklist(_account);
emit Blacklisted(_account);
}
/**
* @notice Removes account from blacklist.
* @param _account The address to remove from the blacklist.
*/
function unBlacklist(address _account) external onlyBlacklister {
_unBlacklist(_account);
emit UnBlacklisted(_account);
}
/**
* @notice Updates the blacklister address.
* @param _newBlacklister The address of the new blacklister.
*/
function updateBlacklister(address _newBlacklister) external onlyOwner {
require(
_newBlacklister != address(0),
"Blacklistable: new blacklister is the zero address"
);
blacklister = _newBlacklister;
emit BlacklisterChanged(blacklister);
}
/**
* @dev Checks if account is blacklisted.
* @param _account The address to check.
* @return true if the account is blacklisted, false otherwise.
*/
function _isBlacklisted(address _account)
internal
virtual
view
returns (bool);
/**
* @dev Helper method that blacklists an account.
* @param _account The address to blacklist.
*/
function _blacklist(address _account) internal virtual;
/**
* @dev Helper method that unblacklists an account.
* @param _account The address to unblacklist.
*/
function _unBlacklist(address _account) internal virtual;
}
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { SafeMath } from "@openzeppelin/contracts/math/SafeMath.sol";
import { AbstractFiatTokenV1 } from "./AbstractFiatTokenV1.sol";
import { Ownable } from "./Ownable.sol";
import { Pausable } from "./Pausable.sol";
import { Blacklistable } from "./Blacklistable.sol";
/**
* @title FiatToken
* @dev ERC20 Token backed by fiat reserves
*/
contract FiatTokenV1 is AbstractFiatTokenV1, Ownable, Pausable, Blacklistable {
using SafeMath for uint256;
string public name;
string public symbol;
uint8 public decimals;
string public currency;
address public masterMinter;
bool internal initialized;
/// @dev A mapping that stores the balance and blacklist states for a given address.
/// The first bit defines whether the address is blacklisted (1 if blacklisted, 0 otherwise).
/// The last 255 bits define the balance for the address.
mapping(address => uint256) internal balanceAndBlacklistStates;
mapping(address => mapping(address => uint256)) internal allowed;
uint256 internal totalSupply_ = 0;
mapping(address => bool) internal minters;
mapping(address => uint256) internal minterAllowed;
event Mint(address indexed minter, address indexed to, uint256 amount);
event Burn(address indexed burner, uint256 amount);
event MinterConfigured(address indexed minter, uint256 minterAllowedAmount);
event MinterRemoved(address indexed oldMinter);
event MasterMinterChanged(address indexed newMasterMinter);
/**
* @notice Initializes the fiat token contract.
* @param tokenName The name of the fiat token.
* @param tokenSymbol The symbol of the fiat token.
* @param tokenCurrency The fiat currency that the token represents.
* @param tokenDecimals The number of decimals that the token uses.
* @param newMasterMinter The masterMinter address for the fiat token.
* @param newPauser The pauser address for the fiat token.
* @param newBlacklister The blacklister address for the fiat token.
* @param newOwner The owner of the fiat token.
*/
function initialize(
string memory tokenName,
string memory tokenSymbol,
string memory tokenCurrency,
uint8 tokenDecimals,
address newMasterMinter,
address newPauser,
address newBlacklister,
address newOwner
) public {
require(!initialized, "FiatToken: contract is already initialized");
require(
newMasterMinter != address(0),
"FiatToken: new masterMinter is the zero address"
);
require(
newPauser != address(0),
"FiatToken: new pauser is the zero address"
);
require(
newBlacklister != address(0),
"FiatToken: new blacklister is the zero address"
);
require(
newOwner != address(0),
"FiatToken: new owner is the zero address"
);
name = tokenName;
symbol = tokenSymbol;
currency = tokenCurrency;
decimals = tokenDecimals;
masterMinter = newMasterMinter;
pauser = newPauser;
blacklister = newBlacklister;
setOwner(newOwner);
initialized = true;
}
/**
* @dev Throws if called by any account other than a minter.
*/
modifier onlyMinters() {
require(minters[msg.sender], "FiatToken: caller is not a minter");
_;
}
/**
* @notice Mints fiat tokens to an address.
* @param _to The address that will receive the minted tokens.
* @param _amount The amount of tokens to mint. Must be less than or equal
* to the minterAllowance of the caller.
* @return True if the operation was successful.
*/
function mint(address _to, uint256 _amount)
external
whenNotPaused
onlyMinters
notBlacklisted(msg.sender)
notBlacklisted(_to)
returns (bool)
{
require(_to != address(0), "FiatToken: mint to the zero address");
require(_amount > 0, "FiatToken: mint amount not greater than 0");
uint256 mintingAllowedAmount = minterAllowed[msg.sender];
require(
_amount <= mintingAllowedAmount,
"FiatToken: mint amount exceeds minterAllowance"
);
totalSupply_ = totalSupply_.add(_amount);
_setBalance(_to, _balanceOf(_to).add(_amount));
minterAllowed[msg.sender] = mintingAllowedAmount.sub(_amount);
emit Mint(msg.sender, _to, _amount);
emit Transfer(address(0), _to, _amount);
return true;
}
/**
* @dev Throws if called by any account other than the masterMinter
*/
modifier onlyMasterMinter() {
require(
msg.sender == masterMinter,
"FiatToken: caller is not the masterMinter"
);
_;
}
/**
* @notice Gets the minter allowance for an account.
* @param minter The address to check.
* @return The remaining minter allowance for the account.
*/
function minterAllowance(address minter) external view returns (uint256) {
return minterAllowed[minter];
}
/**
* @notice Checks if an account is a minter.
* @param account The address to check.
* @return True if the account is a minter, false if the account is not a minter.
*/
function isMinter(address account) external view returns (bool) {
return minters[account];
}
/**
* @notice Gets the remaining amount of fiat tokens a spender is allowed to transfer on
* behalf of the token owner.
* @param owner The token owner's address.
* @param spender The spender's address.
* @return The remaining allowance.
*/
function allowance(address owner, address spender)
external
override
view
returns (uint256)
{
return allowed[owner][spender];
}
/**
* @notice Gets the totalSupply of the fiat token.
* @return The totalSupply of the fiat token.
*/
function totalSupply() external override view returns (uint256) {
return totalSupply_;
}
/**
* @notice Gets the fiat token balance of an account.
* @param account The address to check.
* @return balance The fiat token balance of the account.
*/
function balanceOf(address account)
external
override
view
returns (uint256)
{
return _balanceOf(account);
}
/**
* @notice Sets a fiat token allowance for a spender to spend on behalf of the caller.
* @param spender The spender's address.
* @param value The allowance amount.
* @return True if the operation was successful.
*/
function approve(address spender, uint256 value)
external
virtual
override
whenNotPaused
notBlacklisted(msg.sender)
notBlacklisted(spender)
returns (bool)
{
_approve(msg.sender, spender, value);
return true;
}
/**
* @dev Internal function to set allowance.
* @param owner Token owner's address.
* @param spender Spender's address.
* @param value Allowance amount.
*/
function _approve(
address owner,
address spender,
uint256 value
) internal override {
require(owner != address(0), "ERC20: approve from the zero address");
require(spender != address(0), "ERC20: approve to the zero address");
allowed[owner][spender] = value;
emit Approval(owner, spender, value);
}
/**
* @notice Transfers tokens from an address to another by spending the caller's allowance.
* @dev The caller must have some fiat token allowance on the payer's tokens.
* @param from Payer's address.
* @param to Payee's address.
* @param value Transfer amount.
* @return True if the operation was successful.
*/
function transferFrom(
address from,
address to,
uint256 value
)
external
override
whenNotPaused
notBlacklisted(msg.sender)
notBlacklisted(from)
notBlacklisted(to)
returns (bool)
{
require(
value <= allowed[from][msg.sender],
"ERC20: transfer amount exceeds allowance"
);
_transfer(from, to, value);
allowed[from][msg.sender] = allowed[from][msg.sender].sub(value);
return true;
}
/**
* @notice Transfers tokens from the caller.
* @param to Payee's address.
* @param value Transfer amount.
* @return True if the operation was successful.
*/
function transfer(address to, uint256 value)
external
override
whenNotPaused
notBlacklisted(msg.sender)
notBlacklisted(to)
returns (bool)
{
_transfer(msg.sender, to, value);
return true;
}
/**
* @dev Internal function to process transfers.
* @param from Payer's address.
* @param to Payee's address.
* @param value Transfer amount.
*/
function _transfer(
address from,
address to,
uint256 value
) internal override {
require(from != address(0), "ERC20: transfer from the zero address");
require(to != address(0), "ERC20: transfer to the zero address");
require(
value <= _balanceOf(from),
"ERC20: transfer amount exceeds balance"
);
_setBalance(from, _balanceOf(from).sub(value));
_setBalance(to, _balanceOf(to).add(value));
emit Transfer(from, to, value);
}
/**
* @notice Adds or updates a new minter with a mint allowance.
* @param minter The address of the minter.
* @param minterAllowedAmount The minting amount allowed for the minter.
* @return True if the operation was successful.
*/
function configureMinter(address minter, uint256 minterAllowedAmount)
external
whenNotPaused
onlyMasterMinter
returns (bool)
{
minters[minter] = true;
minterAllowed[minter] = minterAllowedAmount;
emit MinterConfigured(minter, minterAllowedAmount);
return true;
}
/**
* @notice Removes a minter.
* @param minter The address of the minter to remove.
* @return True if the operation was successful.
*/
function removeMinter(address minter)
external
onlyMasterMinter
returns (bool)
{
minters[minter] = false;
minterAllowed[minter] = 0;
emit MinterRemoved(minter);
return true;
}
/**
* @notice Allows a minter to burn some of its own tokens.
* @dev The caller must be a minter, must not be blacklisted, and the amount to burn
* should be less than or equal to the account's balance.
* @param _amount the amount of tokens to be burned.
*/
function burn(uint256 _amount)
external
whenNotPaused
onlyMinters
notBlacklisted(msg.sender)
{
uint256 balance = _balanceOf(msg.sender);
require(_amount > 0, "FiatToken: burn amount not greater than 0");
require(balance >= _amount, "FiatToken: burn amount exceeds balance");
totalSupply_ = totalSupply_.sub(_amount);
_setBalance(msg.sender, balance.sub(_amount));
emit Burn(msg.sender, _amount);
emit Transfer(msg.sender, address(0), _amount);
}
/**
* @notice Updates the master minter address.
* @param _newMasterMinter The address of the new master minter.
*/
function updateMasterMinter(address _newMasterMinter) external onlyOwner {
require(
_newMasterMinter != address(0),
"FiatToken: new masterMinter is the zero address"
);
masterMinter = _newMasterMinter;
emit MasterMinterChanged(masterMinter);
}
/**
* @inheritdoc Blacklistable
*/
function _blacklist(address _account) internal override {
_setBlacklistState(_account, true);
}
/**
* @inheritdoc Blacklistable
*/
function _unBlacklist(address _account) internal override {
_setBlacklistState(_account, false);
}
/**
* @dev Helper method that sets the blacklist state of an account.
* @param _account The address of the account.
* @param _shouldBlacklist True if the account should be blacklisted, false if the account should be unblacklisted.
*/
function _setBlacklistState(address _account, bool _shouldBlacklist)
internal
virtual
{
_deprecatedBlacklisted[_account] = _shouldBlacklist;
}
/**
* @dev Helper method that sets the balance of an account.
* @param _account The address of the account.
* @param _balance The new fiat token balance of the account.
*/
function _setBalance(address _account, uint256 _balance) internal virtual {
balanceAndBlacklistStates[_account] = _balance;
}
/**
* @inheritdoc Blacklistable
*/
function _isBlacklisted(address _account)
internal
virtual
override
view
returns (bool)
{
return _deprecatedBlacklisted[_account];
}
/**
* @dev Helper method to obtain the balance of an account.
* @param _account The address of the account.
* @return The fiat token balance of the account.
*/
function _balanceOf(address _account)
internal
virtual
view
returns (uint256)
{
return balanceAndBlacklistStates[_account];
}
}
V1_1设计结构
逐模块分析
FiatTokenV1_1.sol
Rescuable.sol
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { FiatTokenV1 } from "../v1/FiatTokenV1.sol";
import { Rescuable } from "./Rescuable.sol";
/**
* @title FiatTokenV1_1
* @dev ERC20 Token backed by fiat reserves
*/
contract FiatTokenV1_1 is FiatTokenV1, Rescuable {
}
Rescuable
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { Ownable } from "../v1/Ownable.sol";
import { IERC20 } from "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import { SafeERC20 } from "@openzeppelin/contracts/token/ERC20/SafeERC20.sol";
contract Rescuable is Ownable {
using SafeERC20 for IERC20;
address private _rescuer;
event RescuerChanged(address indexed newRescuer);
/**
* @notice Returns current rescuer
* @return Rescuer's address
*/
function rescuer() external view returns (address) {
return _rescuer;
}
/**
* @notice Revert if called by any account other than the rescuer.
*/
modifier onlyRescuer() {
require(msg.sender == _rescuer, "Rescuable: caller is not the rescuer");
_;
}
/**
* @notice Rescue ERC20 tokens locked up in this contract.
* @param tokenContract ERC20 token contract address
* @param to Recipient address
* @param amount Amount to withdraw
*/
function rescueERC20(
IERC20 tokenContract,
address to,
uint256 amount
) external onlyRescuer {
tokenContract.safeTransfer(to, amount);
}
/**
* @notice Updates the rescuer address.
* @param newRescuer The address of the new rescuer.
*/
function updateRescuer(address newRescuer) external onlyOwner {
require(
newRescuer != address(0),
"Rescuable: new rescuer is the zero address"
);
_rescuer = newRescuer;
emit RescuerChanged(newRescuer);
}
}
SafeERC20.sol
// SPDX-License-Identifier: MIT
pragma solidity >=0.6.0 <0.8.0;
import "./IERC20.sol";
import "../../math/SafeMath.sol";
import "../../utils/Address.sol";
/**
* @title SafeERC20
* @dev Wrappers around ERC20 operations that throw on failure (when the token
* contract returns false). Tokens that return no value (and instead revert or
* throw on failure) are also supported, non-reverting calls are assumed to be
* successful.
* To use this library you can add a `using SafeERC20 for IERC20;` statement to your contract,
* which allows you to call the safe operations as `token.safeTransfer(...)`, etc.
*/
library SafeERC20 {
using SafeMath for uint256;
using Address for address;
function safeTransfer(IERC20 token, address to, uint256 value) internal {
_callOptionalReturn(token, abi.encodeWithSelector(token.transfer.selector, to, value));
}
function safeTransferFrom(IERC20 token, address from, address to, uint256 value) internal {
_callOptionalReturn(token, abi.encodeWithSelector(token.transferFrom.selector, from, to, value));
}
/**
* @dev Deprecated. This function has issues similar to the ones found in
* {IERC20-approve}, and its usage is discouraged.
*
* Whenever possible, use {safeIncreaseAllowance} and
* {safeDecreaseAllowance} instead.
*/
function safeApprove(IERC20 token, address spender, uint256 value) internal {
// safeApprove should only be called when setting an initial allowance,
// or when resetting it to zero. To increase and decrease it, use
// 'safeIncreaseAllowance' and 'safeDecreaseAllowance'
// solhint-disable-next-line max-line-length
require((value == 0) || (token.allowance(address(this), spender) == 0),
"SafeERC20: approve from non-zero to non-zero allowance"
);
_callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));
}
function safeIncreaseAllowance(IERC20 token, address spender, uint256 value) internal {
uint256 newAllowance = token.allowance(address(this), spender).add(value);
_callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));
}
function safeDecreaseAllowance(IERC20 token, address spender, uint256 value) internal {
uint256 newAllowance = token.allowance(address(this), spender).sub(value, "SafeERC20: decreased allowance below zero");
_callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, newAllowance));
}
/**
* @dev Imitates a Solidity high-level call (i.e. a regular function call to a contract), relaxing the requirement
* on the return value: the return value is optional (but if data is returned, it must not be false).
* @param token The token targeted by the call.
* @param data The call data (encoded using abi.encode or one of its variants).
*/
function _callOptionalReturn(IERC20 token, bytes memory data) private {
// We need to perform a low level call here, to bypass Solidity's return data size checking mechanism, since
// we're implementing it ourselves. We use {Address.functionCall} to perform this call, which verifies that
// the target address contains contract code and also asserts for success in the low-level call.
bytes memory returndata = address(token).functionCall(data, "SafeERC20: low-level call failed");
if (returndata.length > 0) { // Return data is optional
// solhint-disable-next-line max-line-length
require(abi.decode(returndata, (bool)), "SafeERC20: ERC20 operation did not succeed");
}
}
}
USDC_V2源码解析
V2设计结构
逐模块分析
AbstractFiatTokenV2.sol
EIP712Domain.sol
EIP2612.sol
EIP3009.sol
FiatTokenV2.sol (重要)
FiatTokenV2_1.sol （重要）
FiatTokenV2_2.sol (重要)
AbstractFiatTokenV2
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { AbstractFiatTokenV1 } from "../v1/AbstractFiatTokenV1.sol";
abstract contract AbstractFiatTokenV2 is AbstractFiatTokenV1 {
function _increaseAllowance(
address owner,
address spender,
uint256 increment
) internal virtual;
function _decreaseAllowance(
address owner,
address spender,
uint256 decrement
) internal virtual;
}
EIP712Domain
EIP712题案细节详见链接EIP712
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
// solhint-disable func-name-mixedcase
/**
* @title EIP712 Domain
*/
contract EIP712Domain {
// was originally DOMAIN_SEPARATOR
// but that has been moved to a method so we can override it in V2_2+
bytes32 internal _DEPRECATED_CACHED_DOMAIN_SEPARATOR;
/**
* @notice Get the EIP712 Domain Separator.
* @return The bytes32 EIP712 domain separator.
*/
function DOMAIN_SEPARATOR() external view returns (bytes32) {
return _domainSeparator();
}
/**
* @dev Internal method to get the EIP712 Domain Separator.
* @return The bytes32 EIP712 domain separator.
*/
function _domainSeparator() internal virtual view returns (bytes32) {
return _DEPRECATED_CACHED_DOMAIN_SEPARATOR;
}
}
EIP2612
EIP2612题案细节及功能详见链接EIP2612。此小结中为USDC重写的对应功能
这段代码实现了EIP-2612标准，是一个用于以太坊代币的"permit"功能的智能合约实现。 主要功能 EIP-2612实现了一种称为"gas抽象授权"(gas-abstracted approvals)的机制，它允许用户通过签名来授权第三方花费他们的代币，而不需要自己支付gas费用进行交互。
关键组件
- PERMIT_TYPEHASH：用于EIP-712结构化数据签名的类型哈希常量。
- _permitNonces映射：跟踪每个地址的nonce值，以防止重放攻击。
- nonces函数：公开查询特定地址的当前nonce。
- _permit函数：核心功能，有两个版本：
- 一个接受v, r, s分离的签名参数
- 一个接受整合的signature字节数组
工作流程
代币持有者(owner)离线签署一个包含以下信息的消息：
- 自己的地址(owner)
- 被授权者地址(spender)
- 授权金额(value)
- 当前nonce值
- 授权截止时间(deadline)
签名后，任何人可以将这个签名提交到合约。 合约验证：
- 检查截止时间是否有效
- 使用EIP-712构建相同的消息哈希
- 验证签名是否匹配owner地址
- 增加owner的nonce值
- 执行实际的approve操作
实际应用场景 这个功能解决了以太坊代币使用的一个主要摩擦点：用户需要进行两次交易才能通过第三方服务使用代币：
首先批准第三方花费代币 然后实际使用第三方服务
使用EIP-2612，用户只需签名一个许可消息（不需要支付gas），然后第三方可以在同一笔交易中验证许可并使用代币，大大改善了用户体验。
技术细节
基于Solidity 0.6.12 实现了EIP-712标准进行结构化数据签名 支持智能合约钱包签名验证（通过SignatureChecker） 可以设置永不过期的授权（通过设置deadline为最大uint256值）
这是一个关键的DeFi基础设施组件，特别适用于稳定币等高频使用的代币，可以显著降低用户与DeFi协议交互的成本和复杂性。
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { AbstractFiatTokenV2 } from "./AbstractFiatTokenV2.sol";
import { EIP712Domain } from "./EIP712Domain.sol";
import { MessageHashUtils } from "../util/MessageHashUtils.sol";
import { SignatureChecker } from "../util/SignatureChecker.sol";
/**
* @title EIP-2612
* @notice Provide internal implementation for gas-abstracted approvals
*/
abstract contract EIP2612 is AbstractFiatTokenV2, EIP712Domain {
// keccak256("Permit(address owner,address spender,uint256 value,uint256 nonce,uint256 deadline)")
bytes32
public constant PERMIT_TYPEHASH = 0x6e71edae12b1b97f4d1f60370fef10105fa2faae0126114a169c64845d6126c9;
mapping(address => uint256) private _permitNonces;
/**
* @notice Nonces for permit
* @param owner Token owner's address (Authorizer)
* @return Next nonce
*/
function nonces(address owner) external view returns (uint256) {
return _permitNonces[owner];
}
/**
* @notice Verify a signed approval permit and execute if valid
* @param owner Token owner's address (Authorizer)
* @param spender Spender's address
* @param value Amount of allowance
* @param deadline The time at which the signature expires (unix time), or max uint256 value to signal no expiration
* @param v v of the signature
* @param r r of the signature
* @param s s of the signature
*/
function _permit(
address owner,
address spender,
uint256 value,
uint256 deadline,
uint8 v,
bytes32 r,
bytes32 s
) internal {
_permit(owner, spender, value, deadline, abi.encodePacked(r, s, v));
}
/**
* @notice Verify a signed approval permit and execute if valid
* @dev EOA wallet signatures should be packed in the order of r, s, v.
* @param owner Token owner's address (Authorizer)
* @param spender Spender's address
* @param value Amount of allowance
* @param deadline The time at which the signature expires (unix time), or max uint256 value to signal no expiration
* @param signature Signature byte array signed by an EOA wallet or a contract wallet
*/
function _permit(
address owner,
address spender,
uint256 value,
uint256 deadline,
bytes memory signature
) internal {
require(
deadline == type(uint256).max || deadline >= now,
"FiatTokenV2: permit is expired"
);
bytes32 typedDataHash = MessageHashUtils.toTypedDataHash(
_domainSeparator(),
keccak256(
abi.encode(
PERMIT_TYPEHASH,
owner,
spender,
value,
_permitNonces[owner]++,
deadline
)
)
);
require(
SignatureChecker.isValidSignatureNow(
owner,
typedDataHash,
signature
),
"EIP2612: invalid signature"
);
_approve(owner, spender, value);
}
}
EIP3009
这段代码实现了EIP-3009标准，提供了一种气体抽象转账（gas-abstracted transfers）的内部实现。
主要功能
EIP-3009允许用户通过离线签名消息授权他人代表自己执行代币转账，而无需亲自支付气体费用。这种模式类似于EIP-2612的授权机制，但专注于直接转账操作。
核心组件
-
三种类型的交易：
transferWithAuthorization: 任何人都可以提交已签名的转账授权receiveWithAuthorization: 只有指定的接收者可以提交已签名的转账授权cancelAuthorization: 允许签名者取消之前未使用的授权
-
授权状态跟踪：
- 使用
_authorizationStates双重映射跟踪每个授权者的每个nonce的使用状态 - 每个授权使用随机生成的32字节nonce来确保唯一性
- 使用
-
事件通知：
AuthorizationUsed: 当授权被使用时发出AuthorizationCanceled: 当授权被取消时发出
工作流程
-
创建授权：
- 用户离线签署包含转账详情的消息（发送方、接收方、金额、有效期、nonce）
- 签名使用EIP-712标准格式化数据以提高可读性和安全性
-
提交授权：
- 对于
transferWithAuthorization：任何人都可以提交授权 - 对于
receiveWithAuthorization：只有指定的接收方可以提交（防止抢跑攻击）
- 对于
-
验证机制：
- 确保授权在有效时间范围内
- 验证nonce未被使用
- 验证签名的有效性
- 标记授权为已使用
- 执行实际转账
技术亮点
-
灵活的安全性：
- 支持时间窗口限制（validAfter/validBefore）
- 支持取消未使用的授权
- 支持智能合约钱包的签名（通过SignatureChecker）
-
改进的用户体验：
- 用户可以离线签署多个转账
- 接收方或第三方可代付气体费用
- 允许创建未来生效的授权
-
防止常见攻击：
- 使用nonce防止重放攻击
receiveWithAuthorization特别增加了调用者验证，防止抢跑
实际应用场景
- 代付费用交易：第三方可以为用户支付气体费用
- 批量处理：离线收集多个签名后一次性处理
- 延迟执行：设置未来时间窗口的授权
- 接收方发起：允许接收方通过
receiveWithAuthorization主动提取授权的资金
这种模式极大地提高了代币的使用灵活性，特别适用于稳定币和高频使用的代币，可以明显降低与DeFi协议交互的摩擦成本。它与EIP-2612（授权机制）相辅相成，共同构成现代代币标准的重要组成部分。
离线签署的基本原理
用户不需要直接与区块链交互，而是在自己的设备上创建并签署一条消息，这条消息包含了转账的所有必要信息。直接的理解就是写支票给别人去银行兑现，自己在这过程中无需与银行沟通。
签署过程详解
-
构建结构化数据：
- 根据交易类型（转账、接收或取消），构建一个遵循EIP-712标准的结构化数据
- 包含发送方地址、接收方地址、金额、有效时间、nonce等信息
-
创建消息哈希：
- 使用typeHash（如
TRANSFER_WITH_AUTHORIZATION_TYPEHASH） - 将所有参数编码：
abi.encode(TYPEHASH, from, to, value, validAfter, validBefore, nonce) - 对编码后的数据进行keccak256哈希
- 使用typeHash（如
-
应用EIP-712域分隔符：
- 将消息哈希与域分隔符(
_domainSeparator())结合 - 使用
MessageHashUtils.toTypedDataHash()方法生成最终待签名哈希
- 将消息哈希与域分隔符(
-
使用私钥签名：
- 用户使用自己的私钥对最终哈希进行签名
- 生成签名组件(v, r, s)或打包的签名字节数组
代码中的实现
在代码中，这个过程对应于：
// 创建消息哈希
bytes32 dataHash = keccak256(
abi.encode(
TRANSFER_WITH_AUTHORIZATION_TYPEHASH,
from,
to,
value,
validAfter,
validBefore,
nonce
)
);
// 应用域分隔符并验证签名
SignatureChecker.isValidSignatureNow(
signer,
MessageHashUtils.toTypedDataHash(_domainSeparator(), dataHash),
signature
)
实际工作流程
-
用户端：
- 用户使用钱包应用或库（如web3.js、ethers.js）
- 创建转账意图（包含接收方、金额等）
- 生成随机nonce和设定有效时间窗口
- 构建结构化数据并使用私钥签名
- 将签名和原始参数共享给执行者
-
执行者端：
- 接收签名和参数
- 调用合约的
transferWithAuthorization或receiveWithAuthorization - 提供签名和所有必要参数
- 支付交易的gas费用
安全性保障
- 确定性哈希：EIP-712确保不同应用为相同数据生成相同哈希
- 域分隔符：防止跨合约重放攻击
- nonce机制：防止同一授权被多次使用
- 时间窗口：授权只在特定时间段有效
- 取消机制：授权者可以取消未使用的授权
这种离线签署机制的最大优势是将签名创建（需要私钥）与交易提交（需要ETH支付gas）完全分离。
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { AbstractFiatTokenV2 } from "./AbstractFiatTokenV2.sol";
import { EIP712Domain } from "./EIP712Domain.sol";
import { SignatureChecker } from "../util/SignatureChecker.sol";
import { MessageHashUtils } from "../util/MessageHashUtils.sol";
/**
* @title EIP-3009
* @notice Provide internal implementation for gas-abstracted transfers
* @dev Contracts that inherit from this must wrap these with publicly
* accessible functions, optionally adding modifiers where necessary
*/
abstract contract EIP3009 is AbstractFiatTokenV2, EIP712Domain {
// keccak256("TransferWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)")
bytes32
public constant TRANSFER_WITH_AUTHORIZATION_TYPEHASH = 0x7c7c6cdb67a18743f49ec6fa9b35f50d52ed05cbed4cc592e13b44501c1a2267;
// keccak256("ReceiveWithAuthorization(address from,address to,uint256 value,uint256 validAfter,uint256 validBefore,bytes32 nonce)")
bytes32
public constant RECEIVE_WITH_AUTHORIZATION_TYPEHASH = 0xd099cc98ef71107a616c4f0f941f04c322d8e254fe26b3c6668db87aae413de8;
// keccak256("CancelAuthorization(address authorizer,bytes32 nonce)")
bytes32
public constant CANCEL_AUTHORIZATION_TYPEHASH = 0x158b0a9edf7a828aad02f63cd515c68ef2f50ba807396f6d12842833a1597429;
/**
* @dev authorizer address => nonce => bool (true if nonce is used)
*/
mapping(address => mapping(bytes32 => bool)) private _authorizationStates;
event AuthorizationUsed(address indexed authorizer, bytes32 indexed nonce);
event AuthorizationCanceled(
address indexed authorizer,
bytes32 indexed nonce
);
/**
* @notice Returns the state of an authorization
* @dev Nonces are randomly generated 32-byte data unique to the
* authorizer's address
* @param authorizer Authorizer's address
* @param nonce Nonce of the authorization
* @return True if the nonce is used
*/
function authorizationState(address authorizer, bytes32 nonce)
external
view
returns (bool)
{
return _authorizationStates[authorizer][nonce];
}
/**
* @notice Execute a transfer with a signed authorization
* @param from Payer's address (Authorizer)
* @param to Payee's address
* @param value Amount to be transferred
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
* @param nonce Unique nonce
* @param v v of the signature
* @param r r of the signature
* @param s s of the signature
*/
function _transferWithAuthorization(
address from,
address to,
uint256 value,
uint256 validAfter,
uint256 validBefore,
bytes32 nonce,
uint8 v,
bytes32 r,
bytes32 s
) internal {
_transferWithAuthorization(
from,
to,
value,
validAfter,
validBefore,
nonce,
abi.encodePacked(r, s, v)
);
}
/**
* @notice Execute a transfer with a signed authorization
* @dev EOA wallet signatures should be packed in the order of r, s, v.
* @param from Payer's address (Authorizer)
* @param to Payee's address
* @param value Amount to be transferred
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
* @param nonce Unique nonce
* @param signature Signature byte array produced by an EOA wallet or a contract wallet
*/
function _transferWithAuthorization(
address from,
address to,
uint256 value,
uint256 validAfter,
uint256 validBefore,
bytes32 nonce,
bytes memory signature
) internal {
_requireValidAuthorization(from, nonce, validAfter, validBefore);
_requireValidSignature(
from,
keccak256(
abi.encode(
TRANSFER_WITH_AUTHORIZATION_TYPEHASH,
from,
to,
value,
validAfter,
validBefore,
nonce
)
),
signature
);
_markAuthorizationAsUsed(from, nonce);
_transfer(from, to, value);
}
/**
* @notice Receive a transfer with a signed authorization from the payer
* @dev This has an additional check to ensure that the payee's address
* matches the caller of this function to prevent front-running attacks.
* @param from Payer's address (Authorizer)
* @param to Payee's address
* @param value Amount to be transferred
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
* @param nonce Unique nonce
* @param v v of the signature
* @param r r of the signature
* @param s s of the signature
*/
function _receiveWithAuthorization(
address from,
address to,
uint256 value,
uint256 validAfter,
uint256 validBefore,
bytes32 nonce,
uint8 v,
bytes32 r,
bytes32 s
) internal {
_receiveWithAuthorization(
from,
to,
value,
validAfter,
validBefore,
nonce,
abi.encodePacked(r, s, v)
);
}
/**
* @notice Receive a transfer with a signed authorization from the payer
* @dev This has an additional check to ensure that the payee's address
* matches the caller of this function to prevent front-running attacks.
* EOA wallet signatures should be packed in the order of r, s, v.
* @param from Payer's address (Authorizer)
* @param to Payee's address
* @param value Amount to be transferred
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
* @param nonce Unique nonce
* @param signature Signature byte array produced by an EOA wallet or a contract wallet
*/
function _receiveWithAuthorization(
address from,
address to,
uint256 value,
uint256 validAfter,
uint256 validBefore,
bytes32 nonce,
bytes memory signature
) internal {
require(to == msg.sender, "FiatTokenV2: caller must be the payee");
_requireValidAuthorization(from, nonce, validAfter, validBefore);
_requireValidSignature(
from,
keccak256(
abi.encode(
RECEIVE_WITH_AUTHORIZATION_TYPEHASH,
from,
to,
value,
validAfter,
validBefore,
nonce
)
),
signature
);
_markAuthorizationAsUsed(from, nonce);
_transfer(from, to, value);
}
/**
* @notice Attempt to cancel an authorization
* @param authorizer Authorizer's address
* @param nonce Nonce of the authorization
* @param v v of the signature
* @param r r of the signature
* @param s s of the signature
*/
function _cancelAuthorization(
address authorizer,
bytes32 nonce,
uint8 v,
bytes32 r,
bytes32 s
) internal {
_cancelAuthorization(authorizer, nonce, abi.encodePacked(r, s, v));
}
/**
* @notice Attempt to cancel an authorization
* @dev EOA wallet signatures should be packed in the order of r, s, v.
* @param authorizer Authorizer's address
* @param nonce Nonce of the authorization
* @param signature Signature byte array produced by an EOA wallet or a contract wallet
*/
function _cancelAuthorization(
address authorizer,
bytes32 nonce,
bytes memory signature
) internal {
_requireUnusedAuthorization(authorizer, nonce);
_requireValidSignature(
authorizer,
keccak256(
abi.encode(CANCEL_AUTHORIZATION_TYPEHASH, authorizer, nonce)
),
signature
);
_authorizationStates[authorizer][nonce] = true;
emit AuthorizationCanceled(authorizer, nonce);
}
/**
* @notice Validates that signature against input data struct
* @param signer Signer's address
* @param dataHash Hash of encoded data struct
* @param signature Signature byte array produced by an EOA wallet or a contract wallet
*/
function _requireValidSignature(
address signer,
bytes32 dataHash,
bytes memory signature
) private view {
require(
SignatureChecker.isValidSignatureNow(
signer,
MessageHashUtils.toTypedDataHash(_domainSeparator(), dataHash),
signature
),
"FiatTokenV2: invalid signature"
);
}
/**
* @notice Check that an authorization is unused
* @param authorizer Authorizer's address
* @param nonce Nonce of the authorization
*/
function _requireUnusedAuthorization(address authorizer, bytes32 nonce)
private
view
{
require(
!_authorizationStates[authorizer][nonce],
"FiatTokenV2: authorization is used or canceled"
);
}
/**
* @notice Check that authorization is valid
* @param authorizer Authorizer's address
* @param nonce Nonce of the authorization
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
*/
function _requireValidAuthorization(
address authorizer,
bytes32 nonce,
uint256 validAfter,
uint256 validBefore
) private view {
require(
now > validAfter,
"FiatTokenV2: authorization is not yet valid"
);
require(now < validBefore, "FiatTokenV2: authorization is expired");
_requireUnusedAuthorization(authorizer, nonce);
}
/**
* @notice Mark an authorization as used
* @param authorizer Authorizer's address
* @param nonce Nonce of the authorization
*/
function _markAuthorizationAsUsed(address authorizer, bytes32 nonce)
private
{
_authorizationStates[authorizer][nonce] = true;
emit AuthorizationUsed(authorizer, nonce);
}
}
FiatTokenV2
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { FiatTokenV1_1 } from "../v1.1/FiatTokenV1_1.sol";
import { EIP712 } from "../util/EIP712.sol";
import { EIP3009 } from "./EIP3009.sol";
import { EIP2612 } from "./EIP2612.sol";
/**
* @title FiatToken V2
* @notice ERC20 Token backed by fiat reserves, version 2
*/
contract FiatTokenV2 is FiatTokenV1_1, EIP3009, EIP2612 {
uint8 internal _initializedVersion;
/**
* @notice Initialize v2
* @param newName New token name
*/
function initializeV2(string calldata newName) external {
// solhint-disable-next-line reason-string
require(initialized && _initializedVersion == 0);
name = newName;
_DEPRECATED_CACHED_DOMAIN_SEPARATOR = EIP712.makeDomainSeparator(
newName,
"2"
);
_initializedVersion = 1;
}
/**
* @notice Increase the allowance by a given increment
* @param spender Spender's address
* @param increment Amount of increase in allowance
* @return True if successful
*/
function increaseAllowance(address spender, uint256 increment)
external
virtual
whenNotPaused
notBlacklisted(msg.sender)
notBlacklisted(spender)
returns (bool)
{
_increaseAllowance(msg.sender, spender, increment);
return true;
}
/**
* @notice Decrease the allowance by a given decrement
* @param spender Spender's address
* @param decrement Amount of decrease in allowance
* @return True if successful
*/
function decreaseAllowance(address spender, uint256 decrement)
external
virtual
whenNotPaused
notBlacklisted(msg.sender)
notBlacklisted(spender)
returns (bool)
{
_decreaseAllowance(msg.sender, spender, decrement);
return true;
}
/**
* @notice Execute a transfer with a signed authorization
* @param from Payer's address (Authorizer)
* @param to Payee's address
* @param value Amount to be transferred
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
* @param nonce Unique nonce
* @param v v of the signature
* @param r r of the signature
* @param s s of the signature
*/
function transferWithAuthorization(
address from,
address to,
uint256 value,
uint256 validAfter,
uint256 validBefore,
bytes32 nonce,
uint8 v,
bytes32 r,
bytes32 s
) external whenNotPaused notBlacklisted(from) notBlacklisted(to) {
_transferWithAuthorization(
from,
to,
value,
validAfter,
validBefore,
nonce,
v,
r,
s
);
}
/**
* @notice Receive a transfer with a signed authorization from the payer
* @dev This has an additional check to ensure that the payee's address
* matches the caller of this function to prevent front-running attacks.
* @param from Payer's address (Authorizer)
* @param to Payee's address
* @param value Amount to be transferred
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
* @param nonce Unique nonce
* @param v v of the signature
* @param r r of the signature
* @param s s of the signature
*/
function receiveWithAuthorization(
address from,
address to,
uint256 value,
uint256 validAfter,
uint256 validBefore,
bytes32 nonce,
uint8 v,
bytes32 r,
bytes32 s
) external whenNotPaused notBlacklisted(from) notBlacklisted(to) {
_receiveWithAuthorization(
from,
to,
value,
validAfter,
validBefore,
nonce,
v,
r,
s
);
}
/**
* @notice Attempt to cancel an authorization
* @dev Works only if the authorization is not yet used.
* @param authorizer Authorizer's address
* @param nonce Nonce of the authorization
* @param v v of the signature
* @param r r of the signature
* @param s s of the signature
*/
function cancelAuthorization(
address authorizer,
bytes32 nonce,
uint8 v,
bytes32 r,
bytes32 s
) external whenNotPaused {
_cancelAuthorization(authorizer, nonce, v, r, s);
}
/**
* @notice Update allowance with a signed permit
* @param owner Token owner's address (Authorizer)
* @param spender Spender's address
* @param value Amount of allowance
* @param deadline The time at which the signature expires (unix time), or max uint256 value to signal no expiration
* @param v v of the signature
* @param r r of the signature
* @param s s of the signature
*/
function permit(
address owner,
address spender,
uint256 value,
uint256 deadline,
uint8 v,
bytes32 r,
bytes32 s
)
external
virtual
whenNotPaused
notBlacklisted(owner)
notBlacklisted(spender)
{
_permit(owner, spender, value, deadline, v, r, s);
}
/**
* @dev Internal function to increase the allowance by a given increment
* @param owner Token owner's address
* @param spender Spender's address
* @param increment Amount of increase
*/
function _increaseAllowance(
address owner,
address spender,
uint256 increment
) internal override {
_approve(owner, spender, allowed[owner][spender].add(increment));
}
/**
* @dev Internal function to decrease the allowance by a given decrement
* @param owner Token owner's address
* @param spender Spender's address
* @param decrement Amount of decrease
*/
function _decreaseAllowance(
address owner,
address spender,
uint256 decrement
) internal override {
_approve(
owner,
spender,
allowed[owner][spender].sub(
decrement,
"ERC20: decreased allowance below zero"
)
);
}
}
FiatTokenV2_1
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { FiatTokenV2 } from "./FiatTokenV2.sol";
// solhint-disable func-name-mixedcase
/**
* @title FiatToken V2.1
* @notice ERC20 Token backed by fiat reserves, version 2.1
*/
contract FiatTokenV2_1 is FiatTokenV2 {
/**
* @notice Initialize v2.1
* @param lostAndFound The address to which the locked funds are sent
*/
function initializeV2_1(address lostAndFound) external {
// solhint-disable-next-line reason-string
require(_initializedVersion == 1);
uint256 lockedAmount = _balanceOf(address(this));
if (lockedAmount > 0) {
_transfer(address(this), lostAndFound, lockedAmount);
}
_blacklist(address(this));
_initializedVersion = 2;
}
/**
* @notice Version string for the EIP712 domain separator
* @return Version string
*/
function version() external pure returns (string memory) {
return "2";
}
}
FiatTokenV2_2
/**
* SPDX-License-Identifier: Apache-2.0
*
* Copyright (c) 2023, Circle Internet Financial, LLC.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
pragma solidity 0.6.12;
import { EIP712Domain } from "./EIP712Domain.sol"; // solhint-disable-line no-unused-import
import { Blacklistable } from "../v1/Blacklistable.sol"; // solhint-disable-line no-unused-import
import { FiatTokenV1 } from "../v1/FiatTokenV1.sol"; // solhint-disable-line no-unused-import
import { FiatTokenV2 } from "./FiatTokenV2.sol"; // solhint-disable-line no-unused-import
import { FiatTokenV2_1 } from "./FiatTokenV2_1.sol";
import { EIP712 } from "../util/EIP712.sol";
// solhint-disable func-name-mixedcase
/**
* @title FiatToken V2.2
* @notice ERC20 Token backed by fiat reserves, version 2.2
*/
contract FiatTokenV2_2 is FiatTokenV2_1 {
/**
* @notice Initialize v2.2
* @param accountsToBlacklist A list of accounts to migrate from the old blacklist
* @param newSymbol New token symbol
* data structure to the new blacklist data structure.
*/
function initializeV2_2(
address[] calldata accountsToBlacklist,
string calldata newSymbol
) external {
// solhint-disable-next-line reason-string
require(_initializedVersion == 2);
// Update fiat token symbol
symbol = newSymbol;
// Add previously blacklisted accounts to the new blacklist data structure
// and remove them from the old blacklist data structure.
for (uint256 i = 0; i < accountsToBlacklist.length; i++) {
require(
_deprecatedBlacklisted[accountsToBlacklist[i]],
"FiatTokenV2_2: Blacklisting previously unblacklisted account!"
);
_blacklist(accountsToBlacklist[i]);
delete _deprecatedBlacklisted[accountsToBlacklist[i]];
}
_blacklist(address(this));
delete _deprecatedBlacklisted[address(this)];
_initializedVersion = 3;
}
/**
* @dev Internal function to get the current chain id.
* @return The current chain id.
*/
function _chainId() internal virtual view returns (uint256) {
uint256 chainId;
assembly {
chainId := chainid()
}
return chainId;
}
/**
* @inheritdoc EIP712Domain
*/
function _domainSeparator() internal override view returns (bytes32) {
return EIP712.makeDomainSeparator(name, "2", _chainId());
}
/**
* @notice Update allowance with a signed permit
* @dev EOA wallet signatures should be packed in the order of r, s, v.
* @param owner Token owner's address (Authorizer)
* @param spender Spender's address
* @param value Amount of allowance
* @param deadline The time at which the signature expires (unix time), or max uint256 value to signal no expiration
* @param signature Signature bytes signed by an EOA wallet or a contract wallet
*/
function permit(
address owner,
address spender,
uint256 value,
uint256 deadline,
bytes memory signature
) external whenNotPaused {
_permit(owner, spender, value, deadline, signature);
}
/**
* @notice Execute a transfer with a signed authorization
* @dev EOA wallet signatures should be packed in the order of r, s, v.
* @param from Payer's address (Authorizer)
* @param to Payee's address
* @param value Amount to be transferred
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
* @param nonce Unique nonce
* @param signature Signature bytes signed by an EOA wallet or a contract wallet
*/
function transferWithAuthorization(
address from,
address to,
uint256 value,
uint256 validAfter,
uint256 validBefore,
bytes32 nonce,
bytes memory signature
) external whenNotPaused notBlacklisted(from) notBlacklisted(to) {
_transferWithAuthorization(
from,
to,
value,
validAfter,
validBefore,
nonce,
signature
);
}
/**
* @notice Receive a transfer with a signed authorization from the payer
* @dev This has an additional check to ensure that the payee's address
* matches the caller of this function to prevent front-running attacks.
* EOA wallet signatures should be packed in the order of r, s, v.
* @param from Payer's address (Authorizer)
* @param to Payee's address
* @param value Amount to be transferred
* @param validAfter The time after which this is valid (unix time)
* @param validBefore The time before which this is valid (unix time)
* @param nonce Unique nonce
* @param signature Signature bytes signed by an EOA wallet or a contract wallet
*/
function receiveWithAuthorization(
address from,
address to,
uint256 value,
uint256 validAfter,
uint256 validBefore,
bytes32 nonce,
bytes memory signature
) external whenNotPaused notBlacklisted(from) notBlacklisted(to) {
_receiveWithAuthorization(
from,
to,
value,
validAfter,
validBefore,
nonce,
signature
);
}
/**
* @notice Attempt to cancel an authorization
* @dev Works only if the authorization is not yet used.
* EOA wallet signatures should be packed in the order of r, s, v.
* @param authorizer Authorizer's address
* @param nonce Nonce of the authorization
* @param signature Signature bytes signed by an EOA wallet or a contract wallet
*/
function cancelAuthorization(
address authorizer,
bytes32 nonce,
bytes memory signature
) external whenNotPaused {
_cancelAuthorization(authorizer, nonce, signature);
}
/**
* @dev Helper method that sets the blacklist state of an account on balanceAndBlacklistStates.
* If _shouldBlacklist is true, we apply a (1 << 255) bitmask with an OR operation on the
* account's balanceAndBlacklistState. This flips the high bit for the account to 1,
* indicating that the account is blacklisted.
*
* If _shouldBlacklist if false, we reset the account's balanceAndBlacklistStates to their
* balances. This clears the high bit for the account, indicating that the account is unblacklisted.
* @param _account The address of the account.
* @param _shouldBlacklist True if the account should be blacklisted, false if the account should be unblacklisted.
*/
function _setBlacklistState(address _account, bool _shouldBlacklist)
internal
override
{
balanceAndBlacklistStates[_account] = _shouldBlacklist
? balanceAndBlacklistStates[_account] | (1 << 255)
: _balanceOf(_account);
}
/**
* @dev Helper method that sets the balance of an account on balanceAndBlacklistStates.
* Since balances are stored in the last 255 bits of the balanceAndBlacklistStates value,
* we need to ensure that the updated balance does not exceed (2^255 - 1).
* Since blacklisted accounts' balances cannot be updated, the method will also
* revert if the account is blacklisted
* @param _account The address of the account.
* @param _balance The new fiat token balance of the account (max: (2^255 - 1)).
*/
function _setBalance(address _account, uint256 _balance) internal override {
require(
_balance <= ((1 << 255) - 1),
"FiatTokenV2_2: Balance exceeds (2^255 - 1)"
);
require(
!_isBlacklisted(_account),
"FiatTokenV2_2: Account is blacklisted"
);
balanceAndBlacklistStates[_account] = _balance;
}
/**
* @inheritdoc Blacklistable
*/
function _isBlacklisted(address _account)
internal
override
view
returns (bool)
{
return balanceAndBlacklistStates[_account] >> 255 == 1;
}
/**
* @dev Helper method to obtain the balance of an account. Since balances
* are stored in the last 255 bits of the balanceAndBlacklistStates value,
* we apply a ((1 << 255) - 1) bit bitmask with an AND operation on the
* balanceAndBlacklistState to obtain the balance.
* @param _account The address of the account.
* @return The fiat token balance of the account.
*/
function _balanceOf(address _account)
internal
override
view
returns (uint256)
{
return balanceAndBlacklistStates[_account] & ((1 << 255) - 1);
}
/**
* @inheritdoc FiatTokenV1
*/
function approve(address spender, uint256 value)
external
override
whenNotPaused
returns (bool)
{
_approve(msg.sender, spender, value);
return true;
}
/**
* @inheritdoc FiatTokenV2
*/
function permit(
address owner,
address spender,
uint256 value,
uint256 deadline,
uint8 v,
bytes32 r,
bytes32 s
) external override whenNotPaused {
_permit(owner, spender, value, deadline, v, r, s);
}
/**
* @inheritdoc FiatTokenV2
*/
function increaseAllowance(address spender, uint256 increment)
external
override
whenNotPaused
returns (bool)
{
_increaseAllowance(msg.sender, spender, increment);
return true;
}
/**
* @inheritdoc FiatTokenV2
*/
function decreaseAllowance(address spender, uint256 decrement)
external
override
whenNotPaused
returns (bool)
{
_decreaseAllowance(msg.sender, spender, decrement);
return true;
}
}
ignition再次部署合约报错
重新部署合约时，由于ignition有记录部署过本合约而拒绝重新部署
[ Transaction ] reconciliation failed ⛔
The module contains changes to executed futures:
Transaction#GLDToken:
- From account has been changed from 0x0988258112531ef09ebfbdb5a0b5a537bc4b860c to 0x373d36662619ed994e9778c5be4f7044f005ff9b
Consider modifying your module to remove the inconsistencies with deployed futures.
解决方法：
npx hardhat ignition wipe deploymentId futureId
Hardhat官方说明文档
Handling errors | Ethereum development environment for professionals by Nomic Foundation
部署环境说明：
Ganache，非公链
补充说明
deploymentId --目前等同于chainid，命名方式为chain-xxx
futureId --对应每个需要部署的合约
deploymentId
npx hardhat ignition deployments
效果如下
futureId
官方文档
npx hardhat ignition status deploymentId
项目中实际命令
npx hardhat ignition status chain-1337
效果如下
wipe命令擦除原本部署的合约记录
官方文档
npx hardhat ignition wipe deploymentId futureId
实际命令
npx hardhat ignition wipe chain-1337 Transaction#GLDToken
效果如下
重新部署测试
npx hardhat ignition deploy ignition/modules/GLD.js --network ganache
效果如下
//注意部署脚本的位置替换为自己脚本的路径
Foundry
一个基础教程引导页面
入门指南书
账户模型
#![allow(unused)] fn main() { pub struct Account{ pub lamports:u64, pub data:Vec<u8>, pub owner:Pubkey, pub excutable:bool, pub rent_epoch:Epoch, } }
结构分析：
| 字段 | 类型 | 作用 |
|---|---|---|
| lamports | u64 | 表示账户的 SOL 余额，以 Lamports 为单位。1 SOL = 1,000,000,000 Lamports(10^9)。用于支付交易费用和账户租金。 |
| data | Vec |
存储账户的实际数据内容。对于普通账户，可以存储任意应用数据；对于程序账户，存储智能合约的二进制代码。 |
| owner | Pubkey | 表示账户的所有者，即拥有和控制该账户的公钥。决定谁可以修改账户数据或转移余额。 |
| executable | bool | 标识该账户是否为可执行账户。当为 `true` 时，表示账户存储的是可执行的智能合约；否则，为普通账户。 |
| rent_epoch | Epoch | 表示账户的租金周期，用于管理账户的存储租金。帮助系统确定是否需要收取新的租金或清除未支付租金的账户。 |
关键字说明
• lamports (u64)：
• 类型：无符号 64 位整数 (u64)。
• 作用：账户的 SOL 余额，以 Lamports 为单位。用于支付交易费用和账户租金，确保账户持有足够的余额以维持其在区块链上的存在。
• data (Vec<u8>)：
• 类型：动态字节向量 (Vec<u8>)。
• 作用：存储账户的实际数据。对于普通账户，可以存储任意应用数据，如代币余额、NFT 元数据等；对于程序账户，存储智能合约的二进制代码，决定账户的行为和功能。
• owner (Pubkey)：
• 类型：公钥 (Pubkey) --solana自定义类型，非rust原生。
• 作用：标识账户的所有者。只有所有者（或被授权的程序）才能修改账户数据或转移账户余额。公钥用于验证交易的签名，确保账户的安全性和控制权。
• executable (bool)：
• 类型：布尔值 (bool)。
• 作用：标识账户是否为可执行账户。当设置为 true 时，表示该账户存储的是可执行的智能合约；否则，为普通账户，用于存储数据和资产。
• rent_epoch (Epoch)：
• 类型：Epoch 类型，表示区块链的一个时间周期--solana自定义类型，非rust原生。
• 作用：用于管理账户的存储租金。系统根据账户的 rent_epoch 来确定是否需要收取新的租金，或者是否因未支付租金而清除账户数据，以优化存储资源的使用。
rent_epoch ：这是从 Solana 有定期从账户扣除 lamports 的机制时遗留下来的一个旧字段。虽然这个字段在 Account 类型中仍然存在，但由于租金收集已被弃用，它不再被使用。
示例
假设你有一个 Solana 账户，其 Account 结构体实例可能如下所示：
#![allow(unused)] fn main() { let account = Account { lamports: 1_000_000_000, // 1 SOL data: vec![0, 1, 2, 3], // 存储的数据 owner: "G1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF".parse().unwrap(), // 所有者公钥 executable: false, // 普通账户 rent_epoch: 123, // 当前租金周期 }; }
原生程序(Native Programs)
以下大部分为对solana官方文档的翻译，如有谬误请联系指正！
系统程序：
1.创建链上所有的新账户
2.为账户分配数据空间
3.转移账户所有权到自定义程序中
BPF加载器
全称Berkeley Packet Filter Loader（伯克利包过滤器加载器），但在Solana中演变为自定义程序的托管者 1.所有已部署的自定义程序的所有者
2.处理程序部署和升级
-
系统程序(System Program)
所有在 Solana 上的“钱包”账户都只是由系统程序拥有的账户。这些账户中存储的 lamport 余额代表钱包拥有的 SOL 数量。只有由系统程序拥有的账户才能用作交易费用支付者。
-
BPF Loader
BPF 加载器是网络上所有自定义程序的所有者，不包括其他原生程序。它负责部署、升级和执行自定义程序。
系统变量账户(Sysvar Accounts)
Sysvar 账户是位于预定义地址的特殊账户，提供对集群状态数据的访问。这些账户会动态更新关于网络集群的数据。您可以在此处找到 Sysvar 账户的完整列表。
自定义程序(Custom Programs)
在 Solana 上，“智能合约”被称为程序。程序是包含可执行代码的账户。您可以通过“可执行”标志设置为 true 来识别程序账户。 程序被部署到网络中，可以被用户和其他程序调用以执行它们的指令。
程序账户(Program Account)
当新的程序目前在 Solana 上部署时，技术上会创建三个独立的账户：
- 程序账户：代表链上程序的账户。此账户存储可执行数据账户的地址（存储编译后的程序代码）以及程序的更新权限（有权对程序进行更改的地址）。
- 程序可执行数据账户：包含程序可执行代码的账户。
- 缓冲账户：在程序部署或升级期间创建的临时账户，用于存储程序的执行代码。成功部署后，代码将被移动到程序执行数据账户，缓冲账户将被关闭。
例如，以下是 Token Extensions Program Account 及其对应的 Program Executable Data Account 在 Solana Explorer 中的链接。
为了简单起见，你可以将程序账户视为程序本身。当调用程序的指令时，你指定程序账户的地址（通常称为“程序 ID”）。关于两个独立账户的详细信息主要是为了理解程序是如何部署和升级的。
数据账户(Data Account)
Solana 上的程序是“无状态的”，这意味着程序账户仅存储可执行代码，不存储用于读取的数据。
为了维护状态，程序定义指令以创建由程序拥有的单独账户。每个账户都有自己的唯一地址，可以存储程序定义的任何任意数据。
注意，只有系统程序可以创建新的账户。一旦系统程序创建了账户，它就可以将新账户的所有权转让给另一个程序。
换句话说，为自定义程序创建数据账户需要两个步骤：
1.调用系统程序创建账户，然后将其所有权转让给自定义程序
2.调用现在拥有账户的自定义程序，然后初始化程序指令定义的账户数据
这个账户创建过程通常被抽象为单一步骤。
交易和指令 (Transactions and Instructions)
Rust
引用（摘自Rust权威指南）译者序
作为系统级语言事实上的标杆，C/C++语言诞生至今已经四十余年了。四十年历史的积累从某种角度上讲亦是四十年的负担。为了开发出运行正确的软件，我们需要投入数年的时间来学会如何避免臭名昭著的漏洞，但即便是最为谨慎的开发者，也无法保证自己的程序万无一失。这些漏洞不仅会导致计算机崩溃，还会带来许多意想不到的安全性问题。特别是随着互联网技术的飞速发展，所有人的私密信息都有可能因为这类安全性问题而赤裸裸地暴露在陌生人的面前。 有些语言，比如C#等，试图使用庞大的运行时系统来解决这一问题，其中最常见的解决方案便是垃圾回收（Garbage Collection）机制。这种机制在保证了内存安全的同时，却在某种程度上剥夺了程序员对底层的控制能力，并往往伴随着性能上的额外损耗。 正是在这样的背景之下，Rust应运而生。 Rust站在了前人的肩膀上，借助于最近几十年的语言研究成果，创造出了所有权与生命周期等崭新的概念。相对于C/C++等传统语言，它具有天生的安全性；换句话说，你无法在安全的Rust代码中执行任何非法的内存操作。相对于C#等带有垃圾回收机制的语言来讲，它遵循了零开销抽象（Zero-Cost Abstraction）规则，并为开发者保留了最大的底层控制能力。 Rust从设计伊始便致力于提供高水准的人体工程学体验。你可以在Rust中看到代数数据类型、卫生宏、迭代器等饱经证明的优秀语言设计，这些刻意的设计能够帮助你自然而然地编写出高效且安全的代码。在语言本身之外，Rust核心开发团队还规划并实现了一系列顶尖的工具链——从集成的包管理器到带有依赖管理的构建工具，再到跨越编辑器的自动补全、类型推导及自动格式化等服务工具。 Rust由开源基金会Mozilla推动开发，它的背后有一个完善且热情的社区。年轻的Rust正在众人合力之下不断进步，许许多多像你我一样的开发者共同决定着Rust的前进方向。你能够在Rust的托管网站GitHub上追踪到最新的源代码及开发进展，甚至是参与到Rust本身的开发之中。
官方资源
官网：rust-lang.org 第三方库：crates.io std-doc :std-doc
推荐学习资源(个人喜好)
在线: course.rs 电子书：Rust权威指南 练习： rustlings
知名项目
rust中基本语句，给声明的变量绑定某个值
个人理解 ： rust中变量设定是内存安全的基石之一 1.对于指针概念的隐藏，通过变量声明控制 2.对于指针访问操作的限制：通过变量可修改性的限制
- 变量重绑定：指已经声明过的变量(指针),重新指向另一片内存空间。此内存空间存储的可以是另一种类型的变量。理解部分:变量可不可变，指的是值，不是指针本身
- 赋值与绑定的区别：赋值为修改已经声明的变量的值
- 关键字
let用于声明变量绑定
不可变变量
- 不可变变量：指值在操作过程中不可修改，可理解为C、C++语言中 此变量声明后作为一个指针，指针指向的内存地址数据为只读
fn main(){ let var1 = 1; //声明并绑定不可变变量 println!("{}",var1); let var1 = 2;//不可变变量重绑定 println!("{}",var1); //var1 = 3; //此代码将报错，将变量赋值给不可变变量 }
错误示例
fn main(){ let var1 = 1; //声明并绑定不可变变量 println!("{}",var1); var1 = 3; //此代码将报错，将变量赋值给不可变变量 }
可变变量
- 可变变量：指值在操作过程中可以修改，可以理解为指针指向的数据可以修改！由于rust变量类型限制，仅能赋值同类型变量。
- 关键字
mut用于声明变量可变，不可变则无此声明
fn main(){ let mut var2 = 1;//声明并绑定可变变量 println!("{}",var2); var2 = 2; //此代码正确，可变变量可赋值 println!("{}",var2); }
rust库中默认内置的变量
一、标量类型（Scalar Types）
1. 整数类型（Integer）
Rust 的整数类型根据符号和位宽分类，命名格式为 [u|i][位数]：
| 类型 | 位数 | 范围 | 示例值 | 典型场景 |
|---|---|---|---|---|
i8 | 8 | -128 ~ 127 | -5i8 | 小范围有符号整数 |
u8 | 8 | 0 ~ 255 | 255u8 | 字节处理、颜色值 |
i16 | 16 | -32,768 ~ 32,767 | 30000i16 | 中等范围有符号整数 |
u16 | 16 | 0 ~ 65,535 | 65535u16 | Unicode 字符码点（如 '\u{2764}'） |
i32 | 32 | -2,147,483,648 ~ 2,147,483,647 | 42（默认推断） | 通用整数，性能最佳 |
u32 | 32 | 0 ~ 4,294,967,295 | 1_000_000u32 | 大范围无符号计数 |
i64 | 64 | -9,223,372,036,854,775,808 ~ 9,223,372,036,854,775,807 | -9_223_372_036i64 | 时间戳、大数值计算 |
u64 | 64 | 0 ~ 18,446,744,073,709,551,615 | 18_446_744u64 | ID 生成、超大计数 |
isize | 平台相关（通常 32/64 位） | 与指针大小相同 | -10isize | 集合索引、内存偏移量 |
usize | 平台相关（通常 32/64 位） | 与指针大小相同 | 0usize | 集合长度、内存地址 |
关键特性：
- 默认类型：未标注时，整数字面量默认推断为
i32。 - 进制表示：
#![allow(unused)] fn main() { let decimal = 98_222; // 十进制：98222 let hex = 0xff; // 十六进制：255 let octal = 0o77; // 八进制：63 let binary = 0b1111_0000; // 二进制：240 let byte = b'A'; // u8 类型字节：65 } - 溢出处理：Debug 模式下溢出会 panic，Release 模式下自动按补码循环（需显式处理用
Wrapping类型）。
2. 浮点类型（Floating-Point）
Rust 提供两种精度浮点数，遵循 IEEE-754 标准：
关于浮点类型是一种以表达式形式存储在内存中的变量
图片来源 ：csapp + 个人学习记录
| 类型 | 位数 | 精度 | 范围 | 示例值 | 场景 |
|---|---|---|---|---|---|
f32 | 32 | 6-7 位小数 | ±3.4×10³⁸ ~ ±1.7×10³⁸ | 3.14f32 | 图形计算、嵌入式 |
f64 | 64 | 15-17 位小数 | ±1.7×10³⁰⁸ ~ ±1.1×10³⁰⁸ | 2.718（默认） | 科学计算、通用 |
重要特性：
- 默认类型：未标注时，浮点字面量默认推断为
f64（因现代 CPU 高效支持）。 - 数值运算：
#![allow(unused)] fn main() { let sum = 5.0 + 10.0; // f64 let difference = 95.5 - 4.3; let product = 4.0 * 30.0; let quotient = 56.7 / 32.2; let remainder = 43.0 % 5.0; } - 陷阱：浮点数存在精度误差，避免直接判等：
#![allow(unused)] fn main() { // ❌ 错误写法 assert!(0.1 + 0.2 == 0.3); // ✅ 正确做法 let tolerance = 1e-10; assert!((0.1 + 0.2 - 0.3).abs() < tolerance); }
3. 布尔类型（Boolean）
- 类型名：
bool - 值域：
true或false - 内存占用：1 字节
- 使用场景：条件判断、逻辑运算
#![allow(unused)] fn main() { let is_rust_cool = true; let is_heavy: bool = 10 > 5; // 自动推断为 true }
4. 字符类型（Character）
- 类型名：
char - 内存占用：4 字节（存储 Unicode 标量值）
- 值域：U+0000 ~ U+D7FF 和 U+E000 ~ U+10FFFF
- 表示方式：单引号，支持 Unicode 转义：
#![allow(unused)] fn main() { let c = 'z'; let emoji = '🚀'; // 直接输入 Unicode let heart = '\u{2764}'; // Unicode 转义：❤ }
二、复合类型（Compound Types）
1. 元组（Tuple）
- 定义：固定长度、可包含不同类型的集合。
- 内存布局：元素紧密排列，无额外开销。
- 示例：
#![allow(unused)] fn main() { let tup: (i32, f64, bool) = (500, 6.4, true); // 显式类型标注 let (x, y, z) = tup; // 解构赋值 let first = tup.0; // 索引访问 } - 空元组：
()表示“无返回值”，是函数的默认返回类型。
2. 数组（Array）
- 定义：固定长度、相同类型的集合，栈上分配。
- 适用场景：已知元素数量的数据集（如月份名称）。
- 示例：
#![allow(unused)] fn main() { let months = ["Jan", "Feb", "Mar"]; // 类型推断为 [&str; 3] let arr: [i32; 5] = [1, 2, 3, 4, 5]; // 显式标注 let zeros = [0; 10]; // 初始化 10 个 0：[0, 0, ..., 0] let first = arr[0]; // 索引访问（编译时检查越界） } - 越界访问：运行时 panic（如
arr[5]）。
三、类型转换与处理
1. 显式类型转换（as）
#![allow(unused)] fn main() { let x = 1000i32; let y = x as u64; // 安全转换 let z = x as u8; // 可能丢失数据（1000 → 232） }
2. 处理不同类型运算
需手动统一类型：
#![allow(unused)] fn main() { let a = 10i32; let b = 100u32; let sum = a as i64 + b as i64; // 统一为 i64 避免溢出 }
3. 类型推断与标注
#![allow(unused)] fn main() { let x = 42; // 默认推断为 i32 let y: u8 = 10; // 显式标注为 u8 let z = x + y; // ❌ 错误：类型不匹配 let z = x + y as i32; // ✅ 正确 }
四、最佳实践与常见问题
1. 如何选择整数类型？
- 通用场景：优先使用
i32（性能最优）。 - 内存敏感：
u8、i16（如网络协议）。 - 大集合索引：
usize（与平台指针同宽）。
2. 为什么浮点数比较需要特殊处理？
- 浮点运算存在精度损失，直接判等可能失败。
- 使用误差范围（epsilon）或专用库（如
approx）。
3. 何时使用数组 vs 向量（Vec<T>）？
- 数组：长度固定、栈分配（高效）。
- 向量：动态长度、堆分配（灵活）。
五、代码示例
fn main() { // 整数操作 let decimal = 98_222; // i32 let hex = 0xff; // i32 let byte = b'A'; // u8 let max_u32 = u32::MAX; // 4,294,967,295 // 浮点运算 let x = 2.0; // f64 let y: f32 = 3.0; // f32 let result = x + (y as f64); // 统一类型 // 布尔逻辑 let is_greater = 10 > 5; // true // 字符与Unicode let emoji = '🚀'; let heart = '\u{2764}'; // 元组和数组 let tup = (500, 6.4, true); let arr = [1, 2, 3, 4, 5]; let first_element = arr[0]; }
通过泛型和特征实现不同结构体实现相同效果
use std::fmt::format; #[derive(Debug)] pub struct Teacher { age: i32, name: String, skill: String, } pub struct Student { age: i32, name: String, class: u32, } pub trait TellInfo { fn Sayage(&self); fn SelfIntroduction(&self) -> String; } impl TellInfo for Teacher { fn Sayage(&self) { println!("Teacher {}'s age is {}", self.name, self.age); } fn SelfIntroduction(&self) -> String { let brief_intro = format!( "As a teacher,my name is {},i'm {} years old and my skill includes {}", self.name, self.age, self.skill ); brief_intro } } impl TellInfo for Student { fn Sayage(&self) { println!("Student {}'s age is {}", self.name, self.age); } fn SelfIntroduction(&self) -> String { let brief_intro = format!( "As a student,my name is {},i'm {} years old and my come from NO.{} class", self.name, self.age, self.class ); brief_intro } } fn StageSpeech(T: &impl TellInfo) { //引入特征变量 let Info = T.SelfIntroduction(); println!("{}", &Info); } fn main() { let Teacher1 = Teacher { age: 33, name: "Tom".to_string(), skill: "Math/english/phyisc".to_string(), }; let Student1 = Student { age: 14, name: "charles".to_string(), class: 3, }; StageSpeech(&Teacher1); StageSpeech(&Student1); }
- 特征类似于java等类语言中的接口，用于给自定义类型或者常见类型变量实现指定的方法
- 常见声明如下
pub trait trait1 { fn a(&self)->Self{};},常用于声明和定义方法和函数：方法和函数的区别在于 方法中引用变量自身作为参数传入 ，而函数不依赖 - 特征变量：从各类变量中抽象出来，仅作为有某一特定特征的变量 调用方式:
- 在函数声明中直接声明，例
fn a(T:&impl Display) - Box
使用智能指针封装并调用。
- 在函数声明中直接声明，例
网络OSI模型
OSI（Open Systems Interconnection，开放系统互连）模型是国际标准化组织（ISO）于1984年提出的网络通信框架，旨在标准化网络体系结构，促进不同系统间的互联互通。它将网络通信划分为七个层次，每层负责特定功能，共同实现数据从发送端到接收端的可靠传输。本文将详细介绍OSI模型的七层结构及其核心职责。
一、OSI模型概述
OSI模型并非具体协议，而是抽象参考框架，为网络协议设计提供了分层思路。每一层为上一层提供服务，并依赖下一层的支持。通过分层，复杂网络通信被分解为模块化、可管理的部分。实际网络（如TCP/IP）常参考OSI模型，但层级划分可能有所简化。
二、七层结构详解
-
物理层（Physical Layer）
- 职责：负责比特流的物理传输，包括电压、信号、接口标准等。
- 功能：定义硬件规范（如网线、光纤、连接器类型 RJ45）、电气特性（如信号电平）、传输介质（如双绞线、同轴电缆）。
- 示例：以太网的1000BASE-T标准（千兆以太网）通过双绞线传输0和1的比特流。
- 关键点：物理层不关心数据含义，只传输原始比特。
-
数据链路层（Data Link Layer）
- 职责：在相邻节点间提供可靠的数据传输，解决物理层不可靠性问题。
- 功能：将比特封装成帧（Frame），实现错误检测与纠正（如CRC校验）、流量控制和介质访问控制（MAC）。
- 示例：以太网（IEEE 802.3）使用MAC地址标识设备，Wi-Fi（IEEE 802.11）通过CSMA/CA避免冲突。
- 关键点：分为子层——LLC（逻辑链路控制）和MAC（介质访问控制）。
-
网络层（Network Layer）
- 职责：负责数据包在网络间的路由和转发。
- 功能：提供逻辑寻址（如IP地址）、路径选择（路由算法，如OSPF、BGP）和数据包分片/重组。
- 示例：IP协议（IPv4/IPv6）定义地址格式，路由器根据路由表转发数据包。
- 关键点：网络层关注端到端传输，而非单跳链接。
-
传输层（Transport Layer）
- 职责：提供主机间可靠的数据传输服务。
- 功能：实现分段与重组、流量控制、错误重传和连接管理。
- 示例：TCP提供可靠传输（通过序号和确认机制），UDP提供无连接快速传输。
- 关键点：引入端口号（如80、443），区分同一主机上的不同应用。
-
会话层（Session Layer）
- 职责：管理应用程序间的会话，建立、维护和终止通信。
- 功能：支持会话同步（如断点续传）、对话控制（如半双工/全双工）。
- 示例：远程登录协议（如NetBIOS）中，会话层协调客户端与服务器的连接状态。
- 关键点：在实际协议中，常与传输层或应用层合并。
-
表示层（Presentation Layer）
- 职责：处理数据的表示形式，确保应用层能正确解析。
- 功能：负责数据加密/解密（如SSL/TLS）、压缩/解压、格式转换（如JPEG、XML）。
- 示例：HTTPS中，TLS加密由表示层完成；浏览器解析HTML也涉及表示层逻辑。
- 关键点：关注数据语法与语义，而非传输。
-
应用层（Application Layer）
- 职责：为用户或应用程序提供网络服务接口。
- 功能：支持具体应用协议，如文件传输（FTP）、电子邮件（SMTP）、网页浏览（HTTP）。
- 示例：浏览器通过HTTP/HTTPS请求网页，邮件客户端使用IMAP接收邮件。
- 关键点：直接面向用户，是协议的最终体现。
三、OSI模型的工作流程
假设用户通过浏览器访问网页：
- 应用层：HTTP生成请求消息。
- 表示层：数据加密为HTTPS，格式化为HTML。
- 会话层：维持浏览器与服务器的会话。
- 传输层：TCP分段数据并添加端口号（如443）。
- 网络层：IP封装数据包，确定路由路径。
- 数据链路层：以太网帧封装，添加MAC地址。
- 物理层：比特流通过网线或Wi-Fi传输。
接收端按相反顺序解封装，最终呈现网页。
四、OSI模型的意义与局限
-
意义
- 标准化：为网络协议设计提供通用框架，促进设备互操作性。
- 模块化：分层简化开发与调试，便于教育和理解。
- 灵活性：支持多种协议栈（如TCP/IP映射到OSI）。
-
局限
- 理论性强：未直接实现为具体协议，实际网络（如TCP/IP）仅用4-5层。
- 复杂性：七层划分有时过于细化，会话层和表示层功能常被合并。
- 历史背景：1984年提出时，TCP/IP已占主导，OSI普及受限。
五、与TCP/IP模型的对比
TCP/IP模型是实际网络的主流实现，与OSI的对应关系如下：
- 应用层（TCP/IP） ≈ OSI的应用层+表示层+会话层
- 传输层 ≈ OSI的传输层
- 网络层（Internet层） ≈ OSI的网络层
- 网络接口层 ≈ OSI的数据链路层+物理层
TCP/IP更简洁实用，但OSI更适合理论分析。
OSI模型作为网络通信的经典框架，清晰地展示了数据传输的分层逻辑。尽管在现代网络中，TCP/IP占据主导地位，但OSI仍以其模块化思维和标准化理念，持续影响着网络技术的发展。理解OSI模型，不仅是掌握网络基础的第一步，也是深入探索通信技术的钥匙。
TCP/IP模型：互联网通信的基石
TCP/IP（Transmission Control Protocol/Internet Protocol）模型是支撑现代互联网的实际网络协议框架，由美国国防部于20世纪70年代开发，并在1983年成为ARPANET标准。它以简洁实用的分层结构，定义了数据通信的完整流程。以下将详细介绍TCP/IP模型的四层结构、核心功能及其应用。
一、TCP/IP模型概述
TCP/IP模型是为实现异构网络互联而设计的实用协议栈，与理论性的OSI模型不同，它直接对应具体协议（如IP、TCP、HTTP）。它将通信分为四层，每层专注于特定任务，共同完成从数据发送到接收的过程。TCP/IP的成功在于其开放性、灵活性和对互联网的适配性。
二、四层结构详解
-
网络接口层（Network Interface Layer）
- 职责：负责将数据包转化为物理信号，通过硬件传输。
- 功能：包括物理传输（比特流）和数据链路功能（如帧封装、MAC寻址）。
- 协议/技术：以太网（IEEE 802.3）、Wi-Fi（IEEE 802.11）、PPP（点对点协议）。
- 示例：以太网交换机根据MAC地址转发帧，网卡将数据转为电信号。
- 关键点：未严格定义具体协议，依赖底层硬件实现，与OSI的物理层和数据链路层对应。
-
网络层（Internet Layer）
- 职责：提供端到端的逻辑寻址和路由。
- 功能：数据包封装、IP地址分配、路由选择、分片与重组。
- 核心协议：IP（IPv4/IPv6）、ICMP（用于诊断，如Ping）、IGMP（组播管理）。
- 示例：路由器根据IP地址（如192.168.1.1）转发数据包，IPv6支持128位地址扩展。
- 关键点：无连接、无状态，依赖上层协议保证可靠性。
-
传输层（Transport Layer）
- 职责：为主机间通信提供服务，区分不同应用程序。
- 功能：数据分段、流量控制、错误纠正、连接管理。
- 核心协议：
- TCP：面向连接，提供可靠传输（通过序号、确认、重传机制）。
- UDP：无连接，快速但不可靠，适合实时应用。
- 示例：TCP用于网页加载（端口80/443），UDP用于视频流（如RTP）。
- 关键点：引入端口号（如80、53），实现进程间通信。
-
应用层（Application Layer）
- 职责：为用户和应用程序提供网络服务接口。
- 功能：处理具体应用逻辑，包括数据格式化、加密、会话管理。
- 核心协议：HTTP（网页）、FTP（文件传输）、SMTP（邮件发送）、DNS（域名解析）。
- 示例：浏览器通过HTTP请求网页，邮件客户端用IMAP接收邮件。
- 关键点：涵盖OSI的应用层、表示层和会话层功能，注重实用性。
三、TCP/IP模型的工作流程
以访问网页为例：
- 应用层：浏览器生成HTTP请求（如GET codermaybe.github.io）。
- 传输层：TCP将请求分段，添加端口号（如443）和序号。
- 网络层：IP封装数据包，分配源/目标IP地址（如192.168.1.10 → 93.184.216.34）。
- 网络接口层：以太网帧封装数据，添加MAC地址，通过网线传输。
接收端按相反顺序解封装，最终显示网页。
四、TCP/IP模型的特点与优势
-
特点
- 简洁实用：四层结构减少复杂性，便于实现和部署。
- 开放标准：由IETF维护，RFC文档（如RFC 791定义IP）公开透明。
- 异构互联：支持不同硬件和网络类型（如以太网、Wi-Fi、4G/5G）。
-
优势
- 广泛应用：驱动互联网、局域网和移动网络，成为事实标准。
- 可扩展性：IPv6解决了地址枯竭问题，DNS支持动态扩展。
- 模块化：各层独立开发，上层协议可复用下层服务。
五、与OSI模型的对比
TCP/IP模型与OSI模型的对应关系如下：
- 网络接口层 ≈ OSI的物理层+数据链路层
- 网络层 ≈ OSI的网络层
- 传输层 ≈ OSI的传输层
- 应用层 ≈ OSI的应用层+表示层+会话层
区别在于：OSI为理论框架，七层划分细致；TCP/IP为实际协议栈，四层设计更紧凑，应用层功能更集中。
六、TCP/IP的演进与现状
- 历史：1974年由Vinton Cerf和Robert Kahn提出，1983年ARPANET全面采用。
- 演进：IPv4（32位地址）向IPv6（128位地址）过渡，截至2025年3月，IPv6普及率已超50%（根据APNIC数据推测）。
- 现状：支持5G、IoT、云计算等技术，HTTP/3（基于UDP的QUIC）成为2025年应用层新趋势。